From duke at openjdk.org Tue Nov 1 00:06:35 2022 From: duke at openjdk.org (David Schlosnagle) Date: Tue, 1 Nov 2022 00:06:35 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com> Message-ID: On Fri, 28 Oct 2022 20:04:18 GMT, R?mi Forax wrote: >> But it's an implementation details, BTW i wonder if the limitation is still valid, i know that John has changed the implementation of the BSM in that area. > > Anyway, i think you are right, this can be public If this is a public int field, it will be inlined to class file byte code at compile time, which may not be what you want if this value needs to change in the future. If this needs to be exposed, should it be as a public method? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mik3hall at gmail.com Tue Nov 1 00:11:52 2022 From: mik3hall at gmail.com (Michael Hall) Date: Mon, 31 Oct 2022 19:11:52 -0500 Subject: [External] : Re: Jpackage OS/X DMG install Application folder alias name incorrectly shows as path with / In-Reply-To: <5F5D63E8-06F9-4928-AD08-61958E1B9C7D@oracle.com> References: <1BE1F863-CB87-49B1-B55E-5DF1A787D1A2@gmail.com> <4226247F-D956-4B1F-98A8-93964B346CA6@gmail.com> <1D65AE81-8DF0-4849-A702-C2624085BF3A@gmail.com> <8A239F65-F7A4-44D1-963C-9754FBDF321E@oracle.com> <4FDC3A61-63E7-43FD-BA5D-C4675D5A9B18@gmail.com> <5F5D63E8-06F9-4928-AD08-61958E1B9C7D@oracle.com> Message-ID: > On Oct 31, 2022, at 6:57 PM, Alexander Matveev wrote: > > Hi Michael. > > If you mean http://mikehall.pairserver.com/DMG_windows.dmg , then I cannot open this link. It says file not found. > > Thanks, > Alexander > Sorry, wrong directory on ftp upload. Should be there now. -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Nov 1 00:25:35 2022 From: duke at openjdk.org (David Schlosnagle) Date: Tue, 1 Nov 2022 00:25:35 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com> On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 201: > 199: @SuppressWarnings("unchecked") > 200: public static List toList(E... elements) { > 201: return JUCA.listFromTrustedArrayNullsAllowed(elements); Is this public method leaking access to the JUCA shared secrets method here? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From smarks at openjdk.org Tue Nov 1 04:02:18 2022 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 1 Nov 2022 04:02:18 GMT Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) [v6] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 03:40:27 GMT, liach wrote: >> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Spec updates and clarifications. Now that the CSR is approved, this should be close to ready to go in. I just ran this through our CI system and there were a bunch of failures. Most likely they are unrelated, but I need to track this down and rerun the tests. I'll post an update when I get this figured out. ------------- PR: https://git.openjdk.org/jdk/pull/8259 From luhenry at openjdk.org Tue Nov 1 06:16:27 2022 From: luhenry at openjdk.org (Ludovic Henry) Date: Tue, 1 Nov 2022 06:16:27 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v4] In-Reply-To: References: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com> Message-ID: <3Ri8tG00c3_Ks_AKRvTYyBxa6UINFqjX24aRsKr43-M=.1a793566-8645-4f75-8c45-0a57d6551791@github.com> On Mon, 31 Oct 2022 22:06:20 GMT, Claes Redestad wrote: >> No you don't need to, the vector loop can be calculated as: >> >> IntVector accumulation = IntVector.zero(INT_SPECIES); >> for (int i = 0; i < bound; i += INT_SPECIES.length()) { >> IntVector current = IntVector.load(INT_SPECIES, array, i); >> accumulation = accumulation.mul(31**(INT_SPECIES.length())).add(current); >> } >> return accumulation.mul(IntVector.of(31**INT_SPECIES.length() - 1, ..., 31**2, 31, 1).reduce(ADD); >> >> Each iteration only requires a multiplication and an addition. The weight of lanes can be calculated just before the reduction operation. > > Ok, I can try rewriting as @merykitty suggests and compare. I'm running out of time to spend on this right now, though, so I sort of hope we can do this experiment as a follow-up RFE. You?re right, we can go forward indeed. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From luhenry at openjdk.org Tue Nov 1 06:19:25 2022 From: luhenry at openjdk.org (Ludovic Henry) Date: Tue, 1 Nov 2022 06:19:25 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v4] In-Reply-To: References: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com> Message-ID: On Mon, 31 Oct 2022 22:06:20 GMT, Claes Redestad wrote: >> No you don't need to, the vector loop can be calculated as: >> >> IntVector accumulation = IntVector.zero(INT_SPECIES); >> for (int i = 0; i < bound; i += INT_SPECIES.length()) { >> IntVector current = IntVector.load(INT_SPECIES, array, i); >> accumulation = accumulation.mul(31**(INT_SPECIES.length())).add(current); >> } >> return accumulation.mul(IntVector.of(31**INT_SPECIES.length() - 1, ..., 31**2, 31, 1).reduce(ADD); >> >> Each iteration only requires a multiplication and an addition. The weight of lanes can be calculated just before the reduction operation. > > Ok, I can try rewriting as @merykitty suggests and compare. I'm running out of time to spend on this right now, though, so I sort of hope we can do this experiment as a follow-up RFE. @cl4es i can write the assembly and send it your way if you want ------------- PR: https://git.openjdk.org/jdk/pull/10847 From alanb at openjdk.org Tue Nov 1 06:52:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Nov 2022 06:52:40 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> References: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> Message-ID: On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ? > > Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ? Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From jiefu at openjdk.org Tue Nov 1 07:28:19 2022 From: jiefu at openjdk.org (Jie Fu) Date: Tue, 1 Nov 2022 07:28:19 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v2] In-Reply-To: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> References: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> Message-ID: On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu wrote: >> Hi all, >> >> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Add jdk_vector_sanity test group > - Merge branch 'master' into JDK-8295970 > - Revert changes in test.yml > - 8295970: Add jdk_vector tests in GHA Hi all, I changed the JBS title as `Add vector api sanity tests in tier1`. And the added `jdk_vector_sanity` tests can be run in less than 2min on my testing box. Any comments? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10879 From peter.firmstone at zeus.net.au Tue Nov 1 08:07:11 2022 From: peter.firmstone at zeus.net.au (Peter Firmstone) Date: Tue, 1 Nov 2022 19:07:11 +1100 Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> Message-ID: On 1/11/2022 5:52 pm, Alan Bateman wrote: > On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > >> You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ? >> >> Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ? > Converting these use-sites to URI will require care and working through issues on a case by case basis. This is because URI is strict and will reject bad input that URL may have handled differently. It may, for example, require changing the exception handling so that exceptions such as URISyntaxException (or IAE if code is changed to URI.create) maps to what is appropriate for code using URL. So slow and careful work for future PRs I think. We found there were some common cases, we made static convenience methods to address them: Fix MS Windows file URI strings, by converting back slashes to forward slashes and inserting a forward slash before the drive letter if missing. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L289 Convert java.io.File to Uri, ensure compatibility with URLClassLoader, when trailing directory character is dropped by java.io.File. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L341 Escape illegal characters when string doesn't contain any existing escape sequences. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L926 Parse and fix a string that contains escaped sequences, any illegal characters are escaped and any that should't be escaped are un-escaped. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L939 Convert java.net.URL to Uri, automatically fixing MS Windows URI syntax. https://github.com/pfirmstone/JGDMS/blob/d8a85ff8cebac7a0e3c9a7f84c7fbfd6e9299fd7/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/net/Uri.java#L324 Cheers, Peter. > > ------------- > > PR: https://git.openjdk.org/jdk/pull/10874 From redestad at openjdk.org Tue Nov 1 09:01:30 2022 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 1 Nov 2022 09:01:30 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v4] In-Reply-To: References: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com> Message-ID: On Tue, 1 Nov 2022 06:17:16 GMT, Ludovic Henry wrote: >> Ok, I can try rewriting as @merykitty suggests and compare. I'm running out of time to spend on this right now, though, so I sort of hope we can do this experiment as a follow-up RFE. > > @cl4es i can write the assembly and send it your way if you want @luhenry if you have some time to translate that snippet then feel free! ------------- PR: https://git.openjdk.org/jdk/pull/10847 From mcimadamore at openjdk.org Tue Nov 1 11:04:52 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 1 Nov 2022 11:04:52 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v2] In-Reply-To: References: <6B56QhHY_HR1zzBPKTlI7SDS-AYVr0U9LoDDzhxtdXA=.7f43ef60-154d-4d83-9a36-4cf831f68f73@github.com> Message-ID: <2vjNyFDHkuJn2pRmWoJcBcUBkAA9IXtpSgkELnAq6zo=.8d159c9e-6779-4ddf-9c9e-f96b7efcfaae@github.com> On Fri, 28 Oct 2022 19:18:23 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4974: >> >>> 4972: if (processor != null) { >>> 4973: resultType = attribTree(processor, env, new ResultInfo(KindSelector.VAL, Type.noType)); >>> 4974: resultType = chk.checkProcessorType(processor, resultType, env); >> >> It seems that if this check is erroneous, the type that is considered as returned by the processor is just `StringTemplate`. This seems odd - if we have issues type-checking and we get StringTemplate instead of some type T that the user expects, but doesn't get (e.g. because of raw types), there could be spurious error messages generated from a type mismatch between T and StringTemplate. > > Not sure where you get `StringTemplate`. If you specify `TemplateProcessor` the `resultType` will be `String`. For example: > > > public class Processor implements TemplateProcessor { > @Override > public String process(StringTemplate st) { > return st.interpolate(); > } > } > > and > > public class Main { > public static void main(String... args) throws Throwable { > Processor processor = new Processor(); > System.out.println(processor."1234"); > } > } > > works with "1234" as a result. > > If you later change to > > > public class Processor implements TemplateProcessor { > @Override > public Integer process(StringTemplate st) { > return Integer.valueOf(st.interpolate()); > } > } > > > Then you get a `java.lang.ClassCastException` as you would expect. I'm looking at this line: Type resultType = syms.stringTemplateType; This assumes that the result type of this AST node will be StringTemplate. Now, if a processor is set, we'll call `chk.checkProcessorType` which *might* set a new expected type (e.g. a string processor type). But if any error is found in that routine (e.g. use of raw string processor), we just log an error, and return the same expected type that was passed in - so the expected type stays `StringTemplate`. Something like this: public class Processor implements TemplateProcessor { ... } Processor raw = new Processor(); String s = raw."1234". This will probably print a spurious error like "expected String, found StringTemplate". ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Tue Nov 1 11:04:53 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 1 Nov 2022 11:04:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 17:57:30 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update TemplateRuntime::combine src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Scanner.java line 100: > 98: private void ensureLookahead(int lookahead) { > 99: for (int i = savedTokens.size() ; i < lookahead ; i++) { > 100: Token ahead = tokenizer.readToken(); curious - why this change? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From dfuchs at openjdk.org Tue Nov 1 12:21:13 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 12:21:13 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding Changes to java (resp sun) .util.logging tests and javax.management tests look good to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/10792 From erikj at openjdk.org Tue Nov 1 12:47:29 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 1 Nov 2022 12:47:29 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v2] In-Reply-To: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> References: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> Message-ID: On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu wrote: >> Hi all, >> >> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Add jdk_vector_sanity test group > - Merge branch 'master' into JDK-8295970 > - Revert changes in test.yml > - 8295970: Add jdk_vector tests in GHA This looks good to me. The group tier1_part3 looks like it's currently the fastest of the 3, so it's the right one to add to. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.org/jdk/pull/10879 From mcimadamore at openjdk.org Tue Nov 1 13:04:27 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 1 Nov 2022 13:04:27 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 230: > 228: > 229: class TransStringTemplate { > 230: JCStringTemplate tree; Presumably some of these can be `final` ? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429: > 427: } > 428: > 429: private JCClassDecl newStringTemplateClass() { I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 555: > 553: if (varSym.flags() == (PUBLIC | FINAL | STATIC) && > 554: varSym.name == names.str && > 555: types.isSameType(varSym.owner.type, syms.stringTemplateType)) { Are you 100% sure that this test works? When we see a statically imported member in Resolve, which is referred to by unqualified name, we "clone" its symbol into the importing class. That is, Resolve will set STR symbol as a symbol whose owner is the class that did the importing, possibly defeating this check. See Resolve::findVar (near the end): if (bestSoFar.kind == VAR && bestSoFar.owner.type != origin.type) return bestSoFar.clone(origin); ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Tue Nov 1 13:16:40 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 1 Nov 2022 13:16:40 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 355: > 353: // If first embedded expression. > 354: if (!isStringTemplate) { > 355: checkSourceLevel(pos, Feature.STRING_TEMPLATES); If we check source level inside the `if`, we would only issue a preview error/warning once, which seems to be against JEP 12? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244: > 242: * mode |= NOLAMBDA : lambdas are not allowed > 243: */ > 244: protected static final int EXPR = 1 << 0; I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244: > 242: * mode |= NOLAMBDA : lambdas are not allowed > 243: */ > 244: protected static final int EXPR = 1 << 0; I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here (perhaps we should consider factoring it out?) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From dfuchs at openjdk.org Tue Nov 1 13:53:37 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 13:53:37 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> References: <0rHERDXBBHvhqRnD-dUoCIUlF7VXmcsY4MYdqjNHIWk=.8b00964e-0dc1-470f-8745-3fcf844d4684@github.com> Message-ID: On Mon, 31 Oct 2022 22:00:01 GMT, Phil Race wrote: > Deprecate URL constructors. Developers are encouraged to use java.net.URI to parse or construct any URL. ... To construct a URL, using URI::toURL should be preferred. > > You have jumped through some refactoring hoops to be able to apply the deprecation suppression to as little code as possible .. having made such changes, then why didn't you just make the recommended change instead ? > > Should I presume that the recommended route will have some nasty little incompatibilities we will need to be careful of first ? Possibly yes. Using URI where it was not used before might cause some behavioral changes, that would need to be examined and possibly documented through separate CSRs. This is better handled on a case-by-case basis for each area affected. The changes as currently proposed will not lead to any behavioral difference. > > And what about Peter Firmstone's comment "We stopped using java.net.URI some years ago as it's obsolete.?" > > I can't reconcile that with the recommendation to use it .. URI implements RFC 2396 with some deviations, noted in its API documentation, which make it a crossbreed between RFC 2396 and RFC 3986. As Alan noted earlier, changing URI to strictly implement RFC 3986 is not a compatible move: it was attempted in JDK 6 but had to backed out quickly as it caused widespread breakage. But even if it doesn't implement the latest RFC strictly, it's still a much more modern API and implementation than java.net.URL. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 13:53:40 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 13:53:40 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:14:22 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 885: > >> 883: >> 884: @SuppressWarnings("deprecation") >> 885: var result = new URL("jrt", host, port, file, null); > > The URL scheme for jrt does not have a port so we should look at that some time. Noted. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:00:40 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:00:40 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:16:24 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 157: > >> 155: * The URL constructors are specified to throw >> 156: * {@link MalformedURLException} but the actual parsing/validation >> 157: * that are performed is implementation dependent. Some parsing/validation > > "the ... are performed" -> "the ... is performed". done > src/java.base/share/classes/java/net/URL.java line 852: > >> 850: * @since 20 >> 851: */ >> 852: public static URL of(URI uri, URLStreamHandler streamHandler) > > The parameter is named "handler" rather than "streamHandler" in constructors so we should probably keep it the same to avoid any confusion. done ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:08:17 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:08:17 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:17:12 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 166: > >> 164: * The {@code java.net.URL} constructors are deprecated. >> 165: * Developers are encouraged to use {@link URI java.net.URI} to parse >> 166: * or construct any {@code URL}. In cases where an instance of {@code > > "any URL" -> "a URL" or "all URLs". done > src/java.base/share/classes/java/net/URL.java line 168: > >> 166: * or construct any {@code URL}. In cases where an instance of {@code >> 167: * java.net.URL} is needed to open a connection, {@link URI} can be used >> 168: * to construct or parse the URL string, possibly calling {@link > > I wonder if it might be clearer to say "url string", only to avoid anyone thinking they call URL::toString. I don't believe it would be syntactically correct to put it in all lower case since URL is an acronym. I could replace it with "URI string" instead but I'm not sure it would be better. What do you think? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:12:27 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:12:27 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Sat, 29 Oct 2022 14:24:09 GMT, Alan Bateman wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 133: > >> 131: * specified. The optional fragment is not inherited. >> 132: * >> 133: *

Constructing instances of {@code URL}

> > Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated? To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 14:26:09 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 14:26:09 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 14:10:01 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/net/URL.java line 133: >> >>> 131: * specified. The optional fragment is not inherited. >>> 132: * >>> 133: *

Constructing instances of {@code URL}

>> >> Would it be better to move the anchor to line 164 (the line where it says that the URL constructors are deprecated? > > To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`. Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the <h2> title? Would that be better? ------------- PR: https://git.openjdk.org/jdk/pull/10874 From alanb at openjdk.org Tue Nov 1 14:44:49 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Nov 2022 14:44:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: <5qgERuIuHFvg5cTRy_yCZyQXkgUoMKMYkv-Cwo2yfVs=.d3f497db-fc65-4c28-8a0e-87cfa9bcf217@github.com> Message-ID: On Mon, 31 Oct 2022 13:45:10 GMT, Jim Laskey wrote: >> Yes, it only occurs to me mid review, that said there is already an implementation in the jdk of a compact immutable that allow null inside the JDK (this implementation is used when stream.toList() is used). >> Using that implementation will avoid a bunch of indirection > > Changing to use `JUCA`. The change to JUCA means the suppress warnings will need to be extended to @SuppressWarnings({"unchecked", "varargs"}). ------------- PR: https://git.openjdk.org/jdk/pull/10889 From alanb at openjdk.org Tue Nov 1 14:51:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 1 Nov 2022 14:51:20 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 14:22:18 GMT, Daniel Fuchs wrote: >> To be discussed: I actually wanted the deprecation link ( the link from `@deprecated` ) to lead here because I find that the whole section is relevant for developers who might want to decide whether to actually move away from using constructors, or be tempted to just use `@SuppressWarnings`. > > Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the <h2> title? Would that be better? Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From weijun at openjdk.org Tue Nov 1 15:17:01 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 1 Nov 2022 15:17:01 GMT Subject: Integrated: 8296167: test/langtools/tools/jdeps/jdkinternals/ShowReplacement.java failing after JDK-8296072 In-Reply-To: <7ISuHIn0Hmcot_xfuCazJ2YEsEnxJxr0iJEXEtHSARY=.afe3cc30-00a9-4f35-8e3d-17e22a058aae@github.com> References: <7ISuHIn0Hmcot_xfuCazJ2YEsEnxJxr0iJEXEtHSARY=.afe3cc30-00a9-4f35-8e3d-17e22a058aae@github.com> Message-ID: <4NQDrQslITUfp1aoXnrn2cYyH_IDHjpJ59eb_IeODfs=.041e48d7-c46e-4743-933c-2b2473b61dc3@github.com> On Tue, 1 Nov 2022 14:18:27 GMT, Weijun Wang wrote: > The argument of `DerEncoder::derEncode` changed. This pull request has now been integrated. Changeset: da0ae512 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/da0ae5128a250bb7a5c6a7484589528db8220ed2 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod 8296167: test/langtools/tools/jdeps/jdkinternals/ShowReplacement.java failing after JDK-8296072 Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/10935 From jlahoda at openjdk.org Tue Nov 1 15:33:38 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 1 Nov 2022 15:33:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: <4jrJpr-CNMkKjBDlIVscDNqLmxyt7mh_Oz5cU8vfRWY=.e1310ec2-f363-4016-818c-5c869abb270e@github.com> On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/java.base/share/classes/java/util/FormatConcatItem.java line 51: > 49: */ > 50: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 51: public sealed interface FormatConcatItem I wonder why is this a public API - is there some way to use it from the client code? Note that in named modules, the permitted subtypes don't need to be in the same package, so if this is not needed in the API, it probably can be moved into a non-API package. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From naoto at openjdk.org Tue Nov 1 15:52:52 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 1 Nov 2022 15:52:52 GMT Subject: RFR: 8296140: Drop unused field java.util.Calendar.DATE_MASK In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 19:07:36 GMT, Andrey Turbanov wrote: > There is no usages for this field. As it has the same value as `DAY_OF_MONTH_MASK` we can drop it. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10888 From dfuchs at openjdk.org Tue Nov 1 16:14:20 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 16:14:20 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: References: Message-ID: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Integrated review feedback - Merge branch 'master' into deprecate-url-ctor-8294241 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml - Merge branch 'master' into deprecate-url-ctor-8294241 - Fix whitespace issues - 8294241 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10874/files - new: https://git.openjdk.org/jdk/pull/10874/files/fd4ca287..f6b8a9f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=01-02 Stats: 3893 lines in 203 files changed: 2469 ins; 611 del; 813 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From prr at openjdk.org Tue Nov 1 16:14:21 2022 From: prr at openjdk.org (Phil Race) Date: Tue, 1 Nov 2022 16:14:21 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Tue, 1 Nov 2022 16:10:47 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Integrated review feedback > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Tue Nov 1 16:14:22 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 1 Nov 2022 16:14:22 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v2] In-Reply-To: References: Message-ID: <2jUuJ4BHyWYygw4wAlZbgMBsxCyVgAOfhNFPl31yKLY=.5c5e0a58-e270-4e95-8cb6-d0c5f7a3bc23@github.com> On Tue, 1 Nov 2022 14:47:49 GMT, Alan Bateman wrote: >> Actually... Maybe I could move up the paragraph that says that URL constructors are deprecated up here, just after the <h2> title? Would that be better? > > Try it, it might be better. I think the main thing is that link brings the reader to somewhere close to the deprecated message. Done. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From kvn at openjdk.org Tue Nov 1 16:15:24 2022 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 1 Nov 2022 16:15:24 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v2] In-Reply-To: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> References: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> Message-ID: <4W4-SzCjMp5ML_70PyjaweJPxaBaBZuT728K3OS4sJc=.5d1b3fec-051d-4b12-bd30-b839f2368c5c@github.com> On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu wrote: >> Hi all, >> >> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Add jdk_vector_sanity test group > - Merge branch 'master' into JDK-8295970 > - Revert changes in test.yml > - 8295970: Add jdk_vector tests in GHA Good. I think we need review from @shipilev too since he had strong opinion about this. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10879 From mcimadamore at openjdk.org Tue Nov 1 17:48:49 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 1 Nov 2022 17:48:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: <4bgm2-JFThFb9QUw8ysIbkh7V4HX65CC5mInOeLn-dY=.168bd4bd-772f-46a6-920e-4ed616ba714b@github.com> On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/java.base/share/classes/java/util/FormatProcessor.java line 118: > 116: > 117: // %[argument_index$][flags][width][.precision][t]conversion > 118: private static final String formatSpecifier Should this be all upper case? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Tue Nov 1 18:24:38 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 1 Nov 2022 18:24:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com> References: <1lXCczNkyU6NVUX-kcITGUPRSJO5nhPgEZcWetMYTEw=.18a8f846-2688-445f-8d23-e2d2eeb88603@github.com> Message-ID: On Mon, 31 Oct 2022 15:51:23 GMT, R?mi Forax wrote: >> Actually instance interpolate() is the most important method. Each synthetic StringTemplate gets a specialized interpolate providing performance equivalent to string concat. And, a good percentage of processors will work with the result of interpolate to produce result. Ex. `StringProcessor STR = st -> st.interpolate();` and`TemplateProcessor JSON = st -> new JSONObject(st.interpolate());` > > Interesting ! > I believe the javadoc should mention that. Will add ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Tue Nov 1 18:24:39 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 1 Nov 2022 18:24:39 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com> References: <81w3GhLtAZqVqYEmlmtrr8sAR1ntZEL-J3HB1x8AoC0=.3d20f03c-ac54-4fb1-b292-5190352bb4a1@github.com> Message-ID: On Mon, 31 Oct 2022 13:43:24 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 45: >> >>> 43: */ >>> 44: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >>> 45: public final class TemplateRuntime { >> >> Why this class is public ? and it should be called `TemplateProcessors` linke all other classes in Java that store a bunch of static methods (Collections, Collectors, etc) > > Purely because of the BSM and BSMs access to internals of `java.lang.template`. I'll work on moving the BSM to `jdk.internal`. and access through `SharedSecrets`. Moved to internal class. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Tue Nov 1 18:24:40 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 1 Nov 2022 18:24:40 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Mon, 31 Oct 2022 20:50:49 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 119: > >> 117: Class tsClass = st.getClass(); >> 118: if (tsClass.isSynthetic()) { >> 119: try { > > I do not know if this code is worth of optimizing but the way to avoid to recompute the List> each time is to use a java.lang.ClassValue and store the classes inside an unmodifiable List. (Field[] -> Class[] -> List>) The last leg can be done just by calling List.of(), there is no need for an ArrayList here Will use List.of. I think use case is raw and caching should be left to the user. > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 132: > >> 130: return result; >> 131: } >> 132: for (Object value : st.values()) { > > I think that valueTypes() should return the types of the values not the dynamic classes of the values. > Here there is no type information so it should be Object for all values. > > It has also the nice property that the return type of the accessors returned by valueAccessors are the same as valueTypes() which is i believe more coherent. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Tue Nov 1 19:09:41 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 1 Nov 2022 19:09:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com> Message-ID: On Mon, 31 Oct 2022 21:23:19 GMT, Stuart Marks wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 99: > >> 97: private static List toList(E... elements) { >> 98: return JUCA.listFromTrustedArrayNullsAllowed(elements); >> 99: } > > I'm ok with using JUCA to create an unmodifiable list that can contain nulls. > > However, it "trusts" the argument array, meaning that the array is assumed to be referenced exclusively and so the array reference is used directly in the resulting List object. That implies that one needs to be very careful about the array that gets passed in, otherwise, the resulting List might not actually be unmodifiable. > > In particular, the call site in StringTemplate.of() > > https://github.com/openjdk/jdk/pull/10889/files#diff-d4e02e5ead5ad4f2cfe509c58d1145f599285cd6736bbf37e4116045b2fd50bcR309 > > passes the array obtained from a List parameter that comes directly from a public call, meaning that malicious code could keep a reference to the array returned by `toArray` and modify it later. You could clone the array, or just revert back to the slow path. Changing caller ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jiefu at openjdk.org Wed Nov 2 01:28:07 2022 From: jiefu at openjdk.org (Jie Fu) Date: Wed, 2 Nov 2022 01:28:07 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v2] In-Reply-To: References: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> Message-ID: On Fri, 28 Oct 2022 13:41:28 GMT, Erik Joelsson wrote: >> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Add jdk_vector_sanity test group >> - Merge branch 'master' into JDK-8295970 >> - Revert changes in test.yml >> - 8295970: Add jdk_vector tests in GHA > > I think you need to add at least one other label than `build` to this now to make sure the right people can have a say in the change. Thanks @erikj79 and @vnkozlov for the review. So @shipilev , are you fine with this change? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10879 From duke at openjdk.org Wed Nov 2 01:34:35 2022 From: duke at openjdk.org (Chris Hennick) Date: Wed, 2 Nov 2022 01:34:35 GMT Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v16] In-Reply-To: References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com> Message-ID: On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick wrote: >> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections: >> >> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`. >> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.) >> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`. > > Chris Hennick has updated the pull request incrementally with one additional commit since the last revision: > > Add parameter to enable/disable fixed PRNG seed Keep open ------------- PR: https://git.openjdk.org/jdk/pull/8131 From joe.darcy at oracle.com Wed Nov 2 02:01:43 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 1 Nov 2022 19:01:43 -0700 Subject: CSR review review for JDK-8296182: Start of release updates for JDK 21 Message-ID: <8cdc0baa-7c67-1cc2-c0a4-279def117457@oracle.com> Hello, Looking ahead to the start of JDK 21, please review the CSR for ??? JDK-8296182: Start of release updates for JDK 21 ??? https://bugs.openjdk.org/browse/JDK-8296182 which adds a new enum constant to ClassFileFormatVersion. (The draft PR https://github.com/openjdk/jdk/pull/10924 will bundle together this and several related changes closer to the start of JDK 21.) Thanks, -Joe From ysatowse at openjdk.org Wed Nov 2 04:21:24 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Wed, 2 Nov 2022 04:21:24 GMT Subject: RFR: 8296108: (tz) Update Timezone Data to 2022f Message-ID: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> Please review this PR. The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga. ------------- Commit messages: - 1st commit for tz2022f Changes: https://git.openjdk.org/jdk/pull/10940/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10940&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296108 Stats: 1362 lines in 25 files changed: 560 ins; 705 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/10940.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10940/head:pull/10940 PR: https://git.openjdk.org/jdk/pull/10940 From ysatowse at openjdk.org Wed Nov 2 04:21:24 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Wed, 2 Nov 2022 04:21:24 GMT Subject: RFR: 8296108: (tz) Update Timezone Data to 2022f In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> Message-ID: <_bDpWidUSH1vqv92HDarj8r4zkckxRJ9Q9oXghWQpNA=.66ae220a-e8cd-437a-a716-c76f5fd9b0c2@github.com> On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato wrote: > Please review this PR. The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga. @naotoj Can I ask you to review the PR? ------------- PR: https://git.openjdk.org/jdk/pull/10940 From serb at openjdk.org Wed Nov 2 05:20:22 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 2 Nov 2022 05:20:22 GMT Subject: RFR: 8296108: (tz) Update Timezone Data to 2022f In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> Message-ID: On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato wrote: > Please review this PR. The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga. Looks fine ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.org/jdk/pull/10940 From alanb at openjdk.org Wed Nov 2 09:25:35 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Nov 2022 09:25:35 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v5] In-Reply-To: References: <3DSgJdolotqpONVrELRWSUEzzKTIRpG_lgOv3eGAOQI=.31f4fa0a-2623-46cb-b2b1-fed8af0449d3@github.com> Message-ID: On Mon, 31 Oct 2022 09:52:06 GMT, Alan Bateman wrote: >> **TL;DR:** Your optimization is now contained in this PR and outperforms the previous code. Nevertheless I plead for Alternative C (double buffering) instead, which is even faster but much simpler. >> >> **Justification** >> >> I took some time and did intensive JMH testing (with two buffer sizes and with four percental start positions within the buffer to simulate non-pre-read, slightly-pre-read, mostly-pre-read and fully-pre-read buffer situations) with three variants: The current code with early buffer resize (which you say is not necessary), the current code without early buffer resize (which you propose instead), and the so-called Alternative C (which uses double-buffering instead of buffer-replacing). >> >> * Alternative B: Optimization outperforms unoptimized code >> The results are shown below, and as you can see, early buffer resize is only a problem in *some*, but not all, cases. Nevertheless I agree that should be avoided, so I already pushed it as commit https://github.com/openjdk/jdk/pull/10525/commits/9c2f502c06083694deefe6a9d4c8ee4b77a92c68 and hope that you are fine with this latest piece of code. >> >> * Alternative C: Outperforms Alternative B (optimized *and* unoptimized code) unless buffer is huge >> Interesting to see BTW is that Alternative C (double-buffering instead of buffer-replacing) even outperforms that optimized code for the default buffer size (8K), and is only slightly slower in the case of large (1M) buffers (apparently `System.arraycopy` is faster than `Arrays.fill` unless the array is huge, which I did not expect originally). As the code is super-simple compared to the current code, and as the originally assumed risk of OOME does not exists (if it would, the `fill()` method would fail already, as it uses double-buffering, too, and is called by the `read` happening *before* `transferTo`) I would propose that we go with this code instead of the optimized Alternative B: >> >> private long implTransferTo(OutputStream out) throws IOException { >> if (getClass() == BufferedInputStream.class && markpos == -1) { >> int avail = count - pos; >> if (avail > 0) { >> byte[] buffer = new byte[avail]; // Double buffering prevents poisoning and leaking >> System.arraycopy(getBufIfOpen(), pos, buffer, 0, avail); >> out.write(buffer); >> pos = count; >> } >> return avail + getInIfOpen().transferTo(out); >> } else { >> return super.transferTo(out); >> } >> } >> >> >> Here are the numbers in full length for your reference: >> >> Alternative B optimized (no early buffer resize) >> >> Benchmark (bufSize) (posPercent) Mode Cnt Score Error Units >> BufferedInputStreamTransferToPerformance.transferTo 8192 0 thrpt 25 4289,949 ?? 217,452 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 10 thrpt 25 3823,443 ?? 314,171 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 90 thrpt 25 4122,949 ?? 52,131 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 100 thrpt 25 4675,491 ?? 46,194 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 0 thrpt 25 3477,497 ?? 111,229 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 10 thrpt 25 4767,220 ?? 18,274 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 90 thrpt 25 43900,923 ?? 799,471 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 100 thrpt 25 1680163,414 ?? 29823,617 ops/s >> >> Alternative B original (with early buffer resize) >> >> Benchmark (bufSize) (posPercent) Mode Cnt Score Error Units >> BufferedInputStreamTransferToPerformance.transferTo 8192 0 thrpt 25 4346,835 ?? 273,140 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 10 thrpt 25 3816,744 ?? 220,669 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 90 thrpt 25 3624,021 ?? 340,279 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 100 thrpt 25 4484,060 ?? 95,201 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 0 thrpt 25 3507,334 ?? 140,604 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 10 thrpt 25 4800,050 ?? 44,987 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 90 thrpt 25 44327,841 ?? 256,322 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 100 thrpt 25 1699685,163 ?? 44257,421 ops/s >> >> Alternative C: Double buffering >> >> Benchmark (bufSize) (posPercent) Mode Cnt Score Error Units >> BufferedInputStreamTransferToPerformance.transferTo 8192 0 thrpt 25 4555,523 ?? 83,370 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 10 thrpt 25 3972,562 ?? 489,380 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 90 thrpt 25 4181,716 ?? 49,527 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 8192 100 thrpt 25 4602,409 ?? 125,641 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 0 thrpt 25 3373,734 ?? 161,989 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 10 thrpt 25 4684,583 ?? 87,257 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 90 thrpt 25 44082,232 ?? 364,210 ops/s >> BufferedInputStreamTransferToPerformance.transferTo 1048576 100 thrpt 25 1690855,778 ?? 53885,439 ops/s >> >> (N.B.: Huge buffers appear to have better numbers than small buffers simply because the test always transported 1 MB of data, so with a huge buffer this happens in few steps, while with small buffers this happens in many steps.) > >> **TL;DR:** Your optimization is now contained in this PR and outperforms the previous code. Nevertheless I plead for Alternative C (double buffering) instead, which is even faster but much simpler. > > You had dismissed this previously so it's useful to have results now to compare. I agree it's much simpler, it can probably use Arrays.copyOfRange too. > > For the results, can you say what the underlying input stream is and what the target output stream is? Also it would be useful to get a baseline. I suspect you have that, it's just not pasted in the table above. > @AlanBateman Alternative C+ Arrays.copyOfRange() is implemented in 92ed32c. So I think we finally got it? :-) Yes, I think so, this is a lot simpler, so I think you've got it to a good place. ------------- PR: https://git.openjdk.org/jdk/pull/10525 From alanb at openjdk.org Wed Nov 2 12:22:31 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Nov 2022 12:22:31 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Integrated review feedback > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10874 From lancea at openjdk.org Wed Nov 2 12:45:51 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 12:45:51 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() Message-ID: Hi all, This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. ------------- Commit messages: - Clarify the javadoc for InflaterInputStream::fill Changes: https://git.openjdk.org/jdk/pull/10945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292427 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10945.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10945/head:pull/10945 PR: https://git.openjdk.org/jdk/pull/10945 From lancea at openjdk.org Wed Nov 2 14:12:35 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 14:12:35 GMT Subject: RFR: JDK-8288232: Address typos in jar man page Message-ID: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> Hi Please review this update to the jar man page which removes the "=" for the non GNU style options Best Lance ------------- Commit messages: - add space for -i option - add space between option - address typos in jar man page Changes: https://git.openjdk.org/jdk/pull/10947/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10947&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288232 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10947.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10947/head:pull/10947 PR: https://git.openjdk.org/jdk/pull/10947 From shade at openjdk.org Wed Nov 2 15:14:36 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 2 Nov 2022 15:14:36 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v2] In-Reply-To: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> References: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> Message-ID: On Fri, 28 Oct 2022 07:19:31 GMT, Jie Fu wrote: >> Hi all, >> >> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Add jdk_vector_sanity test group > - Merge branch 'master' into JDK-8295970 > - Revert changes in test.yml > - 8295970: Add jdk_vector tests in GHA I think the usual style for these files is to maintain original order/sorting. test/jdk/TEST.groups line 44: > 42: :jdk_vector_sanity \ > 43: :jdk_svc_sanity \ > 44: :jdk_foreign \ Suggestion: :jdk_math \ :jdk_svc_sanity \ :jdk_foreign \ :jdk_vector_sanity \ test/jdk/TEST.groups line 80: > 78: :jdk_svc \ > 79: -:jdk_vector_sanity \ > 80: -:jdk_svc_sanity \ Suggestion: :jdk_svc \ -:jdk_svc_sanity \ -:jdk_vector_sanity \ test/jdk/TEST.groups line 367: > 365: > 366: jdk_vector_sanity = \ > 367: jdk/incubator/vector/AddTest.java \ These should probably be sorted too. ------------- PR: https://git.openjdk.org/jdk/pull/10879 From bpb at openjdk.org Wed Nov 2 15:44:31 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 2 Nov 2022 15:44:31 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 12:37:26 GMT, Lance Andersen wrote: > Hi all, > > This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.org/jdk/pull/10945 From naoto at openjdk.org Wed Nov 2 16:30:21 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 2 Nov 2022 16:30:21 GMT Subject: RFR: 8296108: (tz) Update Timezone Data to 2022f In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> Message-ID: On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato wrote: > Please review this PR. The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/10940 From alanb at openjdk.org Wed Nov 2 17:21:28 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Nov 2022 17:21:28 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 12:37:26 GMT, Lance Andersen wrote: > Hi all, > > This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 258: > 256: * unexpectedly > 257: * @apiNote > 258: * The {@link #len} field will be updated when this method is invoked. I don't think an apiNote will work here as it need to be normative text. I suspect this issue will require specifying fill to read up to buf.length bytes into buf starting at element 0 and setting len to the number of bytes. ------------- PR: https://git.openjdk.org/jdk/pull/10945 From duke at openjdk.org Wed Nov 2 17:35:32 2022 From: duke at openjdk.org (Justin Lu) Date: Wed, 2 Nov 2022 17:35:32 GMT Subject: Integrated: 8295670: Remove duplication in java/util/Formatter/Basic*.java In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 21:51:03 GMT, Justin Lu wrote: > Issue: Duplication of methods between Basic*.java test classes, due to auto generation by genBasic.sh > > Fix: Reorganize parts of Basic-X.java.template into base class in Basic.java. Toggled -nel flag for generation script (genBasic.sh) to remove excessive white space. Moved a previous direct change to BasicDateTime.java into the template. > > Note: Main files to look at are Basic.java and Basic-X.java.template, as the rest are a reflection of the auto generation This pull request has now been integrated. Changeset: f84b0ad0 Author: Justin Lu Committer: Brent Christian URL: https://git.openjdk.org/jdk/commit/f84b0ad07c73c305d21c71ec6b8195dc1ee31a3e Stats: 29646 lines in 22 files changed: 1511 ins; 27888 del; 247 mod 8295670: Remove duplication in java/util/Formatter/Basic*.java Reviewed-by: bchristi, lancea, naoto ------------- PR: https://git.openjdk.org/jdk/pull/10910 From jlaskey at openjdk.org Wed Nov 2 17:49:58 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 17:49:58 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v8] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: - Merge branch 'master' into 8285932 - Add @SafeVarargs declarations - Move template bootstrap - Requested changes #2 - Requested changes - Remove .orig file - Update TemplateRuntime::combine - Move StringConcatItem to FormatConcatItem - Tabs to spaces - Force processor before template string expression - ... and 12 more: https://git.openjdk.org/jdk/compare/9bfd9379...6cea084b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/6d1d902e..6cea084b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=06-07 Stats: 145345 lines in 1262 files changed: 82705 ins; 31717 del; 30923 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Wed Nov 2 17:50:00 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Nov 2022 17:50:00 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Tue, 1 Nov 2022 18:22:07 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 119: >> >>> 117: Class tsClass = st.getClass(); >>> 118: if (tsClass.isSynthetic()) { >>> 119: try { >> >> I do not know if this code is worth of optimizing but the way to avoid to recompute the List> each time is to use a java.lang.ClassValue and store the classes inside an unmodifiable List. (Field[] -> Class[] -> List>) The last leg can be done just by calling List.of(), there is no need for an ArrayList here > > Will use List.of. I think use case is raw and caching should be left to the user. i agree ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 2 17:56:14 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 17:56:14 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v9] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/6cea084b..c81d0d20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=07-08 Stats: 104 lines in 7 files changed: 85 ins; 2 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 2 18:05:15 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 18:05:15 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Tue, 1 Nov 2022 12:41:19 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 230: > >> 228: >> 229: class TransStringTemplate { >> 230: JCStringTemplate tree; > > Presumably some of these can be `final` ? Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 2 18:05:16 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 18:05:16 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 18:47:54 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update TemplateRuntime::combine > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Scanner.java line 100: > >> 98: private void ensureLookahead(int lookahead) { >> 99: for (int i = savedTokens.size() ; i < lookahead ; i++) { >> 100: Token ahead = tokenizer.readToken(); > > curious - why this change? Residue from lookahead experiments. Will revert. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From smarks at openjdk.org Wed Nov 2 18:16:25 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 2 Nov 2022 18:16:25 GMT Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) [v6] In-Reply-To: References: Message-ID: <8VbaKYmdnuhiXHnZKvcbjJVp-BtV5I79Lpljo2qdFas=.b0ca565d-50f6-4f8d-98fb-f3c5ffb9184b@github.com> On Wed, 5 Oct 2022 03:40:27 GMT, liach wrote: >> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Spec updates and clarifications. Sorry, the issues with the test failures were a distraction. I had used the wrong version of an internal test suite. Once I figured that out and used the right version, everything passes. OK to integrate! I will sponsor this. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.org/jdk/pull/8259 From joehw at openjdk.org Wed Nov 2 18:19:17 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 2 Nov 2022 18:19:17 GMT Subject: RFR: JDK-8288232: Address typos in jar man page In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> Message-ID: On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen wrote: > Hi > > Please review this update to the jar man page which removes the "=" for the non GNU style options > > Best > Lance Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10947 From jlaskey at openjdk.org Wed Nov 2 18:20:39 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 18:20:39 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Tue, 1 Nov 2022 12:50:52 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 555: > >> 553: if (varSym.flags() == (PUBLIC | FINAL | STATIC) && >> 554: varSym.name == names.str && >> 555: types.isSameType(varSym.owner.type, syms.stringTemplateType)) { > > Are you 100% sure that this test works? When we see a statically imported member in Resolve, which is referred to by unqualified name, we "clone" its symbol into the importing class. That is, Resolve will set STR symbol as a symbol whose owner is the class that did the importing, possibly defeating this check. See Resolve::findVar (near the end): > > > if (bestSoFar.kind == VAR && bestSoFar.owner.type != origin.type) > return bestSoFar.clone(origin); Absolutely certain. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at univ-mlv.fr Wed Nov 2 18:27:02 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 2 Nov 2022 19:27:02 +0100 (CET) Subject: [External] : Re: New candidate JEP: 431: Sequenced Collections In-Reply-To: References: <20221011231719.86821547E2D@eggemoggin.niobe.net> <1020834747.25340915.1665735651688.JavaMail.zimbra@u-pem.fr> <65da58eb-6d9b-1d3b-50c4-6a5ea9e6aafc@oracle.com> <1390728427.28765698.1666105496447.JavaMail.zimbra@u-pem.fr> Message-ID: <1822934833.38464132.1667413622471.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Stuart Marks" > To: "Remi Forax" > Cc: "core-libs-dev" > Sent: Saturday, October 29, 2022 2:16:06 AM > Subject: Re: [External] : Re: New candidate JEP: 431: Sequenced Collections [...] > > You seem to be talking about introduction of new types in opposition to > introduction > of default methods. This proposal does both. Clearly if you're using an old > library, > you can't use new types with it. But if the old library consumes or produces > say, a > List, new applications can definitely use all the default methods added to List > by > this proposal. > > We've previously discussed adding new default methods (getFirst, reversed) to > some > existing type (like Collection) instead of on a new type. The problem is that > they > appear on all collections, even those that have no encounter order. Their > specifications would thus be so weak as to be meaningless. That's the > justification > for adding a new type: to give these methods meaning. All collections have an order the one of their iterator. [...] > > There is a definition of encounter order, but there is no specification of how > the > encounter order is established or how it's modified. That's left to > implementations and subtypes. How this is different to saying the encounter order is the one of the iterator ? > > This example 1) gets the first element, 2) adds another element, and 3) gets the > first element again. Step 2 is a modification to the collection, so there's no > basis > for asserting that the element obtained in step 1 always equals the element > obtained > in step 3. The example shows that add() does not add() at the end of a SequencedSet, the order defined SequencedSet is at best surprising, it's all i'm saying. That why i think SequencedCollection as an interface does not worth the trouble because you can not offer more guarantees than saying the order is the order of the iterator. But at least if the operations are defined on java.util.Collection, people will not fall into the trap of thinking that "sequenced" means that add() adds at the end of the sequence. > >>>> - LinkedHashMap/LinkedHashSet are dinosaurs, there are more efficient >>>> implementations of the concepts of ordered set / ordered map both in term of >>>> memory footprint and runtime execution, so adding new interfaces without >>>> exploring new implementations using Valhalla value class and in relation with >>>> the Collection Literal JEP seems premature to me. >>> >>> LinkedHashMap and LinkedHashSet are in fact used fairly frequently. They're not >>> used >>> as much as HashMap, but they're used more than ArrayDeque or TreeMap. Presumably >>> this is because people find LinkedHashMap/Set useful and that the overhead >>> compared >>> to their non-linked counterparts is acceptable for the additional services they >>> provide. >>> >>> The performance and footprint of LinkedHashMap/Set are not impacted either way >>> by >>> the JEP, nor are any potential future performance improvements (including those >>> that >>> might arise because of Valhalla) precluded by the JEP. >> >> I don't disagree with all you say above, i'm saying that with Valhalla, we need >> to explore implementations of HashMap based on open addressing to get better >> cache performance. >> So adding addFirst() to LinkedHashMap now, is a risk. > > As the LinkedHashMap implementation stands today (prior to JEP 431) it needs to > perform a variety of operations that affect the order of the elements. The > addFirst() method is a new operation, but it's only a small amount of additional > work, given that there are already other operations that operate on both ends. > > In a hypothetical future open-addressed Map, there would need to be some > additional > data structure (likely an array?) that maintains the encounter order. This > structure > would need to support various element shifting and copying operations to > maintain > the ordering; consider what would need to happen with a get() operation on an > access-ordered map. I don't see any problem with implementing an addFirst() > operation on this structure. You do not need any shifting if either you use a tombstone in the array that maintain the encounter order (you can clean them at the same time you rehash) or if you define that removing an entry replace it by the last entry (like Zig let you do). > >> Also, addFirst on a sequenced collection is a dangerous method, exactly like >> List.get() is, depending on the implementation the worst case complexity can be >> either O(1) or O(n). >> I believe we will all live in a better place if we do not add new methods with >> such "complexity range". > > Not the same at all. The problem with LinkedList.get(i) is that people put it in > a > for-loop over int indexes, which seems like it should be O(n), but as we know > it's > O(n^2). That occurs a lot more frequently than indexed add() or remove(). You think that people will never loop on addFirst() ? This is exactly the same issue. > > s'marks R?mi From jlaskey at openjdk.org Wed Nov 2 18:31:14 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 18:31:14 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Tue, 1 Nov 2022 12:57:03 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429: > >> 427: } >> 428: >> 429: private JCClassDecl newStringTemplateClass() { > > I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type. The main consideration is performance. I spent quite a bit of time playing around with different implementations including metafactories (hence the carrier class work.) Since a majority of use cases will be STR and FMT, the number of classes will likely be just a few per application. Because of the change to force processor always, I will be revisiting this during the preview period to work on other solutions (I mentioned ProcessorFactories/ProcessorBuilders earlier). > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 244: > >> 242: * mode |= NOLAMBDA : lambdas are not allowed >> 243: */ >> 244: protected static final int EXPR = 1 << 0; > > I note how many of the changes in this class are "stylistic" - e.g. replacing direct manipulation of state bits with method calls. While I'm not opposed to it, this is something rather orthogonal to what's being discussed here (perhaps we should consider factoring it out?) I agree. I haven't updated uses by others, so it would be good to coordinate. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at univ-mlv.fr Wed Nov 2 18:37:20 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 2 Nov 2022 19:37:20 +0100 (CET) Subject: [External] : Re: New candidate JEP: 431: Sequenced Collections In-Reply-To: <1822934833.38464132.1667413622471.JavaMail.zimbra@u-pem.fr> References: <20221011231719.86821547E2D@eggemoggin.niobe.net> <1020834747.25340915.1665735651688.JavaMail.zimbra@u-pem.fr> <65da58eb-6d9b-1d3b-50c4-6a5ea9e6aafc@oracle.com> <1390728427.28765698.1666105496447.JavaMail.zimbra@u-pem.fr> <1822934833.38464132.1667413622471.JavaMail.zimbra@u-pem.fr> Message-ID: <954764402.38467956.1667414240143.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Remi Forax" > To: "Stuart Marks" > Cc: "core-libs-dev" > Sent: Wednesday, November 2, 2022 7:27:02 PM > Subject: Re: [External] : Re: New candidate JEP: 431: Sequenced Collections There is also the issue with equals/hashCode. You can test the equality of two lists using List.equals(), you can test the equality of two sets using Set.equals(), but you can not compare two SequencedCollection using equals. A SequencedCollection basically occupy the same lattice as Collection and do not provide enough guarantee to be different than Collection. R?mi From lancea at openjdk.org Wed Nov 2 18:51:01 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 18:51:01 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v2] In-Reply-To: References: Message-ID: > Hi all, > > This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Revise the javadoc around the len field ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10945/files - new: https://git.openjdk.org/jdk/pull/10945/files/9c860e96..9242df38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10945.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10945/head:pull/10945 PR: https://git.openjdk.org/jdk/pull/10945 From lancea at openjdk.org Wed Nov 2 18:51:04 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 18:51:04 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v2] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:17:40 GMT, Alan Bateman wrote: > I don't think an apiNote will work here as it need to be normative text. I suspect this issue will require specifying fill to read up to buf.length bytes into buf starting at element 0 and setting len to the number of bytes. Revised per your suggestion ------------- PR: https://git.openjdk.org/jdk/pull/10945 From jlaskey at openjdk.org Wed Nov 2 18:55:41 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 18:55:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <4bgm2-JFThFb9QUw8ysIbkh7V4HX65CC5mInOeLn-dY=.168bd4bd-772f-46a6-920e-4ed616ba714b@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <4bgm2-JFThFb9QUw8ysIbkh7V4HX65CC5mInOeLn-dY=.168bd4bd-772f-46a6-920e-4ed616ba714b@github.com> Message-ID: On Tue, 1 Nov 2022 17:33:30 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/util/FormatProcessor.java line 118: > >> 116: >> 117: // %[argument_index$][flags][width][.precision][t]conversion >> 118: private static final String formatSpecifier > > Should this be all upper case? Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 355: > >> 353: // If first embedded expression. >> 354: if (!isStringTemplate) { >> 355: checkSourceLevel(pos, Feature.STRING_TEMPLATES); > > If we check source level inside the `if`, we would only issue a preview error/warning once, which seems to be against JEP 12? The error is collated to the opening quote so one is sufficient. Embedded Expressions are not the feature. String templates is. The parser bails at that point. >> cat Main.java public class Main { public static void main(String... args) { int x = 10, y = 20; String s = STR."Adding {x} and {y} equals {x + y}"; String t = STR."Adding {x} and {y} equals {x + y}"; } } >> javac Main.java Main.java:4: error: string templates are a preview feature and are disabled by default. String s = STR."Adding {x} and {y} equals {x + y}"; ^ (use --enable-preview to enable string templates) 1 error ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Wed Nov 2 18:55:42 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 2 Nov 2022 18:55:42 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: <5oL6PHLa3_EJIOUaFfBkw2B6pbnoLhmDIasHPWYppfA=.6ab741a9-f0df-4076-a9b2-f82c10a45b9a@github.com> On Wed, 2 Nov 2022 18:27:30 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 429: >> >>> 427: } >>> 428: >>> 429: private JCClassDecl newStringTemplateClass() { >> >> I find it weird to have the compiler emit an implementation of StringTemplate just to capture what is there in the code. If there are many usages of string templates, this could lead to a proliferation of synthetic classes. Perhaps we should consider using a metafactory here, like we do for lambdas, so that we can return some private JDK StringTemplate implementation type. > > The main consideration is performance. I spent quite a bit of time playing around with different implementations including metafactories (hence the carrier class work.) Since a majority of use cases will be STR and FMT, the number of classes will likely be just a few per application. Because of the change to force processor always, I will be revisiting this during the preview period to work on other solutions (I mentioned ProcessorFactories/ProcessorBuilders earlier). @JimLaskey, someone will implement a LOG at some point in the future and you will get many template classes per application class. You mention the carrier but i believe you can implement something similar to a carrier erasing the type of the values but without using method handles to try to make it type safe and instead pass the real types as a class data of a hidden class and later as a type argument once the reified generics will be released. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From lancea at openjdk.org Wed Nov 2 19:06:16 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 19:06:16 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v3] In-Reply-To: References: Message-ID: > Hi all, > > This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Update len field javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10945/files - new: https://git.openjdk.org/jdk/pull/10945/files/9242df38..fa499b2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10945.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10945/head:pull/10945 PR: https://git.openjdk.org/jdk/pull/10945 From lancea at openjdk.org Wed Nov 2 19:11:32 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 19:11:32 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v4] In-Reply-To: References: Message-ID: > Hi all, > > This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Change buffer to input buffer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10945/files - new: https://git.openjdk.org/jdk/pull/10945/files/fa499b2d..0c31da70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10945.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10945/head:pull/10945 PR: https://git.openjdk.org/jdk/pull/10945 From jlaskey at openjdk.org Wed Nov 2 19:14:56 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 19:14:56 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v10] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/c81d0d20..7610dd0c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=08-09 Stats: 18 lines in 4 files changed: 0 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Wed Nov 2 19:24:40 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 2 Nov 2022 19:24:40 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Mon, 31 Oct 2022 20:11:34 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add @SafeVarargs declarations src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 74: > 72: > 73: /** > 74: * Static final processor. Suggestion: * final processor. src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 141: > 139: MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class); > 140: ValidatingProcessor processor = > 141: (ValidatingProcessor)processorGetter.asType(processorGetterType).invokeExact(); Essentially the same as: Suggestion: ValidatingProcessor processor = (ValidatingProcessor)processorGetter.invoke(); src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 184: > 182: MethodHandle mh = MethodHandles.insertArguments(DEFAULT_PROCESS_MH, 0, fragments, processor); > 183: mh = mh.withVarargs(true); > 184: mh = mh.asType(type); I suggest doing: Suggestion: mh = mh.asCollector(Object[].class, type.parameterCount()); mh = mh.asType(type); Instead, as it is more straightforward in terms of the code that gets called. (the impl of `withVarargs` + `asType` does the same thing in a more roundabout way). src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 60: > 58: * @throws NullPointerException if any of the arguments are null > 59: */ > 60: MethodHandle linkage(List fragments, MethodType type); I suggest changing the protocol here to be able to take all bootstrap arguments into account, and return a `CallSite` instead. That will allow a `ProcessorLinkage` to take the lookup and name into account as well, and allows returning e.g. a `MutableCallSite` as well. Maybe this can still be changed later as well though, since the interface is sealed. src/java.base/share/classes/java/lang/template/StringTemplate.java line 103: > 101: * // check or manipulate the fragments and/or values > 102: * ... > 103: * String result = StringTemplate.interpolate(fragments, values);; Suggestion: * String result = StringTemplate.interpolate(fragments, values); src/java.base/share/classes/java/lang/template/StringTemplate.java line 117: > 115: */ > 116: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 117: public interface StringTemplate { What is the reason for having this open to extension? Rather than just being a final class or sealed interface? (I think it is so that implementations can provide a more efficient layout rather than using Lists?) src/java.base/share/classes/java/lang/template/StringTemplate.java line 246: > 244: Objects.requireNonNull(stringTemplate, "stringTemplate should not be null"); > 245: return Objects.hashCode(stringTemplate.fragments()) ^ > 246: Objects.hashCode(stringTemplate.values()); Could also (which is also `null` safe): Suggestion: return Objects.hash(stringTemplate.fragments(), stringTemplate.values()); src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 149: > 147: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 148: @FunctionalInterface > 149: public interface ValidatingProcessor { I suggest moving the doc that gives an overview of the API here to the `package-info` file. The package-info file is a better place to provide an overview of the API I think. (that's what we do for `java.lang.foreign` as well: https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/lang/foreign/package-summary.html) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Wed Nov 2 19:24:41 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 2 Nov 2022 19:24:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com> Message-ID: On Tue, 1 Nov 2022 00:09:21 GMT, David Schlosnagle wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 201: > >> 199: @SuppressWarnings("unchecked") >> 200: public static List toList(E... elements) { >> 201: return JUCA.listFromTrustedArrayNullsAllowed(elements); > > Is this public method leaking access to the JUCA shared secrets method here? Yes, this is leaking access. I suppose this is public because it is called from `javac` generated code. But, from the perspective of the runtime, code generated by `javac` is the same as any other arbitrary non-trusted bytecode. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Wed Nov 2 19:24:41 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 2 Nov 2022 19:24:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Wed, 2 Nov 2022 17:21:11 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 184: > >> 182: MethodHandle mh = MethodHandles.insertArguments(DEFAULT_PROCESS_MH, 0, fragments, processor); >> 183: mh = mh.withVarargs(true); >> 184: mh = mh.asType(type); > > I suggest doing: > Suggestion: > > mh = mh.asCollector(Object[].class, type.parameterCount()); > mh = mh.asType(type); > > Instead, as it is more straightforward in terms of the code that gets called. (the impl of `withVarargs` + `asType` does the same thing in a more roundabout way). As a side note: I think we can add an overload to `asCollector` that takes a `MethodType`, and does the 2 lines above in one. (the array type would be the return type of the method type). ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Wed Nov 2 19:24:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 2 Nov 2022 19:24:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:49:58 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: > > - Merge branch 'master' into 8285932 > - Add @SafeVarargs declarations > - Move template bootstrap > - Requested changes #2 > - Requested changes > - Remove .orig file > - Update TemplateRuntime::combine > - Move StringConcatItem to FormatConcatItem > - Tabs to spaces > - Force processor before template string expression > - ... and 12 more: https://git.openjdk.org/jdk/compare/7a2dcaba...6cea084b src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 118: > 116: List> result = new ArrayList<>(); > 117: Class tsClass = st.getClass(); > 118: if (tsClass.isSynthetic()) { This check seems pretty ad-hoc... What happens if a synthetic class is passed that declares some `x0` field that doesn't correspond to the type of the value? i.e. someone could generating an implementation of `StringTemplate`, slap `ACC_SYNTHETIC` on it, and it seems that could have the potential to break this code. I suggest generating an override of `valueTypes` in the synthetic class emitted by javac instead. src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 160: > 158: for (int i = 0; ; i++) { > 159: Field field = tsClass.getDeclaredField("x" + i); > 160: MethodHandle mh = JLIA.unreflectField(field, false); This by-passes any access checks by using `IMPL_LOOKUP`. This seems problematic. e.g. there's a class that has some `x0` field that I can't access, but the class is not `final`. I generate an impl of `StringTemplate` that extends that class (with `ACC_SYNTHETIC`), and call `valueAccessors` to get a getter that bypasses all access checks. I think the synthetic class generated by javac should generate an override of this method as well. src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 175: > 173: int size = st.values().size(); > 174: for (int index = 0; index < size; index++) { > 175: result.add(MethodHandles.insertArguments(GET_VALUE_MH, 0, index)); The returned method handle takes a `StringTemplate` as an argument, but doesn't guard against the fact that a different string template instance can be passed than the one used here, which can lead to errors when invoking the method handle (e.g. out of bounds access, or cast failures when the value types are different). I was gonna suggest using `List::get` as a method handle instead, and then binding the `values()` list and the index to that. That would drop the `StringTemplate` param, which I suppose is important for `javac` generated code? Could add a `dropArguments` for that, but then the argument would always be ignored. Maybe alternatively, the `getValue` method could do a check that the `StringTemplate` instance passed to it is the same instance as the one used here. I don't know... ------------- PR: https://git.openjdk.org/jdk/pull/10889 From joehw at openjdk.org Wed Nov 2 19:41:14 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 2 Nov 2022 19:41:14 GMT Subject: RFR: 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names Message-ID: Fixed an issue where the condition check for limit=0 was missed. ------------- Commit messages: - 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names Changes: https://git.openjdk.org/jdk/pull/10958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294858 Stats: 97 lines in 1 file changed: 97 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10958/head:pull/10958 PR: https://git.openjdk.org/jdk/pull/10958 From jlaskey at openjdk.org Wed Nov 2 19:44:00 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 2 Nov 2022 19:44:00 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Internalize TemplateSupport ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/7610dd0c..2cf00caa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=09-10 Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From lancea at openjdk.org Wed Nov 2 19:49:27 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 19:49:27 GMT Subject: RFR: 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:32:47 GMT, Joe Wang wrote: > Fixed an issue where the condition check for limit=0 was missed. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10958 From joehw at openjdk.org Wed Nov 2 20:00:55 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 2 Nov 2022 20:00:55 GMT Subject: RFR: 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names [v2] In-Reply-To: References: Message-ID: > Fixed an issue where the condition check for limit=0 was missed. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: source changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10958/files - new: https://git.openjdk.org/jdk/pull/10958/files/01351cc2..ac008e4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10958&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10958&range=00-01 Stats: 10 lines in 2 files changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10958.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10958/head:pull/10958 PR: https://git.openjdk.org/jdk/pull/10958 From lancea at openjdk.org Wed Nov 2 20:02:42 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 20:02:42 GMT Subject: RFR: 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names [v2] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:00:55 GMT, Joe Wang wrote: >> Fixed an issue where the condition check for limit=0 was missed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > source changes Looks fine as discussed ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/10958 From naoto at openjdk.org Wed Nov 2 20:07:25 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 2 Nov 2022 20:07:25 GMT Subject: RFR: JDK-8288232: Address typos in jar man page In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> Message-ID: On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen wrote: > Hi > > Please review this update to the jar man page which removes the "=" for the non GNU style options > > Best > Lance Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10947 From naoto at openjdk.org Wed Nov 2 20:12:47 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 2 Nov 2022 20:12:47 GMT Subject: RFR: 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names [v2] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:00:55 GMT, Joe Wang wrote: >> Fixed an issue where the condition check for limit=0 was missed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > source changes Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10958 From jvernee at openjdk.org Wed Nov 2 20:13:22 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 2 Nov 2022 20:13:22 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:44:00 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize TemplateSupport src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1103: > 1101: } > 1102: > 1103: MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes); The code here us pretty dense. I suggest adding comments that show the type of `mh` as far as it is known. I think it makes it a much easier to keep track of what all the argument indexes mean. e.g. Suggestion: // (byte[],long,ttypes...) -> String MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes); src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1118: > 1116: MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype); > 1117: initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment); > 1118: mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos); Suggestion: Class ttype = ttypes[pos]; // (long,byte[],ttype) -> String MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype); initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment); // (byte[],long,ttypes...) -> String (unchanged) mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos); src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1125: > 1123: MethodHandle newArrayCombinator = lastFragment.isEmpty() ? newArray() : > 1124: newArrayWithSuffix(lastFragment); > 1125: mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator, Suggestion: // (long,ttypes...) -> String mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator, src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1143: > 1141: 0, // old-index > 1142: 1 + pos // selected argument > 1143: ); Suggestion: // (long,ttype) -> long MethodHandle mix = mixer(ttypes[pos]); boolean lastPType = pos == ttypes.length - 1; if (lastPType) { // (ttype) -> long mix = MethodHandles.insertArguments(mix, 0, initialLengthCoder); // (ttypes...) -> String mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, mix, 1 + pos // selected argument ); } else { // (long,ttypes...) -> String mh = MethodHandles.filterArgumentsWithCombiner(mh, 0, mix, 0, // old-index 1 + pos // selected argument ); ------------- PR: https://git.openjdk.org/jdk/pull/10889 From alanb at openjdk.org Wed Nov 2 20:14:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Nov 2022 20:14:39 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v4] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:11:32 GMT, Lance Andersen wrote: >> Hi all, >> >> This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Change buffer to input buffer src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 256: > 254: * This method will read up to {@link #buf}.length bytes into the input > 255: * buffer, {@link #buf}, starting at element {@code 0}. The {@link #len} > 256: * field will be set to the number of bytes read. Thanks for the update, this wording looks okay, I'm just wondering if we should add implSpec as "This method will read ..." is really "Implementation Specification". ------------- PR: https://git.openjdk.org/jdk/pull/10945 From lancea at openjdk.org Wed Nov 2 20:42:42 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 20:42:42 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v5] In-Reply-To: References: Message-ID: > Hi all, > > This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add @implSpec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10945/files - new: https://git.openjdk.org/jdk/pull/10945/files/0c31da70..3d5f2d8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10945&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10945.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10945/head:pull/10945 PR: https://git.openjdk.org/jdk/pull/10945 From lancea at openjdk.org Wed Nov 2 20:42:43 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 2 Nov 2022 20:42:43 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v4] In-Reply-To: References: Message-ID: <9lVQSp3dcJ9XEuoz2an6t4q3ZyQvZ6DhJOQnQpXFRvg=.4aec7823-5a90-4904-8136-e4758c94db10@github.com> On Wed, 2 Nov 2022 20:12:04 GMT, Alan Bateman wrote: > Thanks for the update, this wording looks okay, I'm just wondering if we should add implSpec as "This method will read ..." is really "Implementation Specification". Sure thing added the tag ------------- PR: https://git.openjdk.org/jdk/pull/10945 From alanb at openjdk.org Wed Nov 2 20:48:32 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 2 Nov 2022 20:48:32 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v5] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:42:42 GMT, Lance Andersen wrote: >> Hi all, >> >> This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add @implSpec Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10945 From bpb at openjdk.org Wed Nov 2 21:02:59 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 2 Nov 2022 21:02:59 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v5] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:42:42 GMT, Lance Andersen wrote: >> Hi all, >> >> This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add @implSpec Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10945 From bpb at openjdk.org Wed Nov 2 21:04:39 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 2 Nov 2022 21:04:39 GMT Subject: RFR: JDK-8288232: Address typos in jar man page In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> Message-ID: On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen wrote: > Hi > > Please review this update to the jar man page which removes the "=" for the non GNU style options > > Best > Lance Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10947 From jvernee at openjdk.org Wed Nov 2 21:34:45 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 2 Nov 2022 21:34:45 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:44:00 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize TemplateSupport src/java.base/share/classes/jdk/internal/template/TemplateSupport.java line 147: > 145: > 146: return support.processWithProcessor(); > 147: } Thinking about this protocol some more: this seems to depend on the processor being a constant, which precludes specialized linking of call sites where the processor is a dynamic argument. The returned method handle/call site could maybe be changed to take the processor instance as a leading argument instead. The processor can then be used to pass additional arguments to the processing code (like the DB example in the JEP). (and, AFAICS, that will also allow using calls to this BSM as the sole translation strategy for every type of processor, which seems more robust if types are changed later on to (un-)implement `ProcessorLinkage`) The `linkage` method could instead be a `static` method, which is somehow tied to the type of the processor. Since it's currently a sealed interface you could have a mapping from each implementer to the `linkage` method for the types you care about (only `FormatProcessor` atm). If that is to be opened up to public extension in the future, something like type classes would be needed I think, so that the runtime can reliably map from the processor type to the static `linkage` method. WDYT? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Wed Nov 2 21:42:42 2022 From: duke at openjdk.org (Sam Pullara) Date: Wed, 2 Nov 2022 21:42:42 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com> Message-ID: On Tue, 1 Nov 2022 00:09:21 GMT, David Schlosnagle wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 201: > >> 199: @SuppressWarnings("unchecked") >> 200: public static List toList(E... elements) { >> 201: return JUCA.listFromTrustedArrayNullsAllowed(elements); > > Is this public method leaking access to the JUCA shared secrets method here? It is also a duplicate of a private method in TemplateRuntime ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Wed Nov 2 21:55:40 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 2 Nov 2022 21:55:40 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 21:30:23 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize TemplateSupport > > src/java.base/share/classes/jdk/internal/template/TemplateSupport.java line 147: > >> 145: >> 146: return support.processWithProcessor(); >> 147: } > > Thinking about this protocol some more: this seems to depend on the processor being a constant, which precludes specialized linking of call sites where the processor is a dynamic argument. > > The returned method handle/call site could maybe be changed to take the processor instance as a leading argument instead. The processor can then be used to pass additional arguments to the processing code (like the DB example in the JEP). (and, AFAICS, that will also allow using calls to this BSM as the sole translation strategy for every type of processor, which seems more robust if types are changed later on to (un-)implement `ProcessorLinkage`) > > The `linkage` method could instead be a `static` method, which is somehow tied to the type of the processor. Since it's currently a sealed interface you could have a mapping from each implementer to the `linkage` method for the types you care about (only `FormatProcessor` atm). If that is to be opened up to public extension in the future, something like type classes would be needed I think, so that the runtime can reliably map from the processor type to the static `linkage` method. > > WDYT? (FWIW, I don't see this as prohibitive for this PR to go ahead, but maybe something to consider before finalizing the feature) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From vlivanov at openjdk.org Wed Nov 2 22:54:53 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 2 Nov 2022 22:54:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:44:00 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize TemplateSupport src/java.base/share/classes/java/lang/StringConcatHelper.java line 359: > 357: * @since 19 > 358: */ > 359: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) Just a passerby question: what's the point in marking non-public methods with `@PreviewFeature`? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Thu Nov 3 02:06:29 2022 From: duke at openjdk.org (liach) Date: Thu, 3 Nov 2022 02:06:29 GMT Subject: RFR: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) [v6] In-Reply-To: References: Message-ID: On Wed, 5 Oct 2022 03:40:27 GMT, liach wrote: >> Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Spec updates and clarifications. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/8259 From jiefu at openjdk.org Thu Nov 3 03:16:30 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 3 Nov 2022 03:16:30 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v3] In-Reply-To: References: Message-ID: > Hi all, > > As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with two additional commits since the last revision: - Update test/jdk/TEST.groups Co-authored-by: Aleksey Shipil?v - Update test/jdk/TEST.groups Co-authored-by: Aleksey Shipil?v ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10879/files - new: https://git.openjdk.org/jdk/pull/10879/files/f901b907..b0fa749f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10879&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10879&range=01-02 Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10879.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10879/head:pull/10879 PR: https://git.openjdk.org/jdk/pull/10879 From jiefu at openjdk.org Thu Nov 3 03:31:56 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 3 Nov 2022 03:31:56 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v4] In-Reply-To: References: Message-ID: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com> > Hi all, > > As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. > > Thanks. > Best regards, > Jie Jie Fu has updated the pull request incrementally with one additional commit since the last revision: Sort jdk_vector_sanity tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10879/files - new: https://git.openjdk.org/jdk/pull/10879/files/b0fa749f..d353e26f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10879&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10879&range=02-03 Stats: 19 lines in 1 file changed: 9 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10879.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10879/head:pull/10879 PR: https://git.openjdk.org/jdk/pull/10879 From jiefu at openjdk.org Thu Nov 3 03:33:22 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 3 Nov 2022 03:33:22 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v2] In-Reply-To: References: <8uMsheGwjIBbgf1nJeYkCR4Pt_ddbnq4WVKMRPwS7C0=.c59b10eb-67e1-439c-936e-857c8430c520@github.com> Message-ID: On Wed, 2 Nov 2022 15:11:36 GMT, Aleksey Shipilev wrote: >> Jie Fu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Add jdk_vector_sanity test group >> - Merge branch 'master' into JDK-8295970 >> - Revert changes in test.yml >> - 8295970: Add jdk_vector tests in GHA > > I think the usual style for these files is to maintain original order/sorting. @shipilev , all your comments had been resolved. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10879 From duke at openjdk.org Thu Nov 3 07:49:28 2022 From: duke at openjdk.org (ExE Boss) Date: Thu, 3 Nov 2022 07:49:28 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Tue, 1 Nov 2022 16:14:20 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Integrated review feedback > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml > - Merge branch 'master' into deprecate-url-ctor-8294241 > - Fix whitespace issues > - 8294241 Since?these are?in?the?same compilation?unit as?the?deprecated `URL`?constructors, `@SuppressWarnings("deprecation")` isn?t?needed: src/java.base/share/classes/java/net/URL.java line 885: > 883: @SuppressWarnings("deprecation") > 884: var result = new URL("jrt", host, port, file, null); > 885: return result; Suggestion: return new URL("jrt", host, port, file, null); src/java.base/share/classes/java/net/URL.java line 909: > 907: @SuppressWarnings("deprecation") > 908: var result = new URL((URL)null, uri.toString(), handler); > 909: return result; Suggestion: return new URL((URL)null, uri.toString(), handler); src/java.base/share/classes/java/net/URL.java line 1833: > 1831: try { > 1832: @SuppressWarnings("deprecation") > 1833: var _unused = replacementURL = new URL(urlString); Suggestion: replacementURL = new URL(urlString); ------------- PR: https://git.openjdk.org/jdk/pull/10874 From shade at openjdk.org Thu Nov 3 11:18:35 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 3 Nov 2022 11:18:35 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v4] In-Reply-To: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com> References: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com> Message-ID: On Thu, 3 Nov 2022 03:31:56 GMT, Jie Fu wrote: >> Hi all, >> >> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Sort jdk_vector_sanity tests Marked as reviewed by shade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10879 From jiefu at openjdk.org Thu Nov 3 11:18:35 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 3 Nov 2022 11:18:35 GMT Subject: RFR: 8295970: Add vector api sanity tests in tier1 [v4] In-Reply-To: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com> References: <94_J9ooQ7Sdo3Y9_Z2xOWZbzOfZ8szVM6HwqJJxnRI0=.ff557a5c-3a88-488e-8f02-73287fd3363d@github.com> Message-ID: On Thu, 3 Nov 2022 03:31:56 GMT, Jie Fu wrote: >> Hi all, >> >> As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. >> >> Thanks. >> Best regards, >> Jie > > Jie Fu has updated the pull request incrementally with one additional commit since the last revision: > > Sort jdk_vector_sanity tests Thank you all for the review and comments. ------------- PR: https://git.openjdk.org/jdk/pull/10879 From dfuchs at openjdk.org Thu Nov 3 11:20:03 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 11:20:03 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: References: Message-ID: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10874/files - new: https://git.openjdk.org/jdk/pull/10874/files/f6b8a9f9..fc899005 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=02-03 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From michaelm at openjdk.org Thu Nov 3 11:20:04 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 3 Nov 2022 11:20:04 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 10:56:28 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> src/java.base/share/classes/java/net/URL.java line 152: > 150: * provide any guarantee about its conformance to the URL > 151: * syntax specification. > 152: *

I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)? Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Thu Nov 3 11:20:05 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 11:20:05 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 10:56:28 GMT, Michael McMahon wrote: >> Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update src/java.base/share/classes/java/net/URL.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Update src/java.base/share/classes/java/net/URL.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Update src/java.base/share/classes/java/net/URL.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > > src/java.base/share/classes/java/net/URL.java line 152: > >> 150: * provide any guarantee about its conformance to the URL >> 151: * syntax specification. >> 152: *

> > I wonder do we need a stronger statement about potential incompatibility here (line 149 - 151)? > > Something to the effect that - due to URI's stricter parsing rules not all existing URL instances can be represented as URI's and some that are may turn out to be opaque unexpectedly instead of hierarchical. That would better go in URL::toURI I think - but AFAICS would only apply if you constructed the URL from one of the deprecated constructors. It's not a bad idea - but given that the CSR has been approved I'd rather track that in a follow up PR. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From dfuchs at openjdk.org Thu Nov 3 11:20:08 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 11:20:08 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v3] In-Reply-To: References: <2RkyCDunlrSHcIbxukGVDiJZU8ochwwSSTe0aCOijlg=.894b6a47-1757-4e1c-970e-51c789d85ca6@github.com> Message-ID: On Thu, 3 Nov 2022 07:42:44 GMT, ExE Boss wrote: >> Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Integrated review feedback >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml >> - Merge branch 'master' into deprecate-url-ctor-8294241 >> - Fix whitespace issues >> - 8294241 > > src/java.base/share/classes/java/net/URL.java line 885: > >> 883: @SuppressWarnings("deprecation") >> 884: var result = new URL("jrt", host, port, file, null); >> 885: return result; > > Suggestion: > > return new URL("jrt", host, port, file, null); Ah ! Good point thanks! I have accepted your suggestions. ------------- PR: https://git.openjdk.org/jdk/pull/10874 From jiefu at openjdk.org Thu Nov 3 12:18:14 2022 From: jiefu at openjdk.org (Jie Fu) Date: Thu, 3 Nov 2022 12:18:14 GMT Subject: Integrated: 8295970: Add vector api sanity tests in tier1 In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 03:53:13 GMT, Jie Fu wrote: > Hi all, > > As discussed here https://github.com/openjdk/jdk/pull/10807#pullrequestreview-1150314487 , it would be better to add the vector api tests in GHA. > > Thanks. > Best regards, > Jie This pull request has now been integrated. Changeset: d771abb2 Author: Jie Fu URL: https://git.openjdk.org/jdk/commit/d771abb2fbc72e02faf02f0724aea301953ac5e8 Stats: 27 lines in 1 file changed: 27 ins; 0 del; 0 mod 8295970: Add vector api sanity tests in tier1 Reviewed-by: shade, erikj, kvn ------------- PR: https://git.openjdk.org/jdk/pull/10879 From aefimov at openjdk.org Thu Nov 3 13:05:33 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Thu, 3 Nov 2022 13:05:33 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> `java.naming` changes looks reasonable to me. Thanks! ------------- Marked as reviewed by aefimov (Committer). PR: https://git.openjdk.org/jdk/pull/10874 From jlaskey at openjdk.org Thu Nov 3 14:27:50 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 14:27:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Wed, 2 Nov 2022 17:04:29 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 74: > >> 72: >> 73: /** >> 74: * Static final processor. > > Suggestion: > > * final processor. "The static final processor that triggered the BSM generation." - Changing > src/java.base/share/classes/java/lang/template/StringTemplate.java line 103: > >> 101: * // check or manipulate the fragments and/or values >> 102: * ... >> 103: * String result = StringTemplate.interpolate(fragments, values);; > > Suggestion: > > * String result = StringTemplate.interpolate(fragments, values); Changing > src/java.base/share/classes/java/lang/template/StringTemplate.java line 117: > >> 115: */ >> 116: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >> 117: public interface StringTemplate { > > What is the reason for having this open to extension? Rather than just being a final class or sealed interface? > > (I think it is so that implementations can provide a more efficient layout rather than using Lists?) Generally yes, specializations of the template. Another possibility is other languages can map their template implementations. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 246: > >> 244: Objects.requireNonNull(stringTemplate, "stringTemplate should not be null"); >> 245: return Objects.hashCode(stringTemplate.fragments()) ^ >> 246: Objects.hashCode(stringTemplate.values()); > > Could also (which is also `null` safe): > Suggestion: > > return Objects.hash(stringTemplate.fragments(), stringTemplate.values()); Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 3 14:46:46 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 14:46:46 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: <8Z6JILAAjo3h5wRJrgtjKq_g1r3d6av5pPSNPlaAtb0=.32268df7-ecfb-4549-999a-d3a2783389ef@github.com> On Wed, 2 Nov 2022 17:06:50 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 141: > >> 139: MethodType processorGetterType = MethodType.methodType(ValidatingProcessor.class); >> 140: ValidatingProcessor processor = >> 141: (ValidatingProcessor)processorGetter.asType(processorGetterType).invokeExact(); > > Essentially the same as: > Suggestion: > > ValidatingProcessor processor = (ValidatingProcessor)processorGetter.invoke(); Changing > src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 60: > >> 58: * @throws NullPointerException if any of the arguments are null >> 59: */ >> 60: MethodHandle linkage(List fragments, MethodType type); > > I suggest changing the protocol here to be able to take all bootstrap arguments into account, and return a `CallSite` instead. That will allow a `ProcessorLinkage` to take the lookup and name into account as well, and allows returning e.g. a `MutableCallSite` as well. > > Maybe this can still be changed later as well though, since the interface is sealed. Yes - this will all go away during preview. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 3 14:46:47 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 14:46:47 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Wed, 2 Nov 2022 17:23:24 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/java/lang/runtime/TemplateSupport.java line 184: >> >>> 182: MethodHandle mh = MethodHandles.insertArguments(DEFAULT_PROCESS_MH, 0, fragments, processor); >>> 183: mh = mh.withVarargs(true); >>> 184: mh = mh.asType(type); >> >> I suggest doing: >> Suggestion: >> >> mh = mh.asCollector(Object[].class, type.parameterCount()); >> mh = mh.asType(type); >> >> Instead, as it is more straightforward in terms of the code that gets called. (the impl of `withVarargs` + `asType` does the same thing in a more roundabout way). > > As a side note: I think we can add an overload to `asCollector` that takes a `MethodType`, and does the 2 lines above in one. (the array type would be the return type of the method type). Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 3 14:46:56 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 14:46:56 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:53:03 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: >> >> - Merge branch 'master' into 8285932 >> - Add @SafeVarargs declarations >> - Move template bootstrap >> - Requested changes #2 >> - Requested changes >> - Remove .orig file >> - Update TemplateRuntime::combine >> - Move StringConcatItem to FormatConcatItem >> - Tabs to spaces >> - Force processor before template string expression >> - ... and 12 more: https://git.openjdk.org/jdk/compare/ab757cc6...6cea084b > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 118: > >> 116: List> result = new ArrayList<>(); >> 117: Class tsClass = st.getClass(); >> 118: if (tsClass.isSynthetic()) { > > This check seems pretty ad-hoc... What happens if a synthetic class is passed that declares some `x0` field that doesn't correspond to the type of the value? i.e. someone could generating an implementation of `StringTemplate`, slap `ACC_SYNTHETIC` on it, and it seems that could have the potential to break this code. > > I suggest generating an override of `valueTypes` in the synthetic class emitted by javac instead. I've mentioned TemplateProcessorFactorys and TemplateProcessorBuilders as the long term solution. I think I'll just pull these methods. Optimizing processors is something that needs more discussion. > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 160: > >> 158: for (int i = 0; ; i++) { >> 159: Field field = tsClass.getDeclaredField("x" + i); >> 160: MethodHandle mh = JLIA.unreflectField(field, false); > > This by-passes any access checks by using `IMPL_LOOKUP`. > > This seems problematic. e.g. there's a class that has some `x0` field that I can't access, but the class is not `final`. I generate an impl of `StringTemplate` that extends that class (with `ACC_SYNTHETIC`), and call `valueAccessors` to get a getter that bypasses all access checks. > > I think the synthetic class generated by javac should generate an override of this method as well. See previous. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From simonis at openjdk.org Thu Nov 3 14:49:37 2022 From: simonis at openjdk.org (Volker Simonis) Date: Thu, 3 Nov 2022 14:49:37 GMT Subject: RFR: JDK-8292427: Improve specification of InflaterInputStream.fill() [v5] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:42:42 GMT, Lance Andersen wrote: >> Hi all, >> >> This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add @implSpec Looks good to me. Thanks for updating the CSR. ------------- Marked as reviewed by simonis (Reviewer). PR: https://git.openjdk.org/jdk/pull/10945 From jlaskey at openjdk.org Thu Nov 3 14:52:50 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 14:52:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Wed, 2 Nov 2022 17:44:24 GMT, R?mi Forax wrote: >> Will use List.of. I think use case is raw and caching should be left to the user. > > i agree I agree. Need a balance of performance and #classes. Just something I'll work on during preview. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 3 14:52:59 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 14:52:59 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v8] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 18:01:41 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision: >> >> - Merge branch 'master' into 8285932 >> - Add @SafeVarargs declarations >> - Move template bootstrap >> - Requested changes #2 >> - Requested changes >> - Remove .orig file >> - Update TemplateRuntime::combine >> - Move StringConcatItem to FormatConcatItem >> - Tabs to spaces >> - Force processor before template string expression >> - ... and 12 more: https://git.openjdk.org/jdk/compare/882a8efa...6cea084b > > src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 175: > >> 173: int size = st.values().size(); >> 174: for (int index = 0; index < size; index++) { >> 175: result.add(MethodHandles.insertArguments(GET_VALUE_MH, 0, index)); > > The returned method handle takes a `StringTemplate` as an argument, but doesn't guard against the fact that a different string template instance can be passed than the one used here, which can lead to errors when invoking the method handle (e.g. out of bounds access, or cast failures when the value types are different). > > I was gonna suggest using `List::get` as a method handle instead, and then binding the `values()` list and the index to that. That would drop the `StringTemplate` param, which I suppose is important for `javac` generated code? Could add a `dropArguments` for that, but then the argument would always be ignored. > > Maybe alternatively, the `getValue` method could do a check that the `StringTemplate` instance passed to it is the same instance as the one used here. > > I don't know... Pulled method ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 3 15:09:46 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 15:09:46 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: <5sTm6SXnv2pN72X7RO_dEajB5VJqPwzjew8oep4NVPQ=.ee7c52aa-448b-49cc-a076-dbdccbe11c9f@github.com> On Wed, 2 Nov 2022 20:07:15 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize TemplateSupport > > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1103: > >> 1101: } >> 1102: >> 1103: MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes); > > The code here us pretty dense. I suggest adding comments that show the type of `mh` as far as it is known. I think it makes it a much easier to keep track of what's going on (esp. what all the argument indexes mean). e.g. > Suggestion: > > // (byte[],long,ttypes...) -> String > MethodHandle mh = MethodHandles.dropArguments(newString(), 2, ttypes); Noted ------------- PR: https://git.openjdk.org/jdk/pull/10889 From michaelm at openjdk.org Thu Nov 3 15:10:37 2022 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 3 Nov 2022 15:10:37 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v4] In-Reply-To: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> References: <1AnBlPeUPttoymtYDz2qDIqPWieqUjl3ohZYIJ65Cp0=.9eb13058-8518-45b3-89f4-ae70792641e7@github.com> Message-ID: On Thu, 3 Nov 2022 11:20:03 GMT, Daniel Fuchs wrote: >> Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. >> >> The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. >> >> This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. >> >> In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. >> >> In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. >> >> Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. >> >> The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 > > Daniel Fuchs has updated the pull request incrementally with three additional commits since the last revision: > > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/java/net/URL.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Marked as reviewed by michaelm (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10874 From jlaskey at openjdk.org Thu Nov 3 15:11:52 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 15:11:52 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 22:50:29 GMT, Vladimir Ivanov wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize TemplateSupport > > src/java.base/share/classes/java/lang/StringConcatHelper.java line 359: > >> 357: * @since 19 >> 358: */ >> 359: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > > Just a passerby question: what's the point in marking non-public methods with `@PreviewFeature`? It also lets JDK developers know that the methods are transitional. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 3 15:47:49 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 15:47:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:07:50 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize TemplateSupport > > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1118: > >> 1116: MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype); >> 1117: initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment); >> 1118: mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos); > > Suggestion: > > Class ttype = ttypes[pos]; > // (long,byte[],ttype) -> long > MethodHandle prepender = prepender(lastFragment.isEmpty() ? null : fragment, ttype); > initialLengthCoder = JLA.stringConcatMix(initialLengthCoder, fragment); > // (byte[],long,ttypes...) -> String (unchanged) > mh = MethodHandles.filterArgumentsWithCombiner(mh, 1, prepender,1, 0, 2 + pos); Changing > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1125: > >> 1123: MethodHandle newArrayCombinator = lastFragment.isEmpty() ? newArray() : >> 1124: newArrayWithSuffix(lastFragment); >> 1125: mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator, > > Suggestion: > > // (long,ttypes...) -> String > mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, newArrayCombinator, Changing > src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1143: > >> 1141: 0, // old-index >> 1142: 1 + pos // selected argument >> 1143: ); > > Suggestion: > > // (long,ttype) -> long > MethodHandle mix = mixer(ttypes[pos]); > boolean lastPType = pos == ttypes.length - 1; > > if (lastPType) { > // (ttype) -> long > mix = MethodHandles.insertArguments(mix, 0, initialLengthCoder); > // (ttypes...) -> String > mh = MethodHandles.foldArgumentsWithCombiner(mh, 0, mix, > 1 + pos // selected argument > ); > } else { > // (long,ttypes...) -> String > mh = MethodHandles.filterArgumentsWithCombiner(mh, 0, mix, > 0, // old-index > 1 + pos // selected argument > ); Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From dfuchs at openjdk.org Thu Nov 3 15:52:53 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 15:52:53 GMT Subject: RFR: 8294241: Deprecate URL public constructors [v5] In-Reply-To: References: Message-ID: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 Daniel Fuchs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge branch 'master' into deprecate-url-ctor-8294241 - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/java/net/URL.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Integrated review feedback - Merge branch 'master' into deprecate-url-ctor-8294241 - Updated after review comments. In particular var tmp => var => _unused - and avoid var in java.xml - Merge branch 'master' into deprecate-url-ctor-8294241 - Fix whitespace issues - 8294241 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10874/files - new: https://git.openjdk.org/jdk/pull/10874/files/fc899005..b4a73f40 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10874&range=03-04 Stats: 42853 lines in 291 files changed: 10793 ins; 30812 del; 1248 mod Patch: https://git.openjdk.org/jdk/pull/10874.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10874/head:pull/10874 PR: https://git.openjdk.org/jdk/pull/10874 From jlaskey at openjdk.org Thu Nov 3 16:13:01 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 16:13:01 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v12] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/2cf00caa..7f3d6526 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=10-11 Stats: 172 lines in 5 files changed: 7 ins; 160 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Thu Nov 3 16:40:17 2022 From: duke at openjdk.org (liach) Date: Thu, 3 Nov 2022 16:40:17 GMT Subject: Integrated: 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) In-Reply-To: References: Message-ID: On Fri, 15 Apr 2022 05:58:32 GMT, liach wrote: > Explicitly implement `remove` and `replace` in `IdentityHashMap` to compare values by identity. Updated API documentation of these two methods ([Preview](https://cr.openjdk.java.net/~liach/8178355/IdentityHashMap.html#remove(java.lang.Object,java.lang.Object))) to mention such behavior. This pull request has now been integrated. Changeset: 53905e60 Author: Stuart Marks Committer: Stuart Marks URL: https://git.openjdk.org/jdk/commit/53905e600a0f0f008440da52b4d2b87cc9c5c8dc Stats: 166 lines in 2 files changed: 153 ins; 2 del; 11 mod 8178355: IdentityHashMap uses identity-based comparison for values everywhere except remove(K,V) and replace(K,V,V) Reviewed-by: smarks ------------- PR: https://git.openjdk.org/jdk/pull/8259 From mchung at openjdk.org Thu Nov 3 16:52:08 2022 From: mchung at openjdk.org (Mandy Chung) Date: Thu, 3 Nov 2022 16:52:08 GMT Subject: RFR: 8295673: Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 12:16:54 GMT, Coleen Phillimore wrote: > This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. > Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() > > Tested with tier1-6 and internal applications. Marked as reviewed by mchung (Reviewer). Adding core-libs-dev so that more developers know this behavioral change. *Background:* Prior to JDK 7, custom class loaders using non-hierarchical class delegation model were prone to deadlock (see [1] for details). This workaround was added in the VM in JDK 6 to allow parallel class loading for non-parallel-capable class loaders to avoid deadlocks. The VM also supports a common workaround at the time that some customers explicitly issue a wait() on the class loader lock. Such workaround was kept to allow those customers to migrate to using multi-thread-safe parallel-capable class loaders. It has been 11 years since Java 7 and it's expected that those deadlock-prone custom class loaders should have migrated to the parallel-capable class loaders. If customers have class loaders depending on this legacy behavior, they can set `-XX:+EnableWaitForParallelLoad` flag to enable the legacy behavior and migrate to parallel-capable class loaders as soon as possible. The `EnableWaitForParallelLoad` VM flag will be removed in a future release. Refers to CSR [JDK-8295848](https://bugs.openjdk.org/browse/JDK-8295848) for details. ------------- PR: https://git.openjdk.org/jdk/pull/10832 From lancea at openjdk.org Thu Nov 3 17:05:08 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 3 Nov 2022 17:05:08 GMT Subject: Integrated: JDK-8292427: Improve specification of InflaterInputStream.fill() In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 12:37:26 GMT, Lance Andersen wrote: > Hi all, > > This PR will update the javadoc to clarify the existing behavior of InflaterInputStream::fill as it currently omits the possibility that a EOFException may be thrown and that the protected `len` field is also updated by this method. This pull request has now been integrated. Changeset: 72f74df4 Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/72f74df49afc4ce31bf0d696b603610a991da094 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod 8292427: Improve specification of InflaterInputStream.fill() Reviewed-by: bpb, alanb, simonis ------------- PR: https://git.openjdk.org/jdk/pull/10945 From joehw at openjdk.org Thu Nov 3 17:05:05 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 3 Nov 2022 17:05:05 GMT Subject: RFR: 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names [v2] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:00:55 GMT, Joe Wang wrote: >> Fixed an issue where the condition check for limit=0 was missed. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > source changes Thanks Lance, Naoto! ------------- PR: https://git.openjdk.org/jdk/pull/10958 From lancea at openjdk.org Thu Nov 3 17:09:38 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 3 Nov 2022 17:09:38 GMT Subject: Integrated: JDK-8288232: Address typos in jar man page In-Reply-To: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> References: <86ashnfJVnT6bCN_mH4ybey5bzOyLeTBrnC6a_hIuAg=.db6990cf-a076-4d8f-b205-fd25ad348eb8@github.com> Message-ID: On Wed, 2 Nov 2022 14:04:45 GMT, Lance Andersen wrote: > Hi > > Please review this update to the jar man page which removes the "=" for the non GNU style options > > Best > Lance This pull request has now been integrated. Changeset: 68209adf Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/68209adfa788b3cdf86c75f74857dd28c74c3cc2 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 8288232: Address typos in jar man page Reviewed-by: joehw, naoto, bpb ------------- PR: https://git.openjdk.org/jdk/pull/10947 From joehw at openjdk.org Thu Nov 3 17:09:41 2022 From: joehw at openjdk.org (Joe Wang) Date: Thu, 3 Nov 2022 17:09:41 GMT Subject: Integrated: 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 19:32:47 GMT, Joe Wang wrote: > Fixed an issue where the condition check for limit=0 was missed. This pull request has now been integrated. Changeset: 2ff9d3af Author: Joe Wang URL: https://git.openjdk.org/jdk/commit/2ff9d3af815c0f6ff2643d8fc562cec20ef6c324 Stats: 107 lines in 3 files changed: 102 ins; 0 del; 5 mod 8294858: XMLStreamReader does not respect jdk.xml.maxXMLNameLimit=0 for namespace names Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.org/jdk/pull/10958 From dfuchs at openjdk.org Thu Nov 3 17:22:28 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 3 Nov 2022 17:22:28 GMT Subject: Integrated: 8294241: Deprecate URL public constructors In-Reply-To: References: Message-ID: <4AGCrDQ4XC3UDTwYPRw8OPCbIFPueKKAGAJVb7ulbmM=.d7bc126d-3230-4d27-8519-ff06233dd8d9@github.com> On Wed, 26 Oct 2022 16:00:56 GMT, Daniel Fuchs wrote: > Deprecate URL constructors. Developers are encouraged to use `java.net.URI` to parse or construct any URL. > > The `java.net.URL` class does not itself encode or decode any URL components according to the escaping mechanism defined in RFC2396. It is the responsibility of the caller to encode any fields, which need to be escaped prior to calling URL, and also to decode any escaped fields, that are returned from URL. > > This has lead to many issues in the past. Indeed, if used improperly, there is no guarantee that `URL::toString` or `URL::toExternalForm` will lead to a URL string that can be parsed back into the same URL. This can lead to constructing misleading URLs. Another issue is with `equals()` and `hashCode()` which may have to perform a lookup, and do not take encoding/escaping into account. > > In Java SE 1.4 a new class, `java.net.URI`, has been added to mitigate some of the shortcoming of `java.net.URL`. Conversion methods to create a URL from a URI were also added. However, it was left up to the developers to use `java.net.URI`, or not. This RFE proposes to deprecate all public constructors of `java.net.URL`, in order to provide a stronger warning about their potential misuses. To construct a URL, using `URI::toURL` should be preferred. > > In order to provide an alternative to the constructors that take a stream handler as parameter, a new factory method `URL::fromURI(java.net.URI, java.net.URLStreamHandler)` is provided as part of this change. > > Places in the JDK code base that were constructing `java.net.URL` have been temporarily annotated with `@SuppressWarnings("deprecation")`. Some related issues will be logged to revisit the calling code. > > The CSR can be reviewed here: https://bugs.openjdk.org/browse/JDK-8295949 This pull request has now been integrated. Changeset: 4338f527 Author: Daniel Fuchs URL: https://git.openjdk.org/jdk/commit/4338f527aa81350e3636dcfbcd2eb17ddaad3914 Stats: 853 lines in 82 files changed: 707 ins; 5 del; 141 mod 8294241: Deprecate URL public constructors Reviewed-by: joehw, prr, alanb, aefimov, michaelm ------------- PR: https://git.openjdk.org/jdk/pull/10874 From jlaskey at openjdk.org Thu Nov 3 17:23:53 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 17:23:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Internalize FormatConcatItem ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/7f3d6526..b35ed665 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=11-12 Stats: 151 lines in 7 files changed: 62 ins; 86 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 3 17:23:54 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 3 Nov 2022 17:23:54 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <4jrJpr-CNMkKjBDlIVscDNqLmxyt7mh_Oz5cU8vfRWY=.e1310ec2-f363-4016-818c-5c869abb270e@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <4jrJpr-CNMkKjBDlIVscDNqLmxyt7mh_Oz5cU8vfRWY=.e1310ec2-f363-4016-818c-5c869abb270e@github.com> Message-ID: On Tue, 1 Nov 2022 15:31:20 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add @SafeVarargs declarations > > src/java.base/share/classes/java/util/FormatConcatItem.java line 51: > >> 49: */ >> 50: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >> 51: public sealed interface FormatConcatItem > > I wonder why is this a public API - is there some way to use it from the client code? > > Note that in named modules, the permitted subtypes don't need to be in the same package, so if this is not needed in the API, it probably can be moved into a non-API package. Moved ------------- PR: https://git.openjdk.org/jdk/pull/10889 From dholmes at openjdk.org Fri Nov 4 02:23:32 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 4 Nov 2022 02:23:32 GMT Subject: RFR: 8295673: Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 12:16:54 GMT, Coleen Phillimore wrote: > This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. > Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() > > Tested with tier1-6 and internal applications. It would be a little clearer if the bug synopsis was "Deprecate and disable legacy ...". A couple of queries below, but otherwise this looks good - and it will be good to see this old workaround disappear. Thanks. src/hotspot/share/classfile/placeholders.cpp line 137: > 135: assert(action != PlaceholderTable::LOAD_INSTANCE || seen == NULL, > 136: "Only one LOAD_INSTANCE allowed at a time"); > 137: Unclear why this is removed? If disabling the new flag causes this fail then shouldn't the new flag form part of the condition? src/hotspot/share/classfile/systemDictionary.cpp line 597: > 595: double_lock_wait(current, lockObject); > 596: } else { > 597: return NULL; Not clear why we return NULL here rather than just falling through and retrying? ------------- PR: https://git.openjdk.org/jdk/pull/10832 From ysatowse at openjdk.org Fri Nov 4 02:27:40 2022 From: ysatowse at openjdk.org (Yoshiki Sato) Date: Fri, 4 Nov 2022 02:27:40 GMT Subject: Integrated: 8296108: (tz) Update Timezone Data to 2022f In-Reply-To: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> References: <80z4Y-nV_vdRijEC6u8gfXhBkenIpXFDiHKQVTCjp8A=.5c34de58-91a8-4c2c-af57-a67609414c83@github.com> Message-ID: On Wed, 2 Nov 2022 04:10:43 GMT, Yoshiki Sato wrote: > Please review this PR. The PR includes changes in the resource bundle sources to follow the time zone change observed in America/Chihuahua and America/Ojinaga. This pull request has now been integrated. Changeset: 9d3b4ef2 Author: Yoshiki Sato Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/9d3b4ef2ad658afb5379796b7224458c12c81f5d Stats: 1362 lines in 25 files changed: 560 ins; 705 del; 97 mod 8296108: (tz) Update Timezone Data to 2022f Reviewed-by: serb, naoto ------------- PR: https://git.openjdk.org/jdk/pull/10940 From forax at openjdk.org Fri Nov 4 08:30:49 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 4 Nov 2022 08:30:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v11] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 21:53:00 GMT, Jorn Vernee wrote: >> src/java.base/share/classes/jdk/internal/template/TemplateSupport.java line 147: >> >>> 145: >>> 146: return support.processWithProcessor(); >>> 147: } >> >> Thinking about this protocol some more: this seems to depend on the processor being a constant, which precludes specialized linking of call sites where the processor is a dynamic argument. >> >> The returned method handle/call site could maybe be changed to take the processor instance as a leading argument instead. The processor can then be used to pass additional arguments to the processing code (like the DB example in the JEP). (and, AFAICS, that will also allow using calls to this BSM as the sole translation strategy for every type of processor, which seems more robust if types are changed later on to (un-)implement `ProcessorLinkage`) >> >> The `linkage` method could instead be a `static` method, which is somehow tied to the type of the processor. Since it's currently a sealed interface you could have a mapping from each implementer to the `linkage` method for the types you care about (only `FormatProcessor` atm). If that is to be opened up to public extension in the future, something like type classes would be needed I think, so that the runtime can reliably map from the processor type to the static `linkage` method. >> >> WDYT? > > (FWIW, I don't see this as prohibitive for this PR to go ahead, but maybe something to consider before finalizing the feature) Yes, the current code only supports processors with no fields, which is Okay given that the interface `ProcessorLinkage` is sealed. If/When the processor linkage API is open for everyone as you said the design will have to be changed. But going the other way, creates a general mechanism is painful because either you have an adhoc way to associate the processor to a BSM-like method or you have to delay until runtime the linkage using a monomorphic/polymorphic cache (I know Jim has tested that before back-pedaling to a simpler more constrained good enough solution). ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Fri Nov 4 08:38:42 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Fri, 4 Nov 2022 08:38:42 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: <8Z6JILAAjo3h5wRJrgtjKq_g1r3d6av5pPSNPlaAtb0=.32268df7-ecfb-4549-999a-d3a2783389ef@github.com> References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <8Z6JILAAjo3h5wRJrgtjKq_g1r3d6av5pPSNPlaAtb0=.32268df7-ecfb-4549-999a-d3a2783389ef@github.com> Message-ID: On Thu, 3 Nov 2022 14:37:55 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 60: >> >>> 58: * @throws NullPointerException if any of the arguments are null >>> 59: */ >>> 60: MethodHandle linkage(List fragments, MethodType type); >> >> I suggest changing the protocol here to be able to take all bootstrap arguments into account, and return a `CallSite` instead. That will allow a `ProcessorLinkage` to take the lookup and name into account as well, and allows returning e.g. a `MutableCallSite` as well. >> >> Maybe this can still be changed later as well though, since the interface is sealed. > > Yes - this will all go away during preview. I disagree with Jorn, - CallSite.dynamicInvoker() can be used to see a `MutableCallSite` as a `MethodHandle` so returning a `MethodHandle` is as powerful as returning a `CallSite`. - Having a `ProcessorLinkage` that takes a Lookup as parameter is a security risk because it means that a processor have full access to the user code that calls the processor at runtime. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From coleenp at openjdk.org Fri Nov 4 12:26:53 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 4 Nov 2022 12:26:53 GMT Subject: RFR: 8295673: Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 02:07:25 GMT, David Holmes wrote: >> This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. >> Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() >> >> Tested with tier1-6 and internal applications. > > src/hotspot/share/classfile/placeholders.cpp line 137: > >> 135: assert(action != PlaceholderTable::LOAD_INSTANCE || seen == NULL, >> 136: "Only one LOAD_INSTANCE allowed at a time"); >> 137: > > Unclear why this is removed? If disabling the new flag causes this fail then shouldn't the new flag form part of the condition? If you want, it seemed unnecessary clutter for the assert. > src/hotspot/share/classfile/systemDictionary.cpp line 597: > >> 595: double_lock_wait(current, lockObject); >> 596: } else { >> 597: return NULL; > > Not clear why we return NULL here rather than just falling through and retrying? If we don't return we'll actually do a wait and will hang. Worse, we'll be in a tight loop holding both the ClassLoader and SystemDictionary_lock, that the other thread can't get. ------------- PR: https://git.openjdk.org/jdk/pull/10832 From asotona at openjdk.org Fri Nov 4 15:17:34 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 4 Nov 2022 15:17:34 GMT Subject: RFR: 8294982: Implementation of Classfile API Message-ID: This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. Classfile API development is tracked at: https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch Development branch of consolidated JDK class files parsing, generating, and transforming is at: https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. Please take you time to review this non-trivial JDK addition. Thank you, Adam ------------- Commit messages: - removed executable - removed executable - removed executable flags and fixed whitespaces - removed executable flag from test/micro/org/openjdk/bench/jdk/classfile/Write.java - Merge branch 'classfile-api-branch' into classfile-api-initial-branch - Merge branch 'master' into classfile-api-branch - fixed Classfile API Javadoc build - removed obsolete factory mthods LocalVariableInfo::of and LocalVariableTypeInfo::of - added Classfile.Option FILTER_DEAD_LABELS - fixed javadoc of ModuleOpenInfo and ModuleRequireInfo - ... and 85 more: https://git.openjdk.org/jdk/compare/8ee0f7d5...4b3e63d5 Changes: https://git.openjdk.org/jdk/pull/10982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294982 Stats: 53247 lines in 322 files changed: 53246 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From mchhipa at openjdk.org Fri Nov 4 15:21:10 2022 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 4 Nov 2022 15:21:10 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v3] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 19:08:06 GMT, Bill Huang wrote: >> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. >> >> Tests include: >> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java >> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java >> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Reverted exclusion of nonlocal registry tests. test/jdk/java/rmi/registry/nonLocalRegistry/NonLocalRegistryBase.java line 31: > 29: static final String instructions = > 30: "This is a manual test that requires rmiregistry run on a different host" > 31: + ". Login or ssh to a different host, install the latest JDK " replace "latest JDK" with "JDK under test" test/jdk/java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java line 55: > 53: * property -Dregistry.host set to the hostname or IP address of the different host. > 54: */ > 55: public class NonLocalRegistryTest extends NonLocalRegistryBase { Move private static void assertIsAccessException(Throwable ex) method to NonLocalRegistryBase class. test/jdk/java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java line 81: > 79: * with the hostname or IP address of the different host and run the test with jtreg. > 80: */ > 81: public class NonLocalSkeletonTest extends NonLocalRegistryBase { Move private static void assertIsAccessException(Throwable ex) method to NonLocalRegistryBase class. test/jdk/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java line 222: > 220: System.out.printf("Found expected AccessException: %s%n%n", t); > 221: } else { > 222: throw new RuntimeException("AccessException did not occur when expected", ex); private static void assertIsAccessException(Throwable ex) is define in all these three test classes, move this method in lib/jdk/test/lib test/jdk/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java line 226: > 224: } > 225: > 226: private String readHostInput(int index) { Duplicate code, this code is also in NonLocalRegistryBase.java, Please move this code in a common class under lib/jdk/test/lib. Or move this NonLocalRegistryBase.java under lib/jdk/test/lib and provide some generic name. ------------- PR: https://git.openjdk.org/jdk/pull/10825 From asotona at openjdk.org Fri Nov 4 15:28:58 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 4 Nov 2022 15:28:58 GMT Subject: RFR: 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes Message-ID: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes and this patch converts it to use Classfile API. This pull request suppose to chain on the 8294982: Implementation of Classfile API https://github.com/openjdk/jdk/pull/10982 Please review. Thank you, Adam ------------- Depends on: https://git.openjdk.org/jdk/pull/10982 Commit messages: - Merge branch 'JDK-8294982' into JDK-8294961 - 8294961: java.base java.lang.reflect.ProxyGenerator uses ASM to generate proxy classes Changes: https://git.openjdk.org/jdk/pull/10991/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10991&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294961 Stats: 455 lines in 1 file changed: 45 ins; 196 del; 214 mod Patch: https://git.openjdk.org/jdk/pull/10991.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10991/head:pull/10991 PR: https://git.openjdk.org/jdk/pull/10991 From thomas.stuefe at gmail.com Fri Nov 4 16:54:31 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 4 Nov 2022 17:54:31 +0100 Subject: Proposal: track zlib native memory usage with NMT Message-ID: Hi all, I am currently working on https://bugs.openjdk.org/browse/JDK-8296360; I was preparing the final PR [1], but then Alan did ask me to discuss this on core-libs first. Backstory: NMT tracks hotspot native allocations but does not cover the JDK libraries (small exception: Unsafe.AllocateMemory). However, the native memory footprint of JDK libraries can be significant. We have no in-VM tracker for these and need tools like valgrind or our SapMachine MallocTracer [2] to observe them. At SAP, in our proprietary VM, we have instrumented the whole JDK. Not via NMT, but with an older tracker we developed 15 years ago. It has run stable and productively on many platforms for ~15 years now, atop quite different libc implementations. It is impractical to contribute it upstream, however. Would not make much sense either since it overlaps a lot with NMT. 2018 I discussed the possibility of extending NMT across the JDK wholesale, and the associated risks and difficulties [3]. The reception was not great, so I backed off and did other things. But the issue of JDK native footprint comes up regularly. It is a thorn in our foot. Recently we had a customer whose zlib footprint exploded into the tens of GB range. Luckily the customer used our proprietary VM, so we pinpointed the cause quickly. With the OpenJDK we would have flown blind. I want to change that. Proposal: In contrast to my first proposal from 2018 I'd like to instrument the core libs only in small steps, and only for selected allocation hotspots. There are not that many. And I start with the zlib. My proposal does not touch the zlib itself. The solution works with both bundled zlib and system zlib. All the instrumentation happens in the JVM zlib wrapper. It mainly uses the zalloc mechanism of zlib streams to reroute the allocations. Costs and risks: There is a risk involved with instrumentations like these. If we overlook instrumentation points we end up with unbalanced malloc/frees (instrumented malloc+raw free, or vice versa) which would corrupt the C-heap since NMT uses malloc headers. But in this case, the risk is very small since the instrumentations are few. (Side note: our internal tracker sidesteps this problem entirely by avoiding malloc headers. Instead, it uses a hash tables to match pointers with their meta information. But that has other cons and I do not plan to change the way NMT works.) Performance-wise, instead of calling into the libc directly, we would call into the hotspot, then into the libc. That indirection will cost some cycles. If NMT is off, there does not happen much more beside the real malloc call. Even NMT summary mode is very cheap. So I don't expect this to be a problem but will run performance tests. -------- My patch [1] works and can be built and tested. But the PR is still a work in progress. I just wanted to make sure nobody generally objects to my work. Cheers, Thomas [1] https://github.com/openjdk/jdk/pull/10988 [2] https://github.com/SAP/SapMachine/wiki/SapMachine-MallocTracer [3] https://mail.openjdk.org/pipermail/hotspot-dev/2018-November/035358.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Fri Nov 4 17:02:25 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 4 Nov 2022 17:02:25 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v6] In-Reply-To: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> References: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> Message-ID: On Mon, 31 Oct 2022 13:30:13 GMT, Markus KARG wrote: >> This PR implements JDK-8294696. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Alternative C + Arrays.copyOfRange() Looks all right. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.org/jdk/pull/10525 From alanb at openjdk.org Fri Nov 4 17:02:26 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 4 Nov 2022 17:02:26 GMT Subject: RFR: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set [v6] In-Reply-To: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> References: <6qdrcRAPKcCfsrKlrr91C6mXF9mVKXj3XmDfnvImR_s=.cdb7aac1-abe3-46ea-a573-fd4c0305987e@github.com> Message-ID: On Mon, 31 Oct 2022 13:30:13 GMT, Markus KARG wrote: >> This PR implements JDK-8294696. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Alternative C + Arrays.copyOfRange() Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10525 From mcimadamore at openjdk.org Fri Nov 4 18:23:17 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 4 Nov 2022 18:23:17 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v2] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: - Merge branch 'master' into PR_20 - Merge branch 'master' into PR_20 - Merge pull request #14 from minborg/small-javadoc Update some javadocs - Update some javadocs - Revert some javadoc changes - Merge branch 'master' into PR_20 - Fix benchmark and test failure - Merge pull request #13 from minborg/revert-factories Revert MemorySegment factories - Update javadocs after comments - Revert MemorySegment factories - ... and 7 more: https://git.openjdk.org/jdk/compare/7eb59e41...3d933028 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/ac7733da..3d933028 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=00-01 Stats: 51371 lines in 672 files changed: 16181 ins; 32391 del; 2799 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From duke at openjdk.org Fri Nov 4 21:10:35 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 4 Nov 2022 21:10:35 GMT Subject: Integrated: 8294696 - BufferedInputStream.transferTo should drain buffer when mark set In-Reply-To: References: Message-ID: On Sat, 1 Oct 2022 20:29:23 GMT, Markus KARG wrote: > This PR implements JDK-8294696. This pull request has now been integrated. Changeset: 581133a0 Author: Markus Karg Committer: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/581133a0c8c7d7e98614937c54db3723cd248f07 Stats: 10 lines in 1 file changed: 7 ins; 0 del; 3 mod 8294696: BufferedInputStream.transferTo should drain buffer when mark set Reviewed-by: bpb, alanb ------------- PR: https://git.openjdk.org/jdk/pull/10525 From duke at openjdk.org Fri Nov 4 22:19:24 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 4 Nov 2022 22:19:24 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo Message-ID: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> This PR implements JDK-8296431 ------------- Commit messages: - Alternative C + Array.copyOfRange - Draft: Prevent security issues - wrapped long code lines - removed unused import - Writing available unread bytes in the optimized case - PushbackInputStream::transferTo Changes: https://git.openjdk.org/jdk/pull/10999/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296431 Stats: 268 lines in 2 files changed: 262 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10999.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10999/head:pull/10999 PR: https://git.openjdk.org/jdk/pull/10999 From duke at openjdk.org Fri Nov 4 22:24:57 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 4 Nov 2022 22:24:57 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v2] In-Reply-To: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: <-tSCFbJ19Q6-EjHk17Jo8sgytX8xvSLldn0t-xjJz4U=.04d60dbd-3945-4994-953b-321d40c18b95@github.com> > This PR implements JDK-8296431 Markus KARG has updated the pull request incrementally with one additional commit since the last revision: fixed wrong bug number ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10999/files - new: https://git.openjdk.org/jdk/pull/10999/files/26b3515c..9d387eaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10999.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10999/head:pull/10999 PR: https://git.openjdk.org/jdk/pull/10999 From almatvee at openjdk.org Fri Nov 4 23:33:18 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 4 Nov 2022 23:33:18 GMT Subject: RFR: 8296154: [macos] Change /Applications to Applications in DMG image Message-ID: Changed names of symbolic links for drag and drop location in DMG image. See attached images in JBS. "/Applications" -> "Applications" for app DMG image. "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG image. Automated test was not added, since DMGsetup.scpt is not getting executed in headless environment and thus symbolic links are not created during automated testing. ------------- Commit messages: - 8296154: [macos] Change /Applications to Applications in DMG image Changes: https://git.openjdk.org/jdk/pull/11001/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11001&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296154 Stats: 28 lines in 3 files changed: 24 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11001.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11001/head:pull/11001 PR: https://git.openjdk.org/jdk/pull/11001 From asemenyuk at openjdk.org Fri Nov 4 23:46:26 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 4 Nov 2022 23:46:26 GMT Subject: RFR: 8296154: [macos] Change /Applications to Applications in DMG image In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 23:26:00 GMT, Alexander Matveev wrote: > Changed names of symbolic links for drag and drop location in DMG image. See attached images in JBS. > "/Applications" -> "Applications" for app DMG image. > "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG image. > > Automated test was not added, since DMGsetup.scpt is not getting executed in headless environment and thus symbolic links are not created during automated testing. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 121: > 119: // use "Applications" or "JavaVirtualMachines". For user provided installation > 120: // directory we will use full path as display name. > 121: static String getInstallDirDisplayName( Is this method ever called with `false` as the last parameter? If no, I'd remove it. ------------- PR: https://git.openjdk.org/jdk/pull/11001 From bhuang at openjdk.org Sat Nov 5 00:04:39 2022 From: bhuang at openjdk.org (Bill Huang) Date: Sat, 5 Nov 2022 00:04:39 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v4] In-Reply-To: References: Message-ID: > The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. > > Tests include: > java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java > java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java > javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10825/files - new: https://git.openjdk.org/jdk/pull/10825/files/5ee556aa..278564b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=02-03 Stats: 217 lines in 5 files changed: 75 ins; 113 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/10825.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825 PR: https://git.openjdk.org/jdk/pull/10825 From bhuang at openjdk.org Sat Nov 5 00:04:40 2022 From: bhuang at openjdk.org (Bill Huang) Date: Sat, 5 Nov 2022 00:04:40 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v3] In-Reply-To: References: Message-ID: <2VbiCuTeGEE80AzxSyf5ePuW1H4yfqpr7-_mE16NPxA=.a12dff2e-c03e-4f8f-b6f5-18b25ab3cb24@github.com> On Fri, 4 Nov 2022 15:17:43 GMT, Mahendra Chhipa wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverted exclusion of nonlocal registry tests. > > test/jdk/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java line 222: > >> 220: System.out.printf("Found expected AccessException: %s%n%n", t); >> 221: } else { >> 222: throw new RuntimeException("AccessException did not occur when expected", ex); > > private static void assertIsAccessException(Throwable ex) is define in all these three test classes, move this method in lib/jdk/test/lib This method is test dependent that checks for specific keywords in the AccessException. It seems better remain inside the test classes. ------------- PR: https://git.openjdk.org/jdk/pull/10825 From almatvee at openjdk.org Sat Nov 5 01:08:11 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 5 Nov 2022 01:08:11 GMT Subject: RFR: 8296154: [macos] Change "/Applications" to "Applications" in DMG image [v2] In-Reply-To: References: Message-ID: > Changed names of symbolic links for drag and drop location in DMG image. See attached images in JBS. > "/Applications" -> "Applications" for app DMG image. > "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG image. > > Automated test was not added, since DMGsetup.scpt is not getting executed in headless environment and thus symbolic links are not created during automated testing. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8296154: [macos] Change /Applications to Applications in DMG image [v2] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11001/files - new: https://git.openjdk.org/jdk/pull/11001/files/df794aba..31690e08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11001&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11001&range=00-01 Stats: 16 lines in 2 files changed: 0 ins; 9 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11001.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11001/head:pull/11001 PR: https://git.openjdk.org/jdk/pull/11001 From almatvee at openjdk.org Sat Nov 5 01:08:12 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 5 Nov 2022 01:08:12 GMT Subject: RFR: 8296154: [macos] Change "/Applications" to "Applications" in DMG image [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 23:44:15 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8296154: [macos] Change /Applications to Applications in DMG image [v2] > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacBaseInstallerBundler.java line 121: > >> 119: // use "Applications" or "JavaVirtualMachines". For user provided installation >> 120: // directory we will use full path as display name. >> 121: static String getInstallDirDisplayName( > > Is this method ever called with `false` as the last parameter? If no, I'd remove it. No, it does not. I removed it. ------------- PR: https://git.openjdk.org/jdk/pull/11001 From alanb at openjdk.org Sat Nov 5 07:23:28 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 5 Nov 2022 07:23:28 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v2] In-Reply-To: <-tSCFbJ19Q6-EjHk17Jo8sgytX8xvSLldn0t-xjJz4U=.04d60dbd-3945-4994-953b-321d40c18b95@github.com> References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> <-tSCFbJ19Q6-EjHk17Jo8sgytX8xvSLldn0t-xjJz4U=.04d60dbd-3945-4994-953b-321d40c18b95@github.com> Message-ID: On Fri, 4 Nov 2022 22:24:57 GMT, Markus KARG wrote: >> This PR implements JDK-8296431 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed wrong bug number src/java.base/share/classes/java/io/PushbackInputStream.java line 416: > 414: Objects.requireNonNull(out, "out"); > 415: ensureOpen(); > 416: if (lock != null) { PushbackInputStream's read methods are not synchronised so it doesn't make sense to introduce this for transferTo. In other words, I think you leave "clockLock" as it was. ------------- PR: https://git.openjdk.org/jdk/pull/10999 From duke at openjdk.org Sat Nov 5 08:50:53 2022 From: duke at openjdk.org (Markus KARG) Date: Sat, 5 Nov 2022 08:50:53 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v3] In-Reply-To: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: > This PR implements JDK-8296431 Markus KARG has updated the pull request incrementally with two additional commits since the last revision: - Removing synchronization - Renamed lock back to closeLock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10999/files - new: https://git.openjdk.org/jdk/pull/10999/files/9d387eaa..f7ee1c7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=01-02 Stats: 21 lines in 1 file changed: 0 ins; 15 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10999.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10999/head:pull/10999 PR: https://git.openjdk.org/jdk/pull/10999 From duke at openjdk.org Sat Nov 5 08:50:54 2022 From: duke at openjdk.org (Markus KARG) Date: Sat, 5 Nov 2022 08:50:54 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v2] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> <-tSCFbJ19Q6-EjHk17Jo8sgytX8xvSLldn0t-xjJz4U=.04d60dbd-3945-4994-953b-321d40c18b95@github.com> Message-ID: On Sat, 5 Nov 2022 07:19:32 GMT, Alan Bateman wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed wrong bug number > > src/java.base/share/classes/java/io/PushbackInputStream.java line 416: > >> 414: Objects.requireNonNull(out, "out"); >> 415: ensureOpen(); >> 416: if (lock != null) { > > PushbackInputStream's read methods are not synchronised so it doesn't make sense to introduce this for transferTo. In other words, I think we should leave "closekLock" as it was. I have undone that change, so this PR only introduces the performance optimization now. ------------- PR: https://git.openjdk.org/jdk/pull/10999 From alanb at openjdk.org Sat Nov 5 09:56:33 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 5 Nov 2022 09:56:33 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam @asotona Would it be possible to provide a summary of what is being proposed here? The JEP for Classfile API (JDK-8280389) hasn't been submitted yet so it's not on the technical roadmap. If I read understand this PR correctly, the it looks like it will being the implementation into the java.base so it can be used in java.base in advance of the JEP, is that right? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From alanb at openjdk.org Sat Nov 5 17:15:30 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 5 Nov 2022 17:15:30 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v3] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: On Sat, 5 Nov 2022 08:50:53 GMT, Markus KARG wrote: >> This PR implements JDK-8296431 > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Removing synchronization > - Renamed lock back to closeLock src/java.base/share/classes/java/io/PushbackInputStream.java line 58: > 56: public class PushbackInputStream extends FilterInputStream { > 57: > 58: // initialized to null when BufferedInputStream is sub-classed Thanks for the update, I think the change to PBIS looks okay, it's just this comment, which looks like it was copied from BIS. ------------- PR: https://git.openjdk.org/jdk/pull/10999 From duke at openjdk.org Sat Nov 5 18:29:47 2022 From: duke at openjdk.org (Markus KARG) Date: Sat, 5 Nov 2022 18:29:47 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v4] In-Reply-To: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: > This PR implements JDK-8296431 Markus KARG has updated the pull request incrementally with one additional commit since the last revision: fixed typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10999/files - new: https://git.openjdk.org/jdk/pull/10999/files/f7ee1c7a..b6f4d8cb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10999.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10999/head:pull/10999 PR: https://git.openjdk.org/jdk/pull/10999 From duke at openjdk.org Sat Nov 5 18:29:48 2022 From: duke at openjdk.org (Markus KARG) Date: Sat, 5 Nov 2022 18:29:48 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v3] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: On Sat, 5 Nov 2022 17:13:14 GMT, Alan Bateman wrote: >> Markus KARG has updated the pull request incrementally with two additional commits since the last revision: >> >> - Removing synchronization >> - Renamed lock back to closeLock > > src/java.base/share/classes/java/io/PushbackInputStream.java line 58: > >> 56: public class PushbackInputStream extends FilterInputStream { >> 57: >> 58: // initialized to null when BufferedInputStream is sub-classed > > Thanks for the update, I think the change to PBIS looks okay, it's just this comment, which looks like it was copied from BIS. Fixed. Thanks, I have overlooked this one! ------------- PR: https://git.openjdk.org/jdk/pull/10999 From jvernee at openjdk.org Sat Nov 5 19:48:32 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Sat, 5 Nov 2022 19:48:32 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v2] In-Reply-To: References: Message-ID: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> On Fri, 4 Nov 2022 18:23:17 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: > > - Merge branch 'master' into PR_20 > - Merge branch 'master' into PR_20 > - Merge pull request #14 from minborg/small-javadoc > > Update some javadocs > - Update some javadocs > - Revert some javadoc changes > - Merge branch 'master' into PR_20 > - Fix benchmark and test failure > - Merge pull request #13 from minborg/revert-factories > > Revert MemorySegment factories > - Update javadocs after comments > - Revert MemorySegment factories > - ... and 7 more: https://git.openjdk.org/jdk/compare/e1e4e45b...3d933028 Some preliminary comments about some changes I think are missing from this PR (noticed while I was making a patch for the VM changes) I will do a more thorough review after the changes from https://github.com/openjdk/panama-foreign/pull/750 are included as well. src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 474: > 472: long bbAddress = NIO_ACCESS.getBufferAddress(bb); > 473: Object base = NIO_ACCESS.getBufferBase(bb); > 474: UnmapperProxy unmapper = NIO_ACCESS.unmapper(bb); Looks like here is also missing the fix that rejects StringCharBuffer: https://github.com/openjdk/panama-foreign/pull/741 I think that is good to include as well. src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 477: > 475: case UNBOX_ADDRESS -> emitUnboxAddress(); > 476: case DUP -> emitDupBinding(); > 477: case CAST -> emitCast((Binding.Cast) binding); This contains the CAST binding, but not the accompanying VM changes from: https://github.com/openjdk/panama-foreign/pull/720 which removes the now dead code. Preferably both changes go together (and the code removal is pretty trivial, so I suggest including it here) src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 491: > 489: emitLoad(highLevelType, paramIndex2ParamSlot[paramIndex]); > 490: > 491: if (shouldAcquire(paramIndex)) { I can't comment on the actual line below, but this is also missing the fix from: https://github.com/openjdk/panama-foreign/pull/739 (that is a Java-only change as well). I suggest adding that as well. src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java line 165: > 163: assert forArguments : "no stack returns"; > 164: // stack > 165: long alignment = Math.max(layout.byteAlignment(), STACK_SLOT_SIZE); This is also missing part of the changes from: https://github.com/openjdk/panama-foreign/pull/728/ but other changes to the shared code are present. The `layout` parameter is not needed here. (see the changes to this file in the original PR) ------------- PR: https://git.openjdk.org/jdk/pull/10872 From forax at openjdk.org Sat Nov 5 22:27:39 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 5 Nov 2022 22:27:39 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize FormatConcatItem src/java.base/share/classes/java/lang/template/StringTemplate.java line 276: > 274: * @implNote Contents of both lists are copied to construct immutable lists. > 275: */ > 276: public static StringTemplate of(List fragments, List values) { Should be `StringTemplate of(List fragments, List values) {` The call to List.copyOf() will change the List to List. src/java.base/share/classes/java/lang/template/StringTemplate.java line 299: > 297: * @throws NullPointerException fragments or values is null or if any of the fragments is null > 298: */ > 299: public static String interpolate(List fragments, List values) { Should be `String interpolate(List fragments, List values) {` as above src/java.base/share/classes/java/lang/template/StringTemplate.java line 305: > 303: int valuesSize = values.size(); > 304: if (fragmentsSize != valuesSize + 1) { > 305: throw new RuntimeException("fragments must have one more element than values"); Should be IllegalArgumentException (see method of() above) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Sat Nov 5 22:32:35 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 5 Nov 2022 22:32:35 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize FormatConcatItem src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 159: > 157: } > 158: } > 159: return new SimpleStringTemplate(TemplateRuntime.toList(fragments), TemplateRuntime.toList(values)); Should be `return new SimpleStringTemplate(List.copyOf(fragments), TemplateRuntime.toList(values));` because only a value can be null, a fragment should not be null ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Sat Nov 5 22:38:06 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 5 Nov 2022 22:38:06 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize FormatConcatItem src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 100: > 98: * // check or manipulate the fragments and/or values > 99: * ... > 100: * return StringTemplate.interpolate(fragments, values);; There is two semicolons instead of one at the end of this line src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 126: > 124: * } > 125: * The {@link StringTemplate#interpolate()} method is available for those processors > 126: * that just need to work with the interpolatation; type `interpolatation`-> `interpolation` ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Sat Nov 5 23:13:37 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Sat, 5 Nov 2022 23:13:37 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize FormatConcatItem src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 158: > 156: values[j++] = value; > 157: } > 158: } The sides effects `fragments[i++] += fragmentIter.next();` and `i--` are ugly and can easily be overlook. Also there is no need to use an iterator here, we know that the fragments have a List.get() in O(1). The idea is to concat the last fragment of a template with the first one of the next template, so i propose ... String[] fragments = new String[size + 1]; String last = ""; int i = 0, j = 0; for (StringTemplate st : sts) { List templateFragments = st.fragments(); fragments[i++] = last.concat(templateFragments.get(0)); // concat last fragment with first new fragment int k = 0; for(; k < templateFragments.size() - 1; k++) { fragments[i++] = templateFragments.get(k); } last = templateFragments.get(k); for (Object value : st.values()) { values[j++] = value; } } fragments[i] = last; ------------- PR: https://git.openjdk.org/jdk/pull/10889 From info at j-kuhn.de Sun Nov 6 00:17:19 2022 From: info at j-kuhn.de (Johannes Kuhn) Date: Sun, 6 Nov 2022 01:17:19 +0100 Subject: Unsigned long to double and back Message-ID: <15529cbc-c299-17c4-4bf8-2121b5f2e9bf@j-kuhn.de> When I tried to implement an WASM transpiler, I noticed some missing conversion methods from unsigned types to floating point, for example from unsigned long to a double. For the meaning of unsigned long, see Long.toUnsignedString(long i). Converting between unsigned long and floating point is not a trivial task, as it probably requires some bit manipulation. In particular, I would love to see the following methods added*: - double Double.fromUnsignedLong(long i) - long Double.toUnsignedLong(double d) - float Float.fromUnsignedLong(long i) - long Float.toUnsignedLong(float f) * Subject to bikeshedding - I don't care about the name, or if it is added to the Long class. Currently, I don't think that additional methods for unsigned int are necessary - as it is possible to cast between long and int, but feel free to correct me. In WASM, the specification for those methods can be found here: https://www.w3.org/TR/wasm-core-1/#op-trunc-u https://www.w3.org/TR/wasm-core-1/#op-convert-u Note that the WASM specification is undefined for some values, notably NaN, infinities, and values that fall out of the range. As *I* want to use it to implement WASM instructions, I do not have any strong opinion on the undefined cases - for example, returning the nearest unsigned long value or throwing an exception is fine for me. What do you think? - Johannes From Alan.Bateman at oracle.com Sun Nov 6 08:30:53 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 6 Nov 2022 08:30:53 +0000 Subject: Proposal: track zlib native memory usage with NMT In-Reply-To: References: Message-ID: On 04/11/2022 16:54, Thomas St?fe wrote: > Hi all, > > I am currently working on https://bugs.openjdk.org/browse/JDK-8296360; > I was preparing the final PR [1], but then Alan did ask me to discuss > this on core-libs first. > > Backstory: > > NMT tracks hotspot native allocations but does not cover the JDK > libraries (small exception: Unsafe.AllocateMemory). However, the > native memory footprint of JDK libraries can be significant. We have > no in-VM tracker for these and need tools like valgrind or our > SapMachine MallocTracer [2] to observe them. Thanks for starting a discussion on this as this is a topic that requires agreement from several areas. If this is the start of something bigger, where you want to have all allocation sites in the libraries using NMT, then I think it needs a write-up, maybe a JEP. For starters, I think it needs some agreement on using NMT for memory allocated outside of libjvm. You mentioned Unsafe as an exception but that is implemented in the VM so you get tracking for free, albeit I think all allocations are in the "mtOther" category. A general concern is that it creates more coupling between the VM code and the libraries code. As you probably know, we've removed most of the dependences on JVM_* functions from non-core areas over many years. So I think that needs consideration as I assume we don't want memory/allocation.hpp declaring a dozen catagories for allocations done in say java.desktop module for example. Maybe your proposal will be strictly limited to java.base but even then, do we really want the VM even knowing about categories that are specific to zip compression or decompression? There are probably longer term trends that should be part of the discussion too. One general trend is that "run time" is becoming more and more a hybrid of code in libvm and the Java libraries. Lambdas, module system, virtual threads implementations are a few examples in the last few release. This comes with many "Java on Java" challenges, including serviceability where users of the platform will expect tools to just work and won't care where the code is. NMT is probably more for support teams and not something that most developers will ever use but I think is part of the challenge of having serviceability solutions "just work". In addition to having more of the Java runtime written in Java, there will likely be less JNI code in the future. It's very possible that the JNI code (including the JNI methods in libzip) will be replaced with code that uses Panama memory and linker APIs once they are become permanent. The effect of that would to have a lot of the memory allocations be tracked in the mtOther category again. Maybe integration with memory tracking should be looked at in conjunction with these APIs and this migration. I could imagine the proposed "Arena" API (MemorySession in Java 19) having some integration with NMT and it might be interesting to look into that. So yes, this topic does need broader discussion and it might be a bit premature to start with a PR for libzip without talking about the bigger picture first. -Alan From duke at openjdk.org Sun Nov 6 11:37:32 2022 From: duke at openjdk.org (duke) Date: Sun, 6 Nov 2022 11:37:32 GMT Subject: Withdrawn: 8291916: Unexpected output on Windows command prompt In-Reply-To: References: Message-ID: On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi wrote: > To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module. > > - IBM860 > - IBM861 > - IBM863 > - IBM864 > - IBM865 > - IBM869 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9761 From duke at openjdk.org Sun Nov 6 13:34:20 2022 From: duke at openjdk.org (ExE Boss) Date: Sun, 6 Nov 2022 13:34:20 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize FormatConcatItem src/java.base/share/classes/java/util/FormatItem.java line 75: > 73: try { > 74: return (long)CHAR_MIX.invokeExact(lengthCoder, value); > 75: } catch (RuntimeException ex) { This?should also?rethrow `Error`?instances: Suggestion: } catch (Error | RuntimeException ex) { ------------- PR: https://git.openjdk.org/jdk/pull/10889 From aefimov at openjdk.org Sun Nov 6 16:48:18 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Sun, 6 Nov 2022 16:48:18 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly Message-ID: ### The Proposed Change The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. The list of proposed changes: - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. - Adjust query retries logic to the new implementation of timeouts. - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. ### Testing `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. JNDI regression and JCK tests also didn't highlight any problems with the changes. Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) After proposed changes - pinned threads are not detectable. ------------- Commit messages: - 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly Changes: https://git.openjdk.org/jdk/pull/11007/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11007&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290714 Stats: 691 lines in 4 files changed: 362 ins; 305 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/11007.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11007/head:pull/11007 PR: https://git.openjdk.org/jdk/pull/11007 From dholmes at openjdk.org Sun Nov 6 22:00:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 6 Nov 2022 22:00:07 GMT Subject: RFR: 8295673: Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 12:21:22 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/placeholders.cpp line 137: >> >>> 135: assert(action != PlaceholderTable::LOAD_INSTANCE || seen == NULL, >>> 136: "Only one LOAD_INSTANCE allowed at a time"); >>> 137: >> >> Unclear why this is removed? If disabling the new flag causes this fail then shouldn't the new flag form part of the condition? > > If you want, it seemed unnecessary clutter for the assert. And it's really only necessary for non null class loader data I'd like to understand how the assert connects to the changes. >> src/hotspot/share/classfile/systemDictionary.cpp line 597: >> >>> 595: double_lock_wait(current, lockObject); >>> 596: } else { >>> 597: return NULL; >> >> Not clear why we return NULL here rather than just falling through and retrying? > > If we don't return we'll actually do a wait and will hang. Worse, we'll be in a tight loop holding both the ClassLoader and SystemDictionary_lock, that the other thread can't get. Okay but isn't that what should be expected? This is a flag to prevent a certain kind of classloader from deadlocking, so if we have that kind of classloader and the flag is disabled, then we should expect deadlock. Otherwise what will the failure mode be here? If we are introducing a new failure mode then it needs to be documented in the CSR request and possibly a Release Note. ------------- PR: https://git.openjdk.org/jdk/pull/10832 From darcy at openjdk.org Sun Nov 6 22:18:20 2022 From: darcy at openjdk.org (Joe Darcy) Date: Sun, 6 Nov 2022 22:18:20 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize FormatConcatItem src/java.base/share/classes/java/util/FormatProcessor.java line 38: > 36: > 37: /** > 38: * This {@linkplain ValidatingProcessor yemplate processor} constructs a String Typo: "yemplate processor". src/java.base/share/classes/java/util/FormatProcessor.java line 56: > 54: * to produce a more performant formatter. > 55: * > 56: * @implSpec Since, values are in situ, argument indexing is unsupported. Please avoid Latin phrases like "in situ" in the javadoc. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From coleenp at openjdk.org Sun Nov 6 22:38:29 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sun, 6 Nov 2022 22:38:29 GMT Subject: RFR: 8295673: Deprecate legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 21:54:46 GMT, David Holmes wrote: >> If you want, it seemed unnecessary clutter for the assert. And it's really only necessary for non null class loader data > > I'd like to understand how the assert connects to the changes. Multiple threads can now create the LOAD_INSTANCE placeholder for the same class in the case of non-parallel capable class loader, so this assert is no longer valid for this case. ------------- PR: https://git.openjdk.org/jdk/pull/10832 From dholmes at openjdk.org Sun Nov 6 22:54:21 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 6 Nov 2022 22:54:21 GMT Subject: RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 21:57:36 GMT, David Holmes wrote: >> If we don't return we'll actually do a wait and will hang. Worse, we'll be in a tight loop holding both the ClassLoader and SystemDictionary_lock, that the other thread can't get. > > Okay but isn't that what should be expected? This is a flag to prevent a certain kind of classloader from deadlocking, so if we have that kind of classloader and the flag is disabled, then we should expect deadlock. Otherwise what will the failure mode be here? If we are introducing a new failure mode then it needs to be documented in the CSR request and possibly a Release Note. Coleen has reminded me that I am confused about what the workaround was doing - this code doesn't prevent deadlock, it prevents a LinkageError that would otherwise occur because the classloader has done something tricky (released the monitor) to prevent deadlock. So the correct behaviour here is proceed with the class loading and trigger the LinkageError in the other thread. ------------- PR: https://git.openjdk.org/jdk/pull/10832 From coleenp at openjdk.org Sun Nov 6 23:09:54 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sun, 6 Nov 2022 23:09:54 GMT Subject: RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: References: Message-ID: > This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. > Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() > > Tested with tier1-6 and internal applications. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Remove assert no longer valid. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10832/files - new: https://git.openjdk.org/jdk/pull/10832/files/3f5be0ac..59c07651 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10832&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10832&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10832.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10832/head:pull/10832 PR: https://git.openjdk.org/jdk/pull/10832 From coleenp at openjdk.org Sun Nov 6 23:09:54 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sun, 6 Nov 2022 23:09:54 GMT Subject: RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 22:50:26 GMT, David Holmes wrote: >> Okay but isn't that what should be expected? This is a flag to prevent a certain kind of classloader from deadlocking, so if we have that kind of classloader and the flag is disabled, then we should expect deadlock. Otherwise what will the failure mode be here? If we are introducing a new failure mode then it needs to be documented in the CSR request and possibly a Release Note. > > Coleen has reminded me that I am confused about what the workaround was doing - this code doesn't prevent deadlock, it prevents a LinkageError that would otherwise occur because the classloader has done something tricky (released the monitor) to prevent deadlock. So the correct behaviour here is proceed with the class loading and trigger the LinkageError in the other thread. No, the expectation without this code is a LinkageError: dupicate class definition. I just started the release-note subtask to describe this. The expected behavior is that we don't wait, we just let the application load the class even though they've broken the lock. ------------- PR: https://git.openjdk.org/jdk/pull/10832 From coleenp at openjdk.org Sun Nov 6 23:33:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sun, 6 Nov 2022 23:33:33 GMT Subject: RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 23:03:19 GMT, Coleen Phillimore wrote: >> Coleen has reminded me that I am confused about what the workaround was doing - this code doesn't prevent deadlock, it prevents a LinkageError that would otherwise occur because the classloader has done something tricky (released the monitor) to prevent deadlock. So the correct behaviour here is proceed with the class loading and trigger the LinkageError in the other thread. > > No, the expectation without this code is a LinkageError: dupicate class definition. I just started the release-note subtask to describe this. The expected behavior is that we don't wait, we just let the application load the class even though they've broken the lock. See release note in progress: https://bugs.openjdk.org/browse/JDK-8296446 ------------- PR: https://git.openjdk.org/jdk/pull/10832 From dholmes at openjdk.org Mon Nov 7 00:43:12 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 7 Nov 2022 00:43:12 GMT Subject: RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders [v2] In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 23:09:54 GMT, Coleen Phillimore wrote: >> This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. >> Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() >> >> Tested with tier1-6 and internal applications. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Remove assert no longer valid. Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10832 From jpai at openjdk.org Mon Nov 7 06:53:22 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Nov 2022 06:53:22 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote: > ### The Proposed Change > > The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). > The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. > The list of proposed changes: > - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. > - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. > - Adjust query retries logic to the new implementation of timeouts. > - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. > > > ### Testing > `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. > JNDI regression and JCK tests also didn't highlight any problems with the changes. > > Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: > ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) > java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) > java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) > java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 > java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) > jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 > jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) > jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) > jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) > java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) > java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) > > After proposed changes - pinned threads are not detectable. test/jdk/com/sun/jndi/dns/ConfigTests/Timeout.java line 70: > 68: // Create a DatagramSocket and bind it to the loopback address to simulate > 69: // UDP DNS server that doesn't respond > 70: DatagramSocket ds = new DatagramSocket( Hello Aleksei, perhaps close this socket in a finally block in this test? ------------- PR: https://git.openjdk.org/jdk/pull/11007 From jpai at openjdk.org Mon Nov 7 07:15:11 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Nov 2022 07:15:11 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote: > ### The Proposed Change > > The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). > The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. > The list of proposed changes: > - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. > - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. > - Adjust query retries logic to the new implementation of timeouts. > - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. > > > ### Testing > `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. > JNDI regression and JCK tests also didn't highlight any problems with the changes. > > Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: > ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) > java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) > java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) > java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 > java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) > jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 > jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) > jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) > jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) > java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) > java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) > > After proposed changes - pinned threads are not detectable. src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 185: > 183: public void close() { > 184: try { > 185: udpChannelSelector.close(); Do you think we should now maintain a `closed` boolean flag in this class to keep track of whether this underlying selector has been closed? The javadoc of `Selector.close()` states that any subsequent use of the selector will throw a `ClosedSelectorException`. A `ClosedSelectorException` is a `RuntimeException`, so if a closed `DnsClient` gets used (for example a `query()` gets triggered) then from what I can see it will end up propagating this `ClosedSelectorException` out of these class methods instead of the declared compile time exceptions. Maintaining a `closed` flag could allow us to use that flag to check in these methods (where we use the selector) and throw a more appropriate exception. ------------- PR: https://git.openjdk.org/jdk/pull/11007 From jpai at openjdk.org Mon Nov 7 07:25:30 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 7 Nov 2022 07:25:30 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote: > ### The Proposed Change > > The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). > The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. > The list of proposed changes: > - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. > - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. > - Adjust query retries logic to the new implementation of timeouts. > - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. > > > ### Testing > `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. > JNDI regression and JCK tests also didn't highlight any problems with the changes. > > Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: > ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) > java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) > java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) > java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 > java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) > jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 > jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) > jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) > jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) > java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) > java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) > > After proposed changes - pinned threads are not detectable. src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 470: > 468: } while (timeoutLeft > MIN_TIMEOUT); > 469: // no matching packet received within the timeout > 470: throw new SocketTimeoutException(); It appears to me that, before the change in this PR, we used to return `null` from this method if there is a timeout. The calling code (the method `query`) would then interpret this `null` return in a couple of different ways. One of them being, skipping this server and querying any other server(s) that were known to the client instance. Now, with this change where we throw this `SocketTimeoutException`, that part of the code would behave differently from what I can see. Is this intentional to throw an exception instead of returning `null`? ------------- PR: https://git.openjdk.org/jdk/pull/11007 From alanb at openjdk.org Mon Nov 7 08:25:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Nov 2022 08:25:21 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote: > ### The Proposed Change > > The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). > The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. > The list of proposed changes: > - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. > - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. > - Adjust query retries logic to the new implementation of timeouts. > - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. > > > ### Testing > `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. > JNDI regression and JCK tests also didn't highlight any problems with the changes. > > Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: > ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) > java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) > java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) > java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 > java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) > jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 > jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) > jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) > jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) > java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) > java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) > > After proposed changes - pinned threads are not detectable. src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 441: > 439: udpChannel.connect(target); > 440: int pktTimeout = (timeout * (1 << retry)); > 441: udpChannel.send(opkt, target); FYI: When a DatagramChannel is connected then you can use `write` to send the datagram, you don't need to specify the target address again when sending. ------------- PR: https://git.openjdk.org/jdk/pull/11007 From mcimadamore at openjdk.org Mon Nov 7 09:24:04 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 09:24:04 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v2] In-Reply-To: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> References: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> Message-ID: On Sat, 5 Nov 2022 18:02:33 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - Merge branch 'master' into PR_20 >> - Merge branch 'master' into PR_20 >> - Merge pull request #14 from minborg/small-javadoc >> >> Update some javadocs >> - Update some javadocs >> - Revert some javadoc changes >> - Merge branch 'master' into PR_20 >> - Fix benchmark and test failure >> - Merge pull request #13 from minborg/revert-factories >> >> Revert MemorySegment factories >> - Update javadocs after comments >> - Revert MemorySegment factories >> - ... and 7 more: https://git.openjdk.org/jdk/compare/d314527d...3d933028 > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 477: > >> 475: case UNBOX_ADDRESS -> emitUnboxAddress(); >> 476: case DUP -> emitDupBinding(); >> 477: case CAST -> emitCast((Binding.Cast) binding); > > This contains the CAST binding, but not the accompanying VM changes from: https://github.com/openjdk/panama-foreign/pull/720 which removes the now dead code. Preferably both changes go together (and the code removal is pretty trivial, so I suggest including it here) Why did the normalization test passed even w/o VM changes? Is that because the VM code changes are just removing what is now dead code, right? ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Nov 7 09:30:19 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 09:30:19 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v2] In-Reply-To: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> References: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> Message-ID: On Sat, 5 Nov 2022 18:04:38 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - Merge branch 'master' into PR_20 >> - Merge branch 'master' into PR_20 >> - Merge pull request #14 from minborg/small-javadoc >> >> Update some javadocs >> - Update some javadocs >> - Revert some javadoc changes >> - Merge branch 'master' into PR_20 >> - Fix benchmark and test failure >> - Merge pull request #13 from minborg/revert-factories >> >> Revert MemorySegment factories >> - Update javadocs after comments >> - Revert MemorySegment factories >> - ... and 7 more: https://git.openjdk.org/jdk/compare/1fd35b8a...3d933028 > > src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 491: > >> 489: emitLoad(highLevelType, paramIndex2ParamSlot[paramIndex]); >> 490: >> 491: if (shouldAcquire(paramIndex)) { > > I can't comment on the actual line below, but this is also missing the fix from: https://github.com/openjdk/panama-foreign/pull/739 (that is a Java-only change as well). I suggest adding that as well. Few changes were missing - but the `dontrelease` tests was passing... odd ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Nov 7 09:42:25 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 09:42:25 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v2] In-Reply-To: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> References: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> Message-ID: <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com> On Sat, 5 Nov 2022 18:40:56 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision: >> >> - Merge branch 'master' into PR_20 >> - Merge branch 'master' into PR_20 >> - Merge pull request #14 from minborg/small-javadoc >> >> Update some javadocs >> - Update some javadocs >> - Revert some javadoc changes >> - Merge branch 'master' into PR_20 >> - Fix benchmark and test failure >> - Merge pull request #13 from minborg/revert-factories >> >> Revert MemorySegment factories >> - Update javadocs after comments >> - Revert MemorySegment factories >> - ... and 7 more: https://git.openjdk.org/jdk/compare/d8bb7119...3d933028 > > src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java line 165: > >> 163: assert forArguments : "no stack returns"; >> 164: // stack >> 165: long alignment = Math.max(layout.byteAlignment(), STACK_SLOT_SIZE); > > This is also missing part of the changes from: https://github.com/openjdk/panama-foreign/pull/728/ but other changes to the shared code are present. The `layout` parameter is not needed here. (see the changes to this file in the original PR) Actually, this patch is missing most of the stuff in PR 728. I was under the impression that, in order to fully support that, some VM changes were needed (e.g. to have better granularity in call shuffling - as per https://github.com/openjdk/panama-foreign/pull/699). As a result, this PR only contains changes to SharedUtil (to remove unused alignment functions) - but nothing else. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Nov 7 09:47:34 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 09:47:34 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Fix mismmatched acquire/release in BindingSpecializer - Fix MemorySegment.ofBuffer when applied to StringCharBuffer - Remove VM dead code after implementation of Binding.Cast ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/3d933028..e8b95f83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=01-02 Stats: 51 lines in 6 files changed: 12 ins; 34 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From asotona at openjdk.org Mon Nov 7 10:16:34 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Nov 2022 10:16:34 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam This pull request (plus a set of planned "chained" pull requests) is an attempt to resolve chicken and egg situation in the Classfile API development. According to the JEP summary will Classfile API initially serve as an internal replacement for ASM in the JDK, to be later opened as a public API. The JEP has been returned to draft due to permanent feeling of incompleteness of the Classfile API and for lack of real cases and real impact on the JDK. On the other side it is vital for Classfile API to grow on real cases and very specific applications across the whole JDK. The places of impact are tracked under [JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957) **Consolidate JDK class files parsing, generating, and transforming (umbrella)**, where 11 of the 18 umbrella sub-tasks (representing individual JDK integrations) have been experimentally implemented and 10 of them are tracked and manually re-based and synchronised in the jdk-sandbox repository branch. It is a complex chicken and egg task to develop library designed to replace ASM (currently sitting in java.base), and at the same time to develop and test its integrations spread across the whole JDK (from java.base lambdas and method handlers generation to the last tier test). And at the same time to prove it is complete enough to have a right to sit in the java.base. Classfile API is not classified as a standalone JDK project, as all the applications across JDK can be integrated independently. However it is critical for the Classfile API to evolve close to the JDK mainline, so it can became an integral part of other JDK projects (for example project Valhalla). In this situation raised an idea to use GitHub pull requests chaining as a technical solution. The idea is that many of the future applications of the Classfile API (the "chickens") can be individually reviewed, discussed and synchronised on top of this pull request (the "egg"), without immediate integration. BTW: Originally I though it will be enough to keep this pull request as draft, however technical limitations did not allow me to chain another pull request to a draft pull request. Any suggestions or proposals are welcome. Thanks, Adam ------------- PR: https://git.openjdk.org/jdk/pull/10982 From ihse at openjdk.org Mon Nov 7 11:59:31 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 7 Nov 2022 11:59:31 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam So this should be considered as a "draft" PR, even if you cannot specify it as a draft for technical reasons? May I suggest that you prefix the title by `[DRAFT]`? That will serve the dual purpose of signalling to reviewers that this is indeed a draft, and it will also make the Skara tooling disallow integration (since the title rules are not being followed). ------------- PR: https://git.openjdk.org/jdk/pull/10982 From coleenp at openjdk.org Mon Nov 7 12:14:39 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 12:14:39 GMT Subject: RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders [v3] In-Reply-To: References: Message-ID: > This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. > Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() > > Tested with tier1-6 and internal applications. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix logic in assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10832/files - new: https://git.openjdk.org/jdk/pull/10832/files/59c07651..2d70c34f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10832&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10832&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10832.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10832/head:pull/10832 PR: https://git.openjdk.org/jdk/pull/10832 From ihse at openjdk.org Mon Nov 7 12:19:11 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 7 Nov 2022 12:19:11 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam make/CompileInterimLangtools.gmk line 78: > 76: $(call LogInfo, Generating Preview.java for jdk.compiler.interim) > 77: $(call MakeDir, $(@D)) > 78: $(GREP) -v 'case PATTERN_SWITCH ->' $< > $@ I understand that you have based this on the example above. There is a huge difference, though. The sed expression just updates the package name to include the new `interim` part. These new additions seems to be designed to filter out actual code. Since no reason for this is given in comments, I'm assuming there is some code that either does not compile when building this for the interim JDK, or that gives the incorrect result if included. But that means that now suddenly the makefiles has intricate knowledge about specific lines of code in the source code! That is not a good entanglement to have. make/CompileInterimLangtools.gmk line 84: > 82: $(call LogInfo, Generating TransPatterns.java for jdk.compiler.interim) > 83: $(call MakeDir, $(@D)) > 84: $(GREP) -v 'Assert.check(preview.' $< > $@ (The same goes for this instance, of course) make/modules/java.base/Java.gmk line 37: > 35: > 36: EXCLUDES += java/lang/doc-files > 37: EXCLUDES += jdk/classfile/snippets I don't like hard-coded excludes like this. Is this the first real-world example of snippets in the JDK? If not, how has this been resolved in other instances? Maybe we need a more general method to exclude snippets from compiling. make/test/BuildMicrobenchmark.gmk line 106: > 104: --add-exports java.base/jdk.classfile.components=ALL-UNNAMED \ > 105: --add-exports java.base/jdk.classfile.impl=ALL-UNNAMED \ > 106: --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED \ Why do you need to export ASM now, when it was not needed before? I thought the purpose here was to replace ASM..? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From ihse at openjdk.org Mon Nov 7 12:19:12 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 7 Nov 2022 12:19:12 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com> On Mon, 7 Nov 2022 12:10:56 GMT, Magnus Ihse Bursie wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > make/CompileInterimLangtools.gmk line 78: > >> 76: $(call LogInfo, Generating Preview.java for jdk.compiler.interim) >> 77: $(call MakeDir, $(@D)) >> 78: $(GREP) -v 'case PATTERN_SWITCH ->' $< > $@ > > I understand that you have based this on the example above. There is a huge difference, though. The sed expression just updates the package name to include the new `interim` part. These new additions seems to be designed to filter out actual code. > > Since no reason for this is given in comments, I'm assuming there is some code that either does not compile when building this for the interim JDK, or that gives the incorrect result if included. But that means that now suddenly the makefiles has intricate knowledge about specific lines of code in the source code! That is not a good entanglement to have. To be more specific: is there some way the code in Preview.java and TransPatterns.java can be modified so this transmogrification is not needed? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mcimadamore at openjdk.org Mon Nov 7 12:29:37 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 12:29:37 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add missing tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/e8b95f83..0c70da2c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=02-03 Stats: 162 lines in 3 files changed: 162 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From asotona at openjdk.org Mon Nov 7 12:48:01 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Nov 2022 12:48:01 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 12:38:04 GMT, Adam Sotona wrote: > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam I apologise for inconveniences, this chain of PRs to introduce Classfile API is probably too premature. It seems to be possible to turn it into draft now. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Nov 7 12:48:03 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Nov 2022 12:48:03 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 12:16:29 GMT, Magnus Ihse Bursie wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > make/test/BuildMicrobenchmark.gmk line 106: > >> 104: --add-exports java.base/jdk.classfile.components=ALL-UNNAMED \ >> 105: --add-exports java.base/jdk.classfile.impl=ALL-UNNAMED \ >> 106: --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED \ > > Why do you need to export ASM now, when it was not needed before? I thought the purpose here was to replace ASM..? There are new benchmarks added, comparing performance of Classfile API with ASM. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Nov 7 12:56:30 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Nov 2022 12:56:30 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com> References: <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com> Message-ID: <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com> On Mon, 7 Nov 2022 12:15:35 GMT, Magnus Ihse Bursie wrote: >> make/CompileInterimLangtools.gmk line 78: >> >>> 76: $(call LogInfo, Generating Preview.java for jdk.compiler.interim) >>> 77: $(call MakeDir, $(@D)) >>> 78: $(GREP) -v 'case PATTERN_SWITCH ->' $< > $@ >> >> I understand that you have based this on the example above. There is a huge difference, though. The sed expression just updates the package name to include the new `interim` part. These new additions seems to be designed to filter out actual code. >> >> Since no reason for this is given in comments, I'm assuming there is some code that either does not compile when building this for the interim JDK, or that gives the incorrect result if included. But that means that now suddenly the makefiles has intricate knowledge about specific lines of code in the source code! That is not a good entanglement to have. > > To be more specific: is there some way the code in Preview.java and TransPatterns.java can be modified so this transmogrification is not needed? Patched interim Preview and TransPatterns is a temporary workaround to allow internal use of pattern switch in the JDK sources. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From ihse at openjdk.org Mon Nov 7 12:56:30 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 7 Nov 2022 12:56:30 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 12:45:00 GMT, Adam Sotona wrote: >> make/test/BuildMicrobenchmark.gmk line 106: >> >>> 104: --add-exports java.base/jdk.classfile.components=ALL-UNNAMED \ >>> 105: --add-exports java.base/jdk.classfile.impl=ALL-UNNAMED \ >>> 106: --add-exports java.base/jdk.internal.org.objectweb.asm=ALL-UNNAMED \ >> >> Why do you need to export ASM now, when it was not needed before? I thought the purpose here was to replace ASM..? > > There are new benchmarks added, comparing performance of Classfile API with ASM. I see. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Nov 7 13:05:30 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Nov 2022 13:05:30 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 12:13:08 GMT, Magnus Ihse Bursie wrote: >> This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. >> >> Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. >> >> Classfile API development is tracked at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch >> >> Development branch of consolidated JDK class files parsing, generating, and transforming is at: >> https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch >> >> Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. >> >> Please take you time to review this non-trivial JDK addition. >> >> Thank you, >> Adam > > make/modules/java.base/Java.gmk line 37: > >> 35: >> 36: EXCLUDES += java/lang/doc-files >> 37: EXCLUDES += jdk/classfile/snippets > > I don't like hard-coded excludes like this. Is this the first real-world example of snippets in the JDK? If not, how has this been resolved in other instances? Maybe we need a more general method to exclude snippets from compiling. I'll fix it, thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From jvernee at openjdk.org Mon Nov 7 13:45:33 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 7 Nov 2022 13:45:33 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v2] In-Reply-To: <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com> References: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com> Message-ID: On Mon, 7 Nov 2022 09:40:03 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/foreign/abi/x64/windows/CallArranger.java line 165: >> >>> 163: assert forArguments : "no stack returns"; >>> 164: // stack >>> 165: long alignment = Math.max(layout.byteAlignment(), STACK_SLOT_SIZE); >> >> This is also missing part of the changes from: https://github.com/openjdk/panama-foreign/pull/728/ but other changes to the shared code are present. The `layout` parameter is not needed here. (see the changes to this file in the original PR) > > Actually, this patch is missing most of the stuff in PR 728. I was under the impression that, in order to fully support that, some VM changes were needed (e.g. to have better granularity in call shuffling - as per https://github.com/openjdk/panama-foreign/pull/699). As a result, this PR only contains changes to SharedUtil (to remove unused alignment functions) - but nothing else. 699 is not needed for this. 728 is a pure Java change that simply rejects layouts that don't have their natural alignment (so, it will rejects packed structs for instance, since the implementation doesn't support them on all platforms). All the other changes from 728 are here (most notably the code in AbstractLinker that checks the alignment), except the change that ignores the `layout` here and turns the code around the line above into an `assert`. The mac stack spilling patch requires 699 though (https://github.com/openjdk/panama-foreign/pull/746). I will put that in the PR with the VM changes. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From redestad at openjdk.org Mon Nov 7 13:58:14 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 7 Nov 2022 13:58:14 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v5] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: - Merge branch 'master' into 8282664-polyhash - Merge branch 'master' into 8282664-polyhash - Change scalar unroll to 2 element stride, minding dependency chain - Require UseSSE >= 3 due transitive use of sse3 instructions from ReduceI - Reorder loops and some other suggestions from @merykitty - ws - Add ArraysHashCode microbenchmarks - Fixed vector loops for int and char arrays - Split up Arrays/HashCode tests - Fixes, optimized short inputs, temporarily disabled vector loop for Arrays.hashCode cases, added and improved tests - ... and 33 more: https://git.openjdk.org/jdk/compare/d634ddef...95c10b5f ------------- Changes: https://git.openjdk.org/jdk/pull/10847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=04 Stats: 1151 lines in 32 files changed: 1093 ins; 32 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From mcimadamore at openjdk.org Mon Nov 7 14:06:39 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 14:06:39 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v2] In-Reply-To: References: <5pJEOFSd5uXPZ5W8_SC3dPizt8x83yjMPbtt2gmFwfA=.38b93d3f-13f3-4455-ac0a-33dbca8f44bd@github.com> <09WcJa8UMXNVYkW_eI7w-tW7fnZ6KXt1gt_4cu5Y2KE=.8be58947-1169-42e0-8c6f-45b66ff63c10@github.com> Message-ID: On Mon, 7 Nov 2022 13:43:17 GMT, Jorn Vernee wrote: >> Actually, this patch is missing most of the stuff in PR 728. I was under the impression that, in order to fully support that, some VM changes were needed (e.g. to have better granularity in call shuffling - as per https://github.com/openjdk/panama-foreign/pull/699). As a result, this PR only contains changes to SharedUtil (to remove unused alignment functions) - but nothing else. > > 699 is not needed for this. 728 is a pure Java change that simply rejects layouts that don't have their natural alignment (so, it will rejects packed structs for instance, since the implementation doesn't support them on all platforms). All the other changes from 728 are here (most notably the code in AbstractLinker that checks the alignment), except the change that ignores the `layout` here and turns the code around the line above into an `assert`. > > The mac stack spilling patch requires 699 though (https://github.com/openjdk/panama-foreign/pull/746). I will put that in the PR with the VM changes. Thanks for the clarification - I will incorporate those changes as well then. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Nov 7 14:17:40 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 14:17:40 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v5] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Bring windows CallArranger in sync with panama repo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/0c70da2c..b98febff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=03-04 Stats: 18 lines in 2 files changed: 0 ins; 1 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From redestad at openjdk.org Mon Nov 7 14:23:44 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 7 Nov 2022 14:23:44 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v6] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Remove UseSSE >= 3 precondition now that UseAVX > 0 implies UseSSE=4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/95c10b5f..cdf276de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Mon Nov 7 14:25:21 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 7 Nov 2022 14:25:21 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: <9a0_6b99boFwuVxfQcswe4tQ3UYd7U1Yvv4EzePgH3o=.e8dcffc0-6bd5-4c56-909c-a21acda9a3de@github.com> On Tue, 25 Oct 2022 16:03:28 GMT, Ludovic Henry wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > I did a quick write up explaining the approach at https://gist.github.com/luhenry/2fc408be6f906ef79aaf4115525b9d0c. Also, you can find details in @richardstartin's [blog post](https://richardstartin.github.io/posts/vectorised-polynomial-hash-codes) I've started working on an aarch64 port while @luhenry is working on a forward-iterating variant of his vector algorithm (based on @merykitty's suggestions). However, I'd request this PR be accepted as-is and do ports and such enhancements as follow-ups. That'd simplify work since we can continue work in parallel with less coordination and merges. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From duke at openjdk.org Mon Nov 7 14:26:31 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 7 Nov 2022 14:26:31 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v4] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: <3soUDY9rkr9Rp1lQpO2LSMyQIZRTiZG9Cjhhj9gk6P0=.1bcff6e6-f2aa-4ca5-af01-c9a087194821@github.com> On Sat, 5 Nov 2022 18:29:47 GMT, Markus KARG wrote: >> This PR implements JDK-8296431 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo @AlanBateman I fixed what you asked for. Kindly requesting review. :-) ------------- PR: https://git.openjdk.org/jdk/pull/10999 From mcimadamore at openjdk.org Mon Nov 7 15:00:02 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 15:00:02 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: References: Message-ID: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Make memory session a pure lifetime abstraction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/b98febff..f04be0da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=04-05 Stats: 2492 lines in 139 files changed: 600 ins; 771 del; 1121 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Nov 7 15:01:39 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 7 Nov 2022 15:01:39 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v5] In-Reply-To: References: Message-ID: <7ZPsmtKqqOeItVnPztGyLhwuHi5Q9WsGI8SYzGkyL8Q=.33d63f63-9cbb-42bd-8d81-6555ed3d67d2@github.com> On Mon, 7 Nov 2022 14:17:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Bring windows CallArranger in sync with panama repo I have incorporated additional API changes, described in this document: http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html The main change is that `MemorySession` is now a pure lifetime abstraction and no longer implements `AutoCloseable`/`SegementAllocator`. Instead a new abstraction, called `Arena` should be used for deterministic deallocation use cases. This change allows several simplifications on the `MemorySession` API, as there's no more need to support non-closeable views. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From aefimov at openjdk.org Mon Nov 7 15:44:57 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Mon, 7 Nov 2022 15:44:57 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 07:13:04 GMT, Jaikiran Pai wrote: >> ### The Proposed Change >> >> The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). >> The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. >> The list of proposed changes: >> - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. >> - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. >> - Adjust query retries logic to the new implementation of timeouts. >> - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. >> >> >> ### Testing >> `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. >> JNDI regression and JCK tests also didn't highlight any problems with the changes. >> >> Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: >> ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) >> java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) >> java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) >> java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 >> java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) >> jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) >> jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) >> java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) >> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) >> >> After proposed changes - pinned threads are not detectable. > > src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 185: > >> 183: public void close() { >> 184: try { >> 185: udpChannelSelector.close(); > > Do you think we should now maintain a `closed` boolean flag in this class to keep track of whether this underlying selector has been closed? > > The javadoc of `Selector.close()` states that any subsequent use of the selector will throw a `ClosedSelectorException`. A `ClosedSelectorException` is a `RuntimeException`, so if a closed `DnsClient` gets used (for example a `query()` gets triggered) then from what I can see it will end up propagating this `ClosedSelectorException` out of these class methods instead of the declared compile time exceptions. > > Maintaining a `closed` flag could allow us to use that flag to check in these methods (where we use the selector) and throw a more appropriate exception. Good point - planning to address the closed selector in the `blockingReceive` method by calling `udpChannelSelector.isOpen()`. > src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 470: > >> 468: } while (timeoutLeft > MIN_TIMEOUT); >> 469: // no matching packet received within the timeout >> 470: throw new SocketTimeoutException(); > > It appears to me that, before the change in this PR, we used to return `null` from this method if there is a timeout. The calling code (the method `query`) would then interpret this `null` return in a couple of different ways. One of them being, skipping this server and querying any other server(s) that were known to the client instance. Now, with this change where we throw this `SocketTimeoutException`, that part of the code would behave differently from what I can see. Is this intentional to throw an exception instead of returning `null`? Thanks for spotting that, Jai. You're correct that in its current version the fix changed an old logic of `doUdpQuery`/`query` methods: Before this change the method was returning `null` not when a receive is timed out but when an unmatched packet is received. Socket timeout exceptions thrown by `DatagramSocket.receive` were caught in `query` method. After the proposed change the `doUdpQuery` method is throwing `SocketTimeoutException` for both cases (timeout and unmatched packets) - that needs to be changed to comply with old logic. Will address it in an upcoming changeset. ------------- PR: https://git.openjdk.org/jdk/pull/11007 From redestad at openjdk.org Mon Nov 7 15:53:26 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 7 Nov 2022 15:53:26 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v7] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with four additional commits since the last revision: - Merge pull request #1 from luhenry/dev/cl4es/8282664-polyhash Switch to forward approach for vectorization - Fix vector loop - fix indexing - Switch to forward approach for vectorization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/cdf276de..6f49b5aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=05-06 Stats: 241 lines in 4 files changed: 64 ins; 138 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Mon Nov 7 16:08:31 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 7 Nov 2022 16:08:31 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 16:03:28 GMT, Ludovic Henry wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > I did a quick write up explaining the approach at https://gist.github.com/luhenry/2fc408be6f906ef79aaf4115525b9d0c. Also, you can find details in @richardstartin's [blog post](https://richardstartin.github.io/posts/vectorised-polynomial-hash-codes) Scratch that. I've merged in the forward-iterating vector loop changes @luhenry has worked on, which give a 1.33x speed-up and simplifies the vector loop a lot. Also moves the coefficient array to shared memory. Benchmark (size) Mode Cnt Score Error Units StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1195.828 ? 10.956 ns/op StringHashCode.Algorithm.defaultUTF16 10000 avgt 5 1197.123 ? 10.007 ns/op Some micro-optimizations for smaller arrays were disabled for this, but we'll work on getting that back in place before calling it a day. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From ihse at openjdk.org Mon Nov 7 16:25:39 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 7 Nov 2022 16:25:39 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com> References: <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com> <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com> Message-ID: <5OGC5Uv2U2YuWEueIlag1J1-sIisWbuwQnJdEGwFrRE=.098668c9-1e3a-4e79-9a3a-30d55fe7e440@github.com> On Mon, 7 Nov 2022 12:52:38 GMT, Adam Sotona wrote: >> To be more specific: is there some way the code in Preview.java and TransPatterns.java can be modified so this transmogrification is not needed? > > Patched interim Preview and TransPatterns is a temporary workaround to allow internal use of pattern switch in the JDK sources. So this will be removed later on in one of the follow up "chicken" PRs? ------------- PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Nov 7 16:30:32 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 7 Nov 2022 16:30:32 GMT Subject: RFR: 8294982: Implementation of Classfile API In-Reply-To: <5OGC5Uv2U2YuWEueIlag1J1-sIisWbuwQnJdEGwFrRE=.098668c9-1e3a-4e79-9a3a-30d55fe7e440@github.com> References: <8KVAMrO7qchZ5Cyzq-QbL4bRfKklcSjXVBzsJP-l1x0=.83786c3d-be15-4376-9cff-f2e6f0df9917@github.com> <1D0PTNGSVOGfVS0JBTUNc05udOIxs0UToG_8_Ubb4EU=.f3d5b9af-a5b3-47af-96e0-42df82444edc@github.com> <5OGC5Uv2U2YuWEueIlag1J1-sIisWbuwQnJdEGwFrRE=.098668c9-1e3a-4e79-9a3a-30d55fe7e440@github.com> Message-ID: On Mon, 7 Nov 2022 16:21:48 GMT, Magnus Ihse Bursie wrote: >> Patched interim Preview and TransPatterns is a temporary workaround to allow internal use of pattern switch in the JDK sources. > > So this will be removed later on in one of the follow up "chicken" PRs? It will be removed in this PR later, this specific workaround is not intended to fall into JDK. The CompileInterimLangtools patch represents a way how to make the whole Classfile API and following "chickens" compilable in the current JDK. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From coleenp at openjdk.org Mon Nov 7 17:14:09 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 17:14:09 GMT Subject: RFR: 8296472: Remove a JVMTI ObjectLocker Message-ID: This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. Tested with tier1-4, and jvmti and jdi tests locally. ------------- Commit messages: - 8296472: Remove a JVMTI ObjectLocker Changes: https://git.openjdk.org/jdk/pull/11023/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11023&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296472 Stats: 6 lines in 2 files changed: 1 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11023.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11023/head:pull/11023 PR: https://git.openjdk.org/jdk/pull/11023 From bpb at openjdk.org Mon Nov 7 17:33:20 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 7 Nov 2022 17:33:20 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v4] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: On Sat, 5 Nov 2022 18:29:47 GMT, Markus KARG wrote: >> This PR implements JDK-8296431 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed typo test/jdk/java/io/PushbackInputStream/TransferTo.java line 24: > 22: */ > 23: > 24: import java.io.BufferedInputStream; It looks as if there are several unnecessary imports in this test. Please pare them down to those classes actually used. ------------- PR: https://git.openjdk.org/jdk/pull/10999 From alanb at openjdk.org Mon Nov 7 17:58:30 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Nov 2022 17:58:30 GMT Subject: RFR: 8296472: Remove a JVMTI ObjectLocker In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 17:07:01 GMT, Coleen Phillimore wrote: > This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. > Tested with tier1-4, and jvmti and jdi tests locally. src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 204: > 202: * @see java.lang.instrument.Instrumentation#appendToSystemClassLoaderSearch > 203: */ > 204: synchronized void appendToClassPathForInstrumentation(String path) { We might not need this. appendClasspath is thread safe so it's okay for several agents calling appendToSystemClassLoaderSearch at around the same time. I don't think it needs to sycnrhonize with anything else. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From asemenyuk at openjdk.org Mon Nov 7 18:06:28 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 7 Nov 2022 18:06:28 GMT Subject: RFR: 8296154: [macos] Change "/Applications" to "Applications" in DMG image [v2] In-Reply-To: References: Message-ID: On Sat, 5 Nov 2022 01:08:11 GMT, Alexander Matveev wrote: >> Changed names of symbolic links for drag and drop location in DMG image. See attached images in JBS. >> "/Applications" -> "Applications" for app DMG image. >> "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG image. >> >> Automated test was not added, since DMGsetup.scpt is not getting executed in headless environment and thus symbolic links are not created during automated testing. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8296154: [macos] Change /Applications to Applications in DMG image [v2] Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11001 From naoto at openjdk.org Mon Nov 7 18:16:38 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 7 Nov 2022 18:16:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:23:53 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Internalize FormatConcatItem src/java.base/share/classes/java/util/FormatItem.java line 540: > 538: char ch = (char)getCharMH.invokeExact(buffer, start + i); > 539: putCharMH.invokeExact(buffer, start + i, (int)Character.toUpperCase(ch)); > 540: } Some characters may produce multiple uppercase characters, such as "fi" ligature ('\ufb01' -> "FI"), also this should consider locale, e.g. the case for Turkish dotless i. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From coleenp at openjdk.org Mon Nov 7 18:16:49 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 18:16:49 GMT Subject: RFR: 8296472: Remove a JVMTI ObjectLocker In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 17:56:00 GMT, Alan Bateman wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 204: > >> 202: * @see java.lang.instrument.Instrumentation#appendToSystemClassLoaderSearch >> 203: */ >> 204: synchronized void appendToClassPathForInstrumentation(String path) { > > We might not need this. appendClasspath is thread safe so it's okay for several agents calling appendToSystemClassLoaderSearch at around the same time. I don't think it needs to sycnrhonize with anything else. I traced it down to this: Is this why it's already synchronized ? appendClassPath -> ucp.addFile -> addURL public synchronized void addURL(URL url) { if (closed || url == null) return; synchronized (unopenedUrls) { if (! path.contains(url)) { unopenedUrls.addLast(url); path.add(url); } } } ------------- PR: https://git.openjdk.org/jdk/pull/11023 From alanb at openjdk.org Mon Nov 7 18:36:33 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Nov 2022 18:36:33 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 18:11:29 GMT, Coleen Phillimore wrote: >> src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java line 204: >> >>> 202: * @see java.lang.instrument.Instrumentation#appendToSystemClassLoaderSearch >>> 203: */ >>> 204: synchronized void appendToClassPathForInstrumentation(String path) { >> >> We might not need this. appendClasspath is thread safe so it's okay for several agents calling appendToSystemClassLoaderSearch at around the same time. I don't think it needs to sycnrhonize with anything else. > > I traced it down to this: Is this why it's already synchronized ? > appendClassPath -> ucp.addFile -> addURL > public synchronized void addURL(URL url) { > if (closed || url == null) > return; > synchronized (unopenedUrls) { > if (! path.contains(url)) { > unopenedUrls.addLast(url); > path.add(url); > } > } > } Yes, URLClassPath is already synchronized. I'm not 100% sure why the ObjectLocker is there but it's possible to pre-dates parallel capable class loaders so it dates from a time when findClass/loadClass were synchronized on "this". ------------- PR: https://git.openjdk.org/jdk/pull/11023 From coleenp at openjdk.org Mon Nov 7 18:36:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 18:36:33 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 18:29:56 GMT, Alan Bateman wrote: >> I traced it down to this: Is this why it's already synchronized ? >> appendClassPath -> ucp.addFile -> addURL >> public synchronized void addURL(URL url) { >> if (closed || url == null) >> return; >> synchronized (unopenedUrls) { >> if (! path.contains(url)) { >> unopenedUrls.addLast(url); >> path.add(url); >> } >> } >> } > > Yes, URLClassPath is already synchronized. I'm not 100% sure why the ObjectLocker is there but it's possible to pre-dates parallel capable class loaders so it dates from a time when findClass/loadClass were synchronized on "this". Yes, the code's been there for forever. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11023 From coleenp at openjdk.org Mon Nov 7 19:04:36 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 19:04:36 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v2] In-Reply-To: References: Message-ID: > This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. > Tested with tier1-4, and jvmti and jdi tests locally. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Revert ClassLoaders.java change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11023/files - new: https://git.openjdk.org/jdk/pull/11023/files/0c0e1654..781b44fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11023&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11023&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11023.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11023/head:pull/11023 PR: https://git.openjdk.org/jdk/pull/11023 From coleenp at openjdk.org Mon Nov 7 19:04:37 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 19:04:37 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 17:07:01 GMT, Coleen Phillimore wrote: > This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. > Tested with tier1-4, and jvmti and jdi tests locally. I reran jvmti tests on the change to revert ClassLoaders.java. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From psandoz at openjdk.org Mon Nov 7 19:11:15 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Nov 2022 19:11:15 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: <6pOPurF5NgGOYP73lLadj7jzY6FVrCUl9Fkh7MkBfi0=.7ecd3ff9-a2ac-474f-8270-a30bb0f56c92@github.com> On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/foreign/Arena.java line 37: > 35: * This session is created with the arena, and is closed when the arena is {@linkplain #close() closed}. > 36: * Furthermore, all the native segments {@linkplain #allocate(long, long) allocated} by the arena are associated > 37: * with that session. I think we can simplify the wording by saying an arena has a session: Suggestion: * An arena is a {@linkplain AutoCloseable closeable} segment allocator that has a {@link #session() memory session}. * The arena's session is created when the arena is created, and is closed when the arena is {@linkplain #close() closed}. * All native segments {@linkplain #allocate(long, long) allocated} by the arena are associated * with its session. src/java.base/share/classes/java/lang/foreign/Arena.java line 65: > 63: * The {@link MemorySegment#address()} of the returned memory segment is the starting address of the > 64: * allocated off-heap memory region backing the segment. Moreover, the {@linkplain MemorySegment#address() address} > 65: * of the returned segment is aligned according the provided alignment constraint. Suggestion: /** * Creates a native memory segment with the given size (in bytes) and alignment constraint (in bytes). * The returned segment is associated with the arena's memory session. * The segment's {@link MemorySegment#address() address} is the starting address of the * allocated off-heap memory region backing the segment, and the address is * aligned according the provided alignment constraint. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From psandoz at openjdk.org Mon Nov 7 19:23:28 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Nov 2022 19:23:28 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 357: > 355: > 356: /** > 357: * Creates an access var handle that can be used to access a memory segment at the layout selected by the given layout path, Suggestion: * Creates a var handle that can be used to access a memory segment at the layout selected by the given layout path, ------------- PR: https://git.openjdk.org/jdk/pull/10872 From aefimov at openjdk.org Mon Nov 7 19:28:56 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Mon, 7 Nov 2022 19:28:56 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2] In-Reply-To: References: Message-ID: <99trVu2RlL3ZSTZzWWLJE8J6aLJ9q6p7yNAIsbpcAH8=.5473dc57-e79e-4e6f-bc56-9dbee174e8db@github.com> > ### The Proposed Change > > The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). > The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. > The list of proposed changes: > - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. > - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. > - Adjust query retries logic to the new implementation of timeouts. > - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. > > > ### Testing > `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. > JNDI regression and JCK tests also didn't highlight any problems with the changes. > > Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: > ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) > java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) > java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) > java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 > java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) > jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 > jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) > jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) > jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) > java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) > java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) > > After proposed changes - pinned threads are not detectable. Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11007/files - new: https://git.openjdk.org/jdk/pull/11007/files/ad299512..55dd0a4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11007&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11007&range=00-01 Stats: 54 lines in 2 files changed: 17 ins; 14 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/11007.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11007/head:pull/11007 PR: https://git.openjdk.org/jdk/pull/11007 From aefimov at openjdk.org Mon Nov 7 19:29:00 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Mon, 7 Nov 2022 19:29:00 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 15:41:40 GMT, Aleksei Efimov wrote: >> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 185: >> >>> 183: public void close() { >>> 184: try { >>> 185: udpChannelSelector.close(); >> >> Do you think we should now maintain a `closed` boolean flag in this class to keep track of whether this underlying selector has been closed? >> >> The javadoc of `Selector.close()` states that any subsequent use of the selector will throw a `ClosedSelectorException`. A `ClosedSelectorException` is a `RuntimeException`, so if a closed `DnsClient` gets used (for example a `query()` gets triggered) then from what I can see it will end up propagating this `ClosedSelectorException` out of these class methods instead of the declared compile time exceptions. >> >> Maintaining a `closed` flag could allow us to use that flag to check in these methods (where we use the selector) and throw a more appropriate exception. > > Good point - planning to address the closed selector in the `blockingReceive` method by calling `udpChannelSelector.isOpen()`. Addressed it by catching `ClosedSelectorException` and wrapping it into JNDI's `CommunicationException` in 55dd0a4a ------------- PR: https://git.openjdk.org/jdk/pull/11007 From psandoz at openjdk.org Mon Nov 7 19:34:26 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Nov 2022 19:34:26 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: <_3OEoupwOnEbpnA1ApYUiH3GhzDlHyOxearctDT85a0=.493601cf-85d0-4a5d-959d-d01da03e4e83@github.com> On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 104: > 102: * Every memory segment is associated with a {@linkplain MemorySession memory session}. This ensures that access operations > 103: * on a memory segment cannot occur when the region of memory which backs the memory segment is no longer available > 104: * (e.g. after the memory session associated with the accessed memory segment is no longer {@linkplain MemorySession#isAlive() alive}. Missing close brace: Suggestion: * (e.g., after the memory session associated with the accessed memory segment is no longer {@linkplain MemorySession#isAlive() alive}). ------------- PR: https://git.openjdk.org/jdk/pull/10872 From bhuang at openjdk.org Mon Nov 7 19:38:08 2022 From: bhuang at openjdk.org (Bill Huang) Date: Mon, 7 Nov 2022 19:38:08 GMT Subject: RFR: JDK-8293450 Convert test/closed/sun/management/ shell tests to Java version Message-ID: There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils. ------------- Commit messages: - JDK-8293450 Convert test/closed/sun/management/ shell tests to Java version Changes: https://git.openjdk.org/jdk/pull/11029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293450 Stats: 453 lines in 4 files changed: 216 ins; 234 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11029/head:pull/11029 PR: https://git.openjdk.org/jdk/pull/11029 From alanb at openjdk.org Mon Nov 7 19:46:47 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 7 Nov 2022 19:46:47 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:00:40 GMT, Coleen Phillimore wrote: > I reran jvmti tests on the change to revert ClassLoaders.java. You can revert the comment too because it would be confusing to say that it locks the class loader when it doesn't. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From psandoz at openjdk.org Mon Nov 7 19:47:42 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Nov 2022 19:47:42 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: <4Sj58ZiAdyXGqIagMDMMD3dTWwjKt8pTudl1JHnwp4Q=.cf41a458-e19d-42b7-b465-b3c40db144ac@github.com> On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 312: > 310: * > 311: * > 312: * Heap segment can only be accessed using a layout whose alignment is smaller or equal to the Suggestion: * Heap segments can only be accessed using a layout whose alignment is smaller or equal to the ------------- PR: https://git.openjdk.org/jdk/pull/10872 From psandoz at openjdk.org Mon Nov 7 20:00:39 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Nov 2022 20:00:39 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/foreign/MemorySession.java line 83: > 81: * MemorySegment segment = MemorySegment.allocateNative(100, MemorySession.implicit()); > 82: * ... > 83: * segment = null; // the segment session is unreacheable here and becomes available for implicit close Typo: Suggestion: * segment = null; // the segment session is unreachable here and becomes available for implicit close ------------- PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Mon Nov 7 20:09:27 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 7 Nov 2022 20:09:27 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v5] In-Reply-To: <7ZPsmtKqqOeItVnPztGyLhwuHi5Q9WsGI8SYzGkyL8Q=.33d63f63-9cbb-42bd-8d81-6555ed3d67d2@github.com> References: <7ZPsmtKqqOeItVnPztGyLhwuHi5Q9WsGI8SYzGkyL8Q=.33d63f63-9cbb-42bd-8d81-6555ed3d67d2@github.com> Message-ID: On Mon, 7 Nov 2022 14:59:27 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Bring windows CallArranger in sync with panama repo > > I have incorporated additional API changes, described in this document: > http://cr.openjdk.java.net/~mcimadamore/panama/session_arenas.html > > The main change is that `MemorySession` is now a pure lifetime abstraction and no longer implements `AutoCloseable`/`SegementAllocator`. Instead a new abstraction, called `Arena` should be used for deterministic deallocation use cases. This change allows several simplifications on the `MemorySession` API, as there's no more need to support non-closeable views. @mcimadamore looks like your latest merge also undid the changes from you `b98febf` commit again ------------- PR: https://git.openjdk.org/jdk/pull/10872 From coleenp at openjdk.org Mon Nov 7 20:40:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 20:40:33 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: > This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. > Tested with tier1-4, and jvmti and jdi tests locally. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: really revert the file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11023/files - new: https://git.openjdk.org/jdk/pull/11023/files/781b44fc..66e9133b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11023&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11023&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11023.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11023/head:pull/11023 PR: https://git.openjdk.org/jdk/pull/11023 From coleenp at openjdk.org Mon Nov 7 20:40:34 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 20:40:34 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:04:36 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Revert ClassLoaders.java change Thanks for spotting that Alan, I thought I'd reverted the entire file. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From psandoz at openjdk.org Mon Nov 7 20:42:16 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Nov 2022 20:42:16 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 329: > 327: /** > 328: * Returns an unbounded address layout with the same carrier, alignment constraint, name and order as this address layout, > 329: * but with the specified pointee layout. An unbounded address layouts allow raw addresses to be accessed Suggestion: * but with the specified pointee layout. An unbounded address layout allow raw addresses to be accessed ------------- PR: https://git.openjdk.org/jdk/pull/10872 From dfuchs at openjdk.org Mon Nov 7 20:46:34 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 7 Nov 2022 20:46:34 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2] In-Reply-To: <99trVu2RlL3ZSTZzWWLJE8J6aLJ9q6p7yNAIsbpcAH8=.5473dc57-e79e-4e6f-bc56-9dbee174e8db@github.com> References: <99trVu2RlL3ZSTZzWWLJE8J6aLJ9q6p7yNAIsbpcAH8=.5473dc57-e79e-4e6f-bc56-9dbee174e8db@github.com> Message-ID: <7VsD3m1jfvkk3cIa-aWPHUGia9GpAtICMWSjDo8SkUA=.7c58c4f5-3115-4068-af08-760cfa46ca1f@github.com> On Mon, 7 Nov 2022 19:28:56 GMT, Aleksei Efimov wrote: >> ### The Proposed Change >> >> The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). >> The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. >> The list of proposed changes: >> - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. >> - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. >> - Adjust query retries logic to the new implementation of timeouts. >> - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. >> >> >> ### Testing >> `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. >> JNDI regression and JCK tests also didn't highlight any problems with the changes. >> >> Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: >> ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) >> java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) >> java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) >> java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 >> java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) >> jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) >> jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) >> java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) >> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) >> >> After proposed changes - pinned threads are not detectable. > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Changes requested by dfuchs (Reviewer). src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DNSDatagramChannelFactory.java line 279: > 277: } catch (IOException x) { > 278: // try again until maxtries == 0; > 279: } That can be simplified now: DatagramChannel dc = (family != null) ? DatagramChannel.open(family) : DatagramChannel.open(); try { dc.bind(new InetSocketAddress(port)); lastport = getLocalPort(dc); if (!recycled) history.add(port); return dc; } catch (IOException x) { dc.close(); // try again until maxtries == 0; } There's probably no need to retry if the open call fails, as the next call to `open` is likely to fail too. So if `open` throws we should probably let it propagate upwards - (and declare openRandom() to throw IOException). ------------- PR: https://git.openjdk.org/jdk/pull/11007 From psandoz at openjdk.org Mon Nov 7 20:46:37 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 7 Nov 2022 20:46:37 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/foreign/package-info.java line 103: > 101: * the memory session associated with the segment being accessed has not been closed prematurely. > 102: * We call this guarantee temporal safety. Together, spatial and temporal safety ensure that each memory access > 103: * operation either succeeds - and accesses a valid location of the region of memory backing the memory segment - or fails. Suggestion: * operation either succeeds - and accesses a valid location within the region of memory backing the memory segment - or fails. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From dfuchs at openjdk.org Mon Nov 7 20:46:34 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 7 Nov 2022 20:46:34 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 15:39:55 GMT, Aleksei Efimov wrote: >> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 470: >> >>> 468: } while (timeoutLeft > MIN_TIMEOUT); >>> 469: // no matching packet received within the timeout >>> 470: throw new SocketTimeoutException(); >> >> It appears to me that, before the change in this PR, we used to return `null` from this method if there is a timeout. The calling code (the method `query`) would then interpret this `null` return in a couple of different ways. One of them being, skipping this server and querying any other server(s) that were known to the client instance. Now, with this change where we throw this `SocketTimeoutException`, that part of the code would behave differently from what I can see. Is this intentional to throw an exception instead of returning `null`? > > Thanks for spotting that, Jai. > You're correct that in its current version the fix changed an old logic of `doUdpQuery`/`query` methods: > Before this change the method was returning `null` not when a receive is timed out but when an unmatched packet is received. Socket timeout exceptions thrown by `DatagramSocket.receive` were caught in `query` method. > After the proposed change the `doUdpQuery` method is throwing `SocketTimeoutException` for both cases (timeout and unmatched packets) - that needs to be changed to comply with old logic. Will address it in an upcoming changeset. This is addressed now - right? ------------- PR: https://git.openjdk.org/jdk/pull/11007 From almatvee at openjdk.org Mon Nov 7 20:57:22 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 7 Nov 2022 20:57:22 GMT Subject: Integrated: 8296154: [macos] Change "/Applications" to "Applications" in DMG image In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 23:26:00 GMT, Alexander Matveev wrote: > Changed names of symbolic links for drag and drop location in DMG image. See attached images in JBS. > "/Applications" -> "Applications" for app DMG image. > "/Library/Java/JavaVirtualMachines" -> "JavaVirtualMachines" for runtime DMG image. > > Automated test was not added, since DMGsetup.scpt is not getting executed in headless environment and thus symbolic links are not created during automated testing. This pull request has now been integrated. Changeset: 7e85b41d Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/7e85b41d37c5eec9693cfc07447f5deffd5d483b Stats: 19 lines in 3 files changed: 15 ins; 0 del; 4 mod 8296154: [macos] Change "/Applications" to "Applications" in DMG image Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/11001 From duke at openjdk.org Mon Nov 7 21:46:39 2022 From: duke at openjdk.org (duke) Date: Mon, 7 Nov 2022 21:46:39 GMT Subject: Withdrawn: 8286212: Cgroup v1 initialization causes NPE on some systems In-Reply-To: References: Message-ID: On Tue, 10 May 2022 12:29:10 GMT, Severin Gehwolf wrote: > Please review this change to the cgroup v1 subsystem which makes it more resilient on some of the stranger systems. Unfortunately, I wasn't able to re-create a similar system as the reporter. The idea of using the longest substring match for the cgroupv1 file paths was based on the fact that on systemd systems processes run in separate scopes and the maven forked test runner might exhibit this property. For that it makes sense to use the common ancestor path. Nothing changes in the common cases where the `cgroup_path` matches `_root` and when the `_root` is `/` (container the former, host system the latter). > > In addition, the code paths which are susceptible to throw NPE have been hardened to catch those situations. Should it happen in the future it makes more sense (to me) to not have accurate container detection in favor of continuing to keep running. > > Finally, with the added unit-tests a bug was uncovered on the "substring" match case of cgroup paths in hotspot. `p` returned from `strstr` can never point to `_root` as it's used as the "needle" to find in "haystack" `cgroup_path` (not the other way round). > > Testing: > - [x] Added unit tests > - [x] GHA > - [x] Container tests on cgroups v1 Linux. Continue to pass This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/8629 From duke at openjdk.org Mon Nov 7 22:36:57 2022 From: duke at openjdk.org (Justin Lu) Date: Mon, 7 Nov 2022 22:36:57 GMT Subject: RFR: 8296239: ISO 4217 Amendment 174 Update Message-ID: Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023). ------------- Commit messages: - Actually change to GMT+1 - Convert time to Croatia/GMT+1 - Reflect future change date in table - Add future date, remove localedata changes - Initial changes for ISO 174 Changes: https://git.openjdk.org/jdk/pull/10994/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10994&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296239 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10994.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10994/head:pull/10994 PR: https://git.openjdk.org/jdk/pull/10994 From naoto at openjdk.org Mon Nov 7 22:37:00 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 7 Nov 2022 22:37:00 GMT Subject: RFR: 8296239: ISO 4217 Amendment 174 Update In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 17:21:04 GMT, Justin Lu wrote: > Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023). Changes requested by naoto (Reviewer). src/java.base/share/data/currency/CurrencyData.properties line 192: > 190: CI=XOF > 191: # CROATIA > 192: HR=HRK;2022-12-31-21-00-00;EUR Since Croatian time is `GMT+1`, the cutover time should be `2022-12-31-23-00-00` in GMT test/jdk/java/util/Currency/tablea1.txt line 70: > 68: CR CRC 188 2 > 69: CI XOF 952 0 > 70: HR HRK 191 2 2022-12-31-21-00-00 EUR 978 2 Same as above ------------- PR: https://git.openjdk.org/jdk/pull/10994 From duke at openjdk.org Mon Nov 7 22:37:02 2022 From: duke at openjdk.org (Justin Lu) Date: Mon, 7 Nov 2022 22:37:02 GMT Subject: RFR: 8296239: ISO 4217 Amendment 174 Update In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 17:40:27 GMT, Naoto Sato wrote: >> Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023). > > src/java.base/share/data/currency/CurrencyData.properties line 192: > >> 190: CI=XOF >> 191: # CROATIA >> 192: HR=HRK;2022-12-31-21-00-00;EUR > > Since Croatian time is `GMT+1`, the cutover time should be `2022-12-31-23-00-00` in GMT Made the change thank you ------------- PR: https://git.openjdk.org/jdk/pull/10994 From sspitsyn at openjdk.org Mon Nov 7 22:51:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Nov 2022 22:51:22 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file > We might not need this. appendClasspath is thread safe so it's okay for several > agents calling appendToSystemClassLoaderSearch at around the same time. > I don't think it needs to sycnrhonize with anything else. I'm thinking about a good place where to place a comment about this. Probably, it can be placed before the method `appendToClassPathForInstrumentation`. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From sspitsyn at openjdk.org Mon Nov 7 23:22:30 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 7 Nov 2022 23:22:30 GMT Subject: RFR: JDK-8293450 Convert test/closed/sun/management/ shell tests to Java version In-Reply-To: References: Message-ID: <_YdUIZ-jJx061FAojvH4lGptQWtOlSsDIT5Dgcbo9_Q=.24fa4704-2ec1-49e2-bccb-acc14d3d492b@github.com> On Mon, 7 Nov 2022 19:23:05 GMT, Bill Huang wrote: > There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. The refactoring looks pretty good. But I have a couple of questions. Q1: The method `grantAccess` is converted to the util method `grantFileAccess` and it does not look the same. Could you, please, explain what are the changes? Q2: I'm confused about conversion of the shell tests. Your fix does not convert any shell test. Also, I do not see any changes to the shell ile `test/jdk/sun/management/jmxremote/bootstrap/ReadWriteForbidsCreateTest.sh` listed in the enhancement. Can you explain, please? ------------- PR: https://git.openjdk.org/jdk/pull/11029 From coleenp at openjdk.org Mon Nov 7 23:31:31 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 23:31:31 GMT Subject: RFR: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 16:48:36 GMT, Mandy Chung wrote: >> This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. >> Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. >> https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() >> >> Tested with tier1-6 and internal applications. > > Adding core-libs-dev so that more developers know this behavioral change. > > *Background:* > > Prior to JDK 7, custom class loaders using non-hierarchical class delegation model were prone to deadlock (see [1] for details). This workaround was added in the VM in JDK 6 to allow parallel class loading for non-parallel-capable class loaders to avoid deadlocks. The VM also supports a common workaround at the time that some customers explicitly issue a wait() on the class loader lock. > > Such workaround was kept to allow those customers to migrate to using multi-thread-safe parallel-capable class loaders. It has been 11 years since Java 7 and it's expected that those deadlock-prone custom class loaders should have migrated to the parallel-capable class loaders. > > If customers have class loaders depending on this legacy behavior, they can set `-XX:+EnableWaitForParallelLoad` flag to enable the legacy behavior and migrate to parallel-capable class loaders as soon as possible. The `EnableWaitForParallelLoad` VM flag will be removed in a future release. > > Refers to CSR [JDK-8295848](https://bugs.openjdk.org/browse/JDK-8295848) for details. Thank you for the discussions, CSR, help and code reviews, @mlchung and @dholmes-ora . ------------- PR: https://git.openjdk.org/jdk/pull/10832 From coleenp at openjdk.org Mon Nov 7 23:35:12 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 7 Nov 2022 23:35:12 GMT Subject: Integrated: 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 12:16:54 GMT, Coleen Phillimore wrote: > This change adds an option **EnableWaitForParallelLoad** to enable the legacy behavior where the VM will manage synchronization for multiple threads loading the same class using a non-parallel capable class loader that have released the class loader lock. The VM will break the class loader lock for parallel threads trying to load the class, and wait for the first thread that initiated loading the class to complete. The subsequent threads will use the result of the first thread, rather than get a LinkageError: duplicate class definition for loading the class without synchronization. > Releasing the class loader lock was a common workaround for class loaders that used a non-hierarchical delegation scheme to avoid deadlock, before parallel capable class loading was added. > https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#registerAsParallelCapable() > > Tested with tier1-6 and internal applications. This pull request has now been integrated. Changeset: 76790ad2 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/76790ad2427b777b470ef3e5474fa8df9f3bf875 Stats: 25 lines in 7 files changed: 14 ins; 1 del; 10 mod 8295673: Deprecate and disable legacy parallel class loading workaround for non-parallel-capable class loaders Reviewed-by: mchung, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/10832 From bhuang at openjdk.org Tue Nov 8 00:21:31 2022 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 8 Nov 2022 00:21:31 GMT Subject: RFR: JDK-8293450 Convert test/closed/sun/management/ shell tests to Java version In-Reply-To: <_YdUIZ-jJx061FAojvH4lGptQWtOlSsDIT5Dgcbo9_Q=.24fa4704-2ec1-49e2-bccb-acc14d3d492b@github.com> References: <_YdUIZ-jJx061FAojvH4lGptQWtOlSsDIT5Dgcbo9_Q=.24fa4704-2ec1-49e2-bccb-acc14d3d492b@github.com> Message-ID: On Mon, 7 Nov 2022 23:20:15 GMT, Serguei Spitsyn wrote: >> There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. > > The refactoring looks pretty good. > But I have a couple of questions. > Q1: The method `grantAccess` is converted to the util method `grantFileAccess` and it does not look the same. Could you, please, explain what are the changes? > Q2: I'm confused about conversion of the shell tests. Your fix does not convert any shell test. Also, I do not see any changes to the shell ile `test/jdk/sun/management/jmxremote/bootstrap/ReadWriteForbidsCreateTest.sh` listed in the enhancement. Can you explain, please? Hi @sspitsyn, the methods `grantAccess` and `grantFileAccess` are almost identical except for the parameter `AccessControl access` being changed to a boolean which is used to indicate user access or full access. There is also a minor change in building a new ACL entry out of the original entry. For your Q2 , it is in closed part of JDK. Please see the JBS ticket for the PR link. ------------- PR: https://git.openjdk.org/jdk/pull/11029 From aefimov at openjdk.org Tue Nov 8 00:26:56 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Tue, 8 Nov 2022 00:26:56 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v3] In-Reply-To: References: Message-ID: > ### The Proposed Change > > The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). > The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. > The list of proposed changes: > - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. > - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. > - Adjust query retries logic to the new implementation of timeouts. > - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. > > > ### Testing > `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. > JNDI regression and JCK tests also didn't highlight any problems with the changes. > > Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: > ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) > java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) > java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) > java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 > java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) > jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 > jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) > jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) > jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) > java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) > java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) > > After proposed changes - pinned threads are not detectable. Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: Simplify openRandom ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11007/files - new: https://git.openjdk.org/jdk/pull/11007/files/55dd0a4a..fa7ef187 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11007&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11007&range=01-02 Stats: 18 lines in 1 file changed: 4 ins; 13 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11007.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11007/head:pull/11007 PR: https://git.openjdk.org/jdk/pull/11007 From aefimov at openjdk.org Tue Nov 8 00:26:58 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Tue, 8 Nov 2022 00:26:58 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v2] In-Reply-To: <7VsD3m1jfvkk3cIa-aWPHUGia9GpAtICMWSjDo8SkUA=.7c58c4f5-3115-4068-af08-760cfa46ca1f@github.com> References: <99trVu2RlL3ZSTZzWWLJE8J6aLJ9q6p7yNAIsbpcAH8=.5473dc57-e79e-4e6f-bc56-9dbee174e8db@github.com> <7VsD3m1jfvkk3cIa-aWPHUGia9GpAtICMWSjDo8SkUA=.7c58c4f5-3115-4068-af08-760cfa46ca1f@github.com> Message-ID: On Mon, 7 Nov 2022 20:26:54 GMT, Daniel Fuchs wrote: >> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DNSDatagramChannelFactory.java line 279: > >> 277: } catch (IOException x) { >> 278: // try again until maxtries == 0; >> 279: } > > That can be simplified now: > > DatagramChannel dc = (family != null) > ? DatagramChannel.open(family) > : DatagramChannel.open(); > try { > dc.bind(new InetSocketAddress(port)); > lastport = getLocalPort(dc); > if (!recycled) history.add(port); > return dc; > } catch (IOException x) { > dc.close(); > // try again until maxtries == 0; > } > > There's probably no need to retry if the open call fails, as the next call to `open` is likely to fail too. So if `open` throws we should probably let it propagate upwards - (and declare openRandom() to throw IOException). Thanks for suggestion - `openRandom` looks much simplier, no duplicated code and in-sync with `openDefault`. I agree that it is reasonable not to retry `open` call in failure case, and propagate `IOException`. Changed in fa7ef18713930aa19f1f45672ed3181acd2a0e63 ------------- PR: https://git.openjdk.org/jdk/pull/11007 From aefimov at openjdk.org Tue Nov 8 00:27:00 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Tue, 8 Nov 2022 00:27:00 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:39:27 GMT, Daniel Fuchs wrote: >> Thanks for spotting that, Jai. >> You're correct that in its current version the fix changed an old logic of `doUdpQuery`/`query` methods: >> Before this change the method was returning `null` not when a receive is timed out but when an unmatched packet is received. Socket timeout exceptions thrown by `DatagramSocket.receive` were caught in `query` method. >> After the proposed change the `doUdpQuery` method is throwing `SocketTimeoutException` for both cases (timeout and unmatched packets) - that needs to be changed to comply with old logic. Will address it in an upcoming changeset. > > This is addressed now - right? Yes, already addressed in 55dd0a4 ------------- PR: https://git.openjdk.org/jdk/pull/11007 From coleenp at openjdk.org Tue Nov 8 01:05:24 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 01:05:24 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call Message-ID: The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. Tested with tier 1-4. ------------- Commit messages: - 8296492: Remove ObjectLocker in JVMTI get_subgroups call Changes: https://git.openjdk.org/jdk/pull/11033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296492 Stats: 109 lines in 5 files changed: 30 ins; 67 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11033.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11033/head:pull/11033 PR: https://git.openjdk.org/jdk/pull/11033 From dholmes at openjdk.org Tue Nov 8 04:25:27 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Nov 2022 04:25:27 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file Note the loader involved need not be our own default platform loader and we don't know how a custom system loader might operate. The specification for this says nothing about thread-safety, nor that the VM will do any locking, so I think it is okay to remove it - but it is a change in behaviour that should be documented by a CSR request. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From dholmes at openjdk.org Tue Nov 8 04:49:24 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Nov 2022 04:49:24 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. This is a nice simplification of the VM side of the code! I do have to wonder why this was implemented the way it was rather than doing the simple upcall as you now do, but I suspect it was just performance, which should not be an issue today. One query/concern about exception handling. Thanks. src/hotspot/share/prims/jvmtiEnvBase.cpp line 810: > 808: if (HAS_PENDING_EXCEPTION) { > 809: CLEAR_PENDING_EXCEPTION; > 810: return JVMTI_ERROR_OUT_OF_MEMORY; Do we need to handle unexpected exceptions better, rather than just claiming they are OOME? ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Tue Nov 8 08:01:28 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 08:01:28 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 04:23:13 GMT, David Holmes wrote: > Note the loader involved need not be our own default platform loader and we don't know how a custom system loader might operate. The specification for this says nothing about thread-safety, nor that the VM will do any locking, so I think it is okay to remove it - but it is a change in behaviour that should be documented by a CSR request. In that configuration, the custom system class loader will be created with the app class loader as its parent. It's still the app class loader that loads from the class path and it will be the app class loader's appendToClassPathForInstrumentation method that is called (there's no equivalent for custom system class loaders). I would hope there are tests for this but the discussion makes me wonder what SystemDictionary::java_system_loader() returns, esp. given a custom class loader won't be created until initPhase3. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From sspitsyn at openjdk.org Tue Nov 8 08:20:27 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 8 Nov 2022 08:20:27 GMT Subject: RFR: JDK-8293450 Convert test/closed/sun/management/ shell tests to Java version In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:23:05 GMT, Bill Huang wrote: > There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. test/lib/jdk/test/lib/Utils.java line 980: > 978: PosixFilePermissions.fromString("rwxrwxrwx")); > 979: } > 980: } else if (attr.contains("acl")) { I like more the style as it was before: String perms = userOnly ? "rw-------" : "rwxrwxrwx"; Files.setPosixFilePermissions(file, PosixFilePermissions.fromString(perms)); instead of this: Files.setPosixFilePermissions(file, PosixFilePermissions.fromString("rwx------")); } else { /* Allow access to everyone */ Files.setPosixFilePermissions(file, PosixFilePermissions.fromString("rwxrwxrwx")); ------------- PR: https://git.openjdk.org/jdk/pull/11029 From sspitsyn at openjdk.org Tue Nov 8 08:39:08 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 8 Nov 2022 08:39:08 GMT Subject: RFR: JDK-8293450 Convert test/closed/sun/management/ shell tests to Java version In-Reply-To: References: Message-ID: <_e2mWJMihJQGeKKLEtUcHBLZy6s1rOLYnNcLcRQzuKQ=.03670db8-ac4e-4605-a575-87890bc4d83b@github.com> On Mon, 7 Nov 2022 19:23:05 GMT, Bill Huang wrote: > There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. I've placed a couple of comments. Otherwise, it looks okay to me. Thanks, Serguei ------------- PR: https://git.openjdk.org/jdk/pull/11029 From sspitsyn at openjdk.org Tue Nov 8 08:44:18 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 8 Nov 2022 08:44:18 GMT Subject: RFR: JDK-8293450 Convert test/closed/sun/management/ shell tests to Java version In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:23:05 GMT, Bill Huang wrote: > There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. test/lib/jdk/test/lib/Utils.java line 1007: > 1005: } > 1006: } > 1007: } What was your motivation to get rid of the `Util` methods `revokeAccess`, `allowAccess` and `buildAclEntry`? The implementation did not become more clearer nor simpler. But reviewing it became harder. ------------- PR: https://git.openjdk.org/jdk/pull/11029 From sspitsyn at openjdk.org Tue Nov 8 09:02:40 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 8 Nov 2022 09:02:40 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. This looks nice in general. But I will make another pass. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Tue Nov 8 10:05:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 10:05:18 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 04:45:17 GMT, David Holmes wrote: > This is a nice simplification of the VM side of the code! I do have to wonder why this was implemented the way it was rather than doing the simple upcall as you now do, but I suspect it was just performance, I don't think JVMTI GetThreadGroupChildren was ever performance critical, it's just that historically JVMTI functions haven't done many upcalls because of the potential side effects of events generated when executing Java code. I think the horse has bolted on this already, e.g. the JVMTI functions added in Java 9 all require calling into Java code. So I think it is a good simplification but a reminder that the set of "Universal errors" in the JVMTI spec may not be sufficient to cover the possible exceptions. As you point out, the current patch maps all errors/exceptions to JVMTI_ERROR_OUT_OF_MEMORY. It's the most likely reason for it to fail but it might stack overflow or something else. I note that JvmtiEnv::AddToSystemClassLoaderSearch maps errors/exceptions to JVMTI_ERROR_INTERNAL. Maybe we need an issue in JBS to track examine this issue as it's not specific to GetThreadGroupChildren. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Tue Nov 8 10:09:32 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 10:09:32 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call In-Reply-To: References: Message-ID: <-IUgUziZB4xaQHdy5yU4HFWyH9CP9VzMkH6MS-QATBY=.ae540ff2-d629-4459-bc5a-bb0da8e7f784@github.com> On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. src/java.base/share/classes/java/lang/ThreadGroup.java line 802: > 800: int length = groups.size(); > 801: return groups.toArray(new ThreadGroup[length]); > 802: } Would you mind changing the comment to "Returns a snapshot of the subgroups as an array, used by JVMTI.", only to be consistent with the other methods that return subgroups as they all document it as a "snapshot". Also I think I would rename this to subgroupsAsArray as there isn't a "subgroups array". If you want, `return groups.toArray(new ThreadGroup[0]);` will do the sizing for you. Minor nit, you've additional blank lines after this method, I assume you only meant to add one. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From mcimadamore at openjdk.org Tue Nov 8 10:36:49 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 10:36:49 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v7] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with seven additional commits since the last revision: - Update src/java.base/share/classes/java/lang/foreign/MemorySession.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/lang/foreign/MemoryLayout.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/lang/foreign/Arena.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/lang/foreign/Arena.java Co-authored-by: Paul Sandoz - Bring windows CallArranger in sync with panama repo (again) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/f04be0da..cc4ff582 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=05-06 Stats: 31 lines in 6 files changed: 0 ins; 1 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Tue Nov 8 10:36:49 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 10:36:49 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/java/lang/ModuleLayer.java line 331: > 329: "enableNativeAccess"); > 330: target.implAddEnableNativeAccess(); > 331: return this; ModuelLayer.enableNativeAccess looks fine, we iterated on that in panama-foreign/pull/729. I assume you'll add @since 20. Also you might want to check the alignment, it looks like the method is indented by 5 instead of the usual 4 spaces. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 8 10:42:13 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 10:42:13 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v8] In-Reply-To: References: Message-ID: <1i9WM9QJ9WZsXv_3ZCsHRBDpG65nehSUjtww0HHTYcw=.c53b9cc2-45c9-49d4-bedf-1de71bf86f99@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Fix bad indent on ModuleLayer.Controller - Update src/java.base/share/classes/java/lang/foreign/package-info.java Co-authored-by: Paul Sandoz - Update src/java.base/share/classes/java/lang/foreign/ValueLayout.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/cc4ff582..afb36a95 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=06-07 Stats: 11 lines in 3 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Tue Nov 8 11:27:03 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 11:27:03 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v8] In-Reply-To: <1i9WM9QJ9WZsXv_3ZCsHRBDpG65nehSUjtww0HHTYcw=.c53b9cc2-45c9-49d4-bedf-1de71bf86f99@github.com> References: <1i9WM9QJ9WZsXv_3ZCsHRBDpG65nehSUjtww0HHTYcw=.c53b9cc2-45c9-49d4-bedf-1de71bf86f99@github.com> Message-ID: On Tue, 8 Nov 2022 10:42:13 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: > > - Fix bad indent on ModuleLayer.Controller > - Update src/java.base/share/classes/java/lang/foreign/package-info.java > > Co-authored-by: Paul Sandoz > - Update src/java.base/share/classes/java/lang/foreign/ValueLayout.java > > Co-authored-by: Paul Sandoz src/java.base/share/classes/java/lang/foreign/Arena.java line 34: > 32: * An arena allocates and manages the lifecycle of native segments. > 33: *

> 34: * An arena is a {@linkplain AutoCloseable closeable} segment allocator that has a {@link #session() memory session}. Should this is link MemorySession or linkplan memory session ? src/java.base/share/classes/java/lang/foreign/Arena.java line 98: > 96: * that memory session are also released. > 97: * @throws IllegalStateException if the session associated with this arena is not {@linkplain MemorySession#isAlive() alive}. > 98: * @throws WrongThreadException if this method is called from a thread other than the thread Should this be qualified to say that when the session is confined, and thread is called from a thread other than the owner? ------------- PR: https://git.openjdk.org/jdk/pull/10872 From rgiulietti at openjdk.org Tue Nov 8 11:41:44 2022 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 8 Nov 2022 11:41:44 GMT Subject: RFR: 8296529: Document the default behavior of '$' in regular expressions correctly Message-ID: A small spec change to match established behavior. ------------- Commit messages: - 8296529: Document the default behavior of '$' in regular expressions correctly Changes: https://git.openjdk.org/jdk/pull/11038/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11038&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296529 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11038.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11038/head:pull/11038 PR: https://git.openjdk.org/jdk/pull/11038 From coleenp at openjdk.org Tue Nov 8 11:47:19 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 11:47:19 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call In-Reply-To: <-IUgUziZB4xaQHdy5yU4HFWyH9CP9VzMkH6MS-QATBY=.ae540ff2-d629-4459-bc5a-bb0da8e7f784@github.com> References: <-IUgUziZB4xaQHdy5yU4HFWyH9CP9VzMkH6MS-QATBY=.ae540ff2-d629-4459-bc5a-bb0da8e7f784@github.com> Message-ID: On Tue, 8 Nov 2022 10:05:34 GMT, Alan Bateman wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > src/java.base/share/classes/java/lang/ThreadGroup.java line 802: > >> 800: int length = groups.size(); >> 801: return groups.toArray(new ThreadGroup[length]); >> 802: } > > Would you mind changing the comment to "Returns a snapshot of the subgroups as an array, used by JVMTI.", only to be consistent with the other methods that return subgroups as they all document it as a "snapshot". Also I think I would rename this to subgroupsAsArray as there isn't a "subgroups array". > > If you want, `return groups.toArray(new ThreadGroup[0]);` will do the sizing for you. > > Minor nit, you've additional blank lines after this method, I assume you only meant to add one. Thank you for looking at this - that's a much better name and comment and thanks for the Java hints (I copied that from somewhere else). ------------- PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 8 11:56:23 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 11:56:23 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. Thanks Alan for your comment - yes, I think doing upcalls from JVMTI wasn't done before because of possible events, and it was the way things were done. I'm glad this is okay now. I'm going to file an issue for the error handling. From AddToSystemClassLoaderSearch - this is mapped to JVMTI_ERROR_INTERNAL when it's clearly (?) an OOM but there should be some sort of utility function. Maybe there is already? // need the path as java.lang.String Handle path = java_lang_String::create_from_platform_dependent_str(segment, THREAD); if (HAS_PENDING_EXCEPTION) { CLEAR_PENDING_EXCEPTION; return JVMTI_ERROR_INTERNAL; } ------------- PR: https://git.openjdk.org/jdk/pull/11033 From rgiulietti at openjdk.org Tue Nov 8 12:05:11 2022 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 8 Nov 2022 12:05:11 GMT Subject: RFR: 8296292: Document the default behavior of '$' in regular expressions correctly In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 11:35:17 GMT, Raffaello Giulietti wrote: > A small spec change to match established behavior. As this is a spec change only, please consider reviewing the CSR as well. ------------- PR: https://git.openjdk.org/jdk/pull/11038 From dfuchs at openjdk.org Tue Nov 8 12:10:27 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Tue, 8 Nov 2022 12:10:27 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v3] In-Reply-To: References: Message-ID: <7XgJJk-XrV7-n2O851bMq1uyzoPUFxrkaLh11PYxZFY=.c1fc1d54-e805-48f6-b890-62f526f330af@github.com> On Tue, 8 Nov 2022 00:26:56 GMT, Aleksei Efimov wrote: >> ### The Proposed Change >> >> The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). >> The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. >> The list of proposed changes: >> - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. >> - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. >> - Adjust query retries logic to the new implementation of timeouts. >> - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. >> >> >> ### Testing >> `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. >> JNDI regression and JCK tests also didn't highlight any problems with the changes. >> >> Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: >> ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) >> java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) >> java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) >> java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 >> java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) >> jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) >> jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) >> java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) >> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) >> >> After proposed changes - pinned threads are not detectable. > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Simplify openRandom Changes look good! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11007 From coleenp at openjdk.org Tue Nov 8 12:30:37 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 12:30:37 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v2] In-Reply-To: References: Message-ID: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Handle non OOM exceptions and rename subgroupsAsArray. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11033/files - new: https://git.openjdk.org/jdk/pull/11033/files/a916f3fd..8615b179 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=00-01 Stats: 12 lines in 2 files changed: 5 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11033.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11033/head:pull/11033 PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 8 12:30:38 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 12:30:38 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 04:35:48 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Handle non OOM exceptions and rename subgroupsAsArray. > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 810: > >> 808: if (HAS_PENDING_EXCEPTION) { >> 809: CLEAR_PENDING_EXCEPTION; >> 810: return JVMTI_ERROR_OUT_OF_MEMORY; > > Do we need to handle unexpected exceptions better, rather than just claiming they are OOME? I added a case for returning JVMTI_ERROR_INTERNAL also. In the spec https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#universal-error The other universal errors are inapplicable (and already checked in the case of JVMTI_ERROR_INVALID_THREAD_GROUP and the invalid environment one (by the jvmti code wrapper). ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Tue Nov 8 12:50:52 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 12:50:52 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 12:30:37 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Handle non OOM exceptions and rename subgroupsAsArray. I wonder if the intermediate resource array is needed now. With the change, subgroupsAsArray returns a Java array, JvmtiEnvBase::get_subgroups creates a resource array with a handle to each of the thread group oops, then JvmtiEnvBase::new_jthreadArray creates a new local ref for each group. src/java.base/share/classes/java/lang/ThreadGroup.java line 796: > 794: > 795: /** > 796: * Returns an snapshot of the subgroups as an array, used by JVMTI. The update looks good, just a typo here where it should be "a snapshot". ------------- PR: https://git.openjdk.org/jdk/pull/11033 From jpai at openjdk.org Tue Nov 8 13:03:32 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 8 Nov 2022 13:03:32 GMT Subject: RFR: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly [v3] In-Reply-To: References: Message-ID: <9K7ODi8xvaWffSaVAjtsZegFz3kuR2QroMUdAOcWtv4=.ca5dcdd7-1e7c-4104-9d44-412fb53fec1f@github.com> On Tue, 8 Nov 2022 00:26:56 GMT, Aleksei Efimov wrote: >> ### The Proposed Change >> >> The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). >> The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. >> The list of proposed changes: >> - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. >> - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. >> - Adjust query retries logic to the new implementation of timeouts. >> - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. >> >> >> ### Testing >> `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. >> JNDI regression and JCK tests also didn't highlight any problems with the changes. >> >> Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: >> ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) >> java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) >> java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) >> java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 >> java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 >> jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) >> jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) >> jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) >> java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) >> java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) >> java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) >> >> After proposed changes - pinned threads are not detectable. > > Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision: > > Simplify openRandom Marked as reviewed by jpai (Reviewer). Thank you Aleksei for the changes. The latest revision looks good to me. ------------- PR: https://git.openjdk.org/jdk/pull/11007 From coleenp at openjdk.org Tue Nov 8 13:06:50 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 13:06:50 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v3] In-Reply-To: References: Message-ID: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11033/files - new: https://git.openjdk.org/jdk/pull/11033/files/8615b179..120bee6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11033.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11033/head:pull/11033 PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 8 13:06:50 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 13:06:50 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 12:48:01 GMT, Alan Bateman wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Handle non OOM exceptions and rename subgroupsAsArray. > > src/java.base/share/classes/java/lang/ThreadGroup.java line 796: > >> 794: >> 795: /** >> 796: * Returns an snapshot of the subgroups as an array, used by JVMTI. > > The update looks good, just a typo here where it should be "a snapshot". fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From mcimadamore at openjdk.org Tue Nov 8 13:28:58 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 13:28:58 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v9] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Rework package-level javadoc for restricted methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/afb36a95..e2840232 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=07-08 Stats: 17 lines in 1 file changed: 9 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Tue Nov 8 13:47:15 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 13:47:15 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 13:06:50 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > fix typo Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Tue Nov 8 14:34:14 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 14:34:14 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: <03q_uZD-g1_ZiTYXVINTiCoe9tc26XUyvkUCmodHogM=.6c45ba81-4daf-4132-a51b-3613ad587030@github.com> On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file I checked the JLPIS agent (= j.l.instrument implementation) with a custom system class loader that doesn't define a appendToClassPathForInstrumentation method and it isn't handled correctly. The right behavior should be for AddToSystemClassLoaderSearch to throw UOE but instead it aborts the VM. So I think we'll create a JBS issue for that. If the custom system class loader does define appendToClassPathForInstrumentation then it will be called, it's just not possible for it to delegate it to the application class loader's appendToClassPathForInstrumentation. It's very possible this will lead to some anomalies as the defining class loader for the classes on the original class path will be the app class loader but any classes added by the agent at runtime (after startup) will likely be the custom system class loader. This is Java agents as opposed to JVMTI agents but it does suggest that the combination of custom system class loader and agents augmenting the class path at runtime is not well tested. So ObjectLocker or not, it is unlikely to be detected by any tests. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From coleenp at openjdk.org Tue Nov 8 14:47:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 14:47:59 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v4] In-Reply-To: References: Message-ID: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Clean up extra copy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11033/files - new: https://git.openjdk.org/jdk/pull/11033/files/120bee6b..89955d30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=02-03 Stats: 40 lines in 3 files changed: 10 ins; 20 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11033.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11033/head:pull/11033 PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 8 14:48:03 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 14:48:03 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 12:47:29 GMT, Alan Bateman wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Handle non OOM exceptions and rename subgroupsAsArray. > > I wonder if the intermediate resource array is needed now. With the change, subgroupsAsArray returns a Java array, JvmtiEnvBase::get_subgroups creates a resource array with a handle to each of the thread group oops, then JvmtiEnvBase::new_jthreadArray creates a new local ref for each group. @AlanBateman you're right the extra copy of the thread group array is wasteful and since I've changed this code already, I cleaned up the extra copying. Reran jvmti tests. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 8 14:55:17 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 14:55:17 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: Message-ID: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Forgot a null check. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11033/files - new: https://git.openjdk.org/jdk/pull/11033/files/89955d30..5bfec2e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11033.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11033/head:pull/11033 PR: https://git.openjdk.org/jdk/pull/11033 From rriggs at openjdk.org Tue Nov 8 15:50:22 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Nov 2022 15:50:22 GMT Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 06:04:34 GMT, Jaikiran Pai wrote: >> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259. >> As described in the bug report, `waitFor()` should not be sensitive to the exit value. >> Previously, it erroneously threw IllegalStateException. >> Added a test to verify. > > The reporter of the issue provided additional details that it was their own application/program which was returning that exit value: > >> I encountered it while prototyping an idea involving a Java application spawning a process running a C++ application that returned an exit value indicating the number of items it processed. > > So this appears like the case where this change would help. I haven't found any conclusive/official Windows documentation which forbids user applications from returning this exit value (which represents `STILL_ACTIVE`). @jaikiran There is advice against exiting with STILL_ACTIVE: [GetExitCodeProcess](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-getexitcodeprocess) says: > The GetExitCodeProcess function returns a valid error code defined by the application only after the thread terminates. Therefore, an application should not use STILL_ACTIVE (259) as an error code (STILL_ACTIVE is a macro for STATUS_PENDING (minwinbase.h)). If a thread returns STILL_ACTIVE (259) as an error code, then applications that test for that value could interpret it to mean that the thread is still running, and continue to test for the completion of the thread after the thread has terminated, which could put the application into an infinite loop. ------------- PR: https://git.openjdk.org/jdk/pull/10680 From rriggs at openjdk.org Tue Nov 8 16:04:26 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Nov 2022 16:04:26 GMT Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 In-Reply-To: References: Message-ID: On Wed, 12 Oct 2022 16:30:07 GMT, Roger Riggs wrote: > Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259. > As described in the bug report, `waitFor()` should not be sensitive to the exit value. > Previously, it erroneously threw IllegalStateException. > Added a test to verify. Though `waitForInterruptibly(handle)` doesn't check the handle, the code in the caller `ProcessImpl.waitFor()` calls `Thread.interrupted()` and throws the `InterruptedException` if needed. So the exit code is returned only if the process had exited. ------------- PR: https://git.openjdk.org/jdk/pull/10680 From rriggs at openjdk.org Tue Nov 8 16:04:25 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Nov 2022 16:04:25 GMT Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 [v2] In-Reply-To: References: Message-ID: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> > Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259. > As described in the bug report, `waitFor()` should not be sensitive to the exit value. > Previously, it erroneously threw IllegalStateException. > Added a test to verify. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Test cleanup as suggested by review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10680/files - new: https://git.openjdk.org/jdk/pull/10680/files/dfb2323c..e7c67d26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10680&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10680&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10680.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10680/head:pull/10680 PR: https://git.openjdk.org/jdk/pull/10680 From jvernee at openjdk.org Tue Nov 8 16:20:51 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Nov 2022 16:20:51 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v9] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 13:28:58 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Rework package-level javadoc for restricted methods Did a full review. Only some minor comments. Also, please add attribution with `/contributor add @` for the people that contributed. (I think you have to add yourself as well, if you do that). src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 57: > 55: > 56: @Override > 57: GroupLayout withName(String name); It looks like this method, and `withBitAlignment` below have no javadoc? Does this need `inheritDoc`? src/java.base/share/classes/java/lang/foreign/Linker.java line 75: > 73: *

    > 74: *
  • if {@code L} is a {@link ValueLayout} with carrier {@code E} then {@code C = E}; or
    • > 75: *
  • if {@code L} is a {@link GroupLayout}, then {@code C} is set to {@code MemorySegment.class}
    • Now that we have `FunctionDescriptor::toMethodType` I think this paragraph could be simplified by just referencing that. src/java.base/share/classes/java/lang/foreign/Linker.java line 101: > 99: *
      > 100: *
    • if {@code L} is a {@link ValueLayout} with carrier {@code E} then {@code C = E}; or
      • > 101: *
    • if {@code L} is a {@link GroupLayout}, then {@code C} is set to {@code MemorySegment.class}
      • Same here. This is covered by the doc of `FunctionDescriptor::toMethodType`. src/java.base/share/classes/java/lang/foreign/Linker.java line 119: > 117: *
    • The memory session of {@code A} is {@linkplain MemorySession#isAlive() alive}. Otherwise, the invocation throws > 118: * {@link IllegalStateException};
      • > 119: *
    • The invocation occurs in same thread as the one {@linkplain MemorySession#isOwnedBy(Thread) owning} the memory session of {@code R}, Suggestion: *
    • The invocation occurs in same thread as the one {@linkplain MemorySession#isOwnedBy(Thread) owning} the memory session of {@code A}, src/java.base/share/classes/java/lang/foreign/Linker.java line 121: > 119: *
    • The invocation occurs in same thread as the one {@linkplain MemorySession#isOwnedBy(Thread) owning} the memory session of {@code R}, > 120: * if said session is confined. Otherwise, the invocation throws {@link WrongThreadException}; and
      • > 121: *
    • The memory session of {@code R} is kept alive (and cannot be closed) during the invocation.
      • Suggestion: *
    • The memory session of {@code A} is kept alive (and cannot be closed) during the invocation.
      • src/java.base/share/classes/java/lang/foreign/StructLayout.java line 43: > 41: > 42: @Override > 43: StructLayout withName(String name); Missing `inheritDoc`? src/java.base/share/classes/java/lang/foreign/UnionLayout.java line 43: > 41: > 42: @Override > 43: UnionLayout withName(String name); Missing `inheritDoc`? src/java.base/share/classes/java/lang/foreign/VaList.java line 44: > 42: * Helper class to create and manipulate variable argument lists, similar in functionality to a C {@code va_list}. > 43: *

      > 44: * A variable argument list segment can be created using the {@link #make(Consumer, MemorySession)} factory, as follows: Suggestion: * A variable argument list can be created using the {@link #make(Consumer, MemorySession)} factory, as follows: src/java.base/share/classes/java/lang/foreign/VaList.java line 50: > 48: * .addVarg(C_DOUBLE, 3.8d)); > 49: *} > 50: * Once created, clients can obtain the platform-dependent {@linkplain #segment() memory segment} associated a variable Suggestion: * Once created, clients can obtain the platform-dependent {@linkplain #segment() memory segment} associated with a variable src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 134: > 132: > 133: @Override > 134: ValueLayout withName(String name); Missing `inheritDoc` here as well, and on other withers below. src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 356: > 354: * Equivalent to the following code: > 355: * {@snippet lang=java : > 356: * ADDRESS.of(ByteOrder.nativeOrder()) This code doesn't look correct. It also looks like OfAddress layouts have their alignment set to the address size already, so the alignment adjustment here seems unnecessary as well. src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 367: > 365: * Equivalent to the following code: > 366: * {@snippet lang=java : > 367: * JAVA_BYTE.of(ByteOrder.nativeOrder()).withBitAlignment(8); Same here (and for the other snippets below), `OfByte` doesn't have an `of` method. This looks maybe like a regex-replace error. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Tue Nov 8 16:20:53 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Nov 2022 16:20:53 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v6] In-Reply-To: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> References: <6KFOS0uVml9eRkWm9inRT0um8oEV_kUw3UZPKT_p67Q=.f330d3e5-5579-4361-8963-763928018e9a@github.com> Message-ID: On Mon, 7 Nov 2022 15:00:02 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Make memory session a pure lifetime abstraction src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 157: > 155: public long mismatch(MemorySegment other) { > 156: Objects.requireNonNull(other); > 157: return MemorySegment.mismatch(this, 0, byteSize(), other, 0, other.byteSize()); Bit strange to see this calling back up to a method in the interface. Maybe this should just be a `default` method in `MemorySegment`? src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 163: > 161: * Mismatch over long lengths. > 162: */ > 163: public static long vectorizedMismatchLargeForBytes(MemorySessionImpl aSession, MemorySessionImpl bSession, Does this need to be `public`? Only seems to be referenced below. src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 179: > 177: @ForceInline > 178: public static MemorySessionImpl toSessionImpl(MemorySession session) { > 179: return (MemorySessionImpl)session; Maybe calls to this method should just be replaced with a cast. src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java line 136: > 134: long ptr = UNSAFE.allocateMemory(LAYOUT.byteSize()); > 135: MemorySegment ms = MemorySegment.ofAddress(ptr, LAYOUT.byteSize(), > 136: MemorySession.implicit(), () -> UNSAFE.freeMemory(ptr)); pre-existing, but it seems like this could just use `MemorySegment.allocateNative(LAYOUT, MemorySession.implicit())`? Suggestion: MemorySegment base = MemorySegment.allocateNative(LAYOUT, MemorySession.implicit()); (and remove the dependency on `Unsafe` altogether) src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java line 142: > 140: VH_gr_offs.set(ms, 0); > 141: VH_vr_offs.set(ms, 0); > 142: return ms; I suggest doing Suggestion: return ms.asSlice(0, 0); To create an opaque segment, just like the `segment()` accessor does. Or maybe update the implementation of `SharedUtils.emptyVaList` to do this. src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/linux/LinuxAArch64VaList.java line 408: > 406: @Override > 407: public MemorySegment segment() { > 408: return segment.asSlice(0, 0); A comment about what is happening here would be nice. (making sure the returned segment is opaque?) src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/macos/MacOsAArch64VaList.java line 176: > 174: @Override > 175: public MemorySegment segment() { > 176: return segment.asSlice(0, 0); Same here. src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java line 145: > 143: long ptr = U.allocateMemory(LAYOUT.byteSize()); > 144: MemorySegment base = MemorySegment.ofAddress(ptr, LAYOUT.byteSize(), > 145: MemorySession.implicit(), () -> U.freeMemory(ptr)); Same here: `MemorySegment base = MemorySegment.allocateNative(LAYOUT, MemorySession.implicit());` src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/SysVVaList.java line 150: > 148: VH_overflow_arg_area.set(base, MemorySegment.NULL); > 149: VH_reg_save_area.set(base, MemorySegment.NULL); > 150: return base; Suggestion: return base.asSlice(0, 0); test/jdk/java/foreign/normalize/TestNormalize.java line 203: > 201: public static Object[][] bools() { > 202: return new Object[][]{ > 203: { 0b01, true }, // zero least significant bit, but non-zero first byte According to the comment this should actually be: Suggestion: { 0b10, true }, // zero least significant bit, but non-zero first byte Looks like I wrote this by mistake :( ------------- PR: https://git.openjdk.org/jdk/pull/10872 From naoto at openjdk.org Tue Nov 8 16:27:42 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 8 Nov 2022 16:27:42 GMT Subject: RFR: 8296239: ISO 4217 Amendment 174 Update In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 17:21:04 GMT, Justin Lu wrote: > Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023). Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10994 From mcimadamore at openjdk.org Tue Nov 8 16:30:14 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 16:30:14 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v10] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Revamp javadoc of Arena/MemorySession Rename MemorySession::isOwnedBy to MemorySession::isAccessibleBy Add Arena::isOwnedBy - Javadoc tweaks in MemorySession/Arena ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/e2840232..fd367106 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=08-09 Stats: 311 lines in 10 files changed: 63 ins; 28 del; 220 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Tue Nov 8 16:36:34 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Nov 2022 16:36:34 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v10] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 16:30:14 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Revamp javadoc of Arena/MemorySession > Rename MemorySession::isOwnedBy to MemorySession::isAccessibleBy > Add Arena::isOwnedBy > - Javadoc tweaks in MemorySession/Arena src/java.base/share/classes/java/lang/foreign/Linker.java line 119: > 117: *

    • The memory session of {@code A} is {@linkplain MemorySession#isAlive() alive}. Otherwise, the invocation throws > 118: * {@link IllegalStateException};
      • > 119: *
    • The invocation occurs in same thread as the one {@linkplain MemorySession#isAccessibleBy(Thread) owning} the memory session of {@code R}, Suggestion: *
    • The invocation occurs in same thread as the one {@linkplain MemorySession#isAccessibleBy(Thread) owning} the memory session of {@code A}, ------------- PR: https://git.openjdk.org/jdk/pull/10872 From coleenp at openjdk.org Tue Nov 8 17:07:33 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 17:07:33 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file We call compute_java_loaders with upcall to ClassLoader.getSystemClassLoader() after initPhase3 but before JVMTI live phase: https://github.com/coleenp/jdk/blob/master/src/hotspot/share/runtime/threads.cpp#L731 which is when jvmti calls this: https://github.com/coleenp/jdk/blob/master/src/hotspot/share/prims/jvmtiEnv.cpp#L703 Can one create a class loader to override this function, and does one expect the JVM to synchronize it on the system class loader object (returned by getSystemClassLoader)? This feels too remote to try to explain in a CSR. I'll look to see if we have tests for this case. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From redestad at openjdk.org Tue Nov 8 17:20:39 2022 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 8 Nov 2022 17:20:39 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v8] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with five additional commits since the last revision: - Merge pull request #2 from luhenry/dev/cl4es/8282664-polyhash Unroll + Reorder BBs - fixup! Handle size=0 and size=1 in Java - Handle size=0 and size=1 in Java - reorder BB to do single scalar first to avoid slowdown of short arrays, longer arrays jumps will be amortized by speedups - Unroll loop for cnt1 < 32 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/6f49b5aa..a4d898a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=06-07 Stats: 216 lines in 7 files changed: 154 ins; 19 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From alanb at openjdk.org Tue Nov 8 18:01:27 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 8 Nov 2022 18:01:27 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 17:03:05 GMT, Coleen Phillimore wrote: > Can one create a class loader to override this function, and does one expect the JVM to synchronize it on the system class loader object (returned by getSystemClassLoader)? This feels too remote to try to explain in a CSR. > > I'll look to see if we have tests for this case. In most cases, system class loader == the application class loader. It should be very rare to run with -Djava.system.class.loader=... but we know of a few application servers that do use it. The behavior prior to JDK 9 was to always call the app class loader's appendToClassPathForInstrumentation. This changed in JDK 9 (see JDK-8160950) to call the custom system class loader's appendToClassPathForInstrumentation. The changes for JDK-8160950 added test/java/lang/instrument/CustomSystemLoader so running the test/java/lang/instrument tests would be good. I'd forgotten about that change when initially commenting here. There isn't anything in the API docs about synchronization on the class loader object, nothing should be depending on that but it wouldn't do any harm to note the change in a release note. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From bhuang at openjdk.org Tue Nov 8 18:10:24 2022 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 8 Nov 2022 18:10:24 GMT Subject: RFR: JDK-8293450 Convert test/sun/management/ shell tests to Java version In-Reply-To: References: Message-ID: <1fQtMd7Wtg4mWIhjbcekB2jGf-3mf3XESTutxmey0OY=.1326b1ee-60e1-498c-a76e-e3b1ddc0c8f6@github.com> On Tue, 8 Nov 2022 08:39:39 GMT, Serguei Spitsyn wrote: >> There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. > > test/lib/jdk/test/lib/Utils.java line 1007: > >> 1005: } >> 1006: } >> 1007: } > > What was your motivation to get rid of the `Util` methods `revokeAccess`, `allowAccess` and `buildAclEntry`? The implementation did not become more clearer nor simpler. But reviewing it became harder. Sure, I will add those methods back. ------------- PR: https://git.openjdk.org/jdk/pull/11029 From mcimadamore at openjdk.org Tue Nov 8 18:18:07 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 18:18:07 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v11] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Address review comments - More javadoc tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/fd367106..bb39bef3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=09-10 Stats: 190 lines in 21 files changed: 106 ins; 34 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Tue Nov 8 18:18:08 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Nov 2022 18:18:08 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v11] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 18:14:21 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: > > - Address review comments > - More javadoc tweaks Marked as reviewed by jvernee (Reviewer). src/java.base/share/classes/java/lang/foreign/MemorySession.java line 67: > 65: * cannot be easily determined. As shown in the example above, a memory session that is managed implicitly cannot end > 66: * if a program references to one or more segments associated with that session. This means that memory segments associated > 67: * with implicitly managed can be safely {@linkplain #isAccessibleBy(Thread) accessed} from multiple threads. Suggestion: * with implicitly managed sessions can be safely {@linkplain #isAccessibleBy(Thread) accessed} from multiple threads. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From bhuang at openjdk.org Tue Nov 8 18:20:34 2022 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 8 Nov 2022 18:20:34 GMT Subject: RFR: JDK-8293450 Convert test/sun/management/ shell tests to Java version [v2] In-Reply-To: References: Message-ID: > There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11029/files - new: https://git.openjdk.org/jdk/pull/11029/files/98a7188e..191cd5ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11029&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11029&range=00-01 Stats: 47 lines in 1 file changed: 31 ins; 11 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11029/head:pull/11029 PR: https://git.openjdk.org/jdk/pull/11029 From mcimadamore at openjdk.org Tue Nov 8 18:28:40 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 18:28:40 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v12] In-Reply-To: References: Message-ID: <3_cNn7GNS1M_3ouTex59atRvhCZX3_-cTeDtlGsLfuk=.4699a537-73b1-427a-a42c-a81ba874d658@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/foreign/MemorySession.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/bb39bef3..fff83ca8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Tue Nov 8 18:47:52 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 8 Nov 2022 18:47:52 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 Message-ID: Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. This is split off from the main JEP integration to make reviewing easier. This includes the following patches: 1. https://github.com/openjdk/panama-foreign/pull/698 2. https://github.com/openjdk/panama-foreign/pull/699 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 4. https://github.com/openjdk/panama-foreign/pull/740 5. https://github.com/openjdk/panama-foreign/pull/746 6. https://github.com/openjdk/panama-foreign/pull/742 7. https://github.com/openjdk/panama-foreign/pull/743 Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. Please refer to the PR of each individual patch for a more detailed description. ------------- Depends on: https://git.openjdk.org/jdk/pull/10872 Commit messages: - Rename CAPTURED_STATE_MASK stub location to CAPTURED_STATE_BUFFER - fix TestCaptureCallState - add stubs - 8295353: Mark Register v24 as Volatile in Foreign Function & Memory C ABI Definition - 8294970: Add linker option for saving thread-locals that the VM can overwrite - 8275584: Incorrect stack spilling in CallArranger on MacOS/AArch64 - 8295265: Refactor handling of special values passed to stubs - VMStorage to record - 8275644: Replace VMReg in shuffling code with something more fine grained. - 8291913: Remove the TraceOptimizedUpcallStubs flag Changes: https://git.openjdk.org/jdk/pull/11019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296477 Stats: 2766 lines in 67 files changed: 1861 ins; 315 del; 590 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From rriggs at openjdk.org Tue Nov 8 19:22:10 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 8 Nov 2022 19:22:10 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v8] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 17:20:39 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with five additional commits since the last revision: > > - Merge pull request #2 from luhenry/dev/cl4es/8282664-polyhash > > Unroll + Reorder BBs > - fixup! Handle size=0 and size=1 in Java > - Handle size=0 and size=1 in Java > - reorder BB to do single scalar first to avoid slowdown of short arrays, longer arrays jumps will be amortized by speedups > - Unroll loop for cnt1 < 32 src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 141: > 139: * > 140: * @param supplier supplies the module reader to access the module content > 141: * Revert, there are no other changes to ModuleHashes.java ------------- PR: https://git.openjdk.org/jdk/pull/10847 From mcimadamore at openjdk.org Tue Nov 8 22:07:07 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 22:07:07 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v13] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: More javadoc fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/fff83ca8..9be0c97b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=11-12 Stats: 10 lines in 3 files changed: 0 ins; 1 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From coleenp at openjdk.org Tue Nov 8 22:10:09 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 8 Nov 2022 22:10:09 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file I could add a release note to say something like: When running a java application with the options "-javaagent:myagent.jar -Djava.system.classloader=MyClassLoader" the myagent.jar is added to the custom system class loader rather then the application class loader. The JVM no longer synchronizes on the custom class loader while calling appendToClassPathForInstrumentation. The appendToClassPathForInstrumentation method in the custom class loader must synchronize appending to the class path. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From mcimadamore at openjdk.org Tue Nov 8 22:12:46 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 8 Nov 2022 22:12:46 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v14] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/9be0c97b..df29e6a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From dholmes at openjdk.org Tue Nov 8 23:38:17 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Nov 2022 23:38:17 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Forgot a null check. src/hotspot/share/prims/jvmtiEnvBase.cpp line 540: > 538: > 539: jthread * > 540: JvmtiEnvBase::new_jthreadArray(int length, Handle *handles) { Shouldn't this method need to cast the return value to `jthread*`? And potentially shouldn't all the jobject's now be jthread's? ------------- PR: https://git.openjdk.org/jdk/pull/11033 From dholmes at openjdk.org Tue Nov 8 23:47:38 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 8 Nov 2022 23:47:38 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 22:08:06 GMT, Coleen Phillimore wrote: > in the custom class loader must synchronize appending to the class path I would say: "in the custom class loader must append to the class path in a thread-safe manner." ------------- PR: https://git.openjdk.org/jdk/pull/11023 From redestad at openjdk.org Tue Nov 8 23:48:22 2022 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 8 Nov 2022 23:48:22 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v9] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits: - Revert accidental ModuleHashes change - Merge branch 'master' into 8282664-polyhash - Merge pull request #2 from luhenry/dev/cl4es/8282664-polyhash Unroll + Reorder BBs - fixup! Handle size=0 and size=1 in Java - Handle size=0 and size=1 in Java - reorder BB to do single scalar first to avoid slowdown of short arrays, longer arrays jumps will be amortized by speedups - Unroll loop for cnt1 < 32 - Merge pull request #1 from luhenry/dev/cl4es/8282664-polyhash Switch to forward approach for vectorization - Fix vector loop - fix indexing - ... and 45 more: https://git.openjdk.org/jdk/compare/dd5d4df5...853a7575 ------------- Changes: https://git.openjdk.org/jdk/pull/10847/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=08 Stats: 1186 lines in 33 files changed: 1130 ins; 9 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Tue Nov 8 23:48:24 2022 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 8 Nov 2022 23:48:24 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v8] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 19:14:25 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with five additional commits since the last revision: >> >> - Merge pull request #2 from luhenry/dev/cl4es/8282664-polyhash >> >> Unroll + Reorder BBs >> - fixup! Handle size=0 and size=1 in Java >> - Handle size=0 and size=1 in Java >> - reorder BB to do single scalar first to avoid slowdown of short arrays, longer arrays jumps will be amortized by speedups >> - Unroll loop for cnt1 < 32 > > src/java.base/share/classes/jdk/internal/module/ModuleHashes.java line 141: > >> 139: * >> 140: * @param supplier supplies the module reader to access the module content >> 141: * > > Revert, there are no other changes to ModuleHashes.java Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Tue Nov 8 23:57:02 2022 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 8 Nov 2022 23:57:02 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 16:03:28 GMT, Ludovic Henry wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > I did a quick write up explaining the approach at https://gist.github.com/luhenry/2fc408be6f906ef79aaf4115525b9d0c. Also, you can find details in @richardstartin's [blog post](https://richardstartin.github.io/posts/vectorised-polynomial-hash-codes) Most optimizations for small arrays are now back - thanks @luhenry! - I'll do a pass tomorrow and see if there's something we can simplify or enhance before calling it done. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From egahlin at openjdk.org Wed Nov 9 01:14:54 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 9 Nov 2022 01:14:54 GMT Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly Message-ID: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool. Testing: test/jdk/jdk/jfr test/jdk/jdk/security/logging/ Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/11039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11039&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296229 Stats: 78 lines in 15 files changed: 36 ins; 1 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/11039.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11039/head:pull/11039 PR: https://git.openjdk.org/jdk/pull/11039 From duke at openjdk.org Wed Nov 9 01:22:24 2022 From: duke at openjdk.org (Justin Lu) Date: Wed, 9 Nov 2022 01:22:24 GMT Subject: Integrated: 8296239: ISO 4217 Amendment 174 Update In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 17:21:04 GMT, Justin Lu wrote: > Incorporated ISO 174 Amendment update: Update Croatia's currency from Kuna to Euro (to take place on 1/1/2023). This pull request has now been integrated. Changeset: fd837649 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/fd837649811c866c144c9133d211fb5ad8f994a7 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8296239: ISO 4217 Amendment 174 Update Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/10994 From duke at openjdk.org Wed Nov 9 02:48:52 2022 From: duke at openjdk.org (David Schlosnagle) Date: Wed, 9 Nov 2022 02:48:52 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v9] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 23:48:22 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits: > > - Revert accidental ModuleHashes change > - Merge branch 'master' into 8282664-polyhash > - Merge pull request #2 from luhenry/dev/cl4es/8282664-polyhash > > Unroll + Reorder BBs > - fixup! Handle size=0 and size=1 in Java > - Handle size=0 and size=1 in Java > - reorder BB to do single scalar first to avoid slowdown of short arrays, longer arrays jumps will be amortized by speedups > - Unroll loop for cnt1 < 32 > - Merge pull request #1 from luhenry/dev/cl4es/8282664-polyhash > > Switch to forward approach for vectorization > - Fix vector loop > - fix indexing > - ... and 45 more: https://git.openjdk.org/jdk/compare/dd5d4df5...853a7575 Overall I am excited to see these changes land as this will be a nice boost for many strong heavy applications! src/hotspot/share/opto/matcher.cpp line 1707: > 1705: if (x >= _LAST_MACH_OPER) { > 1706: fprintf(stderr, "x = %d, _LAST_MACH_OPER = %d\n", x, _LAST_MACH_OPER); > 1707: fprintf(stderr, "dump n\n"); Should this be removed before merging? Suggestion: src/hotspot/share/opto/matcher.cpp line 1709: > 1707: fprintf(stderr, "dump n\n"); > 1708: n->dump(); > 1709: fprintf(stderr, "dump svec\n"); Remove? Suggestion: ------------- PR: https://git.openjdk.org/jdk/pull/10847 From duke at openjdk.org Wed Nov 9 07:11:53 2022 From: duke at openjdk.org (Markus KARG) Date: Wed, 9 Nov 2022 07:11:53 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v5] In-Reply-To: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: > This PR implements JDK-8296431 Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Removed unused imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10999/files - new: https://git.openjdk.org/jdk/pull/10999/files/b6f4d8cb..baaf1c6a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10999&range=03-04 Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10999.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10999/head:pull/10999 PR: https://git.openjdk.org/jdk/pull/10999 From duke at openjdk.org Wed Nov 9 07:11:54 2022 From: duke at openjdk.org (Markus KARG) Date: Wed, 9 Nov 2022 07:11:54 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v4] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: On Mon, 7 Nov 2022 17:29:15 GMT, Brian Burkhalter wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed typo > > test/jdk/java/io/PushbackInputStream/TransferTo.java line 24: > >> 22: */ >> 23: >> 24: import java.io.BufferedInputStream; > > It looks as if there are several unnecessary imports in this test. Please pare them down to those classes actually used. Thanks. I have removed the unused imports. ------------- PR: https://git.openjdk.org/jdk/pull/10999 From thomas.stuefe at gmail.com Wed Nov 9 07:12:59 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 9 Nov 2022 08:12:59 +0100 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: References: Message-ID: Hi Alan, (replaced hotspot-runtime-dev with hotspot-dev, since its more of a general topic) thank you for your time! I am very happy to talk this through. I think native memory observability in the JDK (and customer code!) is sorely lacking. Witness the countless "where did my native memory go" blog articles. At SAP we have been struggling with this topic for a long time and have come up with a mixture of solutions. The aforementioned tracker was one, which extended our version of NMT across the JDK. Our SapMachine MallocTracer, which allows us to trace uninstrumented customer code, another. We even experimented with exchanging the allocator (using jemalloc) to gain insights. But that is a whole different topic with deep logistical implications, I don't want to touch it here. Exchanging the allocator does not help to observe virtual memory or the brk segment, of course. And to make the picture complete, another insight we currently lack is the implicit allocator overhead, which can be very significant and is hidden by the libc. We also have observability for that in the SapMachine, and I miss it in OpenJDK. As you noticed, my original intent was just to instrument Zlib and possibly improve tracking for DBBs. Although, thinking beyond that, another attractive instrumentation target would be mapped NIO buffers at least. So I think native memory observability is important. Arguably we could even extend observability to cover other OS resources, e.g. file handles. If we shift code around, to java/Panama: data that move the java heap does not need to be tracked, but other memory will always come from one of the basic system APIs, regardless of who allocates it and where in the stack allocation happens. Be it native JDK code, Panama, or even customer JNI code. If we agree on the importance of native memory observability, then I believe NMT is the right tool for it. It is a good tool. The machinery is already there. It covers both C-heap and virtual memory APIs, as well as thread stacks, and could easily be extended to cover sbrk if needed. And I assume that whatever shape OpenJDK takes on in the future, there always will be a libjvm.so at its core, so we will always have it. But even if not, NMT could be separated from libjvm.so quite easily, since it has no deep ties with the JVM. About coupling JVM with outside code: We don't have to directly link against libjvm.so. We can keep things loose if the intent is to be runnable without a JVM, or be JVM-version-agnostic. That could take the form of a function-pointer interface like JVMTI. Or outside code could dynamically dlsym the JVM allocation hooks. In any case gracefully falling back to system allocation routines when necessary. And I agree, polluting the NMT tag space with outside meaning is ugly. I only did it because I planned to go no further than instrumenting Zlib and possibly DBBs. But if we take this further, my preferred solution would be a reserved tag range or -ranges for outside use, whose inner meaning would be opaque to the JVM. Kind of like SIGRTMIN+SIGRTMAX. Then, outside code could register tags and their meta information with the JVM, or we find a different way to convey the tag meaning to NMT (config files, or callbacks). That could even be opened up for customer use. This also touches on another question, that of NMT tag space. NMT tags are very useful since they allow cheap tracking without capturing call stacks. However, tags are underused and show growing pains since they are too one-dimensional and restrictive. We had competing interests in the past about tag granularity. It is all over the place. We have coarse-grained tags like "mtThread", and very fine-grained ones like "mtObjectMonitor". There are several ways we could improve, e.g., by making them combinable like UL does, or allowing for a hierarchy of them - either a hard-wired limited one like "domain"+"tag", or an unlimited tree-like one. Technically interesting since whatever the new encoding is, they still must fit into a malloc header. I opened https://bugs.openjdk.org/browse/JDK-8281819 to track ideas like these. Instrumenting Panama allocations, including the ability to tag allocations, would be a very good idea. For instance, if we ever remove the native Zlib layer and convert it to java using Panama, we can do the same with Panama I do now natively - use the Zlib zalloc interface to hook in JVM memory allocation functions. The result could be completely identical, and the end user looking at the NMT output need never know that anything changed. And that goes for all instrumentation - if today we add it to JNI code, and that code gets removed tomorrow, we can add it to Panama code too. Unless data structures move to the heap, in which case there is no need to track them. You mentioned that NMT was more of an in-house support tool. Our experience is different. Even though it was positioned as a tool for JVM developers, and we never cared for the backward compatibility or consistency, it gets used a *lot* by our customers. We have to explain its output frequently. Also, many blog articles exist documenting its use. So, maybe it would be okay to elevate it to a user-facing tool since it seems to occupy that role anyway. We may also open up consumption of NMT results via java APIs, or expose its results via MXBeans. If this is to be a JEP, okay, but I'm afraid it would stall things a bit. I am interested in getting a simpler and quicker solution for older support releases at least, possibly based on my PR. I know that would be unconventional though. Thank you, Thomas On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman wrote: > On 04/11/2022 16:54, Thomas St?fe wrote: > > Hi all, > > > > I am currently working on https://bugs.openjdk.org/browse/JDK-8296360; > > I was preparing the final PR [1], but then Alan did ask me to discuss > > this on core-libs first. > > > > Backstory: > > > > NMT tracks hotspot native allocations but does not cover the JDK > > libraries (small exception: Unsafe.AllocateMemory). However, the > > native memory footprint of JDK libraries can be significant. We have > > no in-VM tracker for these and need tools like valgrind or our > > SapMachine MallocTracer [2] to observe them. > > Thanks for starting a discussion on this as this is a topic that > requires agreement from several areas. If this is the start of something > bigger, where you want to have all allocation sites in the libraries > using NMT, then I think it needs a write-up, maybe a JEP. > > For starters, I think it needs some agreement on using NMT for memory > allocated outside of libjvm. You mentioned Unsafe as an exception but > that is implemented in the VM so you get tracking for free, albeit I > think all allocations are in the "mtOther" category. > > A general concern is that it creates more coupling between the VM code > and the libraries code. As you probably know, we've removed most of the > dependences on JVM_* functions from non-core areas over many years. So I > think that needs consideration as I assume we don't want > memory/allocation.hpp declaring a dozen catagories for allocations done > in say java.desktop module for example. Maybe your proposal will be > strictly limited to java.base but even then, do we really want the VM > even knowing about categories that are specific to zip compression or > decompression? > > There are probably longer term trends that should be part of the > discussion too. One general trend is that "run time" is becoming more > and more a hybrid of code in libvm and the Java libraries. Lambdas, > module system, virtual threads implementations are a few examples in the > last few release. This comes with many "Java on Java" challenges, > including serviceability where users of the platform will expect tools > to just work and won't care where the code is. NMT is probably more for > support teams and not something that most developers will ever use but I > think is part of the challenge of having serviceability solutions "just > work". > > In addition to having more of the Java runtime written in Java, there > will likely be less JNI code in the future. It's very possible that the > JNI code (including the JNI methods in libzip) will be replaced with > code that uses Panama memory and linker APIs once they are become > permanent. The effect of that would to have a lot of the memory > allocations be tracked in the mtOther category again. Maybe integration > with memory tracking should be looked at in conjunction with these APIs > and this migration. I could imagine the proposed "Arena" API > (MemorySession in Java 19) having some integration with NMT and it might > be interesting to look into that. > > So yes, this topic does need broader discussion and it might be a bit > premature to start with a PR for libzip without talking about the bigger > picture first. > > -Alan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rehn at openjdk.org Wed Nov 9 08:51:29 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 9 Nov 2022 08:51:29 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 14:34:45 GMT, Jorn Vernee wrote: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Looks good (-+ few nits), the errno capture feature seems handy, thanks! ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11019 From alanb at openjdk.org Wed Nov 9 09:02:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 9 Nov 2022 09:02:18 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 23:45:18 GMT, David Holmes wrote: > "in the custom class loader must append to the class path in a thread-safe manner." Maybe "its search path" rather than "the class path" because the custom class loader can't add to the class path (the application class path continues to be owned by the application class loader). ------------- PR: https://git.openjdk.org/jdk/pull/11023 From aturbanov at openjdk.org Wed Nov 9 09:02:27 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 9 Nov 2022 09:02:27 GMT Subject: Integrated: 8296140: Drop unused field java.util.Calendar.DATE_MASK In-Reply-To: References: Message-ID: <1HU0aCYgnpFc5x9vDE2Q4GrmHEfFWZuCtWW3Zk4Rumc=.7e1ee1e6-7e63-469b-add8-cbb0dbcea433@github.com> On Thu, 27 Oct 2022 19:07:36 GMT, Andrey Turbanov wrote: > There is no usages for this field. As it has the same value as `DAY_OF_MONTH_MASK` we can drop it. This pull request has now been integrated. Changeset: 82cbfb5f Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/82cbfb5fb0db61f3f1d9f0ceeed20c1cf5474652 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8296140: Drop unused field java.util.Calendar.DATE_MASK Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/10888 From alanb at openjdk.org Wed Nov 9 09:20:35 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 9 Nov 2022 09:20:35 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 22:12:46 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo src/java.base/share/classes/java/lang/foreign/Arena.java line 131: > 129: * @param thread the thread to be tested. > 130: */ > 131: boolean isOwnedBy(Thread thread); A shared Arena can be closed by any thread. Should a shared Arena be considered as being owned by all threads so that this method always returns true for a non-null thread? In the old API, a shared memory session has no owner so it was a bit clearer. I think my comment is mostly about the method name being about ownership, whereas the javadoc is about who can close. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From sspitsyn at openjdk.org Wed Nov 9 09:23:17 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Nov 2022 09:23:17 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Forgot a null check. src/hotspot/share/prims/jvmtiEnvBase.cpp line 564: > 562: > 563: for (int i=0; i 564: objArray[i] = JNIHandles::make_local(groups->obj_at(i)); Nit: Spaces are missed around '=' and '<' signs. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From sspitsyn at openjdk.org Wed Nov 9 09:38:41 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Nov 2022 09:38:41 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: Message-ID: <8IJbhIid1KAN_8xogA0fSvh0RIbYhzPBB5sMBVgQkBw=.ed314adf-1e6e-4ba8-a263-ede8118d4107@github.com> On Tue, 8 Nov 2022 14:55:17 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Forgot a null check. src/hotspot/share/prims/jvmtiEnvBase.cpp line 557: > 555: JvmtiEnvBase::new_jthreadGroupArray(int length, objArrayHandle groups) { > 556: if (length == 0) { > 557: return NULL; I do not think returning NULL is allowed for JVMTI `GetThreadGroupChildren()`. Please, see: [GetThreadGroupChildren](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html#GetThreadGroupChildren) ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Wed Nov 9 09:51:37 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 9 Nov 2022 09:51:37 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: <8IJbhIid1KAN_8xogA0fSvh0RIbYhzPBB5sMBVgQkBw=.ed314adf-1e6e-4ba8-a263-ede8118d4107@github.com> References: <8IJbhIid1KAN_8xogA0fSvh0RIbYhzPBB5sMBVgQkBw=.ed314adf-1e6e-4ba8-a263-ede8118d4107@github.com> Message-ID: On Wed, 9 Nov 2022 09:32:42 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Forgot a null check. > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 557: > >> 555: JvmtiEnvBase::new_jthreadGroupArray(int length, objArrayHandle groups) { >> 556: if (length == 0) { >> 557: return NULL; > > I do not think returning NULL is allowed for JVMTI `GetThreadGroupChildren()`. > Please, see: [GetThreadGroupChildren](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html#GetThreadGroupChildren) I don't think this has changed. Right now, if there are no child subgroups then *group_count_ptr will be 0 and *groups_ptr will be NULL as there is no memory to deallocate. JVMTI Deallocate is specified to do nothing when called with NULL. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From sspitsyn at openjdk.org Wed Nov 9 10:03:34 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Nov 2022 10:03:34 GMT Subject: RFR: JDK-8293450 Convert test/sun/management/ shell tests to Java version [v2] In-Reply-To: References: Message-ID: <5KO0PHIMbjYP5ScIoj_NHc2QpaW5pWSdM-zUuk6gcVA=.a0d52fdf-94fb-4cc7-b30a-30c5d6642256@github.com> On Tue, 8 Nov 2022 18:20:34 GMT, Bill Huang wrote: >> There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments. Thank you for the update. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11029 From asotona at openjdk.org Wed Nov 9 10:20:23 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 9 Nov 2022 10:20:23 GMT Subject: RFR: 8296196: `Class.getEnumConstants()` throws undocumented `ClassCastException` and `NullPointerException` Message-ID: When `Class.getEnumConstants()` is called on a bad enum class where `values()` is an instance method, or returns a non?array, then it throws `NullPointerException` or `ClassCastException` respectively. This patch fixes `Class.getEnumConstants()` method to handle above mentioned bad enums and adds relevant tests. Please review. Thanks, Adam ------------- Commit messages: - 8296196: Class.getEnumConstants() throws undocumented ClassCastException and NullPointerException Changes: https://git.openjdk.org/jdk/pull/11056/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11056&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296196 Stats: 119 lines in 4 files changed: 118 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11056.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11056/head:pull/11056 PR: https://git.openjdk.org/jdk/pull/11056 From mcimadamore at openjdk.org Wed Nov 9 11:00:33 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 9 Nov 2022 11:00:33 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v14] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 09:16:49 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo > > src/java.base/share/classes/java/lang/foreign/Arena.java line 131: > >> 129: * @param thread the thread to be tested. >> 130: */ >> 131: boolean isOwnedBy(Thread thread); > > A shared Arena can be closed by any thread. Should a shared Arena be considered as being owned by all threads so that this method always returns true for a non-null thread? In the old API, a shared memory session has no owner so it was a bit clearer. I think my comment is mostly about the method name being about ownership, whereas the javadoc is about who can close. Very good point - all threads are owners. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From coffeys at openjdk.org Wed Nov 9 11:22:21 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Wed, 9 Nov 2022 11:22:21 GMT Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> Message-ID: On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin wrote: > Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool. > > Testing: > test/jdk/jdk/jfr > test/jdk/jdk/security/logging/ > > Thanks > Erik Marked as reviewed by coffeys (Reviewer). LGTM ------------- PR: https://git.openjdk.org/jdk/pull/11039 From mcimadamore at openjdk.org Wed Nov 9 11:42:47 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 9 Nov 2022 11:42:47 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v15] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Rename isOwnedBy -> isCloseableBy Fix minor typos Fix StrLenTest/RingAllocator ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/df29e6a0..2d75f954 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=13-14 Stats: 11 lines in 3 files changed: 2 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From sspitsyn at openjdk.org Wed Nov 9 11:58:32 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 9 Nov 2022 11:58:32 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: <8IJbhIid1KAN_8xogA0fSvh0RIbYhzPBB5sMBVgQkBw=.ed314adf-1e6e-4ba8-a263-ede8118d4107@github.com> Message-ID: On Wed, 9 Nov 2022 09:49:10 GMT, Alan Bateman wrote: >> src/hotspot/share/prims/jvmtiEnvBase.cpp line 557: >> >>> 555: JvmtiEnvBase::new_jthreadGroupArray(int length, objArrayHandle groups) { >>> 556: if (length == 0) { >>> 557: return NULL; >> >> I do not think returning NULL is allowed for JVMTI `GetThreadGroupChildren()`. >> Please, see: [GetThreadGroupChildren](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html#GetThreadGroupChildren) > > I don't think this has changed. Right now, if there are no child subgroups then *group_count_ptr will be 0 and *groups_ptr will be NULL as there is no memory to deallocate. JVMTI Deallocate is specified to do nothing when called with NULL. Alan, you are right. This check existed before. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Wed Nov 9 12:05:35 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 9 Nov 2022 12:05:35 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v14] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 22:12:46 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo src/java.base/share/classes/java/lang/foreign/Arena.java line 125: > 123: */ > 124: @Override > 125: void close(); I'm trying to understand how close interacts with whileAlive on its memory session. Does close throw or block when there is a critical action running? The javadoc doesn't say right now. src/java.base/share/classes/java/lang/foreign/MemorySession.java line 43: > 41: *

      > 42: * Conversely, a bounded memory session has a start and an end. Bounded memory sessions can be managed either > 43: * explicitly, (i.e. using an {@linkplain Arena arena}) or implicitly, by the garbage collector. When a bounded memory A minor style thing here is that this should probably be "using an {@link Arena}" as you really mean the Arena. This helps a bit with the generate docs as it shows up currently as "arenaPREVIEW", if you see what I mean. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From kevinw at openjdk.org Wed Nov 9 12:41:01 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 9 Nov 2022 12:41:01 GMT Subject: RFR: JDK-8293450 Convert test/sun/management/ shell tests to Java version [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 18:20:34 GMT, Bill Huang wrote: >> There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments. Looks ok! 8-) ------------- Marked as reviewed by kevinw (Committer). PR: https://git.openjdk.org/jdk/pull/11029 From mcimadamore at openjdk.org Wed Nov 9 12:57:00 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 9 Nov 2022 12:57:00 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v16] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with four additional commits since the last revision: - Merge pull request #15 from minborg/test Add @apiNote to package-info - Add @apiNote to package-info - Merge pull request #16 from minborg/fix-tests2 Fix failing tests - Fix failing tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/2d75f954..39521344 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=14-15 Stats: 11 lines in 3 files changed: 4 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mgronlun at openjdk.org Wed Nov 9 13:21:35 2022 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 9 Nov 2022 13:21:35 GMT Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> Message-ID: On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin wrote: > Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool. > > Testing: > test/jdk/jdk/jfr > test/jdk/jdk/security/logging/ > > Thanks > Erik Marked as reviewed by mgronlun (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11039 From mcimadamore at openjdk.org Wed Nov 9 13:24:54 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 9 Nov 2022 13:24:54 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v17] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak Arena::close javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/39521344..cd3fbe7c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=15-16 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From rgiulietti at openjdk.org Wed Nov 9 14:22:02 2022 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 9 Nov 2022 14:22:02 GMT Subject: RFR: 8296292: Document the default behavior of '$' in regular expressions correctly [v2] In-Reply-To: References: Message-ID: <9nlj-BBN31ZYZL3inJ4YcEz2hDxW1m-Xol_yee6taXw=.c2a0fe64-87de-4fe6-9059-1e8feb53499c@github.com> > A small spec change to match established behavior. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: 8296292: Document the default behavior of '$' in regular expressions correctly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11038/files - new: https://git.openjdk.org/jdk/pull/11038/files/ff1b13f5..f9c67656 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11038&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11038&range=00-01 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11038.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11038/head:pull/11038 PR: https://git.openjdk.org/jdk/pull/11038 From duke at openjdk.org Wed Nov 9 16:00:20 2022 From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Nov 2022 16:00:20 GMT Subject: RFR: 8293630: Simplify TreeMap.get() with Comparator.naturalOrder() [v4] In-Reply-To: References: Message-ID: On Mon, 17 Oct 2022 10:19:26 GMT, ?????? ??????? wrote: >> We can use `Comparator.naturalOrder()` for cases when a `TreeMap` instance is constructed without comparator. This allows to squash two branches in `TreeMap.get()` into one. >> >> P.S. I think the comment of `TreeMap.getEntryUsingComparator()` is outdated. Should we also change it? > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8293630: Inline natural() For the benchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 15, time = 2, timeUnit = TimeUnit.SECONDS) @Fork(10) @State(Scope.Thread) public class TreeMapGet { @Param({"10", "100", "1000", "10000"}) public int size; @Param({"true", "false"}) public boolean comparator; private TreeMap map; private Integer[] keys; @Setup(Level.Iteration) public void setUp() { map = comparator ? new TreeMap<>(Comparator.reverseOrder()) : new TreeMap<>(); keys = IntStream.range(0, size).boxed().toArray(Integer[]::new); Collections.reverse(Arrays.asList(keys)); for (Integer key : keys) { map.put(key, key); } } @Benchmark public void get(Blackhole bh) { var keys = this.keys; var map = this.map; for (Integer key : keys) { bh.consume(map.get(key)); } } } I got these results: baseline Benchmark (comparator) (size) Mode Cnt Score Error Units TreeMapGet.get true 10 avgt 150 69.170 ? 0.886 ns/op TreeMapGet.get true 100 avgt 150 1369.488 ? 36.312 ns/op TreeMapGet.get true 1000 avgt 150 31462.583 ? 261.650 ns/op TreeMapGet.get true 10000 avgt 150 490948.456 ? 3395.402 ns/op TreeMapGet.get false 10 avgt 150 69.625 ? 0.975 ns/op TreeMapGet.get false 100 avgt 150 1076.163 ? 30.976 ns/op TreeMapGet.get false 1000 avgt 150 36528.309 ? 140.245 ns/op TreeMapGet.get false 10000 avgt 150 422948.634 ? 976.892 ns/op patch Benchmark (comparator) (size) Mode Cnt Score Error Units TreeMapGet.get true 10 avgt 150 68.814 ? 1.221 ns/op TreeMapGet.get true 100 avgt 150 1280.799 ? 34.319 ns/op TreeMapGet.get true 1000 avgt 150 31530.447 ? 329.406 ns/op TreeMapGet.get true 10000 avgt 150 435109.171 ? 1807.717 ns/op TreeMapGet.get false 10 avgt 150 65.646 ? 0.124 ns/op TreeMapGet.get false 100 avgt 150 1083.535 ? 23.545 ns/op TreeMapGet.get false 1000 avgt 150 36299.345 ? 494.126 ns/op TreeMapGet.get false 10000 avgt 150 444266.085 ? 2315.616 ns/op For benchmark @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS) @Measurement(iterations = 15, time = 2, timeUnit = TimeUnit.SECONDS) @Fork(10) @State(Scope.Thread) public class TreeMapEntrySetStream { @Param({"10", "100", "1000", "10000"}) public int size; @Param({"true", "false"}) public boolean comparator; private TreeMap map; @Setup(Level.Iteration) public void setUp() { map = comparator ? new TreeMap<>(Comparator.reverseOrder()) : new TreeMap<>(); var keys = IntStream.range(0, size).boxed().toArray(Integer[]::new); Collections.reverse(Arrays.asList(keys)); for (Integer key : keys) { map.put(key, key); } } @Benchmark public void get(Blackhole bh) { var map = this.map; map.entrySet().stream().forEach(bh::consume); } } results are the following: baseline Benchmark (comparator) (size) Mode Cnt Score Error Units TreeMapEntrySetStream.get true 10 avgt 150 32.714 ? 0.117 ns/op TreeMapEntrySetStream.get true 100 avgt 150 271.825 ? 0.596 ns/op TreeMapEntrySetStream.get true 1000 avgt 150 3267.876 ? 42.650 ns/op TreeMapEntrySetStream.get true 10000 avgt 150 43207.384 ? 457.110 ns/op TreeMapEntrySetStream.get false 10 avgt 150 30.863 ? 0.071 ns/op TreeMapEntrySetStream.get false 100 avgt 150 259.394 ? 0.493 ns/op TreeMapEntrySetStream.get false 1000 avgt 150 3362.446 ? 44.108 ns/op TreeMapEntrySetStream.get false 10000 avgt 150 42190.313 ? 421.604 ns/op patch Benchmark (comparator) (size) Mode Cnt Score Error Units TreeMapEntrySetStream.get true 10 avgt 150 30.856 ? 0.112 ns/op TreeMapEntrySetStream.get true 100 avgt 150 270.719 ? 0.504 ns/op TreeMapEntrySetStream.get true 1000 avgt 150 3278.241 ? 41.304 ns/op TreeMapEntrySetStream.get true 10000 avgt 150 42549.518 ? 427.607 ns/op TreeMapEntrySetStream.get false 10 avgt 150 31.780 ? 0.092 ns/op TreeMapEntrySetStream.get false 100 avgt 150 252.551 ? 0.414 ns/op TreeMapEntrySetStream.get false 1000 avgt 150 3359.962 ? 44.337 ns/op TreeMapEntrySetStream.get false 10000 avgt 150 41613.570 ? 381.721 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/9901 From mullan at openjdk.org Wed Nov 9 17:01:32 2022 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 9 Nov 2022 17:01:32 GMT Subject: RFR: 8296611: Problemlist several sun/security and java/security tests until JDK-8295343 is resolved In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov wrote: > Trivial change, updated jdk problem list. The `java/security/cert/pkix/policyChanges/TestPolicy.java` and `java/security/cert/CertPathBuilder/targetConstraints/BuildEEBasicConstraints.java` test failures are already fixed. There is no need to ProblemList them. ------------- PR: https://git.openjdk.org/jdk/pull/11045 From mseledtsov at openjdk.org Wed Nov 9 17:36:12 2022 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 9 Nov 2022 17:36:12 GMT Subject: RFR: 8296611: Problemlist several sun/security and java/security tests until JDK-8295343 is resolved [v2] In-Reply-To: References: Message-ID: > Trivial change, updated jdk problem list. Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: Addressed review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11045/files - new: https://git.openjdk.org/jdk/pull/11045/files/8834f40e..54faacf5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11045&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11045&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11045.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11045/head:pull/11045 PR: https://git.openjdk.org/jdk/pull/11045 From mseledtsov at openjdk.org Wed Nov 9 17:36:14 2022 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 9 Nov 2022 17:36:14 GMT Subject: RFR: 8296611: Problemlist several sun/security and java/security tests until JDK-8295343 is resolved In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov wrote: > Trivial change, updated jdk problem list. Thanks Sean. I will remove the fixed tests from the list. ------------- PR: https://git.openjdk.org/jdk/pull/11045 From bhuang at openjdk.org Wed Nov 9 18:12:39 2022 From: bhuang at openjdk.org (Bill Huang) Date: Wed, 9 Nov 2022 18:12:39 GMT Subject: RFR: JDK-8293450 Convert test/sun/management/ shell tests to Java version [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 18:20:34 GMT, Bill Huang wrote: >> There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments. It seems there is an integration issue with this PR as the JBS ticket is marked as confidential. I will open a new ticket for this change. ------------- PR: https://git.openjdk.org/jdk/pull/11029 From jvernee at openjdk.org Wed Nov 9 18:16:59 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 9 Nov 2022 18:16:59 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v2] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - Work around x86 failures - Review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/a40080e6..9e13922d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=00-01 Stats: 19 lines in 8 files changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From bpb at openjdk.org Wed Nov 9 18:39:33 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 9 Nov 2022 18:39:33 GMT Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" [v3] In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 20:50:15 GMT, Brian Burkhalter wrote: >> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - 8291911: Minor formatting cleanup in test > - Merge > - 8291911: work in progress > - 8291911: Account for quotas on Windows. > - 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" Ping. ------------- PR: https://git.openjdk.org/jdk/pull/9856 From bhuang at openjdk.org Wed Nov 9 19:05:40 2022 From: bhuang at openjdk.org (Bill Huang) Date: Wed, 9 Nov 2022 19:05:40 GMT Subject: Integrated: 8296718: Refactor bootstrap Test Common Functionalities to test/lib/Utils In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 19:23:05 GMT, Bill Huang wrote: > There is no new changes in the open portion of JDK, but extracting common functionalities in bootstrap Utils to test/lib/Utils which can be used in the closed part. This pull request has now been integrated. Changeset: cc8bf950 Author: Bill Huang URL: https://git.openjdk.org/jdk/commit/cc8bf95046d1fba0f88b0e17481f36b2be870659 Stats: 473 lines in 4 files changed: 236 ins; 234 del; 3 mod 8296718: Refactor bootstrap Test Common Functionalities to test/lib/Utils Reviewed-by: sspitsyn, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/11029 From naoto at openjdk.org Wed Nov 9 19:29:08 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 9 Nov 2022 19:29:08 GMT Subject: RFR: 8296715: CLDR v42 update for tzdata 2022f Message-ID: Pick up the fix in the upstream CLDR v42 maintenance branch for their tzdata2022f changes. ------------- Commit messages: - 8296715: CLDR v42 update for tzdata 2022f Changes: https://git.openjdk.org/jdk/pull/11066/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11066&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296715 Stats: 16 lines in 6 files changed: 6 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11066.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11066/head:pull/11066 PR: https://git.openjdk.org/jdk/pull/11066 From almatvee at openjdk.org Wed Nov 9 20:09:33 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 9 Nov 2022 20:09:33 GMT Subject: RFR: 8296156: [macos] Resize DMG windows and background to fit additional DMG contents Message-ID: Additional DMG content will be arranged in raws with 3 items per raw. DMG windows will be resized to show one or two raws without any scrolling required. To see any additional content after two raws (7 or more items) user will need to use vertical scroll bar. See JBS for screen shots. ------------- Commit messages: - 8296156: [macos] Resize DMG windows and background to fit additional DMG contents Changes: https://git.openjdk.org/jdk/pull/11068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11068&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296156 Stats: 28 lines in 1 file changed: 25 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11068.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11068/head:pull/11068 PR: https://git.openjdk.org/jdk/pull/11068 From duke at openjdk.org Wed Nov 9 21:06:50 2022 From: duke at openjdk.org (iaroslavski) Date: Wed, 9 Nov 2022 21:06:50 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v18] In-Reply-To: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: > Sorting: > > - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) > - fix tryMergeRuns() to better handle case when the last run is a single element > - minor javadoc and comment changes > > Testing: > - add new data inputs in tests for sorting > - add min/max/infinity values to float/double testing > - add tests for radix sort iaroslavski has updated the pull request incrementally with one additional commit since the last revision: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) * Fixed microbenchmarking tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/3938/files - new: https://git.openjdk.org/jdk/pull/3938/files/4772617d..203610a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=3938&range=16-17 Stats: 7 lines in 2 files changed: 2 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.org/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.org/jdk/pull/3938 From jlaskey at openjdk.org Wed Nov 9 21:07:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 21:07:48 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> Message-ID: <0Ob9mnmmVia6pC-tdUTgDZRtj9ix9SRnv4UCKbtB3OE=.5c48122a-ef5a-443a-aa6c-c410e66bce0b@github.com> On Fri, 28 Oct 2022 19:38:28 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 32: >> >>> 30: >>> 31: import java.io.IOException; >>> 32: import java.util.*; >> >> Please do not use import *. > > Changing. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From rriggs at openjdk.org Wed Nov 9 21:13:33 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 9 Nov 2022 21:13:33 GMT Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" [v3] In-Reply-To: References: Message-ID: On Tue, 11 Oct 2022 20:50:15 GMT, Brian Burkhalter wrote: >> On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`. > > Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - 8291911: Minor formatting cleanup in test > - Merge > - 8291911: work in progress > - 8291911: Account for quotas on Windows. > - 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" Looks fine. test/jdk/java/io/File/GetXSpace.java line 140: > 138: StringBuilder sb = new StringBuilder(); > 139: Process p = Runtime.getRuntime().exec(cmd); > 140: try (BufferedReader in = new BufferedReader(new InputStreamReader(p.getInputStream()))) { The RHS could be replaced by `p.inputReader()`. (new in JDK 17) ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/9856 From jlaskey at openjdk.org Wed Nov 9 21:16:38 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 21:16:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> Message-ID: On Fri, 28 Oct 2022 19:38:26 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 36: >> >>> 34: import java.lang.invoke.MethodHandles.Lookup; >>> 35: import java.lang.template.StringTemplate; >>> 36: import java.util.*; >> >> Another import * here > > Changing Raw list? >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 175: >> >>> 173: * method {@code processor.process(this)}. >>> 174: */ >>> 175: default R process(ValidatingProcessor processor) throws E { >> >> signature should be `ValidatingProcessor processor` > > Changing Raw list? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 21:16:40 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 21:16:40 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <_-1mK6x3NfAxQ17jGwVjcyi1ViF1Fe5NNHgKM-JCPk0=.d7c83d2b-96cc-4ef4-b4d6-24580d17d601@github.com> Message-ID: On Tue, 1 Nov 2022 19:06:57 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/TemplateRuntime.java line 99: >> >>> 97: private static List toList(E... elements) { >>> 98: return JUCA.listFromTrustedArrayNullsAllowed(elements); >>> 99: } >> >> I'm ok with using JUCA to create an unmodifiable list that can contain nulls. >> >> However, it "trusts" the argument array, meaning that the array is assumed to be referenced exclusively and so the array reference is used directly in the resulting List object. That implies that one needs to be very careful about the array that gets passed in, otherwise, the resulting List might not actually be unmodifiable. >> >> In particular, the call site in StringTemplate.of() >> >> https://github.com/openjdk/jdk/pull/10889/files#diff-d4e02e5ead5ad4f2cfe509c58d1145f599285cd6736bbf37e4116045b2fd50bcR309 >> >> passes the array obtained from a List parameter that comes directly from a public call, meaning that malicious code could keep a reference to the array returned by `toArray` and modify it later. You could clone the array, or just revert back to the slow path. > > Changing caller Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 21:16:40 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 21:16:40 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> Message-ID: On Thu, 3 Nov 2022 14:48:25 GMT, Jim Laskey wrote: >> i agree > > I agree. Need a balance of performance and #classes. Just something I'll work on during preview. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From darcy at openjdk.org Wed Nov 9 21:38:32 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 9 Nov 2022 21:38:32 GMT Subject: RFR: 8296196: `Class.getEnumConstants()` throws undocumented `ClassCastException` and `NullPointerException` In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:14:45 GMT, Adam Sotona wrote: > When `Class.getEnumConstants()` is called on a bad enum class where `values()` is an instance method, or returns a non?array, then it throws `NullPointerException` or `ClassCastException` respectively. > > This patch fixes `Class.getEnumConstants()` method to handle above mentioned bad enums and adds relevant tests. > > Please review. > > Thanks, > Adam Looks fine. It is fine to use an old class file version, but I think using a new one would be fine too. I don't know if using junit here pulls its weight. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/11056 From forax at openjdk.org Wed Nov 9 21:52:50 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 9 Nov 2022 21:52:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v3] In-Reply-To: References: <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com> Message-ID: On Wed, 9 Nov 2022 21:12:46 GMT, Jim Laskey wrote: >> Changing > > Raw list? I think this comment is not on the right part of the code. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 21:52:49 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 21:52:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v7] In-Reply-To: References: <_TUVrnWDpndw6v_dOzXNTVj8jwOkLyD-_Du9SEk99NQ=.44f8c669-4b67-43f4-8e66-c801d74f8ed7@github.com> <7gRnjkEThVOsx6TKM_fDo-Fy-iFJ2P8EiBa_3QZmN60=.dfc1a522-d536-428b-a5bf-6141e665a827@github.com> Message-ID: On Wed, 2 Nov 2022 17:41:57 GMT, Jorn Vernee wrote: >> It is also a duplicate of a private method in TemplateRuntime > > Yes, this is leaking access. I suppose this is public because it is called from `javac` generated code. But, from the perspective of the runtime, code generated by `javac` is the same as any other arbitrary non-trusted bytecode. Reasonable. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From forax at openjdk.org Wed Nov 9 21:57:53 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Wed, 9 Nov 2022 21:57:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Sat, 5 Nov 2022 22:23:23 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize FormatConcatItem > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 276: > >> 274: * @implNote Contents of both lists are copied to construct immutable lists. >> 275: */ >> 276: public static StringTemplate of(List fragments, List values) { > > Should be `StringTemplate of(List fragments, List values) {` > > The call to List.copyOf() will change the List to List. > raw List ? oops, formatting issue. The idea is that `values` can be typed `List` because the call to List.copyOf() will take the `List` and return a `List`. And as a type of a parameter `List` is better than `List` because `List` is a subtype of `List` but not a subtype of `List`. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 22:13:43 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 22:13:43 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 21:55:24 GMT, R?mi Forax wrote: >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 276: >> >>> 274: * @implNote Contents of both lists are copied to construct immutable lists. >>> 275: */ >>> 276: public static StringTemplate of(List fragments, List values) { >> >> Should be `StringTemplate of(List fragments, List values) {` >> >> The call to List.copyOf() will change the List to List. > >> raw List ? > > oops, formatting issue. > > The idea is that `values` can be typed `List` because the call to List.copyOf() will take the `List` and return a `List`. > > And as a type of a parameter `List` is better than `List` because `List` is a subtype of `List` but not a subtype of `List`. Got you. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mseledtsov at openjdk.org Wed Nov 9 22:44:49 2022 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 9 Nov 2022 22:44:49 GMT Subject: RFR: 8296611: Problemlist several sun/security and java/security tests until JDK-8295343 is resolved [v2] In-Reply-To: References: Message-ID: <4u_8wPYcvjfXfUVTloEz4ZXev1APLsQ4db4uSIP2Lpk=.c1583cb8-eefc-4e22-a562-6a790d5eee20@github.com> On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov wrote: >> Trivial change, updated jdk problem list. > > Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review feedback I have updated the problem list to exclude fixed tests. Please review when you have a chance. ------------- PR: https://git.openjdk.org/jdk/pull/11045 From jlaskey at openjdk.org Wed Nov 9 22:48:47 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 22:48:47 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Sat, 5 Nov 2022 22:23:56 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize FormatConcatItem > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 299: > >> 297: * @throws NullPointerException fragments or values is null or if any of the fragments is null >> 298: */ >> 299: public static String interpolate(List fragments, List values) { > > Should be `String interpolate(List fragments, List values) {` as above Changing > src/java.base/share/classes/java/lang/template/StringTemplate.java line 305: > >> 303: int valuesSize = values.size(); >> 304: if (fragmentsSize != valuesSize + 1) { >> 305: throw new RuntimeException("fragments must have one more element than values"); > > Should be IllegalArgumentException (see method of() above) Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 22:48:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 22:48:48 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 13:28:18 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize FormatConcatItem > > src/java.base/share/classes/java/util/FormatItem.java line 75: > >> 73: try { >> 74: return (long)CHAR_MIX.invokeExact(lengthCoder, value); >> 75: } catch (RuntimeException ex) { > > This?should also?rethrow `Error`?instances: > Suggestion: > > } catch (Error | RuntimeException ex) { Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 22:48:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 22:48:48 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 22:14:29 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize FormatConcatItem > > src/java.base/share/classes/java/util/FormatProcessor.java line 38: > >> 36: >> 37: /** >> 38: * This {@linkplain ValidatingProcessor yemplate processor} constructs a String > > Typo: "yemplate processor". Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 22:55:44 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 22:55:44 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Sun, 6 Nov 2022 22:15:22 GMT, Joe Darcy wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize FormatConcatItem > > src/java.base/share/classes/java/util/FormatProcessor.java line 56: > >> 54: * to produce a more performant formatter. >> 55: * >> 56: * @implSpec Since, values are in situ, argument indexing is unsupported. > > Please avoid Latin phrases like "in situ" in the javadoc. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From joehw at openjdk.org Wed Nov 9 23:11:28 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 9 Nov 2022 23:11:28 GMT Subject: RFR: 8296715: CLDR v42 update for tzdata 2022f In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 18:58:30 GMT, Naoto Sato wrote: > Pick up the fix in the upstream CLDR v42 maintenance branch for their tzdata2022f changes. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11066 From jlaskey at openjdk.org Wed Nov 9 23:26:39 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 23:26:39 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: <8rt4_oTHk-TqYvpbPDO4WzPGYHZroDXlbc2vbgCCKV0=.2ba76eb3-6c46-4d91-9262-7293da6168a2@github.com> On Wed, 9 Nov 2022 22:42:29 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 299: >> >>> 297: * @throws NullPointerException fragments or values is null or if any of the fragments is null >>> 298: */ >>> 299: public static String interpolate(List fragments, List values) { >> >> Should be `String interpolate(List fragments, List values) {` as above > > Changing Have to backtrack short term. This change forces StringTemplate.values() to return List. Will have to think this through (affects the JLS et al) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 23:41:41 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 23:41:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v14] In-Reply-To: References: Message-ID: <6ixtWOJLlNS7SlOF1HOKzGE_O2prcZht_OO5koFX5TA=.a2efe47f-a381-4a26-864a-4f6a4d1e71db@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 28 additional commits since the last revision: - Merge branch 'master' into 8285932 - Internalize FormatConcatItem - Requested changes #5 - Internalize TemplateSupport - Requested changes #4 - Requested changes #3 - Merge branch 'master' into 8285932 - Add @SafeVarargs declarations - Move template bootstrap - Requested changes #2 - ... and 18 more: https://git.openjdk.org/jdk/compare/d0a14fab...c8412eb5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/b35ed665..c8412eb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=12-13 Stats: 44455 lines in 484 files changed: 8506 ins; 33629 del; 2320 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From rhalade at openjdk.org Wed Nov 9 23:48:36 2022 From: rhalade at openjdk.org (Rajan Halade) Date: Wed, 9 Nov 2022 23:48:36 GMT Subject: RFR: 8296611: Problemlist several sun/security and java/security tests until JDK-8295343 is resolved [v2] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov wrote: >> Trivial change, updated jdk problem list. > > Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review feedback Please update the PR commit message in summary. I updated JBS bug summary to indicate only sun/security tests failed. ------------- PR: https://git.openjdk.org/jdk/pull/11045 From jlaskey at openjdk.org Wed Nov 9 23:48:57 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 23:48:57 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v15] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Switch from anonymous classes to carrier based StringTemplate implementation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/c8412eb5..1af7dc15 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=13-14 Stats: 3438 lines in 30 files changed: 2670 ins; 688 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 9 23:49:01 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 9 Nov 2022 23:49:01 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 18:12:39 GMT, Naoto Sato wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Internalize FormatConcatItem > > src/java.base/share/classes/java/util/FormatItem.java line 540: > >> 538: char ch = (char)getCharMH.invokeExact(buffer, start + i); >> 539: putCharMH.invokeExact(buffer, start + i, (int)Character.toUpperCase(ch)); >> 540: } > > Some characters may produce multiple uppercase characters, such as "fi" ligature ('\ufb01' -> "FI"), also this should consider locale, e.g. the case for Turkish dotless i. Switch to Formatter if upper selected ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 10 00:04:49 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 10 Nov 2022 00:04:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v15] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 23:48:57 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Switch from anonymous classes to carrier based StringTemplate implementation Interesting few days. Several reviewers have asked that I don't use anonymous classes to implement string templates; concern about producing lots of little classes. I dusted off the carrier code that I abandoned as non-performant and came up with an idea to make carriers faster (remove a level of indirection). The result is we can now use carriers for compiler generated string templates which can interpolate as fast as the anonymous classes and string concatenation. Now there is only two classes representing compiler generated string templates; one carrier based and one generic array based used when the number of values exceed method max arg count. Along with this change is some significant clean up of the organization; more in line with other systems in the JDK. Most of the files related to templates are now in java.lang.template (moved from jdk.internal). java.lang.template.TemplateSupport containing the template bootstrap methods is renamed to TemplateRuntime and moved to java.lang.runtime along with the other java.lang bootstrap classes. java.lang.template.TemplateRuntime is renamed to TemplateSupport to be more in line with what it represents. Three new files, java.lang.template.Carriers, java.lang.template.ReferencedKeyMap and java.lang.template.ReferenceKey, have been added to support carriers. I've integrated almost all your recommendations. Thank you for your reviews. Keep them coming. I hope this is the last major change required before preview. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From rhalade at openjdk.org Thu Nov 10 00:10:29 2022 From: rhalade at openjdk.org (Rajan Halade) Date: Thu, 10 Nov 2022 00:10:29 GMT Subject: RFR: 8296611: Problemlist several sun/security tests until JDK-8295343 is resolved [v2] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov wrote: >> Trivial change, updated jdk problem list. > > Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review feedback Marked as reviewed by rhalade (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11045 From bpb at openjdk.org Thu Nov 10 00:18:56 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 10 Nov 2022 00:18:56 GMT Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" [v4] In-Reply-To: References: Message-ID: > On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - 8291911: Use Process::inputReader - Merge - 8291911: Minor formatting cleanup in test - Merge - 8291911: work in progress - 8291911: Account for quotas on Windows. - 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/9856/files - new: https://git.openjdk.org/jdk/pull/9856/files/81296309..02556f26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=9856&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9856&range=02-03 Stats: 224292 lines in 2665 files changed: 115506 ins; 70879 del; 37907 mod Patch: https://git.openjdk.org/jdk/pull/9856.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9856/head:pull/9856 PR: https://git.openjdk.org/jdk/pull/9856 From bpb at openjdk.org Thu Nov 10 00:19:04 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 10 Nov 2022 00:19:04 GMT Subject: RFR: 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" [v3] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 21:09:30 GMT, Roger Riggs wrote: >> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - 8291911: Minor formatting cleanup in test >> - Merge >> - 8291911: work in progress >> - 8291911: Account for quotas on Windows. >> - 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" > > test/jdk/java/io/File/GetXSpace.java line 140: > >> 138: StringBuilder sb = new StringBuilder(); >> 139: Process p = Runtime.getRuntime().exec(cmd); >> 140: try (BufferedReader in = new BufferedReader(new InputStreamReader(p.getInputStream()))) { > > The RHS could be replaced by `p.inputReader()`. (new in JDK 17) So changed in 02556f265e1fc5274e73e8cfa75ce218c130112e. @RogerRiggs Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/9856 From mseledtsov at openjdk.org Thu Nov 10 00:44:31 2022 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Thu, 10 Nov 2022 00:44:31 GMT Subject: RFR: 8296611: Problemlist several sun/security tests until JDK-8295343 is resolved [v2] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 17:36:12 GMT, Mikhailo Seledtsov wrote: >> Trivial change, updated jdk problem list. > > Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision: > > Addressed review feedback Thank you Rajan. ------------- PR: https://git.openjdk.org/jdk/pull/11045 From mseledtsov at openjdk.org Thu Nov 10 00:48:29 2022 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Thu, 10 Nov 2022 00:48:29 GMT Subject: Integrated: 8296611: Problemlist several sun/security tests until JDK-8295343 is resolved In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 21:39:03 GMT, Mikhailo Seledtsov wrote: > Trivial change, updated jdk problem list. This pull request has now been integrated. Changeset: d6e2d0d0 Author: Mikhailo Seledtsov URL: https://git.openjdk.org/jdk/commit/d6e2d0d03d2161f934474fa1d4299513d14cb9c5 Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod 8296611: Problemlist several sun/security tests until JDK-8295343 is resolved Reviewed-by: rhalade ------------- PR: https://git.openjdk.org/jdk/pull/11045 From asemenyuk at openjdk.org Thu Nov 10 00:50:34 2022 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 10 Nov 2022 00:50:34 GMT Subject: RFR: 8296156: [macos] Resize DMG windows and background to fit additional DMG contents In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 20:02:05 GMT, Alexander Matveev wrote: > Additional DMG content will be arranged in raws with 3 items per raw. DMG windows will be resized to show one or two raws without any scrolling required. To see any additional content after two raws (7 or more items) user will need to use vertical scroll bar. See JBS for screen shots. Marked as reviewed by asemenyuk (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11068 From duke at openjdk.org Thu Nov 10 01:09:26 2022 From: duke at openjdk.org (pandaapo) Date: Thu, 10 Nov 2022 01:09:26 GMT Subject: RFR: 8296734: JarVerifier:: mapSignersToCodeSource should cache in map Message-ID: The cache named `signerToCodeSource` is never used now. ------------- Commit messages: - Make signerToCodeSource cache work. Changes: https://git.openjdk.org/jdk/pull/11072/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296734 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11072.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11072/head:pull/11072 PR: https://git.openjdk.org/jdk/pull/11072 From jjg at openjdk.org Thu Nov 10 01:21:09 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 01:21:09 GMT Subject: RFR: JDK-8296547: Add @spec tags to API Message-ID: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. "Normalized" means... * Use `https:` where possible (includes pretty much all cases) * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) * Point to the root page of a multi-page spec * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. ------------- Commit messages: - JDK-8296547: Add @spec tags to API Changes: https://git.openjdk.org/jdk/pull/11073/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296547 Stats: 816 lines in 420 files changed: 816 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From almatvee at openjdk.org Thu Nov 10 02:22:35 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 10 Nov 2022 02:22:35 GMT Subject: Integrated: 8296156: [macos] Resize DMG windows and background to fit additional DMG contents In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 20:02:05 GMT, Alexander Matveev wrote: > Additional DMG content will be arranged in raws with 3 items per raw. DMG windows will be resized to show one or two raws without any scrolling required. To see any additional content after two raws (7 or more items) user will need to use vertical scroll bar. See JBS for screen shots. This pull request has now been integrated. Changeset: 0981bfb1 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/0981bfb1a317466c095c392f82ddf6eae595f4af Stats: 28 lines in 1 file changed: 25 ins; 0 del; 3 mod 8296156: [macos] Resize DMG windows and background to fit additional DMG contents Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/11068 From asotona at openjdk.org Thu Nov 10 06:23:48 2022 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 10 Nov 2022 06:23:48 GMT Subject: Integrated: 8296196: Class.getEnumConstants() =?UTF-8?B?dGhyb3dzwqB1bmRvY3VtZW50ZWQ=?= ClassCastException =?UTF-8?B?YW5kwqBOdWxsUG9pbnRlckV4Y2VwdGlvbg==?= In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 10:14:45 GMT, Adam Sotona wrote: > When `Class.getEnumConstants()` is called on a bad enum class where `values()` is an instance method, or returns a non?array, then it throws `NullPointerException` or `ClassCastException` respectively. > > This patch fixes `Class.getEnumConstants()` method to handle above mentioned bad enums and adds relevant tests. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: e802b124 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/e802b124b7a363ca4cb56f8072b4dde5176ef96a Stats: 119 lines in 4 files changed: 118 ins; 0 del; 1 mod 8296196: Class.getEnumConstants() throws?undocumented ClassCastException and?NullPointerException Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/11056 From dfuchs at openjdk.org Thu Nov 10 11:34:25 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 10 Nov 2022 11:34:25 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Hi Jon, When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html) You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From alanb at openjdk.org Thu Nov 10 11:49:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Nov 2022 11:49:21 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote: > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example: http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html ------------- PR: https://git.openjdk.org/jdk/pull/11073 From alanb at openjdk.org Thu Nov 10 12:04:51 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 10 Nov 2022 12:04:51 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. I'm just trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same will spec linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped. In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication? There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jpai at openjdk.org Thu Nov 10 12:26:30 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 10 Nov 2022 12:26:30 GMT Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 [v2] In-Reply-To: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> References: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> Message-ID: On Tue, 8 Nov 2022 16:04:25 GMT, Roger Riggs wrote: >> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259. >> As described in the bug report, `waitFor()` should not be sensitive to the exit value. >> Previously, it erroneously threw IllegalStateException. >> Added a test to verify. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Test cleanup as suggested by review comments. Thank you Roger for the reference to that paragraph in the documentation. I had read that page previously but I think I overlooked that section. Also thank you for the detail about the thread interrupt handling. What you state makes sense. ------------- PR: https://git.openjdk.org/jdk/pull/10680 From jpai at openjdk.org Thu Nov 10 12:35:24 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 10 Nov 2022 12:35:24 GMT Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 [v2] In-Reply-To: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> References: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> Message-ID: On Tue, 8 Nov 2022 16:04:25 GMT, Roger Riggs wrote: >> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259. >> As described in the bug report, `waitFor()` should not be sensitive to the exit value. >> Previously, it erroneously threw IllegalStateException. >> Added a test to verify. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Test cleanup as suggested by review comments. One final question - Now with this change, `Process.waitFor()` won't throw the `IllegalThreadStateException` for such programs that return `STILL_ACTIVE` exit code. However, looking at the code a subsequent Process.exitValue() call on that same process instance will still throw this exception. Should we be changing that too? ------------- PR: https://git.openjdk.org/jdk/pull/10680 From redestad at openjdk.org Thu Nov 10 14:54:45 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 10 Nov 2022 14:54:45 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v10] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - Final touch-ups, restored 2-stride with dependency chain breakage - Minor cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/853a7575..af197062 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=08-09 Stats: 182 lines in 8 files changed: 43 ins; 74 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Thu Nov 10 14:54:48 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 10 Nov 2022 14:54:48 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v9] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 02:35:24 GMT, David Schlosnagle wrote: >> Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits: >> >> - Revert accidental ModuleHashes change >> - Merge branch 'master' into 8282664-polyhash >> - Merge pull request #2 from luhenry/dev/cl4es/8282664-polyhash >> >> Unroll + Reorder BBs >> - fixup! Handle size=0 and size=1 in Java >> - Handle size=0 and size=1 in Java >> - reorder BB to do single scalar first to avoid slowdown of short arrays, longer arrays jumps will be amortized by speedups >> - Unroll loop for cnt1 < 32 >> - Merge pull request #1 from luhenry/dev/cl4es/8282664-polyhash >> >> Switch to forward approach for vectorization >> - Fix vector loop >> - fix indexing >> - ... and 45 more: https://git.openjdk.org/jdk/compare/dd5d4df5...853a7575 > > src/hotspot/share/opto/matcher.cpp line 1707: > >> 1705: if (x >= _LAST_MACH_OPER) { >> 1706: fprintf(stderr, "x = %d, _LAST_MACH_OPER = %d\n", x, _LAST_MACH_OPER); >> 1707: fprintf(stderr, "dump n\n"); > > Should this be removed before merging? > Suggestion: Yes, fixed these in the latest version. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Thu Nov 10 14:57:53 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 10 Nov 2022 14:57:53 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v11] In-Reply-To: References: Message-ID: <2bXXJpyuGGH_dyzzfxu4cN3NFGmwjgjcCxz2mUONkc0=.81046071-5562-4e7e-bf2f-fbfd1076258c@github.com> > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/af197062..2522625c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Thu Nov 10 15:03:26 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 10 Nov 2022 15:03:26 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v12] In-Reply-To: References: Message-ID: <4DATzQcc3E5BBS0xrbxkKDyI64Lt-vpKvtgTGDh6Rew=.5bb45e2c-65bd-4c38-9a30-47feac3a32ca@github.com> > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Qualified guess on shenandoahSupport fix-up ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/2522625c..871f6cef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Thu Nov 10 15:07:14 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 10 Nov 2022 15:07:14 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Tue, 25 Oct 2022 16:03:28 GMT, Ludovic Henry wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > I did a quick write up explaining the approach at https://gist.github.com/luhenry/2fc408be6f906ef79aaf4115525b9d0c. Also, you can find details in @richardstartin's [blog post](https://richardstartin.github.io/posts/vectorised-polynomial-hash-codes) I've restored the 2-stride dependency-chain breaking implementation that got lost in translation when me and @luhenry took turns on this. This helps keep things fast in the 1-31 size range, and allows for a decent speed-up on `byte[]` and `short[]` cases until we can figure out how to vectorize those properly. @luhenry baseline: Benchmark (size) Mode Cnt Score Error Units StringHashCode.Algorithm.defaultLatin1 0 avgt 5 0.786 ? 0.005 ns/op StringHashCode.Algorithm.defaultLatin1 1 avgt 5 1.068 ? 0.005 ns/op StringHashCode.Algorithm.defaultLatin1 2 avgt 5 2.513 ? 0.017 ns/op StringHashCode.Algorithm.defaultLatin1 31 avgt 5 22.837 ? 0.082 ns/op StringHashCode.Algorithm.defaultLatin1 32 avgt 5 16.622 ? 0.107 ns/op StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1193.884 ? 1.862 ns/op StringHashCode.Algorithm.defaultUTF16 0 avgt 5 0.786 ? 0.002 ns/op StringHashCode.Algorithm.defaultUTF16 1 avgt 5 1.884 ? 0.002 ns/op StringHashCode.Algorithm.defaultUTF16 2 avgt 5 2.512 ? 0.011 ns/op StringHashCode.Algorithm.defaultUTF16 31 avgt 5 23.061 ? 0.119 ns/op StringHashCode.Algorithm.defaultUTF16 32 avgt 5 16.429 ? 0.044 ns/op StringHashCode.Algorithm.defaultUTF16 10000 avgt 5 1191.283 ? 4.600 ns/op Patch: Benchmark (size) Mode Cnt Score Error Units StringHashCode.Algorithm.defaultLatin1 0 avgt 5 0.787 ? 0.004 ns/op StringHashCode.Algorithm.defaultLatin1 1 avgt 5 1.050 ? 0.009 ns/op StringHashCode.Algorithm.defaultLatin1 2 avgt 5 2.198 ? 0.010 ns/op StringHashCode.Algorithm.defaultLatin1 31 avgt 5 18.413 ? 0.516 ns/op StringHashCode.Algorithm.defaultLatin1 32 avgt 5 16.599 ? 0.074 ns/op StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1189.958 ? 8.420 ns/op StringHashCode.Algorithm.defaultUTF16 0 avgt 5 0.785 ? 0.002 ns/op StringHashCode.Algorithm.defaultUTF16 1 avgt 5 1.885 ? 0.006 ns/op StringHashCode.Algorithm.defaultUTF16 2 avgt 5 2.219 ? 0.146 ns/op StringHashCode.Algorithm.defaultUTF16 31 avgt 5 19.052 ? 1.203 ns/op StringHashCode.Algorithm.defaultUTF16 32 avgt 5 16.558 ? 0.107 ns/op StringHashCode.Algorithm.defaultUTF16 10000 avgt 5 1188.122 ? 9.394 ns/op The switches @luhenry added to help the 0 and 1 cases marginally help the by allowing the compilation to do early returns in these cases, avoiding jumping around as would be necessary in the inlined intrinsic. It allowed me to simplify the previous attempt at a 2-element stride routine, while ensuring the routine is correct even if we'd call it directly without the switch preamble. I think this is ready for a final review now. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From jlaskey at openjdk.org Thu Nov 10 15:09:14 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 10 Nov 2022 15:09:14 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v16] In-Reply-To: References: Message-ID: <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clean up new StringTemplate creation Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List to List on StringTemplate.interpolate and StringTemplate.of. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/1af7dc15..39c63c01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=14-15 Stats: 189 lines in 6 files changed: 103 ins; 52 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 10 15:09:16 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 10 Nov 2022 15:09:16 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v13] In-Reply-To: <8rt4_oTHk-TqYvpbPDO4WzPGYHZroDXlbc2vbgCCKV0=.2ba76eb3-6c46-4d91-9262-7293da6168a2@github.com> References: <8rt4_oTHk-TqYvpbPDO4WzPGYHZroDXlbc2vbgCCKV0=.2ba76eb3-6c46-4d91-9262-7293da6168a2@github.com> Message-ID: <-EkZU7-ytGRcWsg3g5T9oCV1Kshru-Sjl-PZjRve1hI=.b902f3a2-71fc-42c4-8b90-1ddad398200b@github.com> On Wed, 9 Nov 2022 23:24:32 GMT, Jim Laskey wrote: >> Changing > > Have to backtrack short term. This change forces StringTemplate.values() to return List. Will have to think this through (affects the JLS et al) Worked this through for both StringTemplate.of and StringTemplate.interpolate ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Thu Nov 10 15:09:23 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 10 Nov 2022 15:09:23 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v2] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 18:16:59 GMT, Jorn Vernee wrote: >> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. >> >> This is split off from the main JEP integration to make reviewing easier. >> >> This includes the following patches: >> >> 1. https://github.com/openjdk/panama-foreign/pull/698 >> 2. https://github.com/openjdk/panama-foreign/pull/699 >> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 >> 4. https://github.com/openjdk/panama-foreign/pull/740 >> 5. https://github.com/openjdk/panama-foreign/pull/746 >> 6. https://github.com/openjdk/panama-foreign/pull/742 >> 7. https://github.com/openjdk/panama-foreign/pull/743 >> >> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. >> >> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. >> >> Please refer to the PR of each individual patch for a more detailed description. > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - Work around x86 failures > - Review comments Java changes look good - added few nits src/java.base/share/classes/java/lang/foreign/Linker.java line 319: > 317: * {@return A linker option used to save portions of the execution state immediately after > 318: * calling a foreign function associated with a downcall method handle, > 319: * before it can be overwritten by the runtime, or read through conventional means} Suggestion: * before it can be overwritten by the Java runtime, or read through conventional means} src/java.base/share/classes/java/lang/foreign/Linker.java line 340: > 338: * before it can be overwritten by the runtime, or read through conventional means. > 339: *

      > 340: * State is captured by a downcall method handle on invocation, by writing it Suggestion: * Execution state is captured by a downcall method handle on invocation, by writing it src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 188: > 186: } > 187: > 188: public int capturedStateMask() { Isn't this a final static during execution? src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 78: > 76: private static void checkType(MethodType methodType, boolean needsReturnBuffer, int savedValueMask) { > 77: if (methodType.parameterType(0) != long.class) { > 78: throw new IllegalArgumentException("Address expected as first param: " + methodType); Is throwing IAE correct here? E.g. can the user do anything about it, or does the exception describe more of an internal error? (In that case AssertionError might be better?) src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 83: > 81: if ((needsReturnBuffer && methodType.parameterType(checkIdx++) != long.class) > 82: || (savedValueMask != 0 && methodType.parameterType(checkIdx) != long.class)) { > 83: throw new IllegalArgumentException("return buffer and/or preserved value address expected: " + methodType); Same here src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 3: > 1: /* > 2: * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved. > 3: * Copyright (c) 2019, 2022, Arm Limited. All rights reserved. Not sure if all copyrights of all changed classes have been tweaked? This might be a more general problem with FFM API. test/jdk/ProblemList.txt line 484: > 482: # jdk_foreign > 483: > 484: java/foreign/callarranger/TestAarch64CallArranger.java generic-x86 Should we exclude these tests on 32 bits in the jtreg header (as I think we do for other tests) ? ------------- PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Thu Nov 10 15:28:20 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Nov 2022 15:28:20 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v3] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: Javadoc nits Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/9e13922d..eb38b596 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Thu Nov 10 15:28:25 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Nov 2022 15:28:25 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 14:59:20 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Work around x86 failures >> - Review comments > > src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequence.java line 188: > >> 186: } >> 187: >> 188: public int capturedStateMask() { > > Isn't this a final static during execution? It's fixed for a particular linkage request, but it can differ between them. (for instance, on Windows one downcall handle can save `errno` and another can save `GetLastError`) > src/java.base/share/classes/jdk/internal/foreign/abi/NativeEntryPoint.java line 78: > >> 76: private static void checkType(MethodType methodType, boolean needsReturnBuffer, int savedValueMask) { >> 77: if (methodType.parameterType(0) != long.class) { >> 78: throw new IllegalArgumentException("Address expected as first param: " + methodType); > > Is throwing IAE correct here? E.g. can the user do anything about it, or does the exception describe more of an internal error? (In that case AssertionError might be better?) Yes, it's an internal error. I can change the exception type > test/jdk/ProblemList.txt line 484: > >> 482: # jdk_foreign >> 483: >> 484: java/foreign/callarranger/TestAarch64CallArranger.java generic-x86 > > Should we exclude these tests on 32 bits in the jtreg header (as I think we do for other tests) ? I'm not sure what the conventional move here would be. Adding them to the problem list doesn't seem to make the failures go away in GHA at least. I can exclude them with `@requires` as well. ------------- PR: https://git.openjdk.org/jdk/pull/11019 From ckozak at ckozak.net Thu Nov 10 15:58:03 2022 From: ckozak at ckozak.net (Carter Kozak) Date: Thu, 10 Nov 2022 10:58:03 -0500 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: References: Message-ID: *+serviceability-dev* Firstly, thank you both for your time and work in this space. Apologies if this should be a separate thread, but the new title ?Extend Native Memory Tracking over the JDK? aligns directly with some work I?ve been investigating, and I hope my feedback will be helpful for prioritization of zlib observability as well as the way users think about native memory tracking in general. Observability of native memory in the JVM is critically important, and becomes even more valuable as the industry shifts to more and smaller services deployed in right-sized container environments like kubernetes. Each new JDK release (major and hotfix) offers dramatic improvements, often based on some form of trade-off. To be clear, I cannot overstate how impressed I am with quality and velocity of improvement! However, these trade-offs impact the way that memory is used, and it?s a difficult balance to ensure containers use the correct amount of memory without being wasteful (over-provisioned) or oomkilled (under-provisioned). In production, I have thousands of JVMs running with native memory tracking summary enabled. Real-time monitoring of the output is painful and inefficient. Currently the only supported option I?m aware of is shelling out to create a new jcmd process and parsing the NMT summary text output periodically. In older releases, it was possible to bypass the jcmd process by self-attaching, but that was limited in jdk9 by JDK-8178380 , and still required the caller to parse human-readable strings. In fact, attachment issues in some JDK/environment combinations make automated attachment *dangerous* in a way that has crashed the JVM ? that may be a story for another day, but my point is that simple, efficient NMT data collection would go a very long way. Many modern observability tools, especially those used in container deployments, operate by reading data from within the jvm process, and relaying it to a storage system (Prometheus may be the most ubiquitous example). For my use-case, I?d love to have a simple API I could invoke from java code to access structured native-memory-tracking data, similar in a way to MemoryPoolMXBean for heap pools (although JMX isn?t necessary for me, it aligns with other observability APIs in the JDK). Additionally, I?d like to provide JFR events to periodically record native memory tracking metadata when enabled for better out-of-the-box experience with JMC. I?ve begun investigating some options for JDK-8182634 , but would appreciate feedback before I propose any sort of code change. Thank you all for beginning this discussion, I?m eager to see the ways the JDK continues to improve upon observability features, and do what small part I can to help! Carter Kozak -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.org Thu Nov 10 16:24:26 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 10 Nov 2022 16:24:26 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. I see https://www.ietf.org/rfc/rfc0822.html. Should be https://www.ietf.org/rfc/rfc822.html ------------- PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Thu Nov 10 16:35:32 2022 From: duke at openjdk.org (AJ1062910) Date: Thu, 10 Nov 2022 16:35:32 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. did you changed 420 files ? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From forax at openjdk.org Thu Nov 10 16:47:00 2022 From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 10 Nov 2022 16:47:00 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v16] In-Reply-To: <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@github.com> References: <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@github.com> Message-ID: On Thu, 10 Nov 2022 15:09:14 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Clean up new StringTemplate creation > > Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List to List on StringTemplate.interpolate and StringTemplate.of. src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 36: > 34: import java.lang.template.StringTemplate; > 35: import java.lang.template.ValidatingProcessor; > 36: import java.util.*; They come back :) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Thu Nov 10 16:48:19 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Nov 2022 16:48:19 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v4] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision: - Tweak copyright headers - Use @requires to disable some tests on x86 - Use AssertionError for internal exceptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/eb38b596..7b1b95f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=02-03 Stats: 10 lines in 8 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Thu Nov 10 16:48:21 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Nov 2022 16:48:21 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 15:03:48 GMT, Maurizio Cimadamore wrote: >> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: >> >> - Work around x86 failures >> - Review comments > > src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 3: > >> 1: /* >> 2: * Copyright (c) 2020, 2022, Oracle and/or its affiliates. All rights reserved. >> 3: * Copyright (c) 2019, 2022, Arm Limited. All rights reserved. > > Not sure if all copyrights of all changed classes have been tweaked? This might be a more general problem with FFM API. I've updated them for all the changes in this PR ------------- PR: https://git.openjdk.org/jdk/pull/11019 From naoto at openjdk.org Thu Nov 10 16:54:41 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 10 Nov 2022 16:54:41 GMT Subject: Integrated: 8296715: CLDR v42 update for tzdata 2022f In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 18:58:30 GMT, Naoto Sato wrote: > Pick up the fix in the upstream CLDR v42 maintenance branch for their tzdata2022f changes. This pull request has now been integrated. Changeset: 54c986e7 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/54c986e7d5d0b48a22b4da81c13153ce431c9f2f Stats: 16 lines in 6 files changed: 6 ins; 6 del; 4 mod 8296715: CLDR v42 update for tzdata 2022f Reviewed-by: joehw ------------- PR: https://git.openjdk.org/jdk/pull/11066 From jlaskey at openjdk.org Thu Nov 10 17:08:54 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 10 Nov 2022 17:08:54 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v16] In-Reply-To: References: <2YyIw9ZZ7H2Tj2yDWgNBZ8Uy31Q9OgIL_frX4O8o9BY=.b8603328-a6b4-4099-b67a-2cdb3487517b@github.com> Message-ID: On Thu, 10 Nov 2022 16:44:18 GMT, R?mi Forax wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Clean up new StringTemplate creation >> >> Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List to List on StringTemplate.interpolate and StringTemplate.of. > > src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 36: > >> 34: import java.lang.template.StringTemplate; >> 35: import java.lang.template.ValidatingProcessor; >> 36: import java.util.*; > > They come back :) Should turn off that inspector. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 10 17:42:04 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 10 Nov 2022 17:42:04 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/39c63c01..ac5402ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=15-16 Stats: 13 lines in 3 files changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From lancea at openjdk.org Thu Nov 10 18:47:23 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 10 Nov 2022 18:47:23 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods Message-ID: Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. ------------- Commit messages: - Clean up comment spacing - Move added Read() - Move @Override to its own line - Add back imports removed by intellij - Initial pass for updating the javadoc Changes: https://git.openjdk.org/jdk/pull/10995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8262435 Stats: 201 lines in 1 file changed: 199 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From jpai at openjdk.org Thu Nov 10 18:47:27 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 10 Nov 2022 18:47:27 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 18:13:23 GMT, Lance Andersen wrote: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 210: > 208: * Reads all remaining bytes from the input stream for the current ZIP entry. > 209: * This method blocks until all remaining bytes have been read and end of > 210: * stream is detected, or an exception is thrown. This method does not close Hello Lance, the part where it says that it reads the current ZIP entry sounds fine. However, this also states that it will wait until the end of stream is detected. Should we make it clearer by changing this to say `This method blocks until all remaining bytes of the entry have been read or an exception is thrown`? src/java.base/share/classes/java/util/zip/ZipInputStream.java line 231: > 229: * > 230: * @throws OutOfMemoryError {@inheritDoc} > 231: * I suspect we will also need to explicitly have a `@throws IOException` here. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 242: > 240: * Reads up to a specified number of bytes from the input stream > 241: * for the current ZIP entry. This > 242: * method blocks until the requested number of bytes has been read, end Nit - some of these words could be moved to the previous line to make the line length consistent with other lines. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 276: > 274: * the result is bounded by {@code 2*(long)len}, inclusive. > 275: * > 276: * @throws OutOfMemoryError {@inheritDoc} There are a couple of other `@throws` in the `super` that I think we should inherit here. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 319: > 317: * > 318: * @throws NullPointerException {@inheritDoc} > 319: * @throws IndexOutOfBoundsException {@inheritDoc} Missing `@throws` for `IOException`. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From jpai at openjdk.org Thu Nov 10 18:47:28 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 10 Nov 2022 18:47:28 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 09:55:52 GMT, Jaikiran Pai wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 210: > >> 208: * Reads all remaining bytes from the input stream for the current ZIP entry. >> 209: * This method blocks until all remaining bytes have been read and end of >> 210: * stream is detected, or an exception is thrown. This method does not close > > Hello Lance, the part where it says that it reads the current ZIP entry sounds fine. However, this also states that it will wait until the end of stream is detected. Should we make it clearer by changing this to say `This method blocks until all remaining bytes of the entry have been read or an exception is thrown`? Similar comment for the other `readNBytes` and skip methods. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Thu Nov 10 18:47:29 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 10 Nov 2022 18:47:29 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: References: Message-ID: <7Pz5I0dG_m16Jf6ePIQsVNkwWOkphl1F_TkuIUbow3M=.4efe5470-e489-423c-bb9d-c77550e210ae@github.com> On Mon, 7 Nov 2022 10:08:16 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 210: >> >>> 208: * Reads all remaining bytes from the input stream for the current ZIP entry. >>> 209: * This method blocks until all remaining bytes have been read and end of >>> 210: * stream is detected, or an exception is thrown. This method does not close >> >> Hello Lance, the part where it says that it reads the current ZIP entry sounds fine. However, this also states that it will wait until the end of stream is detected. Should we make it clearer by changing this to say `This method blocks until all remaining bytes of the entry have been read or an exception is thrown`? > > Similar comment for the other `readNBytes` and skip methods. Hi Jai, Thank you for your input above. I had thought about that but decided it would be best to keep the changes at a minimum from InputStream and felt given the change of the first sentence the rest of the wording is in regards to the current ZIP Entry ------------- PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Thu Nov 10 18:47:30 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 10 Nov 2022 18:47:30 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: References: Message-ID: <7DgZYR_iXgg5sGl3YJRiyfhreovALcvfsU17KWaHwpQ=.8bcf1ba7-162e-4c8e-902d-f83c30ec0b7a@github.com> On Mon, 7 Nov 2022 09:58:03 GMT, Jaikiran Pai wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 231: > >> 229: * >> 230: * @throws OutOfMemoryError {@inheritDoc} >> 231: * > > I suspect we will also need to explicitly have a `@throws IOException` here. The javadoc for the checked exceptions will be inherited. I had to specifically add the RuntimeExceptions as they are not inherited by default > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 242: > >> 240: * Reads up to a specified number of bytes from the input stream >> 241: * for the current ZIP entry. This >> 242: * method blocks until the requested number of bytes has been read, end > > Nit - some of these words could be moved to the previous line to make the line length consistent with other lines. I had addressed it but had not pushed it, thanks for the reminder > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 276: > >> 274: * the result is bounded by {@code 2*(long)len}, inclusive. >> 275: * >> 276: * @throws OutOfMemoryError {@inheritDoc} > > There are a couple of other `@throws` in the `super` that I think we should inherit here. See comment above, checked exceptions are inherited > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 319: > >> 317: * >> 318: * @throws NullPointerException {@inheritDoc} >> 319: * @throws IndexOutOfBoundsException {@inheritDoc} > > Missing `@throws` for `IOException`. See comment above, checked exceptions are inherited ------------- PR: https://git.openjdk.org/jdk/pull/10995 From jpai at openjdk.org Thu Nov 10 18:47:31 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 10 Nov 2022 18:47:31 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: <7DgZYR_iXgg5sGl3YJRiyfhreovALcvfsU17KWaHwpQ=.8bcf1ba7-162e-4c8e-902d-f83c30ec0b7a@github.com> References: <7DgZYR_iXgg5sGl3YJRiyfhreovALcvfsU17KWaHwpQ=.8bcf1ba7-162e-4c8e-902d-f83c30ec0b7a@github.com> Message-ID: On Mon, 7 Nov 2022 16:05:28 GMT, Lance Andersen wrote: > The javadoc for the checked exceptions will be inherited Thank you Lance, I wasn't aware of that. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From aefimov at openjdk.org Thu Nov 10 19:24:10 2022 From: aefimov at openjdk.org (Aleksei Efimov) Date: Thu, 10 Nov 2022 19:24:10 GMT Subject: Integrated: 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly In-Reply-To: References: Message-ID: <6h1EjMrNRHi1MmZ0xMR_ZRMYN5Gt4VRth1L69W3obHE=.be5868bf-52b8-44f2-a055-52ccdfde5673@github.com> On Sun, 6 Nov 2022 16:39:48 GMT, Aleksei Efimov wrote: > ### The Proposed Change > > The proposed change updates JNDI's `DnsClient` internal implementation to use `DatagramChannel` (DC) as a replacement for `DatagramSocket` (DS). > The main motivation behind this change is to make JNDI/DNS lookups friendly to virtual-thread environments and update its underlying implementation to use efficient `DatagramChannel` APIs. > The list of proposed changes: > - Replace DS usage with DC. That includes the `DNSDatagramSocketFactory` class updates to return DC instead of DS. The factory class was renamed to `DNSDatagramChannelFactory` to reflect that. > - Change DNS query timeouts implementation - the current version introduces a nio channels selector to implement timeouts. One selector is created for each instance of `DnsClient`. > - Adjust query retries logic to the new implementation of timeouts. > - Modify the `Timeout` test to create a bound UDP socket to simulate an unresponsive DNS server. Before this change, the test was using the '10.0.0.0' network address that doesn't belong to any host. The proposed change with a bound unresponsive UDP socket is better for test stability on different platforms. > > > ### Testing > `jdk-tier1` to `jdk-tier3 `tests are showing no failures related to the changes. > JNDI regression and JCK tests also didn't highlight any problems with the changes. > > Also, an app performing a DNS lookup from a virtual thread context executed with the following options `--enable-preview -Djdk.tracePinnedThreads=full` showed no pinned carrier threads. Before the proposed change the following pinned stack trace was observed: > ``` java.base/sun.nio.ch.DatagramChannelImpl.park(DatagramChannelImpl.java:486) > java.base/sun.nio.ch.DatagramChannelImpl.trustedBlockingReceive(DatagramChannelImpl.java:734) > java.base/sun.nio.ch.DatagramChannelImpl.blockingReceive(DatagramChannelImpl.java:661) > java.base/sun.nio.ch.DatagramSocketAdaptor.receive(DatagramSocketAdaptor.java:241) <== monitors:1 > java.base/java.net.DatagramSocket.receive(DatagramSocket.java:714) > jdk.naming.dns/com.sun.jndi.dns.DnsClient.doUdpQuery(DnsClient.java:430) <== monitors:1 > jdk.naming.dns/com.sun.jndi.dns.DnsClient.query(DnsClient.java:216) > jdk.naming.dns/com.sun.jndi.dns.Resolver.query(Resolver.java:81) > jdk.naming.dns/com.sun.jndi.dns.DnsContext.c_lookup(DnsContext.java:290) > java.naming/com.sun.jndi.toolkit.ctx.ComponentContext.p_lookup(ComponentContext.java:542) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:177) > java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeContext.lookup(PartialCompositeContext.java:166) > java.naming/javax.naming.InitialContext.lookup(InitialContext.java:409) > > After proposed changes - pinned threads are not detectable. This pull request has now been integrated. Changeset: 9ef7852b Author: Aleksei Efimov URL: https://git.openjdk.org/jdk/commit/9ef7852be38ed78a5405e162d160f1ce72a7755b Stats: 726 lines in 4 files changed: 370 ins; 319 del; 37 mod 8290714: Make com.sun.jndi.dns.DnsClient virtual threads friendly Reviewed-by: dfuchs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11007 From jvernee at openjdk.org Thu Nov 10 19:56:45 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Thu, 10 Nov 2022 19:56:45 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 17:42:04 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Requested changes #5 src/java.base/share/classes/java/lang/template/Carriers.java line 415: > 413: */ > 414: @Stable > 415: private final Object[] objects; Looking at all this, I'm skeptical that carriers are worth the complexity for the performance gain they give. AFAICS the fast paths for `FMT` and `STR` avoid boxing values into a StringTemplate instance altogether. So carriers only seem to help cases where processing goes through the default `process` method on a user-defined processor? AFAIK `@Stable` will not do anything here. It only helps constant folding from a constant root object and in general StringTemplate instances are not constant. (and, AFAIK there are also JIT caveats with storing everything in arrays like this). I suggest maybe keeping things simple in this PR, and having a `StringTemplateImpl` with just a `List` for the values. Public support for the linkage-based fast path can be used to avoid the boxing for user defined processors in the future as well, and that seems like a much better way to get performance to me. If carriers are added to improve performance, I'd personally like to see that in a separate PR that's only focused on that, with more benchmarks/bench marking results included as well. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mullan at openjdk.org Thu Nov 10 21:34:30 2022 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 10 Nov 2022 21:34:30 GMT Subject: RFR: JDK-8296547: Add @spec tags to API In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> Message-ID: <9dD51N9kpu4MV5_oJ1e6lxsYLxnk6mG5mQeH_SAzWqA=.71dcec22-0ad2-41f2-89e3-8c9964db61cb@github.com> On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote: > When referencing an RFC, it might be good to keep the RFC number in the text link. +1. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 21:58:28 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 21:58:28 GMT Subject: RFR: JDK-8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 11:30:51 GMT, Daniel Fuchs wrote: > Hi Jon, > > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: > > http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/URL.html > > External Specifications [Format for Literal IPv6 Addresses in URL's](https://www.ietf.org/rfc/rfc2732.html), [Uniform Resource Identifier (URI): Generic Syntax](https://www.ietf.org/rfc/rfc3986.html), [Uniform Resource Identifiers (URI): Generic Syntax](https://www.ietf.org/rfc/rfc2396.html) > > You will see that two of the RFC links have the same text but link to different RFCs, which I am finding confusing. Also I do hope it's clear that if a specification is referenced it doesn't mean it's being implemented. On keeping RFC in the title, I'll go with the team preference. I note that not all spec authorities have such a well-defined naming/numbering scheme, so it does make the summary page a bit inconsistent. Also, the entries under "R" dominate the list, which may not be what you want. On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 22:03:32 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 22:03:32 GMT Subject: RFR: JDK-8296546: Add @spec tags to API In-Reply-To: <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <0ewiD2RJysuNs-Gq-uhprGJE_JzX12b9g-UY5ISVrvQ=.43464ca3-6b75-4dc1-9f82-0348813cd74f@github.com> Message-ID: On Thu, 10 Nov 2022 11:45:39 GMT, Alan Bateman wrote: > > When referencing an RFC, it might be good to keep the RFC number in the text link. For instance I see that java.net.URL now has this: > > I agree and also to add that some RFCs have commas in their titles, the same separator used when there is more than one specification linked. Here's an example: > > http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/nio/channels/MulticastChannel.html I can change the doclet to use a bulleted list when any spec titles contain a comma. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 22:11:30 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 22:11:30 GMT Subject: RFR: JDK-8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 12:01:11 GMT, Alan Bateman wrote: > I'm trying to understand what "fix-ups" will be needed if the automated patch is applied. In some cases, it looks the same spec will be linked from "See also" and "External Specifications", e.g. http://cr.openjdk.java.net/~jjg/8296546/api.00/java.base/java/net/StandardSocketOptions.html#TCP_NODELAY so the `@see` ref can be dropped. > > In other cases we will have inline refs and the same URL in the `@spec`. This may be okay for the short term but maybe there is a way to inline `@spec` to avoid the duplication? > > There will probably be a bit of cleanup to reflow some lines, e.g. StandardSocketOptions.java, as excessively long lines are problematic for side-by-side diffs. The utility I mentioned has the (optional) ability to remove `@see` links when the text of the link exactly matches that used by the `@spec` tag. Unfortunately, the text is typically not exactly the same, and would require manual analysis to see if the `@see` tag can be removed. When inline references are used, the wording is very rarely the primary title of the spec: it is more likely to be a word or phrase that makes sense in the context of the enclosing sentence. _History: version 1 of this feature tried replacing inline links and `@see` tags with a bi-modal `@spec` tag. The results were "not good", especially in the generated external-specs page. Version 2 used a side file to provide the definitive title for each spec, but that was deemed to be too much of a maintenance issue. This is version 3, in which we've eliminated the side-file in favor of duplicating the title in each `@spec` tag._ ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Nov 10 22:19:26 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 10 Nov 2022 22:19:26 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 16:33:09 GMT, AJ1062910 wrote: > did you changed 420 files ? I ran a custom utility that edited these files, yes. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jlaskey at openjdk.org Thu Nov 10 22:59:03 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 10 Nov 2022 22:59:03 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 19:54:30 GMT, Jorn Vernee wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Requested changes #5 > > src/java.base/share/classes/java/lang/template/Carriers.java line 415: > >> 413: */ >> 414: @Stable >> 415: private final Object[] objects; > > Looking at all this, I'm skeptical that carriers are worth the complexity for the performance gain they give. AFAICS the fast paths for `FMT` and `STR` avoid boxing values into a StringTemplate instance altogether. So carriers only seem to help cases where processing goes through the default `process` method on a user-defined processor? > > AFAIK `@Stable` will not do anything here. It only helps constant folding from a constant root object and in general StringTemplate instances are not constant. (and, AFAIK there are also JIT caveats with storing everything in arrays like this). > > I suggest maybe keeping things simple in this PR, and having just `SimpleStringTemplate`. Public support for the linkage-based fast path can be used to avoid the boxing for user defined processors in the future as well, and that seems like a much better way to get performance to me. > > If carriers are added to improve performance, I'd personally like to see that in a separate PR that's only focused on that, with more benchmarks/bench marking results included as well. Fair comment. Initially, 99% of template processing will be through `STR``. However, that will likely change as libraries expand to include template processing. In fact, creating processors is so trivially easy that users will likely start using template processing for every day tasks. During the preview, string templates will be evaluatedby Java influencers for use in future applications. If we come out of the gate with a less than stellar feature then string templates will not gain traction. Several reviewers, including most of the compiler team, had a problem with the use of anonymous classes for each and every string template. Carriers were introduced as an alternative. The fact that they perform well is an added bonus. Note Carriers are not a last minute thing. I've been using them off/on for much of the project. Carriers also have a place in future planned projects. It was Brian that inspired the idea. Carriers, as well as the FormatProcessor, are indeed projects unto themselves, but are a important part of the string template project. Breaking those projects out separately would risk not making preview. It's important to get these classes tested in real use cases during preview. In the balance, as you indicated, STR and FMT are the show. Carriers are low risk with big win. The linkage stuff will likely dissolve into something that doesn't require a lot of MethodHandle experience, something like a TemplateProcessorFactory. I whipped up a trivial JMH benchmark to give a sense of Carrier worth. Note I'm not a performance engineer and milage may vary, but this will give you the sense of degree difference between Carriers and a list implementation. public class MyBenchmark { // Declared globally to spoil optimization. static int x = 10, y = 20; static String result; static StringProcessor INTERPOLATE = st -> st.interpolate(); static List FRAGMENTS = List.of("", " + ", " = ", ""); // String concatenation as a baseline. @Benchmark public void concat() { result = x + " + " + y + " = " + (x + y); } // STR is effectively String concatenation. @Benchmark public void str() { result = STR."{x} + {y} = {x + y}"; } // StringTemplate using a carrier and thus the constructed interpolate. @Benchmark public void carrier() { result = INTERPOLATE."{x} + {y} = {x + y}"; } // StringTemplates using lists for fragments and values. // Note that FRAGMENTS is only constructed once as it would be in the wilds. @Benchmark public void lists() { StringTemplate st = StringTemplate.of(FRAGMENTS, List.of(x, y, x + y)); result = st.interpolate(); } // Formatting can be effectively String concatenation. @Benchmark public void format() { result = FMT."%d{x} + %d{y} = %d{x + y}"; } } Benchmark Mode Cnt Score Error Units MyBenchmark.concat thrpt 25 52570142.770 ? 5373985.927 ops/s MyBenchmark.str thrpt 25 52569879.770 ? 2787317.140 ops/s MyBenchmark.carrier thrpt 25 54161402.682 ? 4587727.795 ops/s MyBenchmark.lists thrpt 25 9260123.476 ? 189741.261 ops/s MyBenchmark.format thrpt 25 50847393.625 ? 135673.614 ops/s Thanks for pointing out the @Stable issue. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From naoto at openjdk.org Thu Nov 10 23:55:34 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 10 Nov 2022 23:55:34 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. src/java.base/share/classes/java/lang/Character.java line 172: > 170: * occur. For example, in a future release, synchronization may fail. > 171: * > 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 This should probably be removed, as the original link (explaining `U+n` notation) is broken. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From egahlin at openjdk.org Fri Nov 11 00:17:07 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 11 Nov 2022 00:17:07 GMT Subject: RFR: 8296229: JFR: jfr tool should print unsigned values correctly [v2] In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> Message-ID: > Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool. > > Testing: > test/jdk/jdk/jfr > test/jdk/jdk/security/logging/ > > Thanks > Erik Erik Gahlin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge - Initial ------------- Changes: https://git.openjdk.org/jdk/pull/11039/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11039&range=01 Stats: 77 lines in 15 files changed: 37 ins; 1 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/11039.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11039/head:pull/11039 PR: https://git.openjdk.org/jdk/pull/11039 From egahlin at openjdk.org Fri Nov 11 00:24:38 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 11 Nov 2022 00:24:38 GMT Subject: Withdrawn: 8296229: JFR: jfr tool should print unsigned values correctly In-Reply-To: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> References: <7VV_XzizFAByK4isg4nocrlZNt-AEIVME-630Lt78uU=.ee88d45e-883f-4b92-89b6-4647a856c144@github.com> Message-ID: <20MAo47rnhTgoC4A5u1zUZ2IlUgV8WaJN8CnNA2z-ck=.aacf45b6-8987-43b6-91eb-cb8c6a92bf7c@github.com> On Tue, 8 Nov 2022 12:03:06 GMT, Erik Gahlin wrote: > Could I have a review of PR that fixes so unsigned numbers are printed correctly in the jfr tool. > > Testing: > test/jdk/jdk/jfr > test/jdk/jdk/security/logging/ > > Thanks > Erik This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11039 From psandoz at openjdk.org Fri Nov 11 00:51:34 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 11 Nov 2022 00:51:34 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v17] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 13:24:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak Arena::close javadoc src/java.base/share/classes/java/lang/foreign/Arena.java line 101: > 99: * @throws IllegalArgumentException if {@code bytesSize < 0}, {@code alignmentBytes <= 0}, or if {@code alignmentBytes} > 100: * is not a power of 2. > 101: * @throws IllegalStateException if the session associated with this arena is not {@linkplain MemorySession#isAlive() alive}. Suggestion: * @throws IllegalStateException if arena's session is not {@linkplain MemorySession#isAlive() alive}. src/java.base/share/classes/java/lang/foreign/Arena.java line 121: > 119: * segments associated with that memory session are also released. > 120: * @throws IllegalStateException if the session associated with this arena is not {@linkplain MemorySession#isAlive() alive}. > 121: * @throws IllegalStateException if this session is {@linkplain MemorySession#whileAlive(Runnable) kept alive} by another client. Suggestion: * @throws IllegalStateException if the arena's session is not {@linkplain MemorySession#isAlive() alive}. * @throws IllegalStateException if the arena's session is {@linkplain MemorySession#whileAlive(Runnable) kept alive}. Note i removed "by another client". I wanted to say "by another thread", but then there is the case of calling close from within the Runnable passed to whileAlive, so i wanted to say "by another caller". But, i think this can all be implied and we don't need to say anything. src/java.base/share/classes/java/lang/foreign/MemorySession.java line 66: > 64: * is not critical, or in unstructured cases where the boundaries of the lifetime associated with a memory session > 65: * cannot be easily determined. As shown in the example above, a memory session that is managed implicitly cannot end > 66: * if a program references to one or more segments associated with that session. This means that memory segments associated Suggestion: * if a program references one or more segments associated with that session. This means that memory segments associated src/java.base/share/classes/java/lang/foreign/MemorySession.java line 89: > 87: > 88: /** > 89: * {@return {@code true} if the provided thread can access and/or obtain segments associated with this memory session} Is the following accurate and more concise? Suggestion: * {@return {@code true} if the provided thread can access and/or associate segments with this memory session} ------------- PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Fri Nov 11 00:57:44 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 11 Nov 2022 00:57:44 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 22:56:22 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/Carriers.java line 415: >> >>> 413: */ >>> 414: @Stable >>> 415: private final Object[] objects; >> >> Looking at all this, I'm skeptical that carriers are worth the complexity for the performance gain they give. AFAICS the fast paths for `FMT` and `STR` avoid boxing values into a StringTemplate instance altogether. So carriers only seem to help cases where processing goes through the default `process` method on a user-defined processor? >> >> AFAIK `@Stable` will not do anything here. It only helps constant folding from a constant root object and in general StringTemplate instances are not constant. (and, AFAIK there are also JIT caveats with storing everything in arrays like this). >> >> I suggest maybe keeping things simple in this PR, and having just `SimpleStringTemplate`. Public support for the linkage-based fast path can be used to avoid the boxing for user defined processors in the future as well, and that seems like a much better way to get performance to me. >> >> If carriers are added to improve performance, I'd personally like to see that in a separate PR that's only focused on that, with more benchmarks/bench marking results included as well. > > Fair comment. Initially, 99% of template processing will be through `STR``. However, that > will likely change as libraries expand to include template processing. In fact, creating > processors is so trivially easy that users will likely start using template processing for > every day tasks. > > During the preview, string templates will be evaluatedby Java influencers for use in > future applications. If we come out of the gate with a less than stellar feature > then string templates will not gain traction. > > Several reviewers, including most of the compiler team, had a problem with the use of > anonymous classes for each and every string template. Carriers were introduced as an > alternative. The fact that they perform well is an added bonus. Note Carriers are not a > last minute thing. I've been using them off/on for much of the project. > > Carriers also have a place in future planned projects. It was Brian that inspired the idea. > > Carriers, as well as the FormatProcessor, are indeed projects unto themselves, but are a > important part of the string template project. Breaking those projects out separately > would risk not making preview. It's important to get these classes tested in real use > cases during preview. In the balance, as you indicated, STR and FMT are the show. Carriers > are low risk with big win. > > The linkage stuff will likely dissolve into something that doesn't require a lot of > MethodHandle experience, something like a TemplateProcessorFactory. > > I whipped up a trivial JMH benchmark to give a sense of Carrier worth. Note I'm not a > performance engineer and milage may vary, but this will give you the sense of degree > difference between Carriers and a list implementation. > > > > public class MyBenchmark { > // Declared globally to spoil optimization. > static int x = 10, y = 20; > static String result; > static StringProcessor INTERPOLATE = st -> st.interpolate(); > static List FRAGMENTS = List.of("", " + ", " = ", ""); > > // String concatenation as a baseline. > @Benchmark > public void concat() { > result = x + " + " + y + " = " + (x + y); > } > > // STR is effectively String concatenation. > @Benchmark > public void str() { > result = STR."{x} + {y} = {x + y}"; > } > > // StringTemplate using a carrier and thus the constructed interpolate. > @Benchmark > public void carrier() { > result = INTERPOLATE."{x} + {y} = {x + y}"; > } > > // StringTemplates using lists for fragments and values. > // Note that FRAGMENTS is only constructed once as it would be in the wilds. > @Benchmark > public void lists() { > StringTemplate st = StringTemplate.of(FRAGMENTS, List.of(x, y, x + y)); > result = st.interpolate(); > } > > // Formatting can be effectively String concatenation. > @Benchmark > public void format() { > result = FMT."%d{x} + %d{y} = %d{x + y}"; > } > > } > > > > > Benchmark Mode Cnt Score Error Units > MyBenchmark.concat thrpt 25 52570142.770 ? 5373985.927 ops/s > MyBenchmark.str thrpt 25 52569879.770 ? 2787317.140 ops/s > MyBenchmark.carrier thrpt 25 54161402.682 ? 4587727.795 ops/s > MyBenchmark.lists thrpt 25 9260123.476 ? 189741.261 ops/s > MyBenchmark.format thrpt 25 50847393.625 ? 135673.614 ops/s > > > Thanks for pointing out the @Stable issue. Thanks, I think benchmarks like this are useful. The `interpolate()` case is not something I considered when I made my earlier comment. Please add any benchmarks to the patch as well, so that performance experiments can be reliably reproduced. I think what this benchmark mainly shows is the benefit of carriers in combination with the instance `interpolate()` method. I expect most custom string processors will interact with string template instances through the `fragments()` and `values()` methods, though (I don't think there is an alternative?). i.e. in the end, we still end up boxing everything into a couple of lists any ways. `interpolate()` also has another leg up in that it knows the shape of the template when the string template instance is constructed, and can use a specialized method handle to do the processing. If I change the benchmark to rely on the `fragments()` and `values()` accessors (which I think the majority/all of the custom processor will have to do), for instance by using `st -> StringTemplate.interpolate(st.fragments(), st.values())` as a custom processor, and I tweak `StringTemplateImplFactory::newStringTemplate` to use `List::copyOf` instead of the stream it uses now [1], then the list based implementation is slightly faster than the carriers based implementation on my machine: Benchmark Mode Cnt Score Error Units Carriers.carrier avgt 15 69.946 ? 0.599 ns/op Carriers.carrier_inst avgt 15 15.014 ? 0.106 ns/op Carriers.concat avgt 15 8.441 ? 0.021 ns/op Carriers.format avgt 15 9.314 ? 0.172 ns/op Carriers.lists avgt 15 61.131 ? 0.401 ns/op Carriers.str avgt 15 8.547 ? 0.145 ns/op It makes me wonder if carriers are worth it at this stage (hard to say...), or if it's better to go all-in on custom linkage, which should give custom processors performance that is comparable with `STR` and `FMT`. Maybe the instance `interpolate()` method is an important enough use-case to add carriers though. I can't really say. I appreciate the fact that carriers will see use in future projects as well, but at face value, it doesn't seem like they add that much for string templates (rather, on the contrary in some cases it seems). [1]: http://cr.openjdk.java.net/~jvernee/bench.diff ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Nov 11 01:43:57 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 11 Nov 2022 01:43:57 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 00:55:24 GMT, Jorn Vernee wrote: >> Fair comment. Initially, 99% of template processing will be through `STR``. However, that >> will likely change as libraries expand to include template processing. In fact, creating >> processors is so trivially easy that users will likely start using template processing for >> every day tasks. >> >> During the preview, string templates will be evaluatedby Java influencers for use in >> future applications. If we come out of the gate with a less than stellar feature >> then string templates will not gain traction. >> >> Several reviewers, including most of the compiler team, had a problem with the use of >> anonymous classes for each and every string template. Carriers were introduced as an >> alternative. The fact that they perform well is an added bonus. Note Carriers are not a >> last minute thing. I've been using them off/on for much of the project. >> >> Carriers also have a place in future planned projects. It was Brian that inspired the idea. >> >> Carriers, as well as the FormatProcessor, are indeed projects unto themselves, but are a >> important part of the string template project. Breaking those projects out separately >> would risk not making preview. It's important to get these classes tested in real use >> cases during preview. In the balance, as you indicated, STR and FMT are the show. Carriers >> are low risk with big win. >> >> The linkage stuff will likely dissolve into something that doesn't require a lot of >> MethodHandle experience, something like a TemplateProcessorFactory. >> >> I whipped up a trivial JMH benchmark to give a sense of Carrier worth. Note I'm not a >> performance engineer and milage may vary, but this will give you the sense of degree >> difference between Carriers and a list implementation. >> >> >> >> public class MyBenchmark { >> // Declared globally to spoil optimization. >> static int x = 10, y = 20; >> static String result; >> static StringProcessor INTERPOLATE = st -> st.interpolate(); >> static List FRAGMENTS = List.of("", " + ", " = ", ""); >> >> // String concatenation as a baseline. >> @Benchmark >> public void concat() { >> result = x + " + " + y + " = " + (x + y); >> } >> >> // STR is effectively String concatenation. >> @Benchmark >> public void str() { >> result = STR."{x} + {y} = {x + y}"; >> } >> >> // StringTemplate using a carrier and thus the constructed interpolate. >> @Benchmark >> public void carrier() { >> result = INTERPOLATE."{x} + {y} = {x + y}"; >> } >> >> // StringTemplates using lists for fragments and values. >> // Note that FRAGMENTS is only constructed once as it would be in the wilds. >> @Benchmark >> public void lists() { >> StringTemplate st = StringTemplate.of(FRAGMENTS, List.of(x, y, x + y)); >> result = st.interpolate(); >> } >> >> // Formatting can be effectively String concatenation. >> @Benchmark >> public void format() { >> result = FMT."%d{x} + %d{y} = %d{x + y}"; >> } >> >> } >> >> >> >> >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.concat thrpt 25 52570142.770 ? 5373985.927 ops/s >> MyBenchmark.str thrpt 25 52569879.770 ? 2787317.140 ops/s >> MyBenchmark.carrier thrpt 25 54161402.682 ? 4587727.795 ops/s >> MyBenchmark.lists thrpt 25 9260123.476 ? 189741.261 ops/s >> MyBenchmark.format thrpt 25 50847393.625 ? 135673.614 ops/s >> >> >> Thanks for pointing out the @Stable issue. > > Thanks, I think benchmarks like this are useful. The `interpolate()` case is not something I considered when I made my earlier comment. Please add any benchmarks to the patch as well, so that performance experiments can be reliably reproduced. > > I think what this benchmark mainly shows is the benefit of carriers in combination with the instance `interpolate()` method. I expect most custom string processors will interact with string template instances through the `fragments()` and `values()` methods, though (I don't think there is an alternative?). i.e. in the end, we still end up boxing everything into a couple of lists any ways. `interpolate()` also has another leg up in that it knows the shape of the template when the string template instance is constructed, and can use a specialized method handle to do the processing. > > If I change the benchmark to rely on the `fragments()` and `values()` accessors (which I think the majority/all of the custom processor will have to do), for instance by using `st -> StringTemplate.interpolate(st.fragments(), st.values())` as a custom processor, and I tweak `StringTemplateImplFactory::newStringTemplate` to use `List::copyOf` instead of the stream it uses now ([1]), then the list based implementation is slightly faster than the carriers based implementation on my machine: > > > Benchmark Mode Cnt Score Error Units > Carriers.carrier avgt 15 69.946 ? 0.599 ns/op > Carriers.carrier_inst avgt 15 15.014 ? 0.106 ns/op > Carriers.concat avgt 15 8.441 ? 0.021 ns/op > Carriers.format avgt 15 9.314 ? 0.172 ns/op > Carriers.lists avgt 15 61.131 ? 0.401 ns/op > Carriers.str avgt 15 8.547 ? 0.145 ns/op > > > It makes me wonder if carriers are worth it at this stage (hard to say... performance is usually a long string to pull), or if it's better to go all-in on custom linkage, which should give custom processors performance that is comparable with `STR` and `FMT`. > > Maybe the instance `interpolate()` method is an important enough use-case to add carriers though. I can't really say. > > I appreciate the fact that carriers will see use in future projects as well, but at face value, it doesn't seem like they add that much for string templates (rather, on the contrary in some cases it seems). > > [1]: http://cr.openjdk.java.net/~jvernee/bench.diff Something like a StringProcessorFactory could produce the same structures as as interpolate without the boxing issues. There are generally two main types of processors (there are others but they would require specialization anyway). The first type doesn't really care about the construction of the string. It just wants to get the interpolation and work with the result. A JSON processor might fall into that category. The second type wants to transform (MH filter args) the fragments or the values or both and then get an interpolation (and maybe work with that result). This is where the StringProcessorFactory would kick in and automate the process and in the end get similar performance as interpolate. No lists or boxing. A formatter processor might fall into that category. What I think you are really objecting to is the existence of StringTemplate objects. Why not just BSM everything? The problem is that processors can be swapped out and can have state. So you need a user model where the what object (StringTemplate) is separate from the how object (TemplateProcessor). Try working through some examples and it will become clearer. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Fri Nov 11 02:43:46 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 11 Nov 2022 02:43:46 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 01:41:15 GMT, Jim Laskey wrote: >> Thanks, I think benchmarks like this are useful. The `interpolate()` case is not something I considered when I made my earlier comment. Please add any benchmarks to the patch as well, so that performance experiments can be reliably reproduced. >> >> I think what this benchmark mainly shows is the benefit of carriers in combination with the instance `interpolate()` method. I expect most custom string processors will interact with string template instances through the `fragments()` and `values()` methods, though (I don't think there is an alternative?). i.e. in the end, we still end up boxing everything into a couple of lists any ways. `interpolate()` also has another leg up in that it knows the shape of the template when the string template instance is constructed, and can use a specialized method handle to do the processing. >> >> If I change the benchmark to rely on the `fragments()` and `values()` accessors (which I think the majority/all of the custom processor will have to do), for instance by using `st -> StringTemplate.interpolate(st.fragments(), st.values())` as a custom processor, and I tweak `StringTemplateImplFactory::newStringTemplate` to use `List::copyOf` instead of the stream it uses now ([1]), then the list based implementation is slightly faster than the carriers based implementation on my machine: >> >> >> Benchmark Mode Cnt Score Error Units >> Carriers.carrier avgt 15 69.946 ? 0.599 ns/op >> Carriers.carrier_inst avgt 15 15.014 ? 0.106 ns/op >> Carriers.concat avgt 15 8.441 ? 0.021 ns/op >> Carriers.format avgt 15 9.314 ? 0.172 ns/op >> Carriers.lists avgt 15 61.131 ? 0.401 ns/op >> Carriers.str avgt 15 8.547 ? 0.145 ns/op >> >> >> It makes me wonder if carriers are worth it at this stage (hard to say... performance is usually a long string to pull), or if it's better to go all-in on custom linkage, which should give custom processors performance that is comparable with `STR` and `FMT`. >> >> Maybe the instance `interpolate()` method is an important enough use-case to add carriers though. I can't really say. >> >> I appreciate the fact that carriers will see use in future projects as well, but at face value, it doesn't seem like they add that much for string templates (rather, on the contrary in some cases it seems). >> >> [1]: http://cr.openjdk.java.net/~jvernee/bench.diff > > Something like a StringProcessorFactory could produce the same structures as as interpolate without the boxing issues. > > There are generally two main types of processors (there are others but they would require specialization anyway). The first type doesn't really care about the construction of the string. It just wants to get the interpolation and work with the result. A JSON processor might fall into that category. > > The second type wants to transform (MH filter args) the fragments or the values or both and then get an interpolation (and maybe work with that result). This is where the StringProcessorFactory would kick in and automate the process and in the end get similar performance as interpolate. No lists or boxing. A formatter processor might fall into that category. > > What I think you are really objecting to is the existence of StringTemplate objects. Why not just BSM everything? The problem is that processors can be swapped out and can have state. So you need a user model where the what object (StringTemplate) is separate from the how object (TemplateProcessor). > > Try working through some examples and it will become clearer. I guess I'm not sure what you have in mind with `StringProcessorFactory`, but I think it's starting to become clearer. I expected it to return a method handle that took all the dynamic values as arguments (similar to the callsites return by the current BSMs), i.e. it would completely bypass `StringTemplate`, but it sounds like it will instead take just a `StringTemplate` instance as argument? In that case carriers make sense to me, as the accesses to the fragments and values would be funneled through the StringTemplate instance, and a StringProcessorFactory could generate 'sharp' accesses to those values (rather than going through `StringTemplate::fragments()` and `StringTemplate::values()`, which would box things into lists any ways). Thanks ------------- PR: https://git.openjdk.org/jdk/pull/10889 From cjplummer at openjdk.org Fri Nov 11 04:18:30 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 11 Nov 2022 04:18:30 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/Connection.java line 105: > 103: * If the length of the packet (as indictaed by the first > 104: * 4 bytes) is less than 11 bytes, or an I/O error occurs. > 105: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/com/sun/jdi/connect/spi/Connection.html#readPacket() Within this javadoc page the jdwp-spec.html references are titled "JDWP Specification", but these `@spec` references are titled "Java Debug Wire Protocol". I suggest making them more consistent. There is one more case below and this same issue also applies to TransportService.java. Perhaps the title in jdwp-spec.html should be updated. I think "Java Debug Wire Protocol (JDWP) Specification" would be good. src/jdk.jdi/share/classes/com/sun/jdi/connect/spi/TransportService.java line 79: > 77: * target VM. > 78: * > 79: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol See above comment for Connection.java. src/jdk.jdi/share/classes/module-info.java line 107: > 105: * > 106: * > 107: * @spec jpda/jpda.html Java Platform Debugger Architecture http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdi/module-summary.html `@spec` and `@see` sections end up one right after the other with the same content, except the `@see` section has the preferred hyperlink title. Suggest you remove the `@see` section and also update `@spec` hyperlink title to include "(JPDA)", or update the actual title in the jpda.html doc so it includes "(JPDA)" in it and then rerun your tool. src/jdk.jdwp.agent/share/classes/module-info.java line 30: > 28: * > 29: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol > 30: * @spec jdwp/jdwp-transport.html Java Debug Wire Protocol Transport Interface (jdwpTransport) http://cr.openjdk.java.net/~jjg/8296546/api.00/jdk.jdwp.agent/module-summary.html The end result here is not very clean. You have the same two specs being referred to just a few lines apart, and the hyperlink titles are not even close to be the same, even though the links are the same. Maybe the "@see" section should be removed. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Fri Nov 11 07:18:39 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 11 Nov 2022 07:18:39 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v5] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: On Wed, 9 Nov 2022 07:11:53 GMT, Markus KARG wrote: >> This PR implements JDK-8296431 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused imports @bplb Is there more you like to get changed? ------------- PR: https://git.openjdk.org/jdk/pull/10999 From dfuchs at openjdk.org Fri Nov 11 10:29:33 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Nov 2022 10:29:33 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 21:56:26 GMT, Jonathan Gibbons wrote: > On the same text but linking to different RFCs: that's tantamount to a bug somewhere. The spec for `@spec` dictates that the URLs and titles should be in 1-1 correspondence, and this is supposed to be enforced in the docket. In other words, specs should have unique titles, and any title should only be used for one spec. It's not uncommon for a newer version of a RFC to change its number but keep its title. I see that the links in the class level API documentation both have the RFC number in their link text. Somehow that was stripped by your tool - possibly because it tried to extract some meta information from the linked page itself? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From lancea at openjdk.org Fri Nov 11 11:49:32 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 11 Nov 2022 11:49:32 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Thu, 10 Nov 2022 01:10:13 GMT, Jonathan Gibbons wrote: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Hi Jon, I only looked at the jar specific updates but there is some duplication leftovers. It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs src/java.base/share/classes/java/util/jar/Attributes.java line 58: > 56: * order that keys were inserted into the map, as with {@link LinkedHashMap}. > 57: * > 58: * @spec jar/jar.html JAR File Specification Line 52 should be removed src/java.base/share/classes/java/util/jar/Attributes.java line 450: > 448: * JAR File Specification > 449: * for more information about valid attribute names and values. > 450: * @spec jar/jar.html JAR File Specification Line 448 should be removed src/java.base/share/classes/java/util/jar/Manifest.java line 47: > 45: * Manifest format specification. > 46: * > 47: * @spec jar/jar.html JAR File Specification Line 44 should be removed src/java.base/share/classes/java/util/jar/package-info.java line 47: > 45: * > 46: * > 47: * @spec jar/jar.html JAR File Specification Line 43 should be removed src/java.base/share/classes/java/util/zip/package-info.java line 75: > 73: * > 74: * > 75: * @spec https://www.ietf.org/rfc/rfc1951.html DEFLATE Compressed Data Format Specification version 1.3 The above references should be removed as they duplicate the` @spec` tags ------------- Changes requested by lancea (Reviewer). PR: https://git.openjdk.org/jdk/pull/11073 From dfuchs at openjdk.org Fri Nov 11 12:01:42 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Nov 2022 12:01:42 GMT Subject: RFR: 8296546: Add @spec tags to API In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Fri, 11 Nov 2022 11:45:43 GMT, Lance Andersen wrote: > It would probably be easier for the reviewers and for you if the PR could be broken out by areas into separate PRs Leaving out the non-public and non-exported classes would also reduce the PR size. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From alanb at openjdk.org Fri Nov 11 12:33:05 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 11 Nov 2022 12:33:05 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 18:13:23 GMT, Lance Andersen wrote: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 222: > 220: *

      The behavior for the case where the input stream is asynchronously > 221: * closed, or the thread interrupted during the read, is highly input > 222: * stream specific, and therefore not specified. I'm not 100% sure about copying this paragraph from InputStream.readAllBytes because ZipInputStream is a specific InputStream implementation. I would be tempted to just drop it. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 263: > 261: *

      The behavior for the case where the input stream is asynchronously > 262: * closed, or the thread interrupted during the read, is highly input > 263: * stream specific, and therefore not specified. This is another case where we might drop a paragraph because it's there to allow for a wide range of input stream implementations. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 273: > 271: * @implNote > 272: * The number of bytes allocated to read data from this stream and return > 273: * the result is bounded by {@code 2*(long)len}, inclusive. Maybe the implNote should just say that it calls super.readNBytes ? src/java.base/share/classes/java/util/zip/ZipInputStream.java line 309: > 307: *

      The behavior for the case where the input stream is asynchronously > 308: * closed, or the thread interrupted during the read, is highly input > 309: * stream specific, and therefore not specified. Another paragraph that probably shouldn't be copied from InputStream. src/java.base/share/classes/java/util/zip/ZipInputStream.java line 355: > 353: * invoked to read a single byte, and if it returns {@code -1}, then an > 354: * {@code EOFException} is thrown. Any exception thrown by {@code skip()} > 355: * or {@code read()} will be propagated. implSpec is usually for methods with a default or overrideable implementation. Yes, it's possible to extend ZipInputStream and override the skipNBytes method but it feels a bit too deep in the hierarchy to have this in the javadoc. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From alanb at openjdk.org Fri Nov 11 12:34:31 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 11 Nov 2022 12:34:31 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v4] In-Reply-To: <3soUDY9rkr9Rp1lQpO2LSMyQIZRTiZG9Cjhhj9gk6P0=.1bcff6e6-f2aa-4ca5-af01-c9a087194821@github.com> References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> <3soUDY9rkr9Rp1lQpO2LSMyQIZRTiZG9Cjhhj9gk6P0=.1bcff6e6-f2aa-4ca5-af01-c9a087194821@github.com> Message-ID: On Mon, 7 Nov 2022 14:24:18 GMT, Markus KARG wrote: > @AlanBateman I fixed what you asked for. Kindly requesting review. :-) I don't have any other comments. @bplb told me that he would sponsor this for you. ------------- PR: https://git.openjdk.org/jdk/pull/10999 From redestad at openjdk.org Fri Nov 11 12:34:34 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 11 Nov 2022 12:34:34 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v12] In-Reply-To: <4DATzQcc3E5BBS0xrbxkKDyI64Lt-vpKvtgTGDh6Rew=.5bb45e2c-65bd-4c38-9a30-47feac3a32ca@github.com> References: <4DATzQcc3E5BBS0xrbxkKDyI64Lt-vpKvtgTGDh6Rew=.5bb45e2c-65bd-4c38-9a30-47feac3a32ca@github.com> Message-ID: On Thu, 10 Nov 2022 15:03:26 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Qualified guess on shenandoahSupport fix-up The test failures in GHA are unrelated. Passed tier1-tier3 in our CI. Full benchmark results pending. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Fri Nov 11 12:43:12 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 11 Nov 2022 12:43:12 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v12] In-Reply-To: References: <5QCLl4R86LlhX9dkwbK7-NtPwkiN9tgQvj0VFoApvzU=.0b12f837-47d4-470a-9b40-961ccd8e181e@github.com> Message-ID: On Mon, 31 Oct 2022 12:25:43 GMT, Claes Redestad wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 3484: >> >>> 3482: decrementl(index); >>> 3483: jmpb(LONG_SCALAR_LOOP_BEGIN); >>> 3484: bind(LONG_SCALAR_LOOP_END); >> >> You can share this loop with the scalar ones above. > > This might be messier than it first looks, since the two different loops use different temp registers based (long scalar can scratch cnt1, short scalar scratches the coef register). I'll have to think about this for a bit. As it happens in the latest version the vector loop drops into the scalar loop after all 32-element chunks has been processed. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From dfuchs at openjdk.org Fri Nov 11 12:43:14 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 11 Nov 2022 12:43:14 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v12] In-Reply-To: <4DATzQcc3E5BBS0xrbxkKDyI64Lt-vpKvtgTGDh6Rew=.5bb45e2c-65bd-4c38-9a30-47feac3a32ca@github.com> References: <4DATzQcc3E5BBS0xrbxkKDyI64Lt-vpKvtgTGDh6Rew=.5bb45e2c-65bd-4c38-9a30-47feac3a32ca@github.com> Message-ID: On Thu, 10 Nov 2022 15:03:26 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Qualified guess on shenandoahSupport fix-up src/java.base/share/classes/java/lang/StringLatin1.java line 194: > 192: return switch (value.length) { > 193: case 0 -> 0; > 194: case 1 -> value[0]; shouldn't that be: case 1 -> value[0] & 0xff; ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Fri Nov 11 12:43:15 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 11 Nov 2022 12:43:15 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v12] In-Reply-To: References: <4DATzQcc3E5BBS0xrbxkKDyI64Lt-vpKvtgTGDh6Rew=.5bb45e2c-65bd-4c38-9a30-47feac3a32ca@github.com> Message-ID: On Fri, 11 Nov 2022 12:36:20 GMT, Daniel Fuchs wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Qualified guess on shenandoahSupport fix-up > > src/java.base/share/classes/java/lang/StringLatin1.java line 194: > >> 192: return switch (value.length) { >> 193: case 0 -> 0; >> 194: case 1 -> value[0]; > > shouldn't that be: > > case 1 -> value[0] & 0xff; Yes, good catch. I'll add a test case for negative latin1 bytes, too. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Fri Nov 11 13:00:06 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 11 Nov 2022 13:00:06 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: > Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. > > I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. > > Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. > > The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. > > With the most recent fixes the x64 intrinsic results on my workstation look like this: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op > StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op > StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op > StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op > > I.e. no measurable overhead compared to baseline even for `size == 1`. > > The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. > > Benchmark for `Arrays.hashCode`: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op > ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op > ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op > ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op > ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op > ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op > ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op > ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op > ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op > ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op > ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op > ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op > ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op > ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op > > Baseline: > > Benchmark (size) Mode Cnt Score Error Units > ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op > ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op > ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op > ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op > ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op > ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op > ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op > ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op > ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op > ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op > ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op > ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op > ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op > ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op > ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op > ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op > > > As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Missing & 0xff in StringLatin1::hashCode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10847/files - new: https://git.openjdk.org/jdk/pull/10847/files/871f6cef..f08a656c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10847&range=11-12 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10847.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10847/head:pull/10847 PR: https://git.openjdk.org/jdk/pull/10847 From duke at openjdk.org Fri Nov 11 13:25:35 2022 From: duke at openjdk.org (Piotr Tarsa) Date: Fri, 11 Nov 2022 13:25:35 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode I think that microbenchmarking the string and array hash code computation with fixed lengths is hiding branch misprediction penalties and they can be pretty high (double digits of cycles lost), even on modern high performance CPU cores that have relatively short pipeline (compared to e.g. Pentium 4). Real world scenarios will probably entail varying, unpredictable, but still short string lengths, so that should be reflected in microbenchmarks and also be given high importance. I see you've added benchmarks like that already: https://github.com/openjdk/jdk/pull/10847/files#diff-0b5a3d8f2d9f485100f701d0917ffac9cf090a023055398154fa9ef1a9681b64R126-R156 (multibytes, multiints, etc) but you don't report on their measurements. Could you add their results? Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Fri Nov 11 13:37:33 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 11 Nov 2022 13:37:33 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode > Yes, I had the same concern as @luhenry was obsessing about 0 and 1-element inputs and added the switches that we might be optimizing for extremely well-predicted micros, so he added those multi* variants. The overall result on both our setups is that we behave well even with mixed inputs, and with the new intrinsics the generated code end up on total a bit less branchy than the baseline across the range of input sizes. I'll upload full results for the multi*-micros once I have run the baseline and patched version thoroughly with no shortcuts. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From david.lloyd at redhat.com Fri Nov 11 14:31:23 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 11 Nov 2022 08:31:23 -0600 Subject: Unsigned long to double and back In-Reply-To: <15529cbc-c299-17c4-4bf8-2121b5f2e9bf@j-kuhn.de> References: <15529cbc-c299-17c4-4bf8-2121b5f2e9bf@j-kuhn.de> Message-ID: I encountered this issue as well; for now I'm using the following transformation: long tmp = input >>> 1; double output = ((double) tmp) * 2.0 + (tmp & 1); I... *think* it's correct but I'm not 100% sure and have a long-standing TODO to try and figure it out... On Sat, Nov 5, 2022 at 7:17 PM Johannes Kuhn wrote: > When I tried to implement an WASM transpiler, I noticed some missing > conversion methods from unsigned types to floating point, for example > from unsigned long to a double. > > For the meaning of unsigned long, see Long.toUnsignedString(long i). > > Converting between unsigned long and floating point is not a trivial > task, as it probably requires some bit manipulation. > > In particular, I would love to see the following methods added*: > > - double Double.fromUnsignedLong(long i) > - long Double.toUnsignedLong(double d) > - float Float.fromUnsignedLong(long i) > - long Float.toUnsignedLong(float f) > > * Subject to bikeshedding - I don't care about the name, or if it is > added to the Long class. > > Currently, I don't think that additional methods for unsigned int are > necessary - as it is possible to cast between long and int, but feel > free to correct me. > > In WASM, the specification for those methods can be found here: > > https://www.w3.org/TR/wasm-core-1/#op-trunc-u > https://www.w3.org/TR/wasm-core-1/#op-convert-u > > Note that the WASM specification is undefined for some values, notably > NaN, infinities, and values that fall out of the range. > > As *I* want to use it to implement WASM instructions, I do not have any > strong opinion on the undefined cases - for example, returning the > nearest unsigned long value or throwing an exception is fine for me. > > What do you think? > > - Johannes > > -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Fri Nov 11 14:38:31 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 11 Nov 2022 08:38:31 -0600 Subject: Unsigned long to double and back In-Reply-To: References: <15529cbc-c299-17c4-4bf8-2121b5f2e9bf@j-kuhn.de> Message-ID: Well, I typed this out from memory so there's an error, of course. `(tmp & 1)` should be `(input & 1)`. On Fri, Nov 11, 2022 at 8:31 AM David Lloyd wrote: > I encountered this issue as well; for now I'm using the following > transformation: > > long tmp = input >>> 1; > double output = ((double) tmp) * 2.0 + (tmp & 1); > > I... *think* it's correct but I'm not 100% sure and have a long-standing > TODO to try and figure it out... > > On Sat, Nov 5, 2022 at 7:17 PM Johannes Kuhn wrote: > >> When I tried to implement an WASM transpiler, I noticed some missing >> conversion methods from unsigned types to floating point, for example >> from unsigned long to a double. >> >> For the meaning of unsigned long, see Long.toUnsignedString(long i). >> >> Converting between unsigned long and floating point is not a trivial >> task, as it probably requires some bit manipulation. >> >> In particular, I would love to see the following methods added*: >> >> - double Double.fromUnsignedLong(long i) >> - long Double.toUnsignedLong(double d) >> - float Float.fromUnsignedLong(long i) >> - long Float.toUnsignedLong(float f) >> >> * Subject to bikeshedding - I don't care about the name, or if it is >> added to the Long class. >> >> Currently, I don't think that additional methods for unsigned int are >> necessary - as it is possible to cast between long and int, but feel >> free to correct me. >> >> In WASM, the specification for those methods can be found here: >> >> https://www.w3.org/TR/wasm-core-1/#op-trunc-u >> https://www.w3.org/TR/wasm-core-1/#op-convert-u >> >> Note that the WASM specification is undefined for some values, notably >> NaN, infinities, and values that fall out of the range. >> >> As *I* want to use it to implement WASM instructions, I do not have any >> strong opinion on the undefined cases - for example, returning the >> nearest unsigned long value or throwing an exception is fine for me. >> >> What do you think? >> >> - Johannes >> >> > > -- > - DML ? he/him > -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From redestad at openjdk.org Fri Nov 11 14:44:41 2022 From: redestad at openjdk.org (Claes Redestad) Date: Fri, 11 Nov 2022 14:44:41 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode Full JMH result comparison, linux-x64: https://jmh.morethan.io/?gist=014b1f9242ae3ad84cbbab893b738d48 Faster on all microbenchmarks and all input sizes. Up to 8x faster on large inputs. (Noting that the old StringHashCode::notCached and empty micros are not recalculating the hashCode since https://bugs.openjdk.org/browse/JDK-8221836 - the original intent of those microbenchmark was to test the hashing algorithm as per the new micros. We can probably remove those two..) ------------- PR: https://git.openjdk.org/jdk/pull/10847 From duke at openjdk.org Fri Nov 11 15:38:30 2022 From: duke at openjdk.org (Markus KARG) Date: Fri, 11 Nov 2022 15:38:30 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v4] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> <3soUDY9rkr9Rp1lQpO2LSMyQIZRTiZG9Cjhhj9gk6P0=.1bcff6e6-f2aa-4ca5-af01-c9a087194821@github.com> Message-ID: On Fri, 11 Nov 2022 12:32:10 GMT, Alan Bateman wrote: > I don't have any other comments. @bplb told me that he would sponsor this for you. Thanks, but I need a successful review logged first. :-) ------------- PR: https://git.openjdk.org/jdk/pull/10999 From forax at univ-mlv.fr Fri Nov 11 15:49:40 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 11 Nov 2022 16:49:40 +0100 (CET) Subject: Unsigned long to double and back In-Reply-To: References: <15529cbc-c299-17c4-4bf8-2121b5f2e9bf@j-kuhn.de> Message-ID: <1628085270.43961698.1668181780711.JavaMail.zimbra@u-pem.fr> Hi all, I don't know if it's the correct way to do it or if there is a better way, but i'm using var result = (double) (value & 0x7fffffffffffffffL ); if (value < 0) { result = result + 9.223372036854776E18; } The idea is to mask the sign bit, do the conversion to double and if the sign bit was present (if value < 0) add Long.MAX_VALUE + 1 (9223372036854775808) as a double. I've got 9.223372036854776E18 as the result of BigInteger.valueOf(Long.MAX_VALUE).add(BigInteger.ONE).doubleValue() R?mi > From: "David Lloyd" > To: "Johannes Kuhn" > Cc: "core-libs-dev" > Sent: Friday, November 11, 2022 3:38:31 PM > Subject: Re: Unsigned long to double and back > Well, I typed this out from memory so there's an error, of course. `(tmp & 1)` > should be `(input & 1)`. > On Fri, Nov 11, 2022 at 8:31 AM David Lloyd < [ mailto:david.lloyd at redhat.com | > david.lloyd at redhat.com ] > wrote: >> I encountered this issue as well; for now I'm using the following >> transformation: >> long tmp = input >>> 1; >> double output = ((double) tmp) * 2.0 + (tmp & 1); >> I... *think* it's correct but I'm not 100% sure and have a long-standing TODO to >> try and figure it out... >> On Sat, Nov 5, 2022 at 7:17 PM Johannes Kuhn < [ mailto:info at j-kuhn.de | >> info at j-kuhn.de ] > wrote: >>> When I tried to implement an WASM transpiler, I noticed some missing >>> conversion methods from unsigned types to floating point, for example >>> from unsigned long to a double. >>> For the meaning of unsigned long, see Long.toUnsignedString(long i). >>> Converting between unsigned long and floating point is not a trivial >>> task, as it probably requires some bit manipulation. >>> In particular, I would love to see the following methods added*: >>> - double Double.fromUnsignedLong(long i) >>> - long Double.toUnsignedLong(double d) >>> - float Float.fromUnsignedLong(long i) >>> - long Float.toUnsignedLong(float f) >>> * Subject to bikeshedding - I don't care about the name, or if it is >>> added to the Long class. >>> Currently, I don't think that additional methods for unsigned int are >>> necessary - as it is possible to cast between long and int, but feel >>> free to correct me. >>> In WASM, the specification for those methods can be found here: >>> [ https://www.w3.org/TR/wasm-core-1/#op-trunc-u | >>> https://www.w3.org/TR/wasm-core-1/#op-trunc-u ] >>> [ https://www.w3.org/TR/wasm-core-1/#op-convert-u | >>> https://www.w3.org/TR/wasm-core-1/#op-convert-u ] >>> Note that the WASM specification is undefined for some values, notably >>> NaN, infinities, and values that fall out of the range. >>> As *I* want to use it to implement WASM instructions, I do not have any >>> strong opinion on the undefined cases - for example, returning the >>> nearest unsigned long value or throwing an exception is fine for me. >>> What do you think? >>> - Johannes >> -- >> - DML ? he/him > -- > - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lloyd at redhat.com Fri Nov 11 16:08:48 2022 From: david.lloyd at redhat.com (David Lloyd) Date: Fri, 11 Nov 2022 10:08:48 -0600 Subject: Unsigned long to double and back In-Reply-To: <1628085270.43961698.1668181780711.JavaMail.zimbra@u-pem.fr> References: <15529cbc-c299-17c4-4bf8-2121b5f2e9bf@j-kuhn.de> <1628085270.43961698.1668181780711.JavaMail.zimbra@u-pem.fr> Message-ID: I'd be hesitant to do that in decimal; it's probably better to add `0x1.0p63` instead. But I guess the approaches are similar: shave off one bit, and then test that bit and adjust the result accordingly. On Fri, Nov 11, 2022 at 9:59 AM Remi Forax wrote: > Hi all, > I don't know if it's the correct way to do it or if there is a better way, > but i'm using > > var result = (double) (value & 0x7fffffffffffffffL); > if (value < 0) { > result = result + 9.223372036854776E18; > } > > > The idea is to mask the sign bit, do the conversion to double and if the > sign bit was present (if value < 0) add Long.MAX_VALUE + 1 > (9223372036854775808) as a double. > > I've got 9.223372036854776E18 as the result of > BigInteger.valueOf(Long.MAX_VALUE).add(BigInteger.ONE).doubleValue() > > R?mi > > ------------------------------ > > *From: *"David Lloyd" > *To: *"Johannes Kuhn" > *Cc: *"core-libs-dev" > *Sent: *Friday, November 11, 2022 3:38:31 PM > *Subject: *Re: Unsigned long to double and back > > Well, I typed this out from memory so there's an error, of course. `(tmp & > 1)` should be `(input & 1)`. > > On Fri, Nov 11, 2022 at 8:31 AM David Lloyd > wrote: > >> I encountered this issue as well; for now I'm using the following >> transformation: >> >> long tmp = input >>> 1; >> double output = ((double) tmp) * 2.0 + (tmp & 1); >> >> I... *think* it's correct but I'm not 100% sure and have a long-standing >> TODO to try and figure it out... >> >> On Sat, Nov 5, 2022 at 7:17 PM Johannes Kuhn wrote: >> >>> When I tried to implement an WASM transpiler, I noticed some missing >>> conversion methods from unsigned types to floating point, for example >>> from unsigned long to a double. >>> >>> For the meaning of unsigned long, see Long.toUnsignedString(long i). >>> >>> Converting between unsigned long and floating point is not a trivial >>> task, as it probably requires some bit manipulation. >>> >>> In particular, I would love to see the following methods added*: >>> >>> - double Double.fromUnsignedLong(long i) >>> - long Double.toUnsignedLong(double d) >>> - float Float.fromUnsignedLong(long i) >>> - long Float.toUnsignedLong(float f) >>> >>> * Subject to bikeshedding - I don't care about the name, or if it is >>> added to the Long class. >>> >>> Currently, I don't think that additional methods for unsigned int are >>> necessary - as it is possible to cast between long and int, but feel >>> free to correct me. >>> >>> In WASM, the specification for those methods can be found here: >>> >>> https://www.w3.org/TR/wasm-core-1/#op-trunc-u >>> https://www.w3.org/TR/wasm-core-1/#op-convert-u >>> >>> Note that the WASM specification is undefined for some values, notably >>> NaN, infinities, and values that fall out of the range. >>> >>> As *I* want to use it to implement WASM instructions, I do not have any >>> strong opinion on the undefined cases - for example, returning the >>> nearest unsigned long value or throwing an exception is fine for me. >>> >>> What do you think? >>> >>> - Johannes >>> >>> >> >> -- >> - DML ? he/him >> > > > -- > - DML ? he/him > > -- - DML ? he/him -------------- next part -------------- An HTML attachment was scrubbed... URL: From lancea at openjdk.org Fri Nov 11 17:16:38 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 11 Nov 2022 17:16:38 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v2] In-Reply-To: References: Message-ID: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Addressed latest set of input on the javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10995/files - new: https://git.openjdk.org/jdk/pull/10995/files/1ff2c0eb..72352cd0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=00-01 Stats: 27 lines in 1 file changed: 0 ins; 26 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Fri Nov 11 17:16:38 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 11 Nov 2022 17:16:38 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 18:13:23 GMT, Lance Andersen wrote: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. thank you Alan for your input. I have made the changes that you suggested. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Fri Nov 11 17:16:39 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 11 Nov 2022 17:16:39 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v2] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 12:22:32 GMT, Alan Bateman wrote: >> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: >> >> Addressed latest set of input on the javadoc > > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 222: > >> 220: *

      The behavior for the case where the input stream is asynchronously >> 221: * closed, or the thread interrupted during the read, is highly input >> 222: * stream specific, and therefore not specified. > > I'm not 100% sure about copying this paragraph from InputStream.readAllBytes because ZipInputStream is a specific InputStream implementation. I would be tempted to just drop it. Removed the paragraph > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 263: > >> 261: *

      The behavior for the case where the input stream is asynchronously >> 262: * closed, or the thread interrupted during the read, is highly input >> 263: * stream specific, and therefore not specified. > > This is another case where we might drop a paragraph because it's there to allow for a wide range of input stream implementations. Removed the paragraph > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 355: > >> 353: * invoked to read a single byte, and if it returns {@code -1}, then an >> 354: * {@code EOFException} is thrown. Any exception thrown by {@code skip()} >> 355: * or {@code read()} will be propagated. > > implSpec is usually for methods with a default or overrideable implementation. Yes, it's possible to extend ZipInputStream and override the skipNBytes method but it feels a bit too deep in the hierarchy to have this in the javadoc. Removed the implSpec ------------- PR: https://git.openjdk.org/jdk/pull/10995 From bpb at openjdk.org Fri Nov 11 17:26:24 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 11 Nov 2022 17:26:24 GMT Subject: RFR: 8296431 - PushbackInputStream should override transferTo [v5] In-Reply-To: References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: On Wed, 9 Nov 2022 07:11:53 GMT, Markus KARG wrote: >> This PR implements JDK-8296431 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused imports Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10999 From alanb at openjdk.org Fri Nov 11 17:48:29 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 11 Nov 2022 17:48:29 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v2] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 17:16:38 GMT, Lance Andersen wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Addressed latest set of input on the javadoc I think it would be useful to generate the javadoc and see if there are terminology or wording differences between the existing and new descriptions being copied down from input stream. For example, the no-arg read is "Reads a byte of uncompressed data from the input stream for the current ZIP entry" where the 3-arg read is "Reads from the current ZIP entry into an array of bytes, returning the number of inflated bytes". So one speaks of reading from the input stream, the other of reading from the current the ZIP entry. One speaks of reading uncompressed data, the other is returning inflated bytes. Another example is the skip methods. The no-arg skip speaks of skipping bytes in the current ZIP entry. The skipNBytes speaks of skipping and discard bytes of data from the input stream. The available method might need attention too because it it specified a result for when EOF for the current entry data is reached. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Fri Nov 11 18:56:36 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 11 Nov 2022 18:56:36 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v3] In-Reply-To: References: Message-ID: <-0Q0h_UtylKQv5-dW1cuCBK9WYV4b8JIucg8u_d-QEs=.ba653186-4a38-4af0-87b7-6aacf245f2ef@github.com> > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Updated a javadoc for more consistentcy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10995/files - new: https://git.openjdk.org/jdk/pull/10995/files/72352cd0..76235c9a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=01-02 Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Fri Nov 11 18:56:37 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 11 Nov 2022 18:56:37 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v2] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 17:46:08 GMT, Alan Bateman wrote: > I think it would be useful to generate the javadoc and see if there are terminology or wording differences between the existing and new descriptions being copied down from input stream. > > For example, the no-arg read is "Reads a byte of uncompressed data from the input stream for the current ZIP entry" where the 3-arg read is "Reads from the current ZIP entry into an array of bytes, returning the number of inflated bytes". So one speaks of reading from the input stream, the other of reading from the current the ZIP entry. One speaks of reading uncompressed data, the other is returning inflated bytes. Another example is the skip methods. The no-arg skip speaks of skipping bytes in the current ZIP entry. The skipNBytes speaks of skipping and discard bytes of data from the input stream. The available method might need attention too because it it specified a result for when EOF for the current entry data is reached. Thanks for the suggestion. I made another pass to make the phrasing more consistent ------------- PR: https://git.openjdk.org/jdk/pull/10995 From rriggs at openjdk.org Fri Nov 11 21:50:41 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 11 Nov 2022 21:50:41 GMT Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 [v2] In-Reply-To: References: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> Message-ID: On Thu, 10 Nov 2022 12:33:05 GMT, Jaikiran Pai wrote: > One final question - Now with this change, `Process.waitFor()` won't throw the `IllegalThreadStateException` for such programs that return `STILL_ACTIVE` exit code. However, looking at the code a subsequent Process.exitValue() call on that same process instance will still throw this exception. Should we be changing that too? To fix that we'd have to find another Windows API to determine if the process had exited. >From the Windows API description, `GetExitCodeProcess` seems to be the recommended way. Also if `exitValue()` returned `STILL_ACTIVE` it would still be confusing to the program/programmer about whether the process had exited and where that exitValue came from. I think the current Windows admonition about returning STILL_ACTIVE to "don't do that" is sufficient. ------------- PR: https://git.openjdk.org/jdk/pull/10680 From jpai at openjdk.org Sat Nov 12 01:38:40 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 12 Nov 2022 01:38:40 GMT Subject: RFR: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 [v2] In-Reply-To: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> References: <7fmv6Ltfyz6C4dDJNOtVgNwm0q6Dvl1JtDMJ04vgxcw=.0301eff4-eb43-4822-9f8f-2cd47e4eb3d6@github.com> Message-ID: On Tue, 8 Nov 2022 16:04:25 GMT, Roger Riggs wrote: >> Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259. >> As described in the bug report, `waitFor()` should not be sensitive to the exit value. >> Previously, it erroneously threw IllegalStateException. >> Added a test to verify. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Test cleanup as suggested by review comments. Thank you Roger. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/10680 From vlivanov at openjdk.org Sat Nov 12 02:06:33 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 12 Nov 2022 02:06:33 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode I haven't closely looked at the stub itself. Commented mostly on C2 and JDK parts. src/hotspot/cpu/x86/x86_64.ad line 12073: > 12071: legRegD tmp_vec13, rRegI tmp1, rRegI tmp2, rRegI tmp3, rFlagsReg cr) > 12072: %{ > 12073: predicate(UseAVX >= 2 && ((VectorizedHashCodeNode*)n)->mode() == VectorizedHashCodeNode::LATIN1); If you represent `VectorizedHashCodeNode::mode()` as an input, it would allow to abstract over supported modes and come up with a single AD instruction. Take a look at `VectorMaskCmp` for an example (not a perfect one though since it has both _predicate member and constant input which is redundant). src/hotspot/cpu/x86/x86_64.ad line 12081: > 12079: format %{ "Array HashCode byte[] $ary1,$cnt1 -> $result // KILL all" %} > 12080: ins_encode %{ > 12081: __ arrays_hashcode($ary1$$Register, $cnt1$$Register, $result$$Register, What's the motivation to keep the stub code inlined instead of calling into a stand-alone pre-generated version of the stub? src/hotspot/share/opto/intrinsicnode.hpp line 175: > 173: // as well as adjusting for special treatment of various encoding of String > 174: // arrays. Must correspond to declared constants in jdk.internal.util.ArraysSupport > 175: typedef enum HashModes { LATIN1 = 0, UTF16 = 1, BYTE = 2, CHAR = 3, SHORT = 4, INT = 5 } HashMode; I question the need for `LATIN1` and `UTF16` modes. If you lift some of input adjustments (initial value and input size) into JDK, it becomes indistinguishable from `BYTE`/`CHAR`. Then you can reuse existing constants for basic types. src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 185: > 183: */ > 184: @IntrinsicCandidate > 185: public static int vectorizedHashCode(Object array, byte mode) { The intrinsic can be generalized by: 1. expanding `array` input into `base`, `offset`, and `length`. It will make it applicable to any type of data source (on-heap/off-heap `ByteBuffer`s, `MemorySegment`s. 2. passing initial value as a parameter. Basically, hash code computation can be represented as a reduction: `reduce(initial_val, (acc, v) -> 31 * acc + v, data)`. You hardcode the operation, but can make the rest variable. (Even the operation can be slightly generalized if you make 31 variable and then precompute the table at runtime. But right now I don't see much value in investing into that.) ------------- PR: https://git.openjdk.org/jdk/pull/10847 From vlivanov at openjdk.org Sat Nov 12 02:06:33 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 12 Nov 2022 02:06:33 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 00:55:56 GMT, Vladimir Ivanov wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing & 0xff in StringLatin1::hashCode > > src/hotspot/cpu/x86/x86_64.ad line 12081: > >> 12079: format %{ "Array HashCode byte[] $ary1,$cnt1 -> $result // KILL all" %} >> 12080: ins_encode %{ >> 12081: __ arrays_hashcode($ary1$$Register, $cnt1$$Register, $result$$Register, > > What's the motivation to keep the stub code inlined instead of calling into a stand-alone pre-generated version of the stub? Also, switching to stand-alone stubs would enable us to compose a generic stub version (as we do in `StubGenerator::generate_generic_copy()` for arraycopy stubs). But it would be even better to do the dispatching on JDK side and always pass a constant into the intrinsic. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From vlivanov at openjdk.org Sat Nov 12 02:10:40 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 12 Nov 2022 02:10:40 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode Also, I'd like to note that C2 auto-vectorization support is not too far away from being able to optimize hash code computations. At some point, I was able to achieve some promising results with modest tweaking of SuperWord pass: https://github.com/iwanowww/jdk/blob/superword/notes.txt http://cr.openjdk.java.net/~vlivanov/superword.reduction/webrev.00/ ------------- PR: https://git.openjdk.org/jdk/pull/10847 From duke at openjdk.org Sat Nov 12 07:19:41 2022 From: duke at openjdk.org (danieljarabek) Date: Sat, 12 Nov 2022 07:19:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 17:42:04 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Requested changes #5 src/java.base/share/classes/java/util/FormatterBuilder.java line 52: > 50: /** > 51: * This package private class supports the construction of the {@link MethodHandle} > 52: * returned by {@Link Formatter#formatFactory}. Suggestion: * returned by {@link Formatter#formatFactory}. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From alanb at openjdk.org Sat Nov 12 12:31:08 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 12 Nov 2022 12:31:08 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v2] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 18:51:49 GMT, Lance Andersen wrote: > Thanks for the suggestion. I made another pass to make the phrasing more consistent Good, I think it looks much better now except for the "available" method which doesn't fully specify the cases for when it returns 0. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From alanb at openjdk.org Sat Nov 12 12:31:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 12 Nov 2022 12:31:11 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v3] In-Reply-To: <-0Q0h_UtylKQv5-dW1cuCBK9WYV4b8JIucg8u_d-QEs=.ba653186-4a38-4af0-87b7-6aacf245f2ef@github.com> References: <-0Q0h_UtylKQv5-dW1cuCBK9WYV4b8JIucg8u_d-QEs=.ba653186-4a38-4af0-87b7-6aacf245f2ef@github.com> Message-ID: On Fri, 11 Nov 2022 18:56:36 GMT, Lance Andersen wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Updated a javadoc for more consistentcy src/java.base/share/classes/java/util/zip/ZipInputStream.java line 177: > 175: /** > 176: * Returns 0 after EOF has reached for the current ZIP entry, > 177: * otherwise always return 1. I think it will need to say that input stream for the current ZIP entry has been read to end of stream, or the ZIP entry has been closed with closeEntry. That will cover the two cases where it returns 0. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From duke at openjdk.org Sat Nov 12 15:29:21 2022 From: duke at openjdk.org (Piotr Tarsa) Date: Sat, 12 Nov 2022 15:29:21 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode Out of curiosity: how does this intrinsic affect time-to-safepoint? Does it matter? I don't see any safepoint poll, but then I don't precisely know how safepoints work, so I could be missing something. Theoretically, with 2^31 elements count limit in Java, the whole computation is always a fraction of a second, but maybe it would matter with e.g. ZGC, which could ask for a safepoint while the thread is hashing an array with 2 billion ints. > 1. expanding `array` input into `base`, `offset`, and `length`. It will make it applicable to any type of data source (on-heap/off-heap `ByteBuffer`s, `MemorySegment`s. There could be memory-mapped ByteBuffers and MemorySegments and that would make the whole hashing operation much more prone to be exceedingly long and therefore possibly dramatically affecting time-to-safepoint. Again, this could be misunderstanding on my side, but I'm curious how safepoints interplay with this intrinsic. Also, even without memory mapping, MemorySegments can be much larger than 2^31 elements in size, so hashing a huge MemorySegment could take much longer than hashing even the biggest ordinary (limited by 31-bit indexing) array of primitives. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From jlaskey at openjdk.org Sat Nov 12 15:46:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Sat, 12 Nov 2022 15:46:48 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v17] In-Reply-To: References: Message-ID: <-JDH0Yc-zlRdN_7CTe6pVBhAFqqo1sdx8SBYn6iXhUE=.d03f0002-a92f-4fd7-9ef8-f431d5590717@github.com> On Sat, 12 Nov 2022 07:17:30 GMT, danieljarabek wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Requested changes #5 > > src/java.base/share/classes/java/util/FormatterBuilder.java line 52: > >> 50: /** >> 51: * This package private class supports the construction of the {@link MethodHandle} >> 52: * returned by {@Link Formatter#formatFactory}. > > Suggestion: > > * returned by {@link Formatter#formatFactory}. Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jwaters at openjdk.org Sat Nov 12 16:45:19 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 12 Nov 2022 16:45:19 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features Message-ID: After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cases were caught by the very briefly integrated 8296115 ------------- Commit messages: - More Style Changes - Minor Style Changes - Merge remote-tracking branch 'upstream/master' into conformance - Missed an attribute - Oops v2 - Resolve Conflict - This will likely fail, but that's not important - Further formatting - Merge jdkMerge remote-tracking branch 'upstream/master' into warnings - Code style - ... and 53 more: https://git.openjdk.org/jdk/compare/657a0b2f...6d85c432 Changes: https://git.openjdk.org/jdk/pull/11081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295146 Stats: 254 lines in 48 files changed: 100 ins; 23 del; 131 mod Patch: https://git.openjdk.org/jdk/pull/11081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11081/head:pull/11081 PR: https://git.openjdk.org/jdk/pull/11081 From redestad at openjdk.org Sun Nov 13 19:54:44 2022 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 13 Nov 2022 19:54:44 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 15:27:09 GMT, Piotr Tarsa wrote: > Out of curiosity: how does this intrinsic affect time-to-safepoint? Does it matter? I don't see any safepoint poll, but then I don't precisely know how safepoints work, so I could be missing something. Theoretically, with 2^31 elements count limit in Java, the whole computation is always a fraction of a second, but maybe it would matter with e.g. ZGC, which could ask for a safepoint while the thread is hashing an array with 2 billion ints. This intrinsic - like several others before it - does not add safepoint checks. There's at least one RFE filed to address this deficiency, and hopefully we can come up with a shared strategy to interleave safepoint checks in the various intrinsics that operate over Strings and arrays: https://bugs.openjdk.org/browse/JDK-8233300 When I brought this up to an internal discussion with @TobiHartmann and @fisk last week several challenges were brought up to the table, including how to deal with all the different contingencies that might be the result of a safepoint, including deoptimization. I think enhancing these intrinsics to poll for safepoints is important to tackle tail-end latencies for extremely latency sensitive applications. In the meantime those applications could (should?) turn off such intrinsics, avoid huge arrays altogether, or both. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Sun Nov 13 21:01:08 2022 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 13 Nov 2022 21:01:08 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 01:06:27 GMT, Vladimir Ivanov wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing & 0xff in StringLatin1::hashCode > > src/hotspot/cpu/x86/x86_64.ad line 12073: > >> 12071: legRegD tmp_vec13, rRegI tmp1, rRegI tmp2, rRegI tmp3, rFlagsReg cr) >> 12072: %{ >> 12073: predicate(UseAVX >= 2 && ((VectorizedHashCodeNode*)n)->mode() == VectorizedHashCodeNode::LATIN1); > > If you represent `VectorizedHashCodeNode::mode()` as an input, it would allow to abstract over supported modes and come up with a single AD instruction. Take a look at `VectorMaskCmp` for an example (not a perfect one though since it has both _predicate member and constant input which is redundant). Thanks for the pointer, I'll check it out! ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Sun Nov 13 21:01:09 2022 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 13 Nov 2022 21:01:09 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 01:10:50 GMT, Vladimir Ivanov wrote: >> src/hotspot/cpu/x86/x86_64.ad line 12081: >> >>> 12079: format %{ "Array HashCode byte[] $ary1,$cnt1 -> $result // KILL all" %} >>> 12080: ins_encode %{ >>> 12081: __ arrays_hashcode($ary1$$Register, $cnt1$$Register, $result$$Register, >> >> What's the motivation to keep the stub code inlined instead of calling into a stand-alone pre-generated version of the stub? > > Also, switching to stand-alone stubs would enable us to compose a generic stub version (as we do in `StubGenerator::generate_generic_copy()` for arraycopy stubs). But it would be even better to do the dispatching on JDK side and always pass a constant into the intrinsic. There are no single reason this code evolved the way it did. @luhenry worked on it initially and was guided towards intrinsifying what was originally a JDK-level unrolling. Then I took over and have tried to find a path of least resistance from there. @luhenry have discussed rewriting part or all of this as a stub, for various reasons. I've been scoping that out, but with no experience writing stub versions I figured perhaps this could be done in a follow-up. If you think there's a compelling enough reason to rewrite this as a stub up front I can try and find the time to do so. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Sun Nov 13 21:03:26 2022 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 13 Nov 2022 21:03:26 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 01:28:51 GMT, Vladimir Ivanov wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing & 0xff in StringLatin1::hashCode > > src/hotspot/share/opto/intrinsicnode.hpp line 175: > >> 173: // as well as adjusting for special treatment of various encoding of String >> 174: // arrays. Must correspond to declared constants in jdk.internal.util.ArraysSupport >> 175: typedef enum HashModes { LATIN1 = 0, UTF16 = 1, BYTE = 2, CHAR = 3, SHORT = 4, INT = 5 } HashMode; > > I question the need for `LATIN1` and `UTF16` modes. If you lift some of input adjustments (initial value and input size) into JDK, it becomes indistinguishable from `BYTE`/`CHAR`. Then you can reuse existing constants for basic types. UTF16 can easily be replaced with CHAR by lifting up the shift as you say, but LATIN1 needs to be distinguished from BYTE since the former needs unsigned semantics. Modeling in a signed/unsigned input is possible, but I figured we might as well call it UNSIGNED_BYTE and decouple it logically from String::LATIN1. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Sun Nov 13 21:07:38 2022 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 13 Nov 2022 21:07:38 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sat, 12 Nov 2022 01:35:39 GMT, Vladimir Ivanov wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Missing & 0xff in StringLatin1::hashCode > > src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 185: > >> 183: */ >> 184: @IntrinsicCandidate >> 185: public static int vectorizedHashCode(Object array, byte mode) { > > The intrinsic can be generalized by: > 1. expanding `array` input into `base`, `offset`, and `length`. It will make it applicable to any type of data source (on-heap/off-heap `ByteBuffer`s, `MemorySegment`s. > 2. passing initial value as a parameter. > > Basically, hash code computation can be represented as a reduction: `reduce(initial_val, (acc, v) -> 31 * acc + v, data)`. You hardcode the operation, but can make the rest variable. > > (Even the operation can be slightly generalized if you make 31 variable and then precompute the table at runtime. But right now I don't see much value in investing into that.) I've been thinking of generalizing as thus as a possible follow-up: get the base operation on entire arrays in, then generalize carefully while ensuring that doesn't add too much complexity, introduce unforeseen overheads etc. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From redestad at openjdk.org Sun Nov 13 21:12:21 2022 From: redestad at openjdk.org (Claes Redestad) Date: Sun, 13 Nov 2022 21:12:21 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> References: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> Message-ID: On Sat, 12 Nov 2022 02:08:19 GMT, Vladimir Ivanov wrote: > Also, I'd like to note that C2 auto-vectorization support is not too far away from being able to optimize hash code computations. At some point, I was able to achieve some promising results with modest tweaking of SuperWord pass: https://github.com/iwanowww/jdk/blob/superword/notes.txt http://cr.openjdk.java.net/~vlivanov/superword.reduction/webrev.00/ Intriguing. How far off is this - and do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc? If we turn this intrinsic into a stub we might also be able to reuse the optimization in other places, including from within the VM (calculating String hashCodes happen in a couple of places, including String deduplication). So I think there are still a few compelling reasons to go the manual route and continue on this path. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From lancea at openjdk.org Sun Nov 13 21:42:38 2022 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 13 Nov 2022 21:42:38 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v4] In-Reply-To: References: Message-ID: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Tweak available() javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10995/files - new: https://git.openjdk.org/jdk/pull/10995/files/76235c9a..b7e102b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=02-03 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Sun Nov 13 21:42:39 2022 From: lancea at openjdk.org (Lance Andersen) Date: Sun, 13 Nov 2022 21:42:39 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v3] In-Reply-To: References: <-0Q0h_UtylKQv5-dW1cuCBK9WYV4b8JIucg8u_d-QEs=.ba653186-4a38-4af0-87b7-6aacf245f2ef@github.com> Message-ID: On Sat, 12 Nov 2022 12:27:30 GMT, Alan Bateman wrote: > I think it will need to say that input stream for the current ZIP entry has been read to end of stream, or the ZIP entry has been closed with closeEntry. That will cover the two cases where it returns 0. Thank you Alan. I have revised the wording per your suggestion and updated the CSR (which would be great if you could review if you are good with the revision. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From dholmes at openjdk.org Sun Nov 13 23:29:06 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 13 Nov 2022 23:29:06 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 06:20:41 GMT, Julian Waters wrote: > After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 > > No changes to the behaviour of the JDK has resulted in any way from this commit This looks good in general. It is a pity there is so much simple moving of where "attributes" are listed, as it makes it look like the changes are more extensive than they really are - that said I prefer to see the attributes appear before a function/method signature rather than after, or somewhere in-between. A few other comments below. Thanks. make/autoconf/flags-cflags.m4 line 632: > 630: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then > 631: STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \ > 632: -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'" So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right? src/hotspot/os/linux/os_perf_linux.cpp line 233: > 231: * Ensure that 'fmt' does _NOT_ contain the first two "%d %s" > 232: */ > 233: SCANF_ARGS(2, 0) static int vread_statdata(const char* procfile, _SCANFMT_ const char* fmt, va_list args) { If `SCANF_ARGS` can/must come first then I suggest adding a newline after it so the method signature is easier to spot. Applied everywhere of course. src/hotspot/os/windows/os_windows.hpp line 35: > 33: class Thread; > 34: > 35: static unsigned __stdcall thread_native_entry(Thread*); Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 src/hotspot/share/cds/filemap.hpp line 482: > 480: > 481: // Errors. > 482: ATTRIBUTE_PRINTF(1, 2) static void fail_stop(const char *msg, ...); Again I suggest a newline after `ATTRIBUTE_PRINTF` src/hotspot/share/utilities/compilerWarnings.hpp line 47: > 45: #endif > 46: > 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`. Update: I see the inconsistency with `compilerWarnings_visCPP.hpp` src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37: > 35: #endif > 36: > 37: #if defined(__clang_major__) && \ Not clear why this was moved ?? src/hotspot/share/utilities/debug.hpp line 172: > 170: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5); > 171: void report_vm_out_of_memory(const char* file, int line, size_t size, VMErrorType vm_err_type, > 172: const char* detail_fmt, ...) ATTRIBUTE_PRINTF(5, 6); Why were the ATTRIBUTE_PRINTFs removed? ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 01:22:47 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 01:22:47 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features In-Reply-To: References: Message-ID: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> On Sun, 13 Nov 2022 22:59:01 GMT, David Holmes wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > src/hotspot/os/windows/os_windows.hpp line 35: > >> 33: class Thread; >> 34: >> 35: static unsigned __stdcall thread_native_entry(Thread*); > > Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`: > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 I'm not sure I follow, I didn't remove anything here? > src/hotspot/share/utilities/compilerWarnings.hpp line 47: > >> 45: #endif >> 46: >> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING > > Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`. > Update: I see the inconsistency with `compilerWarnings_visCPP.hpp` Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 01:38:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 01:38:18 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 23:07:35 GMT, David Holmes wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37: > >> 35: #endif >> 36: >> 37: #if defined(__clang_major__) && \ > > Not clear why this was moved ?? I'm not sure which one you're referring to, but the PRAGMA_DIAG_PUSH/POP was moved up to the top of the header to match compilerWarnings_visCPP.hpp, and PRAGMA_DISABLE_GCC_WARNING_AUX was moved to macros.hpp as the more general PRAGMA macro, since it's useful for all compilers and not just gcc ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 01:41:24 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 01:41:24 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 23:08:53 GMT, David Holmes wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > src/hotspot/share/utilities/debug.hpp line 172: > >> 170: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...) ATTRIBUTE_PRINTF(4, 5); >> 171: void report_vm_out_of_memory(const char* file, int line, size_t size, VMErrorType vm_err_type, >> 172: const char* detail_fmt, ...) ATTRIBUTE_PRINTF(5, 6); > > Why were the ATTRIBUTE_PRINTFs removed? The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 01:46:16 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 01:46:16 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 23:16:47 GMT, David Holmes wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > make/autoconf/flags-cflags.m4 line 632: > >> 630: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then >> 631: STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \ >> 632: -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'" > > So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right? Yep, just something that C++ does a little neater, at least in my view ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 04:14:24 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 04:14:24 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: Message-ID: > After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 > > No changes to the behaviour of the JDK has resulted in any way from this commit Julian Waters has updated the pull request incrementally with one additional commit since the last revision: ATTRIBUTE_SCANF ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11081/files - new: https://git.openjdk.org/jdk/pull/11081/files/6d85c432..bb3ef0dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=00-01 Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11081/head:pull/11081 PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 04:14:26 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 04:14:26 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 22:58:11 GMT, David Holmes wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> ATTRIBUTE_SCANF > > src/hotspot/os/linux/os_perf_linux.cpp line 233: > >> 231: * Ensure that 'fmt' does _NOT_ contain the first two "%d %s" >> 232: */ >> 233: SCANF_ARGS(2, 0) static int vread_statdata(const char* procfile, _SCANFMT_ const char* fmt, va_list args) { > > If `SCANF_ARGS` can/must come first then I suggest adding a newline after it so the method signature is easier to spot. Applied everywhere of course. Resolved, thanks ------------- PR: https://git.openjdk.org/jdk/pull/11081 From thartmann at openjdk.org Mon Nov 14 06:16:33 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 14 Nov 2022 06:16:33 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode For the record, we have [JDK-8233300](https://bugs.openjdk.org/browse/JDK-8233300) to investigate safepoint-aware intrinsics. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From alanb at openjdk.org Mon Nov 14 07:19:15 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 14 Nov 2022 07:19:15 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v4] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 21:42:38 GMT, Lance Andersen wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Tweak available() javadoc src/java.base/share/classes/java/util/zip/ZipInputStream.java line 179: > 177: * {@link #closeEntry()} has been called, otherwise always return 1. > 178: * I think it will need to say that input stream for the current ZIP entry has been read to end of stream, or the > 179: * ZIP entry has been closed with closeEntry A comment from the PR has been pasted here :-) Ignoring that, the updated description for the "available" method looks okay. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From dholmes at openjdk.org Mon Nov 14 08:07:34 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Nov 2022 08:07:34 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> References: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> Message-ID: On Mon, 14 Nov 2022 01:17:38 GMT, Julian Waters wrote: >> src/hotspot/os/windows/os_windows.hpp line 35: >> >>> 33: class Thread; >>> 34: >>> 35: static unsigned __stdcall thread_native_entry(Thread*); >> >> Why was this removed? This is needed to correctly specify the call sequence for the thread entry routine when used with `_beginThreadex`: >> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 > > I'm not sure I follow, I didn't remove anything here? Sorry my eyes must be playing tricks on me. ?? Why did you need to add this here? >> src/hotspot/share/utilities/compilerWarnings.hpp line 47: >> >>> 45: #endif >>> 46: >>> 47: #ifndef PRAGMA_DISABLE_VISCPP_WARNING >> >> Why rename this from `MSVC` to `VISCPP`? IIRC the full name is Microsft Visual Studio C++, so you new name is not obviously better and the change just adds noise to the PR. Further `MSVC` matches what MS themselves use and even the attribute namespace in C++11 is `MSVC`. >> Update: I see the inconsistency with `compilerWarnings_visCPP.hpp` > > Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change I think it is the file that has the "bad" name in this case. :( But okay. >> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 37: >> >>> 35: #endif >>> 36: >>> 37: #if defined(__clang_major__) && \ >> >> Not clear why this was moved ?? > > I'm not sure which one you're referring to, but the PRAGMA_DIAG_PUSH/POP was moved up to the top of the header to match compilerWarnings_visCPP.hpp, and PRAGMA_DISABLE_GCC_WARNING_AUX was moved to macros.hpp as the more general PRAGMA macro, since it's useful for all compilers and not just gcc Okay ------------- PR: https://git.openjdk.org/jdk/pull/11081 From dholmes at openjdk.org Mon Nov 14 08:10:45 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 14 Nov 2022 08:10:45 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: Message-ID: <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com> On Mon, 14 Nov 2022 01:39:17 GMT, Julian Waters wrote: >> src/hotspot/share/utilities/debug.hpp line 172: >> >>> 170: int status, const char* detail); >>> 171: ATTRIBUTE_PRINTF(4, 5) >>> 172: void report_fatal(VMErrorType error_type, const char* file, int line, const char* detail_fmt, ...); >> >> Why were the ATTRIBUTE_PRINTFs removed? > > The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods Wow I'm really having eyesight problems today! Sorry about that. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From stuefe at openjdk.org Mon Nov 14 08:30:35 2022 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 14 Nov 2022 08:30:35 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > ATTRIBUTE_SCANF Hi Julian, unfortunately, your patch will make backporting more difficult. We cannot downport it to older releases compiled with older compilers. But since it touches a lot of files it will sit smack in the middle of patch sequences, requiring manual merges for patches after it. Is there any benefit to using the new syntax compared to the old one? It does seem similar verbose, so I don't see any benefit there. Cheers, Thomas ------------- PR: https://git.openjdk.org/jdk/pull/11081 From alanb at openjdk.org Mon Nov 14 09:02:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 14 Nov 2022 09:02:21 GMT Subject: RFR: 8296405: java/util/concurrent/forkjoin/AsyncShutdownNow.java is too slow Message-ID: java/util/concurrent/forkjoin/AsyncShutdownNow.java takes ~40s as each test uses a delay of 5s before it invokes shutdownNow. The test will run in <1s if changed to poll the thread state and invoke shutdownNow when the thread waits. The update temporarily disables testInvokeAny because of a suspected issue doing shutdown at around the same that worker threads are spinning up. It duplicates more frequently (on Windows at least) with the updated test. JDK-8286352 and JDK-8288899 are two bugs on this issue. Doug Lea is looking into the issue. The test can be re-enabled when that issue is resolved. ------------- Commit messages: - Disable testInvokeAny - Merge - Initial commit Changes: https://git.openjdk.org/jdk/pull/10986/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10986&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296405 Stats: 108 lines in 1 file changed: 50 ins; 41 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/10986.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10986/head:pull/10986 PR: https://git.openjdk.org/jdk/pull/10986 From jpai at openjdk.org Mon Nov 14 09:39:36 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 14 Nov 2022 09:39:36 GMT Subject: RFR: 8296405: java/util/concurrent/forkjoin/AsyncShutdownNow.java is too slow In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:13:42 GMT, Alan Bateman wrote: > java/util/concurrent/forkjoin/AsyncShutdownNow.java takes ~40s as each test uses a delay of 5s before it invokes shutdownNow. The test will run in <1s if changed to poll the thread state and invoke shutdownNow when the thread waits. > > The update temporarily disables testInvokeAny because of a suspected issue doing shutdown at around the same that worker threads are spinning up. It duplicates more frequently (on Windows at least) with the updated test. JDK-8286352 and JDK-8288899 are two bugs on this issue. Doug Lea is looking into the issue. The test can be re-enabled when that issue is resolved. Looks fine to me. Unexpected exceptions could happen in `onWait` and could mean the `action` never gets run or the `action` itself fails. That exception isn't propagated back, but I believe that's fine in the case of these tests because these tests run a task which sleeps for a day. So, if the (`shutdownNow`) action doesn't get run for whatever reason, these tests will fail with a jtreg test timeout and will have the stacktrace printed on System.err from the implementation of the `onWait`. test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java line 131: > 129: * Test shutdownNow with thread blocked in invokeAny. > 130: */ > 131: @Test(dataProvider = "executors", enabled = false) Should we file a JBS to re-enable this so that we don't forget? ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/10986 From lancea at openjdk.org Mon Nov 14 11:07:27 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 11:07:27 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v5] In-Reply-To: References: Message-ID: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Remove rogue comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10995/files - new: https://git.openjdk.org/jdk/pull/10995/files/b7e102b9..3a01b802 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Mon Nov 14 11:10:51 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 11:10:51 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v4] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 07:17:01 GMT, Alan Bateman wrote: > A comment from the PR has been pasted here :-) > Ignoring that, the updated description for the "available" method looks okay but might be clearer to say that closeEntry has been called on the current entry. whoops, fixed :-) ------------- PR: https://git.openjdk.org/jdk/pull/10995 From aph at openjdk.org Mon Nov 14 11:11:27 2022 From: aph at openjdk.org (Andrew Haley) Date: Mon, 14 Nov 2022 11:11:27 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 08:28:04 GMT, Thomas Stuefe wrote: > unfortunately, your patch will make backporting more difficult. We cannot downport it to older releases compiled with older compilers. But since it touches a lot of files it will sit smack in the middle of patch sequences, requiring manual merges for patches after it. > > Is there any benefit to using the new syntax compared to the old one? It does seem similar verbose, so I don't see any benefit there. I have to agree with Thomas here. Newer is not always better. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 12:00:28 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 12:00:28 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com> References: <_hwdz6oHBktC95v1xdiK-szAPmho2bxrDMCWBUAPGo0=.2ff0735d-5fda-4322-ac1f-1b4bec31dc56@github.com> Message-ID: On Mon, 14 Nov 2022 08:08:40 GMT, David Holmes wrote: >> The ATTRIBUTE_PRINTF macros are still there, just moved in front of the methods > > Wow I'm really having eyesight problems today! Sorry about that. Haha, no worries ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Mon Nov 14 12:24:31 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 12:24:31 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> Message-ID: On Mon, 14 Nov 2022 08:01:27 GMT, David Holmes wrote: >> I'm not sure I follow, I didn't remove anything here? > > Sorry my eyes must be playing tricks on me. ?? > > Why did you need to add this here? It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11: > The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage. While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead: > ?11.3/4 [class.friend] A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1). ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jlaskey at openjdk.org Mon Nov 14 12:48:50 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 14 Nov 2022 12:48:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v18] In-Reply-To: References: Message-ID: <3LrmIC3Q0YpqZVfaQw5q4t3moloj7cl81H4iOomail4=.e7bc7f08-6520-4aa2-995a-e97b1f103c0c@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #7 @Stable removal process decl in TemplateProcessor and StringProcessor for specialized javadoc clean up FormatterBuilder javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/ac5402ed..2dc2cad2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=16-17 Stats: 31 lines in 6 files changed: 20 ins; 7 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From kbarrett at openjdk.org Mon Nov 14 13:42:02 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 14 Nov 2022 13:42:02 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > ATTRIBUTE_SCANF Changes requested by kbarrett (Reviewer). make/hotspot/lib/CompileJvm.gmk line 67: > 65: # Hotspot cannot handle an empty build number > 66: VERSION_BUILD := 0 > 67: endif I think the proposed "solution" is *much* worse than this. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From kbarrett at openjdk.org Mon Nov 14 13:42:04 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 14 Nov 2022 13:42:04 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v2] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 01:42:40 GMT, Julian Waters wrote: >> make/autoconf/flags-cflags.m4 line 632: >> >>> 630: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then >>> 631: STATIC_LIBS_CFLAGS="$STATIC_LIBS_CFLAGS -ffunction-sections -fdata-sections \ >>> 632: -DJNIEXPORT='[[gnu::visibility(\"hidden\")]]'" >> >> So IIUC we now use attributes via the C++11 syntax rather than compiler-specific syntax - even where the C++11 syntax is referring to a compiler specific attribute. Is that right? > > Yep, just something that C++ does a little neater, at least in my view We (the HotSpot Group) have not discussed or approved the use of the new C++ attribute syntax, whether for standard attributes or compiler-specific ones. That involves an update to the Style Guide. I'm not convinced switching existing uses from compiler-specific `__attribute__` syntax to compiler-specific `[[attribute]]` syntax is worth the substantial code churn. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From rriggs at openjdk.org Mon Nov 14 14:20:37 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 14 Nov 2022 14:20:37 GMT Subject: Integrated: 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 In-Reply-To: References: Message-ID: On Wed, 12 Oct 2022 16:30:07 GMT, Roger Riggs wrote: > Process.waitFor() throws IllegalThreadStateException when a process returns an exit code of 259. > As described in the bug report, `waitFor()` should not be sensitive to the exit value. > Previously, it erroneously threw IllegalStateException. > Added a test to verify. This pull request has now been integrated. Changeset: 9c399326 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/9c399326724dc47eae90076d1237ff582b783863 Stats: 46 lines in 2 files changed: 45 ins; 0 del; 1 mod 8294899: Process.waitFor() throws IllegalThreadStateException when a process on Windows returns an exit code of 259 Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/10680 From luhenry at openjdk.org Mon Nov 14 15:32:32 2022 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 14 Nov 2022 15:32:32 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> Message-ID: On Sun, 13 Nov 2022 21:08:53 GMT, Claes Redestad wrote: > Also, I'd like to note that C2 auto-vectorization support is not too far away from being able to optimize hash code computations. At some point, I was able to achieve some promising results with modest tweaking of SuperWord pass: https://github.com/iwanowww/jdk/blob/superword/notes.txt http://cr.openjdk.java.net/~vlivanov/superword.reduction/webrev.00/ That would be extremely helpful not just for this case but for many other cases that today require the Vector API or handrolled intrinsics. For cases that would be great to support, a good guide is the [gcc autovectorization support](https://gcc.gnu.org/projects/tree-ssa/vectorization.html) given they use SLP as well. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From jwaters at openjdk.org Mon Nov 14 16:12:48 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 16:12:48 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: Message-ID: > After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 > > No changes to the behaviour of the JDK has resulted in any way from this commit Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert to using simpler solution similar to the original 8274980 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11081/files - new: https://git.openjdk.org/jdk/pull/11081/files/bb3ef0dd..fe5371c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11081&range=01-02 Stats: 28 lines in 2 files changed: 4 ins; 23 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11081.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11081/head:pull/11081 PR: https://git.openjdk.org/jdk/pull/11081 From jlaskey at openjdk.org Mon Nov 14 16:36:21 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 14 Nov 2022 16:36:21 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v19] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision: - Merge branch 'master' into 8285932 - Requested changes #7 @Stable removal process decl in TemplateProcessor and StringProcessor for specialized javadoc clean up FormatterBuilder javadoc - Requested changes #5 - Clean up new StringTemplate creation Centralized StringTemplate creation in StringTemplateImplFactory. Added consistent defensive copying of lists. Changed List to List on StringTemplate.interpolate and StringTemplate.of. - Switch from anonymous classes to carrier based StringTemplate implementation - Merge branch 'master' into 8285932 - Internalize FormatConcatItem - Requested changes #5 - Internalize TemplateSupport - Requested changes #4 - ... and 23 more: https://git.openjdk.org/jdk/compare/bd45530e...c15142a3 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/2dc2cad2..c15142a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=17-18 Stats: 3753 lines in 329 files changed: 2217 ins; 766 del; 770 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Nov 14 17:42:08 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 14 Nov 2022 17:42:08 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v20] In-Reply-To: References: Message-ID: <60MJvn-JZ5LfcY9EUIoyU_B9oPeQrfmZatvAjoCWEjw=.b0f4dd27-bfff-4d95-a2c8-7b05764cc325@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Wrong line separator ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/c15142a3..59d70376 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=18-19 Stats: 230 lines in 1 file changed: 0 ins; 0 del; 230 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Nov 14 17:51:24 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 14 Nov 2022 17:51:24 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Wrong line separator ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/59d70376..e4812ee5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=19-20 Stats: 336 lines in 1 file changed: 0 ins; 0 del; 336 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From vlivanov at openjdk.org Mon Nov 14 17:51:38 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 14 Nov 2022 17:51:38 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 21:01:21 GMT, Claes Redestad wrote: >> src/hotspot/share/opto/intrinsicnode.hpp line 175: >> >>> 173: // as well as adjusting for special treatment of various encoding of String >>> 174: // arrays. Must correspond to declared constants in jdk.internal.util.ArraysSupport >>> 175: typedef enum HashModes { LATIN1 = 0, UTF16 = 1, BYTE = 2, CHAR = 3, SHORT = 4, INT = 5 } HashMode; >> >> I question the need for `LATIN1` and `UTF16` modes. If you lift some of input adjustments (initial value and input size) into JDK, it becomes indistinguishable from `BYTE`/`CHAR`. Then you can reuse existing constants for basic types. > > UTF16 can easily be replaced with CHAR by lifting up the shift as you say, but LATIN1 needs to be distinguished from BYTE since the former needs unsigned semantics. Modeling in a signed/unsigned input is possible, but I figured we might as well call it UNSIGNED_BYTE and decouple it logically from String::LATIN1. FTR `T_BOOLEAN` effectively represents unsigned byte. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From duke at openjdk.org Mon Nov 14 18:07:40 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 14 Nov 2022 18:07:40 GMT Subject: Integrated: 8296431 - PushbackInputStream should override transferTo In-Reply-To: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> References: <44KgDl9en4qEk2TmHLBRlN5D3gMn7PASRjg_GQGjJok=.14d813a6-3247-4136-95bb-7182a90dbccd@github.com> Message-ID: On Fri, 4 Nov 2022 22:12:14 GMT, Markus KARG wrote: > This PR implements JDK-8296431 This pull request has now been integrated. Changeset: 95b84050 Author: Markus Karg Committer: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/95b84050fc009b5665d20168d0470c9f31598d9a Stats: 231 lines in 2 files changed: 231 ins; 0 del; 0 mod 8296431: PushbackInputStream should override transferTo Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/10999 From bpb at openjdk.org Mon Nov 14 18:13:16 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 14 Nov 2022 18:13:16 GMT Subject: Integrated: 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" In-Reply-To: References: Message-ID: On Fri, 12 Aug 2022 14:52:23 GMT, Brian Burkhalter wrote: > On Windows, suppress failure if the total space indicated by `df` is less than `FileStore::getTotalSpace` and the free space indicated by `df` equals `FileStore::getUnallocatedSpace`. This pull request has now been integrated. Changeset: 749335d3 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/749335d34ac570760279ac81308d5d323aba4067 Stats: 58 lines in 2 files changed: 40 ins; 2 del; 16 mod 8291911: java/io/File/GetXSpace.java fails with "53687091200 != 161051996160" Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/9856 From lancea at openjdk.org Mon Nov 14 18:16:50 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 18:16:50 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v6] In-Reply-To: References: Message-ID: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Additional wordsmithing on available() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10995/files - new: https://git.openjdk.org/jdk/pull/10995/files/3a01b802..619a39c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Mon Nov 14 18:16:51 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 18:16:51 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v4] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 11:08:25 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/util/zip/ZipInputStream.java line 179: >> >>> 177: * {@link #closeEntry()} has been called, otherwise always return 1. >>> 178: * I think it will need to say that input stream for the current ZIP entry has been read to end of stream, or the >>> 179: * ZIP entry has been closed with closeEntry >> >> A comment from the PR has been pasted here :-) >> Ignoring that, the updated description for the "available" method looks okay but might be clearer to say that closeEntry has been called on the current entry. > >> A comment from the PR has been pasted here :-) >> Ignoring that, the updated description for the "available" method looks okay but might be clearer to say that closeEntry has been called on the current entry. > > whoops, fixed :-) I just went and added the extra wording regarding the "current entry". I did not add it originally because the verbiage links to closeEntry which indicates that it closes the current entry and thought it might be overkill ------------- PR: https://git.openjdk.org/jdk/pull/10995 From vlivanov at openjdk.org Mon Nov 14 18:18:21 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 14 Nov 2022 18:18:21 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Sun, 13 Nov 2022 19:50:46 GMT, Claes Redestad wrote: > ... several challenges were brought up to the table, including how to deal with all the different contingencies that might be the result of a safepoint, including deoptimization. FTR if the intrinsic is represented as a stand-alone stub, there's no need to care about deoptimization. (In such cases, deopts happen on return from the stub.) It wouldn't be allowed to be a leaf call anymore, but a safepoint check and an OOP map would do the job. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From vlivanov at openjdk.org Mon Nov 14 18:32:38 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Mon, 14 Nov 2022 18:32:38 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: <6lAQI6kDDTGbskylHcWReX8ExaB6qkwgqoai7E6ikZY=.8a69a63c-453d-4bbd-8c76-4d477bfb77fe@github.com> Message-ID: On Sun, 13 Nov 2022 21:08:53 GMT, Claes Redestad wrote: > How far off is this ...? Back then it looked way too constrained (tight constraints on code shapes). But I considered it as a generally applicable optimization. > ... do you think it'll be able to match the efficiency we see here with a memoized coefficient table etc? Yes, it is able to build the constant table at runtime when folding multiplications of constant coefficients produced during loop unrolling and then packing scalars into a constant vector. Moreover, briefly looking at the code shape, the vectorizer would produce a more optimal loop shape (pre-loop would align vector accesses and would use 512-bit vectors when available; vector post-loop could help as well). ------------- PR: https://git.openjdk.org/jdk/pull/10847 From alanb at openjdk.org Mon Nov 14 19:52:50 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 14 Nov 2022 19:52:50 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v6] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 18:16:50 GMT, Lance Andersen wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Additional wordsmithing on available() Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/util/zip/ZipInputStream.java line 178: > 176: * Returns 0 when end of stream is detected for the current ZIP entry or > 177: * {@link #closeEntry()} has been called on the current ZIP entry, otherwise always return 1. > 178: *

      The updated wording looks okay. One small thing is that I think it would be a bit better if the word "always" were dropped. ------------- PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Mon Nov 14 20:03:24 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 20:03:24 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v7] In-Reply-To: References: Message-ID: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Remove always from available() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10995/files - new: https://git.openjdk.org/jdk/pull/10995/files/619a39c5..665dcaf6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=05-06 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Mon Nov 14 20:05:08 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 20:05:08 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v6] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 19:48:43 GMT, Alan Bateman wrote: > The updated wording looks okay. One small thing is that I think it would be a bit better if the word "always" were dropped. Removed always and just pushed another commit with that change. Thank you for the feedback ------------- PR: https://git.openjdk.org/jdk/pull/10995 From bpb at openjdk.org Mon Nov 14 21:05:56 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 14 Nov 2022 21:05:56 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v7] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 20:03:24 GMT, Lance Andersen wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Remove always from available() src/java.base/share/classes/java/util/zip/ZipInputStream.java line 30: > 28: import java.io.EOFException; > 29: import java.io.IOException; > 30: import java.io.InputStream; Nitpick: should the `InputStream` import precede that of `IOException`? src/java.base/share/classes/java/util/zip/ZipInputStream.java line 178: > 176: * Returns 0 when end of stream is detected for the current ZIP entry or > 177: * {@link #closeEntry()} has been called on the current ZIP entry, otherwise > 178: * return 1. Another nitpick: should this be `returns 1` to match `Returns 0` at line 176? Or vice versa? ------------- PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Mon Nov 14 21:26:08 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 21:26:08 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v8] In-Reply-To: References: Message-ID: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Changed return to returns ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10995/files - new: https://git.openjdk.org/jdk/pull/10995/files/665dcaf6..1ecffe41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10995&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10995.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10995/head:pull/10995 PR: https://git.openjdk.org/jdk/pull/10995 From lancea at openjdk.org Mon Nov 14 21:26:09 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 14 Nov 2022 21:26:09 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v7] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 21:00:16 GMT, Brian Burkhalter wrote: > Nitpick: should the `InputStream` import precede that of `IOException`? Gonna leave this as is as IntelliJ keeps changing it and not worth fighting > src/java.base/share/classes/java/util/zip/ZipInputStream.java line 178: > >> 176: * Returns 0 when end of stream is detected for the current ZIP entry or >> 177: * {@link #closeEntry()} has been called on the current ZIP entry, otherwise >> 178: * return 1. > > Another nitpick: should this be `returns 1` to match `Returns 0` at line 176? Or vice versa? Sure updated ------------- PR: https://git.openjdk.org/jdk/pull/10995 From bpb at openjdk.org Mon Nov 14 21:33:59 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 14 Nov 2022 21:33:59 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v8] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 21:26:08 GMT, Lance Andersen wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Changed return to returns Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10995 From vlivanov at openjdk.org Tue Nov 15 00:36:06 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 15 Nov 2022 00:36:06 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v4] In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 16:48:19 GMT, Jorn Vernee wrote: >> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. >> >> This is split off from the main JEP integration to make reviewing easier. >> >> This includes the following patches: >> >> 1. https://github.com/openjdk/panama-foreign/pull/698 >> 2. https://github.com/openjdk/panama-foreign/pull/699 >> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 >> 4. https://github.com/openjdk/panama-foreign/pull/740 >> 5. https://github.com/openjdk/panama-foreign/pull/746 >> 6. https://github.com/openjdk/panama-foreign/pull/742 >> 7. https://github.com/openjdk/panama-foreign/pull/743 >> >> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. >> >> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. >> >> Please refer to the PR of each individual patch for a more detailed description. > > Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision: > > - Tweak copyright headers > - Use @requires to disable some tests on x86 > - Use AssertionError for internal exceptions Haven't finished reviewing VM part. 2 questions so far: * `VMStorage` looks very similar to `VMReg`. What's the purpose of the new representation? * why do you structure the header files the way you do? `vmstorage.inline.hpp`, `vmstorage_.inline.hpp`, `vmstorageBase.inline.hpp` instead of just `vmstorage.hpp`/`vmstorage_.hpp` src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp line 146: > 144: Register tmp2 = r10; > 145: > 146: VMStorage shuffle_reg = VMS_R19; I'd prefer to see `as_VMStorage(Register)` used instead and all `VMS_...` constants go away. src/hotspot/cpu/aarch64/foreignGlobals_aarch64.cpp line 51: > 49: > 50: objArrayOop inputStorage = jdk_internal_foreign_abi_ABIDescriptor::inputStorage(abi_oop); > 51: parse_register_array(inputStorage, (int) StorageType::INTEGER, abi._integer_argument_registers, as_Register); Converting `type_index` argument from `int` to `StorageType` would allow to avoid explicit casts. src/hotspot/cpu/aarch64/vmstorage_aarch64.inline.hpp line 68: > 66: } > 67: > 68: inline VMStorage as_VMStorage(Register reg) { Mark as `constexpr` maybe? src/hotspot/cpu/x86/downcallLinker_x86_64.cpp line 239: > 237: __ vzeroupper(); > 238: > 239: if(should_save_return_value) { Missing space (here and below). ------------- PR: https://git.openjdk.org/jdk/pull/11019 From jwaters at openjdk.org Tue Nov 15 00:52:07 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 15 Nov 2022 00:52:07 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: Message-ID: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com> On Mon, 14 Nov 2022 13:08:56 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert to using simpler solution similar to the original 8274980 > > make/hotspot/lib/CompileJvm.gmk line 67: > >> 65: # Hotspot cannot handle an empty build number >> 66: VERSION_BUILD := 0 >> 67: endif > > I think the proposed "solution" is *much* worse than this. Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0) ------------- PR: https://git.openjdk.org/jdk/pull/11081 From duke at openjdk.org Tue Nov 15 02:01:15 2022 From: duke at openjdk.org (Bo Zhang) Date: Tue, 15 Nov 2022 02:01:15 GMT Subject: RFR: 8296329: Only compare major versions in jar validator Message-ID: As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison. This PR fixes it by only comparing major versions. ------------- Commit messages: - 8296329: Only compare major versions in jar validator Changes: https://git.openjdk.org/jdk/pull/11153/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11153&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296329 Stats: 118 lines in 3 files changed: 114 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11153.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11153/head:pull/11153 PR: https://git.openjdk.org/jdk/pull/11153 From jpai at openjdk.org Tue Nov 15 02:16:35 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 15 Nov 2022 02:16:35 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations Message-ID: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: Objects.requireNonNull(action); while (hasNext()) action.accept(next()); Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator and already advanced and that is what the bug is. The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. ------------- Commit messages: - 8292317: Missing null check for Iterator.forEachRemaining implementations Changes: https://git.openjdk.org/jdk/pull/11154/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292317 Stats: 41 lines in 2 files changed: 40 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11154.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11154/head:pull/11154 PR: https://git.openjdk.org/jdk/pull/11154 From sundar at openjdk.org Tue Nov 15 03:18:54 2022 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Tue, 15 Nov 2022 03:18:54 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations In-Reply-To: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: On Tue, 15 Nov 2022 02:10:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? > > The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. > > `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: > > > Objects.requireNonNull(action); > while (hasNext()) > action.accept(next()); > > Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. > > The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. > > New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.org/jdk/pull/11154 From jpai at openjdk.org Tue Nov 15 06:02:01 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 15 Nov 2022 06:02:01 GMT Subject: RFR: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods [v8] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 21:26:08 GMT, Lance Andersen wrote: >> Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. >> >> There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Changed return to returns Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10995 From kbarrett at openjdk.org Tue Nov 15 06:42:58 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 15 Nov 2022 06:42:58 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert to using simpler solution similar to the original 8274980 A few more issues as I slog my way through this commingled PR. Probably more to come. src/hotspot/share/utilities/globalDefinitions.hpp line 50: > 48: > 49: #ifndef ATTRIBUTE_ALIGNED > 50: #define ATTRIBUTE_ALIGNED(x) alignas(x) HotSpot Group has not discussed or approved use of `alignas` - see https://bugs.openjdk.org/browse/JDK-8250269. This is another change that is independent of most of the rest of this PR, and should be dealt with separately. The various MSVC-conditional direct uses of `_declspec(align(N))` should probably currently be using `ATTRIBUTE_ALIGNED`. ------------- Changes requested by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11081 From kbarrett at openjdk.org Tue Nov 15 06:42:59 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 15 Nov 2022 06:42:59 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com> References: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com> Message-ID: On Tue, 15 Nov 2022 00:49:59 GMT, Julian Waters wrote: >> make/hotspot/lib/CompileJvm.gmk line 67: >> >>> 65: # Hotspot cannot handle an empty build number >>> 66: VERSION_BUILD := 0 >>> 67: endif >> >> I think the proposed "solution" is *much* worse than this. > > Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0) Sorry, but I don't think that's much better than the prior version, and still doesn't seem better than the current code. What problem is this change supposed to be solving? I didn't find any open bugs that seemed relevant (could be I just didn't recognize such). Whatever it is seems likely to be unrelated to any of the other changes in this PR; it would have been / would be better to deal with it separately. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From kbarrett at openjdk.org Tue Nov 15 06:42:59 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 15 Nov 2022 06:42:59 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> Message-ID: On Mon, 14 Nov 2022 08:02:49 GMT, David Holmes wrote: >> Yep, it was renamed since the file is also named VISCPP, and I felt that matching the names was a good style change > > I think it is the file that has the "bad" name in this case. :( But okay. I also think the macro name should be left alone. It's the file suffix that is "bad", though I'm not convinced it's so bad as to be worth changing. (There's also `TARGET_COMPILER_visCPP`.) ------------- PR: https://git.openjdk.org/jdk/pull/11081 From mcimadamore at openjdk.org Tue Nov 15 10:08:22 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 10:08:22 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v18] In-Reply-To: References: Message-ID: <0aDgn8bkT3gjULRqLX7_1doqGRJhDlva7S3Q-uYBtZ4=.23b372a9-8775-4d0c-900f-c8a12d1769b1@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak preview feature description for JEP 434 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/cd3fbe7c..9b97bad6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 10:12:12 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 10:12:12 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v19] In-Reply-To: References: Message-ID: <43YEgUwCbX4IMeM2AjG_ZAytW-ibfIqCPW1fmBoYDpQ=.e2ef76bd-b10b-4785-976b-974501043f28@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 49 additional commits since the last revision: - Merge branch 'master' into PR_20 - Tweak preview feature description for JEP 434 - Tweak Arena::close javadoc - Merge pull request #15 from minborg/test Add @apiNote to package-info - Add @apiNote to package-info - Merge pull request #16 from minborg/fix-tests2 Fix failing tests - Fix failing tests - Rename isOwnedBy -> isCloseableBy Fix minor typos Fix StrLenTest/RingAllocator - Fix typo - More javadoc fixes - ... and 39 more: https://git.openjdk.org/jdk/compare/0ecc71f0...20ee6e8d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/9b97bad6..20ee6e8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=17-18 Stats: 15095 lines in 530 files changed: 6855 ins; 6001 del; 2239 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 11:14:35 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 11:14:35 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v20] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Rename MemorySession -> SegmentScope Improve javadoc of SegmentScope/Arena Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/20ee6e8d..5ae5864a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=18-19 Stats: 1298 lines in 125 files changed: 174 ins; 177 del; 947 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 11:16:22 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 11:16:22 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v19] In-Reply-To: <43YEgUwCbX4IMeM2AjG_ZAytW-ibfIqCPW1fmBoYDpQ=.e2ef76bd-b10b-4785-976b-974501043f28@github.com> References: <43YEgUwCbX4IMeM2AjG_ZAytW-ibfIqCPW1fmBoYDpQ=.e2ef76bd-b10b-4785-976b-974501043f28@github.com> Message-ID: <8jsBP6xJ2lT5UEIEHaGfI_Juqtj_pD1Plp7oynz81Zo=.695ba1b6-bfa9-442d-9cf2-425a7ed5a352@github.com> On Tue, 15 Nov 2022 10:12:12 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 49 additional commits since the last revision: > > - Merge branch 'master' into PR_20 > - Tweak preview feature description for JEP 434 > - Tweak Arena::close javadoc > - Merge pull request #15 from minborg/test > > Add @apiNote to package-info > - Add @apiNote to package-info > - Merge pull request #16 from minborg/fix-tests2 > > Fix failing tests > - Fix failing tests > - Rename isOwnedBy -> isCloseableBy > Fix minor typos > Fix StrLenTest/RingAllocator > - Fix typo > - More javadoc fixes > - ... and 39 more: https://git.openjdk.org/jdk/compare/3ebf94de...20ee6e8d I've renamed `MemorySession` to `SegmentScope`, following some internal and external feedback. I've also greatly improved the javadoc of both `Arena` and `SegmentScope`. A javadoc of the API contained in this iteration can be found here: http://cr.openjdk.java.net/~mcimadamore/jdk/8295044/v3/javadoc/java.base/module-summary.html ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 11:19:26 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 11:19:26 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v21] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/5ae5864a..3d9cebde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=19-20 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Tue Nov 15 12:06:55 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 12:06:55 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 01:52:14 GMT, Bo Zhang wrote: > As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison. > > This PR fixes it by only comparing major versions. See also JDK-8296119. I don't know how common it will be for someone to publish a MR JAR containing classes compiled to use preview features. It would be a bit inconvenient for users as they would need to know to run with --enable-preview on some releases. This shouldn't impact the API compatibility checking that the jar tool does so dropping the minor version and just checking the major version might be okay. ------------- PR: https://git.openjdk.org/jdk/pull/11153 From hannesw at openjdk.org Tue Nov 15 12:23:15 2022 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 15 Nov 2022 12:23:15 GMT Subject: RFR: JDK-8277074: Qualified exported types show up in JavaDoc Message-ID: Please review a simple change to hide internal classes in generated documentation by adding doc comments containing a `@hidden` tag. I verified the fix by making sure `grep -r jdk.internal` returns no matches in the generated documentation tree. ------------- Commit messages: - JDK-8277074: Qualified exported types show up in JavaDoc Changes: https://git.openjdk.org/jdk/pull/11163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8277074 Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11163.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11163/head:pull/11163 PR: https://git.openjdk.org/jdk/pull/11163 From jwaters at openjdk.org Tue Nov 15 12:25:06 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 15 Nov 2022 12:25:06 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: <7OFGmmeTJLL_dl8LZC0y11-crea_x6bM5Sto5_c366k=.8fda2c5a-b7b7-4c98-9a6e-b6c6cf14db3a@github.com> Message-ID: On Tue, 15 Nov 2022 06:12:52 GMT, Kim Barrett wrote: >> Reverted to use the original, less intrusive solution from [8274980](https://github.com/openjdk/jdk/pull/11081/commits/83ed3deb29d7344bbc95a3831f2388d077bc59e9) that initially could not work with the older Visual C++ compiler (With a minor improvement to handle #define 0) > > Sorry, but I don't think that's much better than the prior version, and still doesn't seem better than the current code. What problem is this change supposed to be solving? I didn't find any open bugs that seemed relevant (could be I just didn't recognize such). Whatever it is seems likely to be unrelated to any of the other changes in this PR; it would have been / would be better to deal with it separately. It's related to the JEP-223 version build numbers, which the original commit couldn't get to work due to a preprocessor trick not working with the now unsupported 2017. I just felt it could be included here out of convenience, but I guess I can split it off into another change if required ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Tue Nov 15 12:34:04 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 15 Nov 2022 12:34:04 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 13:06:28 GMT, Kim Barrett wrote: >> Yep, just something that C++ does a little neater, at least in my view > > We (the HotSpot Group) have not discussed or approved the use of the new C++ attribute syntax, whether for standard attributes or compiler-specific ones. That involves an update to the Style Guide. I'm not convinced switching existing uses from compiler-specific `__attribute__` syntax to compiler-specific `[[attribute]]` syntax is worth the substantial code churn. I was under the assumption that anything not listed under "Not discussed" or "Forbidden" was free game in HotSpot, I apologise for my goof since that isn't the case. That said, I am curious if there are any isolated conversations about the attribute syntax anywhere ------------- PR: https://git.openjdk.org/jdk/pull/11081 From mcimadamore at openjdk.org Tue Nov 15 12:34:43 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 12:34:43 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add `since` tag in Module/ModuleLayer preview methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/3d9cebde..b2dd8926 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=20-21 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From shade at openjdk.org Tue Nov 15 13:53:23 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 15 Nov 2022 13:53:23 GMT Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory [v2] In-Reply-To: References: Message-ID: > $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s > ... > > $ ls > Apan.class > ``` > > Additional testing: > - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8296645-javac-bench-class-files - Fix indenting - Fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11055/files - new: https://git.openjdk.org/jdk/pull/11055/files/d272fc6b..f472ba6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11055&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11055&range=00-01 Stats: 10394 lines in 442 files changed: 4082 ins; 4461 del; 1851 mod Patch: https://git.openjdk.org/jdk/pull/11055.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11055/head:pull/11055 PR: https://git.openjdk.org/jdk/pull/11055 From shade at openjdk.org Tue Nov 15 13:53:26 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 15 Nov 2022 13:53:26 GMT Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory In-Reply-To: References: Message-ID: <8WuqzHxbGXq8Jmd9dyI37CQhE20UoqScAjzNp84aIS8=.aa412fa7-f92a-4665-b945-3d6422d95a14@github.com> On Wed, 9 Nov 2022 09:00:14 GMT, Aleksey Shipilev wrote: > $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s > ... > > $ ls > Apan.class > ``` > > Additional testing: > - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers Any takers? :) ------------- PR: https://git.openjdk.org/jdk/pull/11055 From coleenp at openjdk.org Tue Nov 15 14:15:02 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Nov 2022 14:15:02 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 16:12:48 GMT, Julian Waters wrote: >> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++ code across the JDK can be replaced and simplified with cleaner language features that were previously not available due to required compatibility with the now unsupported Visual C++ 2017 compiler. These cleanups were highlighted by the very briefly integrated 8296115 >> >> No changes to the behaviour of the JDK has resulted in any way from this commit > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Revert to using simpler solution similar to the original 8274980 Can you have separate PRs for each type of thing you're changing? ------------- PR: https://git.openjdk.org/jdk/pull/11081 From aph at openjdk.org Tue Nov 15 14:20:43 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 14:20:43 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) Message-ID: JEP 429 implementation. ------------- Commit messages: - Update StressStackOverflow - Release _scopedValueCache after use - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 - Update src/java.base/share/classes/jdk/internal/vm/ScopedValueContainer.java - Rename test - Update - Whitespace - Rewrite ScopedValue stress test - Reviewer feedback - Reviewer feedback - ... and 10 more: https://git.openjdk.org/jdk/compare/d4d183ed...0d72ca2f Changes: https://git.openjdk.org/jdk/pull/10952/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286666 Stats: 3272 lines in 52 files changed: 2868 ins; 246 del; 158 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From dlong at openjdk.org Tue Nov 15 14:20:47 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 15 Nov 2022 14:20:47 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote: > JEP 429 implementation. src/hotspot/share/prims/jvm.cpp line 1410: > 1408: loc = 3; > 1409: } else if (method == resolver.thread_run_method) { > 1410: loc = 2; This depends on how javac numbers locals, right? It seems a bit fragile. This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets. src/java.base/share/classes/jdk/internal/vm/ScopedValueContainer.java line 53: > 51: /** > 52: * Returns the "latest" ScopedValueContainer for the current Thread. This may be on > 53: * the current thread's scope task or ma require walking up the tree to find it. Suggestion: * the current thread's scope task or may require walking up the tree to find it. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From jvernee at openjdk.org Tue Nov 15 14:21:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 15 Nov 2022 14:21:03 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 01:52:14 GMT, Bo Zhang wrote: > As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison. > > This PR fixes it by only comparing major versions. Please assign the JBS ticket to yourself as well. test/jdk/tools/jar/multiRelease/VersionValidatorTest.java line 107: > 105: { "19", "20", "", true }, > 106: { "20", "19", "", false }, > 107: }; My concern with this is that this will need to be updated after each release. Looks like there are also ways to directly alter the minor version of a class file, and I recommend doing that instead. See: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/PreviewVersion.java#L51 Also, there's one more negative case missing where the base version uses 20 + preview features, and the other version is 19. ------------- PR: https://git.openjdk.org/jdk/pull/11153 From aph at openjdk.org Tue Nov 15 14:20:48 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 14:20:48 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 23:17:32 GMT, Dean Long wrote: >> JEP 429 implementation. > > src/hotspot/share/prims/jvm.cpp line 1410: > >> 1408: loc = 3; >> 1409: } else if (method == resolver.thread_run_method) { >> 1410: loc = 2; > > This depends on how javac numbers locals, right? It seems a bit fragile. This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets. Ah, good point. I'll have a look at doing that. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Tue Nov 15 14:20:50 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 14:20:50 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: References: Message-ID: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com> On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote: > JEP 429 implementation. src/hotspot/share/prims/jvm.cpp line 4072: > 4070: */ > 4071: JVM_ENTRY(void, JVM_EnsureMaterializedForStackWalk_func(JNIEnv* env, jobject vthread, jobject value)) > 4072: //asm("nop"); The asm("nop") was commented out to get the build working. Its inserted by the compiler now so I assume the commented now asm can be removed. src/java.base/share/classes/java/lang/VirtualThread.java line 318: > 316: } > 317: } > 318: @Hidden Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 15 14:20:48 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 14:20:48 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 17:42:38 GMT, Andrew Haley wrote: >> src/hotspot/share/prims/jvm.cpp line 1410: >> >>> 1408: loc = 3; >>> 1409: } else if (method == resolver.thread_run_method) { >>> 1410: loc = 2; >> >> This depends on how javac numbers locals, right? It seems a bit fragile. This is one of the reasons why doPrivileged uses the helper method executePrivileged, so the locals are arguments, giving them predictable offsets. > > Ah, good point. I'll have a look at doing that. Done. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 15 14:20:53 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 14:20:53 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: References: Message-ID: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com> On Thu, 3 Nov 2022 11:50:17 GMT, ExE Boss wrote: >> JEP 429 implementation. > > src/java.base/share/classes/java/lang/Thread.java line 1610: > >> 1608: ensureMaterializedForStackWalk(bindings); >> 1609: task.run(); >> 1610: Reference.reachabilityFence(bindings); > > This?should probably?be?in a?`try`?`finally`?block: > Suggestion: > > try { > task.run(); > } finally { > Reference.reachabilityFence(bindings); > } I wonder. The pattern I'm using here is based on `AccessController.executePrivileged`, which doesn't have the `finally` clause. Perhaps I should add one here anyway. > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481: > >> 479: } >> 480: */ >> 481: return findBinding() != Snapshot.NIL; > > This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of: > > if (SCOPED_VALUE.isBound()) { > final var value = SCOPED_VALUE.get(); > // do something with `value` > } > > > -------------------------------------------------------------------------------- > > Suggestion: > > var value = findBinding(); > if (value == Snapshot.NIL) { > return false; > } > Cache.put(this, value); > return true; Probably so, yes. I'll have a look at that along with caching failure. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From dlong at openjdk.org Tue Nov 15 14:20:54 2022 From: dlong at openjdk.org (Dean Long) Date: Tue, 15 Nov 2022 14:20:54 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com> References: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com> Message-ID: On Fri, 4 Nov 2022 09:53:39 GMT, Andrew Haley wrote: >> src/java.base/share/classes/java/lang/Thread.java line 1610: >> >>> 1608: ensureMaterializedForStackWalk(bindings); >>> 1609: task.run(); >>> 1610: Reference.reachabilityFence(bindings); >> >> This?should probably?be?in a?`try`?`finally`?block: >> Suggestion: >> >> try { >> task.run(); >> } finally { >> Reference.reachabilityFence(bindings); >> } > > I wonder. The pattern I'm using here is based on `AccessController.executePrivileged`, which doesn't have the `finally` clause. Perhaps I should add one here anyway. I hope it doesn't matter. There is an example in the reachabilityFence javadocs where it does not use finally. For it to matter, I think the compiler would need to inline through run() and prove that it can throw an exception, but I don't think that's how the JIT compilers currently implement reachabilityFence. I suppose a finally shouldn't hurt, however. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 15 14:20:55 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 14:20:55 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com> References: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com> Message-ID: On Mon, 14 Nov 2022 17:34:31 GMT, Alan Bateman wrote: >> JEP 429 implementation. > > src/java.base/share/classes/java/lang/VirtualThread.java line 318: > >> 316: } >> 317: } >> 318: @Hidden > > Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can? OK. I do want to keep the name of this method consistent throughout. There are version for `Runnable` and `Callable` and it makes the runtime code cleaner if they have the same name. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 15 14:20:56 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 14:20:56 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: References: Message-ID: <3lVtaG-K0g_3M_-8_lszieivuJ4a88CKmyWj0MH8cgU=.fc28bd92-72ec-4eff-962f-06c7404954fd@github.com> On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote: > JEP 429 implementation. src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 475: > 473: // ??? Do we want to search cache for this? In most cases we don't expect > 474: // this {@link ScopedValue} to be bound, so it's not worth it. But I may > 475: // be wrong about that. We should make it switchable by a runtime parameter. We should optionally cache failures. Add a microbenchmark for that. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From duke at openjdk.org Tue Nov 15 14:20:53 2022 From: duke at openjdk.org (ExE Boss) Date: Tue, 15 Nov 2022 14:20:53 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 16:23:34 GMT, Andrew Haley wrote: > JEP 429 implementation. src/java.base/share/classes/java/lang/Thread.java line 1610: > 1608: ensureMaterializedForStackWalk(bindings); > 1609: task.run(); > 1610: Reference.reachabilityFence(bindings); This?should probably?be?in a?`try`?`finally`?block: Suggestion: try { task.run(); } finally { Reference.reachabilityFence(bindings); } src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481: > 479: } > 480: */ > 481: return findBinding() != Snapshot.NIL; This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of: if (SCOPED_VALUE.isBound()) { final var value = SCOPED_VALUE.get(); // do something with `value` } -------------------------------------------------------------------------------- Suggestion: var value = findBinding(); if (value == Snapshot.NIL) { return false; } Cache.put(this, value); return true; ------------- PR: https://git.openjdk.org/jdk/pull/10952 From pminborg at openjdk.org Tue Nov 15 14:43:08 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 14:43:08 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 32: > 30: > 31: /** > 32: * An arena controls the lifecycle of one or more memory segments, providing both flexible allocation and timely deallocation. Strictly: "An arena controls the lifecycle of zero or more ...". A newly created Arena, for example, does not control the lifecycle of any segment. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Tue Nov 15 14:48:01 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 14:48:01 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: <213057Saw0-m7uFTwDAgWYorxtjExq17nhZ0ULRUWGk=.1a10e475-baf5-4c71-a5af-c6288d3db6cc@github.com> On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 35: > 33: *

      > 34: * An arena has a {@linkplain #scope() scope}, called the arena scope. When the arena is {@linkplain #close() closed}, > 35: * the arena scope becomes not {@linkplain SegmentScope#isAlive() alive}. As a result, all the Suggest "the arena scope is no longer {@linkplain SegmentScope#isAlive() alive}" instead. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Tue Nov 15 14:52:05 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 14:52:05 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 63: > 61: * after the arena has been closed. The cost of providing this guarantee varies based on the > 62: * number of threads that have access to the memory segments allocated by the arena. For instance, if an arena > 63: * is always created and closed by one thread, and the memory segments associated with the arena's scope are always Strictly, if a shared segment is created and is only accessed by a single thread, then we need to track thread usage in order to trivially ensure safety. I think we could reword so that if access is only *allowed* by a single thread, it is trivial. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Tue Nov 15 14:55:14 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 14:55:14 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 14:49:30 GMT, Per Minborg wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add `since` tag in Module/ModuleLayer preview methods > > src/java.base/share/classes/java/lang/foreign/Arena.java line 63: > >> 61: * after the arena has been closed. The cost of providing this guarantee varies based on the >> 62: * number of threads that have access to the memory segments allocated by the arena. For instance, if an arena >> 63: * is always created and closed by one thread, and the memory segments associated with the arena's scope are always > > ~~Strictly, if a shared segment is created and is only accessed by a single thread, then we need to track thread usage in order to trivially ensure safety. I think we could reword so that if access is only *allowed* by a single thread, it is trivial.~~ ok. So reading on the initial text makes sense. So, my comment above should be disregarded. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From aph at openjdk.org Tue Nov 15 14:57:35 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 14:57:35 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v2] In-Reply-To: References: Message-ID: <8Yik6EmjgjWQSz-lAL99OFhis_ZpNTP3IGYyebnggyM=.67de9502-136c-4a17-b6fe-9cb89b72c37a@github.com> > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Update test - Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/0d72ca2f..4bd44d66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Tue Nov 15 15:06:05 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 15:06:05 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v2] In-Reply-To: References: <2qiwIUFK4kh7KzfhV8rlx9lXY79B_LkUvFo3E9hKDyM=.682039e2-78be-4864-a90a-3bd6e5372547@github.com> Message-ID: On Tue, 15 Nov 2022 14:15:26 GMT, Andrew Haley wrote: >> src/java.base/share/classes/java/lang/VirtualThread.java line 318: >> >>> 316: } >>> 317: } >>> 318: @Hidden >> >> Can we rename this to runWith(Runnable, Object) in both Thread and VirtualThread to keep the naming consistent if we can? > > OK. I do want to keep the name of this method consistent throughout. There are version for `Runnable` and `Callable` and it makes the runtime code cleaner if they have the same name. The other thing here is that there two calls to reachabilityFence, it shouldn't need both. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From pminborg at openjdk.org Tue Nov 15 15:07:04 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 15:07:04 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 100: > 98: * MemorySegment.allocateNative(bytesSize, byteAlignment, scope()); > 99: *} > 100: * More generally implementations of this method must return a native method featuring the requested size, ... must return a native ~~method~~*segment* featuring ... ------------- PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Tue Nov 15 15:11:15 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 15:11:15 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com> On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 89: > 87: > 88: /** > 89: * Returns a native memory segment with the given size (in bytes) and alignment constraint (in bytes). It is noted that the current documentation does not require a **new** native memory segment to be returned. Would it not be better with: Creates a new native memory segment ... The new shared segment might share actual backing memory though. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Tue Nov 15 15:15:45 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 15:15:45 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 119: > 117: > 118: /** > 119: * {@return the arena scope} Add a period ('.') after the closing curly bracket. src/java.base/share/classes/java/lang/foreign/Arena.java line 124: > 122: > 123: /** > 124: * Closes this arena. If this method completes normally, the arena scope becomes not {@linkplain SegmentScope#isAlive() alive}, See comment above "not alive" -> "is no longer alive" ------------- PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Tue Nov 15 15:00:08 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 15:00:08 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 79: > 77: *

      > 78: * Shared arenas, on the other hand, have no owner thread. The segments created by a shared arena > 79: * can be {@linkplain SegmentScope#isAccessibleBy(Thread) accessed} by multiple threads. This might be useful when Suggest "can be {@linkplain SegmentScope#isAccessibleBy(Thread) accessed} by ~~multiple~~ *any* thread" ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 15:28:50 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 15:28:50 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com> References: <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com> Message-ID: On Tue, 15 Nov 2022 15:09:02 GMT, Per Minborg wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add `since` tag in Module/ModuleLayer preview methods > > src/java.base/share/classes/java/lang/foreign/Arena.java line 89: > >> 87: >> 88: /** >> 89: * Returns a native memory segment with the given size (in bytes) and alignment constraint (in bytes). > > It is noted that the current documentation does not require a **new** native memory segment to be returned. Would it not be better with: > > Creates a new native memory segment ... > > The new shared segment might share actual backing memory though. My feeling is that being overly precise over identity might backfire. It is not important whether the segment is a new instance or not. But there is, perhaps, another invariant that is more semantically relevant: e.g. the returned segments (whether new or not, we don't care) should be backed by "disjoint" regions of memory. That is, if the method returns a segment with address `0` and size `100`, calling the method again cannot return a segment whose address is `50` and size is `100`. In principle, the segment allocator interface allows for this (see `SegmentAllocator::prefixAllocator`) - but for an arena, a behavior such as this would be indesirable, IMHO. > src/java.base/share/classes/java/lang/foreign/Arena.java line 119: > >> 117: >> 118: /** >> 119: * {@return the arena scope} > > Add a period ('.') after the closing curly bracket. This is a general comment. I don't think we did this consistently in other places, I'd prefer to leave as is. > src/java.base/share/classes/java/lang/foreign/Arena.java line 136: > >> 134: >> 135: /** >> 136: * {@return {@code true} if the provided thread can close this arena} > > I think this is equivalent and simpler: > > {@return if the provided thread can close this arena}. > > But I know there are many examples of {@code true} in the JDK. I'll leave as is - we can deal with this cosmetic javadoc issues at a later point. > src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 46: > >> 44: >> 45: /** >> 46: * Returns the member layouts associated with this group. > > We may use {@return the member layouts associated with this group}. Same - I'll leave these tweaks for later. > src/java.base/share/classes/java/lang/foreign/Linker.java line 264: > >> 262: >> 263: /** >> 264: * Returns a symbol lookup for symbols in a set of commonly used libraries. > > Use {@return ...} Same - I'll leave these tweaks for later. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Tue Nov 15 15:34:17 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 15:34:17 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 163: > 161: * segment is derived from the address of the original segment, by adding an offset (expressed in bytes). The size of > 162: * the sliced segment is either derived implicitly (by subtracting the specified offset from the size of the original segment), > 163: * or provided explicitly. In other words, a sliced segment has stricter spatial bounds than those of the original segment: Strictly, a sliced segment can have the *same* spatial bounds as the original segment. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 15:38:52 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 15:38:52 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 15:31:58 GMT, Per Minborg wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add `since` tag in Module/ModuleLayer preview methods > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 163: > >> 161: * segment is derived from the address of the original segment, by adding an offset (expressed in bytes). The size of >> 162: * the sliced segment is either derived implicitly (by subtracting the specified offset from the size of the original segment), >> 163: * or provided explicitly. In other words, a sliced segment has stricter spatial bounds than those of the original segment: > > Strictly, a sliced segment can have the *same* spatial bounds as the original segment. True - but I think the current text is a good compromise e.g. it is narrative text. You can always dive into `MemorySegment::asSlice` and find out more. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 15:48:28 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 15:48:28 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v23] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/b2dd8926..19e0f6d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=21-22 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 15:58:46 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 15:58:46 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v24] In-Reply-To: References: Message-ID: <2K-hydg-uLovxuhq4-WgeYlZPtj-INuCGlEKieRg77E=.de717cd6-8104-4402-b935-7ccb90199e4f@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix tests broken by MemorySession rename ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/19e0f6d5..54fb4856 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=22-23 Stats: 290 lines in 37 files changed: 0 ins; 2 del; 288 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 15:38:49 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 15:38:49 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: <7T_4KxIMV_s9h3OjbniZId7ridKlYeJ1sXu3tgBor2c=.9e0d8f95-554b-4dc3-8b1b-27e78f85578d@github.com> Message-ID: On Tue, 15 Nov 2022 15:22:07 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/foreign/Arena.java line 89: >> >>> 87: >>> 88: /** >>> 89: * Returns a native memory segment with the given size (in bytes) and alignment constraint (in bytes). >> >> It is noted that the current documentation does not require a **new** native memory segment to be returned. Would it not be better with: >> >> Creates a new native memory segment ... >> >> The new shared segment might share actual backing memory though. > > My feeling is that being overly precise over identity might backfire. It is not important whether the segment is a new instance or not. But there is, perhaps, another invariant that is more semantically relevant: e.g. the returned segments (whether new or not, we don't care) should be backed by "disjoint" regions of memory. That is, if the method returns a segment with address `0` and size `100`, calling the method again cannot return a segment whose address is `50` and size is `100`. In principle, the segment allocator interface allows for this (see `SegmentAllocator::prefixAllocator`) - but for an arena, a behavior such as this would be indesirable, IMHO. I will add: Furthermore, for any two segments S1, S2 returned by this method, the following invariant must hold: S1.overlappingSlice(S2).isEmpty() == true ``` ------------- PR: https://git.openjdk.org/jdk/pull/10872 From aph at openjdk.org Tue Nov 15 15:52:22 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 15:52:22 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v3] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/4bd44d66..442a04ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From pminborg at openjdk.org Tue Nov 15 15:28:52 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 15 Nov 2022 15:28:52 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v22] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 12:34:43 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Add `since` tag in Module/ModuleLayer preview methods src/java.base/share/classes/java/lang/foreign/Arena.java line 136: > 134: > 135: /** > 136: * {@return {@code true} if the provided thread can close this arena} I think this is equivalent and simpler: {@return if the provided thread can close this arena}. But I know there are many examples of {@code true} in the JDK. src/java.base/share/classes/java/lang/foreign/GroupLayout.java line 46: > 44: > 45: /** > 46: * Returns the member layouts associated with this group. We may use {@return the member layouts associated with this group}. src/java.base/share/classes/java/lang/foreign/Linker.java line 264: > 262: > 263: /** > 264: * Returns a symbol lookup for symbols in a set of commonly used libraries. Use {@return ...} ------------- PR: https://git.openjdk.org/jdk/pull/10872 From lancea at openjdk.org Tue Nov 15 16:48:08 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 15 Nov 2022 16:48:08 GMT Subject: Integrated: JDK-8262435: Clarify the behavior of a few inherited ZipInputStream methods In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 18:13:23 GMT, Lance Andersen wrote: > Please review the following PR which updates several of the ZipInputStream methods whose javadoc is inherited to clarify the methods are acting on the current ZIP Entry. > > There are no changes in behavior. The main description for the method's javadoc that has been copied has been clarified and the remaining doc is the same. This pull request has now been integrated. Changeset: 6aef3a4a Author: Lance Andersen URL: https://git.openjdk.org/jdk/commit/6aef3a4a3d41116cb4f3783a83c91d5340ef4698 Stats: 185 lines in 1 file changed: 178 ins; 2 del; 5 mod 8262435: Clarify the behavior of a few inherited ZipInputStream methods Reviewed-by: alanb, bpb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/10995 From aph at openjdk.org Tue Nov 15 16:37:15 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 16:37:15 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v4] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/442a04ef..c70945bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=02-03 Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From jvernee at openjdk.org Tue Nov 15 17:17:40 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 15 Nov 2022 17:17:40 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v4] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 20:05:09 GMT, Vladimir Ivanov wrote: >> Jorn Vernee has updated the pull request incrementally with three additional commits since the last revision: >> >> - Tweak copyright headers >> - Use @requires to disable some tests on x86 >> - Use AssertionError for internal exceptions > > src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp line 146: > >> 144: Register tmp2 = r10; >> 145: >> 146: VMStorage shuffle_reg = VMS_R19; > > I'd prefer to see `as_VMStorage(Register)` used instead and all `VMS_...` constants go away. Yes, seems to be possible now that `as_VMStorage` can be made `constexpr`. Will do > src/hotspot/cpu/aarch64/vmstorage_aarch64.inline.hpp line 68: > >> 66: } >> 67: >> 68: inline VMStorage as_VMStorage(Register reg) { > > Mark as `constexpr` maybe? Tried this before when `Register` wasn't as `constexpr` friendly due to the reinterpret casts. Seems to work now though (thanks! :)) I'll change all these to `constexpr`. ------------- PR: https://git.openjdk.org/jdk/pull/11019 From aph at openjdk.org Tue Nov 15 17:18:19 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 17:18:19 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v5] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Fix failing serviceability tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/c70945bf..4e650314 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=03-04 Stats: 17 lines in 7 files changed: 14 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 15 17:36:16 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 15 Nov 2022 17:36:16 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Fix failing serviceability tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/4e650314..e1063d7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=04-05 Stats: 7 lines in 1 file changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From jvernee at openjdk.org Tue Nov 15 17:42:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 15 Nov 2022 17:42:03 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v4] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 00:33:35 GMT, Vladimir Ivanov wrote: > * `VMStorage` looks very similar to `VMReg`. What's the purpose of the new representation? `VMReg` encodes stack offsets in slots (of 32 bits), which is not enough to represent every call shape on macosx-aarch64. Byte offsets are needed. We also need some size information for that, e.g. to avoid a store of 1 byte to the stack from overwriting other things with a 64-bit write. `VMStorage` also has a channel for that: either a size in bytes, or a register mask (mask of used segments of a register) that can be used to indicate the size if needed. (`VMReg` sort of did that with `BasicType`, but we now erase every sub-int type to `int`, so that no longer works, and it always felt a bit wrong since we're really moving bits between registers, not typed Java values). See also: https://github.com/openjdk/panama-foreign/pull/699 > * why do you structure the header files the way you do? `vmstorage.inline.hpp`, `vmstorage_.inline.hpp`, `vmstorageBase.inline.hpp` instead of just `vmstorage.hpp`/`vmstorage_.hpp` The CPU header depends on the definition of `VMStorage` to be complete, so I had that include the `vmstorageBase` header, and had the `vmstorage` header include the cpu header. But, looking now, it looks like I can also just include the CPU header at the end of the `vmstorageBase` file, and remove 1 header. I'll do that to make things simpler. ------------- PR: https://git.openjdk.org/jdk/pull/11019 From mcimadamore at openjdk.org Tue Nov 15 17:54:16 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 17:54:16 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v25] In-Reply-To: References: Message-ID: <-RoscJ-7QuJ7y50zTBcxRISETzsAnuWdhDjOKhkcLoU=.99cc6f49-c850-4d93-a40b-4cd953a99cb2@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix MapToMemorySegmentTest ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/54fb4856..b331a4fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=23-24 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Tue Nov 15 18:03:39 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 18:03:39 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v26] In-Reply-To: References: Message-ID: <-rih5SODHs0oMsQlaTc_lny0Cz6YvYLa4Arjr3Sf0fA=.755847f0-6a14-4784-85ba-97be21e6656b@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix @since tag in SegmentScope ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/b331a4fd..5f60d052 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Tue Nov 15 18:12:41 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 15 Nov 2022 18:12:41 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v4] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 17:13:58 GMT, Jorn Vernee wrote: >> src/hotspot/cpu/aarch64/vmstorage_aarch64.inline.hpp line 68: >> >>> 66: } >>> 67: >>> 68: inline VMStorage as_VMStorage(Register reg) { >> >> Mark as `constexpr` maybe? > > Tried this before when `Register` wasn't as `constexpr` friendly due to the reinterpret casts. Seems to work now though (thanks! :)) I'll change all these to `constexpr`. Err, looks like this works for MSVC, but with GCC I hit a snag eventually (it also require putting `constexpr` on a lot of the `Register`/`VMReg` API). This error occurs: * For target hotspot_variant-server_libjvm_objs_downcallLinker.o: In file included from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/vmstorage.inline.hpp:100, from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/foreignGlobals.hpp:29, from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/downcallLinker.hpp:27, from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/downcallLinker.cpp:25: ------------- PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Tue Nov 15 18:12:42 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 15 Nov 2022 18:12:42 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v4] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 18:07:18 GMT, Jorn Vernee wrote: >> Tried this before when `Register` wasn't as `constexpr` friendly due to the reinterpret casts. Seems to work now though (thanks! :)) I'll change all these to `constexpr`. > > Err, looks like this works for MSVC, but with GCC I hit a snag eventually (it also require putting `constexpr` on a lot of the `Register`/`VMReg` API). > > This error occurs: > > > * For target hotspot_variant-server_libjvm_objs_downcallLinker.o: > In file included from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/vmstorage.inline.hpp:100, > from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/foreignGlobals.hpp:29, > from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/downcallLinker.hpp:27, > from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/downcallLinker.cpp:25: I guess there's also the possibility that this might trip up compilers on other platforms, even if I can manage to fix it here. ------------- PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Tue Nov 15 18:19:09 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 15 Nov 2022 18:19:09 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v4] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 18:09:21 GMT, Jorn Vernee wrote: >> Err, looks like this works for MSVC, but with GCC I hit a snag eventually (it also require putting `constexpr` on a lot of the `Register`/`VMReg` API). >> >> This error occurs: >> >> >> * For target hotspot_variant-server_libjvm_objs_downcallLinker.o: >> In file included from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/vmstorage.inline.hpp:100, >> from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/foreignGlobals.hpp:29, >> from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/downcallLinker.hpp:27, >> from /mnt/h/openjdk/foreign-abi/src/hotspot/share/prims/downcallLinker.cpp:25: > > I guess there's also the possibility that this might trip up compilers on other platforms, even if I can manage to fix it here. Looks like it was the next line after the one in the diagnostic that was actually the problem. I seem to have something working now. ------------- PR: https://git.openjdk.org/jdk/pull/11019 From alanb at openjdk.org Tue Nov 15 18:19:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 18:19:11 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 17:36:16 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing serviceability tests test/jdk/ProblemList.txt line 804: > 802: > 803: # Loom, fibers branch > 804: This is left over from when Stress.java was excluded so we can remove it from the PR. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Tue Nov 15 18:41:08 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 18:41:08 GMT Subject: RFR: 8296405: java/util/concurrent/forkjoin/AsyncShutdownNow.java is too slow In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 09:37:05 GMT, Jaikiran Pai wrote: > Should we file a JBS to re-enable this so that we don't forget? I'll add a note to JDK-8286352 or JDK-8288899, depending on which one is used. ------------- PR: https://git.openjdk.org/jdk/pull/10986 From mcimadamore at openjdk.org Tue Nov 15 18:47:39 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 18:47:39 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: References: Message-ID: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix typo in SegmentScope javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/5f60d052..876587c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=25-26 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From coleenp at openjdk.org Tue Nov 15 18:52:37 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Nov 2022 18:52:37 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v6] In-Reply-To: References: Message-ID: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11033/files - new: https://git.openjdk.org/jdk/pull/11033/files/5bfec2e9..b96186ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11033&range=04-05 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11033.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11033/head:pull/11033 PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 15 18:52:39 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Nov 2022 18:52:39 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 23:35:47 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Forgot a null check. > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 540: > >> 538: >> 539: jthread * >> 540: JvmtiEnvBase::new_jthreadArray(int length, Handle *handles) { > > Shouldn't this method need to cast the return value to `jthread*`? And potentially shouldn't all the jobject's now be jthread's? jthread and jthreadGroup are typedefs to jobject in JVMTI spec. https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#jthread But I updated the code to have the more specific types. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 15 18:52:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Nov 2022 18:52:40 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: <8IJbhIid1KAN_8xogA0fSvh0RIbYhzPBB5sMBVgQkBw=.ed314adf-1e6e-4ba8-a263-ede8118d4107@github.com> Message-ID: On Wed, 9 Nov 2022 11:54:55 GMT, Serguei Spitsyn wrote: >> I don't think this has changed. Right now, if there are no child subgroups then *group_count_ptr will be 0 and *groups_ptr will be NULL as there is no memory to deallocate. JVMTI Deallocate is specified to do nothing when called with NULL. > > Alan, you are right. This check existed before. Thanks Alan, yes, I didn't change the null return. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Tue Nov 15 18:52:41 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Nov 2022 18:52:41 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v5] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 09:19:33 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Forgot a null check. > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 564: > >> 562: >> 563: for (int i=0; i> 564: objArray[i] = JNIHandles::make_local(groups->obj_at(i)); > > Nit: Spaces are missed around '=' and '<' signs. fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From mcimadamore at openjdk.org Tue Nov 15 19:27:08 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 19:27:08 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 17:36:16 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing serviceability tests src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 43: > 41: /** > 42: * A value that is set once and is then available for reading for a bounded period of > 43: * execution by a thread. A {@code ScopedValue} allows for safely and efficiently sharing by a thread, or by one or more threads? (when inherited) src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 160: > 158: * record. > 159: * > 160: *

      For this incubator release, we have provided some system properties Maybe it would be better to frame this as "The reference implementation provides some system properties". The term "reference implementation" is used elsewhere to define JDK specific mechanisms that might, or might not carry across to other JVM/Java SE API implementations. src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 172: > 170: * must be an integer power of 2. > 171: * > 172: *

      For example, you could use {@code -Djdk.incubator.concurrent.ScopedValue.cacheSize=8}. I would also avoid "you" and "we" in the javadoc. While javadoc is not formal, we often use locutions such as "clients can use/do XYZ". src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 180: > 178: * thread preserves its scoped-value cache when blocked. Like {@code > 179: * ScopedValue.cacheSize}, this is a space versus speed trade-off: if > 180: * you have a great many virtual threads that are blocked most of the "in situations where many virtual threads are blocked most of the time, ..." src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 185: > 183: * would have to be regenerated after a blocking operation. > 184: * > 185: * @param the type of the value Suggestion: * @param the type of the scoped value src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 354: > 352: > 353: /** > 354: * Calls a value returning operation with each scoped value in this mapping bound Suggestion: * Calls a value-returning operation with each scoped value in this mapping bound src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 460: > 458: * } > 459: * > 460: * @param key the ScopedValue key should use `@code` or `@link` src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 463: > 461: * @param value the value, can be {@code null} > 462: * @param the type of the value > 463: * @return a new Carrier with a single mapping same here src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 470: > 468: > 469: /** > 470: * Calls a value returning operation with a {@code ScopedValue} bound to a value Suggestion: * Calls a value returning-operation with a {@code ScopedValue} bound to a value src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 490: > 488: * } > 489: * > 490: * @param key the ScopedValue Again, missing `@code` - please check all methods src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 613: > 611: * @return the value of the scoped value if bound, otherwise {@code other} > 612: */ > 613: public T orElse(T other) { >From an API perspective, wouldn't return `Optional` a more consistent choice? `Optional` has all methods we need to deal with this kind of stuff... src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 229: > 227: *

    • Inheritance of {@linkplain ScopedValue scoped values} across threads. > 228: *
    • Confinement checks. The phrase "threads contained in the task scope" in method > 229: * descriptions means threads started in the task scope or descendant scopes. sadly, the term "descendant scopes" is not defined elsewhere in this javadoc src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 233: > 231: * > 232: *

      The following example demonstrates the inheritance of a scoped value. A scoped > 233: * value {@code USERNAME} is bound to the value "duke". A StructuredTaskScope is created Missing `@code` or `@link` for `StructuredTaskScope` src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 237: > 235: * The thread inherits the scoped value bindings captured when creating the > 236: * task scope. The code in {@code childTask} uses the value of the scoped value and so > 237: * reads the value "duke". Suggestion: * reads the value {@code "duke"}. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From coleenp at openjdk.org Tue Nov 15 20:08:16 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 15 Nov 2022 20:08:16 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file What do you think of this release note ? https://bugs.openjdk.org/browse/JDK-8297073 ------------- PR: https://git.openjdk.org/jdk/pull/11023 From alanb at openjdk.org Tue Nov 15 20:14:02 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 20:14:02 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: <5hAVImQZUFPiE99N8uZ5KC7YUGHEkYglmftttBxZln4=.d469624e-5ddc-4c13-bc64-ed0c73ceb5a2@github.com> On Tue, 15 Nov 2022 18:28:56 GMT, Maurizio Cimadamore wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing serviceability tests > > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 43: > >> 41: /** >> 42: * A value that is set once and is then available for reading for a bounded period of >> 43: * execution by a thread. A {@code ScopedValue} allows for safely and efficiently sharing > > by a thread, or by one or more threads? (when inherited) I'd prefer to keep this as is because it's too much to use "threads" or mention inheritance in the first paragraph. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From duke at openjdk.org Tue Nov 15 20:26:34 2022 From: duke at openjdk.org (Weibing Xiao) Date: Tue, 15 Nov 2022 20:26:34 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist Message-ID: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. ------------- Commit messages: - remove extra line - warning message for java.io.tmpdir Changes: https://git.openjdk.org/jdk/pull/11174/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290313 Stats: 146 lines in 4 files changed: 142 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11174/head:pull/11174 PR: https://git.openjdk.org/jdk/pull/11174 From jlaskey at openjdk.org Tue Nov 15 20:27:09 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 15 Nov 2022 20:27:09 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 17:51:24 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Wrong line separator Could we get some review completions so we can move forward? Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From alanb at openjdk.org Tue Nov 15 20:29:10 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 20:29:10 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 19:19:57 GMT, Maurizio Cimadamore wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing serviceability tests > > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 613: > >> 611: * @return the value of the scoped value if bound, otherwise {@code other} >> 612: */ >> 613: public T orElse(T other) { > > From an API perspective, wouldn't return `Optional` a more consistent choice? `Optional` has all methods we need to deal with this kind of stuff... This comment is on orElse but I suspect you are suggesting that get() be changed to return Optional. I think we'll need to get more feedback/usage of this API before re-visiting that. > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 229: > >> 227: *

    • Inheritance of {@linkplain ScopedValue scoped values} across threads. >> 228: *
    • Confinement checks. The phrase "threads contained in the task scope" in method >> 229: * descriptions means threads started in the task scope or descendant scopes. > > sadly, the term "descendant scopes" is not defined elsewhere in this javadoc Good poin,t, we had more setup in previous iterations. @theRealAph I'll adjust this in the loom repo as I can't do it here. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Tue Nov 15 21:03:03 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 15 Nov 2022 21:03:03 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Tue, 15 Nov 2022 19:02:30 GMT, Weibing Xiao wrote: > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. src/java.base/share/classes/java/lang/System.java line 2247: > 2245: Unsafe.getUnsafe().ensureClassInitialized(StringConcatFactory.class); > 2246: > 2247: // print out warning message if java.io.tmpdir is set through command line with non-existing folder It's probably okay to have the warning emitted in checkIoTmpDir, just a bit out of sight and inconsistent with the other warnings printed in this class. I think the comment could be improved by bit with "Emit a warning if java.io.tmpdir is set via the command line to a directory that doesn't exist". ------------- PR: https://git.openjdk.org/jdk/pull/11174 From duke at openjdk.org Tue Nov 15 21:26:47 2022 From: duke at openjdk.org (Justin Lu) Date: Tue, 15 Nov 2022 21:26:47 GMT Subject: RFR: 8287180: Update IANA Language Subtag Registry to Version 2022-08-08 Message-ID: Problem: IANA Language subtag registry is outdated Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) ------------- Commit messages: - Update date for IANA test - Merge branch 'master' into 8287180-IANA - update IANA Changes: https://git.openjdk.org/jdk/pull/10546/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10546&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287180 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10546.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10546/head:pull/10546 PR: https://git.openjdk.org/jdk/pull/10546 From naoto at openjdk.org Tue Nov 15 21:26:48 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 15 Nov 2022 21:26:48 GMT Subject: RFR: 8287180: Update IANA Language Subtag Registry to Version 2022-08-08 In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 20:03:42 GMT, Justin Lu wrote: > Problem: IANA Language subtag registry is outdated > Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) Although there aren't actual code changes, I believe the test `test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java` should be modified as well. ------------- Changes requested by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/10546 From mcimadamore at openjdk.org Tue Nov 15 21:31:37 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 15 Nov 2022 21:31:37 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 20:26:37 GMT, Alan Bateman wrote: >> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 613: >> >>> 611: * @return the value of the scoped value if bound, otherwise {@code other} >>> 612: */ >>> 613: public T orElse(T other) { >> >> From an API perspective, wouldn't return `Optional` a more consistent choice? `Optional` has all methods we need to deal with this kind of stuff... > > This comment is on orElse but I suspect you are suggesting that get() be changed to return Optional. I think we'll need to get more feedback/usage of this API before re-visiting that. Yes, my comment was really on `get` - that said, I note that saying get().get() would look odd (but maybe finding some other name for `ScopedValue::get`, such as `find` might work) ------------- PR: https://git.openjdk.org/jdk/pull/10952 From naoto at openjdk.org Tue Nov 15 21:52:04 2022 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 15 Nov 2022 21:52:04 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Tue, 15 Nov 2022 19:02:30 GMT, Weibing Xiao wrote: > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. I just wonder if this change warrants a CSR. If it is merely printing out a warning, it may not require it IMO. Otherwise, if some real behavioral change exists, or clarifying the behavior, I think the `java.io.tmpdir` in javadoc should mention it. ------------- PR: https://git.openjdk.org/jdk/pull/11174 From some-java-user-99206970363698485155 at vodafonemail.de Tue Nov 15 23:18:19 2022 From: some-java-user-99206970363698485155 at vodafonemail.de (some-java-user-99206970363698485155 at vodafonemail.de) Date: Wed, 16 Nov 2022 00:18:19 +0100 Subject: Should Inflater & Deflater implement Closeable? Message-ID: <9ccf3dcbfe1e44c8aaca9c877b5ee363@vodafonemail.de> Hello, java.util.zip.Inflater and java.util.zip.Deflater both have an `end()` method to release native memory. However, both classes do not implement Closeable. This might prevent IDEs and other tooling from indicating that users should release the resources, and prevents usage in try-with-resources. Are the reasons for this only historical? (Inflater and Deflater seem to be older than Closeable) If so, would it be reasonable to adjust these classes to implement Closeable? The implementation could then delegate to `end()` (and omit `throws IOException`), though to satisfy the `close()` contract it might be necessary to track whether the method has already been before. I did not find anything regarding this on the bug tracker or this mailing list. Kind regards From duke at openjdk.org Wed Nov 16 00:44:50 2022 From: duke at openjdk.org (Bo Zhang) Date: Wed, 16 Nov 2022 00:44:50 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version [v2] In-Reply-To: References: Message-ID: > As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison. > > This PR fixes it by only comparing major versions. Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8296329: Only compare major versions in jar validator ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11153/files - new: https://git.openjdk.org/jdk/pull/11153/files/93ec7fb8..b293cbfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11153&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11153&range=00-01 Stats: 30 lines in 1 file changed: 13 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11153.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11153/head:pull/11153 PR: https://git.openjdk.org/jdk/pull/11153 From duke at openjdk.org Wed Nov 16 00:44:53 2022 From: duke at openjdk.org (Bo Zhang) Date: Wed, 16 Nov 2022 00:44:53 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version [v2] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 02:14:46 GMT, Jorn Vernee wrote: >> Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8296329: Only compare major versions in jar validator > > test/jdk/tools/jar/multiRelease/VersionValidatorTest.java line 116: > > > My concern with this is that this will need to be updated after each release. Looks like there are also ways to directly alter the minor version of a class file, and I recommend doing that instead. See: https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ClassFile/PreviewVersion.java#L51 > > Also, there's one more negative case missing where the base version uses 20 + preview features, and the other version is 19. Thanks @JornVernee . I have updated the test, PTAL! > Please assign the JBS ticket to yourself as well. Sorry, I don't have permission to update JBS ticket. ------------- PR: https://git.openjdk.org/jdk/pull/11153 From sspitsyn at openjdk.org Wed Nov 16 03:58:30 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 16 Nov 2022 03:58:30 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v6] In-Reply-To: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> References: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> Message-ID: On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. I'm sorry for the latency. Looks good to me. I've posted one nit though. Thanks, Serguei src/hotspot/share/prims/jvmtiEnvBase.cpp line 564: > 562: > 563: for (int i = 0; i < length; i++) { > 564: objArray[i] = (jthreadGroup)JNIHandles::make_local(groups->obj_at(i)); Nit: It is better to use `jni_reference` instead of `JNIHandles::make_local` for consistency as at the line 549. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11033 From jai.forums2013 at gmail.com Wed Nov 16 04:15:29 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 16 Nov 2022 09:45:29 +0530 Subject: Should Inflater & Deflater implement Closeable? In-Reply-To: <9ccf3dcbfe1e44c8aaca9c877b5ee363@vodafonemail.de> References: <9ccf3dcbfe1e44c8aaca9c877b5ee363@vodafonemail.de> Message-ID: <40895983-c628-09bf-2417-8bc458658c70@gmail.com> There's https://bugs.openjdk.org/browse/JDK-8225763. I plan to revive that effort some time soon, it's been on my todo list for the past few months. -Jaikiran On 16/11/22 4:48 am, some-java-user-99206970363698485155 at vodafonemail.de wrote: > Hello, > java.util.zip.Inflater and java.util.zip.Deflater both have an `end()` method to release native memory. However, both classes > do not implement Closeable. This might prevent IDEs and other tooling from indicating that users should release the > resources, and prevents usage in try-with-resources. > > Are the reasons for this only historical? (Inflater and Deflater seem to be older than Closeable) > If so, would it be reasonable to adjust these classes to implement Closeable? The implementation could then delegate to > `end()` (and omit `throws IOException`), though to satisfy the `close()` contract it might be necessary to track whether the > method has already been before. > > I did not find anything regarding this on the bug tracker or this mailing list. > > Kind regards > From aph at openjdk.org Wed Nov 16 11:06:46 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 11:06:46 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v7] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/e1063d7b..1bd9d47a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 16 11:06:47 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 11:06:47 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: <5hAVImQZUFPiE99N8uZ5KC7YUGHEkYglmftttBxZln4=.d469624e-5ddc-4c13-bc64-ed0c73ceb5a2@github.com> References: <5hAVImQZUFPiE99N8uZ5KC7YUGHEkYglmftttBxZln4=.d469624e-5ddc-4c13-bc64-ed0c73ceb5a2@github.com> Message-ID: On Tue, 15 Nov 2022 20:11:36 GMT, Alan Bateman wrote: > I'd prefer to keep this as is because it's too much to use "threads" or mention inheritance in the first paragraph. I agree. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 16 11:06:51 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 11:06:51 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 18:35:06 GMT, Maurizio Cimadamore wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing serviceability tests > > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 172: > >> 170: * must be an integer power of 2. >> 171: * >> 172: *

      For example, you could use {@code -Djdk.incubator.concurrent.ScopedValue.cacheSize=8}. > > I would also avoid "you" and "we" in the javadoc. While javadoc is not formal, we often use locutions such as "clients can use/do XYZ". OK, it's a style thing. Wilco. > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 185: > >> 183: * would have to be regenerated after a blocking operation. >> 184: * >> 185: * @param the type of the value > > Suggestion: > > * @param the type of the scoped value Mm, but this is the type of the value of the `ScopedValue` instance. So, the type of the scoped value is `ScopedValue`, the type of the value is `T`, is it not? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 16 11:06:51 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 11:06:51 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 21:28:29 GMT, Maurizio Cimadamore wrote: >> This comment is on orElse but I suspect you are suggesting that get() be changed to return Optional. I think we'll need to get more feedback/usage of this API before re-visiting that. > > Yes, my comment was really on `get` - that said, I note that saying get().get() would look odd (but maybe finding some other name for `ScopedValue::get`, such as `find` might work) It certainly would look odd. This API is, by design, as lightweight as it possibly can be, both from an implementation and a user's point of view. It's also intended to be as close as possible to an "invisible" parameter passed to all callees. From that point of view, `get()` is a wart. `get().get()` is just... ------------- PR: https://git.openjdk.org/jdk/pull/10952 From mcimadamore at openjdk.org Wed Nov 16 11:45:41 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 11:45:41 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 10:57:49 GMT, Andrew Haley wrote: >> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 185: >> >>> 183: * would have to be regenerated after a blocking operation. >>> 184: * >>> 185: * @param the type of the value >> >> Suggestion: >> >> * @param the type of the scoped value > > Mm, but this is the type of the value of the `ScopedValue` instance. > So, the type of the scoped value is `ScopedValue`, the type of the value is `T`, is it not? Right - there's "scoped value" which is the holder, and "value of the scoped value" which is what has the type T. You are correct that just dropping "scoped" in there doesn't make things better. Conversely, just leaving "value" and nothing else (as per PR) is ambiguous. It feels like we need some way (uniform throughout the javadoc) to speak about "the value associated to a scoped value instance". ------------- PR: https://git.openjdk.org/jdk/pull/10952 From mcimadamore at openjdk.org Wed Nov 16 11:45:43 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 11:45:43 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com> On Wed, 16 Nov 2022 11:03:07 GMT, Andrew Haley wrote: >> Yes, my comment was really on `get` - that said, I note that saying get().get() would look odd (but maybe finding some other name for `ScopedValue::get`, such as `find` might work) > > It certainly would look odd. This API is, by design, as lightweight as it possibly can be, both from an implementation and a user's point of view. It's also intended to be as close as possible to an "invisible" parameter passed to all callees. From that point of view, `get()` is a wart. `get().get()` is just... IMHO there are ways to have the cake and eat it too. That is, we could have a couple of overloads: T get() { ... } // throws NSME if not found Optional find() // returns empty optional if not found Then, for simple use cases, code will stay the same as today. But, if users want to deal with optionality explicitly, they can call `find` and then call `orElse`, `map` or whatever they like. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Wed Nov 16 12:04:00 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 12:04:00 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com> References: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com> Message-ID: On Wed, 16 Nov 2022 11:41:49 GMT, Maurizio Cimadamore wrote: >> It certainly would look odd. This API is, by design, as lightweight as it possibly can be, both from an implementation and a user's point of view. It's also intended to be as close as possible to an "invisible" parameter passed to all callees. From that point of view, `get()` is a wart. `get().get()` is just... > > IMHO there are ways to have the cake and eat it too. That is, we could have a couple of overloads: > > > T get() { ... } // throws NSME if not found > Optional find() // returns empty optional if not found > > > Then, for simple use cases, code will stay the same as today. But, if users want to deal with optionality explicitly, they can call `find` and then call `orElse`, `map` or whatever they like. We expect isBound() will be used a lot and I think that is clearer (and cheaper) than find().isEmpty(). Time will tell on orElse/orElseThrow and whether they should be replaced with an Optional view. That is, I think your comments mostly apply to those two methods rather than get/isBound. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From mcimadamore at openjdk.org Wed Nov 16 12:14:14 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 12:14:14 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com> Message-ID: On Wed, 16 Nov 2022 12:01:58 GMT, Alan Bateman wrote: >> IMHO there are ways to have the cake and eat it too. That is, we could have a couple of overloads: >> >> >> T get() { ... } // throws NSME if not found >> Optional find() // returns empty optional if not found >> >> >> Then, for simple use cases, code will stay the same as today. But, if users want to deal with optionality explicitly, they can call `find` and then call `orElse`, `map` or whatever they like. > > We expect isBound() will be used a lot and I think that is clearer (and cheaper) than find().isEmpty(). > > Time will tell on orElse/orElseThrow and whether they should be replaced with an Optional view. That is, I think your comments mostly apply to those two methods rather than get/isBound. Note that `isBound` can also be explained as just a shorcut for `find().isEmpty()`. That is, I'm not really suggesting to drop sugary methods from the API. But by exposing the optional nature of the result, the API might end up being more composable. But, as you said, we don't have to decide now. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From asotona at openjdk.org Wed Nov 16 12:42:56 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 16 Nov 2022 12:42:56 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error Message-ID: Option --disable- at files is not recognised as valid JVM option, however it is already implemented in the launcher. Proposed patch skips --disable- at files option in src/hotspot/share/runtime/arguments.cpp processing, so it does not fall into the category of unknown options. The patch also corrects typo in the launcher.properties and adds simple DisableFilesOptionTest. Please review. Thank you, Adam ------------- Commit messages: - 8293041: --disable- at files option doesn't work and cause an error Changes: https://git.openjdk.org/jdk/pull/11183/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11183&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293041 Stats: 51 lines in 13 files changed: 40 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11183.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11183/head:pull/11183 PR: https://git.openjdk.org/jdk/pull/11183 From james.laskey at oracle.com Wed Nov 16 12:49:27 2022 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 16 Nov 2022 12:49:27 +0000 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) Message-ID: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> May I get a final (PR) review of JDK-8285932 Implementation of JEP-430 String Templates (Preview) from core-libs and compiler. PR: https://github.com/openjdk/jdk/pull/10889 JBS: https://bugs.openjdk.org/browse/JDK-8285932 CSR: https://bugs.openjdk.org/browse/JDK-8286021 JEP: https://openjdk.org/jeps/430 https://bugs.openjdk.org/browse/JDK-8273943 SPEC: https://bugs.openjdk.org/browse/JDK-8296302 Thank you. Cheers, ? Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Wed Nov 16 12:52:10 2022 From: duke at openjdk.org (ExE Boss) Date: Wed, 16 Nov 2022 12:52:10 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com> Message-ID: On Wed, 16 Nov 2022 12:11:45 GMT, Maurizio Cimadamore wrote: >> We expect isBound() will be used a lot and I think that is clearer (and cheaper) than find().isEmpty(). >> >> Time will tell on orElse/orElseThrow and whether they should be replaced with an Optional view. That is, I think your comments mostly apply to those two methods rather than get/isBound. > > Note that `isBound` can also be explained as just a shorcut for `find().isEmpty()`. That is, I'm not really suggesting to drop sugary methods from the API. But by exposing the optional nature of the result, the API might end up being more composable. > > But, as you said, we don't have to decide now. Note?that `ScopedValue` can?currently be?bound to?`null`, but?by?using `Optional`, there?would be?no?way to?differentiate an?unbound `ScopedValue` from?one bound?to?`null`. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From coleenp at openjdk.org Wed Nov 16 12:59:11 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Nov 2022 12:59:11 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v6] In-Reply-To: References: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> Message-ID: On Wed, 16 Nov 2022 03:54:31 GMT, Serguei Spitsyn wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments. > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 564: > >> 562: >> 563: for (int i = 0; i < length; i++) { >> 564: objArray[i] = (jthreadGroup)JNIHandles::make_local(groups->obj_at(i)); > > Nit: It is better to use `jni_reference` instead of `JNIHandles::make_local` for consistency as at the line 549. jni_reference takes a Handle and this passes a Handle to an objArray so groups->obj_at(i) is an oop and it's a waste to make it a handle for jni_reference to just unhandlize it. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Wed Nov 16 13:12:58 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Nov 2022 13:12:58 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v6] In-Reply-To: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> References: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> Message-ID: On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. Thanks for reviewing Serguei. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From alanb at openjdk.org Wed Nov 16 13:16:09 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 13:16:09 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com> Message-ID: On Wed, 16 Nov 2022 12:50:04 GMT, ExE Boss wrote: > Note?that `ScopedValue` can?currently be?bound to?`null`, but?by?using `Optional`, there?would be?no?way to?differentiate an?unbound `ScopedValue` from?one bound?to?`null`. That's right, an Optional view would have to deal with that. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From jvernee at openjdk.org Wed Nov 16 13:25:05 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 16 Nov 2022 13:25:05 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 00:44:50 GMT, Bo Zhang wrote: >> As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison. >> >> This PR fixes it by only comparing major versions. > > Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8296329: Only compare major versions in jar validator This looks good to me. Thanks for fixing. I'm running a test job for tier 1-4 as well Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11153 From duke at openjdk.org Wed Nov 16 14:02:32 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 16 Nov 2022 14:02:32 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v2] In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: the change according to review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11174/files - new: https://git.openjdk.org/jdk/pull/11174/files/0449a6d9..bcbba19e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=00-01 Stats: 13 lines in 2 files changed: 4 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11174/head:pull/11174 PR: https://git.openjdk.org/jdk/pull/11174 From duke at openjdk.org Wed Nov 16 14:04:10 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 16 Nov 2022 14:04:10 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: <29Al7cIKz22bCV-QFJPX9p7Nra4O9RtkODJZkADq-Jk=.d498ae55-f893-4f8d-a01d-a5ba962271dc@github.com> On Tue, 15 Nov 2022 19:02:30 GMT, Weibing Xiao wrote: > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. 1) Removed the link for CSR. 2) Add a new method in SystemProps.java to check if the warning message is required 3) Print the warning message directly in System::initPhase3 ------------- PR: https://git.openjdk.org/jdk/pull/11174 From aph at openjdk.org Wed Nov 16 14:13:29 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 14:13:29 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v8] In-Reply-To: References: Message-ID: <16r2j-OSTNYGEK74xtcCK4RxnFxJ1fztEjSy5uYZ8EY=.9aab72c6-3aa9-4621-bcfc-b1298c83e69d@github.com> > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/1bd9d47a..222ddcbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 16 14:18:01 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 14:18:01 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v9] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Oops ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/222ddcbc..2a2b0cca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Wed Nov 16 14:19:12 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 14:19:12 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v6] In-Reply-To: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> References: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> Message-ID: On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11033 From Alan.Bateman at oracle.com Wed Nov 16 14:22:44 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Nov 2022 14:22:44 +0000 Subject: Should Inflater & Deflater implement Closeable? In-Reply-To: <40895983-c628-09bf-2417-8bc458658c70@gmail.com> References: <9ccf3dcbfe1e44c8aaca9c877b5ee363@vodafonemail.de> <40895983-c628-09bf-2417-8bc458658c70@gmail.com> Message-ID: On 16/11/2022 04:15, Jaikiran Pai wrote: > There's https://bugs.openjdk.org/browse/JDK-8225763. I plan to revive > that effort some time soon, it's been on my todo list for the past few > months. Just to add to Jai's comment is that there is more to this that adding a close method that calls end. The close method should strive to be idempotent and the end method isn't. There is also interaction with subclassing that need to be worked out to avoid surprise. -Alan. From alanb at openjdk.org Wed Nov 16 14:41:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 14:41:58 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 12:34:29 GMT, Adam Sotona wrote: > Option --disable- at files is not recognised as valid JVM option, however it is already implemented in the launcher. > Proposed patch skips --disable- at files option in src/hotspot/share/runtime/arguments.cpp processing, so it does not fall into the category of unknown options. > The patch also corrects typo in the launcher.properties and adds simple DisableFilesOptionTest. > > Please review. > > Thank you, > Adam Are you sure this is right place to do this? There are other "launcher options" that aren't passed through to CreateJavaVM and I'm surprised this one is. ------------- PR: https://git.openjdk.org/jdk/pull/11183 From pminborg at openjdk.org Wed Nov 16 15:13:37 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 16 Nov 2022 15:13:37 GMT Subject: RFR: 8297145: Add a @sealedGraph tag to ConstantDesc Message-ID: <32YXgAxjMzKxazWeNKQIbrEqDG79l2MWz9WJdBM0A5I=.020ea8a9-d48d-4f3c-900c-6279533c8ddd@github.com> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the ConstantDesc class. Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 Here is how it would look like: ConstantDesc_SH ------------- Commit messages: - Add a @sealedGraph tag to ConstantDesc Changes: https://git.openjdk.org/jdk/pull/11187/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11187&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297145 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11187.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11187/head:pull/11187 PR: https://git.openjdk.org/jdk/pull/11187 From rriggs at openjdk.org Wed Nov 16 15:35:16 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 16 Nov 2022 15:35:16 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v2] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Wed, 16 Nov 2022 14:02:32 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > the change according to review comment src/java.base/share/classes/java/lang/System.java line 2249: > 2247: // Emit a warning if java.io.tmpdir is set via the command line to a directory that doesn't exist > 2248: if (SystemProps.checkIfWarningRequired()) { > 2249: System.err.println("WARNING: java.io.tmpdir location does not exist"); Change "location" to "directory", reflecting the exact check being done. src/java.base/share/classes/jdk/internal/util/SystemProps.java line 48: > 46: > 47: /** > 48: * check if warning for custom java.io.tmpdir is required Capitialize and add a period at the end. src/java.base/share/classes/jdk/internal/util/SystemProps.java line 52: > 50: * @return a boolean value > 51: */ > 52: public static boolean checkIfWarningRequired() { I would rename the method to `checkIoTmpdir`; it will be easier to see the purpose in the call in System. src/java.base/share/classes/jdk/internal/util/SystemProps.java line 70: > 68: HashMap props = raw.cmdProperties(); > 69: > 70: customTmpdir = props.get("java.io.tmpdir"); Move the assignment to line 98: `customTmpdir = putIfAbsent(props, "java.io.tmpdir", raw.propDefault(Raw._java_io_tmpdir_NDX));` It will return null if the property is not already set and save a little bit. If it is set, it will return the custom directory. test/jdk/java/io/File/TempDirectoryNotExisting.java line 45: > 43: > 44: String userDir = System.getProperty("user.home"); > 45: String timeStamp = System.currentTimeMillis() + ""; A human readable string might be useful. For example, "2022-11-16T15:10:50.622334Z" `java.time.Instant.now().toString()` test/jdk/java/io/File/TempDirectoryNotExisting.java line 49: > 47: > 48: if (args.length != 0) { > 49: if (args[0].equals("io")) { This code to cover the cases could be a bit cleaner and without duplication as: ``` for (String arg : args) { if (arg.equals("io")) { ... } else if (arg.equals("nio")) { ... } else { throw Exception("unknown case: " + arg); } } test/jdk/java/io/File/TempDirectoryNotExisting.java line 123: > 121: .filter(line -> line.equalsIgnoreCase(ioWarningMsg)) > 122: .collect(Collectors.toList()); > 123: if (list.size() != 1) throw new Exception("counter of messages is not one, but " + list.size()); If there's an error, print the list of messages; it can be very informative to see the unexpected messages, including the case where the exitValue is wrong. ------------- PR: https://git.openjdk.org/jdk/pull/11174 From aph at openjdk.org Wed Nov 16 15:47:05 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 15:47:05 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 11:38:10 GMT, Maurizio Cimadamore wrote: >> Mm, but this is the type of the value of the `ScopedValue` instance. >> So, the type of the scoped value is `ScopedValue`, the type of the value is `T`, is it not? > > Right - there's "scoped value" which is the holder, and "value of the scoped value" which is what has the type T. You are correct that just dropping "scoped" in there doesn't make things better. Conversely, just leaving "value" and nothing else (as per PR) is ambiguous. It feels like we need some way (uniform throughout the javadoc) to speak about "the value associated to a scoped value instance". I think that's the "bound value" of the instance or the "value bound to" the `ScopedValue` instance. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 16 16:01:10 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 16:01:10 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 19:15:21 GMT, Maurizio Cimadamore wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing serviceability tests > > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 460: > >> 458: * } >> 459: * >> 460: * @param key the ScopedValue key > > should use `@code` or `@link` Sorry, I don't understand what you want. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Wed Nov 16 16:04:17 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 16:04:17 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in SegmentScope javadoc src/java.base/share/classes/java/lang/foreign/Arena.java line 132: > 130: * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the > 131: * segments associated with that scope are also released. > 132: * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}. It's not wrong to specify that close throw if already closed but it goes against the advice in AutoCloseable to try to have close methods be idempotent. There may be a good reason for this but I can't help wondering if there are error cases when wrapping that might lead to close being called more than once. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Wed Nov 16 16:04:45 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 16:04:45 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 17:51:24 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Wrong line separator Compiler changes look good to me. I've left some comments on API javadoc, as well as other minor issues. It would be great to address them now, but I understand if there's no time. src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 115: > 113: * @throws Throwable if linkage fails > 114: */ > 115: public static CallSite stringTemplateBSM( In other classes in this package we never use `BSM` in the bootstrap name. Instead, we make some attempt to describe what the BSM does by picking some meaningful name (see SwitchBootstrap::typeSwitch). I think `newStringTemplate` (or `make`, `create`) would work here? src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 48: > 46: */ > 47: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 48: public sealed interface ProcessorLinkage permits FormatProcessor { Does this need to be exposed? FormatProcessor is the only permitted type, so javac could detect that (or have an internal list of supported optimized processors). src/java.base/share/classes/java/lang/template/StringProcessor.java line 31: > 29: > 30: /** > 31: * This interface simplifies declaration of Suggestion: * This interface simplifies the declaration of src/java.base/share/classes/java/lang/template/StringTemplate.java line 28: > 26: package java.lang.template; > 27: > 28: import java.lang.invoke.MethodHandle; Watch out for unused imports - I've seen them here and eslewhere src/java.base/share/classes/java/lang/template/StringTemplate.java line 38: > 36: > 37: /** > 38: * The Java compiler produces implementations of {@link StringTemplate} to I believe this descripton is now out of date - the compiler doesn't create implementations of StringTemplate, TemplateRuntime does - the compiler just request them. src/java.base/share/classes/java/lang/template/StringTemplate.java line 49: > 47: * The {@link StringTemplate#fragments()} method must return an immutable > 48: * {@code List} consistent with the string template body. The list > 49: * contains the string of characters preceeding each of the embedded expressions Suggestion: * contains the string of characters preceding each of the embedded expressions src/java.base/share/classes/java/lang/template/StringTemplate.java line 73: > 71: * {@code values} will be the equivalent of List.of(x, y, x + y). > 72: *

      > 73: * {@link StringTemplate StringTemplates} are primarily used in conjuction Suggestion: * {@link StringTemplate StringTemplates} are primarily used in conjunction src/java.base/share/classes/java/lang/template/StringTemplate.java line 106: > 104: * } > 105: * > 106: * @implSpec An instance of {@link StringTemplate} is immutatble. Also, the Suggestion: * @implSpec An instance of {@link StringTemplate} is immutable. Also, the src/java.base/share/classes/java/lang/template/StringTemplate.java line 120: > 118: /** > 119: * Returns an immutable list of string fragments consisting of the string > 120: * of characters preceeding each of the embedded expressions plus the Suggestion: * of characters preceding each of the embedded expressions plus the src/java.base/share/classes/java/lang/template/StringTemplate.java line 138: > 136: * Returns an immutable list of embedded expression results. In the example: > 137: * {@snippet : > 138: * StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; Would it make sense to use the same student/teacher example as above? Or, perhaps, we should use x and y everywhere? src/java.base/share/classes/java/lang/template/StringTemplate.java line 150: > 148: > 149: /** > 150: * {@return the interpolation of the StringTemplate} A `@link` or `@code` is missing around `StringTemplate`. I think this method needs an example for what interpolation means. Also, in the class javadoc we use the term `string interpolation` which is more specific and I prefer. We should probably use that term everywhere in this class. src/java.base/share/classes/java/lang/template/StringTemplate.java line 173: > 171: * @param Exception thrown type. > 172: * > 173: * @return constructed object of type R Missing `@code` or `@link` around `R` src/java.base/share/classes/java/lang/template/StringTemplate.java line 198: > 196: * @throws NullPointerException if stringTemplate is null > 197: */ > 198: public static String toString(StringTemplate stringTemplate) { `public` is redundant (here and elsewhere) src/java.base/share/classes/java/lang/template/StringTemplate.java line 208: > 206: > 207: /** > 208: * Returns a StringTemplate composed from a string. is `composed` the best term here? E.g. I'd prefer if this method actually told me what the properties of the returned template were - e.g. that it has one fragment (the string) and zero values. src/java.base/share/classes/java/lang/template/StringTemplate.java line 222: > 220: > 221: /** > 222: * Returns a StringTemplate composed from fragments and values. Suggestion: * Returns a StringTemplate with the given fragments and values. src/java.base/share/classes/java/lang/template/StringTemplate.java line 273: > 271: > 272: /** > 273: * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}. Suggestion: * Combine one or more {@link StringTemplate StringTemplates} into a single {@link StringTemplate}. src/java.base/share/classes/java/lang/template/StringTemplate.java line 302: > 300: > 301: /** > 302: * No-op template processor. Used to highlight that non-processing of the StringTemplate I wonder if there's a play to call this the "identity" processor. In the sense that it takes a template and just returns that unchanged. That would also help with calling it "raw" which creates confusion with some compiler messages. src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 31: > 29: > 30: /** > 31: * This interface simplifies declaration of Suggestion: * This interface simplifies the declaration of src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 44: > 42: * } > 43: * > 44: * @param Processor's process result type. Some code block/link missing? src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 28: > 26: package java.lang.template; > 27: > 28: import java.util.Objects; Watch out for unused imports src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 41: > 39: * This interface describes the methods provided by a generalized string template processor. The > 40: * primary method {@link ValidatingProcessor#process(StringTemplate)} is used to validate > 41: * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists. `compose` as in `produce` ? src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 86: > 84: * Composing allows user control over how the result is assembled. Most often, a > 85: * user will construct a new string from the template string, with placeholders > 86: * replaced by stringified objects from the values list. stringified looks funny - but have no idea on how to replace it src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 126: > 124: * } > 125: * The {@link StringTemplate#interpolate()} method is available for those processors > 126: * that just need to work with the interpolation; again, would be better to replace all bare occurrence of "interpolation" with "string interpolation" src/java.base/share/classes/java/util/FormatProcessor.java line 38: > 36: > 37: /** > 38: * This {@linkplain ValidatingProcessor template processor} constructs a String `String` is missing some javadoc wrapping src/java.base/share/classes/java/util/FormatProcessor.java line 39: > 37: /** > 38: * This {@linkplain ValidatingProcessor template processor} constructs a String > 39: * result using {@link Formatter}. Unlike {@link Formatter}, FormatProcessor uses the value from And `FormatProcessor` too src/java.base/share/classes/java/util/FormatProcessor.java line 42: > 40: * the embedded expression that follows immediately after the > 41: * format specifier. > 42: * StringTemplate expressions without a preceeding specifier, use "%s" by Suggestion: * StringTemplate expressions without a preceding specifier, use "%s" by src/java.base/share/classes/java/util/FormatProcessor.java line 51: > 49: * result is: 00010 + 00020 = 00030 > 50: * > 51: * @implNote When used in conjunction with a compiler generated {@link Is this comment still relevant? E.g. the `When used in conjunction with compiler generated...` part. Doesn't javac always emit a call to the optimized linkage entry if it sees that the processor used is a ProcessorLinkage? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 125: > 123: } > 124: > 125: Type makeListType(Type elemType) { Unused src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 136: > 134: } > 135: > 136: JCVariableDecl makeField(JCClassDecl cls, long flags, Name name, Type type, JCExpression init) { Unused src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 145: > 143: } > 144: > 145: MethodType makeMethodType(Type returnType, List argTypes) { Unused src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 149: > 147: } > 148: > 149: JCFieldAccess makeThisFieldSelect(Type owner, JCVariableDecl field) { Unused src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 156: > 154: } > 155: > 156: JCIdent makeParamIdent(List params, Name name) { Unused src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 171: > 169: } > 170: > 171: JCMethodInvocation makeApply(JCFieldAccess method, List args) { Unused src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 179: > 177: } > 178: > 179: JCFieldAccess makeFieldAccess(JCClassDecl owner, Name name) { Unused src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 223: > 221: JCStringTemplate tree; > 222: JCExpression processor; > 223: List fragments; I still believe some of these fields could be final src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 318: > 316: staticArgValues, staticArgsTypes); > 317: } else { > 318: VarSymbol processorSym = (VarSymbol)TreeInfo.symbol(processor); This seems unused src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1301: > 1299: # 0: symbol > 1300: compiler.err.raw.template.processor.type=\ > 1301: raw template processor type: {0} This error message can be confusing now that we have a RAW processor type. I'd suggest maybe rephrasing to `template processor type cannot be a raw type` src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java line 227: > 225: // templated string > 226: public final Name process; > 227: public final Name str; We have precedents for using capital variable names in this class, and we should probably do so here (for `str` and `raw`). ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Wed Nov 16 16:04:47 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 16:04:47 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:41:06 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 273: > >> 271: >> 272: /** >> 273: * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}. > > Suggestion: > > * Combine one or more {@link StringTemplate StringTemplates} into a single {@link StringTemplate}. Should we say more about what the properties of the returned template are? E.g. that the fragments are concatenated (in which order?) and values are also concatenated. > src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 41: > >> 39: * This interface describes the methods provided by a generalized string template processor. The >> 40: * primary method {@link ValidatingProcessor#process(StringTemplate)} is used to validate >> 41: * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists. > > `compose` as in `produce` ? This use of the word `compose` occurs in other places. While I'm not opposed to it, it has not to do with function composition in mathematical sense (unlike StringTemplate::compose), so I'd stay clear. > src/java.base/share/classes/java/util/FormatProcessor.java line 42: > >> 40: * the embedded expression that follows immediately after the >> 41: * format specifier. >> 42: * StringTemplate expressions without a preceeding specifier, use "%s" by > > Suggestion: > > * StringTemplate expressions without a preceding specifier, use "%s" by And, `StringTemplate` is missing a surrounding code/link tag ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Wed Nov 16 16:07:10 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 16 Nov 2022 16:07:10 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v5] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: - constexpr some functions - Review pt1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/7b1b95f5..3f375cfd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=03-04 Stats: 233 lines in 14 files changed: 69 ins; 110 del; 54 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From asotona at openjdk.org Wed Nov 16 16:12:57 2022 From: asotona at openjdk.org (Adam Sotona) Date: Wed, 16 Nov 2022 16:12:57 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 14:38:18 GMT, Alan Bateman wrote: > Are you sure this is right place to do this? There are other "launcher options" that aren't passed through to CreateJavaVM and I'm surprised this one is. I've found this place as a single spot handling (or skipping) tons of options and as a source of the error message. The launcher code I've investigated provides a lot of checking, however no suitable place to skip any option. Filtering in launcher would require significant refactoring, or repeated filtering on many spots to handle all alternative paths (unless I missed something important). Alternate suggestions are welcome, or link to relevant documentation, or an example of another filtered option. Thanks, Adam ------------- PR: https://git.openjdk.org/jdk/pull/11183 From mcimadamore at openjdk.org Wed Nov 16 16:16:21 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 16:16:21 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Wed, 16 Nov 2022 16:01:52 GMT, Alan Bateman wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typo in SegmentScope javadoc > > src/java.base/share/classes/java/lang/foreign/Arena.java line 132: > >> 130: * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the >> 131: * segments associated with that scope are also released. >> 132: * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}. > > It's not wrong to specify that close throw if already closed but it goes against the advice in AutoCloseable to try to have close methods be idempotent. There may be a good reason for this but I can't help wondering if there are error cases when wrapping that might lead to close being called more than once. In our experience with using the API, having exceptions when something is funny about close is very valuable info (as also stated in the javadoc). Almost always there's a subtle temporal bug going on which the ISE catches. I'm not sure if here you refer to the fact that the javadoc is being overly broad in saying "already been closed" instead of "already been closed _successfully_" ? What kind of problems are you thinking of? ------------- PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Wed Nov 16 16:16:22 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 16:16:22 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in SegmentScope javadoc src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 8: > 6: > 7: /** > 8: * A segment scope controls access to a memory segment. A passing comment here is that "to a memory segment" hints of one-to-one relationship when it's actually one-to-many. Arena is specified to control the lifecycle "of memory segments". ------------- PR: https://git.openjdk.org/jdk/pull/10872 From jlaskey at openjdk.org Wed Nov 16 16:28:20 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 16:28:20 GMT Subject: RFR: JDK-8285932 Implementation of JEP-430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 13:12:49 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 115: > >> 113: * @throws Throwable if linkage fails >> 114: */ >> 115: public static CallSite stringTemplateBSM( > > In other classes in this package we never use `BSM` in the bootstrap name. Instead, we make some attempt to describe what the BSM does by picking some meaningful name (see SwitchBootstrap::typeSwitch). I think `newStringTemplate` (or `make`, `create`) would work here? Reasonable. Changing. > src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java line 227: > >> 225: // templated string >> 226: public final Name process; >> 227: public final Name str; > > We have precedents for using capital variable names in this class, and we should probably do so here (for `str` and `raw`). Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From pminborg at openjdk.org Wed Nov 16 16:35:27 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 16 Nov 2022 16:35:27 GMT Subject: RFR: 8297148: Add a @sealedGraph tag to CallSite Message-ID: <8IJ8LRjjK2Tgwudor4KPiAhw-NmlLgXnZFtv6ctqn4w=.9e95d42d-4095-456f-8af5-0274f32eadd4@github.com> This PR proposes to opt in for graphic rendering of the sealed hierarchy of the CallSite class. Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 Here is how it would look like: CallSite_SH ------------- Commit messages: - Add a @sealedGraph tag to CallSite Changes: https://git.openjdk.org/jdk/pull/11190/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11190&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297148 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11190.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11190/head:pull/11190 PR: https://git.openjdk.org/jdk/pull/11190 From alanb at openjdk.org Wed Nov 16 16:40:31 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 16:40:31 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Wed, 16 Nov 2022 16:13:16 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/foreign/Arena.java line 132: >> >>> 130: * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the >>> 131: * segments associated with that scope are also released. >>> 132: * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}. >> >> It's not wrong to specify that close throw if already closed but it goes against the advice in AutoCloseable to try to have close methods be idempotent. There may be a good reason for this but I can't help wondering if there are error cases when wrapping that might lead to close being called more than once. > > In our experience with using the API, having exceptions when something is funny about close is very valuable info (as also stated in the javadoc). Almost always there's a subtle temporal bug going on which the ISE catches. I'm not sure if here you refer to the fact that the javadoc is being overly broad in saying "already been closed" instead of "already been closed _successfully_" ? What kind of problems are you thinking of? Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close. try (var arena = Arena.openConfined(); var wrapper = new MyWrapper(arena)) { : } ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Wed Nov 16 16:44:31 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 16:44:31 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Wed, 16 Nov 2022 16:38:10 GMT, Alan Bateman wrote: >> In our experience with using the API, having exceptions when something is funny about close is very valuable info (as also stated in the javadoc). Almost always there's a subtle temporal bug going on which the ISE catches. I'm not sure if here you refer to the fact that the javadoc is being overly broad in saying "already been closed" instead of "already been closed _successfully_" ? What kind of problems are you thinking of? > > Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close. > > try (var arena = Arena.openConfined(); > var wrapper = new MyWrapper(arena)) { > : > } Actually, I see that the `@apiNote` we used to have has disappeared in the API reshuffling. I will add it back. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From darcy at openjdk.org Wed Nov 16 16:45:04 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 16 Nov 2022 16:45:04 GMT Subject: RFR: 8297148: Add a @sealedGraph tag to CallSite In-Reply-To: <8IJ8LRjjK2Tgwudor4KPiAhw-NmlLgXnZFtv6ctqn4w=.9e95d42d-4095-456f-8af5-0274f32eadd4@github.com> References: <8IJ8LRjjK2Tgwudor4KPiAhw-NmlLgXnZFtv6ctqn4w=.9e95d42d-4095-456f-8af5-0274f32eadd4@github.com> Message-ID: On Wed, 16 Nov 2022 16:17:01 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy of the CallSite class. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > Here is how it would look like: > > CallSite_SH Helpful improvement. Are the type names in the diagram links? ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/11190 From jlaskey at openjdk.org Wed Nov 16 16:48:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 16:48:48 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:22:43 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 125: > >> 123: } >> 124: >> 125: Type makeListType(Type elemType) { > > Unused Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 136: > >> 134: } >> 135: >> 136: JCVariableDecl makeField(JCClassDecl cls, long flags, Name name, Type type, JCExpression init) { > > Unused Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 149: > >> 147: } >> 148: >> 149: JCFieldAccess makeThisFieldSelect(Type owner, JCVariableDecl field) { > > Unused Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 156: > >> 154: } >> 155: >> 156: JCIdent makeParamIdent(List params, Name name) { > > Unused Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 171: > >> 169: } >> 170: >> 171: JCMethodInvocation makeApply(JCFieldAccess method, List args) { > > Unused Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 179: > >> 177: } >> 178: >> 179: JCFieldAccess makeFieldAccess(JCClassDecl owner, Name name) { > > Unused Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 223: > >> 221: JCStringTemplate tree; >> 222: JCExpression processor; >> 223: List fragments; > > I still believe some of these fields could be final Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 318: > >> 316: staticArgValues, staticArgsTypes); >> 317: } else { >> 318: VarSymbol processorSym = (VarSymbol)TreeInfo.symbol(processor); > > This seems unused Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Wed Nov 16 16:54:41 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 16:54:41 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Wed, 16 Nov 2022 16:41:45 GMT, Maurizio Cimadamore wrote: >> Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close. >> >> try (var arena = Arena.openConfined(); >> var wrapper = new MyWrapper(arena)) { >> : >> } > > Actually, I see that the `@apiNote` we used to have has disappeared in the API reshuffling. I will add it back. > Most of the AutoCloseable in the platform are Closeables where close is specified to have no effect when already closed. With a confined Arena it would be benign for the owner to invoke close again. If it's been useful at finding bugs then okay. The scenario that made me wonder about this is something like the follow where MyWrapper::close invokes Arena::close. > > ``` > try (var arena = Arena.openConfined(); > var wrapper = new MyWrapper(arena)) { > : > } > ``` Sure - this would be problematic - however it seems an edge case (could the TWR just use MyWrapper?) I'd prefer to leave it as is for now, and revisit - so far we had no indications of this being a real problem, whereas we had cases where the thrown exception has been useful to spot issues. If consistency with the rest of the JDK is considered more important we can fix it later. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From psandoz at openjdk.org Wed Nov 16 16:54:47 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 16 Nov 2022 16:54:47 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in SegmentScope javadoc src/java.base/share/classes/java/lang/foreign/Arena.java line 132: > 130: * and all the memory segments associated with it can no longer be accessed. Furthermore, any off-heap region of memory backing the > 131: * segments associated with that scope are also released. > 132: * @throws IllegalStateException if the arena has already been {@linkplain #close() closed}. JavaDoc was pointing to itself. Suggestion: * @throws IllegalStateException if the arena has already been closed. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 109: > 107: * Finally, access operations on a memory segment are subject to the thread-confinement checks enforced by the associated > 108: * scope; that is, if the segment is the {@linkplain SegmentScope#global() global scope} or an {@linkplain SegmentScope#auto() automatic scope}, > 109: * it can be accessed by multiple threads. If the segment is associatd with an arena scope, then it can only be Typo: Suggestion: * it can be accessed by multiple threads. If the segment is associated with an arena scope, then it can only be src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 10: > 8: * A segment scope controls access to a memory segment. > 9: *

      > 10: * A memory segment can only be accessed while its scope is {@linkplain #isAlive() alive}. Moreoever, Typo: Suggestion: * A memory segment can only be accessed while its scope is {@linkplain #isAlive() alive}. Moreover, ------------- PR: https://git.openjdk.org/jdk/pull/10872 From aph at openjdk.org Wed Nov 16 16:55:24 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 16:55:24 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Javadoc changes. - ProblemList.txt cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/2a2b0cca..280cd6c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=08-09 Stats: 46 lines in 3 files changed: 8 ins; 6 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From jvernee at openjdk.org Wed Nov 16 17:00:04 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 16 Nov 2022 17:00:04 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v5] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:07:10 GMT, Jorn Vernee wrote: >> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. >> >> This is split off from the main JEP integration to make reviewing easier. >> >> This includes the following patches: >> >> 1. https://github.com/openjdk/panama-foreign/pull/698 >> 2. https://github.com/openjdk/panama-foreign/pull/699 >> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 >> 4. https://github.com/openjdk/panama-foreign/pull/740 >> 5. https://github.com/openjdk/panama-foreign/pull/746 >> 6. https://github.com/openjdk/panama-foreign/pull/742 >> 7. https://github.com/openjdk/panama-foreign/pull/743 >> >> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. >> >> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. >> >> Please refer to the PR of each individual patch for a more detailed description. > > Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision: > > - constexpr some functions > - Review pt1 I've address all review comments so far. I've limited use of `constexpr` to functions that are called on register constants to avoid having to put `constexpr` on too many things (for now). ------------- PR: https://git.openjdk.org/jdk/pull/11019 From jlaskey at openjdk.org Wed Nov 16 17:03:41 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 17:03:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:26:05 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 1301: > >> 1299: # 0: symbol >> 1300: compiler.err.raw.template.processor.type=\ >> 1301: raw template processor type: {0} > > This error message can be confusing now that we have a RAW processor type. I'd suggest maybe rephrasing to `template processor type cannot be a raw type` Agree. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jvernee at openjdk.org Wed Nov 16 17:04:03 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 16 Nov 2022 17:04:03 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v6] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: fix stubs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/3f375cfd..4d440443 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=04-05 Stats: 5 lines in 5 files changed: 0 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From pminborg at openjdk.org Wed Nov 16 17:03:43 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 16 Nov 2022 17:03:43 GMT Subject: RFR: 8297150: Add a @sealedGraph tag to Reference Message-ID: This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `Reference` class. Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 Here is how it would look like: Reference_SH ------------- Commit messages: - Add a @sealedGraph tag to Reference Changes: https://git.openjdk.org/jdk/pull/11191/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11191&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297150 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11191.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11191/head:pull/11191 PR: https://git.openjdk.org/jdk/pull/11191 From jlaskey at openjdk.org Wed Nov 16 17:14:07 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 17:14:07 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:26:55 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 28: > >> 26: package java.lang.template; >> 27: >> 28: import java.lang.invoke.MethodHandle; > > Watch out for unused imports - I've seen them here and eslewhere Cleaning up. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From naoto at openjdk.org Wed Nov 16 17:22:03 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 16 Nov 2022 17:22:03 GMT Subject: RFR: 8287180: Update IANA Language Subtag Registry to Version 2022-08-08 In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 20:03:42 GMT, Justin Lu wrote: > Problem: IANA Language subtag registry is outdated > Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10546 From darcy at openjdk.org Wed Nov 16 17:23:27 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 16 Nov 2022 17:23:27 GMT Subject: RFR: 8297150: Add a @sealedGraph tag to Reference In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:52:50 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `Reference` class. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > Here is how it would look like: > > Reference_SH Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11191 From darcy at openjdk.org Wed Nov 16 17:29:57 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 16 Nov 2022 17:29:57 GMT Subject: RFR: 8297145: Add a @sealedGraph tag to ConstantDesc In-Reply-To: <32YXgAxjMzKxazWeNKQIbrEqDG79l2MWz9WJdBM0A5I=.020ea8a9-d48d-4f3c-900c-6279533c8ddd@github.com> References: <32YXgAxjMzKxazWeNKQIbrEqDG79l2MWz9WJdBM0A5I=.020ea8a9-d48d-4f3c-900c-6279533c8ddd@github.com> Message-ID: <3JvJ8iLLoS2Lu9QOmO2aH5hposq8tQU1WzhACLzXMRA=.0440f4b2-0fc1-4149-a132-9bd64b70cf94@github.com> On Wed, 16 Nov 2022 15:02:08 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy of the ConstantDesc class. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > > Here is how it would look like: > > ConstantDesc_SH Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11187 From alanb at openjdk.org Wed Nov 16 17:30:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 17:30:04 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:10:45 GMT, Adam Sotona wrote: > Alternate suggestions are welcome, or link to relevant documentation, or an example of another filtered option. I think I would start in ParseArguments (libjli/java.c) to see the options that are handled, translated, or passed through. I can't be 100% sure how this one should be handled without studying it more closely. ------------- PR: https://git.openjdk.org/jdk/pull/11183 From jlaskey at openjdk.org Wed Nov 16 17:33:38 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 17:33:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:27:47 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 38: > >> 36: >> 37: /** >> 38: * The Java compiler produces implementations of {@link StringTemplate} to > > I believe this descripton is now out of date - the compiler doesn't create implementations of StringTemplate, TemplateRuntime does - the compiler just request them. Changing. `{@link StringTemplate StringTemplates} are runtime representations of Java string templates and text block templates` > src/java.base/share/classes/java/lang/template/StringTemplate.java line 49: > >> 47: * The {@link StringTemplate#fragments()} method must return an immutable >> 48: * {@code List} consistent with the string template body. The list >> 49: * contains the string of characters preceeding each of the embedded expressions > > Suggestion: > > * contains the string of characters preceding each of the embedded expressions Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 73: > >> 71: * {@code values} will be the equivalent of List.of(x, y, x + y). >> 72: *

      >> 73: * {@link StringTemplate StringTemplates} are primarily used in conjuction > > Suggestion: > > * {@link StringTemplate StringTemplates} are primarily used in conjunction Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 106: > >> 104: * } >> 105: * >> 106: * @implSpec An instance of {@link StringTemplate} is immutatble. Also, the > > Suggestion: > > * @implSpec An instance of {@link StringTemplate} is immutable. Also, the Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 138: > >> 136: * Returns an immutable list of embedded expression results. In the example: >> 137: * {@snippet : >> 138: * StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; > > Would it make sense to use the same student/teacher example as above? Or, perhaps, we should use x and y everywhere? At least for the fragments and values snippets. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 17:46:30 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 17:46:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:32:40 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 120: > >> 118: /** >> 119: * Returns an immutable list of string fragments consisting of the string >> 120: * of characters preceeding each of the embedded expressions plus the > > Suggestion: > > * of characters preceding each of the embedded expressions plus the Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 173: > >> 171: * @param Exception thrown type. >> 172: * >> 173: * @return constructed object of type R > > Missing `@code` or `@link` around `R` Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 17:50:21 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 17:50:21 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <38UI4LMzuSzoMTSR5_zThCxtwLtKcaFvhtqDgMhLwO0=.8b5e9e49-2f84-4994-ac6a-92694df10b8d@github.com> On Wed, 16 Nov 2022 15:36:30 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 198: > >> 196: * @throws NullPointerException if stringTemplate is null >> 197: */ >> 198: public static String toString(StringTemplate stringTemplate) { > > `public` is redundant (here and elsewhere) Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 17:56:37 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 17:56:37 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:37:10 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 208: > >> 206: >> 207: /** >> 208: * Returns a StringTemplate composed from a string. > > is `composed` the best term here? E.g. I'd prefer if this method actually told me what the properties of the returned template were - e.g. that it has one fragment (the string) and zero values. `Returns a StringTemplate as if constructed by invoking StringTemplate.of(List.of(string), List.of()).` Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 222: > >> 220: >> 221: /** >> 222: * Returns a StringTemplate composed from fragments and values. > > Suggestion: > > * Returns a StringTemplate with the given fragments and values. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 17:56:41 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 17:56:41 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:41:49 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 273: >> >>> 271: >>> 272: /** >>> 273: * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}. >> >> Suggestion: >> >> * Combine one or more {@link StringTemplate StringTemplates} into a single {@link StringTemplate}. > > Should we say more about what the properties of the returned template are? E.g. that the fragments are concatenated (in which order?) and values are also concatenated. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From lancea at openjdk.org Wed Nov 16 17:58:00 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 16 Nov 2022 17:58:00 GMT Subject: RFR: 8287180: Update IANA Language Subtag Registry to Version 2022-08-08 In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 20:03:42 GMT, Justin Lu wrote: > Problem: IANA Language subtag registry is outdated > Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10546 From jlaskey at openjdk.org Wed Nov 16 18:08:24 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 18:08:24 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <0aWXRpDkrrAKDAJMbeS9DCSWXu50yewb9HS_qIk2NlI=.3fdd1c46-85d7-4ba4-80d2-b6b113c458f7@github.com> On Wed, 16 Nov 2022 15:43:42 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 302: > >> 300: >> 301: /** >> 302: * No-op template processor. Used to highlight that non-processing of the StringTemplate > > I wonder if there's a play to call this the "identity" processor. In the sense that it takes a template and just returns that unchanged. That would also help with calling it "raw" which creates confusion with some compiler messages. It's a reasonable suggestion. This processor would used rarely, so calling it IDENTITY (more than 3 characters) is not an impediment. However, IDENTITY doesn't really speak to what it does. RAW was chosen primarily because it is what other languages use. (I had used NOOP earlier.) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 18:15:23 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 18:15:23 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:44:55 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 31: > >> 29: >> 30: /** >> 31: * This interface simplifies declaration of > > Suggestion: > > * This interface simplifies the declaration of Changing. > src/java.base/share/classes/java/lang/template/TemplateProcessor.java line 44: > >> 42: * } >> 43: * >> 44: * @param Processor's process result type. > > Some code block/link missing? `};` is in the snippet. `}` is the end of the snippet. > src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 28: > >> 26: package java.lang.template; >> 27: >> 28: import java.util.Objects; > > Watch out for unused imports Went through and did the import clean up en masse. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Wed Nov 16 18:18:43 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 18:18:43 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 17:04:03 GMT, Jorn Vernee wrote: >> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. >> >> This is split off from the main JEP integration to make reviewing easier. >> >> This includes the following patches: >> >> 1. https://github.com/openjdk/panama-foreign/pull/698 >> 2. https://github.com/openjdk/panama-foreign/pull/699 >> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 >> 4. https://github.com/openjdk/panama-foreign/pull/740 >> 5. https://github.com/openjdk/panama-foreign/pull/746 >> 6. https://github.com/openjdk/panama-foreign/pull/742 >> 7. https://github.com/openjdk/panama-foreign/pull/743 >> >> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. >> >> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. >> >> Please refer to the PR of each individual patch for a more detailed description. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > fix stubs Java changes look good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/11019 From redestad at openjdk.org Wed Nov 16 18:22:30 2022 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 16 Nov 2022 18:22:30 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode I'm getting pulled into other tasks and would request for this to be either accepted as-is, rejected or picked up by someone else to rewrite it to something that can be accepted. Obviously I'm biased towards acceptance: While imperfect, it provides improved testing - both functional and performance-wise - and establishes a significantly improved benchmark for more future-proof solutions to beat. There are many ways to iteratively improve upon this solution, some of which would even simplify the implementation. But in the face of upcoming changes that might allow C2 to optimize these kinds of loops without intrinsic support I am not sure spending more time on perfecting the current patch is worth our while. Rejecting it might be the reasonable thing to do, too, especially if the C2 loop optimizations @iwanowww points out might be coming around sooner rather than later. Even if that's not coming soon, the PR at hand adds a chunk of complexity for the compiler team to maintain. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From jlaskey at openjdk.org Wed Nov 16 18:27:35 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 18:27:35 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:54:49 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 48: > >> 46: */ >> 47: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >> 48: public sealed interface ProcessorLinkage permits FormatProcessor { > > Does this need to be exposed? FormatProcessor is the only permitted type, so javac could detect that (or have an internal list of supported optimized processors). Not worth changing at this point. The plan is to replace with TemplateProcessorFactories. > src/java.base/share/classes/java/lang/template/StringProcessor.java line 31: > >> 29: >> 30: /** >> 31: * This interface simplifies declaration of > > Suggestion: > > * This interface simplifies the declaration of Changing. > src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 86: > >> 84: * Composing allows user control over how the result is assembled. Most often, a >> 85: * user will construct a new string from the template string, with placeholders >> 86: * replaced by stringified objects from the values list. > > stringified looks funny - but have no idea on how to replace it * Composing allows user control over how the result is assembled. Most often, a * user will construct a new string from the string template, with placeholders * replaced by string representations of value list elements. These string * representations are created as if invoking {@link String#valueOf}. > src/java.base/share/classes/java/lang/template/ValidatingProcessor.java line 126: > >> 124: * } >> 125: * The {@link StringTemplate#interpolate()} method is available for those processors >> 126: * that just need to work with the interpolation; > > again, would be better to replace all bare occurrence of "interpolation" with "string interpolation" Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Wed Nov 16 18:28:23 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 18:28:23 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:58:49 GMT, Andrew Haley wrote: >> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 460: >> >>> 458: * } >>> 459: * >>> 460: * @param key the ScopedValue key >> >> should use `@code` or `@link` > > Sorry, I don't understand what you want. There is a "bare" reference to `ScopedValue`. Should it be `{@code ScopedValue}` or `{@link ScopedValue}` ? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From iris at openjdk.org Wed Nov 16 18:35:03 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 16 Nov 2022 18:35:03 GMT Subject: RFR: 8287180: Update IANA Language Subtag Registry to Version 2022-08-08 In-Reply-To: References: Message-ID: <8H7rDCCAyKCXQFBW6tzJ7E_PO92o0zGsSEOf-xqvaVY=.b1347130-e029-44bf-a6ad-019f8f43b97e@github.com> On Mon, 3 Oct 2022 20:03:42 GMT, Justin Lu wrote: > Problem: IANA Language subtag registry is outdated > Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10546 From jlaskey at openjdk.org Wed Nov 16 18:36:03 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 18:36:03 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:55:27 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/util/FormatProcessor.java line 38: > >> 36: >> 37: /** >> 38: * This {@linkplain ValidatingProcessor template processor} constructs a String > > `String` is missing some javadoc wrapping Changing. > src/java.base/share/classes/java/util/FormatProcessor.java line 39: > >> 37: /** >> 38: * This {@linkplain ValidatingProcessor template processor} constructs a String >> 39: * result using {@link Formatter}. Unlike {@link Formatter}, FormatProcessor uses the value from > > And `FormatProcessor` too Changing. > src/java.base/share/classes/java/util/FormatProcessor.java line 51: > >> 49: * result is: 00010 + 00020 = 00030 >> 50: * >> 51: * @implNote When used in conjunction with a compiler generated {@link > > Is this comment still relevant? E.g. the `When used in conjunction with compiler generated...` part. Doesn't javac always emit a call to the optimized linkage entry if it sees that the processor used is a ProcessorLinkage? Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 18:36:06 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 18:36:06 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 15:56:25 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/util/FormatProcessor.java line 42: >> >>> 40: * the embedded expression that follows immediately after the >>> 41: * format specifier. >>> 42: * StringTemplate expressions without a preceeding specifier, use "%s" by >> >> Suggestion: >> >> * StringTemplate expressions without a preceding specifier, use "%s" by > > And, `StringTemplate` is missing a surrounding code/link tag Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 18:47:51 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 18:47:51 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v22] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/e4812ee5..dcceb671 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=20-21 Stats: 231 lines in 13 files changed: 32 ins; 113 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From aph at openjdk.org Wed Nov 16 19:06:59 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 19:06:59 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com> References: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com> Message-ID: <6PNLRgFIjkvIRL_tIW0btKxdEapZI6_JC8roNRFBSws=.a6292551-ac7b-4f45-a851-3c4c614edc3b@github.com> On Fri, 4 Nov 2022 09:50:10 GMT, Andrew Haley wrote: >> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 481: >> >>> 479: } >>> 480: */ >>> 481: return findBinding() != Snapshot.NIL; >> >> This?should probably?call `Cache.put(this,?value)` when?`findBinding()` isn?t?`Snapshot.NIL`, since?it?s?likely that?`isBound()` will?most?commonly be?used in?the?form?of: >> >> if (SCOPED_VALUE.isBound()) { >> final var value = SCOPED_VALUE.get(); >> // do something with `value` >> } >> >> >> -------------------------------------------------------------------------------- >> >> Suggestion: >> >> var value = findBinding(); >> if (value == Snapshot.NIL) { >> return false; >> } >> Cache.put(this, value); >> return true; > > Probably so, yes. I'll have a look at that along with caching failure. So I just did the experiment of caching failures and the result of `isBound()`. This test: @Benchmark @OutputTimeUnit(TimeUnit.NANOSECONDS) public int thousandMaybeGets(Blackhole bh) throws Exception { int result = 0; for (int i = 0; i < 1_000; i++) { if (ScopedValuesData.sl1.isBound()) { result += ScopedValuesData.sl1.get(); } } return result; } Before and after: ScopedValues.thousandMaybeGets avgt 10 13436.112 ? 20.885 ns/op ScopedValues.thousandMaybeGets avgt 10 56.315 ? 0.583 ns/op You may have a point. The experiment is on a branch called `JDK-8286666-cache-queries` in [My personal repo](https://github.com/theRealAph/jdk). I'd push it now but it's getting a bit late to make such changes now. WDYT? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From jlaskey at openjdk.org Wed Nov 16 19:08:26 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 19:08:26 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:01:20 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > Compiler changes look good to me. I've left some comments on API javadoc, as well as other minor issues. It would be great to address them now, but I understand if there's no time. Thanks @mcimadamore. I think I've integrated most of your points. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From alex.buckley at oracle.com Wed Nov 16 19:10:20 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Nov 2022 11:10:20 -0800 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> Message-ID: <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> Below, a revised description for `StringTemplate`. // High-level opener. `StringTemplate` is the run-time representation of a string template or text block template in a template expression. [Sidebar. The JEP says "An instance of StringTemplate represents the string template or text block template that appears either as the template in a template expression, or as a standalone literal." -- the 'standalone literal' clause should be deleted.] // Basic concepts. No need to spell out details like immutability or return types here; leave them for the method specs. In the source code of a Java program, a string template or text block template contains an interleaved succession of _fragment literals_ and _embedded expressions_. The `fragments()` method returns the fragment literals, and the `values()` method returns the results of evaluating the embedded expressions. `StringTemplate` does not provide access to the source code of the embedded expressions themselves; it is not a compile-time representation of a string template or text block template. // Usage `StringTemplate` is primarily used in conjunction with a template processor to produce a string or other useful value. Evaluation of a template expression first produces an instance of `StringTemplate`, representing the template of the template expression, and then passes the instance to the template processor given by the template expression. For example, the following code contains a template expression that uses the template processor `RAW`, which simply yields the `StringTemplate` passed to it: int x = 10; int y = 20; StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; List fragments = st.fragments(); List values = st.values(); `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` will be the equivalent of `List.of(10, 20, 30)`. The following code contains a template expression with the same template but a different template processor: int x = 10; int y = 20; String s = STR."\{x} + \{y} = \{x + y}"; When the template expression is evaluated, an instance of `StringTemplate` is produced that returns the same lists from `fragments()` and `values()` as shown above. The `STR` template processor uses these lists to yield an interpolated string. `s` will be equivalent to `"10 + 20 = 30"`. The `interpolate()` method provides a direct way to perform string interpolation of a `StringTemplate`. Template processors can use the following code pattern: List fragments = st.fragments(); List values = st.values(); ... check or manipulate the fragments and/or values ... String result = StringTemplate.interpolate(fragments, values); The `process(ValidatingProcessor)` method provides an alternative to using string template expressions. [Sidebar. The example line of code which follows, is using a template expression. I'm not sure what was meant here.] String result = RAW."\{x} + \{y} = \{x + y}".process(STR); The factory methods `of(String)` and `of(List, List)` can be used to construct a `StringTemplate`. @implNote: Implementations of `StringTemplate` must minimally implement the methods fragments() and values(). Instances of `StringTemplate` are considered immutable. To preserve the semantics of string templates and text block templates, the list returned by `fragments()` must be one element larger than the list returned by `values()`. @jls 15.8.6 Alex On 11/16/2022 4:49 AM, Jim Laskey wrote: > May I get a final ?(PR) review of?JDK-8285932 Implementation of JEP-430 > String Templates (Preview) from core-libs and compiler. > > PR: https://github.com/openjdk/jdk/pull/10889 > > > > JBS: https://bugs.openjdk.org/browse/JDK-8285932 > > CSR: https://bugs.openjdk.org/browse/JDK-8286021 > > JEP: https://openjdk.org/jeps/430 > https://bugs.openjdk.org/browse/JDK-8273943 > > SPEC: https://bugs.openjdk.org/browse/JDK-8296302 > > > Thank you. > > Cheers, > > ? Jim > > From aph at openjdk.org Wed Nov 16 19:11:15 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 16 Nov 2022 19:11:15 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:26:15 GMT, Maurizio Cimadamore wrote: >> Sorry, I don't understand what you want. > > There is a "bare" reference to `ScopedValue`. Should it be `{@code ScopedValue}` or `{@link ScopedValue}` ? Ahh, OK. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From naoto at openjdk.org Wed Nov 16 19:15:59 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 16 Nov 2022 19:15:59 GMT Subject: RFR: 8297152: Add a @sealedGraph tag to ZoneId Message-ID: Adding a `@sealedGraph` tag to `ZoneId` class. ------------- Commit messages: - 8297152: Add a @sealedGraph tag to ZoneId Changes: https://git.openjdk.org/jdk/pull/11195/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11195&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297152 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11195.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11195/head:pull/11195 PR: https://git.openjdk.org/jdk/pull/11195 From jlahoda at openjdk.org Wed Nov 16 19:21:28 2022 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 16 Nov 2022 19:21:28 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 17:51:24 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Wrong line separator I've looked at the javac part, and added a few mostly minor comments. src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 77: > 75: import static com.sun.tools.javac.code.TypeTag.METHOD; > 76: import static com.sun.tools.javac.code.TypeTag.VOID; > 77: import com.sun.tools.javac.code.Types; This change is probably unnecessary? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 31: > 29: import java.util.stream.Collectors; > 30: > 31: import com.sun.tools.javac.code.*; There seem to be changes in this file that are not related to this patch (import section re-organization, addition of empty lines, but possibly also changes to `makeIndyQualifier`) - could these be, please, undone? src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 231: > 229: JCVariableDecl valuesVar; > 230: List fields; > 231: MethodInfo interpolateMethod; Some of the field here appear to be unused? Probably `stringTemplateClass`, `fragmentsVar`, `valuesVar`, `fields`, `interpolateMethod`. src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 700: > 698: S.setPrevToken(stringToken); > 699: } > 700: JCExpression t = F.at(pos).StringTemplate(processor, fragments, expressions); Should there be something like `toP(...)` around the `F.at...`, to set the end position of the tree? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1487: > 1485: if (typeArgs != null) return illegal(); > 1486: t = stringTemplate(t); > 1487: typeArgs = null; `typeArgs = null;` is unnecessary here, correct? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1715: > 1713: } > 1714: t = stringTemplate(t); > 1715: typeArgs = null; `typeArgs = null;` unnecessary? src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1716: > 1714: t = stringTemplate(t); > 1715: typeArgs = null; > 1716: // Uncomment to not allow follow on DOT What is the reason for this comment? Seems like it should be removed? ------------- PR: https://git.openjdk.org/jdk/pull/10889 From alanb at openjdk.org Wed Nov 16 19:17:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 16 Nov 2022 19:17:04 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 19:08:48 GMT, Andrew Haley wrote: >> There is a "bare" reference to `ScopedValue`. Should it be `{@code ScopedValue}` or `{@link ScopedValue}` ? > > Ahh, OK. We fixed those in the recent update. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From james.laskey at oracle.com Wed Nov 16 20:06:58 2022 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 16 Nov 2022 20:06:58 +0000 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> Message-ID: CSR and available docs have been changed to reflect these changes. https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html Cheers, ? Jim On Nov 16, 2022, at 3:10 PM, Alex Buckley > wrote: Below, a revised description for `StringTemplate`. // High-level opener. `StringTemplate` is the run-time representation of a string template or text block template in a template expression. [Sidebar. The JEP says "An instance of StringTemplate represents the string template or text block template that appears either as the template in a template expression, or as a standalone literal." -- the 'standalone literal' clause should be deleted.] // Basic concepts. No need to spell out details like immutability or return types here; leave them for the method specs. In the source code of a Java program, a string template or text block template contains an interleaved succession of _fragment literals_ and _embedded expressions_. The `fragments()` method returns the fragment literals, and the `values()` method returns the results of evaluating the embedded expressions. `StringTemplate` does not provide access to the source code of the embedded expressions themselves; it is not a compile-time representation of a string template or text block template. // Usage `StringTemplate` is primarily used in conjunction with a template processor to produce a string or other useful value. Evaluation of a template expression first produces an instance of `StringTemplate`, representing the template of the template expression, and then passes the instance to the template processor given by the template expression. For example, the following code contains a template expression that uses the template processor `RAW`, which simply yields the `StringTemplate` passed to it: int x = 10; int y = 20; StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; List fragments = st.fragments(); List values = st.values(); `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` will be the equivalent of `List.of(10, 20, 30)`. The following code contains a template expression with the same template but a different template processor: int x = 10; int y = 20; String s = STR."\{x} + \{y} = \{x + y}"; When the template expression is evaluated, an instance of `StringTemplate` is produced that returns the same lists from `fragments()` and `values()` as shown above. The `STR` template processor uses these lists to yield an interpolated string. `s` will be equivalent to `"10 + 20 = 30"`. The `interpolate()` method provides a direct way to perform string interpolation of a `StringTemplate`. Template processors can use the following code pattern: List fragments = st.fragments(); List values = st.values(); ... check or manipulate the fragments and/or values ... String result = StringTemplate.interpolate(fragments, values); The `process(ValidatingProcessor)` method provides an alternative to using string template expressions. [Sidebar. The example line of code which follows, is using a template expression. I'm not sure what was meant here.] String result = RAW."\{x} + \{y} = \{x + y}".process(STR); The factory methods `of(String)` and `of(List, List)` can be used to construct a `StringTemplate`. @implNote: Implementations of `StringTemplate` must minimally implement the methods fragments() and values(). Instances of `StringTemplate` are considered immutable. To preserve the semantics of string templates and text block templates, the list returned by `fragments()` must be one element larger than the list returned by `values()`. @jls 15.8.6 Alex On 11/16/2022 4:49 AM, Jim Laskey wrote: May I get a final (PR) review of JDK-8285932 Implementation of JEP-430 String Templates (Preview) from core-libs and compiler. PR: https://github.com/openjdk/jdk/pull/10889 JBS: https://bugs.openjdk.org/browse/JDK-8285932 CSR: https://bugs.openjdk.org/browse/JDK-8286021 JEP: https://openjdk.org/jeps/430 https://bugs.openjdk.org/browse/JDK-8273943 SPEC: https://bugs.openjdk.org/browse/JDK-8296302 Thank you. Cheers, ? Jim -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.org Wed Nov 16 20:16:00 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 20:16:00 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:07:51 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ArgumentAttr.java line 77: > >> 75: import static com.sun.tools.javac.code.TypeTag.METHOD; >> 76: import static com.sun.tools.javac.code.TypeTag.VOID; >> 77: import com.sun.tools.javac.code.Types; > > This change is probably unnecessary? Changing > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 231: > >> 229: JCVariableDecl valuesVar; >> 230: List fields; >> 231: MethodInfo interpolateMethod; > > Some of the field here appear to be unused? Probably `stringTemplateClass`, `fragmentsVar`, `valuesVar`, `fields`, `interpolateMethod`. Cleaned up earlier. > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1716: > >> 1714: t = stringTemplate(t); >> 1715: typeArgs = null; >> 1716: // Uncomment to not allow follow on DOT > > What is the reason for this comment? Seems like it should be removed? Not sure. Note to future self that if we allow relaxed use of processors, this is where to make change. Open to alternate methodology. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 20:20:02 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 20:20:02 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <-saM3CI4tVMG5xi1DE0XcDRCCT_ixtSJkKTza8X-Tng=.0f3e13c6-c393-4137-b2d3-ef62c99f9d9d@github.com> On Wed, 16 Nov 2022 19:16:26 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 700: > >> 698: S.setPrevToken(stringToken); >> 699: } >> 700: JCExpression t = F.at(pos).StringTemplate(processor, fragments, expressions); > > Should there be something like `toP(...)` around the `F.at...`, to set the end position of the tree? Added. > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1715: > >> 1713: } >> 1714: t = stringTemplate(t); >> 1715: typeArgs = null; > > `typeArgs = null;` unnecessary? Will remove the section for now and make a note elsewhere. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 20:20:04 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 20:20:04 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:12:11 GMT, Jim Laskey wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1716: >> >>> 1714: t = stringTemplate(t); >>> 1715: typeArgs = null; >>> 1716: // Uncomment to not allow follow on DOT >> >> What is the reason for this comment? Seems like it should be removed? > > Not sure. Note to future self that if we allow relaxed use of processors, this is where to make change. Open to alternate methodology. Will drop for now. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 20:28:14 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 20:28:14 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:52:33 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 31: > >> 29: import java.util.stream.Collectors; >> 30: >> 31: import com.sun.tools.javac.code.*; > > There seem to be changes in this file that are not related to this patch (import section re-organization, addition of empty lines, but possibly also changes to `makeIndyQualifier`) - could these be, please, undone? Reverting. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 16 20:33:50 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 16 Nov 2022 20:33:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v23] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Requested changes #8 - Update StringTemplate javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/dcceb671..2edc7925 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=21-22 Stats: 119 lines in 4 files changed: 42 ins; 43 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Wed Nov 16 20:38:51 2022 From: duke at openjdk.org (duke) Date: Wed, 16 Nov 2022 20:38:51 GMT Subject: Withdrawn: 8293910: tools/launcher/FXLauncherTest.java fail with jfx In-Reply-To: References: Message-ID: On Fri, 16 Sep 2022 07:35:03 GMT, Leslie Zhai wrote: > Hi, > > @dumasun reported the issue: > > Configured with jfx-ls-modular-sdk: > > > configure --with-import-modules=modular-sdk > > > `make run-test CONF=fastdebug TEST="tools/launcher/FXLauncherTest.java"` failed: > > > ----------System.err:(11/697)---------- > java.lang.RuntimeException: JavaFX modules erroneously included in the JDK > at FXLauncherTest.main(FXLauncherTest.java:451) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:578) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:1589) > > JavaTest Message: Test threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.RuntimeException: JavaFX modules erroneously included in the JDK > > > Thanks, > Leslie Zhai This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10299 From rriggs at openjdk.org Wed Nov 16 20:40:24 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 16 Nov 2022 20:40:24 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Mon, 14 Nov 2022 17:51:24 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Wrong line separator Mostly comments to make the code easier to read and understand. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1826: > 1824: > 1825: // Used by StringConcatHelper via JLA. > 1826: long mix(long lengthCoder) { `mix` is not a very descriptive name (in all of the places it is used). Perhaps a name that captures the combination of coder and length. `coderAndLength()` or similar The implementation here can do the wrong thing if the `lengthCoder` already includes the bit for UTF16 and the coder for the AbstractStringBuilder is LATIN1. Or is intentional that it will upgrade to UTF16? That could definately use a comment. src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 58: > 56: * optimized {@link StringTemplate StringTemplates} based on StringTemplateImpl. > 57: *

      > 58: * Bootstraps in the for of (Lookup, String, MethodType, MethodHandle, String...) "in the for" -> "in the form" src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 116: > 114: */ > 115: public static CallSite stringTemplateBSM( > 116: MethodHandles.Lookup lookup, The predominate style for method declarations puts the first argument on the same line as the method name and the closing ")" on the same line with the last argument and exceptions. src/java.base/share/classes/java/lang/template/Carriers.java line 628: > 626: * types. > 627: */ > 628: private static class CarrierShape { Is this a candidate to be a Record? src/java.base/share/classes/java/lang/template/StringProcessor.java line 31: > 29: > 30: /** > 31: * This interface simplifies declaration of The first sentence should describe the purpose or function of the interface. The "simplify declaration" language is a design rationale, not a functional description of the interface. src/java.base/share/classes/java/lang/template/StringTemplate.java line 38: > 36: > 37: /** > 38: * The Java compiler produces implementations of {@link StringTemplate} to I'd rather see a first sentence that says what a StringTemplate is, not who produces it. For example, a StringTemplate holds and controls the processing of the fragments and expressions of a string template. src/java.base/share/classes/java/lang/template/StringTemplate.java line 189: > 187: > 188: /** > 189: * Produces a diagnostic string representing the supplied The description should include that it describe the fragments and values. src/java.base/share/classes/java/lang/template/StringTemplate.java line 208: > 206: > 207: /** > 208: * Returns a StringTemplate composed from a string. and no values. src/java.base/share/classes/java/lang/template/StringTemplate.java line 249: > 247: > 248: /** > 249: * Creates a string that interleaves the elements of values between the It might be worth noting that this is the same as STR::interpolate. src/java.base/share/classes/java/lang/template/StringTemplate.java line 273: > 271: > 272: /** > 273: * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}. The description should be more specific about how the lists of fragments and values are combined. For example, is each StringTemplate well formed and have the required string and value counts. (Or when combined, is it only the case that the total number of strings and values meet the n+1/n requirement. I'm not sure this API point pulls it weight in the API. src/java.base/share/classes/java/lang/template/StringTemplate.java line 291: > 289: > 290: /** > 291: * Interpolation template processor instance. Flesh out this description since it is automatically imported and will appear in user code, it should have a clear description. (Same for RAW, expand the description). src/java.base/share/classes/java/lang/template/StringTemplateImpl.java line 35: > 33: > 34: /** > 35: * This class implements specialized {@link StringTemplate StringTemplates} produced by A cross reference to the public api the compiler uses to create these would be useful. So the reader can find the place to start reading. src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 187: > 185: @Override > 186: public StringTemplate newStringTemplate(List fragments, List values) { > 187: return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray())); `values.toArray()` returns a new array; no need to stream the list content. Alt: `Arrays.asList(values.toArray())` src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 202: > 200: @SuppressWarnings({"unchecked", "varargs"}) > 201: private static List toList(E... elements) { > 202: return Collections.unmodifiableList(Arrays.asList(elements)); Is a defensive copy needed here? The caller of `newStringTemplate` could retain a reference to the Object[] array and modify it later. src/java.base/share/classes/java/util/FormatProcessor.java line 102: > 100: * specifier that is incompatible with the given arguments, > 101: * insufficient arguments given the format string, or other > 102: * illegal conditions. For specification of all possible This fragment "For specification of all possible formatting errors." seems to be incomplete or unnecessary. src/java.base/share/classes/java/util/FormatProcessor.java line 154: > 152: > 153: /** > 154: * Convert a {@link StringTemplate} fragments, containing format specifications, Extraneous "a". src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 51: > 49: * > 50: * @param lengthCoder current value of the length + coder > 51: * @param buffer buffer to right into right -> write ------------- PR: https://git.openjdk.org/jdk/pull/10889 From tvaleev at openjdk.org Wed Nov 16 21:21:42 2022 From: tvaleev at openjdk.org (Tagir F. Valeev) Date: Wed, 16 Nov 2022 21:21:42 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:25:30 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 202: > >> 200: @SuppressWarnings({"unchecked", "varargs"}) >> 201: private static List toList(E... elements) { >> 202: return Collections.unmodifiableList(Arrays.asList(elements)); > > Is a defensive copy needed here? > The caller of `newStringTemplate` could retain a reference to the Object[] array and modify it later. Alternatively, `SharedSecrets.getJavaUtilCollectionAccess().listFromTrustedArrayNullsAllowed(elements)` (or `elements.clone()`) could be used here, to reduce amount of wrappers. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From iris at openjdk.org Wed Nov 16 21:37:03 2022 From: iris at openjdk.org (Iris Clark) Date: Wed, 16 Nov 2022 21:37:03 GMT Subject: RFR: 8297152: Add a @sealedGraph tag to ZoneId In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 19:07:48 GMT, Naoto Sato wrote: > Adding a `@sealedGraph` tag to `ZoneId` class. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11195 From alex.buckley at oracle.com Wed Nov 16 21:41:28 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Nov 2022 13:41:28 -0800 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> Message-ID: <06693be8-6ae0-34c1-8fb3-b02b472dc030@oracle.com> The first line says StringTemplates, should say StringTemplate. The paragraph about the `process(ValidatingProcessor)` method is confusing -- it's not an alternative to using template expressions if the example needs to show a template expression before invoking `process`. I think you mean to say something about supporting deferred evaluation of a template expression, in conjunction with the RAW processor? The implNote: "Libraries may produce StringTemplate instances as long as they conform to the requirements of this interface." -- there's no need to say this if the requirements (e.g. for immutability) are spelled out in the normative specs (keep reading). The immutability of lists returned from `fragments()` and `values()` is mentioned both in the user-level spec ("Returns this StringTemplate's immutable list ...") and in the implementer-level spec ("The list returned is immutable."). That's a recipe for confusion. Better to drop the @implNote and commit to immutability as core to the method's result: --- Returns a list of the fragment literals for this StringTemplate. The fragment literals are the character sequences preceding each of the embedded expressions in source code, plus the character sequence following the last embedded expression. Such character sequences may be zero-length if an embedded expression appears at the beginning or end of a template, or if two embedded expressions are directly adjacent in a template. The list is immutable. [I'm not sure why this is important, but OK.] --- The spec of the `interpolate` method has a stray dot and an example which calls `interpolation()`. Please rename `string` to `result`. Say: @return A string denoting the interpolation of this `StringTemplate`'s fragments and values. Alex On 11/16/2022 12:06 PM, Jim Laskey wrote: > CSR and available docs have been changed to reflect these changes. > > https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html > > Cheers, > > ? Jim > > >> On Nov 16, 2022, at 3:10 PM, Alex Buckley > > wrote: >> >> Below, a revised description for `StringTemplate`. >> >> >> // High-level opener. >> >> `StringTemplate` is the run-time representation of a string template >> or text block template in a template expression. >> >> [Sidebar. The JEP says "An instance of StringTemplate represents the >> string template or text block template that appears either as the >> template in a template expression, or as a standalone literal." -- the >> 'standalone literal' clause should be deleted.] >> >> // Basic concepts. No need to spell out details like immutability or >> return types here; leave them for the method specs. >> >> In the source code of a Java program, a string template or text block >> template contains an interleaved succession of _fragment literals_ and >> _embedded expressions_. The `fragments()` method returns the fragment >> literals, and the `values()` method returns the results of evaluating >> the embedded expressions. `StringTemplate` does not provide access to >> the source code of the embedded expressions themselves; it is not a >> compile-time representation of a string template or text block template. >> >> // Usage >> >> `StringTemplate` is primarily used in conjunction with a template >> processor to produce a string or other useful value. Evaluation of a >> template expression first produces an instance of `StringTemplate`, >> representing the template of the template expression, and then passes >> the instance to the template processor given by the template expression. >> >> For example, the following code contains a template expression that >> uses the template processor `RAW`, which simply yields the >> `StringTemplate` passed to it: >> >> int x = 10; >> int y = 20; >> StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; >> List fragments = st.fragments(); >> List values ???= st.values(); >> >> `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` >> will be the equivalent of `List.of(10, 20, 30)`. >> >> The following code contains a template expression with the same >> template but a different template processor: >> >> int x = 10; >> int y = 20; >> String s = STR."\{x} + \{y} = \{x + y}"; >> >> When the template expression is evaluated, an instance of >> `StringTemplate` is produced that returns the same lists from >> `fragments()` and `values()` as shown above. The `STR` template >> processor uses these lists to yield an interpolated string. `s` will >> be equivalent to `"10 + 20 = 30"`. >> >> The `interpolate()` method provides a direct way to perform string >> interpolation of a `StringTemplate`. Template processors can use the >> following code pattern: >> >> List fragments = st.fragments(); >> List values ???= st.values(); >> ... check or manipulate the fragments and/or values ... >> String result = StringTemplate.interpolate(fragments, values); >> >> The `process(ValidatingProcessor)` method provides an alternative to >> using string template expressions. ?[Sidebar. The example line of code >> which follows, is using a template expression. I'm not sure what was >> meant here.] >> >> String result = RAW."\{x} + \{y} = \{x + y}".process(STR); >> >> The factory methods `of(String)` and `of(List, List)` can be used to >> construct a `StringTemplate`. >> >> @implNote: Implementations of `StringTemplate` must minimally >> implement the methods fragments() and values(). Instances of >> `StringTemplate` are considered immutable. To preserve the semantics >> of string templates and text block templates, the list returned by >> `fragments()` must be one element larger than the list returned by >> `values()`. >> >> @jls 15.8.6 >> >> >> Alex >> >> On 11/16/2022 4:49 AM, Jim Laskey wrote: >>> May I get a final ?(PR) review of?JDK-8285932 Implementation of >>> JEP-430 String Templates (Preview) from core-libs and compiler. >>> PR: https://github.com/openjdk/jdk/pull/10889 >>> >>> >> > >>> JBS: https://bugs.openjdk.org/browse/JDK-8285932 >>> >>> >> > >>> CSR: https://bugs.openjdk.org/browse/JDK-8286021 >>> >>> >> > >>> JEP: https://openjdk.org/jeps/430 >>> > >>> https://bugs.openjdk.org/browse/JDK-8273943 >>> >>> >> > >>> SPEC: https://bugs.openjdk.org/browse/JDK-8296302 >>> >>> >> > >>> Thank you. >>> Cheers, >>> ? Jim > From coleenp at openjdk.org Wed Nov 16 22:30:19 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 16 Nov 2022 22:30:19 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file The release note is closed/delivered which I think blocked reviewing this PR. Please review! ------------- PR: https://git.openjdk.org/jdk/pull/11023 From mcimadamore at openjdk.org Wed Nov 16 22:30:32 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 16 Nov 2022 22:30:32 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v23] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:33:50 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Requested changes #8 > - Update StringTemplate javadoc Marked as reviewed by mcimadamore (Reviewer). src/java.base/share/classes/java/lang/template/StringTemplate.java line 34: > 32: > 33: /** > 34: * {@link StringTemplate StringTemplates} is the run-time representation of a Suggestion: * {@link StringTemplate StringTemplate} is the run-time representation of a src/java.base/share/classes/java/lang/template/StringTemplate.java line 218: > 216: > 217: /** > 218: * Returns a StringTemplate as if constructed by invoking Suggestion: * Returns a {@code StringTemplate} as if constructed by invoking src/java.base/share/classes/java/lang/template/StringTemplate.java line 233: > 231: > 232: /** > 233: * Returns a StringTemplate with the given fragments and values. Suggestion: * Returns a {@code StringTemplate} with the given fragments and values. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From joehw at openjdk.org Wed Nov 16 22:54:03 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 16 Nov 2022 22:54:03 GMT Subject: RFR: 8297152: Add a @sealedGraph tag to ZoneId In-Reply-To: References: Message-ID: <_-TLUSUmCzXUo-3IuPHpKmSC0ZeV3W0Q0Mg4F__0Caw=.9b1397b1-1594-4c80-96d5-7efbbc8602e1@github.com> On Wed, 16 Nov 2022 19:07:48 GMT, Naoto Sato wrote: > Adding a `@sealedGraph` tag to `ZoneId` class. Get a nice graph! ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk/pull/11195 From sspitsyn at openjdk.org Wed Nov 16 23:23:20 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 16 Nov 2022 23:23:20 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11023 From john.r.rose at oracle.com Wed Nov 16 23:41:16 2022 From: john.r.rose at oracle.com (John Rose) Date: Wed, 16 Nov 2022 15:41:16 -0800 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> Message-ID: On 16 Nov 2022, at 11:10, Alex Buckley wrote: > ? > For example, the following code contains a template expression that > uses the template processor `RAW`, which simply yields the > `StringTemplate` passed to it: > > int x = 10; > int y = 20; > StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; > List fragments = st.fragments(); > List values = st.values(); > > `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` > will be the equivalent of `List.of(10, 20, 30)`. > ? > To preserve the semantics of string templates and text block > templates, the list returned by `fragments()` must be one element > larger than the list returned by `values()`. And yet, in the example given above, the list of fragments `List.of(" + ", " = ")` is one element *smaller* than the list of values `List.of(10, 20, 30)`. The example is wrong. It?s worth a note in the doc that if an interpolated expression begins and/or ends the template, there will be a zero length fragment at the beginning or end of the fragments list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.buckley at oracle.com Wed Nov 16 23:59:15 2022 From: alex.buckley at oracle.com (Alex Buckley) Date: Wed, 16 Nov 2022 15:59:15 -0800 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> Message-ID: On 11/16/2022 3:41 PM, John Rose wrote: > And yet, in the example given above, the list of fragments |List.of(" + > ", " = ")| is one element /smaller/ than the list of values |List.of(10, > 20, 30)|. The example is wrong. It?s worth a note in the doc that if an > interpolated expression begins and/or ends the template, there will be a > zero length fragment at the beginning or end of the fragments list. Jim already caught and fixed the list examples in the latest javadoc, which says: --- fragments will be equivalent to List.of("", " + ", " = ", "") and values will be the equivalent of List.of(10, 20, 30). --- I agree that the javadoc should flag the existence of zero-length fragments; my later mail offered text for `fragments()` and `values()` which did so; that offering should be treated as merely the first draft of how to explain the reification of a source-code template. Alex From dholmes at openjdk.org Thu Nov 17 01:31:17 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Nov 2022 01:31:17 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 12:34:29 GMT, Adam Sotona wrote: > Option --disable- at files is not recognised as valid JVM option, however it is already implemented in the launcher. > Proposed patch skips --disable- at files option in src/hotspot/share/runtime/arguments.cpp processing, so it does not fall into the category of unknown options. > The patch also corrects typo in the launcher.properties and adds simple DisableFilesOptionTest. > > Please review. > > Thank you, > Adam As far as I can see @-file processing is a launcher feature, including the expansion of JDK_JAVA_OPTIONS, so it should never be getting passed through to the VM in the first place. What I can't figure out is how the test tools/launcher/ArgsFileTest.java is working when the JVM won't start with that flag on the command-line ?? BTW for future reference for the test case we are no longer creating tests using the bug id as a directory, instead tests should be grouped into functional areas. Thanks. I was also surprised to see the i8N changes here as I thought that was normally handled seperately. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11183 From dholmes at openjdk.org Thu Nov 17 01:40:17 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Nov 2022 01:40:17 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file Still think this needs a CSR request - sorry. If it warrants a RN it warrants a CSR request. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From dholmes at openjdk.org Thu Nov 17 01:48:21 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 17 Nov 2022 01:48:21 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v6] In-Reply-To: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> References: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> Message-ID: <8tD0490Li8PSucFYka-cFON3vgNAK-Ti79yN9K3oKNo=.59d97ce0-227a-467d-8a7c-54d00b31aa7f@github.com> On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. Seems okay to me. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Thu Nov 17 02:14:18 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Nov 2022 02:14:18 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file https://bugs.openjdk.org/browse/JDK-8297169 Probably needs better wording. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From smarks at openjdk.org Thu Nov 17 03:42:51 2022 From: smarks at openjdk.org (Stuart Marks) Date: Thu, 17 Nov 2022 03:42:51 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations In-Reply-To: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: <2GNesaBowrc4JsrLclxK_oBT5VONCYCjnByGgBOms1A=.50a1e09f-7d9b-4b76-8ad2-735c9d2f6ece@github.com> On Tue, 15 Nov 2022 02:10:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? > > The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. > > `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: > > > Objects.requireNonNull(action); > while (hasNext()) > action.accept(next()); > > Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. > > The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. > > New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java line 235: > 233: // verify the iterator didn't advance > 234: Assert.assertTrue("Iterator unexpectedly doesn't have any entry", it.hasNext()); > 235: } The checks in Collections.java look good. The tests can be simplified, I think. The reproducers in the original bug report wrap an empty map in either an unmodifiable map or a checked map, so you could just test them with entrySet().iterator().forEachRemaining(null). Those cases do nothing in the current JDK when they indeed should throw NPE. Probably just test for NPE thrown/not-thrown instead of trying to ascertain the position of the iterator. ------------- PR: https://git.openjdk.org/jdk/pull/11154 From jpai at openjdk.org Thu Nov 17 06:05:40 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 17 Nov 2022 06:05:40 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations [v2] In-Reply-To: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: > Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? > > The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. > > `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: > > > Objects.requireNonNull(action); > while (hasNext()) > action.accept(next()); > > Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. > > The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. > > New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: review suggestion - simplify test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11154/files - new: https://git.openjdk.org/jdk/pull/11154/files/b58984ec..ff4c2613 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11154&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11154&range=00-01 Stats: 18 lines in 1 file changed: 0 ins; 12 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11154.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11154/head:pull/11154 PR: https://git.openjdk.org/jdk/pull/11154 From jpai at openjdk.org Thu Nov 17 06:11:27 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 17 Nov 2022 06:11:27 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations [v2] In-Reply-To: <2GNesaBowrc4JsrLclxK_oBT5VONCYCjnByGgBOms1A=.50a1e09f-7d9b-4b76-8ad2-735c9d2f6ece@github.com> References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> <2GNesaBowrc4JsrLclxK_oBT5VONCYCjnByGgBOms1A=.50a1e09f-7d9b-4b76-8ad2-735c9d2f6ece@github.com> Message-ID: On Thu, 17 Nov 2022 03:39:37 GMT, Stuart Marks wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> review suggestion - simplify test > > test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java line 235: > >> 233: // verify the iterator didn't advance >> 234: Assert.assertTrue("Iterator unexpectedly doesn't have any entry", it.hasNext()); >> 235: } > > The checks in Collections.java look good. > > The tests can be simplified, I think. The reproducers in the original bug report wrap an empty map in either an unmodifiable map or a checked map, so you could just test them with entrySet().iterator().forEachRemaining(null). Those cases do nothing in the current JDK when they indeed should throw NPE. Probably just test for NPE thrown/not-thrown instead of trying to ascertain the position of the iterator. Hello Stuart, I have now updated the PR to simplify the test as suggested. New test methods continue to fail without the source change and pass with this fix. ------------- PR: https://git.openjdk.org/jdk/pull/11154 From jpai at openjdk.org Thu Nov 17 07:43:21 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 17 Nov 2022 07:43:21 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: <29Al7cIKz22bCV-QFJPX9p7Nra4O9RtkODJZkADq-Jk=.d498ae55-f893-4f8d-a01d-a5ba962271dc@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> <29Al7cIKz22bCV-QFJPX9p7Nra4O9RtkODJZkADq-Jk=.d498ae55-f893-4f8d-a01d-a5ba962271dc@github.com> Message-ID: On Wed, 16 Nov 2022 14:02:01 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > 1) Removed the link for CSR. > 2) Add a new method in SystemProps.java to check if the warning message is required > 3) Print the warning message directly in System::initPhase3 Hello @weibxiao, I had a look at the linked JBS issue https://bugs.openjdk.org/browse/JDK-8290313. It appears to me that the original motivation of this change is to improve the situation where a call to `File.createTempFile(...)` can fail with the following excepiton: java.io.IOException: No such file or directory at java.io.UnixFileSystem.createFileExclusively(Native Method) at java.io.File.createTempFile(File.java:2001) at java.io.File.createTempFile(File.java:2047) if either the `java.io.tmpdir` doesn't exist or the user passed value for the `directory` parameter to `File.createTempDirectory(prefix, suffix, directory)` doesn't exist. I feel that the change being proposed here to print a warning if the user specified `java.io.tmpdir` won't improve this situation because: - This warning will get printed potentially (far) away and early in the logs as compared to where this exception might get logged. - The user may not even have access to the log file, and it just might be the case that the application code caught this exception and printed its stacktrace - This will continue to fail with the above exception (and without the proposed warning) if the user passed `directory` to the `File.createTempDirectory(prefix, suffix, directory)` is non-existent. For example (`/tmp/blah` directory doesn't exist in the example below): jshell> File.createTempFile("foo", null, new File("/tmp/blah")); | Exception java.io.IOException: No such file or directory | at UnixFileSystem.createFileExclusively0 (Native Method) | at UnixFileSystem.createFileExclusively (UnixFileSystem.java:356) | at File.createTempFile (File.java:2179) | at (#2:1) I think if we want to improve this error message then maybe attempt the solution proposed by Alan in the JBS issue: > Extend jdk.includeInExceptions to include "file", meaning opt-in in secure deployments to include the tmp directory in the exception. or maybe change the code in `File.createTempFile(...)` to something like: diff --git a/src/java.base/share/classes/java/io/File.java b/src/java.base/share/classes/java/io/File.java index 8f1e88219fe..4eb9db40e9d 100644 --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -2157,7 +2157,9 @@ public class File File tmpdir = (directory != null) ? directory : TempDirectory.location(); - + if (!tmpdir.isDirectory()) { + throw new IOException("Parent directory doesn't exist, cannot create a temporary file"); + } @SuppressWarnings("removal") SecurityManager sm = System.getSecurityManager(); File f; I haven't given much thought to the diff I proposed here, so this obviously will need more experimentation and inputs from others whether it's worth pursuing. Additionally, if we do decide to improve the exception being thrown, perhaps we should also review the code in `java.nio.file.Files.createTemp....` methods and the exceptions they throw. ------------- PR: https://git.openjdk.org/jdk/pull/11174 From alanb at openjdk.org Thu Nov 17 08:06:15 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 17 Nov 2022 08:06:15 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> <29Al7cIKz22bCV-QFJPX9p7Nra4O9RtkODJZkADq-Jk=.d498ae55-f893-4f8d-a01d-a5ba962271dc@github.com> Message-ID: On Thu, 17 Nov 2022 07:41:09 GMT, Jaikiran Pai wrote: > I think if we want to improve this error message then maybe attempt the solution proposed by Alan in the JBS issue: > > > Extend jdk.includeInExceptions to include "file", meaning opt-in in secure deployments to include the tmp directory in the exception. Yeah, I listed three suggestions in the JBS issue. This PR is item 2, which is to emit a warning a startup when the running with -Djava.io.tmpdir set to a bad directory. That is useful on its own and should help in some scenarios. Item 1 is the opt-in to improve the exception and I think that can be done too with another PR. ------------- PR: https://git.openjdk.org/jdk/pull/11174 From jai.forums2013 at gmail.com Thu Nov 17 08:34:47 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Thu, 17 Nov 2022 14:04:47 +0530 Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> <29Al7cIKz22bCV-QFJPX9p7Nra4O9RtkODJZkADq-Jk=.d498ae55-f893-4f8d-a01d-a5ba962271dc@github.com> Message-ID: <938f5dc1-8884-f7a6-976c-463fefca7685@gmail.com> On 17/11/22 1:36 pm, Alan Bateman wrote: > On Thu, 17 Nov 2022 07:41:09 GMT, Jaikiran Pai wrote: > >> I think if we want to improve this error message then maybe attempt the solution proposed by Alan in the JBS issue: >> >>> Extend jdk.includeInExceptions to include "file", meaning opt-in in secure deployments to include the tmp directory in the exception. > Yeah, I listed three suggestions in the JBS issue. This PR is item 2, which is to emit a warning a startup when the running with -Djava.io.tmpdir set to a bad directory. That is useful on its own and should help in some scenarios. Thank you Alan for that detail. I didn't realize this was an independent change being pursued. -Jaikiran From jpai at openjdk.org Thu Nov 17 09:09:00 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 17 Nov 2022 09:09:00 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations [v2] In-Reply-To: References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: On Thu, 17 Nov 2022 06:05:40 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? >> >> The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. >> >> `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: >> >> >> Objects.requireNonNull(action); >> while (hasNext()) >> action.accept(next()); >> >> Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. >> >> The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. >> >> New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review suggestion - simplify test tier1, tier2, tier3 and java_util tests in JCK have passed with this change. ------------- PR: https://git.openjdk.org/jdk/pull/11154 From alanb at openjdk.org Thu Nov 17 09:22:49 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 17 Nov 2022 09:22:49 GMT Subject: Integrated: 8296405: java/util/concurrent/forkjoin/AsyncShutdownNow.java is too slow In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:13:42 GMT, Alan Bateman wrote: > java/util/concurrent/forkjoin/AsyncShutdownNow.java takes ~40s as each test uses a delay of 5s before it invokes shutdownNow. The test will run in <1s if changed to poll the thread state and invoke shutdownNow when the thread waits. > > The update temporarily disables testInvokeAny because of a suspected issue doing shutdown at around the same that worker threads are spinning up. It duplicates more frequently (on Windows at least) with the updated test. JDK-8286352 and JDK-8288899 are two bugs on this issue. Doug Lea is looking into the issue. The test can be re-enabled when that issue is resolved. This pull request has now been integrated. Changeset: 636040f8 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/636040f8753e3610193e594605ff1adef5c049ed Stats: 108 lines in 1 file changed: 50 ins; 41 del; 17 mod 8296405: java/util/concurrent/forkjoin/AsyncShutdownNow.java is too slow Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/10986 From pminborg at openjdk.org Thu Nov 17 09:34:01 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 17 Nov 2022 09:34:01 GMT Subject: RFR: 8297148: Add a @sealedGraph tag to CallSite In-Reply-To: References: <8IJ8LRjjK2Tgwudor4KPiAhw-NmlLgXnZFtv6ctqn4w=.9e95d42d-4095-456f-8af5-0274f32eadd4@github.com> Message-ID: On Wed, 16 Nov 2022 16:41:18 GMT, Joe Darcy wrote: > Helpful improvement. > > Are the type names in the diagram links? The diagram is an SVG image rendered via the DOT description language. I think, in theory, it would be possible to add links. I did some experiments with this but decided we might add it later. ------------- PR: https://git.openjdk.org/jdk/pull/11190 From alanb at openjdk.org Thu Nov 17 10:17:34 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 17 Nov 2022 10:17:34 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:55:24 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Javadoc changes. > - ProblemList.txt cleanup src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java line 225: > 223: * > 224: * > 225: * The descendants of a task scope that are child task scopes that it is a parent There is a typo in the update (my fault). Suggestion: * The descendants of a task scope are the child task scopes that it is a parent ------------- PR: https://git.openjdk.org/jdk/pull/10952 From rgiulietti at openjdk.org Thu Nov 17 11:35:20 2022 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 17 Nov 2022 11:35:20 GMT Subject: RFR: 8296292: Document the default behavior of '$' in regular expressions correctly [v2] In-Reply-To: <9nlj-BBN31ZYZL3inJ4YcEz2hDxW1m-Xol_yee6taXw=.c2a0fe64-87de-4fe6-9059-1e8feb53499c@github.com> References: <9nlj-BBN31ZYZL3inJ4YcEz2hDxW1m-Xol_yee6taXw=.c2a0fe64-87de-4fe6-9059-1e8feb53499c@github.com> Message-ID: <5lt-bZuMXO1CfFlmkwF-h7_0zO29VGezjZonVx-OK5k=.e5e8b667-3e9c-44c7-acd1-ab8ec193f84b@github.com> On Wed, 9 Nov 2022 14:22:02 GMT, Raffaello Giulietti wrote: >> A small spec change to match established behavior. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8296292: Document the default behavior of '$' in regular expressions correctly This small change is nothing more than the content of the CSR, which has been approved a couple of days ago. No code changes are involved. A reviewer would only need to crosscheck that the change and the CSR match. Thanks in advance ------------- PR: https://git.openjdk.org/jdk/pull/11038 From lancea at openjdk.org Thu Nov 17 11:52:19 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 17 Nov 2022 11:52:19 GMT Subject: RFR: 8296292: Document the default behavior of '$' in regular expressions correctly [v2] In-Reply-To: <9nlj-BBN31ZYZL3inJ4YcEz2hDxW1m-Xol_yee6taXw=.c2a0fe64-87de-4fe6-9059-1e8feb53499c@github.com> References: <9nlj-BBN31ZYZL3inJ4YcEz2hDxW1m-Xol_yee6taXw=.c2a0fe64-87de-4fe6-9059-1e8feb53499c@github.com> Message-ID: On Wed, 9 Nov 2022 14:22:02 GMT, Raffaello Giulietti wrote: >> A small spec change to match established behavior. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > 8296292: Document the default behavior of '$' in regular expressions correctly Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11038 From coleenp at openjdk.org Thu Nov 17 11:59:21 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Nov 2022 11:59:21 GMT Subject: RFR: 8296492: Remove ObjectLocker in JVMTI get_subgroups call [v6] In-Reply-To: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> References: <2y4cu8hdnxpyMRtiBhBZ86E3JBBK4JUbH6oc_BI3XDY=.6be9e293-900a-4b7f-a1f3-607a257c8b2a@github.com> Message-ID: On Tue, 15 Nov 2022 18:52:37 GMT, Coleen Phillimore wrote: >> The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. >> Tested with tier 1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Review comments. Thanks for reviewing, Alan and David. ------------- PR: https://git.openjdk.org/jdk/pull/11033 From coleenp at openjdk.org Thu Nov 17 12:01:09 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 17 Nov 2022 12:01:09 GMT Subject: Integrated: 8296492: Remove ObjectLocker in JVMTI get_subgroups call In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 00:58:44 GMT, Coleen Phillimore wrote: > The JVM code took a ThreadGroup lock before poking into ThreadGroup fields. Call a method in the ThreadGroup to call the synchronized method instead. > Tested with tier 1-4. This pull request has now been integrated. Changeset: d8c809b1 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/d8c809b196e98bbf22849ec06c6ee337005670e8 Stats: 139 lines in 7 files changed: 39 ins; 83 del; 17 mod 8296492: Remove ObjectLocker in JVMTI get_subgroups call Reviewed-by: dholmes, alanb, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11033 From rgiulietti at openjdk.org Thu Nov 17 12:50:13 2022 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 17 Nov 2022 12:50:13 GMT Subject: Integrated: 8296292: Document the default behavior of '$' in regular expressions correctly In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 11:35:17 GMT, Raffaello Giulietti wrote: > A small spec change to match established behavior. This pull request has now been integrated. Changeset: 35acb891 Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/35acb891660fd5e0fee48b56acb16a6a193417ed Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod 8296292: Document the default behavior of '$' in regular expressions correctly Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/11038 From james.laskey at oracle.com Thu Nov 17 12:56:24 2022 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 17 Nov 2022 12:56:24 +0000 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: <06693be8-6ae0-34c1-8fb3-b02b472dc030@oracle.com> References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> <06693be8-6ae0-34c1-8fb3-b02b472dc030@oracle.com> Message-ID: <5984E564-B175-45D9-A4A2-9AB52AF8E610@oracle.com> Updating. > On Nov 16, 2022, at 5:41 PM, Alex Buckley wrote: > > The first line says StringTemplates, should say StringTemplate. > > The paragraph about the `process(ValidatingProcessor)` method is confusing -- it's not an alternative to using template expressions if the example needs to show a template expression before invoking `process`. I think you mean to say something about supporting deferred evaluation of a template expression, in conjunction with the RAW processor? > > The implNote: "Libraries may produce StringTemplate instances as long as they conform to the requirements of this interface." -- there's no need to say this if the requirements (e.g. for immutability) are spelled out in the normative specs (keep reading). > > The immutability of lists returned from `fragments()` and `values()` is mentioned both in the user-level spec ("Returns this StringTemplate's immutable list ...") and in the implementer-level spec ("The list returned is immutable."). That's a recipe for confusion. Better to drop the @implNote and commit to immutability as core to the method's result: > > --- > Returns a list of the fragment literals for this StringTemplate. > > The fragment literals are the character sequences preceding each of the embedded expressions in source code, plus the character sequence following the last embedded expression. Such character sequences may be zero-length if an embedded expression appears at the beginning or end of a template, or if two embedded expressions are directly adjacent in a template. > > The list is immutable. [I'm not sure why this is important, but OK.] > --- > > The spec of the `interpolate` method has a stray dot and an example which calls `interpolation()`. Please rename `string` to `result`. Say: @return A string denoting the interpolation of this `StringTemplate`'s fragments and values. > > Alex > > On 11/16/2022 12:06 PM, Jim Laskey wrote: >> CSR and available docs have been changed to reflect these changes. >> https://cr.openjdk.java.net/~jlaskey/templates/docs/api/java.base/java/lang/template/StringTemplate.html >> Cheers, >> ? Jim >>> On Nov 16, 2022, at 3:10 PM, Alex Buckley > wrote: >>> >>> Below, a revised description for `StringTemplate`. >>> >>> >>> // High-level opener. >>> >>> `StringTemplate` is the run-time representation of a string template or text block template in a template expression. >>> >>> [Sidebar. The JEP says "An instance of StringTemplate represents the string template or text block template that appears either as the template in a template expression, or as a standalone literal." -- the 'standalone literal' clause should be deleted.] >>> >>> // Basic concepts. No need to spell out details like immutability or return types here; leave them for the method specs. >>> >>> In the source code of a Java program, a string template or text block template contains an interleaved succession of _fragment literals_ and _embedded expressions_. The `fragments()` method returns the fragment literals, and the `values()` method returns the results of evaluating the embedded expressions. `StringTemplate` does not provide access to the source code of the embedded expressions themselves; it is not a compile-time representation of a string template or text block template. >>> >>> // Usage >>> >>> `StringTemplate` is primarily used in conjunction with a template processor to produce a string or other useful value. Evaluation of a template expression first produces an instance of `StringTemplate`, representing the template of the template expression, and then passes the instance to the template processor given by the template expression. >>> >>> For example, the following code contains a template expression that uses the template processor `RAW`, which simply yields the `StringTemplate` passed to it: >>> >>> int x = 10; >>> int y = 20; >>> StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; >>> List fragments = st.fragments(); >>> List values = st.values(); >>> >>> `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` will be the equivalent of `List.of(10, 20, 30)`. >>> >>> The following code contains a template expression with the same template but a different template processor: >>> >>> int x = 10; >>> int y = 20; >>> String s = STR."\{x} + \{y} = \{x + y}"; >>> >>> When the template expression is evaluated, an instance of `StringTemplate` is produced that returns the same lists from `fragments()` and `values()` as shown above. The `STR` template processor uses these lists to yield an interpolated string. `s` will be equivalent to `"10 + 20 = 30"`. >>> >>> The `interpolate()` method provides a direct way to perform string interpolation of a `StringTemplate`. Template processors can use the following code pattern: >>> >>> List fragments = st.fragments(); >>> List values = st.values(); >>> ... check or manipulate the fragments and/or values ... >>> String result = StringTemplate.interpolate(fragments, values); >>> >>> The `process(ValidatingProcessor)` method provides an alternative to using string template expressions. [Sidebar. The example line of code which follows, is using a template expression. I'm not sure what was meant here.] >>> >>> String result = RAW."\{x} + \{y} = \{x + y}".process(STR); >>> >>> The factory methods `of(String)` and `of(List, List)` can be used to construct a `StringTemplate`. >>> >>> @implNote: Implementations of `StringTemplate` must minimally implement the methods fragments() and values(). Instances of `StringTemplate` are considered immutable. To preserve the semantics of string templates and text block templates, the list returned by `fragments()` must be one element larger than the list returned by `values()`. >>> >>> @jls 15.8.6 >>> >>> >>> Alex >>> >>> On 11/16/2022 4:49 AM, Jim Laskey wrote: >>>> May I get a final (PR) review of JDK-8285932 Implementation of JEP-430 String Templates (Preview) from core-libs and compiler. >>>> PR: https://github.com/openjdk/jdk/pull/10889 > >>>> JBS: https://bugs.openjdk.org/browse/JDK-8285932 > >>>> CSR: https://bugs.openjdk.org/browse/JDK-8286021 > >>>> JEP: https://openjdk.org/jeps/430 > https://bugs.openjdk.org/browse/JDK-8273943 > >>>> SPEC: https://bugs.openjdk.org/browse/JDK-8296302 > >>>> Thank you. >>>> Cheers, >>>> ? Jim From james.laskey at oracle.com Thu Nov 17 12:57:17 2022 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 17 Nov 2022 12:57:17 +0000 Subject: RFR of JDK-8285932 Implementation of JEP-430 String Templates (Preview) In-Reply-To: References: <2C598668-1439-4BCE-9DC6-793E320355C6@oracle.com> <9697e318-0c28-e818-1e0b-1c91445c51cd@oracle.com> Message-ID: <2670B559-05D1-49B5-AAA0-166CE7A4190C@oracle.com> I corrected before inserting. On Nov 16, 2022, at 7:41 PM, John Rose > wrote: On 16 Nov 2022, at 11:10, Alex Buckley wrote: ? For example, the following code contains a template expression that uses the template processor `RAW`, which simply yields the `StringTemplate` passed to it: int x = 10; int y = 20; StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; List fragments = st.fragments(); List values = st.values(); `fragments` will be equivalent to `List.of(" + ", " = ")` and `values` will be the equivalent of `List.of(10, 20, 30)`. ? To preserve the semantics of string templates and text block templates, the list returned by `fragments()` must be one element larger than the list returned by `values()`. And yet, in the example given above, the list of fragments List.of(" + ", " = ") is one element smaller than the list of values List.of(10, 20, 30). The example is wrong. It?s worth a note in the doc that if an interpolated expression begins and/or ends the template, there will be a zero length fragment at the beginning or end of the fragments list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlaskey at openjdk.org Thu Nov 17 13:13:52 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 13:13:52 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 19:04:04 GMT, Jan Lahoda wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 1487: > >> 1485: if (typeArgs != null) return illegal(); >> 1486: t = stringTemplate(t); >> 1487: typeArgs = null; > > `typeArgs = null;` is unnecessary here, correct? Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 13:16:58 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 13:16:58 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 19:40:35 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/util/FormatProcessor.java line 102: > >> 100: * specifier that is incompatible with the given arguments, >> 101: * insufficient arguments given the format string, or other >> 102: * illegal conditions. For specification of all possible > > This fragment "For specification of all possible formatting errors." > seems to be incomplete or unnecessary. Changing. > src/java.base/share/classes/java/util/FormatProcessor.java line 154: > >> 152: >> 153: /** >> 154: * Convert a {@link StringTemplate} fragments, containing format specifications, > > Extraneous "a". Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 13:20:08 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 13:20:08 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 20:12:16 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 51: > >> 49: * >> 50: * @param lengthCoder current value of the length + coder >> 51: * @param buffer buffer to right into > > right -> write Guilty, Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 13:40:48 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 13:40:48 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 20:34:30 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 58: > >> 56: * optimized {@link StringTemplate StringTemplates} based on StringTemplateImpl. >> 57: *

      >> 58: * Bootstraps in the for of (Lookup, String, MethodType, MethodHandle, String...) > > "in the for" -> "in the form" Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 13:43:51 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 13:43:51 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <2Rf45bOhZrlM54_zIUPiwSOmQnDHZ631bQv5bmobpLs=.8647917f-ab40-4352-b5ea-0f3690f0108b@github.com> On Tue, 15 Nov 2022 20:37:25 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 116: > >> 114: */ >> 115: public static CallSite stringTemplateBSM( >> 116: MethodHandles.Lookup lookup, > > The predominate style for method declarations puts the first argument on the same line as the method name > and the closing ")" on the same line with the last argument and exceptions. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 14:33:53 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 14:33:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <3N4k5AKwRqG2zYSKEI0geox6jj311x7Sm06gYzTOkto=.269f6bb0-bef9-49ee-8904-1c2ba560b513@github.com> On Tue, 15 Nov 2022 22:12:05 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 291: > >> 289: >> 290: /** >> 291: * Interpolation template processor instance. > > Flesh out this description since it is automatically imported and will appear in user code, it should have a clear description. (Same for RAW, expand the description). Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 14:40:06 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 14:40:06 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 21:31:57 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/Carriers.java line 628: > >> 626: * types. >> 627: */ >> 628: private static class CarrierShape { > > Is this a candidate to be a Record? I think the balance between what is supplied and what is computed leans heavily toward a class. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 15:17:56 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 15:17:56 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <1P9c6UcuLG_33tRPFU-NxDhYmJ8kxLQqGPJGHA4Ipvk=.00e98f52-0fa1-4c98-9ec9-763c099fdc61@github.com> On Tue, 15 Nov 2022 22:02:53 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 189: > >> 187: >> 188: /** >> 189: * Produces a diagnostic string representing the supplied > > The description should include that it describe the fragments and values. Changing > src/java.base/share/classes/java/lang/template/StringTemplate.java line 208: > >> 206: >> 207: /** >> 208: * Returns a StringTemplate composed from a string. > > and no values. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 15:13:00 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 15:13:00 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 21:56:36 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 38: > >> 36: >> 37: /** >> 38: * The Java compiler produces implementations of {@link StringTemplate} to > > I'd rather see a first sentence that says what a StringTemplate is, not who produces it. > For example, a StringTemplate holds and controls the processing of the fragments and expressions of a string template. Cleaned up ValidatingProcessor, TemplateProcessor and StringProcessor. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 15:27:44 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 15:27:44 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 22:05:47 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 249: > >> 247: >> 248: /** >> 249: * Creates a string that interleaves the elements of values between the > > It might be worth noting that this is the same as STR::interpolate. I think you mean `STR.process` but that might be misleading. `interpolate(List fragments, List values)` is actually the fallback method invoked by `STR.process`. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 15:34:44 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 15:34:44 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 22:10:14 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 273: > >> 271: >> 272: /** >> 273: * Combine one or more {@link StringTemplate StringTemplates} to produce a combined {@link StringTemplate}. > > The description should be more specific about how the lists of fragments and values are combined. > For example, is each StringTemplate well formed and have the required string and value counts. > (Or when combined, is it only the case that the total number of strings and values meet the n+1/n requirement. > > > I'm not sure this API point pulls it weight in the API. I think this javadoc was updated since. What is happening here is non-trivial. The use cases are primarily composing documents from several parts. Ex. an SQL PreparedStatement. You don's want to convert to string before processing, so concatenation won't do. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 15:47:57 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 15:47:57 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <7lw_BsakseQkwCJO2F5exX1WEf6g_d11AkLAp0C40pE=.2c967025-4dcf-4e90-a07d-c18fd95874b8@github.com> On Tue, 15 Nov 2022 22:15:45 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplateImpl.java line 35: > >> 33: >> 34: /** >> 35: * This class implements specialized {@link StringTemplate StringTemplates} produced by > > A cross reference to the public api the compiler uses to create these would be useful. > So the reader can find the place to start reading. Links added. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 15:59:49 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 15:59:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 22:23:27 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1826: > >> 1824: >> 1825: // Used by StringConcatHelper via JLA. >> 1826: long mix(long lengthCoder) { > > `mix` is not a very descriptive name (in all of the places it is used). > Perhaps a name that captures the combination of coder and length. > > `coderAndLength()` or similar > > The implementation here can do the wrong thing if the `lengthCoder` already includes the bit for UTF16 > and the coder for the AbstractStringBuilder is LATIN1. Or is intentional that it will upgrade to UTF16? > That could definately use a comment. The goal here is to take the contents of a `StringBuilder/StringBuffer `without first converting to a string when referenced by `StringConcatFactory`. So the terminology is a carry over from `StringConcatFactory` and `StringConcatHelper`. I agree `mix` is weird but historically, it is what it is. Maybe a separate task to rename is in order. The implementation is deliberate. If something in the list of things being concatenated is UTF16, then everything being concatenated is upgraded to UTF16. I'll add commentary. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Thu Nov 17 16:20:29 2022 From: duke at openjdk.org (ExE Boss) Date: Thu, 17 Nov 2022 16:20:29 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v27] In-Reply-To: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> References: <-Lw-dDGfVAZlOT815DeyvfwP0NTWWbj4X0lrl9ek_iQ=.70a5ad19-062f-488d-97fb-f8d923c2dc17@github.com> Message-ID: On Tue, 15 Nov 2022 18:47:39 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix typo in SegmentScope javadoc src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 77: > 75: } catch (Throwable ex) { > 76: throw new ExceptionInInitializerError(ex); > 77: } The?above `catch`?clause should?only catch?`Exception`s, not?`Throwable`s, as?the?latter would?hide VM?errors such?as?`StackOverflowError` or?`OutOfMemoryError`. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From jlaskey at openjdk.org Thu Nov 17 16:24:11 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 16:24:11 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:22:54 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 187: > >> 185: @Override >> 186: public StringTemplate newStringTemplate(List fragments, List values) { >> 187: return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray())); > > `values.toArray()` returns a new array; no need to stream the list content. > Alt: `Arrays.asList(values.toArray())` This is to ensure type Object[]. Ex,. if the user passes in a List. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From psandoz at openjdk.org Thu Nov 17 16:55:26 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 17 Nov 2022 16:55:26 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:55:24 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Javadoc changes. > - ProblemList.txt cleanup src/hotspot/share/utilities/exceptions.cpp line 166: > 164: // Remove the ScopedValue cache in case we got a virtual machine > 165: // Error while we were trying to manipulate ScopedValue bindings. > 166: thread->set_scopedValueCache(NULL); I am see this pattern repeat quite often: thread->set_scopedValueCache(NULL); oop threadObj = thread->vthread(); assert(threadOop != NULL, "must be"); // <--- sometimes java_lang_Thread::clear_scopedValueBindings(threadObj); Encapsulate in a method on the `JavaThread` class? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From duke at openjdk.org Thu Nov 17 16:58:26 2022 From: duke at openjdk.org (Justin Lu) Date: Thu, 17 Nov 2022 16:58:26 GMT Subject: Integrated: 8287180: Update IANA Language Subtag Registry to Version 2022-08-08 In-Reply-To: References: Message-ID: On Mon, 3 Oct 2022 20:03:42 GMT, Justin Lu wrote: > Problem: IANA Language subtag registry is outdated > Fix: Updated from version 2022-03-02 to 2022-08-08 -> [IANA registry](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry) This pull request has now been integrated. Changeset: 992f209d Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/992f209deffac50635646b42ec4220bfbfc96d39 Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod 8287180: Update IANA Language Subtag Registry to Version 2022-08-08 Reviewed-by: naoto, lancea, iris ------------- PR: https://git.openjdk.org/jdk/pull/10546 From naoto at openjdk.org Thu Nov 17 17:02:24 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 17 Nov 2022 17:02:24 GMT Subject: Integrated: 8297152: Add a @sealedGraph tag to ZoneId In-Reply-To: References: Message-ID: <706-OJnqZOU9NYVdaORKjHwIAU6AediltFUrv-NuLHw=.6e6144e1-2535-441c-bbf1-b31768d97e9f@github.com> On Wed, 16 Nov 2022 19:07:48 GMT, Naoto Sato wrote: > Adding a `@sealedGraph` tag to `ZoneId` class. This pull request has now been integrated. Changeset: 8b140e2d Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/8b140e2d747676f6c5f53ccb18cee307e7d3da1c Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8297152: Add a @sealedGraph tag to ZoneId Reviewed-by: iris, joehw ------------- PR: https://git.openjdk.org/jdk/pull/11195 From jlaskey at openjdk.org Thu Nov 17 17:09:52 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 17:09:52 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 21:19:21 GMT, Tagir F. Valeev wrote: >> src/java.base/share/classes/java/lang/template/StringTemplateImplFactory.java line 202: >> >>> 200: @SuppressWarnings({"unchecked", "varargs"}) >>> 201: private static List toList(E... elements) { >>> 202: return Collections.unmodifiableList(Arrays.asList(elements)); >> >> Is a defensive copy needed here? >> The caller of `newStringTemplate` could retain a reference to the Object[] array and modify it later. > > Alternatively, `SharedSecrets.getJavaUtilCollectionAccess().listFromTrustedArrayNullsAllowed(elements)` (or `elements.clone()`) could be used here, to reduce amount of wrappers. The `newStringTemplate` methods are internal and elements is safe. Will get rid of the generics and varargs. @amaembo I was using listFromTrustedArrayNullsAllowed early on but ran into an edge case (crash). Will try again. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Thu Nov 17 17:10:40 2022 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 17 Nov 2022 17:10:40 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v4] In-Reply-To: References: Message-ID: <_xWGOFPmZhaoTCxTS_g3kAE_V7FQROtDgDQy2OuPVdM=.5e32364b-6ac3-4b64-b60a-4d9fbb4a6c99@github.com> On Fri, 14 Oct 2022 19:25:54 GMT, Weibing Xiao wrote: >> 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist > > Weibing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into improve-directory-not-existing-error-message > - new approach: print warning in StaticProperty.java > - Merge branch 'master' into improve-directory-not-existing-error-message > - add the change for nio and update the code according to the comments > - new approach > - change based on the review > - updating according to the comments > - Merge branch 'master' of https://github.com/openjdk/jdk into improve-directory-not-existing-error-message > - update error message > - error message for non-existing directory > - ... and 1 more: https://git.openjdk.org/jdk/compare/8487c56f...2da71bdc Close this one, Using https://github.com/openjdk/jdk/pull/11174 instead ------------- PR: https://git.openjdk.org/jdk/pull/9989 From duke at openjdk.org Thu Nov 17 17:10:40 2022 From: duke at openjdk.org (Weibing Xiao) Date: Thu, 17 Nov 2022 17:10:40 GMT Subject: Withdrawn: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: References: Message-ID: On Tue, 23 Aug 2022 18:32:30 GMT, Weibing Xiao wrote: > 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9989 From jlaskey at openjdk.org Thu Nov 17 17:15:53 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 17:15:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v23] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 21:43:32 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Requested changes #8 >> - Update StringTemplate javadoc > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 34: > >> 32: >> 33: /** >> 34: * {@link StringTemplate StringTemplates} is the run-time representation of a > > Suggestion: > > * {@link StringTemplate StringTemplate} is the run-time representation of a Stale. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 218: > >> 216: >> 217: /** >> 218: * Returns a StringTemplate as if constructed by invoking > > Suggestion: > > * Returns a {@code StringTemplate} as if constructed by invoking Stale > src/java.base/share/classes/java/lang/template/StringTemplate.java line 233: > >> 231: >> 232: /** >> 233: * Returns a StringTemplate with the given fragments and values. > > Suggestion: > > * Returns a {@code StringTemplate} with the given fragments and values. Stale. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 17:31:09 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 17:31:09 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v24] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/2edc7925..89f9ac02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=22-23 Stats: 170 lines in 10 files changed: 66 ins; 28 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Thu Nov 17 17:31:11 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 17 Nov 2022 17:31:11 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 21:47:40 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Wrong line separator > > src/java.base/share/classes/java/lang/template/StringProcessor.java line 31: > >> 29: >> 30: /** >> 31: * This interface simplifies declaration of > > The first sentence should describe the purpose or function of the interface. > The "simplify declaration" language is a design rationale, not a functional description of the interface. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From aph at openjdk.org Thu Nov 17 19:00:29 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 17 Nov 2022 19:00:29 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: References: Message-ID: <3wlfTnsbrVrppFImhVNfweUmw7nm9L2az9SOlqiNCAk=.c3478ce5-b4ab-46ba-a0e9-c7667d9cf5b2@github.com> On Thu, 17 Nov 2022 16:53:13 GMT, Paul Sandoz wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - Javadoc changes. >> - ProblemList.txt cleanup > > src/hotspot/share/utilities/exceptions.cpp line 166: > >> 164: // Remove the ScopedValue cache in case we got a virtual machine >> 165: // Error while we were trying to manipulate ScopedValue bindings. >> 166: thread->set_scopedValueCache(NULL); > > I am see this pattern repeat quite often: > > thread->set_scopedValueCache(NULL); > oop threadObj = thread->vthread(); > assert(threadOop != NULL, "must be"); // <--- sometimes > java_lang_Thread::clear_scopedValueBindings(threadObj); > > Encapsulate in a method on the `JavaThread` class? That sounds good. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From bchristi at openjdk.org Thu Nov 17 19:32:06 2022 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 17 Nov 2022 19:32:06 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) Message-ID: [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. ------------- Commit messages: - Merge branch 'master' into 8295857 - update halt() @apiNote - update doc changes - Update doc for Runtime class and halt() method Changes: https://git.openjdk.org/jdk/pull/11218/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295857 Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11218/head:pull/11218 PR: https://git.openjdk.org/jdk/pull/11218 From bpb at openjdk.org Thu Nov 17 19:43:21 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 17 Nov 2022 19:43:21 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) In-Reply-To: References: Message-ID: <5gOfJMU2uqWZMa7o-21KnFGI7t1Jv15d7NW0cqs6X_U=.0b1fa1be-61e8-4ae9-beee-e5a1f7a4ca3f@github.com> On Thu, 17 Nov 2022 19:25:42 GMT, Brent Christian wrote: > [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". > > One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. src/java.base/share/classes/java/lang/Runtime.java line 95: > 93: * threads' current methods do not complete normally or abruptly. > 94: * {@linkplain Thread.UncaughtExceptionHandler Uncaught exception handlers} are not run, > 95: * no {@code finally} clause of any method is executed, and try-with-resource `try-with-resource` or `try-with-resources`? src/java.base/share/classes/java/lang/Runtime.java line 283: > 281: * any cleanup actions intended to be performed by shutdown hooks, > 282: * {@linkplain Thread.UncaughtExceptionHandler uncaught exception handlers}, > 283: * finally blocks, or try-with-resource blocks. This can lead to data corruption. Same comment as above. ------------- PR: https://git.openjdk.org/jdk/pull/11218 From lancea at openjdk.org Thu Nov 17 20:14:03 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 17 Nov 2022 20:14:03 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 19:25:42 GMT, Brent Christian wrote: > [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". > > One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. Changes requested by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11218 From lancea at openjdk.org Thu Nov 17 20:14:06 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 17 Nov 2022 20:14:06 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) In-Reply-To: <5gOfJMU2uqWZMa7o-21KnFGI7t1Jv15d7NW0cqs6X_U=.0b1fa1be-61e8-4ae9-beee-e5a1f7a4ca3f@github.com> References: <5gOfJMU2uqWZMa7o-21KnFGI7t1Jv15d7NW0cqs6X_U=.0b1fa1be-61e8-4ae9-beee-e5a1f7a4ca3f@github.com> Message-ID: On Thu, 17 Nov 2022 19:39:09 GMT, Brian Burkhalter wrote: > `try-with-resource` or `try-with-resources`? Agree should be [try-with-resources](https://docs.oracle.com/javase/8/docs/technotes/guides/language/try-with-resources.html) ------------- PR: https://git.openjdk.org/jdk/pull/11218 From duke at openjdk.org Thu Nov 17 20:18:24 2022 From: duke at openjdk.org (Marcono1234) Date: Thu, 17 Nov 2022 20:18:24 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations [v2] In-Reply-To: References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: <6oYlDK3ngrhAusJ9glnivF4gu3OTZCjFvIXHyIzgT9Y=.cdecd4ee-5d57-422d-85b3-acab076c2b5f@github.com> On Thu, 17 Nov 2022 06:05:40 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? >> >> The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. >> >> `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: >> >> >> Objects.requireNonNull(action); >> while (hasNext()) >> action.accept(next()); >> >> Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. >> >> The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. >> >> New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review suggestion - simplify test src/java.base/share/classes/java/util/Collections.java line 1718: > 1716: public void forEachRemaining(Consumer> action) { > 1717: Objects.requireNonNull(action); > 1718: i.forEachRemaining(entryConsumer(action)); As pointed out in the bug report description, it might be better to add the `null` check to `entryConsumer`. That would avoid code duplication for the `null` checks for all the current callers of `entryConsumer`. (This comment only applies here; for `CheckedEntrySet` below this does not work because it does not call `entryConsumer`.) ------------- PR: https://git.openjdk.org/jdk/pull/11154 From bchristi at openjdk.org Thu Nov 17 20:29:22 2022 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 17 Nov 2022 20:29:22 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) In-Reply-To: References: <5gOfJMU2uqWZMa7o-21KnFGI7t1Jv15d7NW0cqs6X_U=.0b1fa1be-61e8-4ae9-beee-e5a1f7a4ca3f@github.com> Message-ID: On Thu, 17 Nov 2022 20:08:27 GMT, Lance Andersen wrote: >> src/java.base/share/classes/java/lang/Runtime.java line 95: >> >>> 93: * threads' current methods do not complete normally or abruptly. >>> 94: * {@linkplain Thread.UncaughtExceptionHandler Uncaught exception handlers} are not run, >>> 95: * no {@code finally} clause of any method is executed, and try-with-resource >> >> `try-with-resource` or `try-with-resources`? > >> `try-with-resource` or `try-with-resources`? > > Agree should be [try-with-resources](https://docs.oracle.com/javase/8/docs/technotes/guides/language/try-with-resources.html) Yep ------------- PR: https://git.openjdk.org/jdk/pull/11218 From bchristi at openjdk.org Thu Nov 17 20:32:15 2022 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 17 Nov 2022 20:32:15 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v2] In-Reply-To: References: Message-ID: > [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". > > One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: It's "try-with-resources" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11218/files - new: https://git.openjdk.org/jdk/pull/11218/files/de091d83..9983fa68 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11218/head:pull/11218 PR: https://git.openjdk.org/jdk/pull/11218 From psandoz at openjdk.org Thu Nov 17 20:33:36 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 17 Nov 2022 20:33:36 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:55:24 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Javadoc changes. > - ProblemList.txt cleanup src/java.base/share/classes/java/lang/Thread.java line 744: > 742: > 743: // special value to mean a new thread > 744: this.scopedValueBindings = Thread.class; Perhaps: static final Object NEW_THREAD_BINDINGS = Thread.class; ... this.scopedValueBindings = NEW_THREAD_BINDINGS; ? src/java.base/share/classes/java/lang/Thread.java line 1614: > 1612: } > 1613: > 1614: @Hidden Should we document that the name and signature are special (same of other relevant methods not already documented). src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 49: > 47: * > 48: *

      {@code ScopedValue} defines the {@link #where(ScopedValue, Object, Runnable)} > 49: * method to set the value of a {@code ScopedValue} for the bouned period of execution by Suggestion: * method to set the value of a {@code ScopedValue} for the bounded period of execution by src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 241: > 239: } > 240: > 241: static final class EmptySnapshot extends Snapshot { We could make `Snapshot` final have a static final field? static final Snapshot EMPTY_SNAPSHOT = new Snapshot(); src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 391: > 389: * JVM_FindScopedValueBindings(). > 390: */ > 391: private R runWith(Snapshot newSnapshot, Callable op) throws Exception { Missing `@Hidden` and `@ForceInline` ? like with the other `runWith` method accepting `Runnable`? (I was gonna suggest changing the name to `callWith`, but then reread the docs and VM code. Its convenient to have the same names.) src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 672: > 670: return EmptySnapshot.getInstance(); > 671: } > 672: if (bindings == null) { Suggestion: if (bindings == NEW_THREAD_BINDINGS) { // This must be a new thread return Snapshot.EMPTY_SNAPSHOT; } else if (bindings == null) { src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 720: > 718: // is invoked, we record the result of the lookup in this per-thread cache > 719: // for fast access in future. > 720: private static class Cache { Make the class final and remove the qualifier on all the methods. src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 824: > 822: } > 823: > 824: public static void invalidate() { Is this method used? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From bpb at openjdk.org Thu Nov 17 20:40:33 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 17 Nov 2022 20:40:33 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v2] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 20:32:15 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > It's "try-with-resources" Looks good now. Is a CSR needed here? ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11218 From lancea at openjdk.org Thu Nov 17 20:40:33 2022 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 17 Nov 2022 20:40:33 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v2] In-Reply-To: References: Message-ID: <9bouydzPk59-FE6k1FuTqLSPuFFW-iaJjQMpE5Dct0Q=.316935a8-9368-4d02-8be5-bbbb90f52016@github.com> On Thu, 17 Nov 2022 20:32:15 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > It's "try-with-resources" Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11218 From darcy at openjdk.org Thu Nov 17 21:55:44 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 17 Nov 2022 21:55:44 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview Message-ID: Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. ------------- Commit messages: - JDK-8297215: Update libs tests to use @enablePreview Changes: https://git.openjdk.org/jdk/pull/11222/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297215 Stats: 122 lines in 36 files changed: 33 ins; 1 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/11222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222 PR: https://git.openjdk.org/jdk/pull/11222 From bchristi at openjdk.org Thu Nov 17 22:09:20 2022 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 17 Nov 2022 22:09:20 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v2] In-Reply-To: References: Message-ID: <6utZydB6hfiuojfSKaYtu9CiU7P-cuQL1AO3gcoJfR8=.5cf11294-cee3-4b9e-abd1-14d011f9e308@github.com> On Thu, 17 Nov 2022 20:36:01 GMT, Brian Burkhalter wrote: > Is a CSR needed here? I will check, though the thought is that these are non-normative clarifications to the normative changes made by [8290036](https://bugs.openjdk.org/browse/JDK-8290036). ------------- PR: https://git.openjdk.org/jdk/pull/11218 From jjg at openjdk.org Thu Nov 17 22:31:43 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 17 Nov 2022 22:31:43 GMT Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java Message-ID: Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2 (See https://bugs.openjdk.org/browse/JDK-8297165) In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc. ------------- Commit messages: - JDK-8297164: Update troff man pages and CheckManPageOptions.java Changes: https://git.openjdk.org/jdk/pull/11223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297164 Stats: 8944 lines in 29 files changed: 471 ins; 1589 del; 6884 mod Patch: https://git.openjdk.org/jdk/pull/11223.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223 PR: https://git.openjdk.org/jdk/pull/11223 From rriggs at openjdk.org Thu Nov 17 22:36:52 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 17 Nov 2022 22:36:52 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v23] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:33:50 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Requested changes #8 > - Update StringTemplate javadoc src/java.base/share/classes/java/lang/template/StringTemplate.java line 87: > 85: * alternative to using string template expressions. > 86: * {@snippet : > 87: * StringTemplate st = RAW."\{x} + \{y} = \{x + y}"; RAW and STR are used in similar ways in the examples but RAW produces a compilation error. Somewhere obvious there should be an API note that RAW needs an explicit import static whereas STR is imported automatically. src/java.base/share/classes/java/lang/template/StringTemplate.java line 120: > 118: * String student = "Mary"; > 119: * String teacher = "Johnson"; > 120: * StringTemplate st = RAW."The student \{student} is in \{teacher}'s class room."; typo? "class room" -> "classroom" or just "class" Also below. src/java.base/share/classes/java/lang/template/StringTemplate.java line 176: > 174: * String result2 = RAW."The student \{student} is in \{teacher}'s class room.".process(STR); // @highlight substring="process" > 175: * } > 176: * produces an equivalent result for both {@code result1} and {@code result2}. Capitalize this sentence. "Produces"... src/java.base/share/classes/java/lang/template/StringTemplate.java line 188: > 186: * @throws NullPointerException if processor is null > 187: * > 188: * @implNote The default implementation invokes the processor's process too many processes... Perhaps: ... `invokes the {@code processor.process(this)} method.` src/java.base/share/classes/java/lang/template/StringTemplate.java line 298: > 296: * > 297: * @throws NullPointerException if sts is null or if any of the elements are null > 298: * @throws RuntimeException if sts has zero elements The RuntimeException may be a leftover; TemplateSupport.combine(sts) allows there to be zero elements. (And RuntimeException is too general for the described case, perhaps IllegalArgumentException) ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jpai at openjdk.org Fri Nov 18 01:11:21 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 18 Nov 2022 01:11:21 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations [v2] In-Reply-To: <6oYlDK3ngrhAusJ9glnivF4gu3OTZCjFvIXHyIzgT9Y=.cdecd4ee-5d57-422d-85b3-acab076c2b5f@github.com> References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> <6oYlDK3ngrhAusJ9glnivF4gu3OTZCjFvIXHyIzgT9Y=.cdecd4ee-5d57-422d-85b3-acab076c2b5f@github.com> Message-ID: On Thu, 17 Nov 2022 20:15:55 GMT, Marcono1234 wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> review suggestion - simplify test > > src/java.base/share/classes/java/util/Collections.java line 1718: > >> 1716: public void forEachRemaining(Consumer> action) { >> 1717: Objects.requireNonNull(action); >> 1718: i.forEachRemaining(entryConsumer(action)); > > As pointed out in the bug report description, it might be better to add the `null` check to `entryConsumer`. That would avoid code duplication for the `null` checks for all the current callers of `entryConsumer`. > > (This comment only applies here; for `CheckedEntrySet` below this does not work because it does not call `entryConsumer`.) Hello @Marcono1234, I prefer doing it earliest in the top level method (which specifies the contract) instead of doing it in an internal method that this method calls. ------------- PR: https://git.openjdk.org/jdk/pull/11154 From dholmes at openjdk.org Fri Nov 18 02:35:11 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 18 Nov 2022 02:35:11 GMT Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote: > Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc. Hi @jonathan-gibbons , I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly? ------------- PR: https://git.openjdk.org/jdk/pull/11223 From darcy at openjdk.org Fri Nov 18 03:34:42 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 03:34:42 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes Message-ID: Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 ------------- Commit messages: - JDK-8296743: Tighten Class.getModifiers spec for array classes Changes: https://git.openjdk.org/jdk/pull/11229/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11229&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296743 Stats: 152 lines in 2 files changed: 141 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11229.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11229/head:pull/11229 PR: https://git.openjdk.org/jdk/pull/11229 From jpai at openjdk.org Fri Nov 18 06:52:47 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 18 Nov 2022 06:52:47 GMT Subject: RFR: 8297129: Inflater documentation refers to 'deflate' methods Message-ID: Can I please get a review for this doc only change which fixes the javadoc of java.util.zip.Inflater class? As noted in https://bugs.openjdk.org/browse/JDK-8297129, there's a typo in the javadoc. This commit fixes that. ------------- Commit messages: - 8297129: Inflater documentation refers to 'deflate' methods Changes: https://git.openjdk.org/jdk/pull/11232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297129 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11232.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11232/head:pull/11232 PR: https://git.openjdk.org/jdk/pull/11232 From alanb at openjdk.org Fri Nov 18 08:31:50 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 08:31:50 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 21:48:11 GMT, Joe Darcy wrote: > Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. test/jdk/java/lang/Thread/BuilderTest.java line 29: > 27: * @enablePreview > 28: * @compile BuilderTest.java > 29: * @run testng/othervm BuilderTest I assume `@compile` can be dropped from both of these tests now. Also I think /othervm can be dropped too because jtreg will always use othervm for tests that require --enable-preview. When the feature becomes permanent then it would mean dropping the `@enablePreview` tag, no other changes. test/jdk/java/lang/Thread/virtual/JfrEvents.java line 31: > 29: * @enablePreview > 30: * @compile JfrEvents.java > 31: * @run testng/othervm JfrEvents This one needs to be /othervm. ------------- PR: https://git.openjdk.org/jdk/pull/11222 From alanb at openjdk.org Fri Nov 18 08:37:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 08:37:21 GMT Subject: RFR: 8297129: Inflater documentation refers to 'deflate' methods In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 06:44:03 GMT, Jaikiran Pai wrote: > Can I please get a review for this doc only change which fixes the javadoc of java.util.zip.Inflater class? As noted in https://bugs.openjdk.org/browse/JDK-8297129, there's a typo in the javadoc. This commit fixes that. src/java.base/share/classes/java/util/zip/Inflater.java line 49: > 47: * sequence is provided in either byte array or byte buffer, via one of the > 48: * {@code setInput()} methods. The output byte sequence is written to the > 49: * output byte array or byte buffer passed to the {@code inflate()} methods. This looks okay but probably should be a link as it's first use of inflate. ------------- PR: https://git.openjdk.org/jdk/pull/11232 From jpai at openjdk.org Fri Nov 18 08:41:31 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 18 Nov 2022 08:41:31 GMT Subject: RFR: 8297129: Inflater documentation refers to 'deflate' methods In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 08:33:40 GMT, Alan Bateman wrote: >> Can I please get a review for this doc only change which fixes the javadoc of java.util.zip.Inflater class? As noted in https://bugs.openjdk.org/browse/JDK-8297129, there's a typo in the javadoc. This commit fixes that. > > src/java.base/share/classes/java/util/zip/Inflater.java line 49: > >> 47: * sequence is provided in either byte array or byte buffer, via one of the >> 48: * {@code setInput()} methods. The output byte sequence is written to the >> 49: * output byte array or byte buffer passed to the {@code inflate()} methods. > > This looks okay but probably should be a link as it's first use of inflate. I had thought about it too, but I realized that it talks of inflate "methods" (there are more than one inflate methods with different parameters). So I suspect it was intentional to use `{@code}` instead of `{@link}`. ------------- PR: https://git.openjdk.org/jdk/pull/11232 From alanb at openjdk.org Fri Nov 18 08:46:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 08:46:04 GMT Subject: RFR: 8297129: Inflater documentation refers to 'deflate' methods In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 06:44:03 GMT, Jaikiran Pai wrote: > Can I please get a review for this doc only change which fixes the javadoc of java.util.zip.Inflater class? As noted in https://bugs.openjdk.org/browse/JDK-8297129, there's a typo in the javadoc. This commit fixes that. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11232 From alanb at openjdk.org Fri Nov 18 08:46:06 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 08:46:06 GMT Subject: RFR: 8297129: Inflater documentation refers to 'deflate' methods In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 08:39:05 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/Inflater.java line 49: >> >>> 47: * sequence is provided in either byte array or byte buffer, via one of the >>> 48: * {@code setInput()} methods. The output byte sequence is written to the >>> 49: * output byte array or byte buffer passed to the {@code inflate()} methods. >> >> This looks okay but probably should be a link as it's first use of inflate. > > I had thought about it too, but I realized that it talks of inflate "methods" (there are more than one inflate methods with different parameters). So I suspect it was intentional to use `{@code}` instead of `{@link}`. Okay, we can leave it as a code tag. At some point I suspect the class description of both Inflater and Deflater will need to be replaced as they are missing so much. ------------- PR: https://git.openjdk.org/jdk/pull/11232 From mbaesken at openjdk.org Fri Nov 18 09:28:18 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 18 Nov 2022 09:28:18 GMT Subject: RFR: JDK-8296945: PublicMethodsTest is slow due to dependency verification with debug builds Message-ID: As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch off VerifyDependencies in this test because of slow machines when (fast)debug builds are used, the test sometimes times out after the [JDK-8266074](https://bugs.openjdk.org/browse/JDK-8266074) Vtable-based CHA implementation implementation came in. Same has been done for other tests with similar issues, see 8268227: java/foreign/TestUpcall.java still times out . ------------- Commit messages: - JDK-8296945 Changes: https://git.openjdk.org/jdk/pull/11234/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11234&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296945 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11234.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11234/head:pull/11234 PR: https://git.openjdk.org/jdk/pull/11234 From asotona at openjdk.org Fri Nov 18 11:43:56 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 18 Nov 2022 11:43:56 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error [v2] In-Reply-To: References: Message-ID: > Option --disable- at files is not recognised as valid JVM option, however it is already implemented in the launcher. > Proposed patch skips --disable- at files option in src/hotspot/share/runtime/arguments.cpp processing, so it does not fall into the category of unknown options. > The patch also corrects typo in the launcher.properties and adds simple DisableFilesOptionTest. > > Please review. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: handling of --disable- at files moved from runtime/arguments.cpp to libjli/java.c ParseArguments DisableFilesOptionTest merged to ArgsFileTest::killSwitch help typo moved to a new bug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11183/files - new: https://git.openjdk.org/jdk/pull/11183/files/ab754b8d..acddbffb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11183&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11183&range=00-01 Stats: 58 lines in 15 files changed: 6 ins; 40 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11183.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11183/head:pull/11183 PR: https://git.openjdk.org/jdk/pull/11183 From asotona at openjdk.org Fri Nov 18 11:48:16 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 18 Nov 2022 11:48:16 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 01:26:51 GMT, David Holmes wrote: >> Option --disable- at files is not recognised as valid JVM option, however it is already implemented in the launcher. >> Proposed patch skips --disable- at files option in src/hotspot/share/runtime/arguments.cpp processing, so it does not fall into the category of unknown options. >> The patch also corrects typo in the launcher.properties and adds simple DisableFilesOptionTest. >> >> Please review. >> >> Thank you, >> Adam > > BTW for future reference for the test case we are no longer creating tests using the bug id as a directory, instead tests should be grouped into functional areas. Thanks. > > I was also surprised to see the i8N changes here as I thought that was normally handled seperately. @dholmes-ora and @AlanBateman thanks for pointing me to the right place for the fix. tools/launcher/ArgsFileTest.java was working because it didn't contain any test with --disable- at files option verifying VM really starts ------------- PR: https://git.openjdk.org/jdk/pull/11183 From lancea at openjdk.org Fri Nov 18 12:01:28 2022 From: lancea at openjdk.org (Lance Andersen) Date: Fri, 18 Nov 2022 12:01:28 GMT Subject: RFR: 8297129: Inflater documentation refers to 'deflate' methods In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 06:44:03 GMT, Jaikiran Pai wrote: > Can I please get a review for this doc only change which fixes the javadoc of java.util.zip.Inflater class? As noted in https://bugs.openjdk.org/browse/JDK-8297129, there's a typo in the javadoc. This commit fixes that. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11232 From jpai at openjdk.org Fri Nov 18 12:04:16 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 18 Nov 2022 12:04:16 GMT Subject: RFR: 8297129: Inflater documentation refers to 'deflate' methods In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 06:44:03 GMT, Jaikiran Pai wrote: > Can I please get a review for this doc only change which fixes the javadoc of java.util.zip.Inflater class? As noted in https://bugs.openjdk.org/browse/JDK-8297129, there's a typo in the javadoc. This commit fixes that. Thank you Alan and Lance for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/11232 From asotona at openjdk.org Fri Nov 18 12:05:15 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 18 Nov 2022 12:05:15 GMT Subject: RFR: 8297258: Typo in `java -help` referencing -disable-@files instead of --disable-@files Message-ID: There is a typo in `java -help` referencing -disable- at files instead of --disable- at files option. Please review. Thanks, Adam ------------- Commit messages: - 8297258: Typo in `java -help` referencing -disable- at files instead of --disable- at files Changes: https://git.openjdk.org/jdk/pull/11236/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11236&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297258 Stats: 11 lines in 11 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11236.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11236/head:pull/11236 PR: https://git.openjdk.org/jdk/pull/11236 From jpai at openjdk.org Fri Nov 18 12:08:17 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 18 Nov 2022 12:08:17 GMT Subject: Integrated: 8297129: Inflater documentation refers to 'deflate' methods In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 06:44:03 GMT, Jaikiran Pai wrote: > Can I please get a review for this doc only change which fixes the javadoc of java.util.zip.Inflater class? As noted in https://bugs.openjdk.org/browse/JDK-8297129, there's a typo in the javadoc. This commit fixes that. This pull request has now been integrated. Changeset: 2f2d4046 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/2f2d40465b3c31d95ba607ec053f5697aa22b66e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8297129: Inflater documentation refers to 'deflate' methods Reviewed-by: alanb, lancea ------------- PR: https://git.openjdk.org/jdk/pull/11232 From jlaskey at openjdk.org Fri Nov 18 13:19:04 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 18 Nov 2022 13:19:04 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v23] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 15:46:14 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Requested changes #8 >> - Update StringTemplate javadoc > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 188: > >> 186: * @throws NullPointerException if processor is null >> 187: * >> 188: * @implNote The default implementation invokes the processor's process > > too many processes... > Perhaps: > > ... `invokes the {@code processor.process(this)} method.` Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Nov 18 13:19:07 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 18 Nov 2022 13:19:07 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 22:43:40 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/FormatItem.java line 75: >> >>> 73: try { >>> 74: return (long)CHAR_MIX.invokeExact(lengthCoder, value); >>> 75: } catch (RuntimeException ex) { >> >> This?should also?rethrow `Error`?instances: >> Suggestion: >> >> } catch (Error | RuntimeException ex) { > > Changing Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Nov 18 13:19:10 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 18 Nov 2022 13:19:10 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v13] In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 22:44:38 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/FormatProcessor.java line 38: >> >>> 36: >>> 37: /** >>> 38: * This {@linkplain ValidatingProcessor yemplate processor} constructs a String >> >> Typo: "yemplate processor". > > Changing Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Nov 18 13:27:53 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 18 Nov 2022 13:27:53 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:31:28 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/FormatProcessor.java line 39: >> >>> 37: /** >>> 38: * This {@linkplain ValidatingProcessor template processor} constructs a String >>> 39: * result using {@link Formatter}. Unlike {@link Formatter}, FormatProcessor uses the value from >> >> And `FormatProcessor` too > > Changing. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Nov 18 13:37:50 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 18 Nov 2022 13:37:50 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v21] In-Reply-To: References: Message-ID: <64AZLdWKu5YREx2-YJMax9nl66Uo5ONl__B49aWa1TM=.df4d78ea-ddf7-47f3-804f-b78e28153174@github.com> On Wed, 16 Nov 2022 18:32:19 GMT, Jim Laskey wrote: >> And, `StringTemplate` is missing a surrounding code/link tag > > Changing. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Nov 18 13:53:37 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 18 Nov 2022 13:53:37 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v25] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #10 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/89f9ac02..fc679656 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=23-24 Stats: 26 lines in 1 file changed: 10 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Fri Nov 18 14:10:11 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Fri, 18 Nov 2022 14:10:11 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/fc679656..c51f88c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From alanb at openjdk.org Fri Nov 18 14:42:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 14:42:58 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error [v2] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 11:43:56 GMT, Adam Sotona wrote: >> Option --disable- at files is passed to VM option causing it to fail. >> Proposed patch skips --disable- at files option in src/java.base/share/native/libjli/java.c ParseArguments processing, so it is not passed to the VM. >> The patch also adds relevant test to ArgsFileTest. >> >> Please review. >> >> Thank you, >> Adam > > Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: > > handling of --disable- at files moved from runtime/arguments.cpp to libjli/java.c ParseArguments > DisableFilesOptionTest merged to ArgsFileTest::killSwitch > help typo moved to a new bug Good to see that this turned out to a simple change. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11183 From duke at openjdk.org Fri Nov 18 14:45:56 2022 From: duke at openjdk.org (Weibing Xiao) Date: Fri, 18 Nov 2022 14:45:56 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v3] In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: update according to review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11174/files - new: https://git.openjdk.org/jdk/pull/11174/files/bcbba19e..ede6c42e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=01-02 Stats: 52 lines in 3 files changed: 17 ins; 14 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/11174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11174/head:pull/11174 PR: https://git.openjdk.org/jdk/pull/11174 From jvernee at openjdk.org Fri Nov 18 14:54:52 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 18 Nov 2022 14:54:52 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v7] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: 8296973: saving errno on a value-returning function crashes the JVM Reviewed-by: mcimadamore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/4d440443..0fa0e8cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=05-06 Stats: 197 lines in 9 files changed: 159 ins; 22 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Fri Nov 18 14:54:54 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 18 Nov 2022 14:54:54 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v6] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 17:04:03 GMT, Jorn Vernee wrote: >> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. >> >> This is split off from the main JEP integration to make reviewing easier. >> >> This includes the following patches: >> >> 1. https://github.com/openjdk/panama-foreign/pull/698 >> 2. https://github.com/openjdk/panama-foreign/pull/699 >> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 >> 4. https://github.com/openjdk/panama-foreign/pull/740 >> 5. https://github.com/openjdk/panama-foreign/pull/746 >> 6. https://github.com/openjdk/panama-foreign/pull/742 >> 7. https://github.com/openjdk/panama-foreign/pull/743 >> >> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. >> >> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. >> >> Please refer to the PR of each individual patch for a more detailed description. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > fix stubs I've added one more bug fix to this pull request, which fixes a crash when using `CaptureCallState`. See the original PR: https://github.com/openjdk/panama-foreign/pull/753 See also the commit for a concise diff of the changes: https://github.com/openjdk/jdk/pull/11019/commits/0fa0e8cff14bd1f4978f4b28c5c3ddceda302d20 ------------- PR: https://git.openjdk.org/jdk/pull/11019 From asotona at openjdk.org Fri Nov 18 14:59:56 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 18 Nov 2022 14:59:56 GMT Subject: Integrated: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 12:34:29 GMT, Adam Sotona wrote: > Option --disable- at files is passed to VM option causing it to fail. > Proposed patch skips --disable- at files option in src/java.base/share/native/libjli/java.c ParseArguments processing, so it is not passed to the VM. > The patch also adds relevant test to ArgsFileTest. > > Please review. > > Thank you, > Adam This pull request has now been integrated. Changeset: 13158cb5 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/13158cb52db723be4932d815bdb0a17245259c84 Stats: 7 lines in 2 files changed: 6 ins; 0 del; 1 mod 8293041: --disable- at files option doesn't work and cause an error Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/11183 From aph at openjdk.org Fri Nov 18 15:05:42 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 15:05:42 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v11] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/280cd6c5..d9e5979f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=09-10 Stats: 19 lines in 2 files changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From rriggs at openjdk.org Fri Nov 18 15:10:22 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 18 Nov 2022 15:10:22 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 03:26:38 GMT, Joe Darcy wrote: > Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. > > Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 Marked as reviewed by rriggs (Reviewer). test/jdk/java/lang/Class/getModifiers/TestPrimitiveAndArrayModifiers.java line 73: > 71: int actualModifiers = arrayClass.getModifiers(); > 72: if (expectedModifiers != actualModifiers) { > 73: System.out.println("Expected " + Modifier.toString(expectedModifiers) + Please include the name of the class being tested in the message. If the cause was included in the exception, it would appear in the jtreg summary without needing to read through the .jtr file. Also for the primitive test below. ------------- PR: https://git.openjdk.org/jdk/pull/11229 From alanb at openjdk.org Fri Nov 18 15:23:27 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 15:23:27 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v11] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 15:05:42 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback src/java.base/share/classes/java/lang/Thread.java line 787: > 785: > 786: // special value to mean a new thread > 787: this.scopedValueBindings = Thread.class; The addition of NEW_THREAD_BINDINGS means this one should change too. The update means the comment should probably be adjusted too, maybe "initial value for a new thread". ------------- PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Fri Nov 18 15:40:22 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 15:40:22 GMT Subject: RFR: 8297258: Typo in `java -help` referencing -disable-@files instead of --disable-@files In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 11:57:40 GMT, Adam Sotona wrote: > There is a typo in `java -help` referencing -disable- at files instead of --disable- at files option. > > Please review. > > Thanks, > Adam @alisenchung Would it be possible to comment on whether changes like this should be touching the translations? Is there resource file update planned for JDK 20 that will update these files anyway. ------------- PR: https://git.openjdk.org/jdk/pull/11236 From heidinga at openjdk.org Fri Nov 18 15:51:14 2022 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 18 Nov 2022 15:51:14 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes In-Reply-To: References: Message-ID: <2_vD2JO5SLQezLBajoPxzicNI-kInUOUAZWysD4X5u0=.1f546173-6211-4604-bee4-903f3d50b2a0@github.com> On Fri, 18 Nov 2022 03:26:38 GMT, Joe Darcy wrote: > Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. > > Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 src/java.base/share/classes/java/lang/Class.java line 1306: > 1304: * {@code true} > 1305: *

    • its interface modifier is always {@code false}, event when > 1306: * the component type is an interface Should this mention that all array classes will also have their `abstract` modifier set? The test cases seem to confirm that it's expected but we haven't stated it explicitly here. ------------- PR: https://git.openjdk.org/jdk/pull/11229 From alanb at openjdk.org Fri Nov 18 15:54:34 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 15:54:34 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v3] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Fri, 18 Nov 2022 14:45:56 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > update according to review comment The src changes in update ede6c42e look okay. The test name is a bit strange, maybe a name like TempDirDoesNotExist.java would work better. ------------- PR: https://git.openjdk.org/jdk/pull/11174 From aph at openjdk.org Fri Nov 18 15:55:30 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 15:55:30 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v12] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Reviewer feedback - Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/d9e5979f..22cdc1af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=10-11 Stats: 64 lines in 7 files changed: 30 ins; 19 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Fri Nov 18 15:55:30 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 15:55:30 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: <3wlfTnsbrVrppFImhVNfweUmw7nm9L2az9SOlqiNCAk=.c3478ce5-b4ab-46ba-a0e9-c7667d9cf5b2@github.com> References: <3wlfTnsbrVrppFImhVNfweUmw7nm9L2az9SOlqiNCAk=.c3478ce5-b4ab-46ba-a0e9-c7667d9cf5b2@github.com> Message-ID: On Thu, 17 Nov 2022 18:58:11 GMT, Andrew Haley wrote: >> src/hotspot/share/utilities/exceptions.cpp line 166: >> >>> 164: // Remove the ScopedValue cache in case we got a virtual machine >>> 165: // Error while we were trying to manipulate ScopedValue bindings. >>> 166: thread->set_scopedValueCache(NULL); >> >> I am see this pattern repeat quite often: >> >> thread->set_scopedValueCache(NULL); >> oop threadObj = thread->vthread(); >> assert(threadOop != NULL, "must be"); // <--- sometimes >> java_lang_Thread::clear_scopedValueBindings(threadObj); >> >> Encapsulate in a method on the `JavaThread` class? > > That sounds good. Done. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From rriggs at openjdk.org Fri Nov 18 15:59:27 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 18 Nov 2022 15:59:27 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v2] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: <6GQgMwRBIDb71HOJayH52hqLzqrdHjQTUM9lW7SGG3s=.eb198ebc-1938-440b-863c-fa0643087eae@github.com> On Wed, 16 Nov 2022 15:03:37 GMT, Roger Riggs wrote: >> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: >> >> the change according to review comment > > src/java.base/share/classes/jdk/internal/util/SystemProps.java line 70: > >> 68: HashMap props = raw.cmdProperties(); >> 69: >> 70: customTmpdir = props.get("java.io.tmpdir"); > > Move the assignment to line 98: > > `customTmpdir = putIfAbsent(props, "java.io.tmpdir", raw.propDefault(Raw._java_io_tmpdir_NDX));` > > It will return null if the property is not already set and save a little bit. > If it is set, it will return the custom directory. I retract this suggestion, the `putIfAbsent` method does not return a value. Moving the assignment to before line 113, would keep the references to java.io.tmpdir together. ------------- PR: https://git.openjdk.org/jdk/pull/11174 From rriggs at openjdk.org Fri Nov 18 15:59:28 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 18 Nov 2022 15:59:28 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v3] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: <3wIvK5FWEhb508gOW8KDebIpCY88CUvhUDOl9maX02U=.e54456e7-494e-4a26-9d3e-eb9b6868c458@github.com> On Fri, 18 Nov 2022 14:45:56 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > update according to review comment test/jdk/java/io/File/TempDirectoryNotExisting.java line 73: > 71: } catch (Exception e) { > 72: e.printStackTrace(); > 73: } This repetition of the code is not necessary if invoked with the two arguments "io" and "nio". ------------- PR: https://git.openjdk.org/jdk/pull/11174 From aph at openjdk.org Fri Nov 18 16:02:40 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 16:02:40 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v13] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/StructuredTaskScope.java Co-authored-by: Alan Bateman ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/22cdc1af..cac85ad0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From ethan at mccue.dev Fri Nov 18 16:43:45 2022 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 18 Nov 2022 11:43:45 -0500 Subject: Task for an aspiring JDK contributor In-Reply-To: References: Message-ID: new ArrayList<>(Arrays.asList(theArray)); I'm not intending to be pithy - just this is one of the "known deficiencies" of the collections framework. If you look hard enough you can find some spitballing I did on how to address it in the core-libs mailing list (which would be the place to go for this sort of stuff - cc-ing). The internal class names aren't trivial to fix either because someone somewhere has serialized a java.util.Arrays$ArrayList using ObjectOutputStream and wants to read it back out at some point. Not impossible to address, just tricky. What is the situation where you encountered the internal class name? It could be worth it to make it more clear in whatever that debug scenario is. --- Other than that, to contribute code to the JDK you need to sign the OCA. It will take a bit so you should get that out of the way. On Fri, Nov 18, 2022 at 11:29 AM Andreas R?sdal wrote: > Yes, the exception comes when adding objects to the returned list. So I > would like a convenient way to use Arrays to convert an array to a normal > modifiable java.util.ArrayList, instead of this AbstractList. > > > On Fri, Nov 18, 2022 at 5:23 PM Ethan McCue wrote: > >> What situation were you encountering the exception? Was it when trying to >> add to the returned list? >> >> If so, that's expected. Arrays.asList only wraps an underlying array, it >> can't grow it. By that measure List.of() is even more unintuitive because >> you can't set anything. >> >> On Fri, Nov 18, 2022, 11:06 AM Andreas R?sdal >> wrote: >> >>> Hello! >>> >>> I am an aspiring JDK contributor, having used Java in my work as a >>> developer. >>> >>> I was recently surprised by an Exception thrown when using the >>> java.util.Arrays.asList() method >>> so I would like to propose some improvements to this API. In particular: >>> - When using java.util.Arrays.asList() then AbstractList is throwing UnsupportedOperationException >>> which is not user-friendly or intuitive. >>> - java.util.Arrays.asList() returning a private class called ArrayList, >>> which is not the usual java.util.ArrayList, so it's not user-friendly or >>> intuitive. >>> >>> Since this would be my first contribution to the JDK, and the goal is to >>> complete the contribution with accepted pull request and get the Arrays API >>> improved, what would the first step to making this first improvement to the >>> JDK be? >>> >>> I would also like to share a link to an open source project I've been >>> working on: >>> https://github.com/fciv-net/fciv-net >>> >>> Thank you! >>> >>> Regards, >>> Andreas R. >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From coleenp at openjdk.org Fri Nov 18 16:47:18 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 18 Nov 2022 16:47:18 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file CSR is approved, please review. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From aph at openjdk.org Fri Nov 18 16:47:37 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 16:47:37 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v14] In-Reply-To: References: Message-ID: <4mNldDTjTMEAERukS9Hja6bvLGUGjiTAkGCpp2rdv3g=.b2e85e6b-6eff-4820-bb84-0a3998005c31@github.com> > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 - Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/cac85ad0..6de9a4cc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=12-13 Stats: 27 lines in 2 files changed: 9 ins; 13 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Fri Nov 18 16:47:38 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 16:47:38 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v14] In-Reply-To: <6PNLRgFIjkvIRL_tIW0btKxdEapZI6_JC8roNRFBSws=.a6292551-ac7b-4f45-a851-3c4c614edc3b@github.com> References: <40rwB5m6Mskkevkwkj8B34o540txfesN7P-pOGWPfqA=.4cf0adb3-1e3d-4a87-b2bf-505c7f15d487@github.com> <6PNLRgFIjkvIRL_tIW0btKxdEapZI6_JC8roNRFBSws=.a6292551-ac7b-4f45-a851-3c4c614edc3b@github.com> Message-ID: On Wed, 16 Nov 2022 19:04:29 GMT, Andrew Haley wrote: >> Probably so, yes. I'll have a look at that along with caching failure. > > So I just did the experiment of caching failures and the result of `isBound()`. > > This test: > > > @Benchmark > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public int thousandMaybeGets(Blackhole bh) throws Exception { > int result = 0; > for (int i = 0; i < 1_000; i++) { > if (ScopedValuesData.sl1.isBound()) { > result += ScopedValuesData.sl1.get(); > } > } > return result; > } > > > > Before and after: > > > ScopedValues.thousandMaybeGets avgt 10 13436.112 ? 20.885 ns/op > ScopedValues.thousandMaybeGets avgt 10 56.315 ? 0.583 ns/op > > > You may have a point. The experiment is on a branch called `JDK-8286666-cache-queries` in [My personal repo](https://github.com/theRealAph/jdk). > > I'd push it now but it's getting a bit late to make such changes now. WDYT? Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Fri Nov 18 17:05:32 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 17:05:32 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v10] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 20:18:42 GMT, Paul Sandoz wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - Javadoc changes. >> - ProblemList.txt cleanup > > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 824: > >> 822: } >> 823: >> 824: public static void invalidate() { > > Is this method used? No. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Fri Nov 18 17:13:25 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 17:13:25 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11023 From andreas.rosdal at gmail.com Fri Nov 18 17:14:10 2022 From: andreas.rosdal at gmail.com (=?UTF-8?Q?Andreas_R=C3=B8sdal?=) Date: Fri, 18 Nov 2022 18:14:10 +0100 Subject: Task for an aspiring JDK contributor In-Reply-To: References: Message-ID: `new ArrayList<>(Arrays.asList(array))` is quite complex syntax to convert an array to an java.util.ArrayList, so a suggestion could be to add a new method to Arrays to convert an array to a normal java.util.ArrayList which is modifiable. Are there any low-hanging-fruit issues in core-libs-dev in bugs.openjdk.org that you are aware of that you would like me to help you implement? Thanks for considering my request. Regards, Andreas On Fri, Nov 18, 2022 at 5:51 PM Daniel Fuchs wrote: > Hi Andreas, > > First of all, congratulations for seeking advice before working on > a PR. This is exactly how first contributions should start. Thank > you for that! > > Given the area in which you intended to work however, `core-libs-dev` > might have been a better list than `discuss` to start from. > > With regard to the meat of the issue however, and as noted by Ethan, > Arrays.asList() behaves as intended, and changing that would be a > major incompatible change, as many users of the API expect the list > returned by Arrays.asList to be immutable (and depend on it). > It is not possible nor desirable to change that. > > As for your observation, I believe that: > > `new ArrayList<>(Arrays.asList(array))` > > will get you what you want. > > best regards, > > -- daniel > > On 18/11/2022 16:29, Andreas R?sdal wrote: > > Yes, the exception comes when adding objects to the returned list. So I > > would like a convenient way to use Arrays to convert an array to a > > normal modifiable java.util.ArrayList, instead of this AbstractList. > > > > > > On Fri, Nov 18, 2022 at 5:23 PM Ethan McCue > > wrote: > > > > What situation were you encountering the exception? Was it when > > trying to add to the returned list? > > > > If so, that's expected. Arrays.asList only wraps an underlying > > array, it can't grow it. By that measure List.of() is even more > > unintuitive because you can't set anything. > > > > On Fri, Nov 18, 2022, 11:06 AM Andreas R?sdal > > > wrote: > > > > Hello! > > > > I am an aspiring JDK contributor, having used Java in my work as > > a developer. > > > > I was recently surprised by an Exception thrown when using the > > java.util.Arrays.asList() method > > so I would like to propose some improvements to this API. In > > particular: > > - When using java.util.Arrays.asList() then AbstractList is > > throwing UnsupportedOperationException which is not > > user-friendly or intuitive. > > - java.util.Arrays.asList() returning a private class called > > ArrayList, which is not the usual java.util.ArrayList, so it's > > not user-friendly or intuitive. > > > > Since this would be my first contribution to the JDK, and the > > goal is to complete the contribution with accepted pull request > > and get the Arrays API improved, what would the first step to > > making this first improvement to the JDK be? > > > > I would also like to share a link to an open source project I've > > been working on: > > https://github.com/fciv-net/fciv-net > > > > > > Thank you! > > > > Regards, > > Andreas R. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at openjdk.org Fri Nov 18 17:19:24 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 17:19:24 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v15] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Reviewer feedback - Reviewer feedback Javadoc fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/6de9a4cc..17c458fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=13-14 Stats: 20 lines in 2 files changed: 3 ins; 4 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From ethan at mccue.dev Fri Nov 18 17:23:05 2022 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 18 Nov 2022 12:23:05 -0500 Subject: Task for an aspiring JDK contributor In-Reply-To: References: Message-ID: I think there is potentially actionable feedback in that the exception thrown when users bump into this limitation kinda sucks jshell> Arrays.asList(1, 2, 3).add(4); | Exception java.lang.UnsupportedOperationException | at AbstractList.add (AbstractList.java:155) | at AbstractList.add (AbstractList.java:113) | at (#8:1) jshell> try { Arrays.asList(1, 2, 3).add(4);} catch (Exception e) { System.out.println(e.getMessage());} null I think there would be value in overriding "add" and other such operations to provide enough context for users to *understand* that * they did an unsupported operation * the list given by `Arrays.asList` was the cause If I had to guess, that's the core of the frustration. The process to get from "not understanding what went wrong" -> "understanding what went wrong" -> "knowing how to fix it" is high. The design problem is how much context can be conveyed in an exception message/stack trace. There is a similar conversation to be had for the collections returned by List.of() and similar. jshell> List.of().add(1) | Exception java.lang.UnsupportedOperationException | at ImmutableCollections.uoe (ImmutableCollections.java:142) | at ImmutableCollections$AbstractImmutableCollection.add (ImmutableCollections.java:147) | at (#6:1) jshell> try { List.of(1, 2, 3).add(4);} catch (Exception e) { System.out.println(e.getMessage());} null There is a clue in the stack trace here though for List.of() with the "ImmutableCollections" calls. Maybe if we took two moves 1. Renamed the internal ArrayList to something like ArrayWrappingList 2. Overrode add then the stack trace could be enough (or better than the status quo) jshell> Arrays.asList(1, 2, 3).add(4); | Exception java.lang.UnsupportedOperationException | at ArrayWrappingList.add (ArrayWrappingList.java:155) | at ArrayWrappingList.add (ArrayWrappingList.java:113) | at (#8:1) On Fri, Nov 18, 2022 at 12:14 PM Andreas R?sdal wrote: > `new ArrayList<>(Arrays.asList(array))` is quite complex syntax to > convert an array to an java.util.ArrayList, > so a suggestion could be to add a new method to Arrays to convert an array > to a normal java.util.ArrayList which is modifiable. > > Are there any low-hanging-fruit issues in core-libs-dev in > bugs.openjdk.org that you are aware of that > you would like me to help you implement? > > Thanks for considering my request. > > Regards, > Andreas > > > > > On Fri, Nov 18, 2022 at 5:51 PM Daniel Fuchs > wrote: > >> Hi Andreas, >> >> First of all, congratulations for seeking advice before working on >> a PR. This is exactly how first contributions should start. Thank >> you for that! >> >> Given the area in which you intended to work however, `core-libs-dev` >> might have been a better list than `discuss` to start from. >> >> With regard to the meat of the issue however, and as noted by Ethan, >> Arrays.asList() behaves as intended, and changing that would be a >> major incompatible change, as many users of the API expect the list >> returned by Arrays.asList to be immutable (and depend on it). >> It is not possible nor desirable to change that. >> >> As for your observation, I believe that: >> >> `new ArrayList<>(Arrays.asList(array))` >> >> will get you what you want. >> >> best regards, >> >> -- daniel >> >> On 18/11/2022 16:29, Andreas R?sdal wrote: >> > Yes, the exception comes when adding objects to the returned list. So I >> > would like a convenient way to use Arrays to convert an array to a >> > normal modifiable java.util.ArrayList, instead of this AbstractList. >> > >> > >> > On Fri, Nov 18, 2022 at 5:23 PM Ethan McCue > > > wrote: >> > >> > What situation were you encountering the exception? Was it when >> > trying to add to the returned list? >> > >> > If so, that's expected. Arrays.asList only wraps an underlying >> > array, it can't grow it. By that measure List.of() is even more >> > unintuitive because you can't set anything. >> > >> > On Fri, Nov 18, 2022, 11:06 AM Andreas R?sdal >> > > wrote: >> > >> > Hello! >> > >> > I am an aspiring JDK contributor, having used Java in my work as >> > a developer. >> > >> > I was recently surprised by an Exception thrown when using the >> > java.util.Arrays.asList() method >> > so I would like to propose some improvements to this API. In >> > particular: >> > - When using java.util.Arrays.asList() then AbstractList is >> > throwing UnsupportedOperationException which is not >> > user-friendly or intuitive. >> > - java.util.Arrays.asList() returning a private class called >> > ArrayList, which is not the usual java.util.ArrayList, so it's >> > not user-friendly or intuitive. >> > >> > Since this would be my first contribution to the JDK, and the >> > goal is to complete the contribution with accepted pull request >> > and get the Arrays API improved, what would the first step to >> > making this first improvement to the JDK be? >> > >> > I would also like to share a link to an open source project I've >> > been working on: >> > https://github.com/fciv-net/fciv-net >> > >> > >> > Thank you! >> > >> > Regards, >> > Andreas R. >> > >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Fri Nov 18 17:34:28 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 18 Nov 2022 17:34:28 GMT Subject: RFR: 8297258: Typo in `java -help` referencing -disable-@files instead of --disable-@files In-Reply-To: References: Message-ID: <_MaD09nl447AyZ27NlwxnA_D8VTVo6f0cX11dFIiNbw=.8cf1101e-4293-4610-a760-5b56d59b2f9d@github.com> On Fri, 18 Nov 2022 11:57:40 GMT, Adam Sotona wrote: > There is a typo in `java -help` referencing -disable- at files instead of --disable- at files option. > > Please review. > > Thanks, > Adam Changes in English resource bundles are automatically detected by the translation process, and each JDK release (incl. 20) will have an l10n cycle that should correctly reflect the changes in those l10n files. However that only applies to Oracle supported locales (de/ja/zh-CN), so changes in those other l10n files in this PR will stay. ------------- PR: https://git.openjdk.org/jdk/pull/11236 From alanb at openjdk.org Fri Nov 18 17:34:28 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 17:34:28 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v15] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 17:19:24 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: > > - Reviewer feedback > - Reviewer feedback Javadoc fixes src/java.base/share/classes/java/lang/Thread.java line 789: > 787: > 788: // special value to mean a new thread > 789: this.scopedValueBindings = NEW_THREAD_BINDINGS; Can we change the comment on this one to be the same as the other constructor? src/java.base/share/classes/java/lang/Thread.java line 1622: > 1620: // The VM recognizes this method as special, so any changes to the > 1621: // name or signature require corresponding changes in > 1622: // JVM_FindScopedValueBindings(). Minor nit but I'd prefer to keep things consistent with the existing code/style where we can. In this case, we can move the comment to move the annotations with the /* .. */ comments so it's the same as the other methods. src/java.base/share/classes/java/lang/VirtualThread.java line 316: > 314: } > 315: } > 316: @Hidden Missing line break. Suggestion: @Hidden ------------- PR: https://git.openjdk.org/jdk/pull/10952 From darcy at openjdk.org Fri Nov 18 17:39:23 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 17:39:23 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes In-Reply-To: <2_vD2JO5SLQezLBajoPxzicNI-kInUOUAZWysD4X5u0=.1f546173-6211-4604-bee4-903f3d50b2a0@github.com> References: <2_vD2JO5SLQezLBajoPxzicNI-kInUOUAZWysD4X5u0=.1f546173-6211-4604-bee4-903f3d50b2a0@github.com> Message-ID: On Fri, 18 Nov 2022 15:47:37 GMT, Dan Heidinga wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. >> >> Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 > > src/java.base/share/classes/java/lang/Class.java line 1306: > >> 1304: * {@code true} >> 1305: *
    • its interface modifier is always {@code false}, event when >> 1306: * the component type is an interface > > Should this mention that all array classes will also have their `abstract` modifier set? The test cases seem to confirm that it's expected but we haven't stated it explicitly here. Yes -- good catch. Adding "abstract" got lost in an edit; I'll update the patch and CSR accordingly. ------------- PR: https://git.openjdk.org/jdk/pull/11229 From darcy at openjdk.org Fri Nov 18 17:39:24 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 17:39:24 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 15:04:13 GMT, Roger Riggs wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. >> >> Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 > > test/jdk/java/lang/Class/getModifiers/TestPrimitiveAndArrayModifiers.java line 73: > >> 71: int actualModifiers = arrayClass.getModifiers(); >> 72: if (expectedModifiers != actualModifiers) { >> 73: System.out.println("Expected " + Modifier.toString(expectedModifiers) + > > Please include the name of the class being tested in the message. > If the cause was included in the exception, it would appear in the jtreg summary without needing to read through the .jtr file. > > Also for the primitive test below. Good suggestion; will update. > Please include the name of the class being tested in the message. If the cause was included in the exception, it would appear in the jtreg summary without needing to read through the .jtr file. > > Also for the primitive test below. Good suggestion; will update. ------------- PR: https://git.openjdk.org/jdk/pull/11229 From alanb at openjdk.org Fri Nov 18 17:43:54 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 17:43:54 GMT Subject: RFR: 8296672: Implementation of Virtual Threads (Second Preview) Message-ID: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com> JEP 436 proposes a second preview of Virtual Threads to allow time for more feedback and to get more experience with this feature. There is no change in direction, no API changes, and no bulk update of the implementation. For the implementation, there has been ~35 changes/issues pushed to the main line, and a few more coming. For this PR, we just bump the JEP number used by javadoc from 425 to 436. ------------- Commit messages: - JEP 425 -> JEP 436 Changes: https://git.openjdk.org/jdk/pull/11235/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11235&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296672 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11235.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11235/head:pull/11235 PR: https://git.openjdk.org/jdk/pull/11235 From darcy at openjdk.org Fri Nov 18 17:46:33 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 17:46:33 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v2] In-Reply-To: References: Message-ID: > Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. > > Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11229/files - new: https://git.openjdk.org/jdk/pull/11229/files/3321b086..dd1f3005 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11229&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11229&range=00-01 Stats: 11 lines in 2 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11229.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11229/head:pull/11229 PR: https://git.openjdk.org/jdk/pull/11229 From andreas.rosdal at gmail.com Fri Nov 18 17:46:51 2022 From: andreas.rosdal at gmail.com (=?UTF-8?Q?Andreas_R=C3=B8sdal?=) Date: Fri, 18 Nov 2022 18:46:51 +0100 Subject: Task for an aspiring JDK contributor In-Reply-To: References: Message-ID: How about this as a proposed solution to avoid UnsupportedOperationException: 1. Renamed the internal ArrayList to ArrayWrappingList 2. Override add() in ArrayWrappingList and make it deprecated to warn people from using it. On Fri, Nov 18, 2022 at 6:23 PM Ethan McCue wrote: > I think there is potentially actionable feedback in that the exception > thrown when users bump into this limitation kinda sucks > > jshell> Arrays.asList(1, 2, 3).add(4); > | Exception java.lang.UnsupportedOperationException > | at AbstractList.add (AbstractList.java:155) > | at AbstractList.add (AbstractList.java:113) > | at (#8:1) > > jshell> try { Arrays.asList(1, 2, 3).add(4);} catch (Exception e) { > System.out.println(e.getMessage());} > null > > I think there would be value in overriding "add" and other such operations > to provide enough context for users to *understand* that > * they did an unsupported operation > * the list given by `Arrays.asList` was the cause > > If I had to guess, that's the core of the frustration. The process to get > from "not understanding what went wrong" -> "understanding what went wrong" > -> "knowing how to fix it" is high. > > The design problem is how much context can be conveyed in an exception > message/stack trace. > > There is a similar conversation to be had for the collections returned by > List.of() and similar. > > jshell> List.of().add(1) > | Exception java.lang.UnsupportedOperationException > | at ImmutableCollections.uoe (ImmutableCollections.java:142) > | at ImmutableCollections$AbstractImmutableCollection.add > (ImmutableCollections.java:147) > | at (#6:1) > > jshell> try { List.of(1, 2, 3).add(4);} catch (Exception e) { > System.out.println(e.getMessage());} > null > > There is a clue in the stack trace here though for List.of() with the > "ImmutableCollections" calls. Maybe if we took two moves > > 1. Renamed the internal ArrayList to something like ArrayWrappingList > 2. Overrode add > > then the stack trace could be enough (or better than the status quo) > > jshell> Arrays.asList(1, 2, 3).add(4); > | Exception java.lang.UnsupportedOperationException > | at ArrayWrappingList.add (ArrayWrappingList.java:155) > | at ArrayWrappingList.add (ArrayWrappingList.java:113) > | at (#8:1) > > On Fri, Nov 18, 2022 at 12:14 PM Andreas R?sdal > wrote: > >> `new ArrayList<>(Arrays.asList(array))` is quite complex syntax to >> convert an array to an java.util.ArrayList, >> so a suggestion could be to add a new method to Arrays to convert an >> array to a normal java.util.ArrayList which is modifiable. >> >> Are there any low-hanging-fruit issues in core-libs-dev in >> bugs.openjdk.org that you are aware of that >> you would like me to help you implement? >> >> Thanks for considering my request. >> >> Regards, >> Andreas >> >> >> >> >> On Fri, Nov 18, 2022 at 5:51 PM Daniel Fuchs >> wrote: >> >>> Hi Andreas, >>> >>> First of all, congratulations for seeking advice before working on >>> a PR. This is exactly how first contributions should start. Thank >>> you for that! >>> >>> Given the area in which you intended to work however, `core-libs-dev` >>> might have been a better list than `discuss` to start from. >>> >>> With regard to the meat of the issue however, and as noted by Ethan, >>> Arrays.asList() behaves as intended, and changing that would be a >>> major incompatible change, as many users of the API expect the list >>> returned by Arrays.asList to be immutable (and depend on it). >>> It is not possible nor desirable to change that. >>> >>> As for your observation, I believe that: >>> >>> `new ArrayList<>(Arrays.asList(array))` >>> >>> will get you what you want. >>> >>> best regards, >>> >>> -- daniel >>> >>> On 18/11/2022 16:29, Andreas R?sdal wrote: >>> > Yes, the exception comes when adding objects to the returned list. So >>> I >>> > would like a convenient way to use Arrays to convert an array to a >>> > normal modifiable java.util.ArrayList, instead of this AbstractList. >>> > >>> > >>> > On Fri, Nov 18, 2022 at 5:23 PM Ethan McCue >> > > wrote: >>> > >>> > What situation were you encountering the exception? Was it when >>> > trying to add to the returned list? >>> > >>> > If so, that's expected. Arrays.asList only wraps an underlying >>> > array, it can't grow it. By that measure List.of() is even more >>> > unintuitive because you can't set anything. >>> > >>> > On Fri, Nov 18, 2022, 11:06 AM Andreas R?sdal >>> > > >>> wrote: >>> > >>> > Hello! >>> > >>> > I am an aspiring JDK contributor, having used Java in my work >>> as >>> > a developer. >>> > >>> > I was recently surprised by an Exception thrown when using the >>> > java.util.Arrays.asList() method >>> > so I would like to propose some improvements to this API. In >>> > particular: >>> > - When using java.util.Arrays.asList() then AbstractList is >>> > throwing UnsupportedOperationException which is not >>> > user-friendly or intuitive. >>> > - java.util.Arrays.asList() returning a private class called >>> > ArrayList, which is not the usual java.util.ArrayList, so it's >>> > not user-friendly or intuitive. >>> > >>> > Since this would be my first contribution to the JDK, and the >>> > goal is to complete the contribution with accepted pull request >>> > and get the Arrays API improved, what would the first step to >>> > making this first improvement to the JDK be? >>> > >>> > I would also like to share a link to an open source project >>> I've >>> > been working on: >>> > https://github.com/fciv-net/fciv-net >>> > >>> > >>> > Thank you! >>> > >>> > Regards, >>> > Andreas R. >>> > >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchung at openjdk.org Fri Nov 18 17:47:59 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 18 Nov 2022 17:47:59 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v2] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 17:46:33 GMT, Joe Darcy wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. >> >> Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Same change should also be applied to `Class::accessFlags`? src/java.base/share/classes/java/lang/Class.java line 1305: > 1303: *
    • its {@code final} modifier is always > 1304: * {@code true} > 1305: *
    • its interface modifier is always {@code false}, event when typo: s/event/even/ src/java.base/share/classes/java/lang/Class.java line 1311: > 1309: * void, its {@code public}, {@code abstract}, and {@code final} > 1310: * modifiers are always {@code true}. > 1311: * For class objects representing void, primitive types, and Suggestion: * For {@code Class} objects representing void, primitive types, and ------------- PR: https://git.openjdk.org/jdk/pull/11229 From mchung at openjdk.org Fri Nov 18 17:55:22 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 18 Nov 2022 17:55:22 GMT Subject: RFR: JDK-8296945: PublicMethodsTest is slow due to dependency verification with debug builds In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 09:19:26 GMT, Matthias Baesken wrote: > As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch off VerifyDependencies in this test because of slow machines when (fast)debug builds are used, the test sometimes times out after the [JDK-8266074](https://bugs.openjdk.org/browse/JDK-8266074) Vtable-based CHA implementation implementation came in. > Same has been done for other tests with similar issues, see 8268227: java/foreign/TestUpcall.java still times out . Turning off the dependency verification for this test is okay. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/11234 From mchung at openjdk.org Fri Nov 18 18:01:02 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 18 Nov 2022 18:01:02 GMT Subject: RFR: 8297258: Typo in `java -help` referencing -disable-@files instead of --disable-@files In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 11:57:40 GMT, Adam Sotona wrote: > There is a typo in `java -help` referencing -disable- at files instead of --disable- at files option. > > Please review. > > Thanks, > Adam I believe there is no need to update the localized versions as they will be updated in bulk toward the end of the release. This change is trivial and it's fine. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/11236 From ethan at mccue.dev Fri Nov 18 18:05:36 2022 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 18 Nov 2022 13:05:36 -0500 Subject: Task for an aspiring JDK contributor In-Reply-To: References: Message-ID: The problem is that would necessitate a new public class that is *only* used as a return value. Since it would then come up with auto complete for people searching for ArrayList, that's non trivial. Deprecated also isn't the right concept. Mechanically it puts a line through a method invocation, but this is a more specific sort of disclaimer. Like a @Unsupported. There is a whole separate universe of pitches for more standard annotations, but efforts like that would probably have to start in the community like jspecify is attempting for nullness annotations. On Fri, Nov 18, 2022, 12:47 PM Andreas R?sdal wrote: > How about this as a proposed solution to avoid > UnsupportedOperationException: > 1. Renamed the internal ArrayList to ArrayWrappingList > 2. Override add() in ArrayWrappingList and make it deprecated to warn > people from using it. > > > On Fri, Nov 18, 2022 at 6:23 PM Ethan McCue wrote: > >> I think there is potentially actionable feedback in that the exception >> thrown when users bump into this limitation kinda sucks >> >> jshell> Arrays.asList(1, 2, 3).add(4); >> | Exception java.lang.UnsupportedOperationException >> | at AbstractList.add (AbstractList.java:155) >> | at AbstractList.add (AbstractList.java:113) >> | at (#8:1) >> >> jshell> try { Arrays.asList(1, 2, 3).add(4);} catch (Exception e) { >> System.out.println(e.getMessage());} >> null >> >> I think there would be value in overriding "add" and other such >> operations to provide enough context for users to *understand* that >> * they did an unsupported operation >> * the list given by `Arrays.asList` was the cause >> >> If I had to guess, that's the core of the frustration. The process to get >> from "not understanding what went wrong" -> "understanding what went wrong" >> -> "knowing how to fix it" is high. >> >> The design problem is how much context can be conveyed in an exception >> message/stack trace. >> >> There is a similar conversation to be had for the collections returned by >> List.of() and similar. >> >> jshell> List.of().add(1) >> | Exception java.lang.UnsupportedOperationException >> | at ImmutableCollections.uoe (ImmutableCollections.java:142) >> | at ImmutableCollections$AbstractImmutableCollection.add >> (ImmutableCollections.java:147) >> | at (#6:1) >> >> jshell> try { List.of(1, 2, 3).add(4);} catch (Exception e) { >> System.out.println(e.getMessage());} >> null >> >> There is a clue in the stack trace here though for List.of() with the >> "ImmutableCollections" calls. Maybe if we took two moves >> >> 1. Renamed the internal ArrayList to something like ArrayWrappingList >> 2. Overrode add >> >> then the stack trace could be enough (or better than the status quo) >> >> jshell> Arrays.asList(1, 2, 3).add(4); >> | Exception java.lang.UnsupportedOperationException >> | at ArrayWrappingList.add (ArrayWrappingList.java:155) >> | at ArrayWrappingList.add (ArrayWrappingList.java:113) >> | at (#8:1) >> >> On Fri, Nov 18, 2022 at 12:14 PM Andreas R?sdal >> wrote: >> >>> `new ArrayList<>(Arrays.asList(array))` is quite complex syntax to >>> convert an array to an java.util.ArrayList, >>> so a suggestion could be to add a new method to Arrays to convert an >>> array to a normal java.util.ArrayList which is modifiable. >>> >>> Are there any low-hanging-fruit issues in core-libs-dev in >>> bugs.openjdk.org that you are aware of that >>> you would like me to help you implement? >>> >>> Thanks for considering my request. >>> >>> Regards, >>> Andreas >>> >>> >>> >>> >>> On Fri, Nov 18, 2022 at 5:51 PM Daniel Fuchs >>> wrote: >>> >>>> Hi Andreas, >>>> >>>> First of all, congratulations for seeking advice before working on >>>> a PR. This is exactly how first contributions should start. Thank >>>> you for that! >>>> >>>> Given the area in which you intended to work however, `core-libs-dev` >>>> might have been a better list than `discuss` to start from. >>>> >>>> With regard to the meat of the issue however, and as noted by Ethan, >>>> Arrays.asList() behaves as intended, and changing that would be a >>>> major incompatible change, as many users of the API expect the list >>>> returned by Arrays.asList to be immutable (and depend on it). >>>> It is not possible nor desirable to change that. >>>> >>>> As for your observation, I believe that: >>>> >>>> `new ArrayList<>(Arrays.asList(array))` >>>> >>>> will get you what you want. >>>> >>>> best regards, >>>> >>>> -- daniel >>>> >>>> On 18/11/2022 16:29, Andreas R?sdal wrote: >>>> > Yes, the exception comes when adding objects to the returned list. So >>>> I >>>> > would like a convenient way to use Arrays to convert an array to a >>>> > normal modifiable java.util.ArrayList, instead of this AbstractList. >>>> > >>>> > >>>> > On Fri, Nov 18, 2022 at 5:23 PM Ethan McCue >>> > > wrote: >>>> > >>>> > What situation were you encountering the exception? Was it when >>>> > trying to add to the returned list? >>>> > >>>> > If so, that's expected. Arrays.asList only wraps an underlying >>>> > array, it can't grow it. By that measure List.of() is even more >>>> > unintuitive because you can't set anything. >>>> > >>>> > On Fri, Nov 18, 2022, 11:06 AM Andreas R?sdal >>>> > > >>>> wrote: >>>> > >>>> > Hello! >>>> > >>>> > I am an aspiring JDK contributor, having used Java in my work >>>> as >>>> > a developer. >>>> > >>>> > I was recently surprised by an Exception thrown when using the >>>> > java.util.Arrays.asList() method >>>> > so I would like to propose some improvements to this API. In >>>> > particular: >>>> > - When using java.util.Arrays.asList() then AbstractList is >>>> > throwing UnsupportedOperationException which is not >>>> > user-friendly or intuitive. >>>> > - java.util.Arrays.asList() returning a private class called >>>> > ArrayList, which is not the usual java.util.ArrayList, so it's >>>> > not user-friendly or intuitive. >>>> > >>>> > Since this would be my first contribution to the JDK, and the >>>> > goal is to complete the contribution with accepted pull >>>> request >>>> > and get the Arrays API improved, what would the first step to >>>> > making this first improvement to the JDK be? >>>> > >>>> > I would also like to share a link to an open source project >>>> I've >>>> > been working on: >>>> > https://github.com/fciv-net/fciv-net >>>> > >>>> > >>>> > Thank you! >>>> > >>>> > Regards, >>>> > Andreas R. >>>> > >>>> >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Fri Nov 18 18:09:30 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 18:09:30 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v2] In-Reply-To: References: Message-ID: <172hqjKJaef2hL9ASEl-tAO9cQwQgqMJM8IoXODRokc=.4564a750-3738-4628-9721-f3e91e0c97c3@github.com> On Fri, 18 Nov 2022 17:42:41 GMT, Mandy Chung wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > src/java.base/share/classes/java/lang/Class.java line 1311: > >> 1309: * void, its {@code public}, {@code abstract}, and {@code final} >> 1310: * modifiers are always {@code true}. >> 1311: * For class objects representing void, primitive types, and > > Suggestion: > > * For {@code Class} objects representing void, primitive types, and Yes; I'll make the corresponding change to accessFlags() and its tests; updated PR and CSR momentarily. Thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11229 From darcy at openjdk.org Fri Nov 18 18:12:56 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 18:12:56 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v3] In-Reply-To: References: Message-ID: > Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. > > Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11229/files - new: https://git.openjdk.org/jdk/pull/11229/files/dd1f3005..375c260d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11229&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11229&range=01-02 Stats: 29 lines in 2 files changed: 2 ins; 9 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/11229.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11229/head:pull/11229 PR: https://git.openjdk.org/jdk/pull/11229 From duke at openjdk.org Fri Nov 18 18:36:51 2022 From: duke at openjdk.org (Weibing Xiao) Date: Fri, 18 Nov 2022 18:36:51 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v4] In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: updated from the review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11174/files - new: https://git.openjdk.org/jdk/pull/11174/files/ede6c42e..38f8855b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=02-03 Stats: 249 lines in 3 files changed: 119 ins; 130 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11174/head:pull/11174 PR: https://git.openjdk.org/jdk/pull/11174 From aph at openjdk.org Fri Nov 18 18:38:53 2022 From: aph at openjdk.org (Andrew Haley) Date: Fri, 18 Nov 2022 18:38:53 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v16] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Add ensureMaterializedForStackWalk kludge for AArch64 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/17c458fa..86ce5bbd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=14-15 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From mchung at openjdk.org Fri Nov 18 18:39:58 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 18 Nov 2022 18:39:58 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v3] In-Reply-To: References: Message-ID: <96pQWklodjgDmZELaoFw2P9uoIBucZ6I0MdL8y9o9DY=.62f9bea0-1903-4fc2-8c8d-15b8d9dc41d4@github.com> On Fri, 18 Nov 2022 18:12:56 GMT, Joe Darcy wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. >> >> Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Looks good. src/java.base/share/classes/java/lang/Class.java line 1346: > 1344: * If this {@code Class} object represents a primitive type or > 1345: * void, the flags are {@code PUBLIC}, {@code ABSTRACT}, and > 1346: * {@code FINAL}. Nit: extra space after `*` in L1344-1346. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.org/jdk/pull/11229 From darcy at openjdk.org Fri Nov 18 18:45:01 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 18:45:01 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2] In-Reply-To: References: Message-ID: > Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11222/files - new: https://git.openjdk.org/jdk/pull/11222/files/88a566c6..f3fc9e26 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222 PR: https://git.openjdk.org/jdk/pull/11222 From darcy at openjdk.org Fri Nov 18 18:45:03 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 18:45:03 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 08:28:22 GMT, Alan Bateman wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > test/jdk/java/lang/Thread/BuilderTest.java line 29: > >> 27: * @enablePreview >> 28: * @compile BuilderTest.java >> 29: * @run testng/othervm BuilderTest > > I assume `@compile` can be dropped from most of these tests now. Also I think /othervm can be dropped too because jtreg will always use othervm for tests that require --enable-preview. When the feature becomes permanent then it would mean dropping the `@enablePreview` tag, no other changes. Right; ideally when the feature becomes non-preview the test update would just be removing the "@enablePreview" line. I didn't author these tests so I initially left any "othervm" directives in place since they aren't incorrect, just at worst a bit inefficient. ------------- PR: https://git.openjdk.org/jdk/pull/11222 From heidinga at openjdk.org Fri Nov 18 18:46:36 2022 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 18 Nov 2022 18:46:36 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 18:12:56 GMT, Joe Darcy wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. >> >> Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. looks good. Thanks Joe ------------- Marked as reviewed by heidinga (no project role). PR: https://git.openjdk.org/jdk/pull/11229 From jjg at openjdk.org Fri Nov 18 18:56:31 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Fri, 18 Nov 2022 18:56:31 GMT Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 02:31:19 GMT, David Holmes wrote: > Hi @jonathan-gibbons , > > I notice that in the new version dash characters are no longer escaped as `-`, do these still display correctly? Yes, at least in all the files I verified and I have no reason to believe it might be different in any other files. On a Mac, you can just do `man ` to render the contents of a troff file. That is how I checked the files that I did. ------------- PR: https://git.openjdk.org/jdk/pull/11223 From alanb at openjdk.org Fri Nov 18 19:08:24 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 18 Nov 2022 19:08:24 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 18:38:46 GMT, Joe Darcy wrote: >> test/jdk/java/lang/Thread/BuilderTest.java line 29: >> >>> 27: * @enablePreview >>> 28: * @compile BuilderTest.java >>> 29: * @run testng/othervm BuilderTest >> >> I assume `@compile` can be dropped from most of these tests now. Also I think /othervm can be dropped too because jtreg will always use othervm for tests that require --enable-preview. When the feature becomes permanent then it would mean dropping the `@enablePreview` tag, no other changes. > > Right; ideally when the feature becomes non-preview the test update would just be removing the "@enablePreview" line. I didn't author these tests so I initially left any "othervm" directives in place since they aren't incorrect, just at worst a bit inefficient. `@enablePreview` wasn't available when most of these tests were initially created. I changed some of to use this tag as part of other changes but didn't cover over the remaining tests that still use `@compile --enable-preview -source ${jdk.version} ...` and `@run main/othervm --enable-preview ...`. I just scanned the tests in test/jdk/java/lang/Thread/virtual and they can all be changed the same way, if you want. If you leave it then we'll just change them at the next edit in this area. ------------- PR: https://git.openjdk.org/jdk/pull/11222 From prappo at openjdk.org Fri Nov 18 19:44:19 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Fri, 18 Nov 2022 19:44:19 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 18:12:56 GMT, Joe Darcy wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. >> >> Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Feeling stupid for asking this, but does it make any sense to keep the order of modifiers "blessed" in text and tests? public protected private abstract static final transient volatile synchronized native strictfp ------------- PR: https://git.openjdk.org/jdk/pull/11229 From duke at openjdk.org Fri Nov 18 20:32:30 2022 From: duke at openjdk.org (liach) Date: Fri, 18 Nov 2022 20:32:30 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 18:12:56 GMT, Joe Darcy wrote: >> Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. >> >> Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. In the new paragraph, the modifiers are sorted by their significance in bitwise representation, from least to most significant. Though `interface` bit comes between `final` and `abstract`. However, in the older previous paragraph, they are sorted by the blessed order in source (suggested by JLS). We can consider whether to unify these orders to both blessed or bitwise. ------------- PR: https://git.openjdk.org/jdk/pull/11229 From rriggs at openjdk.org Fri Nov 18 20:36:37 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 18 Nov 2022 20:36:37 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v4] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Fri, 18 Nov 2022 18:36:51 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > updated from the review comment LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11174 From roger.riggs at oracle.com Fri Nov 18 20:56:07 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 18 Nov 2022 15:56:07 -0500 Subject: Task for an aspiring JDK contributor In-Reply-To: References: Message-ID: <0ef5ff9c-db8d-2c68-360f-02c039ba356c@oracle.com> Hi, I agree the exception message could be added to facilitate the understanding and the resolution of UnsupportedOperationExceptions from List implementations. New issue: https://bugs.openjdk.org/browse/JDK-8297283 As to what should be included in the message, that will need more discussion. To the original point, in the case where the list should have particular features or abilities, such as mutability or extensibility, the developer should construct the list themselves or only use factory methods such as Arrays.asList() that are specified to meet their requirements.? With all kinds of lists and other collections, there are many different implementation features to choose from. Immutable lists are very common and well supported by the libraries. $.02, Roger On 11/18/22 12:23 PM, Ethan McCue wrote: > I think there is potentially actionable feedback in that the exception > thrown when users bump into this limitation kinda sucks > > jshell> Arrays.asList(1, 2, 3).add(4); > | ?Exception java.lang.UnsupportedOperationException > | ? ? ? ?at AbstractList.add (AbstractList.java:155) > | ? ? ? ?at AbstractList.add (AbstractList.java:113) > | ? ? ? ?at (#8:1) > > jshell> try { Arrays.asList(1, 2, 3).add(4);} catch (Exception e) { > System.out.println(e.getMessage());} > null > > I think there would be value in overriding "add" and other such > operations to provide enough context for users to *understand* that > * they did an unsupported operation > * the list given by `Arrays.asList` was the cause > > If I had to guess, that's the core of the frustration. The process to > get from "not understanding what went wrong" -> "understanding what > went wrong" -> "knowing how to fix it" is high. > > The design problem is how much context can be conveyed in an exception > message/stack trace. > > There is a similar conversation to be had for the collections returned > by List.of() and similar. > > jshell> List.of().add(1) > | ?Exception java.lang.UnsupportedOperationException > | ? ? ? ?at ImmutableCollections.uoe (ImmutableCollections.java:142) > | ? ? ? ?at ImmutableCollections$AbstractImmutableCollection.add > (ImmutableCollections.java:147) > | ? ? ? ?at (#6:1) > > jshell> try { List.of(1, 2, 3).add(4);} catch (Exception e) { > System.out.println(e.getMessage());} > null > > There is a clue in the stack trace here though for List.of() with the > "ImmutableCollections" calls. Maybe if we took two moves > > 1. Renamed the internal ArrayList to something like ArrayWrappingList > 2. Overrode add > > then the stack trace could be enough (or better than the status quo) > > jshell> Arrays.asList(1, 2, 3).add(4); > | ?Exception java.lang.UnsupportedOperationException > | ? ? ? ?at ArrayWrappingList.add (ArrayWrappingList.java:155) > | ? ? ? ?at ArrayWrappingList.add (ArrayWrappingList.java:113) > | ? ? ? ?at (#8:1) > > On Fri, Nov 18, 2022 at 12:14 PM Andreas R?sdal > wrote: > > `new ArrayList<>(Arrays.asList(array))`? is quite complex syntax > to convert an array to an java.util.ArrayList, > so a suggestion could be to add a new method to Arrays to convert > an array to a normal java.util.ArrayList which is modifiable. > > Are there any low-hanging-fruit issues in core-libs-dev in > bugs.openjdk.org that you are aware of that > you would like me to help you implement? > > Thanks for considering my request. > > Regards, > Andreas > > > > > On Fri, Nov 18, 2022 at 5:51 PM Daniel Fuchs > wrote: > > Hi Andreas, > > First of all, congratulations for seeking advice before working on > a PR. This is exactly how first contributions should start. Thank > you for that! > > Given the area in which you intended to work however, > `core-libs-dev` > might have been a better list than `discuss` to start from. > > With regard to the meat of the issue however, and as noted by > Ethan, > Arrays.asList() behaves as intended, and changing that would be a > major incompatible change, as many users of the API expect the > list > returned by Arrays.asList to be immutable (and depend on it). > It is not possible nor desirable to change that. > > As for your observation, I believe that: > > ? ?`new ArrayList<>(Arrays.asList(array))` > > will get you what you want. > > best regards, > > -- daniel > > On 18/11/2022 16:29, Andreas R?sdal wrote: > > Yes, the exception comes when adding objects to the returned > list. So I > > would like a convenient way to use Arrays to convert an > array to a > > normal modifiable java.util.ArrayList, instead of this > AbstractList. > > > > > > On Fri, Nov 18, 2022 at 5:23 PM Ethan McCue > > wrote: > > > >? ? ?What situation were you encountering the exception? Was > it when > >? ? ?trying to add to the returned list? > > > >? ? ?If so, that's expected. Arrays.asList only wraps an > underlying > >? ? ?array, it can't grow it. By that measure List.of() is > even more > >? ? ?unintuitive because you can't set anything. > > > >? ? ?On Fri, Nov 18, 2022, 11:06 AM Andreas R?sdal > >? ? ? > wrote: > > > >? ? ? ? ?Hello! > > > >? ? ? ? ?I am an aspiring JDK contributor, having used Java > in my work as > >? ? ? ? ?a developer. > > > >? ? ? ? ?I was recently surprised by an Exception thrown when > using the > >? ? ? ? ?java.util.Arrays.asList() method > >? ? ? ? ?so I would like to propose some improvements to this > API. In > >? ? ? ? ?particular: > >? ? ? ? ?- When using java.util.Arrays.asList() then > AbstractList is > >? ? ? ? ?throwing UnsupportedOperationException which is not > >? ? ? ? ?user-friendly or intuitive. > >? ? ? ? ?- java.util.Arrays.asList() returning a private > class called > >? ? ? ? ?ArrayList, which is not the usual > java.util.ArrayList, so it's > >? ? ? ? ?not user-friendly or intuitive. > > > >? ? ? ? ?Since this would be my first contribution to the > JDK, and the > >? ? ? ? ?goal is to complete the contribution with accepted > pull request > >? ? ? ? ?and get the Arrays API improved, what would the > first step to > >? ? ? ? ?making this first improvement to the JDK be? > > > >? ? ? ? ?I would also like to share a link to an open source > project I've > >? ? ? ? ?been working on: > > https://github.com/fciv-net/fciv-net > >? ? ? ? ? > > > >? ? ? ? ?Thank you! > > > >? ? ? ? ?Regards, > >? ? ? ? ?Andreas R. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bchristi at openjdk.org Fri Nov 18 21:22:05 2022 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 18 Nov 2022 21:22:05 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v3] In-Reply-To: References: Message-ID: > [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". > > One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Mentioned effects are not a complete list ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11218/files - new: https://git.openjdk.org/jdk/pull/11218/files/9983fa68..cbba781f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=01-02 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11218/head:pull/11218 PR: https://git.openjdk.org/jdk/pull/11218 From bchristi at openjdk.org Fri Nov 18 21:22:07 2022 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 18 Nov 2022 21:22:07 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v2] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 20:32:15 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > It's "try-with-resources" (Updated the wording, per comment in the bug report) ------------- PR: https://git.openjdk.org/jdk/pull/11218 From bchristi at openjdk.org Fri Nov 18 21:23:49 2022 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 18 Nov 2022 21:23:49 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v2] In-Reply-To: <6utZydB6hfiuojfSKaYtu9CiU7P-cuQL1AO3gcoJfR8=.5cf11294-cee3-4b9e-abd1-14d011f9e308@github.com> References: <6utZydB6hfiuojfSKaYtu9CiU7P-cuQL1AO3gcoJfR8=.5cf11294-cee3-4b9e-abd1-14d011f9e308@github.com> Message-ID: On Thu, 17 Nov 2022 22:06:47 GMT, Brent Christian wrote: > > Is a CSR needed here? > I will check A CSR is not needed. ------------- PR: https://git.openjdk.org/jdk/pull/11218 From darcy at openjdk.org Fri Nov 18 21:32:19 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 21:32:19 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 19:06:02 GMT, Alan Bateman wrote: >> Right; ideally when the feature becomes non-preview the test update would just be removing the "@enablePreview" line. I didn't author these tests so I initially left any "othervm" directives in place since they aren't incorrect, just at worst a bit inefficient. > > `@enablePreview` wasn't available when most of these tests were initially created. I changed some of to use this tag as part of other changes but didn't cover over the remaining tests that still use `@compile --enable-preview -source ${jdk.version} ...` and `@run main/othervm --enable-preview ...`. I just scanned the tests in test/jdk/java/lang/Thread/virtual and they can all be changed the same way, if you want. If you leave it then we'll just change them at the next edit in this area. I think I got most of those in the PR. There was a file or two I didn't update because not all the @compile/@run directives in the file used --enablePreview and the @enablePreview directive applies to all @compile and @run directives. ------------- PR: https://git.openjdk.org/jdk/pull/11222 From darcy at openjdk.org Fri Nov 18 21:42:27 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 21:42:27 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v3] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 19:40:40 GMT, Pavel Rappo wrote: > > Feeling stupid for asking this, but does it make any sense to keep the order of modifiers "blessed" in text and tests? > > public protected private abstract static final transient volatile synchronized native strictfp Will address nit before pushing; thanks. ------------- PR: https://git.openjdk.org/jdk/pull/11229 From asotona at openjdk.org Fri Nov 18 21:44:32 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 18 Nov 2022 21:44:32 GMT Subject: Integrated: 8297258: Typo in `java -help` referencing -disable-@files instead of --disable-@files In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 11:57:40 GMT, Adam Sotona wrote: > There is a typo in `java -help` referencing -disable- at files instead of --disable- at files option. > > Please review. > > Thanks, > Adam This pull request has now been integrated. Changeset: 3a15e848 Author: Adam Sotona URL: https://git.openjdk.org/jdk/commit/3a15e8483c3155add892279f4870628fa04cb130 Stats: 11 lines in 11 files changed: 0 ins; 0 del; 11 mod 8297258: Typo in `java -help` referencing -disable- at files instead of --disable- at files Reviewed-by: mchung ------------- PR: https://git.openjdk.org/jdk/pull/11236 From darcy at openjdk.org Fri Nov 18 21:46:09 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 21:46:09 GMT Subject: RFR: JDK-8296743: Tighten Class.getModifiers spec for array classes [v4] In-Reply-To: References: Message-ID: > Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. > > Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Address review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11229/files - new: https://git.openjdk.org/jdk/pull/11229/files/375c260d..63cf2df7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11229&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11229&range=02-03 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11229.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11229/head:pull/11229 PR: https://git.openjdk.org/jdk/pull/11229 From darcy at openjdk.org Fri Nov 18 21:54:48 2022 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 18 Nov 2022 21:54:48 GMT Subject: Integrated: JDK-8296743: Tighten Class.getModifiers spec for array classes In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 03:26:38 GMT, Joe Darcy wrote: > Update the spec of Class.getModifiers to match long-standing behavior for primitive and array classes. Remove unneeded implementation flexibility with regard to setting other bit positions. This work was prompted to better support anticipated future Valhalla changes. > > Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8297237 This pull request has now been integrated. Changeset: 6fd14421 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/6fd1442123f7c67740280e8555f60f01a4a2a30e Stats: 180 lines in 3 files changed: 143 ins; 9 del; 28 mod 8296743: Tighten Class.getModifiers spec for array classes Reviewed-by: rriggs, mchung, heidinga ------------- PR: https://git.openjdk.org/jdk/pull/11229 From mchung at openjdk.org Fri Nov 18 22:03:26 2022 From: mchung at openjdk.org (Mandy Chung) Date: Fri, 18 Nov 2022 22:03:26 GMT Subject: RFR: 8296672: Implementation of Virtual Threads (Second Preview) In-Reply-To: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com> References: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com> Message-ID: On Fri, 18 Nov 2022 09:57:39 GMT, Alan Bateman wrote: > JEP 436 proposes a second preview of Virtual Threads to allow time for more feedback and to get more experience with this feature. There is no change in direction, no API changes, and no bulk update of the implementation. For the implementation, there has been ~35 changes/issues pushed to the main line, and a few more coming. For this PR, we just bump the JEP number used by javadoc from 425 to 436. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11235 From naoto at openjdk.org Fri Nov 18 22:11:20 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 18 Nov 2022 22:11:20 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v4] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Fri, 18 Nov 2022 18:36:51 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > updated from the review comment Marked as reviewed by naoto (Reviewer). test/jdk/java/io/File/TempDirDoesNotExist.java line 117: > 115: + "\n" + originalOutput.asLines().toString()); > 116: } > 117: } Nit: need a newline at the end ------------- PR: https://git.openjdk.org/jdk/pull/11174 From naoto at openjdk.org Fri Nov 18 22:12:19 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 18 Nov 2022 22:12:19 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v3] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 21:22:05 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Mentioned effects are not a complete list Looks good, Brent ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk/pull/11218 From smarks at openjdk.org Fri Nov 18 22:58:28 2022 From: smarks at openjdk.org (Stuart Marks) Date: Fri, 18 Nov 2022 22:58:28 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations [v2] In-Reply-To: References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: On Thu, 17 Nov 2022 06:05:40 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? >> >> The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. >> >> `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: >> >> >> Objects.requireNonNull(action); >> while (hasNext()) >> action.accept(next()); >> >> Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. >> >> The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. >> >> New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review suggestion - simplify test Updated tests look good, thanks. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.org/jdk/pull/11154 From rriggs at openjdk.org Fri Nov 18 23:10:09 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 18 Nov 2022 23:10:09 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 14:10:11 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Typo src/java.base/share/classes/java/lang/template/StringProcessor.java line 49: > 47: * @implNote Implementations using {@link StringProcessor} are equivalent to implementations using > 48: * {@code TemplateProcessor} or {@code ValidatingProcessor}, > 49: * however the dominance of {@link String} producing template processors supercedes the redundancy. Amusing to read... Perhaps just, "however, StringProcessor is clearer and easier to understand". src/java.base/share/classes/java/lang/template/StringTemplate.java line 35: > 33: /** > 34: * {@link StringTemplate} is the run-time representation of a string template or > 35: * text block template in a template expression. Can the link to the JLS 15.8.6 be included earlier so the definition of "template expression" isn't hanging until the end of the class javadoc. src/java.base/share/classes/java/lang/template/StringTemplate.java line 115: > 113: public interface StringTemplate { > 114: /** > 115: * Returns s list of fragment literals for this {@link StringTemplate}. Suggestion: * Returns a list of fragment literals for this {@link StringTemplate}. src/java.base/share/classes/java/lang/template/StringTemplate.java line 155: > 153: * For better visibility and when practical, it is recommended that users use the > 154: * {@link StringTemplate#STR} processor instead of invoking the > 155: * {@link StringTemplate#interpolate()} method directly. Removing "users use"... Suggestion: * For better visibility and when practical, it is recommended to use the * {@link StringTemplate#STR} processor instead of invoking the * {@link StringTemplate#interpolate()} method. src/java.base/share/classes/java/lang/template/StringTemplate.java line 206: > 204: * @param stringTemplate the {@link StringTemplate} to represent > 205: * > 206: * @return diagnostic string representing the supplied templated string Suggestion: * @return diagnostic string representing the supplied string template src/java.base/share/classes/java/lang/template/StringTemplate.java line 300: > 298: * {@link StringTemplate StringTemplates}. > 299: * > 300: * @param stringTemplates one or more {@link StringTemplate} Suggestion: * @param stringTemplates zero or more {@link StringTemplate} Also the comment in `TemplateSupport.combine` should say zero or more. src/java.base/share/classes/java/lang/template/StringTemplate.java line 317: > 315: /** > 316: * The {@link StringProcessor} instance conventionally used for the string interpolation > 317: * of a supplied {@link StringTemplate}. Suggestion: * The {@link StringProcessor} instance is conventionally used for the string interpolation * of a supplied {@link StringTemplate}. src/java.base/share/classes/java/lang/template/StringTemplate.java line 334: > 332: /** > 333: * The {@link TemplateProcessor} instance conventionally used to indicate that the > 334: * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred Suggestion: * The {@link TemplateProcessor} instance is conventionally used to indicate that the * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred src/java.base/share/classes/java/lang/template/package-info.java line 27: > 25: > 26: /** > 27: * Provides support for string templates and template processors. Not just support... String templates are provided by {@link StringTemplate} and supporting interfaces and classes. It might also be helpful to include a link to the JLS 15.8.6 Template Expression spec. A brief example here (drawn from the JEP or StringTemplate would provide a good hook for the reader to get started. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From rriggs at openjdk.org Fri Nov 18 23:10:12 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 18 Nov 2022 23:10:12 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v23] In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 17:12:53 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 233: >> >>> 231: >>> 232: /** >>> 233: * Returns a StringTemplate with the given fragments and values. >> >> Suggestion: >> >> * Returns a {@code StringTemplate} with the given fragments and values. > > Stale. Seems not to have been addressed, the previous `of` method uses {@link...} ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jpai at openjdk.org Sat Nov 19 00:59:24 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 19 Nov 2022 00:59:24 GMT Subject: RFR: 8292317: Missing null check for Iterator.forEachRemaining implementations [v2] In-Reply-To: References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: On Thu, 17 Nov 2022 06:05:40 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? >> >> The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. >> >> `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: >> >> >> Objects.requireNonNull(action); >> while (hasNext()) >> action.accept(next()); >> >> Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. >> >> The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. >> >> New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > review suggestion - simplify test Thank you everyone for the reviews and the suggestions. ------------- PR: https://git.openjdk.org/jdk/pull/11154 From jpai at openjdk.org Sat Nov 19 00:59:25 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 19 Nov 2022 00:59:25 GMT Subject: Integrated: 8292317: Missing null check for Iterator.forEachRemaining implementations In-Reply-To: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> References: <-7AyI31CQGh9hFIbo8DDNMWIn9vekvbEiHHv-eDD3lk=.ca27b7b8-c565-4683-a0df-c8229bfe9540@github.com> Message-ID: On Tue, 15 Nov 2022 02:10:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to fix https://bugs.openjdk.org/browse/JDK-8292317? > > The `java.util.Iterator` has a `forEachRemaining(Consumer action)` method. As per its contract, the implementations are expected to throw a `NullPointerException` if the passed `action` is `null`. > > `java.util.Collections` has a couple of places where it wraps the passed `action` into another and passes that wrapped `action` to the underlying `java.util.Iterator`'s default `forEachRemaining` implementation which is: > > > Objects.requireNonNull(action); > while (hasNext()) > action.accept(next()); > > Since the passed `action` is now a non-null wrapper, the implementation goes ahead and advances the iterator to the next entry and invokes on the non-null `action` to carry out its action. That non-null wrapper action then calls the `null` user passed action and runs into an expected `NullPointerException`. However, at this point the iterator has already advanced and that is what the bug is. > > The commit in this PR introduces a trivial null check on the `action` very early in the call even before wrapping such an `action`. This prevents any further logic to execute if `action` is null. > > New test methods have been added to the existing test class `test/jdk/java/util/Collections/DelegatingIteratorForEachRemaining.java`. This test class was introduced in https://bugs.openjdk.org/browse/JDK-8205184 where this delegation logic was added for the `forEachRemaining` methods. These new test methods reproduce the failure and verify the fix. This pull request has now been integrated. Changeset: 906f1ca4 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/906f1ca4d7c8d156d60d591d14db4b21a0180ef2 Stats: 29 lines in 2 files changed: 28 ins; 0 del; 1 mod 8292317: Missing null check for Iterator.forEachRemaining implementations Reviewed-by: sundar, smarks ------------- PR: https://git.openjdk.org/jdk/pull/11154 From bpb at openjdk.org Sat Nov 19 01:23:21 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Sat, 19 Nov 2022 01:23:21 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v3] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 21:22:05 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Mentioned effects are not a complete list Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11218 From sspitsyn at openjdk.org Sat Nov 19 07:16:29 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 19 Nov 2022 07:16:29 GMT Subject: RFR: 8296323: JVMTI can_support_virtual_threads not available for agents loaded into running VM Message-ID: <1I_7hZCOwnCc-sMv2nqxC2_J6RJMFrvoepKYPRFQnFs=.2149fccd-7da2-4253-b569-72980d4b30a1@github.com> The can_support_virtual_thread was initially implemented as an onload capability. It is why this capability does not work for the agents loaded into running VM. The fix is to move it from `onload` to `always`capabilities list. Testing: New test is added: VirtualStartThreadTest. TBD: mach5 jvmti, jdi and tier1-6 tests. ------------- Commit messages: - simplified VirtualThreadStartTest - 8296323: JVMTI can_support_virtual_threads not available for agents loaded into running VM Changes: https://git.openjdk.org/jdk/pull/11246/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11246&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296323 Stats: 157 lines in 4 files changed: 153 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11246.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11246/head:pull/11246 PR: https://git.openjdk.org/jdk/pull/11246 From sspitsyn at openjdk.org Sat Nov 19 07:19:16 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 19 Nov 2022 07:19:16 GMT Subject: RFR: 8296323: JVMTI can_support_virtual_threads not available for agents loaded into running VM [v2] In-Reply-To: <1I_7hZCOwnCc-sMv2nqxC2_J6RJMFrvoepKYPRFQnFs=.2149fccd-7da2-4253-b569-72980d4b30a1@github.com> References: <1I_7hZCOwnCc-sMv2nqxC2_J6RJMFrvoepKYPRFQnFs=.2149fccd-7da2-4253-b569-72980d4b30a1@github.com> Message-ID: > The can_support_virtual_thread was initially implemented as an onload capability. > It is why this capability does not work for the agents loaded into running VM. > The fix is to move it from `onload` to `always`capabilities list. > > Testing: > New test is added: VirtualStartThreadTest. > TBD: mach5 jvmti, jdi and tier1-6 tests. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: roll back unintended VirtualThread.java file update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11246/files - new: https://git.openjdk.org/jdk/pull/11246/files/74d67205..71ed522f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11246&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11246&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11246.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11246/head:pull/11246 PR: https://git.openjdk.org/jdk/pull/11246 From alanb at openjdk.org Sat Nov 19 07:51:42 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 19 Nov 2022 07:51:42 GMT Subject: RFR: 8297258: Typo in `java -help` referencing -disable-@files instead of --disable-@files In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 17:57:39 GMT, Mandy Chung wrote: > I believe there is no need to update the localized versions as they will be updated in bulk toward the end of the release. @asotona - I see you integrated the change with the localized properties? Did you mean to do that? I support the next l10n update will just refresh the languages that they support but in general, we don't directly edit them. ------------- PR: https://git.openjdk.org/jdk/pull/11236 From alanb at openjdk.org Sat Nov 19 08:18:40 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 19 Nov 2022 08:18:40 GMT Subject: RFR: 8296323: JVMTI can_support_virtual_threads not available for agents loaded into running VM [v2] In-Reply-To: References: <1I_7hZCOwnCc-sMv2nqxC2_J6RJMFrvoepKYPRFQnFs=.2149fccd-7da2-4253-b569-72980d4b30a1@github.com> Message-ID: On Sat, 19 Nov 2022 07:19:16 GMT, Serguei Spitsyn wrote: >> The can_support_virtual_thread was initially implemented as an onload capability. >> It is why this capability does not work for the agents loaded into running VM. >> The fix is to move it from `onload` to `always`capabilities list. >> >> Testing: >> New test is added: VirtualStartThreadTest. >> TBD: mach5 jvmti, jdi and tier1-6 tests. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > roll back unintended VirtualThread.java file update The update to allow can_support_virtual_threads in the live phase looks okay, I'm just surprised we missed that in JDK 19. The test looks okay too but it's not a complete unit test for the VirtualThreadEvent event. It only tests the late binding agent case (which is what this bug is about). Maybe it should be extended to run with -agentlib so that it starts in the onload phase or maybe rename so that it's clear what the test is for. ------------- PR: https://git.openjdk.org/jdk/pull/11246 From alanb at openjdk.org Sat Nov 19 08:32:10 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 19 Nov 2022 08:32:10 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v2] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 21:29:50 GMT, Joe Darcy wrote: >> `@enablePreview` wasn't available when most of these tests were initially created. I changed some of to use this tag as part of other changes but didn't cover over the remaining tests that still use `@compile --enable-preview -source ${jdk.version} ...` and `@run main/othervm --enable-preview ...`. I just scanned the tests in test/jdk/java/lang/Thread/virtual and they can all be changed the same way, if you want. If you leave it then we'll just change them at the next edit in this area. > > I think I got most of those in the PR. There was a file or two I didn't update because not all the @compile/@run directives in the file used --enablePreview and the @enablePreview directive applies to all @compile and @run directives. Most of the tests in test/jdk/java/lang/Thread/virtual/ still have `@compile` and othervm, is it possible you didn't push the update with those changes? ------------- PR: https://git.openjdk.org/jdk/pull/11222 From duke at openjdk.org Sat Nov 19 10:59:49 2022 From: duke at openjdk.org (ExE Boss) Date: Sat, 19 Nov 2022 10:59:49 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v16] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 18:38:53 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Add ensureMaterializedForStackWalk kludge for AArch64 src/hotspot/cpu/aarch64/aarch64.ad line 3637: > 3635: __ nop(); > 3636: __ block_comment("call JVM_EnsureMaterializedForStackWalk (elided)"); > 3637: } else { This?should probably?have its?indentation?fixed: Suggestion: } else { src/java.base/share/classes/java/lang/Thread.java line 1622: > 1620: // The VM recognizes this method as special, so any changes to the > 1621: // name or signature require corresponding changes in > 1622: // JVM_FindScopedValueBindings(). Suggestion: /** * The VM recognizes this method as special, so any changes to the * name or signature require corresponding changes in * JVM_FindScopedValueBindings(). */ @Hidden @ForceInline ------------- PR: https://git.openjdk.org/jdk/pull/10952 From duke at openjdk.org Sat Nov 19 10:59:51 2022 From: duke at openjdk.org (ExE Boss) Date: Sat, 19 Nov 2022 10:59:51 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v15] In-Reply-To: References: Message-ID: <7OGkkIGaoN-F14YPRCl-WzugX_ZThVr-HThTDCqj5Ic=.247194ee-a343-4634-afc4-6e021b56e6d0@github.com> On Fri, 18 Nov 2022 17:27:28 GMT, Alan Bateman wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - Reviewer feedback >> - Reviewer feedback Javadoc fixes > > src/java.base/share/classes/java/lang/VirtualThread.java line 316: > >> 314: } >> 315: } >> 316: @Hidden > > Missing line break. > Suggestion: > > > @Hidden Also?include the?comment: Suggestion: /** * The VM recognizes this method as special, so any changes to the * name or signature require corresponding changes in * JVM_FindScopedValueBindings(). */ @Hidden ------------- PR: https://git.openjdk.org/jdk/pull/10952 From duke at openjdk.org Sat Nov 19 21:22:59 2022 From: duke at openjdk.org (Markus KARG) Date: Sat, 19 Nov 2022 21:22:59 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo Message-ID: Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. ------------- Commit messages: - SequenceInputStream.transferTo Changes: https://git.openjdk.org/jdk/pull/11248/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11248&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297298 Stats: 37 lines in 2 files changed: 19 ins; 7 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11248/head:pull/11248 PR: https://git.openjdk.org/jdk/pull/11248 From duke at openjdk.org Sat Nov 19 21:57:46 2022 From: duke at openjdk.org (Markus KARG) Date: Sat, 19 Nov 2022 21:57:46 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector Message-ID: There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. ------------- Commit messages: - Replacing Vector by List.of Changes: https://git.openjdk.org/jdk/pull/11249/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297299 Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11249/head:pull/11249 PR: https://git.openjdk.org/jdk/pull/11249 From prappo at openjdk.org Sat Nov 19 23:25:10 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Sat, 19 Nov 2022 23:25:10 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo In-Reply-To: References: Message-ID: <1h9dmxQyL0gvc6YYZAye00mlVuYHwwnAqsjztlMW_WE=.64e3916e-0e5d-4e20-bbfa-c27650a9d330@github.com> On Sat, 19 Nov 2022 16:36:28 GMT, Markus KARG wrote: > Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. > > To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. I might be mistaken, but that vector is not temporary: the vector and the enumeration produced from it seems to be reachable for as long as the stream is. Both the enumeration and the vector are synchronized. That synchronization might provide implicit (JMM) visibility for some stream users. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From jpai at openjdk.org Sun Nov 20 02:19:58 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 20 Nov 2022 02:19:58 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector In-Reply-To: References: Message-ID: <40wTBDaI3AYqsdvxQ0v-sbf0AoCtDwLARSLy0L4MbBI=.e5a98a27-575c-478d-829f-07aa39919f7f@github.com> On Sat, 19 Nov 2022 21:36:56 GMT, Markus KARG wrote: > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. src/java.base/share/classes/java/io/SequenceInputStream.java line 43: > 41: * on the last of the contained input streams. > 42: * > 43: * @author Arthur van Hoff Good catch. Looking at some other files in the JDK, your change here looks correct. src/java.base/share/classes/java/io/SequenceInputStream.java line 83: > 81: */ > 82: public SequenceInputStream(InputStream s1, InputStream s2) { > 83: e = Collections.enumeration(List.of(s1, s2)); Hello Markus, I think removing the `Vector` usage looks fine. The use of `List.of` in this constructor introduces a small change in behaviour of this constructor if the constructor is being passed a `null` `Inputstream`. Previously, before this change, if the first `InputStream` parameter was null this constructor would throw a `NullPointerException` (because the call to `peekNextStream()` in this constructor throws that). However, if the second `InputStream` was `null` then the constructor would return back fine. Only later when the `SequenceInputStream` was used and it was time to move to use the second `InputStream`, it would throw the `NullPointerException` (from the same `peekNextStream()`). Now, with the use of `List.of(s1, s2))`, the `NullPointerException` will get thrown early if either of these two parameters is `null`. Whether or not this change in behaviour related to `NullPointerException` is acceptable (backed by a CSR) is something that others more familiar with this area would be able to tell. But I think it may not be desirable because depending on how the application might have been using the `SequenceInputStream` instance they may not have been encountering the `NullPointerException` (for the second param) if they never read the `SequenceInputStream` completely. You could still remove the `Vector` usage from this code though, by constructing the collection differently instead of `List.of`. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From alanb at openjdk.org Sun Nov 20 07:32:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 20 Nov 2022 07:32:18 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo In-Reply-To: <1h9dmxQyL0gvc6YYZAye00mlVuYHwwnAqsjztlMW_WE=.64e3916e-0e5d-4e20-bbfa-c27650a9d330@github.com> References: <1h9dmxQyL0gvc6YYZAye00mlVuYHwwnAqsjztlMW_WE=.64e3916e-0e5d-4e20-bbfa-c27650a9d330@github.com> Message-ID: On Sat, 19 Nov 2022 23:23:07 GMT, Pavel Rappo wrote: > I might be mistaken, but that vector is not temporary: the vector and the enumeration produced from it seems to be reachable for as long as the stream is. Both the enumeration and the vector are synchronized. That synchronization might provide implicit (JMM) visibility for some stream users. I suspect you meant this comment for PR11249 rather than this one. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From alanb at openjdk.org Sun Nov 20 07:47:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 20 Nov 2022 07:47:21 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo In-Reply-To: References: Message-ID: On Sat, 19 Nov 2022 16:36:28 GMT, Markus KARG wrote: > Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. > > To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. src/java.base/share/classes/java/io/SequenceInputStream.java line 245: > 243: public long transferTo(OutputStream out) throws IOException { > 244: Objects.requireNonNull(out, "out"); > 245: if (getClass() == SequenceInputStream.class) { For BIS we had to restrict optimizations to direct usages because that class exposes its internals to subclasses via protected fields. We don't have this with SIS. On the other hand, SIS is non-final, dates from JDK 1.0, so we have to assume there are "transferTo unaware" subclasses that override the read methods to intercept all access. So I think being conservative and checking for subclassing is right. It doesn't prevent it being relaxed in the future. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From alanb at openjdk.org Sun Nov 20 07:59:17 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 20 Nov 2022 07:59:17 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector In-Reply-To: References: Message-ID: On Sat, 19 Nov 2022 21:36:56 GMT, Markus KARG wrote: > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. Jai is correct, this constructor appears to have tolerated null in the second parameter since JDK 1.0 so we need to proceed with care. The SIS constructor that takes an Enumeration is similar in that it only throws NPE if the first element is null, it probably should have taken a defensive copy but that can't be changed now as there may be lazy implementations in the wild that depend on existing behavior. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 09:07:21 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 09:07:21 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: Message-ID: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: allowing s2 to be null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11249/files - new: https://git.openjdk.org/jdk/pull/11249/files/3495a8b2..b6ccec20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11249/head:pull/11249 PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 09:07:21 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 09:07:21 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 07:56:59 GMT, Alan Bateman wrote: > Jai is correct, this constructor appears to have tolerated null in the second parameter since JDK 1.0 so we need to proceed with care. I have fixe this in https://github.com/openjdk/jdk/pull/11249/commits/b6ccec209f3989ca37ac15585d27e28c2dddfb14, so it still uses `List.of` but keeps the historic behavior. I wonder if we shouldn't change the Javadocs so they clearly tell the reader that `s2` MAY be `null`? ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 09:07:22 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 09:07:22 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: <40wTBDaI3AYqsdvxQ0v-sbf0AoCtDwLARSLy0L4MbBI=.e5a98a27-575c-478d-829f-07aa39919f7f@github.com> References: <40wTBDaI3AYqsdvxQ0v-sbf0AoCtDwLARSLy0L4MbBI=.e5a98a27-575c-478d-829f-07aa39919f7f@github.com> Message-ID: On Sun, 20 Nov 2022 02:16:02 GMT, Jaikiran Pai wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> allowing s2 to be null > > src/java.base/share/classes/java/io/SequenceInputStream.java line 83: > >> 81: */ >> 82: public SequenceInputStream(InputStream s1, InputStream s2) { >> 83: e = Collections.enumeration(List.of(s1, s2)); > > Hello Markus, > I think removing the `Vector` usage looks fine. The use of `List.of` in this constructor introduces a small change in behaviour of this constructor if the constructor is being passed a `null` `Inputstream`. > > Previously, before this change, if the first `InputStream` parameter was null this constructor would throw a `NullPointerException` (because the call to `peekNextStream()` in this constructor throws that). However, if the second `InputStream` was `null` then the constructor would return back fine. Only later when the `SequenceInputStream` was used and it was time to move to use the second `InputStream`, it would throw the `NullPointerException` (from the same `peekNextStream()`). > > Now, with the use of `List.of(s1, s2))`, the `NullPointerException` will get thrown early if either of these two parameters is `null`. > > Whether or not this change in behaviour related to `NullPointerException` is acceptable (backed by a CSR) is something that others more familiar with this area would be able to tell. But I think it may not be desirable because depending on how the application might have been using the `SequenceInputStream` instance they may not have been encountering the `NullPointerException` (for the second param) if they never read the `SequenceInputStream` completely. > > > You could still remove the `Vector` usage from this code though, by constructing the collection differently instead of `List.of`. Thank you for this quick review and bringing up this topic! I will follow-up on this in the below opened by @AlanBateman. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 09:18:18 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 09:18:18 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> Message-ID: <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> On Sun, 20 Nov 2022 09:07:21 GMT, Markus KARG wrote: >> There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > allowing s2 to be null src/java.base/share/classes/java/io/SequenceInputStream.java line 82: > 80: * @param s2 the second input stream to read. > 81: */ > 82: public SequenceInputStream(InputStream s1, InputStream s2) { BTW, what is your opinion @jaikiran and @AlanBateman: We could simplify the 2-arg constructor by calling `this(...)` instead of repeating the 1-arg constructor's implementation here. Is that a *preferred* or a *disliked* pattern in OpenJDK? ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 09:32:26 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 09:32:26 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 07:45:11 GMT, Alan Bateman wrote: >> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. >> >> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. > > src/java.base/share/classes/java/io/SequenceInputStream.java line 245: > >> 243: public long transferTo(OutputStream out) throws IOException { >> 244: Objects.requireNonNull(out, "out"); >> 245: if (getClass() == SequenceInputStream.class) { > > For BIS we had to restrict optimizations to direct usages because that class exposes its internals to subclasses via protected fields. We don't have this with SIS. On the other hand, SIS is non-final, dates from JDK 1.0, so we have to assume there are "transferTo unaware" subclasses that override the read methods to intercept all access. So I think being conservative and checking for subclassing is right. It doesn't prevent it being relaxed in the future. Exactly what I had in mind when authoring this code change. :-) ------------- PR: https://git.openjdk.org/jdk/pull/11248 From duke at openjdk.org Sun Nov 20 09:41:47 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 09:41:47 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2] In-Reply-To: References: Message-ID: > Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. > > To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: fixed bug number ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11248/files - new: https://git.openjdk.org/jdk/pull/11248/files/7d63db24..22d99ba0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11248&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11248&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11248.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11248/head:pull/11248 PR: https://git.openjdk.org/jdk/pull/11248 From duke at openjdk.org Sun Nov 20 09:41:48 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 09:41:48 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo In-Reply-To: References: <1h9dmxQyL0gvc6YYZAye00mlVuYHwwnAqsjztlMW_WE=.64e3916e-0e5d-4e20-bbfa-c27650a9d330@github.com> Message-ID: On Sun, 20 Nov 2022 07:30:15 GMT, Alan Bateman wrote: > I might be mistaken, but that vector is not temporary: the vector and the enumeration produced from it seems to be reachable for as long as the stream is. Both the enumeration and the vector are synchronized. That synchronization might provide implicit (JMM) visibility for some stream users. I do not see that this behavior was intended by the original author of SIS, or that an existing application could be depending on that behavior. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From duke at openjdk.org Sun Nov 20 09:51:27 2022 From: duke at openjdk.org (Jens Lidestrom) Date: Sun, 20 Nov 2022 09:51:27 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 20 Nov 2022 09:14:32 GMT, Markus KARG wrote: >> Markus KARG has updated the pull request incrementally with one additional commit since the last revision: >> >> allowing s2 to be null > > src/java.base/share/classes/java/io/SequenceInputStream.java line 82: > >> 80: * @param s2 the second input stream to read. >> 81: */ >> 82: public SequenceInputStream(InputStream s1, InputStream s2) { > > BTW, what is your opinion @jaikiran and @AlanBateman: We could simplify the 2-arg constructor by calling `this(...)` instead of repeating the 1-arg constructor's implementation here. Is that a *preferred* or a *disliked* pattern in OpenJDK? The updated code now changes the behaviour in the other direction: Previously, if `s2` was null a NPE was thrown in `peekNextStream` when `s1` was exhausted. In the current code, `s2` is silently ignored if it is null. A safer alternative that preserves the behaviour of nulls seems to be the replace `List.of` with `Arrays.asList`. These subtle changes in behaviour demonstrates the problem with even trivial updates to legacy code... ------------- PR: https://git.openjdk.org/jdk/pull/11249 From prappo at openjdk.org Sun Nov 20 11:48:19 2022 From: prappo at openjdk.org (Pavel Rappo) Date: Sun, 20 Nov 2022 11:48:19 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo In-Reply-To: References: <1h9dmxQyL0gvc6YYZAye00mlVuYHwwnAqsjztlMW_WE=.64e3916e-0e5d-4e20-bbfa-c27650a9d330@github.com> Message-ID: On Sun, 20 Nov 2022 07:30:15 GMT, Alan Bateman wrote: > > I might be mistaken, but that vector is not temporary: the vector and the enumeration produced from it seems to be reachable for as long as the stream is. Both the enumeration and the vector are synchronized. That synchronization might provide implicit (JMM) visibility for some stream users. > > I suspect you meant this comment for PR11249 rather than this one. Correct and sorry for the noise. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From duke at openjdk.org Sun Nov 20 12:09:17 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 12:09:17 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 20 Nov 2022 09:47:35 GMT, Jens Lidestrom wrote: >> src/java.base/share/classes/java/io/SequenceInputStream.java line 82: >> >>> 80: * @param s2 the second input stream to read. >>> 81: */ >>> 82: public SequenceInputStream(InputStream s1, InputStream s2) { >> >> BTW, what is your opinion @jaikiran and @AlanBateman: We could simplify the 2-arg constructor by calling `this(...)` instead of repeating the 1-arg constructor's implementation here. Is that a *preferred* or a *disliked* pattern in OpenJDK? > > The updated code now changes the behaviour in the other direction: > > In the original code, if `s2` was null a NPE was thrown in `peekNextStream` when `s1` was exhausted. > > In the current code, `s2` is silently ignored if it is null. > > A safer alternative that preserves the behaviour of nulls seems to be the replace `List.of` with `Arrays.asList`. > > These subtle changes in behaviour demonstrates the problem with even trivial updates to legacy code... It depends on *how far* we want to align the behavior. I do see a benefit in accepting `s2` being `null`. I do not see a benefit in throwing NPE at a later time. Why should an application want to expect that? ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 13:10:18 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 13:10:18 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 20 Nov 2022 12:06:55 GMT, Markus KARG wrote: >> The updated code now changes the behaviour in the other direction: >> >> In the original code, if `s2` was null a NPE was thrown in `peekNextStream` when `s1` was exhausted. >> >> In the current code, `s2` is silently ignored if it is null. >> >> A safer alternative that preserves the behaviour of nulls seems to be the replace `List.of` with `Arrays.asList`. >> >> These subtle changes in behaviour demonstrates the problem with even trivial updates to legacy code... > > It depends on *how far* we want to align the behavior. I do see a benefit in accepting `s2` being `null`. I do not see a benefit in throwing NPE at a *later* time. Why should an application want to expect that? I do understand your opinion but I think that backwards compatibility also should have limits, and in this particular case I would say such a limit is clearly reached. Otherwise we must not replace Vector at all, because someone could actually rely on the synchronization, also. @AlanBateman WDYT? ------------- PR: https://git.openjdk.org/jdk/pull/11249 From alanb at openjdk.org Sun Nov 20 15:25:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 20 Nov 2022 15:25:04 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 20 Nov 2022 13:06:40 GMT, Markus KARG wrote: > @AlanBateman WDYT? The long standing and undocumented behavior is unfortunate. I don't think the 1-arg constructor is fixable while still allowing for lazy behavior. So I think the only thing we can do is document the existing behavior that a null element in the enumeration will lead to read or close throwing NPE at a later time. For the 2-arg constructor then we need to be cautious. This is very old API and we have to assume the phenomenon that is Hyrum's Law. You may be right that nobody can reasonably depend on the current behavior but I think it would need a survey to inform the discussion. I can't tell if this PR was intended to rehabilitate SequenceInputStream or just a reaction to seeing that it uses Vector. If the latter then you could just change it to: var list = new ArrayList(); list.add(s1); list.add(s2); e = Collections.enumeration(list); peekNextStream(); and preserve the existing behavior. While SequenceInputStream may be legacy I guess it would be interesting to get some idea of usage or usages that use something better in libraries. Maybe there is a case for InputStream to have a concat method for example. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From weijun at openjdk.org Sun Nov 20 15:41:25 2022 From: weijun at openjdk.org (Weijun Wang) Date: Sun, 20 Nov 2022 15:41:25 GMT Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v5] In-Reply-To: <5G907msMRcfWwG4y8u9u9wQq5oNGWuGFJGk7Bm46RN8=.a1c914ba-aaa0-46b3-b2dd-6b27aff4a389@github.com> References: <5G907msMRcfWwG4y8u9u9wQq5oNGWuGFJGk7Bm46RN8=.a1c914ba-aaa0-46b3-b2dd-6b27aff4a389@github.com> Message-ID: On Sun, 20 Nov 2022 06:27:32 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional commit since the last revision: > > Modify as reviews. `codomain`, `VerifierCodeSource`, `isSigningRelated`, and `getUnsignedCS` also used nowhere. ------------- PR: https://git.openjdk.org/jdk/pull/11072 From lbourges at openjdk.org Sun Nov 20 15:58:36 2022 From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=) Date: Sun, 20 Nov 2022 15:58:36 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v18] In-Reply-To: References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com> Message-ID: <2xFKxxHRvlY2Pqqi4iMHiNrkfcvcyUTFcHw9xCmP6VA=.13533b01-a0e2-4446-9787-81a5a4f0037d@github.com> On Wed, 9 Nov 2022 21:06:50 GMT, iaroslavski wrote: >> Sorting: >> >> - adopt radix sort for sequential and parallel sorts on int/long/float/double arrays (almost random and length > 6K) >> - fix tryMergeRuns() to better handle case when the last run is a single element >> - minor javadoc and comment changes >> >> Testing: >> - add new data inputs in tests for sorting >> - add min/max/infinity values to float/double testing >> - add tests for radix sort > > iaroslavski has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) > > * Fixed microbenchmarking tests Here are latest results on my ubuntu 20.04 build (openjdk20), i7-6820hk, fixed freq at 2.7ghz: https://jmh.morethan.io/?sources=https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/221120/micro_java_util_ArraysSort_jdk20-ref/jmh-result.json,https://raw.githubusercontent.com/bourgesl/bourgesl.github.io/master/jdk-jmh-arraysort/221120/micro_java_util_ArraysSort_dpqs2211/jmh-result.json It wins! ------------- PR: https://git.openjdk.org/jdk/pull/3938 From duke at openjdk.org Sun Nov 20 16:44:33 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 16:44:33 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v3] In-Reply-To: References: Message-ID: > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Alan's Proposal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11249/files - new: https://git.openjdk.org/jdk/pull/11249/files/b6ccec20..9c902512 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=01-02 Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11249/head:pull/11249 PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 16:49:13 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 16:49:13 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v4] In-Reply-To: References: Message-ID: > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: Jens' Proposal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11249/files - new: https://git.openjdk.org/jdk/pull/11249/files/9c902512..9b3fe93d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11249/head:pull/11249 PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 16:51:18 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 16:51:18 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 20 Nov 2022 15:21:31 GMT, Alan Bateman wrote: >> @AlanBateman WDYT? > >> @AlanBateman WDYT? > > The long standing and undocumented behavior is unfortunate. I don't think the 1-arg constructor is fixable while still allowing for lazy behavior. So I think the only thing we can do is document the existing behavior that a null element in the enumeration will lead to read or close throwing NPE at a later time. For the 2-arg constructor then we need to be cautious. This is very old API and we have to assume the phenomenon that is Hyrum's Law. You may be right that nobody can reasonably depend on the current behavior but I think it would need a survey to inform the discussion. I can't tell if this PR was intended to rehabilitate SequenceInputStream or just a reaction to seeing that it uses Vector. If the latter then you could just change it to: > > var list = new ArrayList(); > list.add(s1); > list.add(s2); > e = Collections.enumeration(list); > peekNextStream(); > > and preserve the existing behavior. > > While SequenceInputStream may be legacy I guess it would be interesting to get some idea of usage or usages that use something better in libraries. Maybe there is a case for InputStream to have a concat method for example. Indeed my intention solely is to get rid of `Vector`, so I am fine with keeping a low profile and being full backwards compatible. I assume SIS is seldomly used, so opening a can of warms is not worth it (I think). I am perfectly happy with your proposal, but for the sake of brevity I'd rather go with a shorter way of doing the pretty same: ```this(Collections.enumeration(Arrays.asList(s1, s2))``` Are we all fine with that? Otherwise I'd switch this PR back to Alan`s proposal. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 17:01:18 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 17:01:18 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 20 Nov 2022 16:49:16 GMT, Markus KARG wrote: >>> @AlanBateman WDYT? >> >> The long standing and undocumented behavior is unfortunate. I don't think the 1-arg constructor is fixable while still allowing for lazy behavior. So I think the only thing we can do is document the existing behavior that a null element in the enumeration will lead to read or close throwing NPE at a later time. For the 2-arg constructor then we need to be cautious. This is very old API and we have to assume the phenomenon that is Hyrum's Law. You may be right that nobody can reasonably depend on the current behavior but I think it would need a survey to inform the discussion. I can't tell if this PR was intended to rehabilitate SequenceInputStream or just a reaction to seeing that it uses Vector. If the latter then you could just change it to: >> >> var list = new ArrayList(); >> list.add(s1); >> list.add(s2); >> e = Collections.enumeration(list); >> peekNextStream(); >> >> and preserve the existing behavior. >> >> While SequenceInputStream may be legacy I guess it would be interesting to get some idea of usage or usages that use something better in libraries. Maybe there is a case for InputStream to have a concat method for example. > > Indeed my intention solely is to get rid of `Vector`, so I am fine with keeping a low profile and being full backwards compatible. I assume SIS is seldomly used, so opening a can of warms is not worth it (I think). I am perfectly happy with your proposal, but for the sake of brevity I'd rather go with a shorter way of doing the pretty same: > ```this(Collections.enumeration(Arrays.asList(s1, s2))``` > Are we all fine with that? Otherwise I'd switch this PR back to Alan`s proposal. N.B.: Regarding usage numbers, I will do a quick poll on Twitter. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Sun Nov 20 17:41:28 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 20 Nov 2022 17:41:28 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5] In-Reply-To: References: Message-ID: > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Jens' Proposal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11249/files - new: https://git.openjdk.org/jdk/pull/11249/files/9b3fe93d..2e957354 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11249/head:pull/11249 PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Mon Nov 21 00:29:34 2022 From: duke at openjdk.org (pandaapo) Date: Mon, 21 Nov 2022 00:29:34 GMT Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v6] In-Reply-To: References: Message-ID: <51Ppy4DuBRLKLVx791XoBw0QMuafO7TWBEDtfIMVU-g=.2daad272-8b8f-4f35-91d2-5337ea2fc74b@github.com> > The cache named `signerToCodeSource` in `JarVerifier` is never used now. pandaapo has updated the pull request incrementally with one additional commit since the last revision: Modify as review and update copyright. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11072/files - new: https://git.openjdk.org/jdk/pull/11072/files/a8fb419c..fb933804 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11072&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11072&range=04-05 Stats: 92 lines in 3 files changed: 0 ins; 90 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11072.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11072/head:pull/11072 PR: https://git.openjdk.org/jdk/pull/11072 From duke at openjdk.org Mon Nov 21 00:32:26 2022 From: duke at openjdk.org (pandaapo) Date: Mon, 21 Nov 2022 00:32:26 GMT Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v5] In-Reply-To: References: <5G907msMRcfWwG4y8u9u9wQq5oNGWuGFJGk7Bm46RN8=.a1c914ba-aaa0-46b3-b2dd-6b27aff4a389@github.com> Message-ID: On Sun, 20 Nov 2022 15:37:24 GMT, Weijun Wang wrote: > `codomain`, `VerifierCodeSource`, `isSigningRelated`, and `getUnsignedCS` also used nowhere. Thanks. I think your `codomain` must mean `csdomain`. ------------- PR: https://git.openjdk.org/jdk/pull/11072 From ethan at mccue.dev Mon Nov 21 01:02:49 2022 From: ethan at mccue.dev (Ethan McCue) Date: Sun, 20 Nov 2022 20:02:49 -0500 Subject: What are the policies for internal modules? Message-ID: There are some modules like jdk.internal.le which contain no publicly exported packages. In some of the experimentation we are doing, We want to use the jdk.internal.org.jline.utils.Levenshtien class from jdk.compiler. Mechanically, we can do this without creating any new modules by adding a qualified export of the utils package to jdk.compiler. We could also make a brand new, tiny pointless module called jdk.internal.levenshtien. That would be the "cleanest" approach, but only if we didn't consider the existence of the internal modules to be public API. So that's my general question - what is the bar for making a new internal module, and is the set of internal modules subject to backwards compatibility concerns? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dholmes at openjdk.org Mon Nov 21 01:14:26 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Nov 2022 01:14:26 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 11:44:32 GMT, Adam Sotona wrote: > tools/launcher/ArgsFileTest.java was working because it didn't contain any test with --disable- at files option verifying VM really starts What about the killswitch test ?? ------------- PR: https://git.openjdk.org/jdk/pull/11183 From dholmes at openjdk.org Mon Nov 21 01:35:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Nov 2022 01:35:20 GMT Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote: > Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc. Looks okay. Thanks for doing this before the end-of-release updates! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11223 From dholmes at openjdk.org Mon Nov 21 01:50:20 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 21 Nov 2022 01:50:20 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: <5OuxSKr8ZPZuCE9SOk2yCEaSO7nJ96pz1yx-yFbHixQ=.c1dfd974-8b9a-475a-b04a-47eac0c82dd9@github.com> On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file Looks good. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11023 From jwaters at openjdk.org Mon Nov 21 02:45:19 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 21 Nov 2022 02:45:19 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 06:33:00 GMT, Kim Barrett wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert to using simpler solution similar to the original 8274980 > > src/hotspot/share/utilities/globalDefinitions.hpp line 50: > >> 48: >> 49: #ifndef ATTRIBUTE_ALIGNED >> 50: #define ATTRIBUTE_ALIGNED(x) alignas(x) > > HotSpot Group has not discussed or approved use of `alignas` - see https://bugs.openjdk.org/browse/JDK-8250269. This is another change that is independent of most of the rest of this PR, and should be dealt with separately. The various MSVC-conditional direct uses of `_declspec(align(N))` should probably currently be using `ATTRIBUTE_ALIGNED`. Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? I've read through 8250269 briefly and unlike the issues that come with C++ attributes, alignas looks relatively straightforward to switch to, without much effect on existing code. Seems like a bit of a waste to leave the JBS entry sitting on the shelf to me > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED. The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing) ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jpai at openjdk.org Mon Nov 21 06:34:13 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 21 Nov 2022 06:34:13 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5] In-Reply-To: References: Message-ID: <_-8C7yBI3aq7qJ_KJGYL3kMX7Hm8wWGoKfiojRgqjIE=.bf9f2684-e0e8-4bd7-9ef4-26a77a4aa525@github.com> On Sun, 20 Nov 2022 17:41:28 GMT, Markus KARG wrote: >> There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. > > Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > Jens' Proposal Thank you Markus for the changes. The latest version in `2e957354` looks fine to me. While we are at it, would you be willing to change the member variables `e` to `private final` and the `in` to `private`? From what I can see, I don't see any other class accessing these package private fields. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From thartmann at openjdk.org Mon Nov 21 06:57:17 2022 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 21 Nov 2022 06:57:17 GMT Subject: RFR: JDK-8296945: PublicMethodsTest is slow due to dependency verification with debug builds In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 09:19:26 GMT, Matthias Baesken wrote: > As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch off VerifyDependencies in this test because of slow machines when (fast)debug builds are used, the test sometimes times out after the [JDK-8266074](https://bugs.openjdk.org/browse/JDK-8266074) Vtable-based CHA implementation implementation came in. > Same has been done for other tests with similar issues, see 8268227: java/foreign/TestUpcall.java still times out . Looks good to me too. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.org/jdk/pull/11234 From jpai at openjdk.org Mon Nov 21 06:58:49 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 21 Nov 2022 06:58:49 GMT Subject: RFR: 8296672: Implementation of Virtual Threads (Second Preview) In-Reply-To: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com> References: <3xn4pJmY7VbtV47kZiR7L3c6-C-0vR5fVQ-y-SXlSx0=.56d8f675-e215-4457-b48e-13babb0d7ae7@github.com> Message-ID: <_fHtpizL7xGwZQtvmKA5histBSksY7rnidfUak1iQw8=.0d879e07-3088-4c8c-9195-b067736db13e@github.com> On Fri, 18 Nov 2022 09:57:39 GMT, Alan Bateman wrote: > JEP 436 proposes a second preview of Virtual Threads to allow time for more feedback and to get more experience with this feature. There is no change in direction, no API changes, and no bulk update of the implementation. For the implementation, there has been ~35 changes/issues pushed to the main line, and a few more coming. For this PR, we just bump the JEP number used by javadoc from 425 to 436. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11235 From mbaesken at openjdk.org Mon Nov 21 07:41:17 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 21 Nov 2022 07:41:17 GMT Subject: RFR: JDK-8296945: PublicMethodsTest is slow due to dependency verification with debug builds In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 09:19:26 GMT, Matthias Baesken wrote: > As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch off VerifyDependencies in this test because of slow machines when (fast)debug builds are used, the test sometimes times out after the [JDK-8266074](https://bugs.openjdk.org/browse/JDK-8266074) Vtable-based CHA implementation implementation came in. > Same has been done for other tests with similar issues, see 8268227: java/foreign/TestUpcall.java still times out . Hi Mandy and Tobias, thanks for the reviews ! ------------- PR: https://git.openjdk.org/jdk/pull/11234 From mbaesken at openjdk.org Mon Nov 21 07:45:11 2022 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 21 Nov 2022 07:45:11 GMT Subject: Integrated: JDK-8296945: PublicMethodsTest is slow due to dependency verification with debug builds In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 09:19:26 GMT, Matthias Baesken wrote: > As discussed in https://bugs.openjdk.org/browse/JDK-8296945 , let us switch off VerifyDependencies in this test because of slow machines when (fast)debug builds are used, the test sometimes times out after the [JDK-8266074](https://bugs.openjdk.org/browse/JDK-8266074) Vtable-based CHA implementation implementation came in. > Same has been done for other tests with similar issues, see 8268227: java/foreign/TestUpcall.java still times out . This pull request has now been integrated. Changeset: bcc6b12b Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/bcc6b12b711a9c5007d963123fb38a7e72aaf8e5 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8296945: PublicMethodsTest is slow due to dependency verification with debug builds Reviewed-by: mchung, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/11234 From alanb at openjdk.org Mon Nov 21 07:46:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 07:46:23 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 20 Nov 2022 16:58:56 GMT, Markus KARG wrote: >> Indeed my intention solely is to get rid of `Vector`, so I am fine with keeping a low profile and being full backwards compatible. I assume SIS is seldomly used, so opening a can of warms is not worth it (I think). I am perfectly happy with your proposal, but for the sake of brevity I'd rather go with a shorter way of doing the pretty same: >> ```this(Collections.enumeration(Arrays.asList(s1, s2)))``` >> Are we all fine with that? Otherwise I'd switch this PR back to Alan's proposal. > > N.B.: Regarding usage numbers, I will do a quick poll on Twitter. > Indeed my intention solely is to get rid of `Vector`, so I am fine with keeping a low profile and being full backwards compatible. I assume SIS is seldomly used, so opening a can of warms is not worth it (I think). If you have the cycles then collecting data on usages and finding examples where the constructor is called with a second parameter of null would be useful. It's a lot of work to do that of course. The changes in update 2e957354 look okay, I can't immediately see any behavior change with that version. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Mon Nov 21 07:50:23 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 21 Nov 2022 07:50:23 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5] In-Reply-To: <_-8C7yBI3aq7qJ_KJGYL3kMX7Hm8wWGoKfiojRgqjIE=.bf9f2684-e0e8-4bd7-9ef4-26a77a4aa525@github.com> References: <_-8C7yBI3aq7qJ_KJGYL3kMX7Hm8wWGoKfiojRgqjIE=.bf9f2684-e0e8-4bd7-9ef4-26a77a4aa525@github.com> Message-ID: <9sxjlLkNX3QVyDUof1kVpCEw6P1ZpYf18EHGs_RtO2c=.7296051d-52c4-482b-82fa-9220489a9eee@github.com> On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote: > While we are at it, would you be willing to change the member variables `e` to `private final` and the `in` to `private`? From what I can see, I don't see any other class accessing these package private fields. Good catch, will do later today. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From asotona at openjdk.org Mon Nov 21 08:03:25 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 21 Nov 2022 08:03:25 GMT Subject: RFR: 8293041: --disable-@files option doesn't work and cause an error In-Reply-To: References: Message-ID: <-7k1E_KWOYEcNke8VxLTvT895Kzl74ezZrrXXBw2i6s=.c663bf2b-e5d6-440f-8e05-5675085a1425@github.com> On Mon, 21 Nov 2022 01:11:55 GMT, David Holmes wrote: > > tools/launcher/ArgsFileTest.java was working because it didn't contain any test with --disable- at files option verifying VM really starts > > What about the killswitch test ?? KillSwitch test did not construct valid command line, it didn't expect VM to start correctly and so it didn't test the VM exit value. KillSwitch test just checked expanded options presence in the debug log (before passing to ParseArguments). I've added one simple test composing valid cmd line 'java --disable- at files --version' and verifying successful VM execution. ------------- PR: https://git.openjdk.org/jdk/pull/11183 From Alan.Bateman at oracle.com Mon Nov 21 08:19:23 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Nov 2022 08:19:23 +0000 Subject: What are the policies for internal modules? In-Reply-To: References: Message-ID: On 21/11/2022 01:02, Ethan McCue wrote: > There are some modules like jdk.internal.le which contain no > publicly?exported packages. In some of the experimentation we are > doing, We want to use the > jdk.internal.org.jline.utils.Levenshtien?class from jdk.compiler. > > Mechanically, we can do this without creating any new modules by > adding a qualified export of the utils package to jdk.compiler. We > could also make a brand new, tiny pointless module called > jdk.internal.levenshtien. That would be the "cleanest" approach, but > only if we didn't consider the existence of the internal modules to be > public API. > > So that's?my general question - what is the bar for making a new > internal module, and is the set of internal modules subject to > backwards compatibility concerns? There aren't many compatibility constraints on jdk.internal modules. Assume they can change or be removed in any release. It's important they don't export any packages to all modules, otherwise they cease to be "internal".? Also if they provide services then the name of the module may be something that users of jlink may become dependent on, so we have to be careful there. A general point is that we don't want the JDK to backslide to a big ball of mud. We put a lot of effort several years ago to de-tangle the libraries so it would be disappointing see jdk.compiler, with no interest in line editing, add a dependency on jdk.internal.le so that it can make use of one of utility classes. So I don't think we should do that. Can you say a bit more about what you are doing? Is this just a method to compute the Levenshtein distance between two strings? I assume you can just implement that in jdk.compiler without touching the module graph. It might be useful to get some sense on how common fuzzy matching is in the eco system to see if there is any merit to exposing APIs for this. -Alan From pminborg at openjdk.org Mon Nov 21 11:00:13 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 11:00:13 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded Message-ID: This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. Design choices in this PR: There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code. On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. ------------- Commit messages: - Guard usages of DirectBuffer::address Changes: https://git.openjdk.org/jdk/pull/11260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296024 Stats: 277 lines in 26 files changed: 191 ins; 4 del; 82 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 21 11:31:16 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 11:31:16 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code. > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. src/java.base/share/classes/java/nio/Buffer.java line 785: > 783: static final JavaNioAccess.SessionAcquisition NO_OP_CLOSE = new JavaNioAccess.SessionAcquisition() { > 784: @Override > 785: public void close() throws RuntimeException {} The throws RuntimeException is not needed here. Also would it be possible to reflow the comment to avoid the wildly long line. src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 161: > 159: > 160: @Override > 161: void close() throws RuntimeException; You can drop throws RuntimeEXcepton here too. src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 38: > 36: // try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) { > 37: // performOperation(bb.address()); > 38: // } This comment is very messy and needs to be cleaned up. src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252: > 250: try { > 251: // 'dst' is guaranteed not to be associated with a closeable session. > 252: // Hence, there is no need for acquiring any session. This comment is will be confusing to anyone reading this code. Is this really needed? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 21 11:36:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 11:36:23 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 10:53:07 GMT, Per Minborg wrote: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code. > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. src/java.base/share/classes/java/util/zip/Adler32.java line 102: > 100: return; > 101: if (buffer.isDirect()) { > 102: try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) { We need to find something better than "sessionAcquisition", it looks very messy at all these use sites. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 11:40:23 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 11:40:23 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:29:07 GMT, Alan Bateman wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code. >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252: > >> 250: try { >> 251: // 'dst' is guaranteed not to be associated with a closeable session. >> 252: // Hence, there is no need for acquiring any session. > > This comment is will be confusing to anyone reading this code. Is this really needed? The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 12:09:20 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 12:09:20 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:32:35 GMT, Alan Bateman wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code. >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > src/java.base/share/classes/java/util/zip/Adler32.java line 102: > >> 100: return; >> 101: if (buffer.isDirect()) { >> 102: try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) { > > We need to find something better than "sessionAcquisition", it looks very messy at all these use sites. Eventually, I hope most of them will be named `_`. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 21 12:09:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 12:09:20 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 11:36:44 GMT, Per Minborg wrote: >> src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java line 252: >> >>> 250: try { >>> 251: // 'dst' is guaranteed not to be associated with a closeable session. >>> 252: // Hence, there is no need for acquiring any session. >> >> This comment is will be confusing to anyone reading this code. Is this really needed? > > The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them. I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 12:20:01 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 12:20:01 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v2] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. These cases have been documented in the code. > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Cleanup after comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/23a6fd14..9fafafac Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=00-01 Stats: 50 lines in 20 files changed: 6 ins; 0 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Mon Nov 21 12:20:05 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 21 Nov 2022 12:20:05 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v2] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 12:03:35 GMT, Per Minborg wrote: >> src/java.base/share/classes/java/util/zip/Adler32.java line 102: >> >>> 100: return; >>> 101: if (buffer.isDirect()) { >>> 102: try (var sessionAcquisition = NIO_ACCESS.acquireSessionAsAutoCloseable(buffer)) { >> >> We need to find something better than "sessionAcquisition", it looks very messy at all these use sites. > > Eventually, I hope most of them will be named `_`. maybe just `bufferLock` and and just `acquireBuffer` ? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 21 12:21:56 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 12:21:56 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v2] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 12:16:01 GMT, Maurizio Cimadamore wrote: >> Eventually, I hope most of them will be named `_`. > > maybe just `bufferLock` and and just `acquireBuffer` ? Would it be possible to re-examine acquireSession returning Runnable and acquireSessionAsAutoCloseable returning AutoCloseable. The naming is awkward at most of the use sites and maybe we can do better. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 12:37:33 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 12:37:33 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v3] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/9fafafac..9fcf2bb3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=01-02 Stats: 18 lines in 6 files changed: 4 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From jlaskey at openjdk.org Mon Nov 21 12:47:45 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 12:47:45 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: <6ZJz5F38mg_IpViGodZp7sCIgD06ELqefF89iIzK-IE=.0695a46a-613d-44d9-9a10-33c2e39b5b4a@github.com> On Fri, 18 Nov 2022 23:05:30 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Typo > > src/java.base/share/classes/java/lang/template/StringProcessor.java line 49: > >> 47: * @implNote Implementations using {@link StringProcessor} are equivalent to implementations using >> 48: * {@code TemplateProcessor} or {@code ValidatingProcessor}, >> 49: * however the dominance of {@link String} producing template processors supercedes the redundancy. > > Amusing to read... > Perhaps just, "however, StringProcessor is clearer and easier to understand". Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 115: > >> 113: public interface StringTemplate { >> 114: /** >> 115: * Returns s list of fragment literals for this {@link StringTemplate}. > > Suggestion: > > * Returns a list of fragment literals for this {@link StringTemplate}. Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 155: > >> 153: * For better visibility and when practical, it is recommended that users use the >> 154: * {@link StringTemplate#STR} processor instead of invoking the >> 155: * {@link StringTemplate#interpolate()} method directly. > > Removing "users use"... > > Suggestion: > > * For better visibility and when practical, it is recommended to use the > * {@link StringTemplate#STR} processor instead of invoking the > * {@link StringTemplate#interpolate()} method. Changing > src/java.base/share/classes/java/lang/template/StringTemplate.java line 206: > >> 204: * @param stringTemplate the {@link StringTemplate} to represent >> 205: * >> 206: * @return diagnostic string representing the supplied templated string > > Suggestion: > > * @return diagnostic string representing the supplied string template Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 317: > >> 315: /** >> 316: * The {@link StringProcessor} instance conventionally used for the string interpolation >> 317: * of a supplied {@link StringTemplate}. > > Suggestion: > > * The {@link StringProcessor} instance is conventionally used for the string interpolation > * of a supplied {@link StringTemplate}. Same issue as `STR`. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 334: > >> 332: /** >> 333: * The {@link TemplateProcessor} instance conventionally used to indicate that the >> 334: * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred > > Suggestion: > > * The {@link TemplateProcessor} instance is conventionally used to indicate that the > * processing of the {@link StringTemplate} is to be deferred to a later time. Deferred Interestingly enough, someone asked me to remove the 'is'. If you leave the 'is' in it read as 'The TemplateProcessor instance is used to indicate that the' vs 'The TemplateProcessor instance used to indicate that the' which makes more sense. Maybe 'This TemplateProcessor instance is used to indicate that the'. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From pminborg at openjdk.org Mon Nov 21 12:54:17 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 12:54:17 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v3] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 12:19:21 GMT, Alan Bateman wrote: >> maybe just `bufferLock` and and just `acquireBuffer` ? > > Would it be possible to re-examine acquireSession returning Runnable and > acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better. I think it would be confusing to have overloads with the same name. The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From jlaskey at openjdk.org Mon Nov 21 12:54:52 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 12:54:52 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 23:00:49 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Typo > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 35: > >> 33: /** >> 34: * {@link StringTemplate} is the run-time representation of a string template or >> 35: * text block template in a template expression. > > Can the link to the JLS 15.8.6 be included earlier so the definition of "template expression" isn't hanging until the end of the class javadoc. Didn't know that it was positional. Will change. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From pminborg at openjdk.org Mon Nov 21 13:02:48 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 13:02:48 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: Message-ID: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rename methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/9fcf2bb3..c081b4ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=02-03 Stats: 51 lines in 20 files changed: 0 ins; 6 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From duke at openjdk.org Mon Nov 21 13:39:23 2022 From: duke at openjdk.org (ExE Boss) Date: Mon, 21 Nov 2022 13:39:23 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rename methods src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 94: > 92: * required to guarantee safety. > 93: * {@snippet lang = java: > 94: * var handler = acquireSessionOrNoOp(buffer); Suggestion: * var handler = acquireSessionOrNull(buffer, async); src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41: > 39: // An example of a guarded use of a memory address is shown here: > 40: // > 41: // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) { Suggestion: // try (var guard = NIO_ACCESS.acquireSession(bb)) { ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 13:43:21 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 13:43:21 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v5] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Cleanup static declarations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/c081b4ae..eca7c388 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=03-04 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 13:49:09 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 13:49:09 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 13:32:43 GMT, ExE Boss wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename methods > > src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41: > >> 39: // An example of a guarded use of a memory address is shown here: >> 40: // >> 41: // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) { > > Suggestion: > > // try (var guard = NIO_ACCESS.acquireSession(bb)) { Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From duke at openjdk.org Mon Nov 21 13:49:09 2022 From: duke at openjdk.org (ExE Boss) Date: Mon, 21 Nov 2022 13:49:09 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 13:43:56 GMT, Per Minborg wrote: >> src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 41: >> >>> 39: // An example of a guarded use of a memory address is shown here: >>> 40: // >>> 41: // try (var guard = NIO_ACCESS.acquireSessionAsAutoCloseable(bb)) { >> >> Suggestion: >> >> // try (var guard = NIO_ACCESS.acquireSession(bb)) { > > Are you happy with the proposed renaming now @ExE-Boss ? I think our propositions crossed in time? This?change was?missed in?commit?. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 14:02:38 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 14:02:38 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v6] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/eca7c388..a0de3bcf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=04-05 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From weijun at openjdk.org Mon Nov 21 14:02:32 2022 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 21 Nov 2022 14:02:32 GMT Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v6] In-Reply-To: <51Ppy4DuBRLKLVx791XoBw0QMuafO7TWBEDtfIMVU-g=.2daad272-8b8f-4f35-91d2-5337ea2fc74b@github.com> References: <51Ppy4DuBRLKLVx791XoBw0QMuafO7TWBEDtfIMVU-g=.2daad272-8b8f-4f35-91d2-5337ea2fc74b@github.com> Message-ID: <0ImiP6uglDLfXTD0-fnQhgXcTxXzX7uwPBea-NxT1NQ=.699d9f54-3eea-425d-97ed-872d6dc9c7c0@github.com> On Mon, 21 Nov 2022 00:29:34 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional commit since the last revision: > > Modify as review and update copyright. Looks almost complete. Just 2 small comments. src/java.base/share/classes/java/util/jar/JarVerifier.java line 330: > 328: } > 329: > 330: public Certificate[] getCerts(JarEntry entry) You might want to move the javadoc of the removed `getCerts(String)` method here. It looks there was a single javadoc for 2 methods. We should keep one. src/java.base/share/classes/java/util/jar/JarVerifier.java line 345: > 343: } > 344: > 345: public CodeSigner[] getCodeSigners(JarEntry entry) Since the 1st `getCodeSigners` is only used by the 2nd one. We can inline the 1st one into the 2nd one. ------------- PR: https://git.openjdk.org/jdk/pull/11072 From pminborg at openjdk.org Mon Nov 21 14:06:08 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 14:06:08 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v7] In-Reply-To: References: Message-ID: <85JCc27fZGJjTrQbm1vJfA6BY1KgAZ9PLlRJQgbcj3M=.1707b29d-4c0c-4f0f-9be9-acbfc341d571@github.com> > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains six commits: - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Cleanup static declarations - Rename methods - Remove comments - Cleanup after comments - Guard usages of DirectBuffer::address ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/a0de3bcf..17a72e9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 21 14:11:31 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 14:11:31 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 13:02:48 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rename methods src/java.base/share/classes/java/util/zip/Adler32.java line 105: > 103: adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem); > 104: } finally { > 105: Reference.reachabilityFence(buffer); The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible. I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 21 14:16:41 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 14:16:41 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v6] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 14:02:38 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with two additional commits since the last revision: > > - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92: > 90: * allocated from the heap. > 91: *

      > 92: * The returned NativeBuffer is guaranteed not to be asynchronously closeable. This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of asynchronously close so maybe it would best to not add this comment to these sources. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From coleenp at openjdk.org Mon Nov 21 14:17:35 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 21 Nov 2022 14:17:35 GMT Subject: RFR: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call [v3] In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 20:40:33 GMT, Coleen Phillimore wrote: >> This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. >> Tested with tier1-4, and jvmti and jdi tests locally. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > really revert the file Thanks David and Alan for the code review and all the help with the CSR and release notes. ------------- PR: https://git.openjdk.org/jdk/pull/11023 From duke at openjdk.org Mon Nov 21 14:19:05 2022 From: duke at openjdk.org (Strahinja Stanojevic) Date: Mon, 21 Nov 2022 14:19:05 GMT Subject: RFR: 8292914: Introduce a system property that enables stable names for lambda proxy classes [v4] In-Reply-To: References: Message-ID: > This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`. > Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process. > We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value. > We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html. In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified. > We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions. > We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own. > We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/. > > JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas: > > - TestStableLambdaNames$$Lambda$1/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$2/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38 > The same method in the second run generates lambdas with different names: > - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470 > > If we use the introduced flag, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38 > In the second run of the method, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470 > > We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test. Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision: Calculate stable names for lambda classes using another hash function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10024/files - new: https://git.openjdk.org/jdk/pull/10024/files/6a8f9128..dd8e592d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=02-03 Stats: 606 lines in 2 files changed: 298 ins; 308 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10024.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10024/head:pull/10024 PR: https://git.openjdk.org/jdk/pull/10024 From coleenp at openjdk.org Mon Nov 21 14:19:30 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 21 Nov 2022 14:19:30 GMT Subject: Integrated: 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call In-Reply-To: References: Message-ID: <1oVXMFWnlx-cv4MyUKu8M0mozrUReohL4Tg_HjcESUw=.81b0a9da-ed02-45a2-ae97-3380bc55474e@github.com> On Mon, 7 Nov 2022 17:07:01 GMT, Coleen Phillimore wrote: > This patch moves the acquisition of the boot class loader lock out of the JVM and into the Java function. > Tested with tier1-4, and jvmti and jdi tests locally. This pull request has now been integrated. Changeset: 5c334540 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/5c3345404d850cf01d9629b48015f1783a32bfc0 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod 8296472: Remove ObjectLocker around appendToClassPathForInstrumentation call Reviewed-by: sspitsyn, alanb, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11023 From duke at openjdk.org Mon Nov 21 14:22:07 2022 From: duke at openjdk.org (Strahinja Stanojevic) Date: Mon, 21 Nov 2022 14:22:07 GMT Subject: RFR: 8292914: Introduce a system property that enables stable names for lambda proxy classes [v5] In-Reply-To: References: Message-ID: > This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`. > Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process. > We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value. > We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html. In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified. > We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions. > We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own. > We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/. > > JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas: > > - TestStableLambdaNames$$Lambda$1/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$2/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38 > The same method in the second run generates lambdas with different names: > - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470 > > If we use the introduced flag, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38 > In the second run of the method, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470 > > We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test. Strahinja Stanojevic has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Calculate stable names for lambda classes using different hash function. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10024/files - new: https://git.openjdk.org/jdk/pull/10024/files/dd8e592d..6179915a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=03-04 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10024.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10024/head:pull/10024 PR: https://git.openjdk.org/jdk/pull/10024 From duke at openjdk.org Mon Nov 21 14:31:45 2022 From: duke at openjdk.org (Strahinja Stanojevic) Date: Mon, 21 Nov 2022 14:31:45 GMT Subject: RFR: 8292914: Introduce a system property that enables stable names for lambda proxy classes [v6] In-Reply-To: References: Message-ID: <8BsIDJsVskNiRBQUmrhmmwvByDxgoa9FfFegZ_yx8Sw=.08efeb30-3fc9-4031-9cd8-3802cb009022@github.com> > This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`. > Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process. > We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value. > We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html. In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified. > We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions. > We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own. > We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/. > > JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas: > > - TestStableLambdaNames$$Lambda$1/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$2/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38 > The same method in the second run generates lambdas with different names: > - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470 > > If we use the introduced flag, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38 > In the second run of the method, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470 > > We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test. Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision: Create stable lambda names using CRC32 hash function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10024/files - new: https://git.openjdk.org/jdk/pull/10024/files/6179915a..f5feb430 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=04-05 Stats: 82 lines in 1 file changed: 27 ins; 30 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/10024.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10024/head:pull/10024 PR: https://git.openjdk.org/jdk/pull/10024 From jlaskey at openjdk.org Mon Nov 21 13:42:15 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 13:42:15 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 22:25:22 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Typo > > src/java.base/share/classes/java/lang/template/package-info.java line 27: > >> 25: >> 26: /** >> 27: * Provides support for string templates and template processors. > > Not just support... > > String templates are provided by {@link StringTemplate} and supporting interfaces and classes. > It might also be helpful to include a link to the JLS 15.8.6 Template Expression spec. > > A brief example here (drawn from the JEP or StringTemplate would provide a good hook for the reader to get started. Will expand. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Nov 21 14:58:47 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 14:58:47 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: <4F14OGh3NmKE0zOCPRRn9FWFzDmwWZAA7Jzy1868NhY=.91b4c725-67e2-409b-ab3b-d6307159bd24@github.com> On Mon, 21 Nov 2022 12:52:42 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/template/StringTemplate.java line 35: >> >>> 33: /** >>> 34: * {@link StringTemplate} is the run-time representation of a string template or >>> 35: * text block template in a template expression. >> >> Can the link to the JLS 15.8.6 be included earlier so the definition of "template expression" isn't hanging until the end of the class javadoc. > > Didn't know that it was positional. Will change. Turns out that @jls is sensitive to its position. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From redestad at openjdk.org Mon Nov 21 14:58:49 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 21 Nov 2022 14:58:49 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 14:10:11 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Typo src/java.base/share/classes/java/util/Digits.java line 39: > 37: */ > 38: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) > 39: interface Digits { Should this be modeled as an `abstract sealed` class hierarchy instead? test/micro/org/openjdk/bench/java/lang/template/StringTemplateFMT.java line 41: > 39: /* > 40: * This benchmark measures StringTemplate.FMT FormatProcessor performance; > 41: * exactly mirroring {@link org.openjdk.bench.java.lang.StringFormat} benchmark While it's good to mirror the `StringFormat` benchmark, I think we'd see benefit from building this out to be a bit more comprehensive and for example cover `FormatConcatItem` cases. What you have here is probably good enough for first integration, though. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From pminborg at openjdk.org Mon Nov 21 15:31:32 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 15:31:32 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v6] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 14:14:14 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Update src/java.base/share/classes/sun/nio/ch/DirectBuffer.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > > src/java.base/share/classes/sun/nio/fs/NativeBuffers.java line 92: > >> 90: * allocated from the heap. >> 91: *

      >> 92: * The returned NativeBuffer is guaranteed not to be asynchronously closeable. > > This class, and the temporary buffer cache in sun.nio.ch.Util, are intended to be used with try-finally. There isn't any notion of asynchronously close so maybe it would best to not add this comment to these sources. That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 21 15:34:54 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 15:34:54 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v8] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'guard-directbuffer-address' of https://github.com/minborg/jdk into guard-directbuffer-address - Update src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Remove comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/17a72e9f..88ed3aa2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=06-07 Stats: 5 lines in 3 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From jlaskey at openjdk.org Mon Nov 21 15:42:55 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 15:42:55 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 22:34:35 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Typo > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 300: > >> 298: * {@link StringTemplate StringTemplates}. >> 299: * >> 300: * @param stringTemplates one or more {@link StringTemplate} > > Suggestion: > > * @param stringTemplates zero or more {@link StringTemplate} > > > Also the comment in `TemplateSupport.combine` should say zero or more. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From coffeys at openjdk.org Mon Nov 21 16:08:27 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 21 Nov 2022 16:08:27 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v2] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Wed, 16 Nov 2022 15:06:14 GMT, Roger Riggs wrote: >> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: >> >> the change according to review comment > > src/java.base/share/classes/jdk/internal/util/SystemProps.java line 52: > >> 50: * @return a boolean value >> 51: */ >> 52: public static boolean checkIfWarningRequired() { > > I would rename the method to `checkIoTmpdir`; it will be easier to see the purpose in the call in System. +1 I might suggest `isBadIoTmpdir` for method name ------------- PR: https://git.openjdk.org/jdk/pull/11174 From pminborg at openjdk.org Mon Nov 21 16:10:27 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 21 Nov 2022 16:10:27 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 14:07:38 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Rename methods > > src/java.base/share/classes/java/util/zip/Adler32.java line 105: > >> 103: adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem); >> 104: } finally { >> 105: Reference.reachabilityFence(buffer); > > The updated naming is a bit better but there are it still feels that that there are too many things going on at the use sites ("guard", "session", "reachability fence"). Ideally the acquire would return something with an accessor for the direct buffer address but that may not be possible. I wonder if changing NOP_CLOSE.close to do reachabilityFence(this) would work as expected and improve many of these use sites? This can certainly be done. We could, for example, add a new method to the `JavaNioAccess` interface: ```AddressAcquisition acquireSession2(Buffer buffer); // to be renamed``` This would allow us to go from: try (var guard = NIO_ACCESS.acquireSession(buffer)) { adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem); } finally { Reference.reachabilityFence(buffer); } to try (var guard = NIO_ACCESS.acquireSession2(buffer)) { adler = updateByteBuffer(adler, guard.address(), pos, rem); } Although this looks much simpler and concise, it means "a new object is created for each invocation" (*). This also allows us to remove the `@SupressWarnings("try")` annotations. Here is how the undercarriage might look like: @Override public AddressAcquisition acquireSession2(Buffer buffer) { var session = buffer.session(); if (session == null) { return AddressAcquisition.create(buffer, () -> {}); } session.acquire0(); return AddressAcquisition.create(buffer, session::release0); } and sealed interface AddressAcquisition extends AutoCloseable { long address(); @Override void close(); static AddressAcquisition create(Buffer buffer, Runnable closeActions) { return new AddressAcquisitionImpl(buffer, closeActions); } final class AddressAcquisitionImpl implements AddressAcquisition { private final DirectBuffer directBuffer; private final Runnable closeAction; public AddressAcquisitionImpl(Buffer buffer, Runnable closeAction) { this.directBuffer = (DirectBuffer) buffer; this.closeAction = closeAction; } @Override public long address() { return directBuffer.address(); } @Override public void close() { try { closeAction.run(); } finally { Reference.reachabilityFence(directBuffer); } } } } (*) In reality, a representation of the object might be allocated on the stack instead. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From coffeys at openjdk.org Mon Nov 21 16:13:43 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 21 Nov 2022 16:13:43 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v4] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Fri, 18 Nov 2022 18:36:51 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > updated from the review comment src/java.base/share/classes/java/lang/System.java line 2247: > 2245: Unsafe.getUnsafe().ensureClassInitialized(StringConcatFactory.class); > 2246: > 2247: // Emit a warning if java.io.tmpdir is set via the command line to a directory that doesn't exist could you split this comment across 2 lines ? - Keeps length similar to comment just above this code. test/jdk/java/io/File/TempDirDoesNotExist.java line 30: > 28: */ > 29: > 30: import jdk.test.lib.Platform; unused import ------------- PR: https://git.openjdk.org/jdk/pull/11174 From jlaskey at openjdk.org Mon Nov 21 16:22:28 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 16:22:28 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v27] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #11 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/c51f88c7..f2562ab3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=25-26 Stats: 85 lines in 6 files changed: 73 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Mon Nov 21 16:35:46 2022 From: duke at openjdk.org (Weibing Xiao) Date: Mon, 21 Nov 2022 16:35:46 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v5] In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: <2pDPZ1y-M_2nwuLb5Yf1xScY5FilE2i3HE3l3gEFOt0=.14849702-a403-4f03-80db-61c045f77e32@github.com> > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: update according to the review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11174/files - new: https://git.openjdk.org/jdk/pull/11174/files/38f8855b..ba12fc0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11174&range=03-04 Stats: 8 lines in 3 files changed: 1 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11174.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11174/head:pull/11174 PR: https://git.openjdk.org/jdk/pull/11174 From alanb at openjdk.org Mon Nov 21 16:37:33 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 16:37:33 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 16:08:20 GMT, Per Minborg wrote: > Although this looks much simpler and concise, it means "a new object is created for each invocation" My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From coffeys at openjdk.org Mon Nov 21 16:43:28 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 21 Nov 2022 16:43:28 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v5] In-Reply-To: <2pDPZ1y-M_2nwuLb5Yf1xScY5FilE2i3HE3l3gEFOt0=.14849702-a403-4f03-80db-61c045f77e32@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> <2pDPZ1y-M_2nwuLb5Yf1xScY5FilE2i3HE3l3gEFOt0=.14849702-a403-4f03-80db-61c045f77e32@github.com> Message-ID: On Mon, 21 Nov 2022 16:35:46 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > update according to the review comments Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11174 From duke at openjdk.org Mon Nov 21 16:46:43 2022 From: duke at openjdk.org (Strahinja Stanojevic) Date: Mon, 21 Nov 2022 16:46:43 GMT Subject: RFR: 8292914: Introduce a system property that enables stable names for lambda proxy classes [v7] In-Reply-To: References: Message-ID: > This PR introduces an option to output stable names for the lambda classes in the JDK. A stable name consists of two parts: The first part is the predefined value `$$Lambda$` appended to the lambda capturing class, and the second is a 64-bit hash part of the name. Thus, it looks like `lambdaCapturingClass$$Lambda$hashValue`. > Parameters used to create a stable hash are a superset of the parameters used for lambda class archiving when the CDS dumping option is enabled. During this process, all the mutual parameters are in the same form as they are in the low-level implementation (`SystemDictionaryShared::add_lambda_proxy_class`) of the archiving process. > We decided to use a well-specified `CRC32` algorithm from the standard Java library. We created two 32-bit hashes from the parameters used to create stable names. Then, we combined those two 32-bit hashes into one 64-bit hash value. > We chose `CRC32` because it is a well-specified hash function, and we don't need to write additional code in the JDK. `SHA-256, MD5`, and all other hash functions that rely on `MessageDigest` use lambdas in the implementation, so they are unsuitable for our purpose. We also considered a few different hash functions with a low collision rate. All these functions would require at least 100 lines of additional code in the JDK. The best alternative we found is 64-bit` MurmurHash2`: https://commons.apache.org/proper/commons-codec/jacoco/org.apache.commons.codec.digest/MurmurHash2.java.html. In case adding a new hash implementation (e.g., Murmur2) to the JDK is preferred, this PR can be easily modified. > We found the post (https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed/145633#145633) that compares different hash functions. > We also tested the `CRC32` hash function against half a billion generated strings, and there were no collisions. Note that the capturing-class name is also part of the lambda class name, so the potential collisions can only appear in a single class. Thus, we do not expect to have name collisions due to a relatively low number of lambdas per class. Every tool that uses this feature should handle potential collisions on its own. > We found an overall approximation of the collision rate too. You can find it here: https://preshing.com/20110504/hash-collision-probabilities/. > > JDK currently adds an atomic integer after `$$Lambda$`, and the names of the lambdas depend on the creation order. In the `TestStableLambdaNames`, we generate all the lambdas two times. In the first run, the method createPlainLambdas generate the following lambdas: > > - TestStableLambdaNames$$Lambda$1/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$2/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$3/0x0000000800c01a38 > The same method in the second run generates lambdas with different names: > - TestStableLambdaNames$$Lambda$1471/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1472/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$1473/0x0000000800d10470 > > If we use the introduced flag, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800c00400 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800c01800 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800c01a38 > In the second run of the method, generated lambdas are: > - TestStableLambdaNames$$Lambda$65ba26bbc6c7500d/0x0000000800d10000 > - TestStableLambdaNames$$Lambda$1569c8c4abe3ab18/0x0000000800d10238 > - TestStableLambdaNames$$Lambda$493c0ecaaf682428/0x0000000800d10470 > > We can see that the introduced hash value does not change between two calls of the method `createPlainLambdas`. That was not the case in the JDK run without this change. Those lambdas are extracted directly from the test. Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision: Remove address from lambda class names in test on the 32-bit architecture too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10024/files - new: https://git.openjdk.org/jdk/pull/10024/files/f5feb430..275e23f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10024&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10024.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10024/head:pull/10024 PR: https://git.openjdk.org/jdk/pull/10024 From mcimadamore at openjdk.org Mon Nov 21 17:05:38 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 21 Nov 2022 17:05:38 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v8] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 12:50:43 GMT, Per Minborg wrote: >> Would it be possible to re-examine acquireSession returning Runnable and >> acquireSessionAsAutoCloseable returning AutoCloseable. The naming is bit awkward at most of the use sites and maybe we can do better. > > I think it would be confusing to have overloads with the same name. > > The `aquireSession(Buffer, boolean)` method is only used once and is used in `IOUtil` so we could rename it to `aquireSessionOrNull` and then rename `acquireSessionAsAutoCloseable` to `acquireSession`. IIRC, Runnable was chosen back then because of the issues with using TWR which was generating warnings (because resource not accessed in body of TWR). I don't have strong opinions on this, other than we should only have one way to do things, rather than 2-3. Since the JDK has capabilities to acquire and release a session w/o a TWR and/or Runnable, one might also consider whether exposing acquire/release separately, and just use those. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Mon Nov 21 17:05:38 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 21 Nov 2022 17:05:38 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 16:34:46 GMT, Alan Bateman wrote: > > Although this looks much simpler and concise, it means "a new object is created for each invocation" > > My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites. Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From jlaskey at openjdk.org Mon Nov 21 17:43:16 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 17:43:16 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: References: Message-ID: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Seal Digits ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/f2562ab3..da3ea20d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=26-27 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Mon Nov 21 17:43:20 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Mon, 21 Nov 2022 17:43:20 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v26] In-Reply-To: References: Message-ID: <7kOOlCeqtY0VNYWGrxWKkU9bDAHsf8HK_Fc4cqdpEN8=.4dbbf505-2b12-431c-b701-0080dedd16d9@github.com> On Mon, 21 Nov 2022 13:38:58 GMT, Claes Redestad wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Typo > > src/java.base/share/classes/java/util/Digits.java line 39: > >> 37: */ >> 38: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) >> 39: interface Digits { > > Should this be modeled as an `abstract sealed` class hierarchy instead? Changing ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Mon Nov 21 17:43:23 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 21 Nov 2022 17:43:23 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v6] In-Reply-To: References: Message-ID: > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. Markus KARG has updated the pull request incrementally with one additional commit since the last revision: private member variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11249/files - new: https://git.openjdk.org/jdk/pull/11249/files/2e957354..8d298318 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11249&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11249.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11249/head:pull/11249 PR: https://git.openjdk.org/jdk/pull/11249 From alanb at openjdk.org Mon Nov 21 17:43:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 17:43:23 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v6] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 17:39:24 GMT, Markus KARG wrote: >> There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > private member variables Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Mon Nov 21 17:43:24 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 21 Nov 2022 17:43:24 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5] In-Reply-To: <9sxjlLkNX3QVyDUof1kVpCEw6P1ZpYf18EHGs_RtO2c=.7296051d-52c4-482b-82fa-9220489a9eee@github.com> References: <_-8C7yBI3aq7qJ_KJGYL3kMX7Hm8wWGoKfiojRgqjIE=.bf9f2684-e0e8-4bd7-9ef4-26a77a4aa525@github.com> <9sxjlLkNX3QVyDUof1kVpCEw6P1ZpYf18EHGs_RtO2c=.7296051d-52c4-482b-82fa-9220489a9eee@github.com> Message-ID: On Mon, 21 Nov 2022 07:48:01 GMT, Markus KARG wrote: > While we are at it, would you be willing to change the member variables `e` to `private final` and the `in` to `private`? From what I can see, I don't see any other class accessing these package private fields. Fixed in 8d29831 :-) ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Mon Nov 21 17:43:26 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 21 Nov 2022 17:43:26 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v5] In-Reply-To: <_-8C7yBI3aq7qJ_KJGYL3kMX7Hm8wWGoKfiojRgqjIE=.bf9f2684-e0e8-4bd7-9ef4-26a77a4aa525@github.com> References: <_-8C7yBI3aq7qJ_KJGYL3kMX7Hm8wWGoKfiojRgqjIE=.bf9f2684-e0e8-4bd7-9ef4-26a77a4aa525@github.com> Message-ID: On Mon, 21 Nov 2022 06:31:47 GMT, Jaikiran Pai wrote: >> Markus KARG has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> Jens' Proposal > > Thank you Markus for the changes. The latest version in `2e957354` looks fine to me. While we are at it, would you be willing to change the member variables `e` to `private final` and the `in` to `private`? From what I can see, I don't see any other class accessing these package private fields. @jaikiran Kindly requesting your review approval. :-) ------------- PR: https://git.openjdk.org/jdk/pull/11249 From duke at openjdk.org Mon Nov 21 17:47:16 2022 From: duke at openjdk.org (Markus KARG) Date: Mon, 21 Nov 2022 17:47:16 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Mon, 21 Nov 2022 07:42:35 GMT, Alan Bateman wrote: >> N.B.: Regarding usage numbers, I will do a quick poll on Twitter. > >> Indeed my intention solely is to get rid of `Vector`, so I am fine with keeping a low profile and being full backwards compatible. I assume SIS is seldomly used, so opening a can of warms is not worth it (I think). > > If you have the cycles then collecting data on usages and finding examples where the constructor is called with a second parameter of null would be useful. It's a lot of work to do that of course. The changes in update 2e957354 look okay, I can't immediately see any behavior change with that version. I think the public visibility of my Twitter account is not wide enough to get *really robust* answers, unfortunately. So far, 92% answered that they not even used SIS in their whole life. So the users of two-args constructor must be really neglectable. Nevertheless, they are definitively not zero, so all we could do is marking it deprecated some day. Anyways, thanks for the review. At least we get rid of `Vector` here. Would be happy if you mark the PR as reviewed. :-) ------------- PR: https://git.openjdk.org/jdk/pull/11249 From jjg at openjdk.org Mon Nov 21 17:54:15 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 21 Nov 2022 17:54:15 GMT Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java [v2] In-Reply-To: References: Message-ID: > Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc. Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Fix merge issue - Merge with upstream/master - JDK-8297164: Update troff man pages and CheckManPageOptions.java ------------- Changes: https://git.openjdk.org/jdk/pull/11223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11223&range=01 Stats: 8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod Patch: https://git.openjdk.org/jdk/pull/11223.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11223/head:pull/11223 PR: https://git.openjdk.org/jdk/pull/11223 From dfuchs at openjdk.org Mon Nov 21 18:19:23 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 21 Nov 2022 18:19:23 GMT Subject: RFR: JDK-8297164: Update troff man pages and CheckManPageOptions.java [v2] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 17:54:15 GMT, Jonathan Gibbons wrote: >> Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2 >> (See https://bugs.openjdk.org/browse/JDK-8297165) >> >> In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc. > > Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Fix merge issue > - Merge with upstream/master > - JDK-8297164: Update troff man pages and CheckManPageOptions.java The diffs are a bit difficult to read but I didn't spot anything obviously wrong with jwebserver. I could see that the new compress option was there in jmod man page too. +1. ------------- PR: https://git.openjdk.org/jdk/pull/11223 From duke at openjdk.org Mon Nov 21 18:26:02 2022 From: duke at openjdk.org (Jens Lidestrom) Date: Mon, 21 Nov 2022 18:26:02 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Mon, 21 Nov 2022 17:43:58 GMT, Markus KARG wrote: > I think the public visibility of my Twitter account is not wide enough to get really robust answers, unfortunately. One alternative is to search GitHub. It's amazing how fast they can search such a huge code corpus. Example: https://github.com/search?l=&q=%22new+SequenceInputStream%22+-filename%3ASequenceInputStreamTest.java&type=code One problem with GitHub search is that often you get a lot of duplicate matches. In the example above I have filtered out `SequenceInputStreamTest.java` which showed up a lot. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From alanb at openjdk.org Mon Nov 21 20:08:22 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 21 Nov 2022 20:08:22 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 17:00:52 GMT, Maurizio Cimadamore wrote: >>> Although this looks much simpler and concise, it means "a new object is created for each invocation" >> >> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites. > >> > Although this looks much simpler and concise, it means "a new object is created for each invocation" >> >> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites. > > Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths. Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From cstein at openjdk.org Mon Nov 21 20:26:37 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 21 Nov 2022 20:26:37 GMT Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools Message-ID: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: - `jdk.jartool` - `jdk.jlink` - `jdk.jpackage` Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". - [x] Remove `CommandLine.java` from `jdk.jartool` module - [x] Remove `CommandLine.java` from `jdk.jlink` module - [x] Remove `CommandLine.java` from `jdk.jpackage` module - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... ------------- Commit messages: - 8236919: Delete superseded `CommandLine` classes - 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools Changes: https://git.openjdk.org/jdk/pull/11272/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11272&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8236919 Stats: 514 lines in 10 files changed: 35 ins; 472 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11272.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11272/head:pull/11272 PR: https://git.openjdk.org/jdk/pull/11272 From mcimadamore at openjdk.org Mon Nov 21 21:56:01 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 21 Nov 2022 21:56:01 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v28] In-Reply-To: References: Message-ID: <0y8JsbYwjCSOwW3GHC-7W3u4__AjjxlyQ_GZHR1YBtk=.f17cdd0e-652b-4906-a9a3-bf53e3d4768a@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Address more review comments - Fix bad @throws in MemorySegment::copy methods - Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/876587c3..a0cee7b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=26-27 Stats: 19 lines in 4 files changed: 8 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From jjg at openjdk.org Mon Nov 21 22:02:01 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 21 Nov 2022 22:02:01 GMT Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> Message-ID: On Mon, 21 Nov 2022 15:40:19 GMT, Christian Stein wrote: > This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: > - `jdk.jartool` > - `jdk.jlink` > - `jdk.jpackage` > > Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. > > - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". > - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". > - [x] Remove `CommandLine.java` from `jdk.jartool` module > - [x] Remove `CommandLine.java` from `jdk.jlink` module > - [x] Remove `CommandLine.java` from `jdk.jpackage` module > - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... I guess git is "confused" by not realizing that the "new" `CommandLine.java` is just a clone of the existing `javac` version. (It is, isn't it ... apart from the package rename?) src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java line 51: > 49: * If you write code that depends on this, you do so at your own risk. > 50: * This code and its internal interfaces are subject to change or > 51: * deletion without notice. Maybe we can drop this part of the comment ------------- Marked as reviewed by jjg (Reviewer). PR: https://git.openjdk.org/jdk/pull/11272 From jjg at openjdk.org Mon Nov 21 22:06:36 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 21 Nov 2022 22:06:36 GMT Subject: Integrated: JDK-8297164: Update troff man pages and CheckManPageOptions.java In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 22:23:53 GMT, Jonathan Gibbons wrote: > Please review an update for the troff man pages, following the recent update to upgrade to use pandoc 2.19.2 > (See https://bugs.openjdk.org/browse/JDK-8297165) > > In conjunction with this, one javadoc test also needs to be updated, to work with the new form of output generated by the new version of pandoc. This pull request has now been integrated. Changeset: 5a45c251 Author: Jonathan Gibbons URL: https://git.openjdk.org/jdk/commit/5a45c25151b1da8e329ea2be21a0e4d2652f8b4a Stats: 8963 lines in 29 files changed: 471 ins; 1587 del; 6905 mod 8297164: Update troff man pages and CheckManPageOptions.java Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11223 From sviswanathan at openjdk.org Tue Nov 22 00:07:26 2022 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Tue, 22 Nov 2022 00:07:26 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v13] In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 13:00:06 GMT, Claes Redestad wrote: >> Continuing the work initiated by @luhenry to unroll and then intrinsify polynomial hash loops. >> >> I've rewired the library changes to route via a single `@IntrinsicCandidate` method. To make this work I've harmonized how they are invoked so that there's less special handling and checks in the intrinsic. Mainly do the null-check outside of the intrinsic for `Arrays.hashCode` cases. >> >> Having a centralized entry point means it'll be easier to parameterize the factor and start values which are now hard-coded (always 31, and a start value of either one for `Arrays` or zero for `String`). It seems somewhat premature to parameterize this up front. >> >> The current implementation is performance neutral on microbenchmarks on all tested platforms (x64, aarch64) when not enabling the intrinsic. We do add a few trivial method calls which increase the call stack depth, so surprises cannot be ruled out on complex workloads. >> >> With the most recent fixes the x64 intrinsic results on my workstation look like this: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.199 ? 0.017 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 6.933 ? 0.049 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 29.935 ? 0.221 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 1596.982 ? 7.020 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.defaultLatin1 1 avgt 5 2.200 ? 0.013 ns/op >> StringHashCode.Algorithm.defaultLatin1 10 avgt 5 9.424 ? 0.122 ns/op >> StringHashCode.Algorithm.defaultLatin1 100 avgt 5 90.541 ? 0.512 ns/op >> StringHashCode.Algorithm.defaultLatin1 10000 avgt 5 9425.321 ? 67.630 ns/op >> >> I.e. no measurable overhead compared to baseline even for `size == 1`. >> >> The vectorized code now nominally works for all unsigned cases as well as ints, though more testing would be good. >> >> Benchmark for `Arrays.hashCode`: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 1.884 ? 0.013 ns/op >> ArraysHashCode.bytes 10 avgt 5 6.955 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 87.218 ? 0.595 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9419.591 ? 38.308 ns/op >> ArraysHashCode.chars 1 avgt 5 2.200 ? 0.010 ns/op >> ArraysHashCode.chars 10 avgt 5 6.935 ? 0.034 ns/op >> ArraysHashCode.chars 100 avgt 5 30.216 ? 0.134 ns/op >> ArraysHashCode.chars 10000 avgt 5 1601.629 ? 6.418 ns/op >> ArraysHashCode.ints 1 avgt 5 2.200 ? 0.007 ns/op >> ArraysHashCode.ints 10 avgt 5 6.936 ? 0.034 ns/op >> ArraysHashCode.ints 100 avgt 5 29.412 ? 0.268 ns/op >> ArraysHashCode.ints 10000 avgt 5 1610.578 ? 7.785 ns/op >> ArraysHashCode.shorts 1 avgt 5 1.885 ? 0.012 ns/op >> ArraysHashCode.shorts 10 avgt 5 6.961 ? 0.034 ns/op >> ArraysHashCode.shorts 100 avgt 5 87.095 ? 0.417 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.617 ? 50.089 ns/op >> >> Baseline: >> >> Benchmark (size) Mode Cnt Score Error Units >> ArraysHashCode.bytes 1 avgt 5 3.213 ? 0.207 ns/op >> ArraysHashCode.bytes 10 avgt 5 8.483 ? 0.040 ns/op >> ArraysHashCode.bytes 100 avgt 5 90.315 ? 0.655 ns/op >> ArraysHashCode.bytes 10000 avgt 5 9422.094 ? 62.402 ns/op >> ArraysHashCode.chars 1 avgt 5 3.040 ? 0.066 ns/op >> ArraysHashCode.chars 10 avgt 5 8.497 ? 0.074 ns/op >> ArraysHashCode.chars 100 avgt 5 90.074 ? 0.387 ns/op >> ArraysHashCode.chars 10000 avgt 5 9420.474 ? 41.619 ns/op >> ArraysHashCode.ints 1 avgt 5 2.827 ? 0.019 ns/op >> ArraysHashCode.ints 10 avgt 5 7.727 ? 0.043 ns/op >> ArraysHashCode.ints 100 avgt 5 89.405 ? 0.593 ns/op >> ArraysHashCode.ints 10000 avgt 5 9426.539 ? 51.308 ns/op >> ArraysHashCode.shorts 1 avgt 5 3.071 ? 0.062 ns/op >> ArraysHashCode.shorts 10 avgt 5 8.168 ? 0.049 ns/op >> ArraysHashCode.shorts 100 avgt 5 90.399 ? 0.292 ns/op >> ArraysHashCode.shorts 10000 avgt 5 9420.171 ? 44.474 ns/op >> >> >> As we can see the `Arrays` intrinsics are faster for small inputs, and faster on large inputs for `char` and `int` (the ones currently vectorized). I aim to fix `byte` and `short` cases before integrating, though it might be acceptable to hand that off as follow-up enhancements to not further delay integration of this enhancement. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Missing & 0xff in StringLatin1::hashCode We have seen this as a hotspot in workloads. It will be good to optimize the StringUTF16 and StringLatin1 hash code computation. ------------- PR: https://git.openjdk.org/jdk/pull/10847 From duke at openjdk.org Tue Nov 22 00:45:00 2022 From: duke at openjdk.org (pandaapo) Date: Tue, 22 Nov 2022 00:45:00 GMT Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7] In-Reply-To: References: Message-ID: > The cache named `signerToCodeSource` in `JarVerifier` is never used now. pandaapo has updated the pull request incrementally with one additional commit since the last revision: Modify as reviews. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11072/files - new: https://git.openjdk.org/jdk/pull/11072/files/fb933804..1aa65b2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11072&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11072&range=05-06 Stats: 10 lines in 1 file changed: 4 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11072.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11072/head:pull/11072 PR: https://git.openjdk.org/jdk/pull/11072 From bchristi at openjdk.org Tue Nov 22 00:50:51 2022 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 22 Nov 2022 00:50:51 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v4] In-Reply-To: References: Message-ID: > [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". > > One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Update Runtime class doc re: other unexpected behaviors ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11218/files - new: https://git.openjdk.org/jdk/pull/11218/files/cbba781f..6df8acf8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11218/head:pull/11218 PR: https://git.openjdk.org/jdk/pull/11218 From vlivanov at openjdk.org Tue Nov 22 00:52:25 2022 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 22 Nov 2022 00:52:25 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v7] In-Reply-To: References: Message-ID: <8WIJU705KWrVpK3zR1FhwrrpqSbxiUUm_aJaRR0Zdzk=.1594761d-bc52-4968-a4ca-262a2a7cb55b@github.com> On Fri, 18 Nov 2022 14:54:52 GMT, Jorn Vernee wrote: >> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. >> >> This is split off from the main JEP integration to make reviewing easier. >> >> This includes the following patches: >> >> 1. https://github.com/openjdk/panama-foreign/pull/698 >> 2. https://github.com/openjdk/panama-foreign/pull/699 >> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 >> 4. https://github.com/openjdk/panama-foreign/pull/740 >> 5. https://github.com/openjdk/panama-foreign/pull/746 >> 6. https://github.com/openjdk/panama-foreign/pull/742 >> 7. https://github.com/openjdk/panama-foreign/pull/743 >> >> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. >> >> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. >> >> Please refer to the PR of each individual patch for a more detailed description. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > 8296973: saving errno on a value-returning function crashes the JVM > > Reviewed-by: mcimadamore Unless I'm missing something important, `vmstorage.inline.hpp`/`vmstorage_.inline.hpp` should be named `vmstorage.hpp`/`vmstorage_.hpp`. Otherwise, looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Tue Nov 22 01:29:58 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 22 Nov 2022 01:29:58 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v8] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: drop .inline from vmstorage header names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/0fa0e8cf..03be64c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=06-07 Stats: 7 lines in 11 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From jvernee at openjdk.org Tue Nov 22 01:29:59 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 22 Nov 2022 01:29:59 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v7] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 14:54:52 GMT, Jorn Vernee wrote: >> Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. >> >> This is split off from the main JEP integration to make reviewing easier. >> >> This includes the following patches: >> >> 1. https://github.com/openjdk/panama-foreign/pull/698 >> 2. https://github.com/openjdk/panama-foreign/pull/699 >> 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 >> 4. https://github.com/openjdk/panama-foreign/pull/740 >> 5. https://github.com/openjdk/panama-foreign/pull/746 >> 6. https://github.com/openjdk/panama-foreign/pull/742 >> 7. https://github.com/openjdk/panama-foreign/pull/743 >> >> Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. >> >> The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. >> >> Please refer to the PR of each individual patch for a more detailed description. > > Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision: > > 8296973: saving errno on a value-returning function crashes the JVM > > Reviewed-by: mcimadamore Thanks for the review, I've dropped the `.inline` from the header file names. ------------- PR: https://git.openjdk.org/jdk/pull/11019 From jpai at openjdk.org Tue Nov 22 01:45:29 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 22 Nov 2022 01:45:29 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v6] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 17:43:23 GMT, Markus KARG wrote: >> There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > private member variables Thank you Markus for these changes. The latest state in `8d298318` looks good to me. I'll run some tests today before sponsoring this. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11249 From weijun at openjdk.org Tue Nov 22 01:46:43 2022 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 22 Nov 2022 01:46:43 GMT Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 00:45:00 GMT, pandaapo wrote: >> The cache named `signerToCodeSource` in `JarVerifier` is never used now. > > pandaapo has updated the pull request incrementally with one additional commit since the last revision: > > Modify as reviews. Everything looks fine now. Thanks so much for the cleanup. It's always nice to see unused lines removed. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.org/jdk/pull/11072 From duke at openjdk.org Tue Nov 22 01:58:22 2022 From: duke at openjdk.org (pandaapo) Date: Tue, 22 Nov 2022 01:58:22 GMT Subject: RFR: 8297301: Cleanup unused methods in JavaUtilJarAccess [v7] In-Reply-To: References: Message-ID: <5BMq7qlR9msrDdQONoHzHFKw4T99g0CcYuFh03SKuD8=.809ab694-3694-4a2a-80a6-2b13136c43ae@github.com> On Tue, 22 Nov 2022 01:44:29 GMT, Weijun Wang wrote: > Everything looks fine now. Thanks so much for the cleanup. It's always nice to see unused lines removed. Thank you for your review. ------------- PR: https://git.openjdk.org/jdk/pull/11072 From duke at openjdk.org Tue Nov 22 03:24:38 2022 From: duke at openjdk.org (pandaapo) Date: Tue, 22 Nov 2022 03:24:38 GMT Subject: Integrated: 8297301: Cleanup unused methods in JavaUtilJarAccess In-Reply-To: References: Message-ID: On Thu, 10 Nov 2022 01:02:00 GMT, pandaapo wrote: > The cache named `signerToCodeSource` in `JarVerifier` is never used now. This pull request has now been integrated. Changeset: f0e99c63 Author: pandaapo <1052156701 at qq.com> Committer: Weijun Wang URL: https://git.openjdk.org/jdk/commit/f0e99c634693fafc0c5d1103184e73c6669629db Stats: 652 lines in 4 files changed: 3 ins; 636 del; 13 mod 8297301: Cleanup unused methods in JavaUtilJarAccess Reviewed-by: weijun ------------- PR: https://git.openjdk.org/jdk/pull/11072 From duke at openjdk.org Tue Nov 22 05:07:35 2022 From: duke at openjdk.org (Markus KARG) Date: Tue, 22 Nov 2022 05:07:35 GMT Subject: Integrated: JDK-8297299 SequenceInputStream should not use Vector In-Reply-To: References: Message-ID: On Sat, 19 Nov 2022 21:36:56 GMT, Markus KARG wrote: > There is no need to use a temporary Vector within the constructor of SynchronizedInputStream, as more efficient (non-synchronized) alternative code (like List.of) will do the same in possibly less time. While the optimization is not dramatic, it still makes sense to replace Vector unless synchronization is really needed. This pull request has now been integrated. Changeset: 06968548 Author: Markus Karg Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/069685489afcea9b31491f0d9fec8cc52e210e99 Stats: 11 lines in 1 file changed: 2 ins; 5 del; 4 mod 8297299: SequenceInputStream should not use Vector Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11249 From yyang at openjdk.org Tue Nov 22 06:15:02 2022 From: yyang at openjdk.org (Yi Yang) Date: Tue, 22 Nov 2022 06:15:02 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc In-Reply-To: References: Message-ID: <8wkboRZfT8sOY2KvKTTP-BOvBcxCJHsWcXQHetGp_BU=.7147cf58-eacf-442e-9423-7fb2be32f6ec@github.com> On Tue, 15 Nov 2022 15:05:45 GMT, Dongxu Wang wrote: > 8297385: Remove duplicated null typos in javadoc good catch, do you need a JBS issue for this? ------------- PR: https://git.openjdk.org/jdk/pull/11169 From duke at openjdk.org Tue Nov 22 06:15:01 2022 From: duke at openjdk.org (Dongxu Wang) Date: Tue, 22 Nov 2022 06:15:01 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc Message-ID: 8297385: Remove duplicated null typos in javadoc ------------- Commit messages: - Minor remove duplicate null typo Changes: https://git.openjdk.org/jdk/pull/11169/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11169&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297385 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11169.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11169/head:pull/11169 PR: https://git.openjdk.org/jdk/pull/11169 From duke at openjdk.org Tue Nov 22 06:15:03 2022 From: duke at openjdk.org (Dongxu Wang) Date: Tue, 22 Nov 2022 06:15:03 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc In-Reply-To: <8wkboRZfT8sOY2KvKTTP-BOvBcxCJHsWcXQHetGp_BU=.7147cf58-eacf-442e-9423-7fb2be32f6ec@github.com> References: <8wkboRZfT8sOY2KvKTTP-BOvBcxCJHsWcXQHetGp_BU=.7147cf58-eacf-442e-9423-7fb2be32f6ec@github.com> Message-ID: On Mon, 21 Nov 2022 15:16:14 GMT, Yi Yang wrote: > good catch, do you need a JBS issue for this? Thank you if you can help with that. ------------- PR: https://git.openjdk.org/jdk/pull/11169 From yyang at openjdk.org Tue Nov 22 06:15:04 2022 From: yyang at openjdk.org (Yi Yang) Date: Tue, 22 Nov 2022 06:15:04 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc In-Reply-To: References: <8wkboRZfT8sOY2KvKTTP-BOvBcxCJHsWcXQHetGp_BU=.7147cf58-eacf-442e-9423-7fb2be32f6ec@github.com> Message-ID: <2Tfvfo9N6jkfm7yM03ZJ5SW5oONriuYnVsWvxHtI2hg=.de72cc76-3a41-47b9-b14b-f08d30571c66@github.com> On Tue, 22 Nov 2022 02:22:20 GMT, Dongxu Wang wrote: > > good catch, do you need a JBS issue for this? > > Thank you if you can help with that. I filed https://bugs.openjdk.org/browse/JDK-8297385 for this, you can change your PR title and commit message to [8297385: Remove duplicated null typo in javadoc](https://bugs.openjdk.org/browse/JDK-8297385), OpenJDK robot will guide you remaining processes. ------------- PR: https://git.openjdk.org/jdk/pull/11169 From pminborg at openjdk.org Tue Nov 22 09:11:44 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 22 Nov 2022 09:11:44 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Rework Acquisition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/88ed3aa2..0526e3dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=07-08 Stats: 249 lines in 19 files changed: 66 ins; 91 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Tue Nov 22 09:11:44 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 22 Nov 2022 09:11:44 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v4] In-Reply-To: References: <0TGCdAziwM5zde96UHQd5aHM6LrHWiL4gOkmThawpQQ=.8daf0bde-6cc3-4ef8-b432-842355bdc197@github.com> Message-ID: On Mon, 21 Nov 2022 20:06:20 GMT, Alan Bateman wrote: >>> > Although this looks much simpler and concise, it means "a new object is created for each invocation" >>> >>> My comment was actually to see if DirectBuffer could extend AutoCloseable so that the acquire returns "this" for the non-session case. Doing the equivalent for the session case might leak into MemorySessionImpl implementing DirectBuffer which you probably don't want to do. If NOP_CLOSE.close can do the Reference.reachabilityFence(this) then it would at least improve some of the use-sites. >> >> Not sure that is simpler. ByteBuffer <: AutoCloseable doesn't seem to make sense to me. I'm also not sure how much object allocation (all this stuff will become value types) should be the driving factor in these code paths. > > Right, I didn't mean BB <: AC but to see if we avoid needing to wrap it because this PR is touching several low level and performance critical code paths. For the faraway places then having the close do a Reference.reachabilityFence(this) should avoid the surprise that the buffer has to kept alive even though it appears that the try-with-resources is doing it already. I have reworked Acquisition. I think we could merge the old and new way in a separate PR. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From duke at openjdk.org Tue Nov 22 09:33:21 2022 From: duke at openjdk.org (Dongxu Wang) Date: Tue, 22 Nov 2022 09:33:21 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc In-Reply-To: <2Tfvfo9N6jkfm7yM03ZJ5SW5oONriuYnVsWvxHtI2hg=.de72cc76-3a41-47b9-b14b-f08d30571c66@github.com> References: <8wkboRZfT8sOY2KvKTTP-BOvBcxCJHsWcXQHetGp_BU=.7147cf58-eacf-442e-9423-7fb2be32f6ec@github.com> <2Tfvfo9N6jkfm7yM03ZJ5SW5oONriuYnVsWvxHtI2hg=.de72cc76-3a41-47b9-b14b-f08d30571c66@github.com> Message-ID: On Tue, 22 Nov 2022 03:33:55 GMT, Yi Yang wrote: > > > good catch, do you need a JBS issue for this? > > > > > > Thank you if you can help with that. > > I filed https://bugs.openjdk.org/browse/JDK-8297385 for this, you can change your PR title and commit message to [8297385: Remove duplicated null typo in javadoc](https://bugs.openjdk.org/browse/JDK-8297385), OpenJDK robot will guide you remaining processes. Thank you, can you also help review ------------- PR: https://git.openjdk.org/jdk/pull/11169 From alanb at openjdk.org Tue Nov 22 09:34:36 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Nov 2022 09:34:36 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v6] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 15:29:11 GMT, Per Minborg wrote: > That is clear to me but I am trying to prevent future redundant guarding. Anyway, I will remove the comments. The faraway use sites look much better now. The performance sensitive usages need close attention. Can you summarise the changes to DatagramChannel, are you creating a NoOpScopeAcquisition for every send/receive? This is low level code where we do do something different to avoid the try-with-resources. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From duke at openjdk.org Tue Nov 22 09:38:12 2022 From: duke at openjdk.org (Ismael Juma) Date: Tue, 22 Nov 2022 09:38:12 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rework Acquisition > because this PR is touching several low level and performance critical code paths Indeed. Have we verified that performance doesn't regress with these changes? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Tue Nov 22 09:38:15 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 22 Nov 2022 09:38:15 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rework Acquisition src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914: > 912: * If so, make a copy to put the dst data in. > 913: */ > 914: @SuppressWarnings("try") After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with). src/java.base/share/classes/java/nio/Buffer.java line 827: > 825: > 826: @Override > 827: public Runnable acquireSessionOrNull(Buffer buffer, boolean async) { If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this: Buffer b = ... try { // use buffer.address(); } finally { Reference.reachabilityFence(b); } We could transform to this: Buffer b = ... acquire(b); // calls MemorySessionImpl.acquire0 if session is not null try { // use buffer.address(); } finally { release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case) } This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too. src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590: > 588: int pos) > 589: throws IOException { > 590: try (var guard = NIO_ACCESS.acquireScope(bb)) { Why was the old code not using reachability fences? Bug or feature? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Tue Nov 22 09:42:23 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 22 Nov 2022 09:42:23 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 09:32:32 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Rework Acquisition > > src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590: > >> 588: int pos) >> 589: throws IOException { >> 590: try (var guard = NIO_ACCESS.acquireScope(bb)) { > > Why was the old code not using reachability fences? Bug or feature? I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing). Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From duke at openjdk.org Tue Nov 22 10:23:04 2022 From: duke at openjdk.org (ExE Boss) Date: Tue, 22 Nov 2022 10:23:04 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 09:11:44 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Rework Acquisition src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 43: > 41: // try (var guard = NIO_ACCESS.acquireSession(bb)) { > 42: // performOperation(bb.address()); > 43: // } Again, updating?this?comment was?missed: Suggestion: // try (var guard = NIO_ACCESS.acquireScope(bb)) { // performOperation(guard.address()); // } ------------- PR: https://git.openjdk.org/jdk/pull/11260 From lancea at openjdk.org Tue Nov 22 11:39:20 2022 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 22 Nov 2022 11:39:20 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v4] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 00:50:51 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Update Runtime class doc re: other unexpected behaviors Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11218 From alanb at openjdk.org Tue Nov 22 12:00:24 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Nov 2022 12:00:24 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 09:38:35 GMT, Maurizio Cimadamore wrote: >> src/jdk.sctp/unix/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java line 590: >> >>> 588: int pos) >>> 589: throws IOException { >>> 590: try (var guard = NIO_ACCESS.acquireScope(bb)) { >> >> Why was the old code not using reachability fences? Bug or feature? > > I see that there's a subsequent buffer call if `n > 0`, so that's probably why the fence was skipped? (I also assume that the code calling this method will access the buffer before/after, so reachability is never truly an issue - but for session-backed buffers this needs fixing). > > Also, stepping back, I note how, if `receive0` was a native call using Linker, perhaps we wouldn't need all this manual address computation - we'd just get a memory segment slice from the buffer and pass that to the handle (which will perform the correct liveness check). E.g. maybe a better long term solution would be to panama-ize this code? Yes, once the memory/linker APIs are permanent then the SCTP implementation would be a good candidate to redo. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Tue Nov 22 12:00:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 22 Nov 2022 12:00:23 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: <4GRnrg0zNGXoQdiG3uL9JeQyj4bdDVubzv0oMoIuSnM=.1dabdf13-e8b7-477d-86d0-20e5ba2f47bf@github.com> On Tue, 22 Nov 2022 09:29:14 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Rework Acquisition > > src/java.base/share/classes/java/nio/Buffer.java line 827: > >> 825: >> 826: @Override >> 827: public Runnable acquireSessionOrNull(Buffer buffer, boolean async) { > > If allocation/performance is an issue, a relatively straightforward way to adjust the code would be to let go of the TWR entirely. E.g. we have code that does this: > > > Buffer b = ... > try { > // use buffer.address(); > } finally { > Reference.reachabilityFence(b); > } > > > We could transform to this: > > > Buffer b = ... > acquire(b); // calls MemorySessionImpl.acquire0 if session is not null > try { > // use buffer.address(); > } finally { > release(b); // calls MemorySessionImpl.release0 if session is not null (and maybe adds a reachability fence, just in case) > } > > This leads to a simpler patch that is probably easier to validate. The remaining IOUtil code will be using a different idiom, and perhaps we can, at some point, go back and make that consistent too. The AutoCloseable experiment was interesting to try but I think you are right, acquire try { .. } finally release would be simpler and also remove the concerns about the performance critical code paths. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Tue Nov 22 13:52:22 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 22 Nov 2022 13:52:22 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: References: Message-ID: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com> On Tue, 22 Nov 2022 09:23:40 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Rework Acquisition > > src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914: > >> 912: * If so, make a copy to put the dst data in. >> 913: */ >> 914: @SuppressWarnings("try") > > After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with). Well spotted. I will remove the guarding here. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Tue Nov 22 14:01:39 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 22 Nov 2022 14:01:39 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v10] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove redundant guard and fix comment permanently ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/0526e3dc..06c764ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=08-09 Stats: 59 lines in 2 files changed: 19 ins; 26 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Tue Nov 22 14:48:04 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 22 Nov 2022 14:48:04 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v29] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix wrong check in MemorySegment::spliterator/elements (The check which ensures that the segment size is multiple of spliterator element size is bogus) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/a0cee7b0..66dd888d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=27-28 Stats: 29 lines in 2 files changed: 21 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From rriggs at openjdk.org Tue Nov 22 14:54:28 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 22 Nov 2022 14:54:28 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 15:05:45 GMT, Dongxu Wang wrote: > 8297385: Remove duplicated null typos in javadoc The source of this PR is the "master" branch of your fork. Note the Comment from the bot at the top. The conventional usage is to create a branch specific to the change you are making and create the PR from that. You will run into trouble with git due to any commits in the master branch other than are pulled from the mainline. You can create the new branch from your current master and then reset the HEAD of the master back to match the mainline head. ------------- PR: https://git.openjdk.org/jdk/pull/11169 From chegar999 at gmail.com Tue Nov 22 15:21:39 2022 From: chegar999 at gmail.com (Chris Hegarty) Date: Tue, 22 Nov 2022 15:21:39 +0000 Subject: JDK 19 innocuous reaper threads Message-ID: <8e745203-e5c8-4ffd-2ca4-be030f9f71c3@gmail.com> Hi, A change in JDK 19, that changed process reaper threads to be innocuous [1], has had an adverse affect when terminating the Elasticsearch server [2]. I agree with changing the process reapers to be innocuous, but just wonder if we're missing a few doPriv blocks. Additionally, and also in JDK 19, is the welcome improvement of the pid in the reaper thread name [3], but again I wonder if we're missing a few doPriv blocks here too. The issues we're seeing arise from the calls to `setDaemon` and `setName` outside of doPriv blocks, which can (depending on your security manager implementation) result in checking the callers permissions, and its callers permissions, etc, all the way to the thread's inherited access control context - which is effectively empty for these threads, since they are innocuous. I don't remember where we ended up with these kinda calls for innocuous threads, I'm thinking specifically about `setDaemon` (but `setName` seems similar) - whether they should be in doPriv or not, given the default security manager implementation. My feeling is that they should, since the caller should never be required to hold any specific permissions for these specific operations [4][5][6] to succeed. -Chris. [1] https://bugs.openjdk.org/browse/JDK-8279488 [2] https://github.com/elastic/elasticsearch/issues/91650 [3] https://bugs.openjdk.org/browse/JDK-8284165 [4] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ProcessHandleImpl.java#L103 [5] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ProcessHandleImpl.java#LL144 [6] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ProcessHandleImpl.java#LL175 From cstein at openjdk.org Tue Nov 22 15:50:20 2022 From: cstein at openjdk.org (Christian Stein) Date: Tue, 22 Nov 2022 15:50:20 GMT Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> Message-ID: On Mon, 21 Nov 2022 15:40:19 GMT, Christian Stein wrote: > This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: > - `jdk.jartool` > - `jdk.jlink` > - `jdk.jpackage` > > Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. > > - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". > - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". > - [x] Remove `CommandLine.java` from `jdk.jartool` module > - [x] Remove `CommandLine.java` from `jdk.jlink` module > - [x] Remove `CommandLine.java` from `jdk.jpackage` module > - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... Yes. I copied `CommandLine` class from module `jdk.compiler`. In addition to update of the copyright year and the name of the package, I also added small API changes that other tools developed in their copies of the class. Find a diff attached below: diff --git a/open/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java b/open/src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java index ec6f711f9b..9e4b0c6fe2 100644 --- a/open/src/jdk.compiler/share/classes/com/sun/tools/javac/main/CommandLine.java +++ b/open/src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 2022, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,17 +23,25 @@ * questions. */ -package com.sun.tools.javac.main; +package jdk.internal.opt; import java.io.IOException; +import java.io.InputStream; +import java.io.InputStreamReader; import java.io.Reader; import java.nio.charset.Charset; import java.nio.file.Files; import java.nio.file.Paths; import java.util.ArrayList; -import java.util.Arrays; import java.util.List; +/* + * This file was originally a copy of CommandLine.java in + * com.sun.tools.javac.main -- and it will be the last. + * + * Find details at https://bugs.openjdk.org/browse/JDK-8236919 + */ + /** * Various utility methods for processing Java tool command line arguments. * @@ -42,7 +50,16 @@ import java.util.List; * This code and its internal interfaces are subject to change or * deletion without notice. */ -public class CommandLine { +public final class CommandLine { + /** + * Convenient wrapper for the {@code List}-based parse method. + * + * @see #parse(List) + */ + public static String[] parse(String... args) throws IOException { + return parse(List.of(args)).toArray(String[]::new); + } + /** * Process Win32-style command files for the specified command line * arguments and return the resulting arguments. A command file argument @@ -91,7 +108,7 @@ public class CommandLine { * @param args the arguments that may contain @files * @return the arguments, with environment variable's content and expansion of @files * @throws IOException if there is a problem reading any of the @files - * @throws com.sun.tools.javac.main.CommandLine.UnmatchedQuote + * @throws CommandLine.UnmatchedQuote */ public static List parse(String envVariable, List args) throws IOException, UnmatchedQuote { @@ -104,8 +121,18 @@ public class CommandLine { return newArgs; } + public static void loadCmdFile(InputStream in, List args) throws IOException { + Reader reader = new InputStreamReader(in); + loadCmdFileAndCloseReader(reader, args); + } + private static void loadCmdFile(String name, List args) throws IOException { - try (Reader r = Files.newBufferedReader(Paths.get(name), Charset.defaultCharset())) { + Reader reader = Files.newBufferedReader(Paths.get(name), Charset.defaultCharset()); + loadCmdFileAndCloseReader(reader, args); + } + + private static void loadCmdFileAndCloseReader(Reader r, List args) throws IOException { + try (r) { Tokenizer t = new Tokenizer(r); String s; while ((s = t.nextToken()) != null) { ------------- PR: https://git.openjdk.org/jdk/pull/11272 From cstein at openjdk.org Tue Nov 22 15:57:57 2022 From: cstein at openjdk.org (Christian Stein) Date: Tue, 22 Nov 2022 15:57:57 GMT Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools [v2] In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> Message-ID: > This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: > - `jdk.jartool` > - `jdk.jlink` > - `jdk.jpackage` > > Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. > > - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". > - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". > - [x] Remove `CommandLine.java` from `jdk.jartool` module > - [x] Remove `CommandLine.java` from `jdk.jlink` module > - [x] Remove `CommandLine.java` from `jdk.jpackage` module > - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Remove superseded comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11272/files - new: https://git.openjdk.org/jdk/pull/11272/files/ebdcbde7..7854e14c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11272&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11272&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11272.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11272/head:pull/11272 PR: https://git.openjdk.org/jdk/pull/11272 From Alan.Bateman at oracle.com Tue Nov 22 16:08:09 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Nov 2022 16:08:09 +0000 Subject: JDK 19 innocuous reaper threads In-Reply-To: <8e745203-e5c8-4ffd-2ca4-be030f9f71c3@gmail.com> References: <8e745203-e5c8-4ffd-2ca4-be030f9f71c3@gmail.com> Message-ID: <399bebbc-f56e-4557-773a-fe91b3ffb737@oracle.com> On 22/11/2022 15:21, Chris Hegarty wrote: > Hi, > > A change in JDK 19, that changed process reaper threads to be > innocuous [1], has had an adverse affect when terminating the > Elasticsearch server [2]. I agree with changing the process reapers to > be innocuous, but just wonder if we're missing a few doPriv blocks. > Additionally, and also in JDK 19, is the welcome improvement of the pid > in the reaper thread name [3], but again I wonder if we're missing a few > doPriv blocks here too. > > The issues we're seeing arise from the calls to `setDaemon` and `setName` > outside of doPriv blocks, which can (depending on your security manager > implementation) result in checking the callers permissions, and its > callers permissions, etc, all the way to the thread's inherited access > control context - which is effectively empty for these threads, since > they are innocuous. > > I don't remember where we ended up with these kinda calls for innocuous > threads, I'm thinking specifically about `setDaemon` (but `setName` > seems similar) - whether they should be in doPriv or not, given the > default security manager implementation. My feeling is that they should, > since the caller should never be required to hold any specific > permissions for these specific operations [4][5][6] to succeed. Just to double check, does the ES security manager override checkAccess(Thread)? That is usually a no-op but if overridden then it will expose an issue with the thread factory for the "process reaper" where it attempts changes the daemon status outside of a doPriv block. -Alan From chegar999 at gmail.com Tue Nov 22 16:12:49 2022 From: chegar999 at gmail.com (Chris Hegarty) Date: Tue, 22 Nov 2022 16:12:49 +0000 Subject: JDK 19 innocuous reaper threads In-Reply-To: <399bebbc-f56e-4557-773a-fe91b3ffb737@oracle.com> References: <8e745203-e5c8-4ffd-2ca4-be030f9f71c3@gmail.com> <399bebbc-f56e-4557-773a-fe91b3ffb737@oracle.com> Message-ID: <720dc5b8-1c2c-d624-7423-c9d127e6234e@gmail.com> Hi Alan, On 22/11/2022 16:08, Alan Bateman wrote: > On 22/11/2022 15:21, Chris Hegarty wrote: >> .. > > Just to double check, does the ES security manager override > checkAccess(Thread)? Yes. :-( > That is usually a no-op but if overridden then it > will expose an issue with the thread factory for the "process reaper" > where it attempts changes the daemon status outside of a doPriv block. Right. That's exactly what we're running into. If there are no objections, then I'm happy to file an issue and PR to add narrow doPriv blocks around these calls. -Chris [1] https://github.com/elastic/elasticsearch/blob/main/libs/secure-sm/src/main/java/org/elasticsearch/secure_sm/SecureSM.java#L118 From aph at openjdk.org Tue Nov 22 16:56:04 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 22 Nov 2022 16:56:04 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v17] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 - Fix bad merge. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/86ce5bbd..04320c7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=15-16 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From roger.riggs at oracle.com Tue Nov 22 17:01:35 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 22 Nov 2022 12:01:35 -0500 Subject: JDK 19 innocuous reaper threads In-Reply-To: <720dc5b8-1c2c-d624-7423-c9d127e6234e@gmail.com> References: <8e745203-e5c8-4ffd-2ca4-be030f9f71c3@gmail.com> <399bebbc-f56e-4557-773a-fe91b3ffb737@oracle.com> <720dc5b8-1c2c-d624-7423-c9d127e6234e@gmail.com> Message-ID: Hi Chris, Yes, adding a doPriv for setDaemon and setName in a couple of places makes sense. Thanks, Roger On 11/22/22 11:12 AM, Chris Hegarty wrote: > Hi Alan, > > On 22/11/2022 16:08, Alan Bateman wrote: >> On 22/11/2022 15:21, Chris Hegarty wrote: >>> .. >> >> Just to double check, does the ES security manager override >> checkAccess(Thread)? > > Yes. :-( > >> That is usually a no-op but if overridden then it will expose an >> issue with the thread factory for the "process reaper" where it >> attempts changes the daemon status outside of a doPriv block. > > Right. That's exactly what we're running into. > > If there are no objections, then I'm happy to file an issue > and PR to add narrow doPriv blocks around these calls. > > -Chris > > [1] > https://github.com/elastic/elasticsearch/blob/main/libs/secure-sm/src/main/java/org/elasticsearch/secure_sm/SecureSM.java#L118 From jjg at openjdk.org Tue Nov 22 17:19:28 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 22 Nov 2022 17:19:28 GMT Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools [v2] In-Reply-To: References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> Message-ID: <0WBh1OHEuCdBwQ4dXLlip2J6bhh-X7LZu-Jm0JenJlY=.e77a0a31-7427-42fd-9667-7dad4c0d64b8@github.com> On Tue, 22 Nov 2022 15:57:57 GMT, Christian Stein wrote: >> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: >> - `jdk.jartool` >> - `jdk.jlink` >> - `jdk.jpackage` >> >> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. >> >> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". >> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". >> - [x] Remove `CommandLine.java` from `jdk.jartool` module >> - [x] Remove `CommandLine.java` from `jdk.jlink` module >> - [x] Remove `CommandLine.java` from `jdk.jpackage` module >> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Remove superseded comment Marked as reviewed by jjg (Reviewer). src/jdk.internal.opt/share/classes/jdk/internal/opt/CommandLine.java line 49: > 47: * > 48: *

      This is NOT part of any supported API. > 49: * If you write code that depends on this, you do so at your own risk. I think this entire paragraph can be removed. It is "just" the "scary warning" meant to warn people about using not-really-public classes in javac, before we had a module system for the encapsulation. ------------- PR: https://git.openjdk.org/jdk/pull/11272 From aph at openjdk.org Tue Nov 22 17:23:59 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 22 Nov 2022 17:23:59 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v18] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Remove incorrect assertion. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/04320c7b..afad922c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=16-17 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 22 17:27:14 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 22 Nov 2022 17:27:14 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v19] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/cpu/aarch64/aarch64.ad Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/afad922c..7c49e676 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 22 17:31:05 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 22 Nov 2022 17:31:05 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v20] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/Thread.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/7c49e676..b06ea927 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=18-19 Stats: 8 lines in 1 file changed: 5 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Tue Nov 22 17:34:22 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 22 Nov 2022 17:34:22 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v21] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with three additional commits since the last revision: - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 - Update src/java.base/share/classes/java/lang/VirtualThread.java Co-authored-by: Alan Bateman - Feedback from reviewers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/b06ea927..dc577736 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=19-20 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From duke at openjdk.org Tue Nov 22 19:28:27 2022 From: duke at openjdk.org (ExE Boss) Date: Tue, 22 Nov 2022 19:28:27 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v9] In-Reply-To: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com> References: <4rNr-0R3QzfPSfR_8nAJ9o3Vo38vaKIQfzu0-HRv0pc=.c6af0e66-cc9e-4958-8f80-99b657e054f5@github.com> Message-ID: <-3UxCy1TSFrc9DMZZMdsiUpX7i3wOmiTRTHpyRKEjYs=.54eef999-bad4-49ce-9c66-d45fd16fe9b5@github.com> On Tue, 22 Nov 2022 13:49:45 GMT, Per Minborg wrote: >> src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java line 914: >> >>> 912: * If so, make a copy to put the dst data in. >>> 913: */ >>> 914: @SuppressWarnings("try") >> >> After looking at the implementation some more, I'm not sure this need fixing? E.g. this method is just using the address to compute some overlap - and return a buffer sliced accordingly. There's no access to the buffer data (except for the last part which does a `put`). The access will fail if the session is closed from underneath. I don't think this can crash the VM (in fact this code did not have a reachability fence to begin with). > > Well spotted. I will remove the guarding here. This?`@SuppressWarnings` annotation is?no?longer?needed: Suggestion: ------------- PR: https://git.openjdk.org/jdk/pull/11260 From rriggs at openjdk.org Tue Nov 22 19:33:07 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 22 Nov 2022 19:33:07 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> References: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> Message-ID: On Mon, 21 Nov 2022 17:43:16 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Seal Digits Javadoc suggestions around readability, linking. src/java.base/share/classes/java/lang/template/StringProcessor.java line 58: > 56: /** > 57: * Constructs a {@link String} based on the template fragments and values in the > 58: * supplied {@link StringTemplate stringTemplate} object. When reading the javadoc, I expected the type name, not the variable name. Suggestion: * supplied {@link StringTemplate StringTemplate} object. src/java.base/share/classes/java/lang/template/StringTemplate.java line 52: > 50: * given by the template expression. > 51: *

      > 52: * For example, the following code contains a template expression that uses the template Though this is trying to explain the general mechanism, it might be more useful to readers to start with the most common use case, that of using a string processor. Swapping the order of the examples possibly. src/java.base/share/classes/java/lang/template/StringTemplate.java line 63: > 61: * {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")}, > 62: * which includes the empty first and last fragments. {@code values} will be the > 63: * equivalent of {@code List.of(10, 20, 30)}. Find a way to capitalize the first word of the sentence. Suggestion: * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")}, * which includes the empty first and last fragments. The {@code values} will be the * equivalent of {@code List.of(10, 20, 30)}. src/java.base/share/classes/java/lang/template/StringTemplate.java line 66: > 64: *

      > 65: * The following code contains a template expression with the same template but a > 66: * different template processor: Suggestion: * The following code contains a template expression with the same template but a * string template processor: src/java.base/share/classes/java/lang/template/StringTemplate.java line 75: > 73: * produced that returns the same lists from {@link StringTemplate#fragments()} and > 74: * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template > 75: * processor uses these lists to yield an interpolated string. {@code s} will be equivalent to Suggestion: * processor uses these lists to yield an interpolated string. The value of {@code s} will be equivalent to src/java.base/share/classes/java/lang/template/StringTemplate.java line 319: > 317: * This {@link StringProcessor} instance is conventionally used for the string interpolation > 318: * of a supplied {@link StringTemplate}. > 319: *

      It should be mentioned that the string representations are created as if invoking {@link String#valueOf}. An perhaps a link/@see to `FMT` for control over formatting. Also include it in the javadoc for `interpolate`. src/java.base/share/classes/java/lang/template/package-info.java line 57: > 55: *{@link java.lang.template.StringTemplate}. The end result of the process template > 56: * expression is the value that is produced by invoking the processor's > 57: *{@link java.lang.template.ValidatingProcessor#process(StringTemplate)} I would reduce the use of "proper", it should be sufficient to describe them without the qualifier. The single use of "improper" is fine to warn of compilation errors. Also, add a space between "*" and "{". src/java.base/share/classes/java/lang/template/package-info.java line 61: > 59: * improper processor arguments result in compilation errors. > 60: *

      > 61: * In the example, {@code STR."The result of adding \{x} and \{y} is \{x + y}."}, Maybe avoid the repetition of the example. Suggestion: * In the example above, src/java.base/share/classes/java/lang/template/package-info.java line 76: > 74: * String literals and text blocks can be used as proper processor arguments as > 75: * well. This is automatically facilitated by the Java compiler converted the > 76: * strings to {@link java.lang.template.StringTemplate StringTemplate} using the Suggestion: * well. This is automatically facilitated by the Java compiler converting the * strings to {@link java.lang.template.StringTemplate StringTemplate} using the src/java.base/share/classes/java/lang/template/package-info.java line 79: > 77: * {@link java.lang.template.StringTemplate#of(String)} method. > 78: *

      > 79: * Users can create their own template processors by implementing either Suggestion: * Users can create their own template processors by implementing one of src/java.base/share/classes/java/lang/template/package-info.java line 83: > 81: * {@link java.lang.template.TemplateProcessor} or > 82: * {@link java.lang.template.StringProcessor} interfaces. > 83: * See {@link java.lang.template.ValidatingProcessor} for examples and details. I would give the reader a firm what to read next suggestion. It may be useful to mention and link to the `FMT` processor as a way to control the formatting of the values. Suggestion: * For more examples and details see {@link java.lang.template.StringTemplate} and * {@link java.lang.template.ValidatingProcessor}. src/java.base/share/classes/java/util/FormatProcessor.java line 64: > 62: * > 63: * @implSpec Since, values are found within the string template, argument indexing > 64: * specifiers are unsupported. What is the behavior of a format that references an index? Ignored, throw? I can see an argument for simplicity, but the values are a sequential list similar to that of a varargs call to format("xx", x, y, z, ...) so it can be well defined to what value an index in the format refers. src/java.base/share/classes/java/util/FormatProcessor.java line 196: > 194: * format specifier. > 195: * StringTemplate expressions without a preceeding specifier, use "%s" by > 196: Its worth specifying the locale that is used by FMT, is it `Locale.ROOT`? If it is `Locale.default`, the results may vary from run to run. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Tue Nov 22 19:58:59 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 22 Nov 2022 19:58:59 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: References: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> Message-ID: On Tue, 22 Nov 2022 18:17:28 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Seal Digits > > src/java.base/share/classes/java/lang/template/package-info.java line 57: > >> 55: *{@link java.lang.template.StringTemplate}. The end result of the process template >> 56: * expression is the value that is produced by invoking the processor's >> 57: *{@link java.lang.template.ValidatingProcessor#process(StringTemplate)} > > I would reduce the use of "proper", it should be sufficient to describe them without the qualifier. > The single use of "improper" is fine to warn of compilation errors. > > Also, add a space between "*" and "{". Changing. > src/java.base/share/classes/java/lang/template/package-info.java line 61: > >> 59: * improper processor arguments result in compilation errors. >> 60: *

      >> 61: * In the example, {@code STR."The result of adding \{x} and \{y} is \{x + y}."}, > > Maybe avoid the repetition of the example. > Suggestion: > > * In the example above, Changing. > src/java.base/share/classes/java/lang/template/package-info.java line 76: > >> 74: * String literals and text blocks can be used as proper processor arguments as >> 75: * well. This is automatically facilitated by the Java compiler converted the >> 76: * strings to {@link java.lang.template.StringTemplate StringTemplate} using the > > Suggestion: > > * well. This is automatically facilitated by the Java compiler converting the > * strings to {@link java.lang.template.StringTemplate StringTemplate} using the Changing. > src/java.base/share/classes/java/lang/template/package-info.java line 79: > >> 77: * {@link java.lang.template.StringTemplate#of(String)} method. >> 78: *

      >> 79: * Users can create their own template processors by implementing either > > Suggestion: > > * Users can create their own template processors by implementing one of Changing. > src/java.base/share/classes/java/lang/template/package-info.java line 83: > >> 81: * {@link java.lang.template.TemplateProcessor} or >> 82: * {@link java.lang.template.StringProcessor} interfaces. >> 83: * See {@link java.lang.template.ValidatingProcessor} for examples and details. > > I would give the reader a firm what to read next suggestion. > It may be useful to mention and link to the `FMT` processor as a way to control the formatting of the values. > Suggestion: > > * For more examples and details see {@link java.lang.template.StringTemplate} and > * {@link java.lang.template.ValidatingProcessor}. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Tue Nov 22 20:09:11 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 22 Nov 2022 20:09:11 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: References: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> Message-ID: On Tue, 22 Nov 2022 18:33:23 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Seal Digits > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 52: > >> 50: * given by the template expression. >> 51: *

      >> 52: * For example, the following code contains a template expression that uses the template > > Though this is trying to explain the general mechanism, it might be more useful to readers to start with the most common use case, that of using a string processor. Swapping the order of the examples possibly. The issue is that most users will not see a StringTemplate object. If they've come here then they want to see the inner workings. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 63: > >> 61: * {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")}, >> 62: * which includes the empty first and last fragments. {@code values} will be the >> 63: * equivalent of {@code List.of(10, 20, 30)}. > > Find a way to capitalize the first word of the sentence. > Suggestion: > > * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")}, > * which includes the empty first and last fragments. The {@code values} will be the > * equivalent of {@code List.of(10, 20, 30)}. Changing. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 66: > >> 64: *

      >> 65: * The following code contains a template expression with the same template but a >> 66: * different template processor: > > Suggestion: > > * The following code contains a template expression with the same template but a > * string template processor: Changing. Missing "with" as well. > src/java.base/share/classes/java/lang/template/StringTemplate.java line 75: > >> 73: * produced that returns the same lists from {@link StringTemplate#fragments()} and >> 74: * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template >> 75: * processor uses these lists to yield an interpolated string. {@code s} will be equivalent to > > Suggestion: > > * processor uses these lists to yield an interpolated string. The value of {@code s} will be equivalent to Changing. > src/java.base/share/classes/java/util/FormatProcessor.java line 196: > >> 194: * format specifier. >> 195: * StringTemplate expressions without a preceeding specifier, use "%s" by >> 196: > > Its worth specifying the locale that is used by FMT, is it `Locale.ROOT`? > If it is `Locale.default`, the results may vary from run to run. Okay. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Tue Nov 22 20:19:02 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Tue, 22 Nov 2022 20:19:02 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: References: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> Message-ID: <2GJrLatDQGRght0hyld2P5-AQfPrTvcshddE93uT5Oo=.85cc51dc-32eb-4bb5-b10b-5708b74c0776@github.com> On Tue, 22 Nov 2022 18:43:53 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Seal Digits > > src/java.base/share/classes/java/lang/template/StringProcessor.java line 58: > >> 56: /** >> 57: * Constructs a {@link String} based on the template fragments and values in the >> 58: * supplied {@link StringTemplate stringTemplate} object. > > When reading the javadoc, I expected the type name, not the variable name. > Suggestion: > > * supplied {@link StringTemplate StringTemplate} object. Changing. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From chegar999 at gmail.com Tue Nov 22 20:27:25 2022 From: chegar999 at gmail.com (Chris Hegarty) Date: Tue, 22 Nov 2022 20:27:25 +0000 Subject: JDK 19 innocuous reaper threads In-Reply-To: References: <8e745203-e5c8-4ffd-2ca4-be030f9f71c3@gmail.com> <399bebbc-f56e-4557-773a-fe91b3ffb737@oracle.com> <720dc5b8-1c2c-d624-7423-c9d127e6234e@gmail.com> Message-ID: <11025a5e-90ac-e491-9099-a36849ed057d@gmail.com> Thanks you Alan and Roger. I filed the following issue to track this: https://bugs.openjdk.org/browse/JDK-8297451 There are likely many more usages of innocuous thread that could be improved by ensuring setDaemon is invoked while asserting privileges, but I'd like to leave those to a later issue, since the usage in process is causing us issues right now, and it would be great to get this fixed (and eventually backported to 19.0.2). -Chris. On 22/11/2022 17:01, Roger Riggs wrote: > Hi Chris, > > Yes, adding a doPriv for setDaemon and setName in a couple of places > makes sense. > > Thanks, Roger > > > On 11/22/22 11:12 AM, Chris Hegarty wrote: >> Hi Alan, >> >> On 22/11/2022 16:08, Alan Bateman wrote: >>> On 22/11/2022 15:21, Chris Hegarty wrote: >>>> .. >>> >>> Just to double check, does the ES security manager override >>> checkAccess(Thread)? >> >> Yes. :-( >> >>> That is usually a no-op but if overridden then it will expose an >>> issue with the thread factory for the "process reaper" where it >>> attempts changes the daemon status outside of a doPriv block. >> >> Right. That's exactly what we're running into. >> >> If there are no objections, then I'm happy to file an issue >> and PR to add narrow doPriv blocks around these calls. >> >> -Chris >> >> [1] >> https://github.com/elastic/elasticsearch/blob/main/libs/secure-sm/src/main/java/org/elasticsearch/secure_sm/SecureSM.java#L118 >> > From jjg at openjdk.org Tue Nov 22 22:04:57 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Tue, 22 Nov 2022 22:04:57 GMT Subject: RFR: 8296546: Add @spec tags to API [v2] In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Prefix RFC titles with `RFC NNNN:` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11073/files - new: https://git.openjdk.org/jdk/pull/11073/files/30ce235f..c29092d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=00-01 Stats: 325 lines in 165 files changed: 4 ins; 4 del; 317 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From dholmes at openjdk.org Tue Nov 22 22:26:24 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 22 Nov 2022 22:26:24 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v4] In-Reply-To: References: Message-ID: <75GEEMZlcZqCOSDaWQu4XgoOY4sDM2MBxep2ZH6f8hA=.e68d75e0-0ef8-4629-977b-f9742f228ef5@github.com> On Tue, 22 Nov 2022 00:50:51 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Update Runtime class doc re: other unexpected behaviors src/java.base/share/classes/java/lang/Runtime.java line 97: > 95: * no {@code finally} clause of any method is executed, and try-with-resources > 96: * blocks do not {@linkplain AutoCloseable close} their resources. > 97: * Other unexpected behaviors may also result. No sorry that doesn't work for me. It sounds like you might get unexpected things happening, when in fact it is things not happening that might surprise someone (who doesn't understand what "immediately prevented from executing any further Java code" means). The list of examples is getting too long to handle in sentence structure so I suggest an actual list (not sure of list syntax). Suggestion: * Java code. This includes shutdown hooks as well as daemon and non-daemon threads. This * means, for example, that: * - threads' current methods do not complete normally or abruptly * - no {@code finally} clause of any method is executed * - no {@linkplain Thread.UncaughtExceptionHandler uncaught exception handler} is executed * - no try-with-resources blocks {@linkplain AutoCloseable close} their resources ------------- PR: https://git.openjdk.org/jdk/pull/11218 From sspitsyn at openjdk.org Wed Nov 23 00:32:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 23 Nov 2022 00:32:53 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 Message-ID: This problem has two sides. One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` value has been set to `true` when an agent library is loaded into running VM. The fix is to get rid of this cashing. Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. Testing: The originally failed tests are passed now: runtime/vthread/RedefineClass.java runtime/vthread/TestObjectAllocationSampleEvent.java In progress: Run the tiers 1-6 to make sure there are no regression. ------------- Commit messages: - 8297286: runtime/vthread tests crashing after JDK-8296324 Changes: https://git.openjdk.org/jdk/pull/11304/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11304&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297286 Stats: 6 lines in 3 files changed: 1 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11304.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11304/head:pull/11304 PR: https://git.openjdk.org/jdk/pull/11304 From lmesnik at openjdk.org Wed Nov 23 02:21:10 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 23 Nov 2022 02:21:10 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 00:24:28 GMT, Serguei Spitsyn wrote: > This problem has two sides. > One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. > It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` > value has been set to `true` when an agent library is loaded into running VM. > The fix is to get rid of this cashing. > Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. > Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. > The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. > > Testing: > The originally failed tests are passed now: > > runtime/vthread/RedefineClass.java > runtime/vthread/TestObjectAllocationSampleEvent.java > > In progress: > Run the tiers 1-6 to make sure there are no regression. Marked as reviewed by lmesnik (Reviewer). src/java.base/share/classes/java/lang/VirtualThread.java line 273: > 271: private void run(Runnable task) { > 272: assert state == RUNNING; > 273: boolean notifyJvmti = notifyJvmtiEvents; Don't we have same issue in yieldContinuation() method? (line 396) ------------- PR: https://git.openjdk.org/jdk/pull/11304 From lmesnik at openjdk.org Wed Nov 23 02:24:28 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 23 Nov 2022 02:24:28 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 00:24:28 GMT, Serguei Spitsyn wrote: > This problem has two sides. > One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. > It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` > value has been set to `true` when an agent library is loaded into running VM. > The fix is to get rid of this cashing. > Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. > Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. > The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. > > Testing: > The originally failed tests are passed now: > > runtime/vthread/RedefineClass.java > runtime/vthread/TestObjectAllocationSampleEvent.java > > In progress: > Run the tiers 1-6 to make sure there are no regression. Needed to check yieldContinuation() method for same issue. ------------- Changes requested by lmesnik (Reviewer). PR: https://git.openjdk.org/jdk/pull/11304 From duke at openjdk.org Wed Nov 23 02:52:34 2022 From: duke at openjdk.org (Bo Zhang) Date: Wed, 23 Nov 2022 02:52:34 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 13:23:03 GMT, Jorn Vernee wrote: >> Bo Zhang has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: >> >> 8296329: Only compare major versions in jar validator > > Marked as reviewed by jvernee (Reviewer). @JornVernee can you please sponsor this PR? ------------- PR: https://git.openjdk.org/jdk/pull/11153 From jvernee at openjdk.org Wed Nov 23 03:04:33 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 23 Nov 2022 03:04:33 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 02:50:26 GMT, Bo Zhang wrote: >> Marked as reviewed by jvernee (Reviewer). > > @JornVernee can you please sponsor this PR? @blindpirate Yes. If you `/integrate` it, I can then `/sponsor`. ------------- PR: https://git.openjdk.org/jdk/pull/11153 From duke at openjdk.org Wed Nov 23 03:10:44 2022 From: duke at openjdk.org (Bo Zhang) Date: Wed, 23 Nov 2022 03:10:44 GMT Subject: RFR: 8296329: jar validator doesn't account for minor class file version [v2] In-Reply-To: References: Message-ID: <3zWUu4_htVwRRuA8ekMWUf8CSB0fVDl5j2-MEHrLqpY=.7987cebe-4b22-4ad4-8130-adbd5404ae93@github.com> On Wed, 23 Nov 2022 03:01:51 GMT, Jorn Vernee wrote: >> @JornVernee can you please sponsor this PR? > > @blindpirate Yes. If you `/integrate` it, I can then `/sponsor`. Thanks @JornVernee ! ------------- PR: https://git.openjdk.org/jdk/pull/11153 From duke at openjdk.org Wed Nov 23 03:12:35 2022 From: duke at openjdk.org (Bo Zhang) Date: Wed, 23 Nov 2022 03:12:35 GMT Subject: Integrated: 8296329: jar validator doesn't account for minor class file version In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 01:52:14 GMT, Bo Zhang wrote: > As described in [JDK-8296329](https://bugs.openjdk.org/browse/JDK-8296329), previously, the jar validator compare the "version" to validate a multi-release jar. The "version" is a mix of the major and minor version fused into a single int, which might be a negative number with `--enable-preview` - this result in wrong comparison. > > This PR fixes it by only comparing major versions. This pull request has now been integrated. Changeset: faf48e61 Author: Bo Zhang Committer: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/faf48e61be4f97f725b053aa351d3c64638546bf Stats: 127 lines in 3 files changed: 123 ins; 1 del; 3 mod 8296329: jar validator doesn't account for minor class file version Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/11153 From kbarrett at openjdk.org Wed Nov 23 05:02:09 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 23 Nov 2022 05:02:09 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: Message-ID: <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com> On Mon, 21 Nov 2022 02:43:12 GMT, Julian Waters wrote: > Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? [...] A PR to address JDK-8252584 would be welcomed by me. Just do the process for Style Guide changes (see the Style Guide or previous PRs for such). I don't expect it would be very controversial. I think the only reason it hasn't already happened is because nobody has gotten around to it, or felt the need for it. JDK-8250269 touches a bit more code (mostly in stubGenerator_x86_64 and macroAssembler_x86_32), but also seems like it should be straightforward. > > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED. > > The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing) You are right that the Windows-conditionalized uses are in non-HotSpot code. I missed that context when skimming through the changes. Since Visual Studio is always C++ (even though the shared files are written as C), using alignas with appropriate conditionalization in those files should be fine. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From duke at openjdk.org Wed Nov 23 05:09:46 2022 From: duke at openjdk.org (Ryan Ernst) Date: Wed, 23 Nov 2022 05:09:46 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread Message-ID: This commit guards thread modifications for the process reaper thread with doPrivileged. ------------- Commit messages: - 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread Changes: https://git.openjdk.org/jdk/pull/11309/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11309&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297451 Stats: 31 lines in 2 files changed: 19 ins; 1 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11309.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11309/head:pull/11309 PR: https://git.openjdk.org/jdk/pull/11309 From kbarrett at openjdk.org Wed Nov 23 05:24:24 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 23 Nov 2022 05:24:24 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> Message-ID: On Mon, 14 Nov 2022 12:20:54 GMT, Julian Waters wrote: >> Sorry my eyes must be playing tricks on me. ?? >> >> Why did you need to add this here? > > It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11: > >> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage. > > While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead: > >> ?11.3/4 [class.friend] > A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1). I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From duke at openjdk.org Wed Nov 23 06:49:56 2022 From: duke at openjdk.org (Dongxu Wang) Date: Wed, 23 Nov 2022 06:49:56 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc [v2] In-Reply-To: References: Message-ID: > 8297385: Remove duplicated null typos in javadoc Dongxu Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'openjdk:master' into master - Minor remove duplicate null typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11169/files - new: https://git.openjdk.org/jdk/pull/11169/files/65327c89..f731384b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11169&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11169&range=00-01 Stats: 44876 lines in 726 files changed: 16653 ins; 16626 del; 11597 mod Patch: https://git.openjdk.org/jdk/pull/11169.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11169/head:pull/11169 PR: https://git.openjdk.org/jdk/pull/11169 From yyang at openjdk.org Wed Nov 23 06:49:56 2022 From: yyang at openjdk.org (Yi Yang) Date: Wed, 23 Nov 2022 06:49:56 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 06:45:26 GMT, Dongxu Wang wrote: >> 8297385: Remove duplicated null typos in javadoc > > Dongxu Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into master > - Minor remove duplicate null typo This looks good, but I'm not a Reviewer, you still need an approval from Reviewer. ------------- Marked as reviewed by yyang (Committer). PR: https://git.openjdk.org/jdk/pull/11169 From duke at openjdk.org Wed Nov 23 07:03:02 2022 From: duke at openjdk.org (Dongxu Wang) Date: Wed, 23 Nov 2022 07:03:02 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 06:43:56 GMT, Yi Yang wrote: > This looks good, but I'm not a Reviewer, you still need an approval from Reviewer. Thanks ------------- PR: https://git.openjdk.org/jdk/pull/11169 From duke at openjdk.org Wed Nov 23 07:03:05 2022 From: duke at openjdk.org (Dongxu Wang) Date: Wed, 23 Nov 2022 07:03:05 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 06:49:56 GMT, Dongxu Wang wrote: >> 8297385: Remove duplicated null typos in javadoc > > Dongxu Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into master > - Minor remove duplicate null typo Use #11311 instead, close this pr. ------------- PR: https://git.openjdk.org/jdk/pull/11169 From duke at openjdk.org Wed Nov 23 07:03:06 2022 From: duke at openjdk.org (Dongxu Wang) Date: Wed, 23 Nov 2022 07:03:06 GMT Subject: Withdrawn: 8297385: Remove duplicated null typos in javadoc In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 15:05:45 GMT, Dongxu Wang wrote: > 8297385: Remove duplicated null typos in javadoc This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11169 From duke at openjdk.org Wed Nov 23 07:07:50 2022 From: duke at openjdk.org (Dongxu Wang) Date: Wed, 23 Nov 2022 07:07:50 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc Message-ID: 8297385: Remove duplicated null typos in javadoc ------------- Commit messages: - 8297385: Remove duplicated null typo in javadoc Changes: https://git.openjdk.org/jdk/pull/11311/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11311&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297385 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11311.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11311/head:pull/11311 PR: https://git.openjdk.org/jdk/pull/11311 From chegar at openjdk.org Wed Nov 23 08:37:39 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 23 Nov 2022 08:37:39 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 05:01:40 GMT, Ryan Ernst wrote: > This commit guards thread modifications for the process reaper thread with doPrivileged. Hi @rjernst Thanks for taking this one on. I agree with adding the privileged blocks around the calls to Thread::setName, but the usage raises a warning which fails the build. It might be cleaner and easier to refactor into a privilegedThreadSetName helper method. Additionally, I noticed that there is an existing test that can be modified slightly to cover this. I've put these two comments / suggestions in the form of a PR and raised it against your branch. https://github.com/rjernst/jdk/pull/1 ------------- PR: https://git.openjdk.org/jdk/pull/11309 From chegar at openjdk.org Wed Nov 23 08:42:28 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 23 Nov 2022 08:42:28 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 05:01:40 GMT, Ryan Ernst wrote: > This commit guards thread modifications for the process reaper thread with doPrivileged. Changes requested by chegar (Reviewer). src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 137: > 135: public static Thread newSystemThread(String name, Runnable target, > 136: long stackSize, int priority, > 137: boolean daemon) { Thanks for adding this overload, I think that it will be useful for the future too. ( it never seems to matter how many variants of these factories we have, we still need one more :-) ) ------------- PR: https://git.openjdk.org/jdk/pull/11309 From sspitsyn at openjdk.org Wed Nov 23 10:03:22 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 23 Nov 2022 10:03:22 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 02:17:43 GMT, Leonid Mesnik wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > src/java.base/share/classes/java/lang/VirtualThread.java line 273: > >> 271: private void run(Runnable task) { >> 272: assert state == RUNNING; >> 273: boolean notifyJvmti = notifyJvmtiEvents; > > Don't we have same issue in yieldContinuation() method? (line 396) Good point. I'll check and make an update if needed. Thank you for looking at it. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From sspitsyn at openjdk.org Wed Nov 23 10:14:23 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 23 Nov 2022 10:14:23 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: > This problem has two sides. > One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. > It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` > value has been set to `true` when an agent library is loaded into running VM. > The fix is to get rid of this cashing. > Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. > Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. > The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. > > Testing: > The originally failed tests are passed now: > > runtime/vthread/RedefineClass.java > runtime/vthread/TestObjectAllocationSampleEvent.java > > In progress: > Run the tiers 1-6 to make sure there are no regression. Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: remove caching if notifyJvmtiEvents in yieldContinuation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11304/files - new: https://git.openjdk.org/jdk/pull/11304/files/c0d2f0ef..6608b1a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11304&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11304&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11304.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11304/head:pull/11304 PR: https://git.openjdk.org/jdk/pull/11304 From sspitsyn at openjdk.org Wed Nov 23 10:18:59 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 23 Nov 2022 10:18:59 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 10:01:07 GMT, Serguei Spitsyn wrote: >> src/java.base/share/classes/java/lang/VirtualThread.java line 273: >> >>> 271: private void run(Runnable task) { >>> 272: assert state == RUNNING; >>> 273: boolean notifyJvmti = notifyJvmtiEvents; >> >> Don't we have same issue in yieldContinuation() method? (line 396) > > Good point. I'll check and make an update if needed. > Thank you for looking at it. Fixed the `yieldContinuation()` method. There is also `switchToCarrierThread()` method that returns the `notifyJvmtiEvents` value. It seems to be an optimization. I'm not sure yet, if we need to fix these places as well. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From alanb at openjdk.org Wed Nov 23 10:33:22 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 23 Nov 2022 10:33:22 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 10:16:44 GMT, Serguei Spitsyn wrote: > There is also `switchToCarrierThread()` method that returns the `notifyJvmtiEvents` value. > It seems to be an optimization. I'm not sure yet, if we need to fix these places as well. It was to ensure that hide(true) and hide(false) are balanced. If it were to re-poll notifyJvmtiEvents and a JVMTI agent enables the capability while a thread in doing a temporary transition then you may get a hide(false) without the corresponding hide(true). ------------- PR: https://git.openjdk.org/jdk/pull/11304 From mcimadamore at openjdk.org Wed Nov 23 10:54:53 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 23 Nov 2022 10:54:53 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v30] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix bit vs. byte mismatch in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/66dd888d..3c75e097 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=28-29 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From pminborg at openjdk.org Wed Nov 23 12:21:07 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 23 Nov 2022 12:21:07 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v11] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Refactor to try-finally handling ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/06c764ca..88ae68b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=09-10 Stats: 677 lines in 20 files changed: 286 ins; 152 del; 239 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From dfuchs at openjdk.org Wed Nov 23 12:27:24 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 23 Nov 2022 12:27:24 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc In-Reply-To: References: Message-ID: <3hCQ6aL9k6nVWhfnOTMfLXWGRTC81EUbcxL8l5d2T7E=.24cd4617-e271-4b50-a189-69093a221296@github.com> On Wed, 23 Nov 2022 06:58:09 GMT, Dongxu Wang wrote: > 8297385: Remove duplicated null typos in javadoc LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11311 From pminborg at openjdk.org Wed Nov 23 12:39:40 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 23 Nov 2022 12:39:40 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v12] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/88ae68b8..682b6f5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=10-11 Stats: 23 lines in 9 files changed: 1 ins; 1 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From dfuchs at openjdk.org Wed Nov 23 12:47:43 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 23 Nov 2022 12:47:43 GMT Subject: RFR: 8296546: Add @spec tags to API [v2] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com> On Tue, 22 Nov 2022 22:04:57 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Prefix RFC titles with `RFC NNNN:` Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jlaskey at openjdk.org Wed Nov 23 12:58:04 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 23 Nov 2022 12:58:04 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: References: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> Message-ID: On Tue, 22 Nov 2022 19:09:12 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Seal Digits > > src/java.base/share/classes/java/lang/template/StringTemplate.java line 319: > >> 317: * This {@link StringProcessor} instance is conventionally used for the string interpolation >> 318: * of a supplied {@link StringTemplate}. >> 319: *

      > > It should be mentioned that the string representations are created as if invoking {@link String#valueOf}. > An perhaps a link/@see to `FMT` for control over formatting. > > Also include it in the javadoc for `interpolate`. Changing. > src/java.base/share/classes/java/util/FormatProcessor.java line 64: > >> 62: * >> 63: * @implSpec Since, values are found within the string template, argument indexing >> 64: * specifiers are unsupported. > > What is the behavior of a format that references an index? Ignored, throw? > I can see an argument for simplicity, but the values are a sequential list similar to that of a varargs call to format("xx", x, y, z, ...) so it can be well defined to what value an index in the format refers. Kind of blows the whole concept of embedded expressions. This is one of those, just because you can, doesn't mean you should. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From duke at openjdk.org Wed Nov 23 13:08:56 2022 From: duke at openjdk.org (duke) Date: Wed, 23 Nov 2022 13:08:56 GMT Subject: Withdrawn: 8292937: Improve performance of some read operations of RandomAccessFile In-Reply-To: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com> References: <8__MBgqmZ3VCnm2AIMjwSWk3Zk-cv1XSDpEg-iguvKs=.1b823502-0735-4ae8-bc7e-3ceb5e44f986@github.com> Message-ID: On Thu, 25 Aug 2022 17:14:20 GMT, Sergey Tsypanov wrote: > Currently some operations of RandomAccessFile are implemented with multiple read() invocations: > > public final int readInt() throws IOException { > int ch1 = this.read(); > int ch2 = this.read(); > int ch3 = this.read(); > int ch4 = this.read(); > if ((ch1 | ch2 | ch3 | ch4) < 0) > throw new EOFException(); > return ((ch1 << 24) + (ch2 << 16) + (ch3 << 8) + (ch4 << 0)); > } > > This can be improved by using bulk reads: > > public final int readInt() throws IOException { > readFully(readBuffer, 0, 4); > return Bits.getInt(readBuffer, 0); > } > > Benchmarking: > > baselile > Benchmark (kiloBytes) Mode Cnt Score Error Units > RandomAccessFileReadBenchmark.readInt 1 avgt 10 1060,526 ? 62,036 us/op > RandomAccessFileReadBenchmark.readInt 5 avgt 10 5745,671 ? 1374,277 us/op > RandomAccessFileReadBenchmark.readLong 1 avgt 10 1399,494 ? 378,072 us/op > RandomAccessFileReadBenchmark.readLong 5 avgt 10 4864,425 ? 329,282 us/op > RandomAccessFileReadBenchmark.readShort 1 avgt 10 1111,163 ? 70,883 us/op > RandomAccessFileReadBenchmark.readShort 5 avgt 10 4933,058 ? 339,273 us/op > > patch > Benchmark (kiloBytes) Mode Cnt Score Error Units > RandomAccessFileReadBenchmark.readInt 1 avgt 10 311,404 ? 17,337 us/op > RandomAccessFileReadBenchmark.readInt 5 avgt 10 1210,381 ? 22,742 us/op > RandomAccessFileReadBenchmark.readLong 1 avgt 10 201,726 ? 8,885 us/op > RandomAccessFileReadBenchmark.readLong 5 avgt 10 667,117 ? 6,779 us/op > RandomAccessFileReadBenchmark.readShort 1 avgt 10 560,259 ? 16,783 us/op > RandomAccessFileReadBenchmark.readShort 5 avgt 10 2251,975 ? 54,533 us/op This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10031 From jlaskey at openjdk.org Wed Nov 23 13:16:30 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 23 Nov 2022 13:16:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v29] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Requested changes #12 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/da3ea20d..e9f52f2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=27-28 Stats: 32 lines in 4 files changed: 12 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 23 13:55:38 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 23 Nov 2022 13:55:38 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v30] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update @since ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/e9f52f2f..09f1ac08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=28-29 Stats: 27 lines in 19 files changed: 0 ins; 0 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From aph at openjdk.org Wed Nov 23 14:16:35 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 14:16:35 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v15] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 17:31:30 GMT, Alan Bateman wrote: >> Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: >> >> - Reviewer feedback >> - Reviewer feedback Javadoc fixes > > src/java.base/share/classes/java/lang/Thread.java line 789: > >> 787: >> 788: // special value to mean a new thread >> 789: this.scopedValueBindings = NEW_THREAD_BINDINGS; > > Can we change the comment on this one to be the same as the other constructor? Done. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 23 14:22:28 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 14:22:28 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v6] In-Reply-To: References: <8Gol6phltQIqgGpXbVDn_iUDtqyRm8NKy_U63w2oQ8g=.ba7a834d-bb03-4a20-ae69-4371068f1439@github.com> Message-ID: <-BdUpu_Zl8KQtodaCeDyz4zhcQhuyI7Z1ujcqg7-c8Q=.25c08e24-cc8f-4dda-b78a-dd85c6d32d66@github.com> On Wed, 16 Nov 2022 13:13:59 GMT, Alan Bateman wrote: >> Note?that `ScopedValue` can?currently be?bound to?`null`, but?by?using `Optional`, there?would be?no?way to?differentiate an?unbound `ScopedValue` from?one bound?to?`null`. > >> Note?that `ScopedValue` can?currently be?bound to?`null`, but?by?using `Optional`, there?would be?no?way to?differentiate an?unbound `ScopedValue` from?one bound?to?`null`. > > That's right, an Optional view would have to deal with that. OK, so unless anyone has any /strong/ objections I'll mark this as Resolved. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 23 14:33:48 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 14:33:48 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v22] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/classfile/vmSymbols.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/dc577736..b28ca4d2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=20-21 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 23 14:33:51 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 14:33:51 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v21] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 17:34:22 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with three additional commits since the last revision: > > - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 > - Update src/java.base/share/classes/java/lang/VirtualThread.java > > Co-authored-by: Alan Bateman > - Feedback from reviewers src/hotspot/share/classfile/vmSymbols.hpp line 612: > 610: template(thread_throwable_void_signature, "(Ljava/lang/Thread;Ljava/lang/Throwable;)V") \ > 611: template(thread_void_signature, "(Ljava/lang/Thread;)V") \ > 612: template(runnable_void_signature, "(Ljava/lang/Runnable;)V") \ Suggestion: template(runnable_void_signature, "(Ljava/lang/Runnable;)V") \ ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 23 14:38:52 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 14:38:52 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v23] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Feedback from reviewers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/b28ca4d2..7ac61ba2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=21-22 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From rriggs at openjdk.org Wed Nov 23 15:20:49 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 23 Nov 2022 15:20:49 GMT Subject: RFR: 8297385: Remove duplicated null typos in javadoc In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 06:58:09 GMT, Dongxu Wang wrote: > 8297385: Remove duplicated null typos in javadoc Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11311 From rriggs at openjdk.org Wed Nov 23 15:30:38 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 23 Nov 2022 15:30:38 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 08:38:02 GMT, Chris Hegarty wrote: >> This commit guards thread modifications for the process reaper thread with doPrivileged. > > src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 137: > >> 135: public static Thread newSystemThread(String name, Runnable target, >> 136: long stackSize, int priority, >> 137: boolean daemon) { > > Thanks for adding this overload, I think that it will be useful for the future too. ( it never seems to matter how many variants of these factories we have, we still need one more :-) ) I would prefer to to avoid creating new factories when the desired function can be done on the resulting thread. Such as `setDaemon()` and `setName()`, etc. It does avoid the doPriv in this case, but is not necessary and when the security manager goes away, will leave around clutter (duplicated) functionality. ------------- PR: https://git.openjdk.org/jdk/pull/11309 From rriggs at openjdk.org Wed Nov 23 15:41:12 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 23 Nov 2022 15:41:12 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v30] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 13:55:38 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update @since > /issue add JDK-8296302 The BOT comment at the top says /issue cannot refer to a CSR. You'll need to /issue remove it before integration. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From cstein at openjdk.org Wed Nov 23 15:59:42 2022 From: cstein at openjdk.org (Christian Stein) Date: Wed, 23 Nov 2022 15:59:42 GMT Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools [v3] In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> Message-ID: > This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: > - `jdk.jartool` > - `jdk.jlink` > - `jdk.jpackage` > > Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. > > - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". > - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". > - [x] Remove `CommandLine.java` from `jdk.jartool` module > - [x] Remove `CommandLine.java` from `jdk.jlink` module > - [x] Remove `CommandLine.java` from `jdk.jpackage` module > - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Remove entire "scary warning" paragraph ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11272/files - new: https://git.openjdk.org/jdk/pull/11272/files/7854e14c..6d2de1ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11272&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11272&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11272.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11272/head:pull/11272 PR: https://git.openjdk.org/jdk/pull/11272 From rriggs at openjdk.org Wed Nov 23 16:01:04 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 23 Nov 2022 16:01:04 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: References: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> Message-ID: On Tue, 22 Nov 2022 20:17:41 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/FormatProcessor.java line 64: >> >>> 62: * >>> 63: * @implSpec Since, values are found within the string template, argument indexing >>> 64: * specifiers are unsupported. >> >> What is the behavior of a format that references an index? Ignored, throw? >> I can see an argument for simplicity, but the values are a sequential list similar to that of a varargs call to format("xx", x, y, z, ...) so it can be well defined to what value an index in the format refers. > > Kind of blows the whole concept of embedded expressions. This is one of those, just because you can, doesn't mean you should. ok, still what is the behavior if the format includes an index? The pattern scanner in FormatProcessor permits an index and does not cause an error. Also, there might be a small benefit to using the existing compiled pattern in Formatter.java. (make it package private and rename to uppercase). ------------- PR: https://git.openjdk.org/jdk/pull/10889 From chegar at openjdk.org Wed Nov 23 16:06:28 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Wed, 23 Nov 2022 16:06:28 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 15:22:47 GMT, Roger Riggs wrote: >> src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 137: >> >>> 135: public static Thread newSystemThread(String name, Runnable target, >>> 136: long stackSize, int priority, >>> 137: boolean daemon) { >> >> Thanks for adding this overload, I think that it will be useful for the future too. ( it never seems to matter how many variants of these factories we have, we still need one more :-) ) > > I would prefer to to avoid creating new factories when the desired function can be done on the resulting thread. > Such as `setDaemon()` and `setName()`, etc. > It does avoid the doPriv in this case, but is not necessary and when the security manager goes away, will leave around clutter (duplicated) functionality. Looking beyond this specific change, there is a lot of potential use for this new factory elsewhere in the code. It also avoids similar bugs from possibly reoccurring (by having the setDaemon call inside the factory). ------------- PR: https://git.openjdk.org/jdk/pull/11309 From mcimadamore at openjdk.org Wed Nov 23 16:17:40 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 23 Nov 2022 16:17:40 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v12] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 12:39:40 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125: > 123: * @see #releaseScope(Buffer, MemorySessionImpl) > 124: */ > 125: MemorySessionImpl acquireScopeOrNull(Buffer buffer); I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null. I suggest to rename: * `acquireSession` -> `acquireSessionAsRunnable` * `acquireScopeOrNull` -> `acquireSession` * `releaseScope` -> `releaseSession` Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release. src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164: > 162: int pageSize(); > 163: > 164: sealed interface ScopeAcquisition extends AutoCloseable { Is this still needed? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From jlaskey at openjdk.org Wed Nov 23 16:20:27 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 23 Nov 2022 16:20:27 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v28] In-Reply-To: References: <3o5bVrwhDjcaSKgxqc9IOFcOEwDscZg4o-oUvTbmO_w=.c234c907-dba2-45d3-96fb-ea3b08c3c86e@github.com> Message-ID: On Wed, 23 Nov 2022 15:57:54 GMT, Roger Riggs wrote: >> Kind of blows the whole concept of embedded expressions. This is one of those, just because you can, doesn't mean you should. > > ok, still what is the behavior if the format includes an index? > The pattern scanner in FormatProcessor permits an index and does not cause an error. > > Also, there might be a small benefit to using the existing compiled pattern in Formatter.java. (make it package private and rename to uppercase). Currently it issues an `MissingFormatArgumentException` which I guess could be confusing. Changing to IllegalFormatFlagsException with a descriptive message. Re: Pattern - I was originally trying to minimize changes to Formatter, but considering what I did change... ------------- PR: https://git.openjdk.org/jdk/pull/10889 From rriggs at openjdk.org Wed Nov 23 16:20:30 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 23 Nov 2022 16:20:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v30] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 13:55:38 GMT, Jim Laskey wrote: >> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update @since src/java.base/share/classes/java/util/FormatProcessor.java line 85: > 83: > 84: /** > 85: * {@inheritDoc} The javadoc should describe in more detail what `process` does and the errors than can occur. That will help developers understand the errors that come out of Formatter in the context of FMT. That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed. The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment. For example, if multiple format strings appear in the fragment they are all passed to Formatter. If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value. For example, int x = 1; FMT."x: %s {x}"; // extra space It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument. That's exposing the implementation and may look like a bug in the FMT. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jlaskey at openjdk.org Wed Nov 23 16:43:03 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 23 Nov 2022 16:43:03 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v30] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 16:08:33 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Update @since > > src/java.base/share/classes/java/util/FormatProcessor.java line 85: > >> 83: >> 84: /** >> 85: * {@inheritDoc} > > The javadoc should describe in more detail what `process` does and the errors than can occur. > That will help developers understand the errors that come out of Formatter in the context of FMT. > That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed. > The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment. > For example, if multiple format strings appear in the fragment they are all passed to Formatter. > If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value. For example, > > int x = 1; > FMT."x: %s {x}"; // extra space > > It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument. That's exposing the implementation and may look like a bug in the FMT. Will clean up javadoc for FormatProcessor::process. It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From jjg at openjdk.org Wed Nov 23 16:47:22 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 23 Nov 2022 16:47:22 GMT Subject: RFR: 8296546: Add @spec tags to API [v2] In-Reply-To: <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <67cwjpPDhYIJW3yrDIi-6S1mSKwd-i9-e7Dm8X1MryM=.4cf1a49c-7798-42f6-90ab-524f4a623922@github.com> Message-ID: <1chEBBDbhD7PiPdKybnhe3Bq2DyO-GTGaxTU5qtw7C4=.8191c086-d70c-4bc1-b03e-d781b1268f07@github.com> On Wed, 23 Nov 2022 12:43:16 GMT, Daniel Fuchs wrote: > Thanks for adding the RFC NNNN prefix to the RFC link. What is the purpose of editing non exported classes though, like those in the `sun.net` subpackages? That was not intentional, and is a result of the scripted edit. I will look to revert those changes and/or change the tooling to ignore those packages. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Wed Nov 23 17:14:34 2022 From: duke at openjdk.org (Weibing Xiao) Date: Wed, 23 Nov 2022 17:14:34 GMT Subject: Integrated: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist In-Reply-To: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Tue, 15 Nov 2022 19:02:30 GMT, Weibing Xiao wrote: > print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. This pull request has now been integrated. Changeset: 8df3bc4e Author: Weibing Xiao Committer: Sean Coffey URL: https://git.openjdk.org/jdk/commit/8df3bc4ec57a15d5bca844e030c8cc3f8c077a49 Stats: 140 lines in 4 files changed: 136 ins; 0 del; 4 mod 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist Reviewed-by: rriggs, naoto, coffeys ------------- PR: https://git.openjdk.org/jdk/pull/11174 From rriggs at openjdk.org Wed Nov 23 17:30:03 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 23 Nov 2022 17:30:03 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v30] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 16:40:10 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/FormatProcessor.java line 85: >> >>> 83: >>> 84: /** >>> 85: * {@inheritDoc} >> >> The javadoc should describe in more detail what `process` does and the errors than can occur. >> That will help developers understand the errors that come out of Formatter in the context of FMT. >> That will help even if that is just to describe how the format string passed to j.u.Formatter is constructed. >> The javadoc should warn that the fragment should contain only a single format string and it must be at the end of the fragment. >> For example, if multiple format strings appear in the fragment they are all passed to Formatter. >> If the last format string is not the last in the fragment (for example, followed by a space) then a %s is appended and there are two formatters for a single value. For example, >> >> int x = 1; >> FMT."x: %s {x}"; // extra space >> >> It is unfortunate that the exception reported (in the case of a mismatch in the number for format strings vs values) is a BootStrapMethodError with a cause of MissingFormatArgument. That's exposing the implementation and may look like a bug in the FMT. > > Will clean up javadoc for FormatProcessor::process. > > It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually. Since FormatProcessor is scanning for format strings (in stringTempateFormat), it could check for the wrong number and misplaced format strings and throw. It would make the exception more specific to the arguments to the FMT.process() and easier for the developer to correct. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From mcimadamore at openjdk.org Wed Nov 23 17:33:06 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 23 Nov 2022 17:33:06 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v31] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * remove unused Scoped interface * re-add trusting of final fields in layout class implementations * Fix BulkOps benchmark, which had alignment issues ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/3c75e097..97168155 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=29-30 Stats: 56 lines in 5 files changed: 8 ins; 39 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From smarks at openjdk.org Wed Nov 23 17:37:13 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 23 Nov 2022 17:37:13 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v4] In-Reply-To: <75GEEMZlcZqCOSDaWQu4XgoOY4sDM2MBxep2ZH6f8hA=.e68d75e0-0ef8-4629-977b-f9742f228ef5@github.com> References: <75GEEMZlcZqCOSDaWQu4XgoOY4sDM2MBxep2ZH6f8hA=.e68d75e0-0ef8-4629-977b-f9742f228ef5@github.com> Message-ID: On Tue, 22 Nov 2022 22:24:00 GMT, David Holmes wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> Update Runtime class doc re: other unexpected behaviors > > src/java.base/share/classes/java/lang/Runtime.java line 97: > >> 95: * no {@code finally} clause of any method is executed, and try-with-resources >> 96: * blocks do not {@linkplain AutoCloseable close} their resources. >> 97: * Other unexpected behaviors may also result. > > No sorry that doesn't work for me. It sounds like you might get unexpected things happening, when in fact it is things not happening that might surprise someone (who doesn't understand what "immediately prevented from executing any further Java code" means). The list of examples is getting too long to handle in sentence structure so I suggest an actual list (not sure of list syntax). Suggestion: > > > * Java code. This includes shutdown hooks as well as daemon and non-daemon threads. This > * means, for example, that: > * - threads' current methods do not complete normally or abruptly > * - no {@code finally} clause of any method is executed > * - no {@linkplain Thread.UncaughtExceptionHandler uncaught exception handler} is executed > * - no try-with-resources blocks {@linkplain AutoCloseable close} their resources I think it's reasonable to position these as examples and to put them into list form. (wordsmithing) For parallel structure I'd suggest "X does not occur" instead of "no X occurs" in all but the first item, specifically (markup elided): - threads' current methods do not complete normally or abruptly; - finally clauses are not executed; - uncaught exception handlers are not executed; and - resources opened by try-with-resources statements are not closed. ------------- PR: https://git.openjdk.org/jdk/pull/11218 From smarks at openjdk.org Wed Nov 23 17:37:16 2022 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 23 Nov 2022 17:37:16 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v4] In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 00:50:51 GMT, Brent Christian wrote: >> [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". >> >> One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Update Runtime class doc re: other unexpected behaviors src/java.base/share/classes/java/lang/Runtime.java line 285: > 283: * actions intended to be performed by shutdown hooks, > 284: * {@linkplain Thread.UncaughtExceptionHandler uncaught exception handlers}, > 285: * finally blocks, or try-with-resources blocks. This can lead to data corruption. Since the examples of the consequences of halting are covered above in "JVM Termination" and are getting a bit involved, I'd suggest not trying to list the concrete consequences here, and referring the reader (again) to the "JVM Termination" section. ------------- PR: https://git.openjdk.org/jdk/pull/11218 From pminborg at openjdk.org Wed Nov 23 17:40:24 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 23 Nov 2022 17:40:24 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v12] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 16:14:52 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanup > > src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 125: > >> 123: * @see #releaseScope(Buffer, MemorySessionImpl) >> 124: */ >> 125: MemorySessionImpl acquireScopeOrNull(Buffer buffer); > > I think this looks better - but naming-wise it's still a bit problematic. This method really acquires the underlying session, not a scope. And also, here we have `OrNull`, but the already existing `acquireSession` also has a similar semantics w.r.t. null. > > I suggest to rename: > > * `acquireSession` -> `acquireSessionAsRunnable` > * `acquireScopeOrNull` -> `acquireSession` > * `releaseScope` -> `releaseSession` > > Also, once we have `acquire/releaseSession`, it is not clear to me that we still need `acquireSessionAsRunnable` in the JavaNIOAccess class - it seems like you can create the Runnable where it's required (probably IOUtil), simply by using straight acquire/release. The name "scope" was used in anticipation of the new proposed Java 20 naming. But I can change it back to session again. We could always rename later. > src/java.base/share/classes/jdk/internal/access/JavaNioAccess.java line 164: > >> 162: int pageSize(); >> 163: >> 164: sealed interface ScopeAcquisition extends AutoCloseable { > > Is this still needed? Well spotted. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From aph at openjdk.org Wed Nov 23 18:18:56 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 18:18:56 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v24] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: javadoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/7ac61ba2..8c526003 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=22-23 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 23 18:25:41 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 18:25:41 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v11] In-Reply-To: References: Message-ID: On Fri, 18 Nov 2022 15:19:35 GMT, Alan Bateman wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewer feedback > > src/java.base/share/classes/java/lang/Thread.java line 787: > >> 785: >> 786: // special value to mean a new thread >> 787: this.scopedValueBindings = Thread.class; > > The addition of NEW_THREAD_BINDINGS means this one should change too. The update means the comment should probably be adjusted too, maybe "initial value for a new thread". Done ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Wed Nov 23 18:39:19 2022 From: aph at openjdk.org (Andrew Haley) Date: Wed, 23 Nov 2022 18:39:19 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v25] In-Reply-To: References: Message-ID: <9ZhPphzsMfl1vMcmbOjnzXi1THKCagn-RIE5TAE3a0M=.0e019155-9ea9-4e6c-ab03-a38cf7a7de33@github.com> > JEP 429 implementation. Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: - Merge master - javadoc - Feedback from reviewers - Update src/hotspot/share/classfile/vmSymbols.hpp - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 - Update src/java.base/share/classes/java/lang/VirtualThread.java Co-authored-by: Alan Bateman - Update src/java.base/share/classes/java/lang/Thread.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Update src/hotspot/cpu/aarch64/aarch64.ad Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Feedback from reviewers - Remove incorrect assertion. - ... and 42 more: https://git.openjdk.org/jdk/compare/2afb4c33...30f150e1 ------------- Changes: https://git.openjdk.org/jdk/pull/10952/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=24 Stats: 3332 lines in 61 files changed: 2907 ins; 254 del; 171 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From jjg at openjdk.org Wed Nov 23 18:57:03 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 23 Nov 2022 18:57:03 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: Remove updates from unexported files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11073/files - new: https://git.openjdk.org/jdk/pull/11073/files/c29092d8..3905ac83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=01-02 Stats: 34 lines in 25 files changed: 0 ins; 34 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From psandoz at openjdk.org Wed Nov 23 19:18:39 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 23 Nov 2022 19:18:39 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v25] In-Reply-To: <9ZhPphzsMfl1vMcmbOjnzXi1THKCagn-RIE5TAE3a0M=.0e019155-9ea9-4e6c-ab03-a38cf7a7de33@github.com> References: <9ZhPphzsMfl1vMcmbOjnzXi1THKCagn-RIE5TAE3a0M=.0e019155-9ea9-4e6c-ab03-a38cf7a7de33@github.com> Message-ID: On Wed, 23 Nov 2022 18:39:19 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: > > - Merge master > - javadoc > - Feedback from reviewers > - Update src/hotspot/share/classfile/vmSymbols.hpp > - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 > - Update src/java.base/share/classes/java/lang/VirtualThread.java > > Co-authored-by: Alan Bateman > - Update src/java.base/share/classes/java/lang/Thread.java > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Update src/hotspot/cpu/aarch64/aarch64.ad > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> > - Feedback from reviewers > - Remove incorrect assertion. > - ... and 42 more: https://git.openjdk.org/jdk/compare/2afb4c33...30f150e1 Looks good (just some last minor comments). I did not focus on the tests, nor too closely at all of the HotSpot changes. Something for future investigation perhaps (if not already thought about): consider using a persistent map, a Hash Array Mapped Trie (HAMT), for storing scoped keys and values, which could potentially remove the need for the cache of replace the cache when many values are in scope. The HAMT's structural sharing properties, wide-branching factor, and `Integer.bitCount` being intrinsic all make for an efficient implementation. src/hotspot/share/classfile/vmSymbols.hpp line 401: > 399: template(daemon_name, "daemon") \ > 400: template(run_method_name, "run") \ > 401: template(call_method_name, "call") \ Is this used? src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 209: > 207: final int bitmask; > 208: > 209: private static final Object NIL = new Object(); Suggestion: static final Object NO_VALUE = new Object(); src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 212: > 210: > 211: static final Snapshot EMPTY_SNAPSHOT = new Snapshot(); > 212: Snapshot(Carrier bindings, Snapshot prev) { Suggestion: static final Snapshot EMPTY_SNAPSHOT = new Snapshot(); Snapshot(Carrier bindings, Snapshot prev) { src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 218: > 216: } > 217: > 218: protected Snapshot() { Suggestion: Snapshot() { src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 464: > 462: * Calls a value-returning operation with a {@code ScopedValue} bound to a value > 463: * in the current thread. When the operation completes (normally or with an > 464: * exception), the {@code ScopedValue} will revert to being unbound, or rervert to Suggestion: * exception), the {@code ScopedValue} will revert to being unbound, or revert to ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.org/jdk/pull/10952 From jlaskey at openjdk.org Wed Nov 23 19:22:14 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 23 Nov 2022 19:22:14 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v30] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 17:26:58 GMT, Roger Riggs wrote: >> Will clean up javadoc for FormatProcessor::process. >> >> It is unfortunate. If you have any ideas will gladly take them on. On the other hand, not sure if the exception is any worse that a static initializer exception visually. > > Since FormatProcessor is scanning for format strings (in stringTempateFormat), it could check for the wrong number and misplaced format strings and throw. It would make the exception more specific to the arguments to the FMT.process() and easier for the developer to correct. It is doing that now, but I can make the message more informative. The problem still exists that this is always done in the bootstrap method. ------------- PR: https://git.openjdk.org/jdk/pull/10889 From dfuchs at openjdk.org Wed Nov 23 19:23:53 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Wed, 23 Nov 2022 19:23:53 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From sspitsyn at openjdk.org Wed Nov 23 19:40:27 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 23 Nov 2022 19:40:27 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 10:31:00 GMT, Alan Bateman wrote: >> Fixed the `yieldContinuation()` method. >> There is also `switchToCarrierThread()` method that returns the `notifyJvmtiEvents` value. >> It seems to be an optimization. I'm not sure yet, if we need to fix these places as well. > >> There is also `switchToCarrierThread()` method that returns the `notifyJvmtiEvents` value. >> It seems to be an optimization. I'm not sure yet, if we need to fix these places as well. > > It was to ensure that hide(true) and hide(false) are balanced. If it were to re-poll notifyJvmtiEvents and a JVMTI agent enables the capability while a thread in doing a temporary transition then you may get a hide(false) without the corresponding hide(true). Okay, I see it now. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From dcubed at openjdk.org Wed Nov 23 20:27:37 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 23 Nov 2022 20:27:37 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v5] In-Reply-To: <2pDPZ1y-M_2nwuLb5Yf1xScY5FilE2i3HE3l3gEFOt0=.14849702-a403-4f03-80db-61c045f77e32@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> <2pDPZ1y-M_2nwuLb5Yf1xScY5FilE2i3HE3l3gEFOt0=.14849702-a403-4f03-80db-61c045f77e32@github.com> Message-ID: <5sj4h_iePqEvXZaHAXBS7UVeEuViwYxCf205JXZfsRE=.c478ff47-c8ca-41bc-aea0-b706ecc97d0e@github.com> On Mon, 21 Nov 2022 16:35:46 GMT, Weibing Xiao wrote: >> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. > > Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: > > update according to the review comments The new test, java/io/File/TempDirDoesNotExist.java, is failing on windows-x64. See [JDK-8297528](https://bugs.openjdk.org/browse/JDK-8297528) new java/io/File/TempDirDoesNotExist.java test failing on windows-x64 ------------- PR: https://git.openjdk.org/jdk/pull/11174 From roger.riggs at oracle.com Wed Nov 23 21:43:37 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 23 Nov 2022 16:43:37 -0500 Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v5] In-Reply-To: <5sj4h_iePqEvXZaHAXBS7UVeEuViwYxCf205JXZfsRE=.c478ff47-c8ca-41bc-aea0-b706ecc97d0e@github.com> References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> <2pDPZ1y-M_2nwuLb5Yf1xScY5FilE2i3HE3l3gEFOt0=.14849702-a403-4f03-80db-61c045f77e32@github.com> <5sj4h_iePqEvXZaHAXBS7UVeEuViwYxCf205JXZfsRE=.c478ff47-c8ca-41bc-aea0-b706ecc97d0e@github.com> Message-ID: <1504a283-208e-9df4-16fe-af66be663903@oracle.com> Please review a PR to put the test on the ProblemList until the test is fixed. https://github.com/openjdk/jdk/pull/11334 Thanks, Roger On 11/23/22 3:27 PM, Daniel D. Daugherty wrote: > On Mon, 21 Nov 2022 16:35:46 GMT, Weibing Xiao wrote: > >>> print warning message for java.io.tmpdir when it is set through the command line and the value is not good for creating file folder. >> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: >> >> update according to the review comments > The new test, java/io/File/TempDirDoesNotExist.java, is failing on windows-x64. > See [JDK-8297528](https://bugs.openjdk.org/browse/JDK-8297528) new java/io/File/TempDirDoesNotExist.java test failing on windows-x64 > > ------------- > > PR: https://git.openjdk.org/jdk/pull/11174 From kbarrett at openjdk.org Wed Nov 23 21:47:09 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 23 Nov 2022 21:47:09 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> Message-ID: <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com> On Wed, 23 Nov 2022 05:22:10 GMT, Kim Barrett wrote: >> It's to avoid redefining the linkage as static in os_windows.cpp (where it's implemented) after an extern declaration (inside the class), which is forbidden by C++11: >> >>> The linkages implied by successive declarations for a given entity shall agree. That is, within a given scope, each declaration declaring the same variable name or the same overloading of a function name shall imply the same linkage. >> >> While 2019 by default seems to ignore this rule and accepts the conflicting linkage as a language extension, this can cause issues with newer and stricter versions of the Visual C++ compiler (especially with -permissive- passed during compilation, which Magnus and Daniel have pointed out in another discussion will become the default mode of compilation in the future). It's not possible to declare a static friend inside a class, so the addition above takes advantage of another C++ feature instead: >> >>> ?11.3/4 [class.friend] >> A function first declared in a friend declaration has external linkage (3.5). Otherwise, the function retains its previous linkage (7.1.1). > > I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted. Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`. One obvious and cheap solution to that would be to make that enum public. I think that would be an improvement vs the current friend declaration. But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used. Here's a patch that I think cleans this up. diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp index 0651f0868f3..bf9e759b1d6 100644 --- a/src/hotspot/os/windows/os_windows.cpp +++ b/src/hotspot/os/windows/os_windows.cpp @@ -511,7 +511,9 @@ JNIEXPORT LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo); // Thread start routine for all newly created threads -static unsigned __stdcall thread_native_entry(Thread* thread) { +// Called with the associated Thread* as the argument. +unsigned __stdcall os::win32::thread_native_entry(void* t) { + Thread* thread = static_cast(t); thread->record_stack_base_and_size(); thread->initialize_thread_current(); @@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type, thread_handle = (HANDLE)_beginthreadex(NULL, (unsigned)stack_size, - (unsigned (__stdcall *)(void*)) thread_native_entry, + &os::win32::thread_native_entry, thread, initflag, &thread_id); diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp index 94d7c3c5e2d..197797078d7 100644 --- a/src/hotspot/os/windows/os_windows.hpp +++ b/src/hotspot/os/windows/os_windows.hpp @@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int); class os::win32 { friend class os; - friend unsigned __stdcall thread_native_entry(Thread*); protected: static int _processor_type; @@ -70,6 +69,10 @@ class os::win32 { static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen); private: + // The handler passed to _beginthreadex(). + // Called with the associated Thread* as the argument. + static unsigned __stdcall thread_native_entry(void*); + enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE }; // Wrapper around _endthreadex(), exit() and _exit() static int exit_process_or_thread(Ept what, int exit_code); ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jjg at openjdk.org Wed Nov 23 22:09:23 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 23 Nov 2022 22:09:23 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 19:20:53 GMT, Daniel Fuchs wrote: > The java.base/net/, java.http/, java.naming/ changes look reasonable to me - though like Alan I wonder if it wouldn't be better to have an inline `{@spec }` tag - similar to `{@systemProperty }`, rather than repeating all the references outside of the context where they were cited. This probably also calls for a review of these references by maintainers of the various areas - as some of them might need some updating - e.g. linking to `rfceditor` as was previously suggested, and double checking whether all of them still make sense. Not something to be conducted within this PR though. Believe me, I tried *very* hard to design and use an inline `{@spec}` tag but such a tag effectively needs a normative external file to indicate the root of a multi-page spec, and the definitive title, since inline tags either do not or are unlikely to contain such information. The general history of this work is: * version 1: bimodal tag with no external file -- the content of the summary page was effectively rubbish * version 2: bimodal tag with an external file -- in discussion with @jddarcy and CSR, we decided that was too much of a non-standard maintenance load * version 3: new tag, with no external file needed -- as you see here ------------- PR: https://git.openjdk.org/jdk/pull/11073 From joehw at openjdk.org Wed Nov 23 23:08:05 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 23 Nov 2022 23:08:05 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files src/java.xml/share/classes/javax/xml/XMLConstants.java line 35: > 33: * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition) > 34: * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition) > 35: * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition Hi Jon, I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0. points to the fifth edition while @see second. A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read. [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html ------------- PR: https://git.openjdk.org/jdk/pull/11073 From joehw at openjdk.org Wed Nov 23 23:43:57 2022 From: joehw at openjdk.org (Joe Wang) Date: Wed, 23 Nov 2022 23:43:57 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <3O_lqMPzsBuGyrQ_snbw0Qv-XY-OaGUly6OBtoRz8hw=.041bf0b3-9dd4-4616-a003-617d28030139@github.com> On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files Specs for XSLT and XPath (many occurrences) need to point to specific version (e.g. 1.0) rather than the "cover page" (this is an issue in the original javadoc). src/java.xml/share/classes/javax/xml/transform/OutputKeys.java line 35: > 33: * > 34: * @spec https://www.w3.org/TR/xslt xslt cover page - W3C > 35: * @see The pages for XSLT and XPath at W3C are organized differently from the days when this javadoc was created. The "latest version" now points to the "cover page". Could you change the spec to the following? https://www.w3.org/TR/1999/REC-xslt-19991116 XSL Transformations (XSLT) Version 1.0 The @spec points to the general spec while @see also a specific section (similar situation as other classes in the package), if we want to keep @see ref here, it would be: https://www.w3.org/TR/1999/REC-xslt-19991116#output src/java.xml/share/classes/javax/xml/xpath/XPath.java line 104: > 102: * @author Norman Walsh > 103: * @author Jeff Suttor > 104: * @see XML Path Language (XPath) Version 1.0 Similar situation as XSLT above, the latest version now points to "cover page". For this javadoc then, it needs to be: https://www.w3.org/TR/1999/REC-xpath-19991116/ XML Path Language (XPath) Version 1.0 Unlike XSLT, the original @see ref also points to the spec generally (not a specific section), we could then drop it to keep just the @spec ref. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From lmesnik at openjdk.org Thu Nov 24 01:39:18 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 24 Nov 2022 01:39:18 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: <5CWDDqV9i7S2TQeIhw0PtKjvWbnH2YqFUwiwZHXzm3g=.882e76f5-c157-49c8-a175-94693c323a8e@github.com> On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove caching if notifyJvmtiEvents in yieldContinuation Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11304 From aph at openjdk.org Thu Nov 24 08:48:17 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 08:48:17 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v26] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Paul Sandoz - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/30f150e1..1395b52f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=24-25 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Thu Nov 24 09:09:27 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 09:09:27 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v25] In-Reply-To: References: <9ZhPphzsMfl1vMcmbOjnzXi1THKCagn-RIE5TAE3a0M=.0e019155-9ea9-4e6c-ab03-a38cf7a7de33@github.com> Message-ID: On Wed, 23 Nov 2022 19:16:23 GMT, Paul Sandoz wrote: > Looks good (just some last minor comments). I did not focus on the tests, nor too closely at all of the HotSpot changes. > > Something for future investigation perhaps (if not already thought about): consider using a persistent map, a Hash Array Mapped Trie (HAMT), for storing scoped keys and values, which could potentially remove the need for the cache of replace the cache when many values are in scope. The HAMT's structural sharing properties, wide-branching factor, and `Integer.bitCount` being intrinsic all make for an efficient implementation. I've certainly considered a HAMT. (I've considered everything! It's been a long journey.) The trouble is that using one penalizes binding operations because a persistent HAMT requires path copying for insertions. This won't matter if your bind operation is rare, such as at the start of a large block of code. However, it might not be. Consider a common case such as a parallel stream using fork/join. void parallelRunWithCredentials(List aList, Runnable aRunnable) { var permissions = ScopedValue.where(PERMISSION, getCredentials()); aList.parallelStream().forEach(() -> permissions.run(aRunnable)); } Because the binding operation `permissions.run()` is invoked for every element on the list, we must make the binding operation as fast as it can possibly be. In addition, the cache is _extremely_ fast. Typically it's four instructions, and C2 almost always hoists values, once looked up in cache, into registers. A HAMT lookup, while fast and (mostly) O(1), is more complex. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Thu Nov 24 09:29:27 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 09:29:27 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v25] In-Reply-To: References: <9ZhPphzsMfl1vMcmbOjnzXi1THKCagn-RIE5TAE3a0M=.0e019155-9ea9-4e6c-ab03-a38cf7a7de33@github.com> Message-ID: On Wed, 23 Nov 2022 18:49:07 GMT, Paul Sandoz wrote: >> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: >> >> - Merge master >> - javadoc >> - Feedback from reviewers >> - Update src/hotspot/share/classfile/vmSymbols.hpp >> - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 >> - Update src/java.base/share/classes/java/lang/VirtualThread.java >> >> Co-authored-by: Alan Bateman >> - Update src/java.base/share/classes/java/lang/Thread.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Update src/hotspot/cpu/aarch64/aarch64.ad >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Feedback from reviewers >> - Remove incorrect assertion. >> - ... and 42 more: https://git.openjdk.org/jdk/compare/2afb4c33...30f150e1 > > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 209: > >> 207: final int bitmask; >> 208: >> 209: private static final Object NIL = new Object(); > > Suggestion: > > static final Object NO_VALUE = new Object(); It not very important, but I'm going to push back (very gently) on this one. "nil: noun. nothing; naught; zero. adjective. having no value or existence." That is the exact literal meaning of this sentinel. Also, "nil" has been used with this meaning in programming languages for 60 years. What is your objection to it here? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From coffeys at openjdk.org Thu Nov 24 09:37:29 2022 From: coffeys at openjdk.org (Sean Coffey) Date: Thu, 24 Nov 2022 09:37:29 GMT Subject: RFR: 8290313: Produce warning when user specified java.io.tmpdir directory doesn't exist [v2] In-Reply-To: References: <4I-YnQzIwl9l6gBQnqb1qc_axCxl9nuuzAtaXWu2nt4=.838d3af8-f26b-4f23-ad38-552ff230852c@github.com> Message-ID: On Wed, 16 Nov 2022 15:12:41 GMT, Roger Riggs wrote: >> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision: >> >> the change according to review comment > > test/jdk/java/io/File/TempDirectoryNotExisting.java line 45: > >> 43: >> 44: String userDir = System.getProperty("user.home"); >> 45: String timeStamp = System.currentTimeMillis() + ""; > > A human readable string might be useful. For example, "2022-11-16T15:10:50.622334Z" > `java.time.Instant.now().toString()` root cause for JDK-8297528 Please revert the change Weibing and be sure to remove the test from ProblemList when doing so (next week) Please also ensure that you run tests against mach5 before integrating any change in future, ------------- PR: https://git.openjdk.org/jdk/pull/11174 From stsypanov at openjdk.org Thu Nov 24 10:15:28 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 24 Nov 2022 10:15:28 GMT Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints() Message-ID: `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`. ------------- Commit messages: - 8297561: Redundant index check in String.offsetByCodePoints() Changes: https://git.openjdk.org/jdk/pull/11350/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11350&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297561 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11350.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11350/head:pull/11350 PR: https://git.openjdk.org/jdk/pull/11350 From aph at openjdk.org Thu Nov 24 10:26:49 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 10:26:49 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v27] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 - Fix merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/1395b52f..3a6f8037 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=25-26 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Thu Nov 24 10:31:08 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 10:31:08 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v28] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/3a6f8037..4bcfa52e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=26-27 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Thu Nov 24 10:31:16 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 10:31:16 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v25] In-Reply-To: References: <9ZhPphzsMfl1vMcmbOjnzXi1THKCagn-RIE5TAE3a0M=.0e019155-9ea9-4e6c-ab03-a38cf7a7de33@github.com> Message-ID: On Wed, 23 Nov 2022 18:47:28 GMT, Paul Sandoz wrote: >> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 52 commits: >> >> - Merge master >> - javadoc >> - Feedback from reviewers >> - Update src/hotspot/share/classfile/vmSymbols.hpp >> - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 >> - Update src/java.base/share/classes/java/lang/VirtualThread.java >> >> Co-authored-by: Alan Bateman >> - Update src/java.base/share/classes/java/lang/Thread.java >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Update src/hotspot/cpu/aarch64/aarch64.ad >> >> Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> >> - Feedback from reviewers >> - Remove incorrect assertion. >> - ... and 42 more: https://git.openjdk.org/jdk/compare/2afb4c33...30f150e1 > > src/hotspot/share/classfile/vmSymbols.hpp line 401: > >> 399: template(daemon_name, "daemon") \ >> 400: template(run_method_name, "run") \ >> 401: template(call_method_name, "call") \ > > Is this used? No. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Thu Nov 24 10:36:16 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 10:36:16 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v29] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/4bcfa52e..c10a5d79 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=27-28 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Thu Nov 24 10:46:56 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 10:46:56 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v30] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with five additional commits since the last revision: - Merge branch 'JDK-8286666' of https://github.com/theRealAph/jdk into JDK-8286666 - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Paul Sandoz - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Paul Sandoz - Reviewer feedback - Update src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java Co-authored-by: Paul Sandoz ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/c10a5d79..15db2a30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=28-29 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From aph at openjdk.org Thu Nov 24 10:49:56 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 10:49:56 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v31] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/15db2a30..903780d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=29-30 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Thu Nov 24 10:56:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 24 Nov 2022 10:56:23 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files src/java.se/share/classes/module-info.java line 39: > 37: * > 38: * @spec jdwp/jdwp-spec.html Java Debug Wire Protocol > 39: * @spec jni/index.html Java Native Interface Specification One thing that that bothers me a bit here is that the JNI and JDWP specs will be listed as "External Specifications" in the generated javadoc. This heading is appropriate for RFCs and other standards that we reference but seems misleading for specifications that are part of Java SE. Has this come up already? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From aph at openjdk.org Thu Nov 24 10:57:51 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 10:57:51 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v32] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Cleanup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/903780d6..1b3c39bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=30-31 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From pminborg at openjdk.org Thu Nov 24 11:42:52 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 24 Nov 2022 11:42:52 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove redundant method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/682b6f5a..0546b23b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=11-12 Stats: 213 lines in 20 files changed: 12 ins; 105 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Thu Nov 24 11:53:28 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 24 Nov 2022 11:53:28 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant method Looks good - I'm glad that the changes to IOUtil turned out simpler than expected! ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Thu Nov 24 11:53:29 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 24 Nov 2022 11:53:29 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove caching if notifyJvmtiEvents in yieldContinuation Would it be possible to summarize behavior for when an agent enables the capability as a virtual thread executes for the first time or it continues after yield? More specifically JVMTI will be notified of a mount end without a correspond mount begin. It might be that we can narrow this down to if finish_VTMS_transition is okay without a preceding start_VTMS_transition. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From mcimadamore at openjdk.org Thu Nov 24 11:57:09 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 24 Nov 2022 11:57:09 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: Message-ID: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com> On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant method src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519: > 517: } > 518: > 519: record LinkedRunnable(Runnable node, Runnable next) Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Thu Nov 24 12:00:21 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 24 Nov 2022 12:00:21 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com> References: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com> Message-ID: On Thu, 24 Nov 2022 11:54:43 GMT, Maurizio Cimadamore wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant method > > src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519: > >> 517: } >> 518: >> 519: record LinkedRunnable(Runnable node, Runnable next) > > Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes. Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line). Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Thu Nov 24 12:00:22 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Thu, 24 Nov 2022 12:00:22 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com> Message-ID: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com> On Thu, 24 Nov 2022 11:57:33 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 519: >> >>> 517: } >>> 518: >>> 519: record LinkedRunnable(Runnable node, Runnable next) >> >> Some (optional) style comments: I'm not sure this is a record. E.g. both this and the `Releaser` class are only used externally to call their `run` method. The fact that they are made up of components is immaterial to clients, which seems to suggest that an interface would be better - at least subjectively. If I were to write the code I will declare the implementation inside the factories, as local/anon classes. > > Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line). > > Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd. (to be clear, some of the above comments refer to the code that was already there before your changes) ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Thu Nov 24 12:17:06 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 24 Nov 2022 12:17:06 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 11:42:52 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant method src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java line 790: > 788: try { > 789: int n = receive0(fd, > 790: ((DirectBuffer)bb).address() + pos, rem, Would it be possible to restore the original alignment, just to make it easier to read. src/java.base/share/classes/sun/nio/ch/DirectBuffer.java line 39: > 37: // silent unrelated memory mutation and JVM crashes. > 38: // > 39: // Guards are available in the JavaNioAccess class. Did you mean to leave the word "Guards" in the comment? I guess I would say something "See JavaNioAccess for methods to acquire/release" or something like that. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480: > 478: static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) { > 479: if (async && NIO_ACCESS.isThreadConfined(bb)) { > 480: throw new IllegalStateException("Confined session not supported"); No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 543: > 541: @Override public void run() { releaseScope(bb, session); } > 542: static Runnable of(ByteBuffer bb, MemorySessionImpl session) { return new Releaser(bb, session); } > 543: static Runnable ofNullable(ByteBuffer bb, MemorySessionImpl session) { Would it be possible to re-format this to make it more readable? There's just a bit more going on compared to the original and it's harder to read. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From sspitsyn at openjdk.org Thu Nov 24 12:48:59 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 24 Nov 2022 12:48:59 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove caching if notifyJvmtiEvents in yieldContinuation I've forgotten the `JvmtiVTMSTransitionDisabler` is not going to work before the `notifyJvmtiEvents` is set to `true`. I agree, we may want to allow `start_VTMS_transition/finish_VTMS_transition` not properly paired as you suggest. But then it is not good that we loose the ability to strictly check/assert pairing of VTMS transition notifications for other cases. Need to think a bit more on this. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From redestad at openjdk.org Thu Nov 24 13:31:24 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 24 Nov 2022 13:31:24 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation Message-ID: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> When concatenating Strings, OutOfMemoryError should be thrown on all overflow conditions. This fixes a case that erroneously thro IAE on concatenations of long (`length > Integer.MAX_VALUE/2`) UTF16 strings due failing to check for overflow after shifting index left with the coder. This was caught by a fuzzer test. Added a sanity test that fails without the patch (loosely derived from ImplicitStringConcatMany.java) ------------- Commit messages: - Verify the sanity test holds when -CompactStrings - Adjust newArray to correctly throw OOME on overflow due shifting the index for UTF16 encoding Changes: https://git.openjdk.org/jdk/pull/11354/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11354&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297530 Stats: 143 lines in 2 files changed: 141 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11354.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11354/head:pull/11354 PR: https://git.openjdk.org/jdk/pull/11354 From jlaskey at openjdk.org Thu Nov 24 13:38:30 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Thu, 24 Nov 2022 13:38:30 GMT Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates (Preview) [v31] In-Reply-To: References: Message-ID: > Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12). Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: FormatProcessor changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10889/files - new: https://git.openjdk.org/jdk/pull/10889/files/09f1ac08..69efbb48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=29-30 Stats: 131 lines in 3 files changed: 81 ins; 16 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/10889.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889 PR: https://git.openjdk.org/jdk/pull/10889 From enikitin at openjdk.org Thu Nov 24 13:44:49 2022 From: enikitin at openjdk.org (Evgeny Nikitin) Date: Thu, 24 Nov 2022 13:44:49 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation In-Reply-To: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: On Thu, 24 Nov 2022 13:23:13 GMT, Claes Redestad wrote: > When concatenating Strings, OutOfMemoryError should be thrown on all overflow conditions. This fixes a case that erroneously thro IAE on concatenations of long (`length > Integer.MAX_VALUE/2`) UTF16 strings due failing to check for overflow after shifting index left with the coder. > > This was caught by a fuzzer test. Added a sanity test that fails without the patch (loosely derived from ImplicitStringConcatMany.java) LGTM. ------------- Marked as reviewed by enikitin (Author). PR: https://git.openjdk.org/jdk/pull/11354 From aph at openjdk.org Thu Nov 24 14:05:41 2022 From: aph at openjdk.org (Andrew Haley) Date: Thu, 24 Nov 2022 14:05:41 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v33] In-Reply-To: References: Message-ID: > JEP 429 implementation. Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: Unused variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10952/files - new: https://git.openjdk.org/jdk/pull/10952/files/1b3c39bc..37441eeb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10952&range=31-32 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/10952.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10952/head:pull/10952 PR: https://git.openjdk.org/jdk/pull/10952 From alanb at openjdk.org Thu Nov 24 14:17:22 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 24 Nov 2022 14:17:22 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation In-Reply-To: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: On Thu, 24 Nov 2022 13:23:13 GMT, Claes Redestad wrote: > When concatenating Strings, OutOfMemoryError should be thrown on all overflow conditions. This fixes a case that erroneously thro IAE on concatenations of long (`length > Integer.MAX_VALUE/2`) UTF16 strings due failing to check for overflow after shifting index left with the coder. > > This was caught by a fuzzer test. Added a sanity test that fails without the patch (loosely derived from ImplicitStringConcatMany.java) test/jdk/java/lang/String/concat/ImplicitStringConcatOOME.java line 36: > 34: * @run main/othervm -Xverify:all -Xmx4g ImplicitStringConcatOOME > 35: * > 36: * @compile ImplicitStringConcatOOME.java I don't think you need the @compile tags but you might need `@requires sun.arch.data.model == "64"` so that the test only runs on 64-bit systems. ------------- PR: https://git.openjdk.org/jdk/pull/11354 From pminborg at openjdk.org Thu Nov 24 14:52:15 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 24 Nov 2022 14:52:15 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com> References: <6_xl7BuxkvCa-fr22bCsynHbVL_xr-UbnjUJNjXSydw=.ef8bfc28-8fff-4f95-90ae-a8b501a91755@github.com> <3wPm9hvjgcVnOci7fXpCyCdwS_HHcJUKURWSwEZ0W3o=.dc312fb1-e0f9-4099-88e2-133c65fd1476@github.com> Message-ID: On Thu, 24 Nov 2022 11:58:12 GMT, Maurizio Cimadamore wrote: >> Separately, also (optional) stylistic: the indenting on this and following class is a bit odd. There is a certain tendency to compress lines - e.g. to reach for one-liners, when in reality the body is not that trivial. If I were to write the code I'd insert a newline after the `{` and I'd also break apart initialization (e.g. no two statements separated by `;` in the same line). >> >> Also, I noted that you start the body of the record (e.g. `{`) on a new line, which I also find odd. > > (to be clear, some of the above comments refer to the code that was already there before your changes) I also found the above as a bit odd but tried to stick with the existing implementation and style as much as possible. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Thu Nov 24 14:58:19 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 24 Nov 2022 14:58:19 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 12:06:44 GMT, Alan Bateman wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant method > > src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480: > >> 478: static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) { >> 479: if (async && NIO_ACCESS.isThreadConfined(bb)) { >> 480: throw new IllegalStateException("Confined session not supported"); > > No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify. This was the old behaviour which was retained in this PR. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From redestad at openjdk.org Thu Nov 24 15:01:12 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 24 Nov 2022 15:01:12 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation [v2] In-Reply-To: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: > When concatenating Strings, OutOfMemoryError should be thrown on all overflow conditions. This fixes a case that erroneously thro IAE on concatenations of long (`length > Integer.MAX_VALUE/2`) UTF16 strings due failing to check for overflow after shifting index left with the coder. > > This was caught by a fuzzer test. Added a sanity test that fails without the patch (loosely derived from ImplicitStringConcatMany.java) Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Require 64-bit arch to avoid (most) hypothetical false positives ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11354/files - new: https://git.openjdk.org/jdk/pull/11354/files/884dac30..124a7350 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11354&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11354&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11354.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11354/head:pull/11354 PR: https://git.openjdk.org/jdk/pull/11354 From redestad at openjdk.org Thu Nov 24 15:04:49 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 24 Nov 2022 15:04:49 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation [v2] In-Reply-To: References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: On Thu, 24 Nov 2022 14:14:56 GMT, Alan Bateman wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Require 64-bit arch to avoid (most) hypothetical false positives > > test/jdk/java/lang/String/concat/ImplicitStringConcatOOME.java line 36: > >> 34: * @run main/othervm -Xverify:all -Xmx4g ImplicitStringConcatOOME >> 35: * >> 36: * @compile ImplicitStringConcatOOME.java > > I don't think you need the @compile tags but you might need `@requires sun.arch.data.model == "64"` so that the test only runs on 64-bit systems. Seems to work without yes. Started with a copy of a similar test that used the `@compile` tags to control different compilation modes. Testing each ISC compilation mode seemed excessive for this sanity test. ------------- PR: https://git.openjdk.org/jdk/pull/11354 From alanb at openjdk.org Thu Nov 24 15:17:17 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 24 Nov 2022 15:17:17 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation [v2] In-Reply-To: References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: <2z7XQ-9jiQS98vgFcqk1NgOO3eYXMcnUEn231INqlFI=.258bce04-321a-41dc-baed-0db67240dc79@github.com> On Thu, 24 Nov 2022 15:01:12 GMT, Claes Redestad wrote: >> When concatenating Strings, OutOfMemoryError should be thrown on all overflow conditions. This fixes a case that erroneously thro IAE on concatenations of long (`length > Integer.MAX_VALUE/2`) UTF16 strings due failing to check for overflow after shifting index left with the coder. >> >> This was caught by a fuzzer test. Added a sanity test that fails without the patch (loosely derived from ImplicitStringConcatMany.java) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Require 64-bit arch to avoid (most) hypothetical false positives Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11354 From pminborg at openjdk.org Thu Nov 24 16:21:42 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 24 Nov 2022 16:21:42 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v14] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Reformat and fix comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/0546b23b..30aff118 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=12-13 Stats: 26 lines in 3 files changed: 13 ins; 2 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Thu Nov 24 17:07:27 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 24 Nov 2022 17:07:27 GMT Subject: RFR: 8297150: Add a @sealedGraph tag to Reference In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:52:50 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `Reference` class. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > Here is how it would look like: > > Reference_SH Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11191 From pminborg at openjdk.org Thu Nov 24 17:11:18 2022 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 24 Nov 2022 17:11:18 GMT Subject: Integrated: 8297150: Add a @sealedGraph tag to Reference In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 16:52:50 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy of the `Reference` class. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > Here is how it would look like: > > Reference_SH This pull request has now been integrated. Changeset: 390e69ad Author: Per Minborg Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/390e69ad065ebefe2e998f6200d19d45cf043b16 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8297150: Add a @sealedGraph tag to Reference Reviewed-by: darcy, alanb ------------- PR: https://git.openjdk.org/jdk/pull/11191 From redestad at openjdk.org Thu Nov 24 17:44:41 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 24 Nov 2022 17:44:41 GMT Subject: Integrated: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation In-Reply-To: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: On Thu, 24 Nov 2022 13:23:13 GMT, Claes Redestad wrote: > When concatenating Strings, OutOfMemoryError should be thrown on all overflow conditions. This fixes a case that erroneously thro IAE on concatenations of long (`length > Integer.MAX_VALUE/2`) UTF16 strings due failing to check for overflow after shifting index left with the coder. > > This was caught by a fuzzer test. Added a sanity test that fails without the patch (loosely derived from ImplicitStringConcatMany.java) This pull request has now been integrated. Changeset: 87d1097d Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/87d1097d9be1ef804bfd4640a4254126242b1d8c Stats: 141 lines in 2 files changed: 139 ins; 0 del; 2 mod 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation Reviewed-by: enikitin, alanb ------------- PR: https://git.openjdk.org/jdk/pull/11354 From aturbanov at openjdk.org Thu Nov 24 17:54:29 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 24 Nov 2022 17:54:29 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation [v2] In-Reply-To: References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: On Thu, 24 Nov 2022 15:01:12 GMT, Claes Redestad wrote: >> When concatenating Strings, OutOfMemoryError should be thrown on all overflow conditions. This fixes a case that erroneously thro IAE on concatenations of long (`length > Integer.MAX_VALUE/2`) UTF16 strings due failing to check for overflow after shifting index left with the coder. >> >> This was caught by a fuzzer test. Added a sanity test that fails without the patch (loosely derived from ImplicitStringConcatMany.java) > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Require 64-bit arch to avoid (most) hypothetical false positives test/jdk/java/lang/String/concat/ImplicitStringConcatOOME.java line 129: > 127: } > 128: > 129: public static void test(String expected, String actual) { When this method is called? ------------- PR: https://git.openjdk.org/jdk/pull/11354 From redestad at openjdk.org Thu Nov 24 18:00:24 2022 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 24 Nov 2022 18:00:24 GMT Subject: RFR: 8297530: java.lang.IllegalArgumentException: Negative length on strings concatenation [v2] In-Reply-To: References: <2xeAdW72Dtp2u5U9Cd8L5FQ5v-AalYHuMwnaIHJyWyU=.4b7228bc-cc70-4620-821a-d44bcc46f298@github.com> Message-ID: On Thu, 24 Nov 2022 17:50:42 GMT, Andrey Turbanov wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Require 64-bit arch to avoid (most) hypothetical false positives > > test/jdk/java/lang/String/concat/ImplicitStringConcatOOME.java line 129: > >> 127: } >> 128: >> 129: public static void test(String expected, String actual) { > > When this method is called? Never - accidental left-over from the test I used as a template for this. I'd remove it if I hadn't already integrated - but opening a bug to clean that out doesn't seem worthwhile. ------------- PR: https://git.openjdk.org/jdk/pull/11354 From duke at openjdk.org Thu Nov 24 20:24:22 2022 From: duke at openjdk.org (Markus KARG) Date: Thu, 24 Nov 2022 20:24:22 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2] In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 09:41:47 GMT, Markus KARG wrote: >> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. >> >> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed bug number Kindly requesting review. :-) ------------- PR: https://git.openjdk.org/jdk/pull/11248 From ethan at mccue.dev Fri Nov 25 01:26:39 2022 From: ethan at mccue.dev (Ethan McCue) Date: Thu, 24 Nov 2022 20:26:39 -0500 Subject: What are the policies for internal modules? In-Reply-To: References: Message-ID: (always so hard to remember to reply all) On Thu, Nov 24, 2022 at 8:26 PM Ethan McCue wrote: > The use here is giving help to the user on > misspelled classes/methods/fields like "new ArayList". > > For now we've just copy pasted the class since that seems the least > architecturally painful. (And it's not clear that text distance is the full > story with regards to this sort of analysis, so tbd if that stays in its > current form) > > On Mon, Nov 21, 2022 at 3:19 AM Alan Bateman > wrote: > >> On 21/11/2022 01:02, Ethan McCue wrote: >> > There are some modules like jdk.internal.le which contain no >> > publicly exported packages. In some of the experimentation we are >> > doing, We want to use the >> > jdk.internal.org.jline.utils.Levenshtien class from jdk.compiler. >> > >> > Mechanically, we can do this without creating any new modules by >> > adding a qualified export of the utils package to jdk.compiler. We >> > could also make a brand new, tiny pointless module called >> > jdk.internal.levenshtien. That would be the "cleanest" approach, but >> > only if we didn't consider the existence of the internal modules to be >> > public API. >> > >> > So that's my general question - what is the bar for making a new >> > internal module, and is the set of internal modules subject to >> > backwards compatibility concerns? >> >> There aren't many compatibility constraints on jdk.internal modules. >> Assume they can change or be removed in any release. It's important they >> don't export any packages to all modules, otherwise they cease to be >> "internal". Also if they provide services then the name of the module >> may be something that users of jlink may become dependent on, so we have >> to be careful there. >> >> A general point is that we don't want the JDK to backslide to a big ball >> of mud. We put a lot of effort several years ago to de-tangle the >> libraries so it would be disappointing see jdk.compiler, with no >> interest in line editing, add a dependency on jdk.internal.le so that it >> can make use of one of utility classes. So I don't think we should do >> that. >> >> Can you say a bit more about what you are doing? Is this just a method >> to compute the Levenshtein distance between two strings? I assume you >> can just implement that in jdk.compiler without touching the module >> graph. It might be useful to get some sense on how common fuzzy matching >> is in the eco system to see if there is any merit to exposing APIs for >> this. >> >> -Alan >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Fri Nov 25 01:55:58 2022 From: ethan at mccue.dev (Ethan McCue) Date: Thu, 24 Nov 2022 20:55:58 -0500 Subject: What is meant by "document context" in JEP 198? Message-ID: I'm reading JEP 198 and sketching out what an implementation could look like pursuant to this old conversation. https://mail.openjdk.org/pipermail/discuss/2020-April/005401.html My biggest question right now is what does the JEP mean exactly by "document context" - Parsing APIs which allow a choice of parsing token stream, event (includes document hierarchy context) stream, or immutable tree representation views of JSON documents and data streams. So token stream I understand as something akin to sealed interface Token { record StartArray() implements Token {} record EndArray() implements Token {} record StartObject() implements Token {} record EndObject() implements Token {} record Number(Json.Number value) implements Token {} record String(Json.String value) implements Token {} record True() implements Token {} record False() implements Token {} record Null() implements Token {} } Which matches up with the model in https://fasterxml.github.io/jackson-core/javadoc/2.7/com/fasterxml/jackson/core/JsonToken.html And an immutable tree representation as akin to sealed interface Json { sealed interface Array extends Json, List ... sealed interface Object extends Json, Map ... sealed abstract class Number extends java.lang.Number implements Json ... sealed interface String extends Json, CharSequence ... sealed interface Boolean ... sealed interface Null extends Json ... } Which, ignoring the open questions of * Does the immutable tree need to be eagerly realized? * Do we need to wait for valhalla to land * Do we need to wait for full pattern matching to land (because they make me sad) I'm still unsure what information needs to be included in an "Event" stream that would constitute "document context". Is it pointers to parent collections? The current "Path"? sealed interface PathElement { record Field(String fieldName) implements PathElement {} record Index(int index) implements PathElement {} } -------------- next part -------------- An HTML attachment was scrubbed... URL: From ethan at mccue.dev Fri Nov 25 02:04:08 2022 From: ethan at mccue.dev (Ethan McCue) Date: Thu, 24 Nov 2022 21:04:08 -0500 Subject: What is meant by "document context" in JEP 198? In-Reply-To: References: Message-ID: I suppose while I'm asking questions - what exactly are the parts of the JDK making use of ad-hoc json? Maybe we could ship *something* as a jdk.internal module for those use cases? On Thu, Nov 24, 2022 at 8:55 PM Ethan McCue wrote: > I'm reading JEP 198 and sketching out what an implementation could look > like pursuant to this old conversation. > > https://mail.openjdk.org/pipermail/discuss/2020-April/005401.html > > My biggest question right now is what does the JEP mean exactly by > "document context" > > > - Parsing APIs which allow a choice of parsing token stream, event > (includes document hierarchy context) stream, or immutable tree > representation views of JSON documents and data streams. > > > > So token stream I understand as something akin to > > sealed interface Token { > record StartArray() implements Token {} > record EndArray() implements Token {} > record StartObject() implements Token {} > record EndObject() implements Token {} > record Number(Json.Number value) implements Token {} > record String(Json.String value) implements Token {} > record True() implements Token {} > record False() implements Token {} > record Null() implements Token {} > } > > Which matches up with the model in > https://fasterxml.github.io/jackson-core/javadoc/2.7/com/fasterxml/jackson/core/JsonToken.html > > And an immutable tree representation as akin to > > sealed interface Json { > sealed interface Array extends Json, List ... > sealed interface Object extends Json, Map ... > sealed abstract class Number extends java.lang.Number implements Json > ... > sealed interface String extends Json, CharSequence ... > sealed interface Boolean ... > sealed interface Null extends Json ... > } > > Which, ignoring the open questions of > * Does the immutable tree need to be eagerly realized? > * Do we need to wait for valhalla to land > * Do we need to wait for full pattern matching to land > > (because they make me sad) > > I'm still unsure what information needs to be included in an "Event" > stream that would constitute "document context". Is it pointers to parent > collections? The current "Path"? > > sealed interface PathElement { > record Field(String fieldName) implements PathElement {} > record Index(int index) implements PathElement {} > } > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Fri Nov 25 05:58:49 2022 From: duke at openjdk.org (Dongxu Wang) Date: Fri, 25 Nov 2022 05:58:49 GMT Subject: Integrated: 8297385: Remove duplicated null typos in javadoc In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 06:58:09 GMT, Dongxu Wang wrote: > 8297385: Remove duplicated null typos in javadoc This pull request has now been integrated. Changeset: 0ed8b337 Author: Dongxu Wang Committer: Yi Yang URL: https://git.openjdk.org/jdk/commit/0ed8b337eaa59881a62af5dcc0abb454761f2e71 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8297385: Remove duplicated null typos in javadoc Reviewed-by: dfuchs, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/11311 From duke at openjdk.org Fri Nov 25 06:49:27 2022 From: duke at openjdk.org (ExE Boss) Date: Fri, 25 Nov 2022 06:49:27 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 14:56:07 GMT, Per Minborg wrote: >> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 480: >> >>> 478: static MemorySessionImpl acquireScope(ByteBuffer bb, boolean async) { >>> 479: if (async && NIO_ACCESS.isThreadConfined(bb)) { >>> 480: throw new IllegalStateException("Confined session not supported"); >> >> No sure about ISE here. There is no mutable state on the input that would allow the acquire to succeed. I don't think anyone has run into it yet but we will need to look at the AsynchronousXXXX read/write methods to decide which exception to specify. > > This was the old behaviour which was retained in this PR. I?believe `UnsupportedOperationException` would?be?better for?this. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Fri Nov 25 07:17:08 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 25 Nov 2022 07:17:08 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v13] In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 06:46:52 GMT, ExE Boss wrote: > I?believe `UnsupportedOperationException` would?be?better for?this. It would but Per is right that this it is throwing ISE today, it's just that the PR adds an explicit check and that highlights that the wrong exception is thrown. Buffers that are views over memory that is thread confined can't be used with the AsynchronousXXXX APIs and this will needed to be specified. There is further work required in this area too because IOUtil was intended for synchronous I/O. The "async" support was added on a temporary basis and will need to be re-visited at some point. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Fri Nov 25 07:35:19 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 25 Nov 2022 07:35:19 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 20:22:16 GMT, Markus KARG wrote: > Kindly requesting review. :-) The override looks fine. I think [bplb](https://github.com/bplb) plans to review/sponsor it. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From Alan.Bateman at oracle.com Fri Nov 25 07:52:02 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2022 07:52:02 +0000 Subject: What is meant by "document context" in JEP 198? In-Reply-To: References: Message-ID: <6c96408c-8da2-10f0-2339-b0090d4d5ee2@oracle.com> On 25/11/2022 02:04, Ethan McCue wrote: > I suppose while I'm asking questions - what exactly are the parts of > the JDK making use of ad-hoc json? Maybe we could ship *something* as > a jdk.internal module for those use cases? > JEP 198 pre-dates records, sealed classes, pattern matching, ... and I will assume will re-drafted or replaced when the time comes. Right now, I don't think there are too many places in the JDK that interact with JSON.? The `jfr` tool can print the records from a JFR recording as a JSON document. The HotSpotDiagnosMXBean API and `jcmd` tool can generate a thread dump as a JSON document. I think the only parsing at this time is the HotSpot compiler control (JEP 165) where directives file is a subset of JSON but that is implemented in C++ in libjvm and probably not what you are looking for. There are number of places in the JDK that read configuration and it might be that some of these could consume configuration in JSON in the future. -Alan From turbanoff at gmail.com Fri Nov 25 13:17:45 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Fri, 25 Nov 2022 16:17:45 +0300 Subject: Redundant condition in java.math.MutableBigInteger#divideMagnitude Message-ID: Hello. I noticed that IntelliJ IDEA show warning in the method java.math.MutableBigInteger#divideMagnitude here - https://github.com/openjdk/jdk/blob/4f65570204e2d38415e7761bd81660b081eae882/src/java.base/share/classes/java/math/MutableBigInteger.java#L1536 It seems that condition is always 'true' if (rem.intLen == nlen) { 'rem' and 'nlen' variables are not changed anyhow after this assignment a few lines above: int nlen = rem.intLen; To make sure that it's really true, I've modified source to include else branch: } else { throw new AssertionError("Condition 'rem.intLen == nlen' wasn't met."); } And all tests from "jdk/java/math" passed. Can we clean up the code to remove this condition? Code is already complex enough and each condition makes its reading harder. It was added as part of performance improvements in https://bugs.openjdk.org/browse/JDK-7082971 Andrey Turbanov From ethan at mccue.dev Fri Nov 25 13:27:30 2022 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 25 Nov 2022 08:27:30 -0500 Subject: What is meant by "document context" in JEP 198? In-Reply-To: <6c96408c-8da2-10f0-2339-b0090d4d5ee2@oracle.com> References: <6c96408c-8da2-10f0-2339-b0090d4d5ee2@oracle.com> Message-ID: ...huh >> The recent removal of Nashorn has indicated several places were >> javascript were used in the JDK mainly due to it's built-in support for >> parsing JSON None of those seem like they would have been using nashorn in the past, so i wonder what this is referring to. On Fri, Nov 25, 2022 at 2:52 AM Alan Bateman wrote: > On 25/11/2022 02:04, Ethan McCue wrote: > > I suppose while I'm asking questions - what exactly are the parts of > > the JDK making use of ad-hoc json? Maybe we could ship *something* as > > a jdk.internal module for those use cases? > > > JEP 198 pre-dates records, sealed classes, pattern matching, ... and I > will assume will re-drafted or replaced when the time comes. > > Right now, I don't think there are too many places in the JDK that > interact with JSON. The `jfr` tool can print the records from a JFR > recording as a JSON document. The HotSpotDiagnosMXBean API and `jcmd` > tool can generate a thread dump as a JSON document. I think the only > parsing at this time is the HotSpot compiler control (JEP 165) where > directives file is a subset of JSON but that is implemented in C++ in > libjvm and probably not what you are looking for. > > There are number of places in the JDK that read configuration and it > might be that some of these could consume configuration in JSON in the > future. > > -Alan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Fri Nov 25 14:08:10 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2022 14:08:10 +0000 Subject: What is meant by "document context" in JEP 198? In-Reply-To: References: <6c96408c-8da2-10f0-2339-b0090d4d5ee2@oracle.com> Message-ID: On 25/11/2022 13:27, Ethan McCue wrote: > ...huh > > >>The recent removal of Nashorn has indicated several places were > >> javascript were used in the JDK mainly due to it's built-in support for > >> parsing JSON//None of those seem like they would have been using nashorn in the > past, so i wonder what this is referring to. The quoted text seems to be from a mail that Magnus Ihse Bursie sent to the discuss list in 2020 [1]. It's the same date that JDK-8242934 [1] was created so it may be that the mail was (at least partly) prompted by the need to change the test? for`jfr print --json`. The test for that feature used to use Nashorn and had to be changed to use a JSON parser in the test suite. The JSON parser was subsequently moved to test/lib/jdk/test/lib/json/JSONValue.java so it could be used by other tests. -Alan [1] https://mail.openjdk.org/pipermail/discuss/2020-April/005398.html [2] https://bugs.openjdk.org/browse/JDK-8242934 -------------- next part -------------- An HTML attachment was scrubbed... URL: From asotona at openjdk.org Fri Nov 25 15:20:20 2022 From: asotona at openjdk.org (Adam Sotona) Date: Fri, 25 Nov 2022 15:20:20 GMT Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 13:01:41 GMT, Adam Sotona wrote: >> make/modules/java.base/Java.gmk line 37: >> >>> 35: >>> 36: EXCLUDES += java/lang/doc-files >>> 37: EXCLUDES += jdk/classfile/snippets >> >> I don't like hard-coded excludes like this. Is this the first real-world example of snippets in the JDK? If not, how has this been resolved in other instances? Maybe we need a more general method to exclude snippets from compiling. > > I'll fix it, thanks. Unfortunately I found only two use cases of external snippets in JDK. One is explicitly excluding the snippets package and the other does not care, so the snippets are included. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From ethan at mccue.dev Fri Nov 25 16:02:18 2022 From: ethan at mccue.dev (Ethan McCue) Date: Fri, 25 Nov 2022 11:02:18 -0500 Subject: What is meant by "document context" in JEP 198? In-Reply-To: References: <6c96408c-8da2-10f0-2339-b0090d4d5ee2@oracle.com> Message-ID: That tracks. The component I, personally, might want JSON available internally for is an artifact resolution API [1]. Gradle's module metadata is out there in the world and could be worth consuming [2]. That's neither here nor there though. I'd say that the JEP as written could use some rework even before its "time has come". * Goals like "useful subset for Java ME" don't feel relevant anymore. * Unstated goals that seem implicit in how folks have talked about potential APIs, like "improve over JSR-353" or "obviate ecosystem desire for JAXB type data binding" * "Goals" that seem derived more from the properties of whatever prototype implementation the JEP had than a core "user story". A split token/event/immutable tree API is just one possible solution to problems like big documents and letting power users avoid allocations. [1]: https://mail.openjdk.org/pipermail/core-libs-dev/2022-September/094231.html [2]: https://docs.gradle.org/current/userguide/publishing_gradle_module_metadata.html On Fri, Nov 25, 2022 at 9:08 AM Alan Bateman wrote: > On 25/11/2022 13:27, Ethan McCue wrote: > > ...huh > > >> The recent removal of Nashorn has indicated several places were > >> javascript were used in the JDK mainly due to it's built-in support for > >> parsing JSON > None of those seem like they would have been using nashorn in the past, so i wonder what this is referring to. > > > The quoted text seems to be from a mail that Magnus Ihse Bursie sent to > the discuss list in 2020 [1]. It's the same date that JDK-8242934 [1] was > created so it may be that the mail was (at least partly) prompted by the > need to change the test for`jfr print --json`. The test for that feature > used to use Nashorn and had to be changed to use a JSON parser in the test > suite. The JSON parser was subsequently moved to > test/lib/jdk/test/lib/json/JSONValue.java so it could be used by other > tests. > > -Alan > > [1] https://mail.openjdk.org/pipermail/discuss/2020-April/005398.html > [2] https://bugs.openjdk.org/browse/JDK-8242934 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mchhipa at openjdk.org Fri Nov 25 17:05:11 2022 From: mchhipa at openjdk.org (Mahendra Chhipa) Date: Fri, 25 Nov 2022 17:05:11 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v4] In-Reply-To: References: Message-ID: <4y7Bt3HYXsF48N7jku8aOSm8v9vHeywxe0nfX_2hBmI=.f4c24c4b-5ee0-4ced-ba0d-9f6dda1ff632@github.com> On Sat, 5 Nov 2022 00:04:39 GMT, Bill Huang wrote: >> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. >> >> Tests include: >> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java >> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java >> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments. LGTM ------------- PR: https://git.openjdk.org/jdk/pull/10825 From pminborg at openjdk.org Sat Nov 26 08:31:11 2022 From: pminborg at openjdk.org (Per Minborg) Date: Sat, 26 Nov 2022 08:31:11 GMT Subject: Integrated: 8297148: Add a @sealedGraph tag to CallSite In-Reply-To: <8IJ8LRjjK2Tgwudor4KPiAhw-NmlLgXnZFtv6ctqn4w=.9e95d42d-4095-456f-8af5-0274f32eadd4@github.com> References: <8IJ8LRjjK2Tgwudor4KPiAhw-NmlLgXnZFtv6ctqn4w=.9e95d42d-4095-456f-8af5-0274f32eadd4@github.com> Message-ID: On Wed, 16 Nov 2022 16:17:01 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy of the CallSite class. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > Here is how it would look like: > > CallSite_SH This pull request has now been integrated. Changeset: 099b42f3 Author: Per Minborg Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/099b42f360a0e693a63f009e3e044307aab5c689 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8297148: Add a @sealedGraph tag to CallSite Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/11190 From pminborg at openjdk.org Sat Nov 26 08:32:21 2022 From: pminborg at openjdk.org (Per Minborg) Date: Sat, 26 Nov 2022 08:32:21 GMT Subject: Integrated: 8297145: Add a @sealedGraph tag to ConstantDesc In-Reply-To: <32YXgAxjMzKxazWeNKQIbrEqDG79l2MWz9WJdBM0A5I=.020ea8a9-d48d-4f3c-900c-6279533c8ddd@github.com> References: <32YXgAxjMzKxazWeNKQIbrEqDG79l2MWz9WJdBM0A5I=.020ea8a9-d48d-4f3c-900c-6279533c8ddd@github.com> Message-ID: On Wed, 16 Nov 2022 15:02:08 GMT, Per Minborg wrote: > This PR proposes to opt in for graphic rendering of the sealed hierarchy of the ConstantDesc class. > > Rendering capability was added via https://bugs.openjdk.org/browse/JDK-8295653 > > > Here is how it would look like: > > ConstantDesc_SH This pull request has now been integrated. Changeset: 76a24c3f Author: Per Minborg Committer: Alan Bateman URL: https://git.openjdk.org/jdk/commit/76a24c3f90d8e0655bfcaa3dd5c2d1f74515ebc6 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8297145: Add a @sealedGraph tag to ConstantDesc Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/11187 From duke at openjdk.org Sat Nov 26 14:48:35 2022 From: duke at openjdk.org (Ryan Ernst) Date: Sat, 26 Nov 2022 14:48:35 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v2] In-Reply-To: References: Message-ID: > This commit guards thread modifications for the process reaper thread with doPrivileged. Ryan Ernst has updated the pull request incrementally with two additional commits since the last revision: - Merge pull request #1 from ChrisHegarty/reaper_thread_modify Add privileged helper method and update existing test - Add privileged helper method and update existing test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11309/files - new: https://git.openjdk.org/jdk/pull/11309/files/c02f3f09..a822cc8e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11309&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11309&range=00-01 Stats: 31 lines in 2 files changed: 20 ins; 6 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11309.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11309/head:pull/11309 PR: https://git.openjdk.org/jdk/pull/11309 From duke at openjdk.org Sat Nov 26 15:55:27 2022 From: duke at openjdk.org (Ryan Ernst) Date: Sat, 26 Nov 2022 15:55:27 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v3] In-Reply-To: References: Message-ID: > This commit guards thread modifications for the process reaper thread with doPrivileged. Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: Revert factory method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11309/files - new: https://git.openjdk.org/jdk/pull/11309/files/a822cc8e..bc42d415 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11309&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11309&range=01-02 Stats: 29 lines in 2 files changed: 9 ins; 12 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11309.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11309/head:pull/11309 PR: https://git.openjdk.org/jdk/pull/11309 From chegar at openjdk.org Sat Nov 26 15:55:27 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Sat, 26 Nov 2022 15:55:27 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v3] In-Reply-To: References: Message-ID: On Sat, 26 Nov 2022 15:50:54 GMT, Ryan Ernst wrote: >> This commit guards thread modifications for the process reaper thread with doPrivileged. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > Revert factory method LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/11309 From chegar at openjdk.org Sat Nov 26 16:39:06 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Sat, 26 Nov 2022 16:39:06 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v3] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 16:02:37 GMT, Chris Hegarty wrote: >> I would prefer to to avoid creating new factories when the desired function can be done on the resulting thread. >> Such as `setDaemon()` and `setName()`, etc. >> It does avoid the doPriv in this case, but is not necessary and when the security manager goes away, will leave around clutter (duplicated) functionality. > > Looking beyond this specific change, there is a lot of potential use for this new factory elsewhere in the code. It also avoids similar bugs from possibly reoccurring (by having the setDaemon call inside the factory). In the interest of making progress, let?s revert the change to the factory. This can be done separately, if at all. ------------- PR: https://git.openjdk.org/jdk/pull/11309 From alanb at openjdk.org Sat Nov 26 17:26:07 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 26 Nov 2022 17:26:07 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v3] In-Reply-To: References: Message-ID: On Sat, 26 Nov 2022 15:55:27 GMT, Ryan Ernst wrote: >> This commit guards thread modifications for the process reaper thread with doPrivileged. > > Ryan Ernst has updated the pull request incrementally with one additional commit since the last revision: > > Revert factory method This looks okay. Not important but can eliminate the casts from privilegedThreadSetXXX methods if you separate the creation of the PrivilegedAction from the doPriv call. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11309 From ihse at openjdk.org Sat Nov 26 18:44:51 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sat, 26 Nov 2022 18:44:51 GMT Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 15:18:09 GMT, Adam Sotona wrote: >> I'll fix it, thanks. > > Unfortunately I found only two use cases of external snippets in JDK. One is explicitly excluding the snippets package and the other does not care, so the snippets are included. Is the practice of naming the directory `snippets` well-established or mandated? Otherwise I think a name like `snippet-files` (akin to `doc-files`) would be much better, since it indicates that is not a java package name. (These do not usually include `-`; I am unsure if this is prohibited by the specification, or just not used by convention.) In fact, when checking, I see that there is already a handful of `snippet-files`: ./jdk.jfr/share/classes/jdk/jfr/snippet-files ./jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files ./java.compiler/share/classes/javax/tools/snippet-files So maybe rename it to `snippet-files`, and I'll look into making exclusion of `snippet-files` be done automatically. ------------- PR: https://git.openjdk.org/jdk/pull/10982 From duke at openjdk.org Sat Nov 26 20:04:46 2022 From: duke at openjdk.org (Ryan Ernst) Date: Sat, 26 Nov 2022 20:04:46 GMT Subject: RFR: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread [v3] In-Reply-To: References: Message-ID: On Sat, 26 Nov 2022 17:24:02 GMT, Alan Bateman wrote: > Not important but can eliminate the casts from privilegedThreadSetXXX methods if you separate the creation of the PrivilegedAction from the doPriv call. I chose to keep it as is since there was already another doPriv in the file that uses the cast style. ------------- PR: https://git.openjdk.org/jdk/pull/11309 From duke at openjdk.org Sat Nov 26 20:07:40 2022 From: duke at openjdk.org (Ryan Ernst) Date: Sat, 26 Nov 2022 20:07:40 GMT Subject: Integrated: 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 05:01:40 GMT, Ryan Ernst wrote: > This commit guards thread modifications for the process reaper thread with doPrivileged. This pull request has now been integrated. Changeset: 50f9043c Author: Ryan Ernst Committer: Chris Hegarty URL: https://git.openjdk.org/jdk/commit/50f9043c6965360c426b187e47c49c42481a2549 Stats: 36 lines in 2 files changed: 29 ins; 0 del; 7 mod 8297451: ProcessHandleImpl should assert privilege when modifying reaper thread Reviewed-by: chegar, alanb ------------- PR: https://git.openjdk.org/jdk/pull/11309 From egahlin at openjdk.org Sun Nov 27 01:40:14 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Sun, 27 Nov 2022 01:40:14 GMT Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API In-Reply-To: References: Message-ID: On Sat, 26 Nov 2022 18:42:39 GMT, Magnus Ihse Bursie wrote: >> Unfortunately I found only two use cases of external snippets in JDK. One is explicitly excluding the snippets package and the other does not care, so the snippets are included. > > Is the practice of naming the directory `snippets` well-established or mandated? Otherwise I think a name like `snippet-files` (akin to `doc-files`) would be much better, since it indicates that is not a java package name. (These do not usually include `-`; I am unsure if this is prohibited by the specification, or just not used by convention.) > > In fact, when checking, I see that there is already a handful of `snippet-files`: > > ./jdk.jfr/share/classes/jdk/jfr/snippet-files > ./jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files > ./java.compiler/share/classes/javax/tools/snippet-files > > > So maybe rename it to `snippet-files`, and I'll look into making exclusion of `snippet-files` be done automatically. It would be nice to get the directory excluded by default. I used the snippet-files name since it was mentioned in the JEP https://openjdk.org/jeps/413 ------------- PR: https://git.openjdk.org/jdk/pull/10982 From alanb at openjdk.org Sun Nov 27 16:59:51 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 27 Nov 2022 16:59:51 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v14] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Reformat and fix comment The latest version (30aff118) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP 434 integrated or soon afterwards? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Sun Nov 27 17:09:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 27 Nov 2022 17:09:20 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v14] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Reformat and fix comment src/java.base/share/classes/java/util/zip/Deflater.java line 594: > 592: try { > 593: result = deflateBufferBytes(zsRef.address(), > 594: ((DirectBuffer) input).address() + inputPos, inputRem, Somewhat subjective but the original code, with inputAddress, was a easier to read and avoided having too much going on in the parameters to deflateBufferBytes. In any case, you probably should fix the formatting to avoid have different parameters with different indentations. src/java.base/share/classes/java/util/zip/Deflater.java line 717: > 715: result = deflateBytesBuffer(zsRef.address(), > 716: inputArray, inputPos, inputLim - inputPos, > 717: ((DirectBuffer) output).address() + outputPos, outputRem, Same here, I think I would keep outputAddress to keep the call to deflateByteBuffer simple. src/java.base/share/classes/java/util/zip/Deflater.java line 740: > 738: try { > 739: result = deflateBufferBuffer(zsRef.address(), > 740: ((DirectBuffer) input).address() + inputPos, inputRem, Another one where inputAddress and outputAddress have been removed so the call to deflatBufferBuffer is much hard to digest. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From duke at openjdk.org Sun Nov 27 17:53:19 2022 From: duke at openjdk.org (Markus KARG) Date: Sun, 27 Nov 2022 17:53:19 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Mon, 21 Nov 2022 18:22:26 GMT, Jens Lidestrom wrote: >> I think the public visibility of my Twitter account is not wide enough to get *really robust* answers, unfortunately. So far, 92% answered that they not even used SIS in their whole life. So the users of two-args constructor must be really neglectable. Nevertheless, they are definitively not zero, so all we could do is marking it deprecated some day. >> >> Anyways, thanks for the review. At least we get rid of `Vector` here. Would be happy if you mark the PR as reviewed. :-) > >> I think the public visibility of my Twitter account is not wide enough to get really robust answers, unfortunately. > > One alternative is to search GitHub. It's amazing how fast they can search such a huge code corpus. > > Example: https://github.com/search?l=&q=%22new+SequenceInputStream%22+-filename%3ASequenceInputStreamTest.java&type=code > > One problem with GitHub search is that often you get a lot of duplicate matches. In the example above I have filtered out `SequenceInputStreamTest.java` which showed up a lot. Twitter survey results after one week: 5.4% of all voters have actually used SIS before! This number is big enough to consider SIS as "not irrelevant". OTOH this number is so small that any further poll whether this 5.4% actually used the one-arg or two-arg constructor would not provide stable results. Looking at the results of @jensli's GitHub search tells us that apparently *all* of those findings are using 2-args. So we actually need to be careful, not to break (up to) 5.4% of all existing applications. So what could be our plan to improve the live of that 5.4%? Some thoughts: 1. We could safely add a `public InputStream concat(InputStream)` *default method* to `InputStream` as a factory for *anonymous* sequences. This allows any IS implementation to provide an optimized variant if needed/wanted, falling back to the existing SIS *by default* as a starting point (until we come up with a better fallback implementation). 2. Having done that, we could deprecate-for-removal SIS with the clear note that from now on `concat` should be used instead. This triggers people to overhaul their existing code little by little, while we gain time to work on a replacement for SIS. 3. We then could provide a **non-public** `ConcatenatedInputStream` which holds **exactly two** IS (`first` and `last` MUST be given), and make that one the default implementation of `concat`, gaining a modern, easy-to-maintain, fully tested, high-performance, sequence of streams. 4. Some fine day we do remove SIS, effectively getting rid of the discussed quirky behavior. @AlanBateman How does that sound? Shall I go on with a PR for step 1.? ------------- PR: https://git.openjdk.org/jdk/pull/11249 From mernst at openjdk.org Sun Nov 27 17:53:30 2022 From: mernst at openjdk.org (Michael Ernst) Date: Sun, 27 Nov 2022 17:53:30 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 16:51:36 GMT, Michael Ernst wrote: >> 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni > > Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Reinstate typos in Apache code that is copied into the JDK > - Merge ../jdk-openjdk into typos-typos > - Remove file that was removed upstream > - Fix inconsistency in capitalization > - Undo change in zlip > - Fix typos Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From aturbanov at openjdk.org Sun Nov 27 19:16:54 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 27 Nov 2022 19:16:54 GMT Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints() In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 10:08:31 GMT, Sergey Tsypanov wrote: > `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`. Marked as reviewed by aturbanov (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/11350 From jcking at openjdk.org Mon Nov 28 03:30:33 2022 From: jcking at openjdk.org (Justin King) Date: Mon, 28 Nov 2022 03:30:33 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling Message-ID: Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. ------------- Commit messages: - Fix memory leaks related to options in libjli Changes: https://git.openjdk.org/jdk/pull/11384/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11384&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297688 Stats: 55 lines in 2 files changed: 22 ins; 1 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/11384.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11384/head:pull/11384 PR: https://git.openjdk.org/jdk/pull/11384 From dholmes at openjdk.org Mon Nov 28 04:06:11 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 28 Nov 2022 04:06:11 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. Doesn't this just "leak" the duplicated string now instead of the original? ------------- PR: https://git.openjdk.org/jdk/pull/11384 From jcking at openjdk.org Mon Nov 28 04:16:50 2022 From: jcking at openjdk.org (Justin King) Date: Mon, 28 Nov 2022 04:16:50 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 04:02:33 GMT, David Holmes wrote: > Doesn't this just "leak" the duplicated string now instead of the original? No, this frees all the strings in `FreeOptions()`. ------------- PR: https://git.openjdk.org/jdk/pull/11384 From dholmes at openjdk.org Mon Nov 28 04:48:33 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 28 Nov 2022 04:48:33 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. Sorry I misread things. I do worry about the extra overhead of this additional string copying though ... but I will leave that for core-libs folk to decide. ------------- PR: https://git.openjdk.org/jdk/pull/11384 From jcking at openjdk.org Mon Nov 28 05:10:07 2022 From: jcking at openjdk.org (Justin King) Date: Mon, 28 Nov 2022 05:10:07 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. We can always add two separate functions or a separate parameter signifying ownership semantics. Then deal with it appropriately by maintaining a separate list of owned strings. Up to core-libs. I just went for the path of least complexity to start with. ------------- PR: https://git.openjdk.org/jdk/pull/11384 From pminborg at openjdk.org Mon Nov 28 08:38:55 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 28 Nov 2022 08:38:55 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v14] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 16:21:42 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Reformat and fix comment > The latest version ([30aff11](https://github.com/openjdk/jdk/commit/30aff1187d4978c59d1e6feebafc2d45aba3e5f2)) looks quite good but the naming at the use sites (`var scope = NIO_ACCESS.acquireSession(buffer);`) is temporarily confusing. Will that be fixed with the JEP 434 integrated or soon afterwards? The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (*Session* -> *Scope*) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion? ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 28 08:51:07 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 08:51:07 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. If I read this correctly, the additional overhead for each option is a JLI_StringDup/JLI_MemFree, and a JLI_MemFree for the options that required JLI_MemAlloc. So while the ownership is clear, there is a lot of copying going on when there is a lot of XX options. It might be worth trying the other suggestion to have a parameter AddOption indicate if the option needs to be freed later (or a separate function). It does mean another array to track if the option should be freed but we can at least see how easy it is to maintain. ------------- PR: https://git.openjdk.org/jdk/pull/11384 From jpai at openjdk.org Mon Nov 28 09:02:13 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Nov 2022 09:02:13 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Sun, 27 Nov 2022 17:49:57 GMT, Michael Ernst wrote: > Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs. ------------- PR: https://git.openjdk.org/jdk/pull/10029 From jpai at openjdk.org Mon Nov 28 09:07:24 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Nov 2022 09:07:24 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Message-ID: Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. I'll raise separate PRs in the other remaining areas from that other PR. ------------- Commit messages: - 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Changes: https://git.openjdk.org/jdk/pull/11385/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11385&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294321 Stats: 21 lines in 20 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/11385.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11385/head:pull/11385 PR: https://git.openjdk.org/jdk/pull/11385 From jcking at openjdk.org Mon Nov 28 09:07:44 2022 From: jcking at openjdk.org (Justin King) Date: Mon, 28 Nov 2022 09:07:44 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling [v2] In-Reply-To: References: Message-ID: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. Justin King has updated the pull request incrementally with one additional commit since the last revision: Maintain separate list of dynamically allocated option strings Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11384/files - new: https://git.openjdk.org/jdk/pull/11384/files/cbd06fda..564d1733 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11384&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11384&range=00-01 Stats: 48 lines in 1 file changed: 26 ins; 9 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11384.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11384/head:pull/11384 PR: https://git.openjdk.org/jdk/pull/11384 From jcking at openjdk.org Mon Nov 28 09:10:29 2022 From: jcking at openjdk.org (Justin King) Date: Mon, 28 Nov 2022 09:10:29 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling [v3] In-Reply-To: References: Message-ID: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. Justin King has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary NULL assignment in FreeOptions Signed-off-by: Justin King ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11384/files - new: https://git.openjdk.org/jdk/pull/11384/files/564d1733..dc9b0be6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11384&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11384&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11384.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11384/head:pull/11384 PR: https://git.openjdk.org/jdk/pull/11384 From jcking at openjdk.org Mon Nov 28 09:10:30 2022 From: jcking at openjdk.org (Justin King) Date: Mon, 28 Nov 2022 09:10:30 GMT Subject: RFR: JDK-8297688: libjli leaks memory related to options handling In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote: > Fix memory leaks by making `AddOption` unconditionally duplicate passed in strings, taking ownership. Callers using dynamic memory free their storage after calling `AddOption`. This ensures no memory is dropped on the floor. This also removes the second argument to `AddOption` as it is unused and shifts it into the source file. Switched to maintaining a separate list of allocated strings instead of always duplicating strings. `AddOptions` does not take ownership of the underlying string. `AddAllocatedOptions` is `AddOptions` but the given string is freed later after the the JVM has been initialized. ------------- PR: https://git.openjdk.org/jdk/pull/11384 From alanb at openjdk.org Mon Nov 28 09:13:34 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 09:13:34 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. > > I'll raise separate PRs in the other remaining areas from that other PR. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11385 From alanb at openjdk.org Mon Nov 28 09:43:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 09:43:18 GMT Subject: RFR: JDK-8297299 SequenceInputStream should not use Vector [v2] In-Reply-To: References: <-S9q3AKDQbNqmMKh9HorcOcsfM6zQpDcgMuIJZaQ4r0=.7f6b403d-0823-4e16-9331-968aa5cc3fa7@github.com> <3toZC9GIobPMMI82rZCE7VD-sLvTbHeuxrsXRMdafDs=.3653dec4-e321-4753-af22-92e667bd7917@github.com> Message-ID: On Sun, 27 Nov 2022 17:49:25 GMT, Markus KARG wrote: >>> I think the public visibility of my Twitter account is not wide enough to get really robust answers, unfortunately. >> >> One alternative is to search GitHub. It's amazing how fast they can search such a huge code corpus. >> >> Example: https://github.com/search?l=&q=%22new+SequenceInputStream%22+-filename%3ASequenceInputStreamTest.java&type=code >> >> One problem with GitHub search is that often you get a lot of duplicate matches. In the example above I have filtered out `SequenceInputStreamTest.java` which showed up a lot. > > Twitter survey results after one week: 5.4% of all voters have actually used SIS before! This number is big enough to consider SIS as "not irrelevant". OTOH this number is so small that any further poll whether this 5.4% actually used the one-arg or two-arg constructor would not provide stable results. Looking at the results of @jensli's GitHub search tells us that apparently *all* of those findings are using 2-args. So we actually need to be careful, not to break (up to) 5.4% of all existing applications. > > So what could be our plan to improve the live of that 5.4%? Some thoughts: > 1. We could safely add a `public InputStream concat(InputStream)` *default method* to `InputStream` as a factory for *anonymous* sequences. This allows any IS implementation to provide an optimized variant if needed/wanted, falling back to the existing SIS *by default* as a starting point (until we come up with a better fallback implementation). > 2. Having done that, we could deprecate-for-removal SIS with the clear note that from now on `concat` should be used instead. This triggers people to overhaul their existing code little by little, while we gain time to work on a replacement for SIS. > 3. We then could provide a **non-public** `ConcatenatedInputStream` which holds **exactly two** IS (`first` and `last` MUST be given), and make that one the default implementation of `concat`, gaining a modern, easy-to-maintain, fully tested, high-performance, sequence of streams. > 4. Some fine day we do remove SIS, effectively getting rid of the discussed quirky behavior. > > @AlanBateman How does that sound? Shall I go on with a PR for step 1.? I did a search of 30M classes in 130k artifacts from Maven Central and it found usages in 1670 classes in 852 artifacts. I haven't dug into it too closely but it looks like the usages are mostly (if not all) the 2-arg constructor. If you have the cycles, then prototyping a _concat_ method (you could try both instance and static) would help inform on issues and whether this is worth doing. Adding methods to older, and widely used, classes such as InputStream will often encounter compatibility issues. For the instance method you'll need to think about security/snooping issues. I think it would also be useful to survey libraries that provide an equivalent and if there is much usage. SIS may be legacy but I don't think there is a case to deprecate it at this time. ------------- PR: https://git.openjdk.org/jdk/pull/11249 From alanb at openjdk.org Mon Nov 28 09:56:14 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 09:56:14 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. > > I'll raise separate PRs in the other remaining areas from that other PR. test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67: > 65: * to generate elements type your Subscriber is able to consume. > 66: *

      > 67: * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber The comment on the original PR is that this is a 3rd party code and not clear if it should be changed. ------------- PR: https://git.openjdk.org/jdk/pull/11385 From jpai at openjdk.org Mon Nov 28 10:02:47 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Nov 2022 10:02:47 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. > > I'll raise separate PRs in the other remaining areas from that other PR. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Address review comment - don't change WithHelperPublisher.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11385/files - new: https://git.openjdk.org/jdk/pull/11385/files/85669caf..37a51582 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11385&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11385&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11385.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11385/head:pull/11385 PR: https://git.openjdk.org/jdk/pull/11385 From jpai at openjdk.org Mon Nov 28 10:02:50 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Nov 2022 10:02:50 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 09:54:08 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comment - don't change WithHelperPublisher.java > > test/jdk/java/net/httpclient/reactivestreams-tck/org/reactivestreams/tck/WithHelperPublisher.java line 67: > >> 65: * to generate elements type your Subscriber is able to consume. >> 66: *

      >> 67: * Sometimes you may want to implement your own custom helper Publisher - to validate behaviour of a Subscriber > > The comment on the original PR is that this is a 3rd party code and not clear if it should be changed. Hello Alan, I have now updated this PR to remove changes to this file. ------------- PR: https://git.openjdk.org/jdk/pull/11385 From pminborg at openjdk.org Mon Nov 28 10:36:40 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 28 Nov 2022 10:36:40 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v15] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Re-introduce address variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/30aff118..95c40581 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=13-14 Stats: 24 lines in 2 files changed: 11 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 28 10:40:11 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 10:40:11 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v15] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 10:36:40 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Re-introduce address variables > The name was selected in anticipation of the proposed renaming in JEP 434. I think once the JEP is merged, we can rename some of the methods (_Session_ -> _Scope_) and then the user site naming would be much better. Another alternative, which certainly can be done, is to rename `scope` to `session` and then rename these back again when the JEP is merged. What is the preferred way in your opinion? Whatever is easiest. Given the fork for JDK 20 is coming up soon then it would be good to get the rename done soon after JEP 434 integrates, just to avoid JDK 20 having the mix of names. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From pminborg at openjdk.org Mon Nov 28 10:47:47 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 28 Nov 2022 10:47:47 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v16] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Re-introduce yet another address vairable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/95c40581..eedf41ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=14-15 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Mon Nov 28 10:55:02 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 10:55:02 GMT Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 Message-ID: The proposed updates for JDK 20 are: - ForkJoinPool.externalSubmit - ForkJoinWorkerThread.getQueuedTaskCount These methods will be used to improve the Thread.yield implementation for virtual threads. The range of alternatives explored include not exposing an API and protected methods such as "offerSubmission". The class description speaks of "external clients" and "submissions from non-ForkJoinTask clients", hence the proposed naming and javadoc text. ------------- Commit messages: - Improve javadoc - Merge - Initial commit Changes: https://git.openjdk.org/jdk/pull/11319/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11319&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297495 Stats: 237 lines in 4 files changed: 233 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11319.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11319/head:pull/11319 PR: https://git.openjdk.org/jdk/pull/11319 From alanb at openjdk.org Mon Nov 28 11:19:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 11:19:20 GMT Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension Message-ID: Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup. java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified . The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method. It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. ------------- Commit messages: - Remove allowThreadSuspension Changes: https://git.openjdk.org/jdk/pull/11373/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11373&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297295 Stats: 24 lines in 2 files changed: 0 ins; 24 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11373.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11373/head:pull/11373 PR: https://git.openjdk.org/jdk/pull/11373 From lancea at openjdk.org Mon Nov 28 11:29:09 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 28 Nov 2022 11:29:09 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. >> >> I'll raise separate PRs in the other remaining areas from that other PR. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - don't change WithHelperPublisher.java Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11385 From shade at openjdk.org Mon Nov 28 12:09:08 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 28 Nov 2022 12:09:08 GMT Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory [v2] In-Reply-To: References: Message-ID: <7jXzpo2jiJQKxSFTVpuanwyEe1j74uOI0qqL_ZI9IRo=.ed533750-9dce-41f1-b0b0-49206bc04b1a@github.com> On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev wrote: >> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s >> ... >> >> $ ls >> Apan.class >> ``` >> >> Additional testing: >> - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8296645-javac-bench-class-files > - Fix indenting > - Fix Anyone? :) ------------- PR: https://git.openjdk.org/jdk/pull/11055 From jvernee at openjdk.org Mon Nov 28 12:11:00 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 28 Nov 2022 12:11:00 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v31] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 17:33:06 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues Latest version looks good to me as well ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Mon Nov 28 12:14:50 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 28 Nov 2022 12:14:50 GMT Subject: RFR: 8296477: Foreign linker implementation update following JEP 434 [v9] In-Reply-To: References: Message-ID: > Pull in linker implementation changes, that include non-trivial changes to VM code, from the panama-foreign repo into the main JDK. > > This is split off from the main JEP integration to make reviewing easier. > > This includes the following patches: > > 1. https://github.com/openjdk/panama-foreign/pull/698 > 2. https://github.com/openjdk/panama-foreign/pull/699 > 3. (part of) https://github.com/openjdk/panama-foreign/pull/731 > 4. https://github.com/openjdk/panama-foreign/pull/740 > 5. https://github.com/openjdk/panama-foreign/pull/746 > 6. https://github.com/openjdk/panama-foreign/pull/742 > 7. https://github.com/openjdk/panama-foreign/pull/743 > > Probably the biggest change to the code comes from replacing `VMReg` - which can not represent offsets into the stack that are not a multiple of the VM's stack slot size (32-bits) - with the new `VMStorage` class, which can describe byte offsets into the stack, as well as having a register mask to indicate only certain register segments. > > The only part of 3. that is in this PR is the part that turns the `VMStorage` class in Java into a record. > > Please refer to the PR of each individual patch for a more detailed description. Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision: - use Arena in example - Merge branch 'PR_20' into VM_Changes - drop .inline from vmstorage header names - 8296973: saving errno on a value-returning function crashes the JVM Reviewed-by: mcimadamore - fix stubs - constexpr some functions - Review pt1 - Tweak copyright headers - Use @requires to disable some tests on x86 - Use AssertionError for internal exceptions - ... and 13 more: https://git.openjdk.org/jdk/compare/bbde3878...75917216 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11019/files - new: https://git.openjdk.org/jdk/pull/11019/files/03be64c9..75917216 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11019&range=07-08 Stats: 16892 lines in 695 files changed: 7158 ins; 6214 del; 3520 mod Patch: https://git.openjdk.org/jdk/pull/11019.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11019/head:pull/11019 PR: https://git.openjdk.org/jdk/pull/11019 From raffaello.giulietti at oracle.com Mon Nov 28 12:35:45 2022 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 28 Nov 2022 12:35:45 +0000 Subject: Redundant condition in java.math.MutableBigInteger#divideMagnitude In-Reply-To: References: Message-ID: I can confirm that testing that condition is indeed useless From: core-libs-dev on behalf of Andrey Turbanov Date: Friday, 2022-November-25 at 14:18 To: core-libs-dev Subject: Redundant condition in java.math.MutableBigInteger#divideMagnitude Hello. I noticed that IntelliJ IDEA show warning in the method java.math.MutableBigInteger#divideMagnitude here - https://github.com/openjdk/jdk/blob/4f65570204e2d38415e7761bd81660b081eae882/src/java.base/share/classes/java/math/MutableBigInteger.java#L1536 It seems that condition is always 'true' if (rem.intLen == nlen) { 'rem' and 'nlen' variables are not changed anyhow after this assignment a few lines above: int nlen = rem.intLen; To make sure that it's really true, I've modified source to include else branch: } else { throw new AssertionError("Condition 'rem.intLen == nlen' wasn't met."); } And all tests from "jdk/java/math" passed. Can we clean up the code to remove this condition? Code is already complex enough and each condition makes its reading harder. It was added as part of performance improvements in https://bugs.openjdk.org/browse/JDK-7082971 Andrey Turbanov -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Mon Nov 28 12:48:18 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 12:48:18 GMT Subject: RFR: 8297717: Remove jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java from ProblemList Message-ID: <94xltYMp2EmStWlKHsNAgXxgwFG7amb25ea5LjNqoVU=.56d19e0d-82ab-4fcd-89d0-a799bc789a4f@github.com> JDK-8291760 removed java/lang/ProcessBuilder/PipelineLeaksFD.java from test/jdk/ProblemList.txt but accidentally added jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java, presumably there was a merge at the time. ------------- Commit messages: - Remove test from ProblemList.txt Changes: https://git.openjdk.org/jdk/pull/11389/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11389&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297717 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11389.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11389/head:pull/11389 PR: https://git.openjdk.org/jdk/pull/11389 From redestad at openjdk.org Mon Nov 28 12:56:34 2022 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 28 Nov 2022 12:56:34 GMT Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory [v2] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev wrote: >> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s >> ... >> >> $ ls >> Apan.class >> ``` >> >> Additional testing: >> - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8296645-javac-bench-class-files > - Fix indenting > - Fix LGTM ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.org/jdk/pull/11055 From jpai at openjdk.org Mon Nov 28 13:15:33 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Nov 2022 13:15:33 GMT Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 18:54:28 GMT, Alan Bateman wrote: > Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup. > > java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified . > > The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. > > A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method. > > It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. Looks fine to me. > Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. I guess, this would then mean this PR will be integrated into mainline after 8th December when the branch for JDK 20 will be forked https://openjdk.org/projects/jdk/20/#Schedule? ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11373 From jpai at openjdk.org Mon Nov 28 13:19:49 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 28 Nov 2022 13:19:49 GMT Subject: RFR: 8297717: Remove jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java from ProblemList In-Reply-To: <94xltYMp2EmStWlKHsNAgXxgwFG7amb25ea5LjNqoVU=.56d19e0d-82ab-4fcd-89d0-a799bc789a4f@github.com> References: <94xltYMp2EmStWlKHsNAgXxgwFG7amb25ea5LjNqoVU=.56d19e0d-82ab-4fcd-89d0-a799bc789a4f@github.com> Message-ID: On Mon, 28 Nov 2022 12:38:20 GMT, Alan Bateman wrote: > JDK-8291760 removed java/lang/ProcessBuilder/PipelineLeaksFD.java from test/jdk/ProblemList.txt but accidentally added jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java, presumably there was a merge at the time. Marked as reviewed by jpai (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11389 From alanb at openjdk.org Mon Nov 28 13:30:34 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 13:30:34 GMT Subject: Integrated: 8297717: Remove jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java from ProblemList In-Reply-To: <94xltYMp2EmStWlKHsNAgXxgwFG7amb25ea5LjNqoVU=.56d19e0d-82ab-4fcd-89d0-a799bc789a4f@github.com> References: <94xltYMp2EmStWlKHsNAgXxgwFG7amb25ea5LjNqoVU=.56d19e0d-82ab-4fcd-89d0-a799bc789a4f@github.com> Message-ID: On Mon, 28 Nov 2022 12:38:20 GMT, Alan Bateman wrote: > JDK-8291760 removed java/lang/ProcessBuilder/PipelineLeaksFD.java from test/jdk/ProblemList.txt but accidentally added jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java, presumably there was a merge at the time. This pull request has now been integrated. Changeset: ba0a2521 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/ba0a2521ba6d7db041580be7cda633311836b455 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8297717: Remove jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java from ProblemList Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/11389 From alanb at openjdk.org Mon Nov 28 14:00:41 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 14:00:41 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v4] In-Reply-To: References: Message-ID: On Sat, 5 Nov 2022 00:04:39 GMT, Bill Huang wrote: >> The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. >> >> Tests include: >> java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java >> java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java >> javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java > > Bill Huang has updated the pull request incrementally with one additional commit since the last revision: > > Implemented review comments. test/jdk/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java line 167: > 165: Set.copyOf(Arrays.asList(InetAddress.getAllByName(myHostName))); > 166: Set hostAddrs = > 167: Set.copyOf(Arrays.asList(InetAddress.getAllByName(host))); Is there a reason to change this from Set.of? ------------- PR: https://git.openjdk.org/jdk/pull/10825 From duke at openjdk.org Mon Nov 28 14:06:38 2022 From: duke at openjdk.org (duke) Date: Mon, 28 Nov 2022 14:06:38 GMT Subject: Withdrawn: 8279361: Error in documentation of third Stream.reduce method In-Reply-To: References: Message-ID: On Wed, 28 Sep 2022 15:36:50 GMT, Viktor Klang wrote: > This JavaDoc change attempts to shine some light on the `combiner`-function as it relates to the third variant of `Stream.reduce` since it according to the bug submission in JBS can be confusing that the `combiner` is not mentioned in the code example in the documentation. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10469 From alanb at openjdk.org Mon Nov 28 14:12:55 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 14:12:55 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v16] In-Reply-To: References: Message-ID: <8-MFynuwsRGfpV5mqTvonYTwphy5h1Jzs0CO31Og-wQ=.1ec9c4d4-d7dd-4dd6-96de-d6aa60d89930@github.com> On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a try-with-resources friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned TwR is using a "session acquisition" that is not used explicitly in the try block itself. This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`. Another alternative was evaluated where a non-autocloseable resource was used. However, it became relatively complicated to guarantee that the session was always released and, at the same time, the existing 'final` block was always executed properly (as they both might throw exceptions). In the end, the proposed solution was much simpler and robust despite requiring a non-referenced TwR variable. >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Re-introduce yet another address vairable Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11260 From dfuchs at openjdk.org Mon Nov 28 14:27:32 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 28 Nov 2022 14:27:32 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: <6IgwmfUT8rOETK23hGf9t27oV1vdSLUUNr7QOvsmjII=.aa65f8e7-8c7a-4d3f-aa69-ef899725bcb4@github.com> On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. >> >> I'll raise separate PRs in the other remaining areas from that other PR. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - don't change WithHelperPublisher.java Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11385 From asotona at openjdk.org Mon Nov 28 14:44:40 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 28 Nov 2022 14:44:40 GMT Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v2] In-Reply-To: References: Message-ID: > **This pull request is not intended for immediate integration to JDK mainline.** > > This is root pull request with Classfile API implementation, tests and benchmarks initial drop into JDK. > > Following pull requests consolidating JDK class files parsing, generating, and transforming ([JDK-8294957](https://bugs.openjdk.org/browse/JDK-8294957)) will chain to this one. > > Classfile API development is tracked at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-branch > > Development branch of consolidated JDK class files parsing, generating, and transforming is at: > https://github.com/openjdk/jdk-sandbox/tree/classfile-api-dev-branch > > Classfile API [JEP](https://bugs.openjdk.org/browse/JDK-8280389) and [online API documentation](https://htmlpreview.github.io/?https://raw.githubusercontent.com/openjdk/jdk-sandbox/classfile-api-javadoc-branch/doc/classfile-api/javadoc/jdk/classfile/package-summary.html) is also available. > > Please take you time to review this non-trivial JDK addition. > > Thank you, > Adam Adam Sotona has updated the pull request incrementally with one additional commit since the last revision: PackageSnippets moved from jdk/classfile/snippets to jdk/classfile/snippet-files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10982/files - new: https://git.openjdk.org/jdk/pull/10982/files/4b3e63d5..3827e529 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10982&range=00-01 Stats: 35 lines in 5 files changed: 1 ins; 3 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/10982.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10982/head:pull/10982 PR: https://git.openjdk.org/jdk/pull/10982 From asotona at openjdk.org Mon Nov 28 14:46:41 2022 From: asotona at openjdk.org (Adam Sotona) Date: Mon, 28 Nov 2022 14:46:41 GMT Subject: RFR: [DRAFT] 8294982: Implementation of Classfile API [v2] In-Reply-To: References: Message-ID: <9DkX_WiKaon_oKZKOiZdkuUnsadGzwY7EGBsI4lh7k4=.c24e15ab-0490-441d-8e7b-41025be907b9@github.com> On Sun, 27 Nov 2022 01:38:01 GMT, Erik Gahlin wrote: >> Is the practice of naming the directory `snippets` well-established or mandated? Otherwise I think a name like `snippet-files` (akin to `doc-files`) would be much better, since it indicates that is not a java package name. (These do not usually include `-`; I am unsure if this is prohibited by the specification, or just not used by convention.) >> >> In fact, when checking, I see that there is already a handful of `snippet-files`: >> >> ./jdk.jfr/share/classes/jdk/jfr/snippet-files >> ./jdk.jfr/share/classes/jdk/jfr/consumer/snippet-files >> ./java.compiler/share/classes/javax/tools/snippet-files >> >> >> So maybe rename it to `snippet-files`, and I'll look into making exclusion of `snippet-files` be done automatically. > > It would be nice to get the directory excluded (from packaging) by default. I used the snippet-files name since it was mentioned in the JEP https://openjdk.org/jeps/413 Snippets moved from `jdk/classfile/snippets` to `jdk/classfile/snippet-files` and explicit exclusion of `jdk/classfile/snippet-files` will be removed when excluded from compilation by default. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10982 From mcimadamore at openjdk.org Mon Nov 28 15:00:32 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 28 Nov 2022 15:00:32 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v16] In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 12:05:31 GMT, Alan Bateman wrote: >> The reason for the comment is to make it clear why `DirectBuffer::address` can be used directly without guarding. This will also reduce the probability of unnecessary guarding being added in the future. However, if the consensus is that these comments just adds confusion, I am happy to remove them. > > I'd prefer to see this comment removed from all places that are obviously interacting with the direct buffer cache. These usages are try-finally to acquire and return the temporary direct buffer cache back to the cache. Talking about closable sessions here is definitely confusing. > Thanks for persisting with it, latest version looks okay to me and the naming issue can be sorted out after the JEP is integrated. IMHO the renaming is not super important - the underlying abstraction managing the segment lifetime is still called MemorySession, even after https://git.openjdk.org/jdk/pull/10872. And, acquire/release are methods on MemorySession - so I think the current name might be more precise even after we integrate the latest API changes. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From duke at openjdk.org Mon Nov 28 15:27:15 2022 From: duke at openjdk.org (duke) Date: Mon, 28 Nov 2022 15:27:15 GMT Subject: Withdrawn: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: <34um0oOZCtdh8b-xckxmi96IEO_zSklavBH96B2WmhQ=.e83685bf-8f28-4966-aecc-a8ec0b369bfe@github.com> On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi wrote: > OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. > |Charset|Mix|SBCS|DBCS| > | -- | -- | -- | -- | > | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | > | Korean | Cp933 | Cp833 | Cp834 | > > But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. > > I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency > |Charset|Mix|SBCS|DBCS| > | ------------- | ------------- | ------------- | ------------- | > | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | > | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | > | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | > > *1: Cp037 compatible This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/9399 From pminborg at openjdk.org Mon Nov 28 16:44:47 2022 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 28 Nov 2022 16:44:47 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v31] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 17:33:06 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues Looks good on API level. ------------- Marked as reviewed by pminborg (no project role). PR: https://git.openjdk.org/jdk/pull/10872 From duke at openjdk.org Mon Nov 28 17:20:10 2022 From: duke at openjdk.org (Weibing Xiao) Date: Mon, 28 Nov 2022 17:20:10 GMT Subject: RFR: 8297528: java/io/File/TempDirDoesNotExist.java test failing on windows-x64 Message-ID: fix the illegal characters of directory names in Windows ------------- Commit messages: - fix illegal charater of directory name in Windows Changes: https://git.openjdk.org/jdk/pull/11393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297528 Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11393.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11393/head:pull/11393 PR: https://git.openjdk.org/jdk/pull/11393 From rriggs at openjdk.org Mon Nov 28 17:29:57 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 28 Nov 2022 17:29:57 GMT Subject: RFR: 8297528: java/io/File/TempDirDoesNotExist.java test failing on windows-x64 In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 16:52:09 GMT, Weibing Xiao wrote: > fix the illegal characters of directory names in Windows LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11393 From jjg at openjdk.org Mon Nov 28 17:31:40 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Mon, 28 Nov 2022 17:31:40 GMT Subject: RFR: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools [v3] In-Reply-To: References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> Message-ID: On Wed, 23 Nov 2022 15:59:42 GMT, Christian Stein wrote: >> This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: >> - `jdk.jartool` >> - `jdk.jlink` >> - `jdk.jpackage` >> >> Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. >> >> - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". >> - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". >> - [x] Remove `CommandLine.java` from `jdk.jartool` module >> - [x] Remove `CommandLine.java` from `jdk.jlink` module >> - [x] Remove `CommandLine.java` from `jdk.jpackage` module >> - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Remove entire "scary warning" paragraph Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11272 From cstein at openjdk.org Mon Nov 28 17:37:38 2022 From: cstein at openjdk.org (Christian Stein) Date: Mon, 28 Nov 2022 17:37:38 GMT Subject: Integrated: 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools In-Reply-To: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> References: <00fqWUpCBTTHJ9rhGoBczNZSMlRR0z5LVEtOXx_umuE=.3844324d-8128-4561-bc03-0b2a5750b1c3@github.com> Message-ID: <_jaH15voFPIFFZjhJQxCQkfWaRmmDfixLhKiSMGiEjs=.6662aab3-6aae-49f0-b24c-11b78a7cf3d1@github.com> On Mon, 21 Nov 2022 15:40:19 GMT, Christian Stein wrote: > This PR copies the `CommandLine.java` file from module `jdk.compiler` (package `com.sun.tools.javac.main`) into the `jdk.internal.opt` module, creating a new package with name `jdk.internal.opt`. That new `jdk.internal.opt` package is then exported to the following modules: > - `jdk.jartool` > - `jdk.jlink` > - `jdk.jpackage` > > Now, `jar`, `jlink`, and `jpackage` use a shared `CommandLine` class. In a future commit (presumable for JDK 21) the original `CommandLine.java` file in `jdk.compiler` can and will be replaced with this new one in `jdk.internal.opt`. Same goes for the `jdk.javadoc` module. > > - [x] Keep `CommandLine.java` in `jdk.compiler` module for the time being due to "JDK N-1 rule". > - [x] Keep `CommandLine.java` in `jdk.javadoc` module for the time being due to "JDK N-1 rule". > - [x] Remove `CommandLine.java` from `jdk.jartool` module > - [x] Remove `CommandLine.java` from `jdk.jlink` module > - [x] Remove `CommandLine.java` from `jdk.jpackage` module > - [x] Check for related but renamed(?) usages of `CommandLine.java` in other JDK tools: `jshell`, `jdeps`, `jfr`, ... This pull request has now been integrated. Changeset: a80552e1 Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/a80552e1e15fba42e0e647248a3d50fa44c5bf53 Stats: 519 lines in 10 files changed: 35 ins; 477 del; 7 mod 8236919: Refactor com.sun.tools.javac.main.CommandLine into a reusable module for other JDK tools Reviewed-by: jjg ------------- PR: https://git.openjdk.org/jdk/pull/11272 From iris at openjdk.org Mon Nov 28 17:45:44 2022 From: iris at openjdk.org (Iris Clark) Date: Mon, 28 Nov 2022 17:45:44 GMT Subject: RFR: 8297528: java/io/File/TempDirDoesNotExist.java test failing on windows-x64 In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 16:52:09 GMT, Weibing Xiao wrote: > fix the illegal characters of directory names in Windows Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11393 From bhuang at openjdk.org Mon Nov 28 17:57:28 2022 From: bhuang at openjdk.org (Bill Huang) Date: Mon, 28 Nov 2022 17:57:28 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v4] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 13:56:29 GMT, Alan Bateman wrote: >> Bill Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> Implemented review comments. > > test/jdk/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java line 167: > >> 165: Set.copyOf(Arrays.asList(InetAddress.getAllByName(myHostName))); >> 166: Set hostAddrs = >> 167: Set.copyOf(Arrays.asList(InetAddress.getAllByName(host))); > > Is there a reason to change this from Set.of? This is a workaround for duplicate elements detected by Set.of(). On my localhost, InetAddress.getAllByName(localhost returns duplicate IPv6 addresses with different scoped id which is not counted during comparison. This change shouldn't impact the goal of these tests which is to verify that registry modification request from client side is prohibited. ------------- PR: https://git.openjdk.org/jdk/pull/10825 From psandoz at openjdk.org Mon Nov 28 18:01:42 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 28 Nov 2022 18:01:42 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v25] In-Reply-To: References: <9ZhPphzsMfl1vMcmbOjnzXi1THKCagn-RIE5TAE3a0M=.0e019155-9ea9-4e6c-ab03-a38cf7a7de33@github.com> Message-ID: On Thu, 24 Nov 2022 09:27:04 GMT, Andrew Haley wrote: >> src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 209: >> >>> 207: final int bitmask; >>> 208: >>> 209: private static final Object NIL = new Object(); >> >> Suggestion: >> >> static final Object NO_VALUE = new Object(); > > It not very important, but I'm going to push back (very gently) on this one. "nil: noun. nothing; naught; zero. adjective. having no value or existence." That is the exact literal meaning of this sentinel. Also, "nil" has been used with this meaning in programming languages for 60 years. What is your objection to it here? I agree its not very important, please feel free to ignore my suggestion. My thinking was to prefer something more explicit in the code when reading, since i felt the use of the term nil was more idiomatic in other languages than Java. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From bpb at openjdk.org Mon Nov 28 18:05:21 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 28 Nov 2022 18:05:21 GMT Subject: RFR: 8297528: java/io/File/TempDirDoesNotExist.java test failing on windows-x64 In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 16:52:09 GMT, Weibing Xiao wrote: > fix the illegal characters of directory names in Windows Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11393 From duke at openjdk.org Mon Nov 28 18:18:42 2022 From: duke at openjdk.org (Justin Lu) Date: Mon, 28 Nov 2022 18:18:42 GMT Subject: RFR: 8297685: Typo in NullPointerException description specified by Locale.lookup Message-ID: Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563. Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `. ------------- Commit messages: - Replace tags with locales in javadoc for locale.lookup Changes: https://git.openjdk.org/jdk/pull/11394/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11394&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297685 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11394.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11394/head:pull/11394 PR: https://git.openjdk.org/jdk/pull/11394 From naoto at openjdk.org Mon Nov 28 18:18:43 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 28 Nov 2022 18:18:43 GMT Subject: RFR: 8297685: Typo in NullPointerException description specified by Locale.lookup In-Reply-To: References: Message-ID: <_KpUO_-ffGZT7Zt7h9ZX7OkRTFMEgdfKVtmmamBWZKs=.a48b0986-91e6-4f42-844a-47d1bbc09d7a@github.com> On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu wrote: > Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563. > > Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11394 From lancea at openjdk.org Mon Nov 28 18:26:30 2022 From: lancea at openjdk.org (Lance Andersen) Date: Mon, 28 Nov 2022 18:26:30 GMT Subject: RFR: 8297685: Typo in NullPointerException description specified by Locale.lookup In-Reply-To: References: Message-ID: <_yaHUaHxnux0bhwgUrx4p6wg4zFg-Y11tpkooUtoMhM=.bcff4549-f25d-45b2-944b-1026ce3fac12@github.com> On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu wrote: > Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563. > > Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11394 From psandoz at openjdk.org Mon Nov 28 18:30:46 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 28 Nov 2022 18:30:46 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v31] In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 17:33:06 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues Marked as reviewed by psandoz (Reviewer). src/java.base/share/classes/jdk/internal/foreign/FunctionDescriptorImpl.java line 57: > 55: * {@return the return layout (if any) associated with this function descriptor} > 56: */ > 57: public final Optional returnLayout() { No need for `final` since class is final. Suggestion: public Optional returnLayout() { src/java.base/share/classes/jdk/internal/foreign/SlicingAllocator.java line 33: > 31: public final class SlicingAllocator implements SegmentAllocator { > 32: > 33: public static final long DEFAULT_BLOCK_SIZE = 4 * 1024; Not used. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Mon Nov 28 18:38:24 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 28 Nov 2022 18:38:24 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v4] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 17:54:51 GMT, Bill Huang wrote: >> test/jdk/javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java line 167: >> >>> 165: Set.copyOf(Arrays.asList(InetAddress.getAllByName(myHostName))); >>> 166: Set hostAddrs = >>> 167: Set.copyOf(Arrays.asList(InetAddress.getAllByName(host))); >> >> Is there a reason to change this from Set.of? > > This is a workaround for duplicate elements detected by Set.of(). On my localhost, InetAddress.getAllByName(localhost returns duplicate IPv6 addresses with different scoped id which is not counted during comparison. This change shouldn't impact the goal of these tests which is to verify that registry modification request from client side is prohibited. Thanks. You might want to add a comment to avoid drive-by suggestions to simplify it. ------------- PR: https://git.openjdk.org/jdk/pull/10825 From naoto at openjdk.org Mon Nov 28 18:46:30 2022 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 28 Nov 2022 18:46:30 GMT Subject: RFR: 8297528: java/io/File/TempDirDoesNotExist.java test failing on windows-x64 In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 16:52:09 GMT, Weibing Xiao wrote: > fix the illegal characters of directory names in Windows Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11393 From joe.darcy at oracle.com Mon Nov 28 18:48:23 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 28 Nov 2022 10:48:23 -0800 Subject: Redundant condition in java.math.MutableBigInteger#divideMagnitude In-Reply-To: References: Message-ID: Filed https://bugs.openjdk.org/browse/JDK-8297731. Thanks, -Joe On 11/28/2022 4:35 AM, Raffaello Giulietti wrote: > > I can confirm that testing that condition is indeed useless > > *From: *core-libs-dev on behalf of > Andrey Turbanov > *Date: *Friday, 2022-November-25 at 14:18 > *To: *core-libs-dev > *Subject: *Redundant condition in > java.math.MutableBigInteger#divideMagnitude > > Hello. > I noticed that IntelliJ IDEA show warning in the method > java.math.MutableBigInteger#divideMagnitude > here - > https://github.com/openjdk/jdk/blob/4f65570204e2d38415e7761bd81660b081eae882/src/java.base/share/classes/java/math/MutableBigInteger.java#L1536 > It seems that condition is always 'true' > > ?? if (rem.intLen == nlen) { > > 'rem' and 'nlen' variables are not changed anyhow after this > assignment a few lines above: > > ??? int nlen = rem.intLen; > > To make sure that it's really true, I've modified source to include > else branch: > > } else { > ??? throw new AssertionError("Condition 'rem.intLen == nlen' wasn't > met."); > } > > And all tests from "jdk/java/math" passed. > > > Can we clean up the code to remove this condition? Code is already > complex enough and each condition makes its reading harder. > It was added as part of performance improvements in > https://bugs.openjdk.org/browse/JDK-7082971 > > > Andrey Turbanov > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Mon Nov 28 19:06:31 2022 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 28 Nov 2022 19:06:31 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide Message-ID: Remove redundant code reported in https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html ------------- Commit messages: - JDK-8297731: Remove redundant check in MutableBigInteger.divide Changes: https://git.openjdk.org/jdk/pull/11395/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11395&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297731 Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11395/head:pull/11395 PR: https://git.openjdk.org/jdk/pull/11395 From bpb at openjdk.org Mon Nov 28 19:10:10 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 28 Nov 2022 19:10:10 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 18:58:29 GMT, Joe Darcy wrote: > Remove redundant code reported in > > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11395 From mcimadamore at openjdk.org Mon Nov 28 19:29:08 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 28 Nov 2022 19:29:08 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v32] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/97168155..6699ad99 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=30-31 Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From psandoz at openjdk.org Mon Nov 28 19:39:58 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 28 Nov 2022 19:39:58 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v16] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 10:47:47 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Re-introduce yet another address vairable The approach looks good, and almost the least intrusive (see comment). src/java.base/share/classes/java/nio/Buffer.java line 838: > 836: > 837: @Override > 838: public void releaseSession(Buffer buffer, MemorySessionImpl scope) { I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.org/jdk/pull/11260 From serb at openjdk.org Mon Nov 28 19:52:41 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 28 Nov 2022 19:52:41 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 18:58:29 GMT, Joe Darcy wrote: > Remove redundant code reported in > > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html src/java.base/share/classes/java/math/MutableBigInteger.java line 1536: > 1534: > 1535: // Must insert leading 0 in rem if its length did not change > 1536: if (rem.intLen == nlen) { Looks like after this change the local nlen variable is used only once, and probably can be removed? ------------- PR: https://git.openjdk.org/jdk/pull/11395 From serb at openjdk.org Mon Nov 28 19:58:43 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 28 Nov 2022 19:58:43 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 19:49:55 GMT, Sergey Bylokhov wrote: >> Remove redundant code reported in >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html > > src/java.base/share/classes/java/math/MutableBigInteger.java line 1536: > >> 1534: >> 1535: // Must insert leading 0 in rem if its length did not change >> 1536: if (rem.intLen == nlen) { > > Looks like after this change the local nlen variable is used only once, and probably can be removed? BTW the "rem.leftShift(shift);" above may change the "rem.intLen" value, no? ------------- PR: https://git.openjdk.org/jdk/pull/11395 From serb at openjdk.org Mon Nov 28 20:08:00 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 28 Nov 2022 20:08:00 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 19:56:23 GMT, Sergey Bylokhov wrote: >> src/java.base/share/classes/java/math/MutableBigInteger.java line 1536: >> >>> 1534: >>> 1535: // Must insert leading 0 in rem if its length did not change >>> 1536: if (rem.intLen == nlen) { >> >> Looks like after this change the local nlen variable is used only once, and probably can be removed? > > BTW the "rem.leftShift(shift);" above may change the "rem.intLen" value, no? Sorry I have looked into the different method=), -> divideLongMagnitude. ------------- PR: https://git.openjdk.org/jdk/pull/11395 From duke at openjdk.org Mon Nov 28 21:39:27 2022 From: duke at openjdk.org (Weibing Xiao) Date: Mon, 28 Nov 2022 21:39:27 GMT Subject: Integrated: 8297528: java/io/File/TempDirDoesNotExist.java test failing on windows-x64 In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 16:52:09 GMT, Weibing Xiao wrote: > fix the illegal characters of directory names in Windows This pull request has now been integrated. Changeset: cdf9ed07 Author: Weibing Xiao Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/cdf9ed07de102ae388278163e3bf702d861fc30a Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod 8297528: java/io/File/TempDirDoesNotExist.java test failing on windows-x64 Reviewed-by: rriggs, iris, bpb, naoto ------------- PR: https://git.openjdk.org/jdk/pull/11393 From smarks at openjdk.org Mon Nov 28 21:57:51 2022 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 28 Nov 2022 21:57:51 GMT Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 18:54:28 GMT, Alan Bateman wrote: > Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup. > > java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified . > > The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. > > A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method. > > It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11373 From smarks at openjdk.org Mon Nov 28 21:57:53 2022 From: smarks at openjdk.org (Stuart Marks) Date: Mon, 28 Nov 2022 21:57:53 GMT Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension In-Reply-To: References: Message-ID: <9I_fhcX74uidks9GdmGIku5KUeCwair18blGci2XOBk=.90e2025f-a27b-41bd-9d04-97001d636aff@github.com> On Mon, 28 Nov 2022 13:13:09 GMT, Jaikiran Pai wrote: >> Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup. >> >> java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified . >> >> The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. >> >> A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method. >> >> It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. > >> Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. > > I guess, this would then mean this PR will be integrated into mainline after 8th December when the branch for JDK 20 will be forked https://openjdk.org/projects/jdk/20/#Schedule? @jaikiran wrote: > I guess, this would then mean this PR will be integrated into mainline after 8th December when the branch for JDK 20 will be forked Yes, I'm sure this will go in soon after the JDK 20 fork. ------------- PR: https://git.openjdk.org/jdk/pull/11373 From rriggs at openjdk.org Mon Nov 28 23:05:54 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 28 Nov 2022 23:05:54 GMT Subject: RFR: 8297271: AccessFlags should be specific to class file version Message-ID: The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field assume the access flags are from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits. The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version: ------------- Commit messages: - 8297271: AccessFlags should be specific to class file version Changes: https://git.openjdk.org/jdk/pull/11399/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11399&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297271 Stats: 206 lines in 9 files changed: 198 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11399.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11399/head:pull/11399 PR: https://git.openjdk.org/jdk/pull/11399 From prr at openjdk.org Mon Nov 28 23:27:55 2022 From: prr at openjdk.org (Phil Race) Date: Mon, 28 Nov 2022 23:27:55 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: > > Remove updates from unexported files src/java.desktop/share/classes/java/awt/package-info.java line 58: > 56: *

    • The AWT Modality > 57: *
    • > 58: * The Java AWT Native Interface (JAWT) Why only 1 of these 3 ? src/java.desktop/share/classes/java/awt/package-info.java line 62: > 60: * > 61: * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide > 62: * @since 1.0 I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ? But I also wonder why only the native_interface spec was added and not the other two ? src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226: > 224: * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 > 225: * @see #TAG_COMPRESSION > 226: * @see DEFLATE specification Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ? ------------- PR: https://git.openjdk.org/jdk/pull/11073 From bhuang at openjdk.org Tue Nov 29 00:55:08 2022 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 29 Nov 2022 00:55:08 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v5] In-Reply-To: References: Message-ID: > The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. > > Tests include: > java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java > java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java > javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Implemented review comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10825/files - new: https://git.openjdk.org/jdk/pull/10825/files/278564b3..cff3773c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=03-04 Stats: 9 lines in 3 files changed: 5 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10825.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825 PR: https://git.openjdk.org/jdk/pull/10825 From bpb at openjdk.org Tue Nov 29 01:05:44 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 01:05:44 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE Message-ID: `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. ------------- Commit messages: - 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE Changes: https://git.openjdk.org/jdk/pull/11403/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297632 Stats: 23 lines in 1 file changed: 22 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403 PR: https://git.openjdk.org/jdk/pull/11403 From bhuang at openjdk.org Tue Nov 29 01:06:49 2022 From: bhuang at openjdk.org (Bill Huang) Date: Tue, 29 Nov 2022 01:06:49 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v6] In-Reply-To: References: Message-ID: > The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. > > Tests include: > java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java > java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java > javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Bill Huang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge master - Implemented review comments. - Implemented review comments. - Reverted exclusion of nonlocal registry tests. - Updated test instruction messages. - Updated TEST.groups - JDK-8295756 Improve NonLocalRegistry Manual Test Process ------------- Changes: https://git.openjdk.org/jdk/pull/10825/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=05 Stats: 350 lines in 7 files changed: 256 ins; 58 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/10825.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825 PR: https://git.openjdk.org/jdk/pull/10825 From itakiguchi at openjdk.org Tue Nov 29 01:35:27 2022 From: itakiguchi at openjdk.org (Ichiroh Takiguchi) Date: Tue, 29 Nov 2022 01:35:27 GMT Subject: RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets In-Reply-To: References: Message-ID: On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi wrote: > OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets. > |Charset|Mix|SBCS|DBCS| > | -- | -- | -- | -- | > | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 | > | Korean | Cp933 | Cp833 | Cp834 | > > But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets. > > I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency > |Charset|Mix|SBCS|DBCS| > | ------------- | ------------- | ------------- | ------------- | > | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 | > | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** | > | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | > > *1: Cp037 compatible I'm still working on this one. ------------- PR: https://git.openjdk.org/jdk/pull/9399 From darcy at openjdk.org Tue Nov 29 02:42:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 02:42:21 GMT Subject: RFR: 8297271: AccessFlags should be specific to class file version In-Reply-To: References: Message-ID: <5ADOFh1C_r2IlV1prDPgx2lcALXokCoIKzJ_IQyb7iI=.d37711d7-45f6-46b8-8037-e8ba04938aed@github.com> On Mon, 28 Nov 2022 22:56:27 GMT, Roger Riggs wrote: > The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field assume the access flags are from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits. Hmm. I don't agree with that characterization of the current situation. The AccessFlag class has a method that takes a ClassFileFormatVersion argument and there are regression tests of the AccessFlag feature that user downrev versions of class file to exercise all the functionality: https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/reflect/AccessFlag/StrictAccessFlagTest.java It is more accurate to say that the class file version is an *implicit* argument to all the give-me-the-access-flags functionality. > The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version: The current implementation does rely on the JVM "doing the right thing"(TM) in terms of screening out access_flags bits that are not appropriate for the class file version. However, I don't think this needs to be underlined, necessarily. Perhaps a sealed interface, strawman name AccessFlags, stated such a requirement for the core reflection classes? ------------- PR: https://git.openjdk.org/jdk/pull/11399 From darcy at openjdk.org Tue Nov 29 04:21:14 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 04:21:14 GMT Subject: RFR: JDK-8296149: Start of release updates for JDK 21 Message-ID: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21. ------------- Commit messages: - Fix failed HotSpot regression tests. - Merge branch 'master' into JDK-8296149 - Update symbol information to JDK 20 build 24. - Merge branch 'master' into JDK-8296149 - Merge branch 'master' into JDK-8296149 - Update symbols for JDK 20 b23. - Merge branch 'master' into JDK-8296149 - Merge branch 'master' into JDK-8296149 - Update symbols for JDK 20 build 22. - Update expected GA date. - ... and 1 more: https://git.openjdk.org/jdk/compare/105d9d75...5810345e Changes: https://git.openjdk.org/jdk/pull/10924/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10924&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296149 Stats: 3653 lines in 69 files changed: 3608 ins; 1 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/10924.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10924/head:pull/10924 PR: https://git.openjdk.org/jdk/pull/10924 From darcy at openjdk.org Tue Nov 29 04:21:14 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 04:21:14 GMT Subject: RFR: JDK-8296149: Start of release updates for JDK 21 In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> Message-ID: On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy wrote: > Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21. Flipping the draft-bit off for this PR ahead of the upcoming start of JDK 21. Symbol information now up-to-date as of JDK 20 b25. ------------- PR: https://git.openjdk.org/jdk/pull/10924 From dholmes at openjdk.org Tue Nov 29 04:52:28 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 29 Nov 2022 04:52:28 GMT Subject: RFR: JDK-8296149: Start of release updates for JDK 21 In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> Message-ID: <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com> On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy wrote: > Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21. I looked at everything bar the sym files. All seems fine/usual. One query below (probably one I ask each release). Thanks. src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java line 47: > 45: * @since 14 > 46: */ > 47: @SupportedSourceVersion(RELEASE_21) It is a pity these have to be updated each release. Is there no way to say `latest` here? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/10924 From darcy at openjdk.org Tue Nov 29 05:15:25 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 05:15:25 GMT Subject: RFR: JDK-8296149: Start of release updates for JDK 21 In-Reply-To: <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com> References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> <0KXjUacMHUpCfdwzClgnvCzB9iOtpr6xk10wBaVuucs=.0395129f-9740-4e6c-bce5-338569ee2d09@github.com> Message-ID: On Tue, 29 Nov 2022 04:45:57 GMT, David Holmes wrote: >> Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21. > > src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java line 47: > >> 45: * @since 14 >> 46: */ >> 47: @SupportedSourceVersion(RELEASE_21) > > It is a pity these have to be updated each release. Is there no way to say `latest` here? Not with the current language specification, no. The only enum value "constant-enough" to use in an annotation is the name of an enum constant, a public static final field assigned an enum value is not enough. On the flip side, I make the updates to these annotations using a one-line sed script I have saved away in a comment on one of the previous start-of-release-updates-for-JDK-N bugs. Using the annotations in this way is in lieu of adding another type specification for the JDK version. In other words, having AbstractAnnotationValueVisitor**14**.java with an annotation indicating RELEASE_21 prevents having AbstractAnnotationValueVisitor15, AbstractAnnotationValueVisitor16, ... , AbstractAnnotationValueVisitor21. New visitors are now only introduced when adding new kinds of structures requires differences in behavior. Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/10924 From jpai at openjdk.org Tue Nov 29 06:03:33 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 29 Nov 2022 06:03:33 GMT Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory [v2] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev wrote: >> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s >> ... >> >> $ ls >> Apan.class >> ``` >> >> Additional testing: >> - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8296645-javac-bench-class-files > - Fix indenting > - Fix Looks fine to me. The copyright year will need an update. ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11055 From jpai at openjdk.org Tue Nov 29 06:46:23 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 29 Nov 2022 06:46:23 GMT Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 In-Reply-To: References: Message-ID: <-DfzsuUNyPwbFCsUByDKFoKuJW_de4WV8FjzxrHUfPo=.f1346117-a1ac-4780-9065-40cdf18064e3@github.com> On Wed, 23 Nov 2022 12:40:05 GMT, Alan Bateman wrote: > The proposed updates for JDK 20 are: > > - ForkJoinPool.externalSubmit > - ForkJoinWorkerThread.getQueuedTaskCount > > These methods will be used to improve the Thread.yield implementation for virtual threads. The range of alternatives explored include not exposing an API and protected methods such as "offerSubmission". The class description speaks of "external clients" and "submissions from non-ForkJoinTask clients", hence the proposed naming and javadoc text. I don't have enough knowledge of this area, but the API changes look OK to me. With this addition of the `externalSubmit` method should the javadoc of the existing `submit` method be enhanced a bit to explain how it behaves differently as compared to this one and when to choose one over the other. For example, should `submit` API state (its already existing behaviour) that it will use the current worker thread's queue to push this new task if called from the worker thread? ------------- PR: https://git.openjdk.org/jdk/pull/11319 From jpai at openjdk.org Tue Nov 29 06:52:18 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 29 Nov 2022 06:52:18 GMT Subject: RFR: 8297495: j.u.concurrent updates for JDK 20 In-Reply-To: References: Message-ID: On Wed, 23 Nov 2022 12:40:05 GMT, Alan Bateman wrote: > The proposed updates for JDK 20 are: > > - ForkJoinPool.externalSubmit > - ForkJoinWorkerThread.getQueuedTaskCount > > These methods will be used to improve the Thread.yield implementation for virtual threads. The range of alternatives explored include not exposing an API and protected methods such as "offerSubmission". The class description speaks of "external clients" and "submissions from non-ForkJoinTask clients", hence the proposed naming and javadoc text. test/jdk/java/util/concurrent/tck/ForkJoinPool20Test.java line 48: > 46: * Tests for ForkJoinPool and ForkJoinWorkerThread additions in JDK 20. > 47: */ > 48: public class ForkJoinPool20Test extends JSR166TestCase { The new `externalSubmit` API states: > @implSpec > This method is equivalent to {@link #submit(ForkJoinTask)} when called > from a thread that is not in this pool. Should this new test class include a test which verifies this behaviour? As far as I can see, the new test methods that assert the queue counts are being invoked from within a worker thread. ------------- PR: https://git.openjdk.org/jdk/pull/11319 From jpai at openjdk.org Tue Nov 29 07:01:05 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 29 Nov 2022 07:01:05 GMT Subject: RFR: 8297685: Typo in NullPointerException description specified by Locale.lookup In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu wrote: > Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563. > > Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `. Looks good to me. P.S: There appears to be another PR open for this same change https://github.com/openjdk/jdk/pull/11378 ------------- Marked as reviewed by jpai (Reviewer). PR: https://git.openjdk.org/jdk/pull/11394 From iris at openjdk.org Tue Nov 29 07:29:53 2022 From: iris at openjdk.org (Iris Clark) Date: Tue, 29 Nov 2022 07:29:53 GMT Subject: RFR: JDK-8296149: Start of release updates for JDK 21 In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> Message-ID: <3XmL-mIaH-juXigTJOSqPUWTLRwlBBvpYhpjQRLKofk=.e05f97cb-2ed6-468f-8184-07a0935c9645@github.com> On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy wrote: > Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10924 From aturbanov at openjdk.org Tue Nov 29 07:42:26 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 29 Nov 2022 07:42:26 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 18:58:29 GMT, Joe Darcy wrote: > Remove redundant code reported in > > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html IDEA now highlights unnecessary `rem.offset=1` assignments, which are above modified code. Now we always overwrite it with `0` anyway. https://github.com/openjdk/jdk/blob/6f06f440bcf8a5db379b80e8765af38a15449356/src/java.base/share/classes/java/math/MutableBigInteger.java#L1498 https://github.com/openjdk/jdk/blob/6f06f440bcf8a5db379b80e8765af38a15449356/src/java.base/share/classes/java/math/MutableBigInteger.java#L1504 https://github.com/openjdk/jdk/blob/6f06f440bcf8a5db379b80e8765af38a15449356/src/java.base/share/classes/java/math/MutableBigInteger.java#L1520 Perhaps we can drop them too. ------------- PR: https://git.openjdk.org/jdk/pull/11395 From pminborg at openjdk.org Tue Nov 29 07:57:23 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 29 Nov 2022 07:57:23 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v16] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 19:35:24 GMT, Paul Sandoz wrote: > I prefer methods that do not expose the scope implementation so access is limited to just to the acquire/release methods, but i am unsure of the performance implications. These methods might not reliably inline, and we may need to ensure that first (which is also separately a good thing). I think it requires that the shared secret fields are stable and that there is only one implementation of `JavaNioAccess`, which there is, but we can enforce via sealing. Something to consider as a further iteration. I agree. A similar approach was done in a previous incarnation of the PR whereby we exposed a `ScopeAcqusition` that held an internal copy of the buffer and provided means to release. We feared that would cause performance regression. But your comment made me think of another way of doing acquire/release which would not expose the session and that would always be performant. I will explore this idea a bit more. ------------- PR: https://git.openjdk.org/jdk/pull/11260 From alanb at openjdk.org Tue Nov 29 08:32:20 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Nov 2022 08:32:20 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 00:56:58 GMT, Brian Burkhalter wrote: > `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. InputStream.transferTo is specified to transfer "all bytes from this input stream" so changing it to do a "short write" is major change and also creates a big inconsistency with java.io methods such as OutputStream.write that write all bytes. I think other options will need to be explored. We have this same issue in other APIs where they specify that they return Long.MAX_VALUE when the size is larger. It is likely that some of the overrides will need attention too. ------------- Changes requested by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11403 From pminborg at openjdk.org Tue Nov 29 09:40:58 2022 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 29 Nov 2022 09:40:58 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v17] In-Reply-To: References: Message-ID: > This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. > > Design choices in this PR: > > There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. > > The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ > > In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ > > On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". > > I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. > > This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Remove session exposure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11260/files - new: https://git.openjdk.org/jdk/pull/11260/files/eedf41ae..619473ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11260&range=15-16 Stats: 125 lines in 20 files changed: 11 ins; 13 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/11260.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11260/head:pull/11260 PR: https://git.openjdk.org/jdk/pull/11260 From mcimadamore at openjdk.org Tue Nov 29 10:19:48 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 29 Nov 2022 10:19:48 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v17] In-Reply-To: References: Message-ID: <8HV7vdX-QrKG_OhlGWLwAG2uLsT8sKIbIqAce65bNWU=.68ffecbe-2065-418c-a0a5-1f0d04964717@github.com> On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove session exposure This looks more symmetric, I like it. Since `acquire` was only really returning null if the underlying buffer had no associated session, I believe this rewriting preserves the semantics we had before (e.g. no accidental double releases). ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/11260 From daniel.fuchs at oracle.com Tue Nov 29 11:03:04 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 29 Nov 2022 11:03:04 +0000 Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net> Message-ID: <65e42b26-6f83-b3a7-5247-7feb78b9e006@oracle.com> We hear you Mike :-) I have logged https://bugs.openjdk.org/browse/JDK-8297755 to update the links in java.net / java.net.http API documentation. best regards, -- daniel On 29/11/2022 03:14, Michael StJohns wrote: > Hi - > > I need to repeat again.? Please avoid using www.ietf.org as the URL base > for referencing RFCs.? The appropriate location is www.rfc-editor.org > and is going to be more stable in the long run than any reference to an > RFC that runs through the IETF's website.? These two websites have > different purposes, and the structure of the IETF website has changed at > least once recently and may change again relatively (~5 years) soon. > > The most general and correct form for referencing RFCs is > "https://www.rfc-editor.org/info/rfc"? That will get you to the > front page with pointers to all of the current semi-canonical versions > of the spec (e.g. text, pdf-a, html, and xml). > > Mike From shade at openjdk.org Tue Nov 29 11:08:51 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 29 Nov 2022 11:08:51 GMT Subject: RFR: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory [v2] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 13:53:23 GMT, Aleksey Shipilev wrote: >> $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s >> ... >> >> $ ls >> Apan.class >> ``` >> >> Additional testing: >> - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8296645-javac-bench-class-files > - Fix indenting > - Fix Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11055 From shade at openjdk.org Tue Nov 29 11:12:14 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 29 Nov 2022 11:12:14 GMT Subject: Integrated: 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 09:00:14 GMT, Aleksey Shipilev wrote: > $ java -jar ../build/linux-x86_64-server-release/images/test/micro/benchmarks.jar org.openjdk.bench.javax.tools.Javac.testCompile -f 1 -r 1s -w 1s > ... > > $ ls > Apan.class > ``` > > Additional testing: > - [x] Eyeballing CWD and `/tmp` contents after the benchmark -- no leftovers This pull request has now been integrated. Changeset: bd51b7ea Author: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/bd51b7ea43b210ea07399b09d61c366594ac2cfd Stats: 24 lines in 1 file changed: 23 ins; 0 del; 1 mod 8296645: org.openjdk.bench.javax.tools.Javac leaves class files in current directory Reviewed-by: redestad, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11055 From aph at openjdk.org Tue Nov 29 11:51:39 2022 From: aph at openjdk.org (Andrew Haley) Date: Tue, 29 Nov 2022 11:51:39 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v33] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Unused variable src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 385: > 383: try { > 384: JLA.setScopedValueBindings(newSnapshot); > 385: JLA.ensureMaterializedForStackWalk(newSnapshot); Question: is it necessary here to invoke `ensureMaterializedForStackWalk()` It's really only there to prevent the new `Snapshot` from being scalar replaced. But we know that it cannot be scalar replaced, because it really does escape: a pointer to it is stored in the current `Thread`. So should we simply remove the call to `ensureMaterializedForStackWalk()`, on the grounds that it cannot have any effect? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From chegar at openjdk.org Tue Nov 29 12:05:30 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 29 Nov 2022 12:05:30 GMT Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 18:54:28 GMT, Alan Bateman wrote: > Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup. > > java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified . > > The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. > > A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method. > > It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/11373 From erikj at openjdk.org Tue Nov 29 13:45:40 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 29 Nov 2022 13:45:40 GMT Subject: RFR: JDK-8296149: Start of release updates for JDK 21 In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> Message-ID: On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy wrote: > Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21. Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10924 From jvernee at openjdk.org Tue Nov 29 13:52:11 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 29 Nov 2022 13:52:11 GMT Subject: RFR: 8297736: test/jdk/java/foreign/TestMatrix.java is broken Message-ID: - Fix tests that try to run `TestDowncall` which was split into TestDowncallScope and TestDowncallStack - Fix use of obsolete system properties to control specilization - Add test to run TestVarArgs in un-sampled mode. Testing: Manual runs of TestMatrix.java (it's a manual test) on Windows and Linux (WSL). ------------- Commit messages: - Fix TestMatrix Changes: https://git.openjdk.org/jdk/pull/11398/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11398&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297736 Stats: 74 lines in 1 file changed: 33 ins; 0 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/11398.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11398/head:pull/11398 PR: https://git.openjdk.org/jdk/pull/11398 From jvernee at openjdk.org Tue Nov 29 13:54:13 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 29 Nov 2022 13:54:13 GMT Subject: RFR: 8297733: Refactor Cast binding to enum Message-ID: Refactor the cast binding to an enum, which clearly enumerates all supported conversions. This also fixes a bug where `java/foreign/normalize/TestNormalize` was failing when running in interpreted mode (`-Djdk.internal.foreign.DowncallLinker.USE_SPEC=false`), for conversions from `int` to `byte` because the `explicitCast` method handle that was used only considers the least significant bit, while we want to look at all of the least significant byte. As mentioned in the JBS issue, doing this will also make it easier going forward to support multiple conversions with the same from and to types, but requiring different semantics. Testing: jdk_foreign test suite. ------------- Depends on: https://git.openjdk.org/jdk/pull/11019 Commit messages: - Refactor cast operator to enum Changes: https://git.openjdk.org/jdk/pull/11397/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11397&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297733 Stats: 82 lines in 2 files changed: 56 ins; 14 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11397.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11397/head:pull/11397 PR: https://git.openjdk.org/jdk/pull/11397 From alanb at openjdk.org Tue Nov 29 14:25:53 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Nov 2022 14:25:53 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v17] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove session exposure Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11260 From cstein at openjdk.org Tue Nov 29 14:52:57 2022 From: cstein at openjdk.org (Christian Stein) Date: Tue, 29 Nov 2022 14:52:57 GMT Subject: RFR: 8296710: Update to use jtreg 7.1 Message-ID: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com> Please review the change to update to using jtreg `7.1`. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. This pull request was created by copying the following and using `7.1` at appropriate places: - https://github.com/openjdk/jdk/pull/9393 ------------- Commit messages: - 8296710: Update to use jtreg 7.1 Changes: https://git.openjdk.org/jdk/pull/11416/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11416&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8296710 Stats: 9 lines in 8 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/11416.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11416/head:pull/11416 PR: https://git.openjdk.org/jdk/pull/11416 From rriggs at openjdk.org Tue Nov 29 15:36:21 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 29 Nov 2022 15:36:21 GMT Subject: RFR: 8297271: AccessFlags should be specific to class file version In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 22:56:27 GMT, Roger Riggs wrote: > The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field assume the access flags are from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits. > > The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version: Yes, the location information via `AccessFlags.locations(ClassFileFormatVersion)` provides the needed information. And the tests verify that information. My objective was to make the AccessFlags returned for a class reflect the class file format version number of the underlying class. Currently, it is implicitly the current class file format version supported by the VM, not necessarily the version of the class loaded. Suggestions welcome for how that is exposed in the APIs and implemented. ------------- PR: https://git.openjdk.org/jdk/pull/11399 From alanb at openjdk.org Tue Nov 29 16:09:24 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Nov 2022 16:09:24 GMT Subject: RFR: 8296710: Update to use jtreg 7.1 In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com> References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com> Message-ID: On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein wrote: > Please review the change to update to using jtreg `7.1`. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > This pull request was created by copying the following and using `7.1` at appropriate places: > - https://github.com/openjdk/jdk/pull/9393 Can you confirm that you've run all the tests with the change? Sometimes these updates need changes to a small number of tests. ------------- PR: https://git.openjdk.org/jdk/pull/11416 From alanb at openjdk.org Tue Nov 29 16:09:37 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Nov 2022 16:09:37 GMT Subject: RFR: 8294278: ForkJoinPool.getAndAddPoolIds should use Unsafe.staticFieldBase Message-ID: Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide the Class object as the base instead of the base object returned by Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/11369/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11369&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294278 Stats: 17 lines in 2 files changed: 12 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11369.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11369/head:pull/11369 PR: https://git.openjdk.org/jdk/pull/11369 From jvernee at openjdk.org Tue Nov 29 16:13:11 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 29 Nov 2022 16:13:11 GMT Subject: RFR: 8290231: java/foreign/malloc/TestMixedMallocFree.java crashed in JDK19 ATR run Message-ID: This test allocates on the native side with `malloc`, and then tries to free that memory on the Java side. The library that we look up on the Java side is either ucrtbase.dll, or msvcrt.dll as a fallback if we don't find it. The fact that we're seeing this crash likely means that the test machine doesn't have ucrtbase.dll, but it does have a newer standard runtime library other than msvcrt.dll (one of the msvcp*.dll libraries). So, what can happen is: the native code in the test ends up being linked against this newer runtime library. We allocate using the newer runtime library's `malloc` function. Look up `free` from Java, don't find ucrtbase.dll so fall back to msvcrt.dll. Call `free` from msvcrt.dll which is not the right one, and then crash due to the allocator mismatch. --- I think we should just remove this test. In practice, we can not guarantee that native code is linked against the same dll as the one we pick to be the default library (for instance, the native code could have been linked against an older dll, even while ucrtbase.dll is present on the system). Trying to mach up the 2 libraries was important when we had public `allocateMemory` and `freeMemory` functions, but those were removed from the API. Using matching allocate & free pairs, which some of the other tests do, still works. ------------- Commit messages: - Remove MixedMallocFree test Changes: https://git.openjdk.org/jdk/pull/11417/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11417&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8290231 Stats: 101 lines in 2 files changed: 0 ins; 101 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11417.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11417/head:pull/11417 PR: https://git.openjdk.org/jdk/pull/11417 From psandoz at openjdk.org Tue Nov 29 16:21:25 2022 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 29 Nov 2022 16:21:25 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v17] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove session exposure Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11260 From burban at openjdk.org Tue Nov 29 16:31:01 2022 From: burban at openjdk.org (Bernhard Urban-Forster) Date: Tue, 29 Nov 2022 16:31:01 GMT Subject: RFR: 8294278: ForkJoinPool.getAndAddPoolIds should use Unsafe.staticFieldBase In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:53:57 GMT, Alan Bateman wrote: > Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide the Class object as the base instead of the base object returned by Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM. LGTM, thank you! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1532: > 1530: private static final long THREADIDS; > 1531: private static final Object POOLIDS_BASE; > 1532: private static final long POOLIDS; Minor nit: Maybe `POOLIDS` should be renamed to `POOLIDS_OFFSET`? ------------- Marked as reviewed by burban (Author). PR: https://git.openjdk.org/jdk/pull/11369 From chegar at openjdk.org Tue Nov 29 16:31:02 2022 From: chegar at openjdk.org (Chris Hegarty) Date: Tue, 29 Nov 2022 16:31:02 GMT Subject: RFR: 8294278: ForkJoinPool.getAndAddPoolIds should use Unsafe.staticFieldBase In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:53:57 GMT, Alan Bateman wrote: > Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide the Class object as the base instead of the base object returned by Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM. LGTM ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.org/jdk/pull/11369 From alanb at openjdk.org Tue Nov 29 16:38:48 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Nov 2022 16:38:48 GMT Subject: RFR: 8294278: ForkJoinPool.getAndAddPoolIds should use Unsafe.staticFieldBase In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 16:26:54 GMT, Bernhard Urban-Forster wrote: >> Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide the Class object as the base instead of the base object returned by Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM. > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1532: > >> 1530: private static final long THREADIDS; >> 1531: private static final Object POOLIDS_BASE; >> 1532: private static final long POOLIDS; > > Minor nit: Maybe `POOLIDS` should be renamed to `POOLIDS_OFFSET`? ForkJoinPool has several fields for field offsets so renaming one would be inconsistent and we'd end up renaming all of them. We also don't want to get too much out of sync with the "master" in Doug Lea's CVS. ------------- PR: https://git.openjdk.org/jdk/pull/11369 From darcy at openjdk.org Tue Nov 29 16:46:19 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 16:46:19 GMT Subject: RFR: 8297295: Remove ThreadGroup.allowThreadSuspension In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 18:54:28 GMT, Alan Bateman wrote: > Another small step in the multi-release/multi-year effort to remove cruft from Thread/ThreadGroup. > > java.lang.ThreadGroup.allowThreadSuspension(boolean) dates from JDK 1.1 and the Classic VM. The method controlled whether threads were suspended when the GC failed. It appears to have interacted with a callback mechanism that could potentially free memory, allowing the GC to retry. The method was never specified . > > The method was deprecated and changed to do nothing in JDK 1.2. It was deprecated for removal in Java 14. > > A corpus analysis of 30M classes in 130k artifacts found 0 usages of this method. > > It is time to finally remove this method. The compatibility impact should be negligible. Joe, Stuart and I discussed briefly and think early in JDK 21 is a good time to do this. Good for JDK 21. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.org/jdk/pull/11373 From jwaters at openjdk.org Tue Nov 29 17:09:28 2022 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 29 Nov 2022 17:09:28 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com> References: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com> Message-ID: On Wed, 23 Nov 2022 21:36:24 GMT, Kim Barrett wrote: >> I think the problem here is the friend declaration, which doesn't look like it's needed and could be deleted. > > Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`. > > One obvious and cheap solution to that would be to make that enum public. I think that would be an improvement vs the current friend declaration. But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used. Here's a patch that I think cleans this up. > > > diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp > index 0651f0868f3..bf9e759b1d6 100644 > --- a/src/hotspot/os/windows/os_windows.cpp > +++ b/src/hotspot/os/windows/os_windows.cpp > @@ -511,7 +511,9 @@ JNIEXPORT > LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo); > > // Thread start routine for all newly created threads > -static unsigned __stdcall thread_native_entry(Thread* thread) { > +// Called with the associated Thread* as the argument. > +unsigned __stdcall os::win32::thread_native_entry(void* t) { > + Thread* thread = static_cast(t); > > thread->record_stack_base_and_size(); > thread->initialize_thread_current(); > @@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type, > thread_handle = > (HANDLE)_beginthreadex(NULL, > (unsigned)stack_size, > - (unsigned (__stdcall *)(void*)) thread_native_entry, > + &os::win32::thread_native_entry, > thread, > initflag, > &thread_id); > diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp > index 94d7c3c5e2d..197797078d7 100644 > --- a/src/hotspot/os/windows/os_windows.hpp > +++ b/src/hotspot/os/windows/os_windows.hpp > @@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int); > > class os::win32 { > friend class os; > - friend unsigned __stdcall thread_native_entry(Thread*); > > protected: > static int _processor_type; > @@ -70,6 +69,10 @@ class os::win32 { > static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen); > > private: > + // The handler passed to _beginthreadex(). > + // Called with the associated Thread* as the argument. > + static unsigned __stdcall thread_native_entry(void*); > + > enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE }; > // Wrapper around _endthreadex(), exit() and _exit() > static int exit_process_or_thread(Ept what, int exit_code); The issue with that would be that thread_native_entry is declared as static to the compilation unit on other other Operating Systems as well, and having it as a static member on the win32 class instead would end up breaking this convention, for which I'm not sure if there's a reason why all of them are declared like this ------------- PR: https://git.openjdk.org/jdk/pull/11081 From vromero at openjdk.org Tue Nov 29 17:33:19 2022 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 29 Nov 2022 17:33:19 GMT Subject: RFR: JDK-8296149: Start of release updates for JDK 21 In-Reply-To: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> References: <8UtOnxdA8Un9aL-EfX77-9vvCVQW6BCZQBH4zM4rkGw=.2810e51c-6c15-4124-ad1d-e2269f65bdbe@github.com> Message-ID: On Tue, 1 Nov 2022 05:49:25 GMT, Joe Darcy wrote: > Usual start-of-release updates. Symbol updates in initial version reflect JDK 20 build 21. looks good ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.org/jdk/pull/10924 From erikj at openjdk.org Tue Nov 29 17:57:22 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 29 Nov 2022 17:57:22 GMT Subject: RFR: 8296710: Update to use jtreg 7.1 In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com> References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com> Message-ID: <3MbFV3Yz1mkexhdEMXTtpXXGdr-yJvvM7Z9FyyVu9Do=.2c003086-a5b8-45f7-86d0-4574425677c7@github.com> On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein wrote: > Please review the change to update to using jtreg `7.1`. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > This pull request was created by copying the following and using `7.1` at appropriate places: > - https://github.com/openjdk/jdk/pull/9393 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11416 From bpb at openjdk.org Tue Nov 29 18:08:26 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 18:08:26 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v17] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove session exposure Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11260 From bpb at openjdk.org Tue Nov 29 18:26:03 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 18:26:03 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v2] In-Reply-To: References: Message-ID: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> > `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8297632: Transfer all bytes but clamp returned value to Long.MAX_VALUE ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11403/files - new: https://git.openjdk.org/jdk/pull/11403/files/11d73c60..254d6990 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=00-01 Stats: 20 lines in 1 file changed: 0 ins; 12 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403 PR: https://git.openjdk.org/jdk/pull/11403 From bpb at openjdk.org Tue Nov 29 18:28:14 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 18:28:14 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 00:56:58 GMT, Brian Burkhalter wrote: > `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. Modified in 254d6990bcf75700f1c3aa18e0f8b73b639d9bad to transfer all bytes but clamp the return value to `Long.MAX_VALUE`. Overrides in `java.io` were already examined and do not appear problematic but a second check would not hurt. ------------- PR: https://git.openjdk.org/jdk/pull/11403 From duke at openjdk.org Tue Nov 29 18:35:23 2022 From: duke at openjdk.org (Justin Lu) Date: Tue, 29 Nov 2022 18:35:23 GMT Subject: Integrated: 8297685: Typo in NullPointerException description specified by Locale.lookup In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 17:53:43 GMT, Justin Lu wrote: > Problem: Javadoc in Locale.lookup is incorrect. Javadoc should match the parameter arguments. See lines 3562-3563. > > Fix: For `@throws NullPointerException` replace `if priorityList or tags is null` with `if priorityList or locales is null `. This pull request has now been integrated. Changeset: ae5b1f76 Author: Justin Lu Committer: Naoto Sato URL: https://git.openjdk.org/jdk/commit/ae5b1f765678a9928696acb7228b197e293171be Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8297685: Typo in NullPointerException description specified by Locale.lookup Reviewed-by: naoto, lancea, jpai ------------- PR: https://git.openjdk.org/jdk/pull/11394 From alanb at openjdk.org Tue Nov 29 18:39:39 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Nov 2022 18:39:39 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v2] In-Reply-To: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> References: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> Message-ID: On Tue, 29 Nov 2022 18:26:03 GMT, Brian Burkhalter wrote: >> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297632: Transfer all bytes but clamp returned value to Long.MAX_VALUE I assume Reader.transferTo will need similar treatment. ------------- PR: https://git.openjdk.org/jdk/pull/11403 From bpb at openjdk.org Tue Nov 29 18:39:39 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 18:39:39 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v2] In-Reply-To: References: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> Message-ID: On Tue, 29 Nov 2022 18:35:40 GMT, Alan Bateman wrote: > I assume Reader.transferTo will need similar treatment. Looks like it. I will re-scan for other places as well. ------------- PR: https://git.openjdk.org/jdk/pull/11403 From alanb at openjdk.org Tue Nov 29 18:51:24 2022 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 29 Nov 2022 18:51:24 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v2] In-Reply-To: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> References: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> Message-ID: On Tue, 29 Nov 2022 18:26:03 GMT, Brian Burkhalter wrote: >> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297632: Transfer all bytes but clamp returned value to Long.MAX_VALUE I assume this will require adjustments to SequenceInputStream.transferTo proposed in pull/11248. ------------- PR: https://git.openjdk.org/jdk/pull/11403 From bpb at openjdk.org Tue Nov 29 18:54:28 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 18:54:28 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v2] In-Reply-To: References: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> Message-ID: On Tue, 29 Nov 2022 18:47:35 GMT, Alan Bateman wrote: > I assume this will require adjustments to SequenceInputStream.transferTo proposed in pull/11248. I will scan for all overrides. ------------- PR: https://git.openjdk.org/jdk/pull/11403 From bpb at openjdk.org Tue Nov 29 19:00:06 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 19:00:06 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v2] In-Reply-To: References: <9DAlbngK-gVIO934QZzcun5RdR1Ktfw6cwjR4CK2Dlg=.21ee821d-b166-409f-b61c-b8bd7c36334e@github.com> Message-ID: On Tue, 29 Nov 2022 18:52:23 GMT, Brian Burkhalter wrote: > > I assume this will require adjustments to SequenceInputStream.transferTo proposed in pull/11248. > > I will scan for all overrides. Correction: yes, that one has the same problem. ------------- PR: https://git.openjdk.org/jdk/pull/11403 From mcimadamore at openjdk.org Tue Nov 29 19:10:23 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 29 Nov 2022 19:10:23 GMT Subject: RFR: 8290231: java/foreign/malloc/TestMixedMallocFree.java crashed in JDK19 ATR run In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 15:40:53 GMT, Jorn Vernee wrote: > This test allocates on the native side with `malloc`, and then tries to free that memory on the Java side. The library that we look up on the Java side is either ucrtbase.dll, or msvcrt.dll as a fallback if we don't find it. The fact that we're seeing this crash likely means that the test machine doesn't have ucrtbase.dll, but it does have a newer standard runtime library other than msvcrt.dll (one of the msvcp*.dll libraries). > > So, what can happen is: the native code in the test ends up being linked against this newer runtime library. We allocate using the newer runtime library's `malloc` function. Look up `free` from Java, don't find ucrtbase.dll so fall back to msvcrt.dll. Call `free` from msvcrt.dll which is not the right one, and then crash due to the allocator mismatch. > > --- > > I think we should just remove this test. In practice, we can not guarantee that native code is linked against the same dll as the one we pick to be the default library (for instance, the native code could have been linked against an older dll, even while ucrtbase.dll is present on the system). > > Trying to mach up the 2 libraries was important when we had public `allocateMemory` and `freeMemory` functions, but those were removed from the API. > > Using matching allocate & free pairs, which some of the other tests do, still works. Looks good - I agree this test isn't useful anymore ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/11417 From ihse at openjdk.org Tue Nov 29 19:26:36 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 29 Nov 2022 19:26:36 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding Yes bot, I know. I'll need to split this up into multiple steps, but please keep this open for a while more. Thank you. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From bpb at openjdk.org Tue Nov 29 19:36:40 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 19:36:40 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v3] In-Reply-To: References: Message-ID: > `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8297632: Add Reader::transferTo and select InputStream::transferTo overrides ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11403/files - new: https://git.openjdk.org/jdk/pull/11403/files/254d6990..67516279 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=01-02 Stats: 26 lines in 5 files changed: 21 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403 PR: https://git.openjdk.org/jdk/pull/11403 From bpb at openjdk.org Tue Nov 29 19:42:28 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 19:42:28 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2] In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 09:41:47 GMT, Markus KARG wrote: >> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. >> >> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed bug number Please take note of the changes proposed in #11403. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From shade at openjdk.org Tue Nov 29 19:48:59 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 29 Nov 2022 19:48:59 GMT Subject: RFR: 8297784: Optimize @Stable field for Method.isCallerSensitive Message-ID: [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the `@Stable private Boolean callerSensitive;` cache in `Method`. That field is essentially a tri-state `Boolean` that relies on its `null` value to serve as "not initialized" value for `@Stable`. This works well when the holder `Method` instance is constant: JIT compilers fold `@Stable` well. But if such folding fails, we always dereference the full-blown reference to "boxed" `Boolean` from the field on every access. We can instead do a more lean tri-state primitive field to improve that non-optimized case without sacrificing optimized case. I chose `byte` and `-1`, `0`, `1` to let the fastpath encode well on most (all?) architectures. On adhoc benchmark like: @State(Scope.Thread) public class WrapperConstness { static final Method CONST; static Method NON_CONST; static { try { CONST = WrapperConstness.class.getDeclaredMethod("target"); NON_CONST = CONST; } catch (NoSuchMethodException e) { throw new RuntimeException(e); } } public void target() {} @Benchmark public void nonConstant() throws Exception { NON_CONST.invoke(this); } @Benchmark public void constant() throws Exception { CONST.invoke(this); } } We have a minor improvement for non-const case, confirmed due to better `isCallerSensitive` access: Benchmark Mode Cnt Score Error Units # Baseline WrapperConstness.constant avgt 25 0.410 ? 0.010 ns/op WrapperConstness.nonConstant avgt 25 7.283 ? 0.025 ns/op # Patched WrapperConstness.constant avgt 5 0.407 ? 0.008 ns/op WrapperConstness.nonConstant avgt 5 7.054 ? 0.027 ns/op ; -3% Additional testing: - [x] Ad-hoc benchmarks - [x] Linux x86_64 fastdebug `java/lang/reflect` - [ ] Linux x86_64 fastdebug `tier1`, `tier2` ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/11422/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11422&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297784 Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11422/head:pull/11422 PR: https://git.openjdk.org/jdk/pull/11422 From darcy at openjdk.org Tue Nov 29 20:25:21 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 20:25:21 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide In-Reply-To: References: Message-ID: <1O_AmxAYyIId09Yv1IzyTD_RFmXKl8-jk7LN20R0YUE=.42a1376f-2b48-4cb6-aa7a-827864a6df0b@github.com> On Tue, 29 Nov 2022 07:39:59 GMT, Andrey Turbanov wrote: > IDEA now highlights unnecessary `rem.offset=1` assignments, which are above modified code. Now we always overwrite it with `0` anyway. > > https://github.com/openjdk/jdk/blob/6f06f440bcf8a5db379b80e8765af38a15449356/src/java.base/share/classes/java/math/MutableBigInteger.java#L1498 > > https://github.com/openjdk/jdk/blob/6f06f440bcf8a5db379b80e8765af38a15449356/src/java.base/share/classes/java/math/MutableBigInteger.java#L1504 > > https://github.com/openjdk/jdk/blob/6f06f440bcf8a5db379b80e8765af38a15449356/src/java.base/share/classes/java/math/MutableBigInteger.java#L1520 > > Perhaps we can drop them too. Hmm. Looks to me like the earlier assignments of 1 to the rem object's offset field are to preserve inter-field semantic constraints. So while it is true this field is not used before it is overwritten circa line 1536, I'd reluctant to "break" the object constraints in the interim since it could complicated future maintenance, event with commenting. Thoughts @bplb or @rgiulietti ? ------------- PR: https://git.openjdk.org/jdk/pull/11395 From darcy at openjdk.org Tue Nov 29 20:35:00 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 20:35:00 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide [v2] In-Reply-To: References: Message-ID: > Remove redundant code reported in > > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Remove whitespace. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11395/files - new: https://git.openjdk.org/jdk/pull/11395/files/0e74b515..1f1a2b59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11395&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11395&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11395.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11395/head:pull/11395 PR: https://git.openjdk.org/jdk/pull/11395 From mstjohns at comcast.net Tue Nov 29 03:14:20 2022 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 28 Nov 2022 22:14:20 -0500 Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <6eb484c9-2652-0e4d-ac6d-f13f3810795b@comcast.net> Hi - I need to repeat again.? Please avoid using www.ietf.org as the URL base for referencing RFCs.? The appropriate location is www.rfc-editor.org and is going to be more stable in the long run than any reference to an RFC that runs through the IETF's website.? These two websites have different purposes, and the structure of the IETF website has changed at least once recently and may change again relatively (~5 years) soon. The most general and correct form for referencing RFCs is "https://www.rfc-editor.org/info/rfc"? That will get you to the front page with pointers to all of the current semi-canonical versions of the spec (e.g. text, pdf-a, html, and xml). Mike On 11/28/2022 6:27 PM, Phil Race wrote: > On Wed, 23 Nov 2022 18:57:03 GMT, Jonathan Gibbons wrote: > >>> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >>> >>> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >>> >>> "Normalized" means... >>> * Use `https:` where possible (includes pretty much all cases) >>> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >>> * Point to the root page of a multi-page spec >>> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >>> >>> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >>> >>> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >>> >>> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >>> >>> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >>> >>> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >>> >>> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove updates from unexported files > src/java.desktop/share/classes/java/awt/package-info.java line 58: > >> 56: *
    • The AWT Modality >> 57: *
    • >> 58: * The Java AWT Native Interface (JAWT) > Why only 1 of these 3 ? > > src/java.desktop/share/classes/java/awt/package-info.java line 62: > >> 60: * >> 61: * @spec AWT_Native_Interface.html The Java AWT Native Interface Specification and Guide >> 62: * @since 1.0 > I wonder if links to html we include in the javadoc should be really treated in the same manner as referecnes to externally defined specifactions ? > But I also wonder why only the native_interface spec was added and not the other two ? > > src/java.desktop/share/classes/javax/imageio/plugins/tiff/BaselineTIFFTagSet.java line 226: > >> 224: * @spec https://www.ietf.org/rfc/rfc1951.html RFC 1951: DEFLATE Compressed Data Format Specification version 1.3 >> 225: * @see #TAG_COMPRESSION >> 226: * @see DEFLATE specification > Does having @spec and @see mean we have two clickable links to the same place adjacent to each other ? > > ------------- > > PR: https://git.openjdk.org/jdk/pull/11073 From duke at openjdk.org Tue Nov 29 21:06:18 2022 From: duke at openjdk.org (Markus KARG) Date: Tue, 29 Nov 2022 21:06:18 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 19:39:49 GMT, Brian Burkhalter wrote: > Please take note of the changes proposed in #11403. It might make sense to merge *this* PR as-is *first*, but then add the needed fix to #11403 afterwards? Otherwise it might be confusing for a reader, why #11403 is not covering SIS when checking the commit history. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From mcimadamore at openjdk.org Tue Nov 29 21:30:21 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 29 Nov 2022 21:30:21 GMT Subject: RFR: 8297733: Refactor Cast binding to enum In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 20:13:35 GMT, Jorn Vernee wrote: > Refactor the cast binding to an enum, which clearly enumerates all supported conversions. > > This also fixes a bug where `java/foreign/normalize/TestNormalize` was failing when running in interpreted mode (`-Djdk.internal.foreign.DowncallLinker.USE_SPEC=false`), for conversions from `int` to `byte` because the `explicitCast` method handle that was used only considers the least significant bit, while we want to look at all of the least significant byte. > > As mentioned in the JBS issue, doing this will also make it easier going forward to support multiple conversions with the same from and to types, but requiring different semantics. > > Testing: jdk_foreign test suite. Looks good ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.org/jdk/pull/11397 From duke at openjdk.org Tue Nov 29 21:41:06 2022 From: duke at openjdk.org (Oliver Kopp) Date: Tue, 29 Nov 2022 21:41:06 GMT Subject: RFR: 8240567: MethodTooLargeException thrown while creating a jlink image [v5] In-Reply-To: References: Message-ID: <90FTl1ZDV293y3BOchnTcIbfSmcfRYBDJMpZ3ZGC10U=.27c2bf05-ee65-4103-9a9e-49a74f0dad25@github.com> > Fix for [JDK-8240567](https://bugs.openjdk.org/browse/JDK-8240567): "MethodTooLargeException thrown while creating a jlink image". > > Java still has a 64kb limit: A method may not be longer than 64kb. The idea of the fix is to split up the generated methods in several smaller methods Oliver Kopp has updated the pull request incrementally with two additional commits since the last revision: - Adapt number to have javac working (and refine test) - Remove obsolete comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10704/files - new: https://git.openjdk.org/jdk/pull/10704/files/7c39bd3e..8e94741a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10704&range=03-04 Stats: 17 lines in 2 files changed: 8 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/10704.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10704/head:pull/10704 PR: https://git.openjdk.org/jdk/pull/10704 From mcimadamore at openjdk.org Tue Nov 29 21:47:30 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 29 Nov 2022 21:47:30 GMT Subject: RFR: 8297736: test/jdk/java/foreign/TestMatrix.java is broken In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 21:03:33 GMT, Jorn Vernee wrote: > - Fix tests that try to run `TestDowncall` which was split into TestDowncallScope and TestDowncallStack > - Fix use of obsolete system properties to control specilization > - Add test to run TestVarArgs in un-sampled mode. > > Testing: Manual runs of TestMatrix.java (it's a manual test) on Windows and Linux (WSL). Marked as reviewed by mcimadamore (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11398 From redestad at openjdk.org Tue Nov 29 22:07:01 2022 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 29 Nov 2022 22:07:01 GMT Subject: RFR: 8297728: Cache invocation type rather than invoker in NamedFunction Message-ID: `java.lang.invoke.LambdaForm.NamedFunction` has an `invoker` field acting as a cache, but this field is only used for lambda form interpretation, thus not very performance sensitive. Since the invoker is already cached in the method type hierarchy we could replace it with a cache of the invocation type instead. This means cost to retrieve an invoker for lambda form interpretation is only slightly affected (a few ns/op that end up in the noise since interpretation already incur a >50ns/op overhead on even the simplest forms), while speeding up bytecode generation for `LF`s with `NamedFunction`s not holding a resolvedHandle. Being lazy about the creation of the type is not significantly beneficial right now, but is done in anticipation of future changes that may better defer bytecode spinning for `LambdaForm`s. ------------- Commit messages: - Lazily calculate type - Cache invocation type rather than invoker in NamedFunction Changes: https://git.openjdk.org/jdk/pull/11424/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11424&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297728 Stats: 19 lines in 1 file changed: 9 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11424.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11424/head:pull/11424 PR: https://git.openjdk.org/jdk/pull/11424 From redestad at openjdk.org Tue Nov 29 22:21:33 2022 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 29 Nov 2022 22:21:33 GMT Subject: RFR: 8297784: Optimize @Stable field for Method.isCallerSensitive In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 19:39:02 GMT, Aleksey Shipilev wrote: > [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the `@Stable private Boolean callerSensitive;` cache in `Method`. That field is essentially a tri-state `Boolean` that relies on its `null` value to serve as "not initialized" value for `@Stable`. > > This works well when the holder `Method` instance is constant: JIT compilers fold `@Stable` well. But if such folding fails, we always dereference the full-blown reference to "boxed" `Boolean` from the field on every access. We can instead do a more lean tri-state primitive field to improve that non-optimized case without sacrificing optimized case. > > I chose `byte` and `-1`, `0`, `1` to let the fastpath encode well on most (all?) architectures. > > On adhoc benchmark like: > > > @State(Scope.Thread) > public class WrapperConstness { > static final Method CONST; > static Method NON_CONST; > > static { > try { > CONST = WrapperConstness.class.getDeclaredMethod("target"); > NON_CONST = CONST; > } catch (NoSuchMethodException e) { > throw new RuntimeException(e); > } > } > > public void target() {} > > @Benchmark > public void nonConstant() throws Exception { > NON_CONST.invoke(this); > } > > @Benchmark > public void constant() throws Exception { > CONST.invoke(this); > } > } > > > We have a minor improvement for non-const case, confirmed due to better `isCallerSensitive` access: > > > Benchmark Mode Cnt Score Error Units > > # Baseline > WrapperConstness.constant avgt 25 0.410 ? 0.010 ns/op > WrapperConstness.nonConstant avgt 25 7.283 ? 0.025 ns/op > > # Patched > WrapperConstness.constant avgt 5 0.407 ? 0.008 ns/op > WrapperConstness.nonConstant avgt 5 7.054 ? 0.027 ns/op ; -3% > > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug `java/lang/reflect` > - [ ] Linux x86_64 fastdebug `tier1`, `tier2` LGTM. ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.org/jdk/pull/11422 From darcy at openjdk.org Tue Nov 29 22:37:16 2022 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 29 Nov 2022 22:37:16 GMT Subject: RFR: 8297271: AccessFlags should be specific to class file version In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 15:33:44 GMT, Roger Riggs wrote: > Yes, the location information via `AccessFlags.locations(ClassFileFormatVersion)` provides the needed information. And the tests verify that information. My objective was to make the AccessFlags returned for a class reflect the class file format version number of the underlying class. Currently, it is implicitly the current class file format version supported by the VM, not necessarily the version of the class loaded. Suggestions welcome for how that is exposed in the APIs and implemented. I don't agree the assessment that the API implicitly assumes the class file version used to compute the access flags is the latest one supported by the JVM. In the context of the accessFlags methods defined in core reflection, the implementation in the Java libraries and the specification implicitly assume the JVM "does the right thing" with respect to access flags per JVMS 4.1. The ClassFile Structure: "All bits of the access_flags item not assigned in [Table 4.1-B](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.1-200-E.1) are reserved for future use. They should be set to zero in generated class files and should be ignored by Java Virtual Machine implementations." So the desired (and actual observed) behavior is that in effect a class file version specific mask is applied to screen out the access flag bits before they are handed back to the core reflection library code to build the Set for a class, method, field, etc. ------------- PR: https://git.openjdk.org/jdk/pull/11399 From jvernee at openjdk.org Tue Nov 29 22:46:15 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 29 Nov 2022 22:46:15 GMT Subject: RFR: 8297728: Cache invocation type rather than invoker in NamedFunction In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 21:57:09 GMT, Claes Redestad wrote: > `java.lang.invoke.LambdaForm.NamedFunction` has an `invoker` field acting as a cache, but this field is only used for lambda form interpretation, thus not very performance sensitive. > > Since the invoker is already cached in the method type hierarchy we could replace it with a cache of the invocation type instead. This means cost to retrieve an invoker for lambda form interpretation is only slightly affected (a few ns/op that end up in the noise since interpretation already incur a >50ns/op overhead on even the simplest forms), while speeding up bytecode generation for `LF`s with `NamedFunction`s not holding a resolvedHandle. > > Being lazy about the creation of the type is not significantly beneficial right now, but is done in anticipation of future changes that may better defer bytecode spinning for `LambdaForm`s. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11424 From jvernee at openjdk.org Tue Nov 29 22:47:07 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 29 Nov 2022 22:47:07 GMT Subject: RFR: 8297784: Optimize @Stable field for Method.isCallerSensitive In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 19:39:02 GMT, Aleksey Shipilev wrote: > [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the `@Stable private Boolean callerSensitive;` cache in `Method`. That field is essentially a tri-state `Boolean` that relies on its `null` value to serve as "not initialized" value for `@Stable`. > > This works well when the holder `Method` instance is constant: JIT compilers fold `@Stable` well. But if such folding fails, we always dereference the full-blown reference to "boxed" `Boolean` from the field on every access. We can instead do a more lean tri-state primitive field to improve that non-optimized case without sacrificing optimized case. > > I chose `byte` and `-1`, `0`, `1` to let the fastpath encode well on most (all?) architectures. > > On adhoc benchmark like: > > > @State(Scope.Thread) > public class WrapperConstness { > static final Method CONST; > static Method NON_CONST; > > static { > try { > CONST = WrapperConstness.class.getDeclaredMethod("target"); > NON_CONST = CONST; > } catch (NoSuchMethodException e) { > throw new RuntimeException(e); > } > } > > public void target() {} > > @Benchmark > public void nonConstant() throws Exception { > NON_CONST.invoke(this); > } > > @Benchmark > public void constant() throws Exception { > CONST.invoke(this); > } > } > > > We have a minor improvement for non-const case, confirmed due to better `isCallerSensitive` access: > > > Benchmark Mode Cnt Score Error Units > > # Baseline > WrapperConstness.constant avgt 25 0.410 ? 0.010 ns/op > WrapperConstness.nonConstant avgt 25 7.283 ? 0.025 ns/op > > # Patched > WrapperConstness.constant avgt 5 0.407 ? 0.008 ns/op > WrapperConstness.nonConstant avgt 5 7.054 ? 0.027 ns/op ; -3% > > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug `java/lang/reflect` > - [ ] Linux x86_64 fastdebug `tier1`, `tier2` Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11422 From bpb at openjdk.org Tue Nov 29 23:43:16 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 29 Nov 2022 23:43:16 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2] In-Reply-To: References: Message-ID: On Sun, 20 Nov 2022 09:41:47 GMT, Markus KARG wrote: >> Since JDK 18 some implementations of InputStream.transferTo, namely FileInputStream and ChannelInputStream, offload work to lower layers using NIO channels. This provides shorter execution time and reduced resource consumption. Unfortunately, this effect is prevented once the input stream itself is wrapped by a SequenceInputStream. While compared to other InputStreams the SequenceInputStream is a rather edge case (e. g. used to merge two files into one), nevertheless it makes sense to get rid of this obstacle simply by implementing transferTo (e. g. by allowing to offload the file merge, or parts of the file merge, to the operating system). As a result, more existing applications will experience the offloading-improvements made by JDK 18. >> >> To provide enhanced performance to existing applications, it makes sense to address this impediment: SequenceInputStream.transferTo should be implemented in a way that iteratively calls transferTo on each enumerated InputStream of the SequenceInputStream in ordered sequence. > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed bug number > > Please take note of the changes proposed in #11403. > > It might make sense to merge _this_ PR as-is _first_, but then add the needed fix to #11403 afterwards? I concur. I will take a look at the test soon. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From jpai at openjdk.org Wed Nov 30 00:40:21 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 30 Nov 2022 00:40:21 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 10:02:47 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. >> >> I'll raise separate PRs in the other remaining areas from that other PR. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Address review comment - don't change WithHelperPublisher.java Thank you everyone for the reviews. ------------- PR: https://git.openjdk.org/jdk/pull/11385 From jpai at openjdk.org Wed Nov 30 00:40:21 2022 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 30 Nov 2022 00:40:21 GMT Subject: Integrated: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 08:58:29 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which fixes the typos in the test packages? @mernst submitted this as a separate PR https://github.com/openjdk/jdk/pull/10029 but given the number of areas and files that other PR touches, the progress has been stalled. > > I'll raise separate PRs in the other remaining areas from that other PR. This pull request has now been integrated. Changeset: 0ce18272 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/0ce182723b8d3a98c71c1b71fa1d3f5a7479fba8 Stats: 20 lines in 19 files changed: 0 ins; 0 del; 20 mod 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Co-authored-by: Michael Ernst Reviewed-by: alanb, lancea, dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/11385 From bchristi at openjdk.org Wed Nov 30 01:15:54 2022 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 30 Nov 2022 01:15:54 GMT Subject: RFR: 8295857: Clarify that cleanup code can be skipped when the JVM terminates (e.g. when calling halt()) [v5] In-Reply-To: References: Message-ID: > [JDK-8290036](https://bugs.openjdk.org/browse/JDK-8290036) documented the shutdown sequence, noting that calling Runtime.halt() skips the shutdown sequence and immediately terminates the VM. Thus, "threads' current methods do not complete normally or abruptly; no finally clause of any method is executed". > > One ramification of this is that resources within try-with-resource blocks will not be released. It would be good to state this explicitly. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: put examples into a list, in class doc only, not halt() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11218/files - new: https://git.openjdk.org/jdk/pull/11218/files/6df8acf8..4f2fb241 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11218&range=03-04 Stats: 13 lines in 1 file changed: 2 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11218.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11218/head:pull/11218 PR: https://git.openjdk.org/jdk/pull/11218 From martin at openjdk.org Wed Nov 30 02:21:21 2022 From: martin at openjdk.org (Martin Buchholz) Date: Wed, 30 Nov 2022 02:21:21 GMT Subject: RFR: 8294278: ForkJoinPool.getAndAddPoolIds should use Unsafe.staticFieldBase In-Reply-To: References: Message-ID: On Fri, 25 Nov 2022 14:53:57 GMT, Alan Bateman wrote: > Two (since 19) usages of Unsafe.getAndAddInt to update a static field provide the Class object as the base instead of the base object returned by Unsafe.staticFieldBase. This doesn't change anything on the HotSpot VM. The introduction of POOLIDS_BASE strengthens the case for renaming POOLIDS to POOLIDS_OFFSET for clarity - I would do that. ------------- Marked as reviewed by martin (Reviewer). PR: https://git.openjdk.org/jdk/pull/11369 From darcy at openjdk.org Wed Nov 30 04:58:24 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 30 Nov 2022 04:58:24 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v32] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 19:29:08 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/java.base/share/classes/java/lang/foreign/Linker.java line 288: > 286: > 287: /** > 288: * {@return A linker option used to denote the index of the first variadic argument layout in a Typo: "A linker" vs "a linker" ------------- PR: https://git.openjdk.org/jdk/pull/10872 From duke at openjdk.org Wed Nov 30 05:02:25 2022 From: duke at openjdk.org (Chris Hennick) Date: Wed, 30 Nov 2022 05:02:25 GMT Subject: RFR: 8284493: Fix rounding error in computeNextExponential [v16] In-Reply-To: References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com> Message-ID: <8yRT_qJsNf9-ik9iJ3puKB8XeX7J2hpaFDRa4qUcRVc=.c2bf8458-698d-4a87-b944-602c6d222dde@github.com> On Tue, 4 Oct 2022 17:36:56 GMT, Chris Hennick wrote: >> This PR improves both the performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections: >> >> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`. >> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.) >> * Uses the newly-extracted `computeWinsorizedNextExponential` function to greatly reduce the probability that `nextGaussian` suffers from *two* tail cases of `nextExponential`. > > Chris Hennick has updated the pull request incrementally with one additional commit since the last revision: > > Add parameter to enable/disable fixed PRNG seed Keep open. Testing is in progress right now. ------------- PR: https://git.openjdk.org/jdk/pull/8131 From dholmes at openjdk.org Wed Nov 30 06:07:30 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 30 Nov 2022 06:07:30 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: References: <0fVP40VVRuOoZCEJ1M3BLubshBHbD4m_lj-j1qaGTTk=.391ade50-b3fe-4d4e-ae71-ba8a975a31cd@github.com> <3mBOtLQz_ulylm0XJkhUBwzPEV7AoPmMo20facw9Xn4=.c431ac9c-4f1f-4db6-bb46-745987f06777@github.com> Message-ID: <5dO9bO57dyw99J9wxZceMOy1FujzO-JFXWxODl3LlCc=.e37a178a-21c9-4aec-97f0-ec01eb3903b0@github.com> On Tue, 29 Nov 2022 17:07:02 GMT, Julian Waters wrote: >> Digging into this some more, the friend declaration exists to provide access to the private `os::win32::enum Ept`. >> >> One obvious and cheap solution to that would be to make that enum public. I think that would be an improvement vs the current friend declaration. But there are some other things one could complain about there, such as the type of the function requiring a complicated function pointer cast where it's used. Here's a patch that I think cleans this up. >> >> >> diff --git a/src/hotspot/os/windows/os_windows.cpp b/src/hotspot/os/windows/os_windows.cpp >> index 0651f0868f3..bf9e759b1d6 100644 >> --- a/src/hotspot/os/windows/os_windows.cpp >> +++ b/src/hotspot/os/windows/os_windows.cpp >> @@ -511,7 +511,9 @@ JNIEXPORT >> LONG WINAPI topLevelExceptionFilter(struct _EXCEPTION_POINTERS* exceptionInfo); >> >> // Thread start routine for all newly created threads >> -static unsigned __stdcall thread_native_entry(Thread* thread) { >> +// Called with the associated Thread* as the argument. >> +unsigned __stdcall os::win32::thread_native_entry(void* t) { >> + Thread* thread = static_cast(t); >> >> thread->record_stack_base_and_size(); >> thread->initialize_thread_current(); >> @@ -744,7 +746,7 @@ bool os::create_thread(Thread* thread, ThreadType thr_type, >> thread_handle = >> (HANDLE)_beginthreadex(NULL, >> (unsigned)stack_size, >> - (unsigned (__stdcall *)(void*)) thread_native_entry, >> + &os::win32::thread_native_entry, >> thread, >> initflag, >> &thread_id); >> diff --git a/src/hotspot/os/windows/os_windows.hpp b/src/hotspot/os/windows/os_windows.hpp >> index 94d7c3c5e2d..197797078d7 100644 >> --- a/src/hotspot/os/windows/os_windows.hpp >> +++ b/src/hotspot/os/windows/os_windows.hpp >> @@ -36,7 +36,6 @@ typedef void (*signal_handler_t)(int); >> >> class os::win32 { >> friend class os; >> - friend unsigned __stdcall thread_native_entry(Thread*); >> >> protected: >> static int _processor_type; >> @@ -70,6 +69,10 @@ class os::win32 { >> static HINSTANCE load_Windows_dll(const char* name, char *ebuf, int ebuflen); >> >> private: >> + // The handler passed to _beginthreadex(). >> + // Called with the associated Thread* as the argument. >> + static unsigned __stdcall thread_native_entry(void*); >> + >> enum Ept { EPT_THREAD, EPT_PROCESS, EPT_PROCESS_DIE }; >> // Wrapper around _endthreadex(), exit() and _exit() >> static int exit_process_or_thread(Ept what, int exit_code); > > The issue with that would be that thread_native_entry is declared as static to the compilation unit on other other Operating Systems as well, and having it as a static member on the win32 class instead would end up breaking this convention, for which I'm not sure if there's a reason why all of them are declared like this The thread entry functions are expected to be plain C functions as we use C library calls to create threads (`_beginthreadex`, `pthread_create`) not C++. They don't need to be visible outside the compilation unit hence static. ------------- PR: https://git.openjdk.org/jdk/pull/11081 From jwaters at openjdk.org Wed Nov 30 07:55:24 2022 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 30 Nov 2022 07:55:24 GMT Subject: RFR: 8295146: Clean up native code with newer C/C++ language features [v3] In-Reply-To: <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com> References: <4NLoUD7YZRPKuVc08q_QnsbuPpb0wZIdmAuMN2tqM_c=.a34c13d0-0a6b-495e-b48e-e88debf6b4da@github.com> Message-ID: On Wed, 23 Nov 2022 04:58:38 GMT, Kim Barrett wrote: >> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? I've read through 8250269 briefly and unlike the issues that come with C++ attributes, alignas looks relatively straightforward to switch to, without much effect on existing code. Seems like a bit of a waste to leave the JBS entry sitting on the shelf to me >> >>> The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED. >> >> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing) > >> Out of curiosity, is there a way to get the discussion on approving the use of alignas back up? [...] > > A PR to address JDK-8252584 would be welcomed by me. Just do the process for > Style Guide changes (see the Style Guide or previous PRs for such). I don't > expect it would be very controversial. I think the only reason it hasn't > already happened is because nobody has gotten around to it, or felt the need > for it. > > JDK-8250269 touches a bit more code (mostly in stubGenerator_x86_64 and > macroAssembler_x86_32), but also seems like it should be straightforward. > >> > The various MSVC-conditional direct uses of __declspec(align(N)) should probably currently be using ATTRIBUTE_ALIGNED. >> >> The instances of `__declspec(align())` changed here are in the native libraries written in C, not within HotSpot itself. From what I can see at least HotSpot never uses compiler alignment attributes directly and always strictly sticks to `ATTRIBUTE_ALIGNED` (which is probably a good thing) > > You are right that the Windows-conditionalized uses are in non-HotSpot code. > I missed that context when skimming through the changes. Since Visual Studio > is always C++ (even though the shared files are written as C), using alignas > with appropriate conditionalization in those files should be fine. Resolved, will address re-implementing ATTRIBUTE_ALIGNED with alignas in another Pull Request ------------- PR: https://git.openjdk.org/jdk/pull/11081 From alanb at openjdk.org Wed Nov 30 07:57:15 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 07:57:15 GMT Subject: RFR: 8297784: Optimize @Stable field for Method.isCallerSensitive In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 19:39:02 GMT, Aleksey Shipilev wrote: > [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the `@Stable private Boolean callerSensitive;` cache in `Method`. That field is essentially a tri-state `Boolean` that relies on its `null` value to serve as "not initialized" value for `@Stable`. > > This works well when the holder `Method` instance is constant: JIT compilers fold `@Stable` well. But if such folding fails, we always dereference the full-blown reference to "boxed" `Boolean` from the field on every access. We can instead do a more lean tri-state primitive field to improve that non-optimized case without sacrificing optimized case. > > I chose `byte` and `-1`, `0`, `1` to let the fastpath encode well on most (all?) architectures. > > On adhoc benchmark like: > > > @State(Scope.Thread) > public class WrapperConstness { > static final Method CONST; > static Method NON_CONST; > > static { > try { > CONST = WrapperConstness.class.getDeclaredMethod("target"); > NON_CONST = CONST; > } catch (NoSuchMethodException e) { > throw new RuntimeException(e); > } > } > > public void target() {} > > @Benchmark > public void nonConstant() throws Exception { > NON_CONST.invoke(this); > } > > @Benchmark > public void constant() throws Exception { > CONST.invoke(this); > } > } > > > We have a minor improvement for non-const case, confirmed due to better `isCallerSensitive` access: > > > Benchmark Mode Cnt Score Error Units > > # Baseline > WrapperConstness.constant avgt 25 0.410 ? 0.010 ns/op > WrapperConstness.nonConstant avgt 25 7.283 ? 0.025 ns/op > > # Patched > WrapperConstness.constant avgt 5 0.407 ? 0.008 ns/op > WrapperConstness.nonConstant avgt 5 7.054 ? 0.027 ns/op ; -3% > > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug `java/lang/reflect` > - [ ] Linux x86_64 fastdebug `tier1`, `tier2` Marked as reviewed by alanb (Reviewer). src/java.base/share/classes/java/lang/reflect/Method.java line 612: > 610: // -1 = initialized, not CS > 611: @Stable private byte callerSensitive; > 612: private boolean isCallerSensitive() { A minor nit but a blank line between the declaration and the method would be good here, only to see that the comment is on the field, not the boolean returning method. ------------- PR: https://git.openjdk.org/jdk/pull/11422 From alanb at openjdk.org Wed Nov 30 08:01:21 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 08:01:21 GMT Subject: RFR: JDK-8297298 - SequenceInputStream should override transferTo [v2] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 23:40:58 GMT, Brian Burkhalter wrote: > > > Please take note of the changes proposed in #11403. > > > > > > It might make sense to merge _this_ PR as-is _first_, but then add the needed fix to #11403 afterwards? > > I concur. I will take a look at the test soon. That would be better, as would pushing out #11403 to after the fork for JDK 20 as that change could have a bug tail. ------------- PR: https://git.openjdk.org/jdk/pull/11248 From stefan.johansson at oracle.com Wed Nov 30 08:37:50 2022 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 30 Nov 2022 09:37:50 +0100 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: References: Message-ID: <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com> Hi Carter, Your mail made me pick up an old item from my wishlist: to have native memory tracking information available in JFR recordings. When we, in GC, do improvements to decrease the native memory overhead of our algorithms, NMT is a very good tool to track the progress. We have scripts that sound very similar to what you describe and more than once I've been thinking about adding this information into JFR. But it has not been a priority and the greater value has been unclear. Hearing that others might also benefit from such a change I took a discussion with the JFR team on how to best proceed with this. I have created a branch for this and will probably create a PR for it shortly, but I thought I would drop it here first: https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt The change adds two new JFR events: one for the total usage and one for the usage of each memory type. These are sent only if Native Memory Tracking is turned on, and they are enabled in the default JFR profile with an interval of 1s. This might change during reviewing but it was a good starting point. With this you will be able to use JFR streaming to access the events from within your running process. I hope this will help your use cases and please let us know if you have any comments or suggestions. Thanks, Stefan On 2022-11-10 16:58, Carter Kozak wrote: > /+serviceability-dev/ > > Firstly, thank you both for your time and work in this space. Apologies > if this should be a separate thread, but the new title ?Extend Native > Memory Tracking over the JDK? aligns directly with some work I?ve been > investigating, and I hope my feedback will be helpful for prioritization > of zlib observability as well as the way users think about native memory > tracking in general. > > Observability of native memory in the JVM is critically important, and > becomes even more valuable as the industry shifts to more and smaller > services deployed in right-sized container environments like kubernetes. > Each new JDK release (major and hotfix) offers dramatic improvements, > often based on some form of trade-off. To be clear, I cannot overstate > how impressed I am with quality and velocity of improvement! However, > these trade-offs impact the way that memory is used, and it?s a > difficult balance to ensure containers use the correct amount of memory > without being wasteful (over-provisioned) or oomkilled (under-provisioned). > > In production, I have thousands of JVMs running with native memory > tracking summary enabled. Real-time monitoring of the output is painful > and inefficient. Currently the only supported option I?m aware of is > shelling out to create a new jcmd process and parsing the NMT summary > text output periodically. In older releases, it was possible to bypass > the jcmd process by self-attaching, but that was limited in jdk9 by > JDK-8178380 , and still > required the caller to parse human-readable strings. In fact, attachment > issues in some JDK/environment combinations make automated attachment > /dangerous/ in a way that has crashed the JVM ? that may be a story for > another day, but my point is that simple, efficient NMT data collection > would go a very long way. Many modern observability tools, especially > those used in container deployments, operate by reading data from within > the jvm process, and relaying it to a storage system (Prometheus may be > the most ubiquitous example). > > For my use-case, I?d love to have a simple API I could invoke from java > code to access structured native-memory-tracking data, similar in a way > to MemoryPoolMXBean for heap pools (although JMX isn?t necessary for me, > it aligns with other observability APIs in the JDK). Additionally, I?d > like to provide JFR events to periodically record native memory tracking > metadata when enabled for better out-of-the-box experience with JMC. > I?ve begun investigating some options for JDK-8182634 > , but would appreciate > feedback before I propose any sort of code change. > > Thank you all for beginning this discussion, I?m eager to see the ways > the JDK continues to improve upon observability features, and do what > small part I can to help! > > Carter Kozak From shade at openjdk.org Wed Nov 30 08:43:54 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 30 Nov 2022 08:43:54 GMT Subject: RFR: 8297784: Optimize @Stable field for Method.isCallerSensitive [v2] In-Reply-To: References: Message-ID: > [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the `@Stable private Boolean callerSensitive;` cache in `Method`. That field is essentially a tri-state `Boolean` that relies on its `null` value to serve as "not initialized" value for `@Stable`. > > This works well when the holder `Method` instance is constant: JIT compilers fold `@Stable` well. But if such folding fails, we always dereference the full-blown reference to "boxed" `Boolean` from the field on every access. We can instead do a more lean tri-state primitive field to improve that non-optimized case without sacrificing optimized case. > > I chose `byte` and `-1`, `0`, `1` to let the fastpath encode well on most (all?) architectures. > > On adhoc benchmark like: > > > @State(Scope.Thread) > public class WrapperConstness { > static final Method CONST; > static Method NON_CONST; > > static { > try { > CONST = WrapperConstness.class.getDeclaredMethod("target"); > NON_CONST = CONST; > } catch (NoSuchMethodException e) { > throw new RuntimeException(e); > } > } > > public void target() {} > > @Benchmark > public void nonConstant() throws Exception { > NON_CONST.invoke(this); > } > > @Benchmark > public void constant() throws Exception { > CONST.invoke(this); > } > } > > > We have a minor improvement for non-const case, confirmed due to better `isCallerSensitive` access: > > > Benchmark Mode Cnt Score Error Units > > # Baseline > WrapperConstness.constant avgt 25 0.410 ? 0.010 ns/op > WrapperConstness.nonConstant avgt 25 7.283 ? 0.025 ns/op > > # Patched > WrapperConstness.constant avgt 5 0.407 ? 0.008 ns/op > WrapperConstness.nonConstant avgt 5 7.054 ? 0.027 ns/op ; -3% > > > Additional testing: > - [x] Ad-hoc benchmarks > - [x] Linux x86_64 fastdebug `java/lang/reflect` > - [x] Linux x86_64 fastdebug `tier1`, `tier2` Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Add a newline ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11422/files - new: https://git.openjdk.org/jdk/pull/11422/files/51ccc4b9..be0bb88b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11422&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11422&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11422.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11422/head:pull/11422 PR: https://git.openjdk.org/jdk/pull/11422 From shade at openjdk.org Wed Nov 30 08:43:56 2022 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 30 Nov 2022 08:43:56 GMT Subject: RFR: 8297784: Optimize @Stable field for Method.isCallerSensitive [v2] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 07:54:59 GMT, Alan Bateman wrote: >> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a newline > > src/java.base/share/classes/java/lang/reflect/Method.java line 612: > >> 610: // -1 = initialized, not CS >> 611: @Stable private byte callerSensitive; >> 612: private boolean isCallerSensitive() { > > A minor nit but a blank line between the declaration and the method would be good here, only to see that the comment is on the field, not the boolean returning method. Added. ------------- PR: https://git.openjdk.org/jdk/pull/11422 From alanb at openjdk.org Wed Nov 30 09:01:59 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 09:01:59 GMT Subject: RFR: 8297784: Optimize @Stable field for Method.isCallerSensitive [v2] In-Reply-To: References: Message-ID: <6mC2Ym5V6GwMIQDkP-uazjbD0wfq-K47-5Bi8qjjjD4=.4eedda4c-3d13-4d7e-9ae9-881431502aa3@github.com> On Wed, 30 Nov 2022 08:43:54 GMT, Aleksey Shipilev wrote: >> [JDK-8271820](https://bugs.openjdk.org/browse/JDK-8271820) introduced the `@Stable private Boolean callerSensitive;` cache in `Method`. That field is essentially a tri-state `Boolean` that relies on its `null` value to serve as "not initialized" value for `@Stable`. >> >> This works well when the holder `Method` instance is constant: JIT compilers fold `@Stable` well. But if such folding fails, we always dereference the full-blown reference to "boxed" `Boolean` from the field on every access. We can instead do a more lean tri-state primitive field to improve that non-optimized case without sacrificing optimized case. >> >> I chose `byte` and `-1`, `0`, `1` to let the fastpath encode well on most (all?) architectures. >> >> On adhoc benchmark like: >> >> >> @State(Scope.Thread) >> public class WrapperConstness { >> static final Method CONST; >> static Method NON_CONST; >> >> static { >> try { >> CONST = WrapperConstness.class.getDeclaredMethod("target"); >> NON_CONST = CONST; >> } catch (NoSuchMethodException e) { >> throw new RuntimeException(e); >> } >> } >> >> public void target() {} >> >> @Benchmark >> public void nonConstant() throws Exception { >> NON_CONST.invoke(this); >> } >> >> @Benchmark >> public void constant() throws Exception { >> CONST.invoke(this); >> } >> } >> >> >> We have a minor improvement for non-const case, confirmed due to better `isCallerSensitive` access: >> >> >> Benchmark Mode Cnt Score Error Units >> >> # Baseline >> WrapperConstness.constant avgt 25 0.410 ? 0.010 ns/op >> WrapperConstness.nonConstant avgt 25 7.283 ? 0.025 ns/op >> >> # Patched >> WrapperConstness.constant avgt 5 0.407 ? 0.008 ns/op >> WrapperConstness.nonConstant avgt 5 7.054 ? 0.027 ns/op ; -3% >> >> >> Additional testing: >> - [x] Ad-hoc benchmarks >> - [x] Linux x86_64 fastdebug `java/lang/reflect` >> - [x] Linux x86_64 fastdebug `tier1`, `tier2` > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Add a newline Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11422 From alanb at openjdk.org Wed Nov 30 09:51:26 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 09:51:26 GMT Subject: RFR: 8296710: Update to use jtreg 7.1 In-Reply-To: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com> References: <4t-uTHoUVlflpzDnfuHO7TAnix7nNO1MGF28CJBjZBo=.deb056ac-6571-4c79-a272-680b923d58c5@github.com> Message-ID: <-n11nKKODtr-Mua5vvwmAVEvevjYu2pv3iSzs7tIzzU=.2c8711c8-daab-42b4-a186-4c3f71b4bc73@github.com> On Tue, 29 Nov 2022 14:44:12 GMT, Christian Stein wrote: > Please review the change to update to using jtreg `7.1`. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the requiredVersion has been updated in the various `TEST.ROOT` files. > > This pull request was created by copying the following and using `7.1` at appropriate places: > - https://github.com/openjdk/jdk/pull/9393 Christian has confirmed on the testing so I think this is good. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11416 From rgiulietti at openjdk.org Wed Nov 30 11:07:21 2022 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 30 Nov 2022 11:07:21 GMT Subject: RFR: JDK-8297731: Remove redundant check in MutableBigInteger.divide [v2] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 20:35:00 GMT, Joe Darcy wrote: >> Remove redundant code reported in >> >> https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Remove whitespace. I second Joe's concern: breaking invariants makes reasoning harder for future changes. In my experience, IDEA suggestions are almost always good, but sometimes I stumbled upon the eternal human-versus-mechanical reasoning dilemma. ------------- PR: https://git.openjdk.org/jdk/pull/11395 From mcimadamore at openjdk.org Wed Nov 30 12:30:50 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 30 Nov 2022 12:30:50 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v33] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Polish javadoc: * Make sure that first para of class javadoc is succinct and descriptive * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. * Other minor typos fixes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/6699ad99..5a75118b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=31-32 Stats: 59 lines in 10 files changed: 19 ins; 18 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Wed Nov 30 15:14:26 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 30 Nov 2022 15:14:26 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v34] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/5a75118b..ce85d182 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=32-33 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Wed Nov 30 15:30:40 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 30 Nov 2022 15:30:40 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v35] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 67 additional commits since the last revision: - Merge branch 'master' into PR_20 - Address review comment - Polish javadoc: * Make sure that first para of class javadoc is succinct and descriptive * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. * Other minor typos fixes - Address review comments - * remove unused Scoped interface * re-add trusting of final fields in layout class implementations * Fix BulkOps benchmark, which had alignment issues - Fix bit vs. byte mismatch in test - Fix wrong check in MemorySegment::spliterator/elements (The check which ensures that the segment size is multiple of spliterator element size is bogus) - Address more review comments - Fix bad @throws in MemorySegment::copy methods - Address review comments - ... and 57 more: https://git.openjdk.org/jdk/compare/d0d99ae1...8668fb39 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/ce85d182..8668fb39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=34 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=33-34 Stats: 65983 lines in 1282 files changed: 30320 ins; 21180 del; 14483 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From jvernee at openjdk.org Wed Nov 30 16:08:28 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 30 Nov 2022 16:08:28 GMT Subject: RFR: 8297853: windows-x86 test build broken In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 15:58:17 GMT, Magnus Ihse Bursie wrote: > test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the correct macro definition to compile on 32-bit Windows. test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c line 31: > 29: #include "JNICB.h" > 30: > 31: #if defined(_WIN64) || defined(_WIN32) `_WIN32` is defined on x64 as well [1], so I think this can just be `#ifdef _WIN32` to mean 'Windows' [1]: https://learn.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-170 ------------- PR: https://git.openjdk.org/jdk/pull/11434 From ihse at openjdk.org Wed Nov 30 16:08:26 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 30 Nov 2022 16:08:26 GMT Subject: RFR: 8297853: windows-x86 test build broken Message-ID: test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the correct macro definition to compile on 32-bit Windows. ------------- Commit messages: - 8297853: windows-x86 test build broken Changes: https://git.openjdk.org/jdk/pull/11434/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11434&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297853 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11434.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11434/head:pull/11434 PR: https://git.openjdk.org/jdk/pull/11434 From alanb at openjdk.org Wed Nov 30 16:29:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 16:29:04 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v3] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 19:36:40 GMT, Brian Burkhalter wrote: >> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297632: Add Reader::transferTo and select InputStream::transferTo overrides Can you check ZipInputStream.transferTo? It has a partial copy of a lot of the InputStream javadoc because it has to insert "current ZIP entry" into the text. It's not possible to have a ZIP file larger than Long.MAX_VALUE so there may be nothing to do there but we should check the javadoc. ------------- PR: https://git.openjdk.org/jdk/pull/11403 From alanb at openjdk.org Wed Nov 30 16:41:16 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 16:41:16 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v35] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 67 additional commits since the last revision: > > - Merge branch 'master' into PR_20 > - Address review comment > - Polish javadoc: > * Make sure that first para of class javadoc is succinct and descriptive > * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) > * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. > * Other minor typos fixes > - Address review comments > - * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues > - Fix bit vs. byte mismatch in test > - Fix wrong check in MemorySegment::spliterator/elements > (The check which ensures that the segment size is multiple of spliterator element size is bogus) > - Address more review comments > - Fix bad @throws in MemorySegment::copy methods > - Address review comments > - ... and 57 more: https://git.openjdk.org/jdk/compare/4c9f206a...8668fb39 src/java.base/share/classes/java/nio/channels/FileChannel.java line 1004: > 1002: * Maps a region of this channel's file into a new mapped memory segment, with the given offset, > 1003: * size and memory session. The {@linkplain MemorySegment#address() address} of the returned memory segment > 1004: * is the starting address of the mapped off-heap region backing the segment. Would you mind reflowing this paragraph to that the line lengths are a bit more consistent with the paragraphs that follow? That would also help with side-by-side views when looking at changes. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Wed Nov 30 16:44:42 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 16:44:42 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v35] In-Reply-To: References: Message-ID: <2wV4OEuvJQXQGnRNZ7qhv1PZuMlEYFBqnDgOp5L6D9U=.76a9f864-872a-4c39-a02e-2b0646414571@github.com> On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 67 additional commits since the last revision: > > - Merge branch 'master' into PR_20 > - Address review comment > - Polish javadoc: > * Make sure that first para of class javadoc is succinct and descriptive > * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) > * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. > * Other minor typos fixes > - Address review comments > - * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues > - Fix bit vs. byte mismatch in test > - Fix wrong check in MemorySegment::spliterator/elements > (The check which ensures that the segment size is multiple of spliterator element size is bogus) > - Address more review comments > - Fix bad @throws in MemorySegment::copy methods > - Address review comments > - ... and 57 more: https://git.openjdk.org/jdk/compare/e1da2b11...8668fb39 src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 1: > 1: package java.lang.foreign; This one is missing a header. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From alanb at openjdk.org Wed Nov 30 16:49:00 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 16:49:00 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v35] In-Reply-To: References: Message-ID: <1Ao-HvZlCHoGgLIJSJTXOOnvoR1pRtaZoljYUZpFEv0=.1a93bb09-06aa-4fad-905a-41f5f12b6945@github.com> On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 67 additional commits since the last revision: > > - Merge branch 'master' into PR_20 > - Address review comment > - Polish javadoc: > * Make sure that first para of class javadoc is succinct and descriptive > * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) > * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. > * Other minor typos fixes > - Address review comments > - * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues > - Fix bit vs. byte mismatch in test > - Fix wrong check in MemorySegment::spliterator/elements > (The check which ensures that the segment size is multiple of spliterator element size is bogus) > - Address more review comments > - Fix bad @throws in MemorySegment::copy methods > - Address review comments > - ... and 57 more: https://git.openjdk.org/jdk/compare/3e822e72...8668fb39 src/java.base/share/classes/java/lang/ModuleLayer.java line 313: > 311: * where possible. > 312: * > 313: * @since 20 We usually put the "@since 20" after the params/return/throws. ------------- PR: https://git.openjdk.org/jdk/pull/10872 From darcy at openjdk.org Wed Nov 30 16:54:47 2022 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 30 Nov 2022 16:54:47 GMT Subject: Integrated: JDK-8297731: Remove redundant check in MutableBigInteger.divide In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 18:58:29 GMT, Joe Darcy wrote: > Remove redundant code reported in > > https://mail.openjdk.org/pipermail/core-libs-dev/2022-November/097163.html This pull request has now been integrated. Changeset: c6855691 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/c68556916ae7cc0301f3c89c05148547dcb44278 Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod 8297731: Remove redundant check in MutableBigInteger.divide Reviewed-by: bpb ------------- PR: https://git.openjdk.org/jdk/pull/11395 From alanb at openjdk.org Wed Nov 30 16:56:56 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 16:56:56 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v35] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 67 additional commits since the last revision: > > - Merge branch 'master' into PR_20 > - Address review comment > - Polish javadoc: > * Make sure that first para of class javadoc is succinct and descriptive > * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) > * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. > * Other minor typos fixes > - Address review comments > - * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues > - Fix bit vs. byte mismatch in test > - Fix wrong check in MemorySegment::spliterator/elements > (The check which ensures that the segment size is multiple of spliterator element size is bogus) > - Address more review comments > - Fix bad @throws in MemorySegment::copy methods > - Address review comments > - ... and 57 more: https://git.openjdk.org/jdk/compare/9a07ecac...8668fb39 src/java.base/share/classes/java/lang/foreign/SegmentScope.java line 69: > 67: * Creates a new scope that is managed, automatically, by the garbage collector. > 68: * Segments associated with the returned scope can be > 69: * {@linkplain SegmentScope#isAccessibleBy(Thread) accessed} by multiple threads. "can be accessed by multiple threads" hints a bit of concurrency. It might be clearer to say "by any thread". ------------- PR: https://git.openjdk.org/jdk/pull/10872 From naoto at openjdk.org Wed Nov 30 17:03:57 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 30 Nov 2022 17:03:57 GMT Subject: RFR: 8295803: Console should be usable in jshell and other environments Message-ID: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted. ------------- Commit messages: - Minor fixup - GetPropertyAction.privilegedGetProperty - Changed to use SharedSecrets - Password.readPassword() fix - Always returns Console, even without TTY attached - Comments refresh, clean-up - Removed charset from factory, added new jdk.console property - Revived the provider i/f - Replacing SPI with proxy delegate - javadoc - ... and 3 more: https://git.openjdk.org/jdk/compare/ae5b1f76...96a46843 Changes: https://git.openjdk.org/jdk/pull/11421/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8295803 Stats: 387 lines in 10 files changed: 373 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/11421.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421 PR: https://git.openjdk.org/jdk/pull/11421 From alanb at openjdk.org Wed Nov 30 17:08:13 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 17:08:13 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v35] In-Reply-To: References: Message-ID: <9lmq8wD3c1YD4s0NGrHQXV6CgVJyJ9S42xUmx1FzXJ0=.2f64ed69-a54d-4517-ae29-1539f06cffe0@github.com> On Wed, 30 Nov 2022 15:30:40 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 67 additional commits since the last revision: > > - Merge branch 'master' into PR_20 > - Address review comment > - Polish javadoc: > * Make sure that first para of class javadoc is succinct and descriptive > * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) > * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. > * Other minor typos fixes > - Address review comments > - * remove unused Scoped interface > * re-add trusting of final fields in layout class implementations > * Fix BulkOps benchmark, which had alignment issues > - Fix bit vs. byte mismatch in test > - Fix wrong check in MemorySegment::spliterator/elements > (The check which ensures that the segment size is multiple of spliterator element size is bogus) > - Address more review comments > - Fix bad @throws in MemorySegment::copy methods > - Address review comments > - ... and 57 more: https://git.openjdk.org/jdk/compare/ddc274f3...8668fb39 src/java.base/share/classes/java/lang/foreign/Arena.java line 135: > 133: * @apiNote This operation is not idempotent; that is, closing an already closed arena always results in an > 134: * exception being thrown. This reflects a deliberate design choice: arena state transitions should be > 135: * manifest in the client code; a failure in any of these transitions reveals a bug in the underlying application Not important but I'm not sure about the wording here. Maybe you mean "manifested" or "should manifest" ? src/java.base/share/classes/java/lang/foreign/Arena.java line 155: > 153: > 154: /** > 155: * {@return a new confined arena} For completeness, this should probably say "a new confined arena owned by the current thread". ------------- PR: https://git.openjdk.org/jdk/pull/10872 From ihse at openjdk.org Wed Nov 30 17:12:46 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 30 Nov 2022 17:12:46 GMT Subject: RFR: 8297853: windows-x86 test build broken [v2] In-Reply-To: References: Message-ID: <3SFGkGVJ5iYl5nh1vBmKb6fXQ_DZ5lvU5D88bg4iZxI=.e6851472-bd56-4222-89ed-46905d9d7d73@github.com> > test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the correct macro definition to compile on 32-bit Windows. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Use only _WIN32 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11434/files - new: https://git.openjdk.org/jdk/pull/11434/files/b3cb7e71..7e956dec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11434&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11434&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11434.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11434/head:pull/11434 PR: https://git.openjdk.org/jdk/pull/11434 From jvernee at openjdk.org Wed Nov 30 17:12:47 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 30 Nov 2022 17:12:47 GMT Subject: RFR: 8297853: windows-x86 test build broken [v2] In-Reply-To: <3SFGkGVJ5iYl5nh1vBmKb6fXQ_DZ5lvU5D88bg4iZxI=.e6851472-bd56-4222-89ed-46905d9d7d73@github.com> References: <3SFGkGVJ5iYl5nh1vBmKb6fXQ_DZ5lvU5D88bg4iZxI=.e6851472-bd56-4222-89ed-46905d9d7d73@github.com> Message-ID: On Wed, 30 Nov 2022 17:08:36 GMT, Magnus Ihse Bursie wrote: >> test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the correct macro definition to compile on 32-bit Windows. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Use only _WIN32 Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11434 From jlaskey at openjdk.org Wed Nov 30 17:17:09 2022 From: jlaskey at openjdk.org (Jim Laskey) Date: Wed, 30 Nov 2022 17:17:09 GMT Subject: RFR: 8295803: Console should be usable in jshell and other environments In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com> References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com> Message-ID: On Tue, 29 Nov 2022 19:38:02 GMT, Naoto Sato wrote: > This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted. Looks good otherwise. Add tests. src/java.base/share/classes/java/io/Console.java line 617: > 615: > 616: public Charset charset() { > 617: return cons.charset(); What happens when cons is null? ------------- PR: https://git.openjdk.org/jdk/pull/11421 From pminborg at openjdk.org Wed Nov 30 17:34:50 2022 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 30 Nov 2022 17:34:50 GMT Subject: RFR: 8296024: Usage of DIrectBuffer::address should be guarded [v17] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 09:40:58 GMT, Per Minborg wrote: >> This PR proposes the introduction of **guarding** of the use of `DirectBuffer::address` within the JDK. With the introduction of the Foreign Function and Memory access, it is possible to derive Buffer instances that are backed by native memory that, in turn, can be closed asynchronously by the user (and not only via a `Cleaner` when there is no other reference to the `Buffer` object). If another thread is invoking `MemorySession::close` while a thread is doing work using raw addresses, the outcome is undefined. This means the JVM might crash or even worse, silent modification of unrelated memory might occur. >> >> Design choices in this PR: >> >> There is already a method `MemorySession::whileAlive` that takes a runnable and that will perform the provided action while acquiring the underlying` MemorySession` (if any). However, using this method entailed relatively large changes while converting larger/nested code segments into lambdas. This would also risk introducing lambda capturing. So, instead, a ~~try-with-resources~~ *try-finally* friendly access method was added. This made is more easy to add guarding and did not risk lambda capturing. Also, introducing lambdas in certain fundamental JDK classes might incur bootstrap problems. >> >> The aforementioned ~~TwR~~ TF is using a ~~"session acquisition" that is not used explicitly in the try block itself~~ session used in the *finally* block. ~~This raises a warning that is suppressed using `@SuppressWarnings("try")`. In the future, we might be able to remove these suppressions by using the reserved variable name `_`.~~ >> >> In some cases, where is is guaranteed that the backing memory session is non-closeable, we do not have to guard the use of `DirectBuffer::address`. ~~These cases have been documented in the code.~~ >> >> On some occasions, a plurality of acquisitions are made. This would never lead to deadlocks as acquisitions are fundamentally concurrent counters and not resources that only one thread can "own". >> >> I have added comments (and not javadocs) before the declaration of the non-public-api `DirectBuffer::address` method, that the use of the returned address needs to be guarded. It can be discussed if this is preferable or not. >> >> This PR spawns several areas of responsibility and so, I expect more than one reviewer before promoting the PR. > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Remove session exposure I've converted this PR to a draft because we want to wait for the PR_20 branch being merged [JEP 434](https://openjdk.org/jeps/434) ------------- PR: https://git.openjdk.org/jdk/pull/11260 From bpb at openjdk.org Wed Nov 30 17:35:48 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 30 Nov 2022 17:35:48 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v3] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 16:26:59 GMT, Alan Bateman wrote: > Can you check ZipInputStream.transferTo? That implementation just calls the overridden method, but the single sentence added to the `InputStream::transferTo` javadoc should probably be inserted here as well. Do you concur? ------------- PR: https://git.openjdk.org/jdk/pull/11403 From lancea at openjdk.org Wed Nov 30 18:10:22 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 30 Nov 2022 18:10:22 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v3] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 17:33:17 GMT, Brian Burkhalter wrote: > > Can you check ZipInputStream.transferTo? > > That implementation just calls the overridden method, but the single sentence added to the `InputStream::transferTo` javadoc should probably be inserted here as well. Do you concur? I believe that makes sense ------------- PR: https://git.openjdk.org/jdk/pull/11403 From mcimadamore at openjdk.org Wed Nov 30 18:14:00 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 30 Nov 2022 18:14:00 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v36] In-Reply-To: References: Message-ID: <1oR6S6K1w-GPz7Mw67Sqw9s8mPI4YDyC9_FOOjIqJU4=.9e645539-2bba-4740-be1e-e61493a3252f@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/8668fb39..df8a4a63 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=35 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=34-35 Stats: 34 lines in 3 files changed: 29 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From andrew at openjdk.org Wed Nov 30 18:15:29 2022 From: andrew at openjdk.org (Andrew John Hughes) Date: Wed, 30 Nov 2022 18:15:29 GMT Subject: RFR: 8297804: (tz) Update Timezone Data to 2022g Message-ID: <4b1tG73Xp3BMUy2X6Ab7W2So7u4jcSu9SrAWvrHLw1g=.d6218261-7f4e-48c5-9989-eb0887e0207e@github.com> Update to the latest tzdata, 2022g. Primary changes: * `America/Ojinaga` (CST) is split, creating `America/Ciudad_Juarez` (MST/MDT) * `America/Pangnirtung` becomes a link to `America/Iqaluit` * `America/Ojinaga` gains DST (CDT) See bug for the full details. There will likely also be CLDR changes ([CLDR-16181](https://unicode-org.atlassian.net/browse/CLDR-16181)) that are not yet included in this change. We can either wait for these and include them in this patch, or do a separate change like [JDK-8296715](https://bugs.openjdk.org/browse/JDK-8296715) Tests in `java/util/TimeZone`, `java/time/test` and `sun/text/resources` all pass. ------------- Commit messages: - 8297804: (tz) Update Timezone Data to 2022g Changes: https://git.openjdk.org/jdk/pull/11438/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11438&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297804 Stats: 217 lines in 21 files changed: 125 ins; 56 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/11438.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11438/head:pull/11438 PR: https://git.openjdk.org/jdk/pull/11438 From stsypanov at openjdk.org Wed Nov 30 18:17:47 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 30 Nov 2022 18:17:47 GMT Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints() [v2] In-Reply-To: References: Message-ID: > `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`. Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into JDK-8297561 - 8297561: Add benchmark - 8297561: Redundant index check in String.offsetByCodePoints() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11350/files - new: https://git.openjdk.org/jdk/pull/11350/files/9b844f35..1fdc0197 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11350&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11350&range=00-01 Stats: 13546 lines in 539 files changed: 9038 ins; 2549 del; 1959 mod Patch: https://git.openjdk.org/jdk/pull/11350.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11350/head:pull/11350 PR: https://git.openjdk.org/jdk/pull/11350 From stsypanov at openjdk.org Wed Nov 30 18:19:53 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Wed, 30 Nov 2022 18:19:53 GMT Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints() In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 10:08:31 GMT, Sergey Tsypanov wrote: > `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`. I've added a benchmark for the changes, on my machine it gives the following results: baseline Benchmark Mode Cnt Score Error Units StringOffsetByCodePoints.offsetByCodePoints avgt 30 6.616 ? 0.040 ns/op patch Benchmark Mode Cnt Score Error Units StringOffsetByCodePoints.offsetByCodePoints avgt 30 6.606 ? 0.008 ns/op ------------- PR: https://git.openjdk.org/jdk/pull/11350 From rriggs at openjdk.org Wed Nov 30 18:45:56 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 30 Nov 2022 18:45:56 GMT Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints() [v2] In-Reply-To: References: Message-ID: <60_c0vMcmcYp_9DhOy-j3UIfF-jWfbEUAJUdxT3iCcQ=.2c97e71f-c459-45af-bb85-61267ca20133@github.com> On Wed, 30 Nov 2022 18:17:47 GMT, Sergey Tsypanov wrote: >> `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`. > > Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8297561 > - 8297561: Add benchmark > - 8297561: Redundant index check in String.offsetByCodePoints() LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11350 From naoto at openjdk.org Wed Nov 30 18:49:02 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 30 Nov 2022 18:49:02 GMT Subject: RFR: 8295803: Console should be usable in jshell and other environments In-Reply-To: References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com> Message-ID: <7WZIOj2VKO3XArhieDZXxG_YQgQCHtjyNRuRtAbfxHs=.490ebf81-101f-4a91-8b87-f1c82f07e5f1@github.com> On Wed, 30 Nov 2022 17:07:35 GMT, Jim Laskey wrote: >> This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted. > > src/java.base/share/classes/java/io/Console.java line 617: > >> 615: >> 616: public Charset charset() { >> 617: return cons.charset(); > > What happens when cons is null? Turned out that `JavaIOAccess.charset()` is not used anywhere. Will remove this method. Will also add a test. ------------- PR: https://git.openjdk.org/jdk/pull/11421 From jvernee at openjdk.org Wed Nov 30 18:51:20 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 30 Nov 2022 18:51:20 GMT Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip still deserves clarification Message-ID: A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior. ------------- Commit messages: - Clarify spec Changes: https://git.openjdk.org/jdk/pull/11440/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11440&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291359 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11440.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11440/head:pull/11440 PR: https://git.openjdk.org/jdk/pull/11440 From jvernee at openjdk.org Wed Nov 30 18:54:49 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 30 Nov 2022 18:54:49 GMT Subject: RFR: 8291359: Specification of method j.l.foreign.VaList::skip still deserves clarification [v2] In-Reply-To: References: Message-ID: > A small clarification of the VaList spec to say that attempts to access elements through an incorrect memory layout result in undefined behavior. Jorn Vernee has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Clarify spec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11440/files - new: https://git.openjdk.org/jdk/pull/11440/files/4ec1cf54..79590943 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11440&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11440&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11440.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11440/head:pull/11440 PR: https://git.openjdk.org/jdk/pull/11440 From cushon at openjdk.org Wed Nov 30 18:57:48 2022 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 30 Nov 2022 18:57:48 GMT Subject: RFR: 8297875: jar should not compress the manifest directory entry Message-ID: This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations. ------------- Commit messages: - 8297875: jar should not compress the manifest directory entry Changes: https://git.openjdk.org/jdk/pull/11441/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11441&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297875 Stats: 87 lines in 2 files changed: 87 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11441.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11441/head:pull/11441 PR: https://git.openjdk.org/jdk/pull/11441 From ihse at openjdk.org Wed Nov 30 19:04:34 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 30 Nov 2022 19:04:34 GMT Subject: Integrated: 8297853: windows-x86 test build broken In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 15:58:17 GMT, Magnus Ihse Bursie wrote: > test/micro/org/openjdk/bench/java/lang/foreign/libQSortJNI.c is missing the correct macro definition to compile on 32-bit Windows. This pull request has now been integrated. Changeset: 6bac3323 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/6bac332371d4c0a8cdf31b6603f8cbb6d2490f65 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8297853: windows-x86 test build broken Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/11434 From jvernee at openjdk.org Wed Nov 30 20:02:46 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 30 Nov 2022 20:02:46 GMT Subject: Integrated: 8297736: test/jdk/java/foreign/TestMatrix.java is broken In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 21:03:33 GMT, Jorn Vernee wrote: > - Fix tests that try to run `TestDowncall` which was split into TestDowncallScope and TestDowncallStack > - Fix use of obsolete system properties to control specilization > - Add test to run TestVarArgs in un-sampled mode. > > Testing: Manual runs of TestMatrix.java (it's a manual test) on Windows and Linux (WSL). This pull request has now been integrated. Changeset: 1a2ff587 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/1a2ff58761d755c2330dec46e3eb53bc6d9a9839 Stats: 74 lines in 1 file changed: 33 ins; 0 del; 41 mod 8297736: test/jdk/java/foreign/TestMatrix.java is broken 8291642: java/foreign/TestMatrix.java -few tests are failing due to JDK-8287158. Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/11398 From jvernee at openjdk.org Wed Nov 30 20:03:51 2022 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 30 Nov 2022 20:03:51 GMT Subject: Integrated: 8290231: java/foreign/malloc/TestMixedMallocFree.java crashed in JDK19 ATR run In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 15:40:53 GMT, Jorn Vernee wrote: > This test allocates on the native side with `malloc`, and then tries to free that memory on the Java side. The library that we look up on the Java side is either ucrtbase.dll, or msvcrt.dll as a fallback if we don't find it. The fact that we're seeing this crash likely means that the test machine doesn't have ucrtbase.dll, but it does have a newer standard runtime library other than msvcrt.dll (one of the msvcp*.dll libraries). > > So, what can happen is: the native code in the test ends up being linked against this newer runtime library. We allocate using the newer runtime library's `malloc` function. Look up `free` from Java, don't find ucrtbase.dll so fall back to msvcrt.dll. Call `free` from msvcrt.dll which is not the right one, and then crash due to the allocator mismatch. > > --- > > I think we should just remove this test. In practice, we can not guarantee that native code is linked against the same dll as the one we pick to be the default library (for instance, the native code could have been linked against an older dll, even while ucrtbase.dll is present on the system). > > Trying to mach up the 2 libraries was important when we had public `allocateMemory` and `freeMemory` functions, but those were removed from the API. > > Using matching allocate & free pairs, which some of the other tests do, still works. This pull request has now been integrated. Changeset: 1722f9cc Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/1722f9cce346563923fcebd92b32ea2cb30ea744 Stats: 101 lines in 2 files changed: 0 ins; 101 del; 0 mod 8290231: java/foreign/malloc/TestMixedMallocFree.java crashed in JDK19 ATR run Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/11417 From alanb at openjdk.org Wed Nov 30 20:35:29 2022 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 30 Nov 2022 20:35:29 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v36] In-Reply-To: <1oR6S6K1w-GPz7Mw67Sqw9s8mPI4YDyC9_FOOjIqJU4=.9e645539-2bba-4740-be1e-e61493a3252f@github.com> References: <1oR6S6K1w-GPz7Mw67Sqw9s8mPI4YDyC9_FOOjIqJU4=.9e645539-2bba-4740-be1e-e61493a3252f@github.com> Message-ID: On Wed, 30 Nov 2022 18:14:00 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10872 From naoto at openjdk.org Wed Nov 30 20:44:30 2022 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 30 Nov 2022 20:44:30 GMT Subject: RFR: 8295803: Console should be usable in jshell and other environments [v2] In-Reply-To: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com> References: <3BXfYlvsf5BCYvPO9ostFbkgdCEQIwcvJoCYeMQW81I=.839afe33-229e-4ca7-bc98-8f9687d9dba5@github.com> Message-ID: > This is to allow Console to be used even when it is not attached to the platform provided terminal, such as the case when the standard input is redirected. `System.console()` now returns a Console implementation based on `jdk.internal.le` terminal by default, or jshell implementation if available. A corresponding CSR has been drafted. Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: - Adds a test - Removed JavaIOAccess.charset() which is no longer needed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11421/files - new: https://git.openjdk.org/jdk/pull/11421/files/96a46843..3d2b01f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11421&range=00-01 Stats: 70 lines in 4 files changed: 64 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11421.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11421/head:pull/11421 PR: https://git.openjdk.org/jdk/pull/11421 From ckozak at ckozak.net Wed Nov 30 20:43:39 2022 From: ckozak at ckozak.net (Carter Kozak) Date: Wed, 30 Nov 2022 15:43:39 -0500 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com> References: <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com> Message-ID: This looks fantastic, thank you so much! I can confirm that the proposed design would solve my use-case. I'd enjoy discussing the NMT event contract somewhere more specific to the implementation, but I don't want to muddle this thread with implementation details. Carter Kozak On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote: > Hi Carter, > > Your mail made me pick up an old item from my wishlist: to have native > memory tracking information available in JFR recordings. When we, in GC, > do improvements to decrease the native memory overhead of our > algorithms, NMT is a very good tool to track the progress. We have > scripts that sound very similar to what you describe and more than once > I've been thinking about adding this information into JFR. But it has > not been a priority and the greater value has been unclear. > > Hearing that others might also benefit from such a change I took a > discussion with the JFR team on how to best proceed with this. I have > created a branch for this and will probably create a PR for it shortly, > but I thought I would drop it here first: > https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt > > The change adds two new JFR events: one for the total usage and one for > the usage of each memory type. These are sent only if Native Memory > Tracking is turned on, and they are enabled in the default JFR profile > with an interval of 1s. This might change during reviewing but it was a > good starting point. > > With this you will be able to use JFR streaming to access the events > from within your running process. I hope this will help your use cases > and please let us know if you have any comments or suggestions. > > Thanks, > Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From redestad at openjdk.org Wed Nov 30 20:47:18 2022 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 30 Nov 2022 20:47:18 GMT Subject: RFR: 8297561: Redundant index check in String.offsetByCodePoints() [v2] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 18:17:47 GMT, Sergey Tsypanov wrote: >> `String.offsetByCodePoints()` delegates to `Character.offsetByCodePoints()` which in turn specifies the same exception thrown under the same conditions and the implementation does exactly the same checks. This means we can remove the check from `String.offsetByCodePoints()` and rely on the one of `Character.offsetByCodePoints()`. > > Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into JDK-8297561 > - 8297561: Add benchmark > - 8297561: Redundant index check in String.offsetByCodePoints() Changes requested by redestad (Reviewer). test/micro/org/openjdk/bench/java/lang/StringOffsetByCodePoints.java line 1: > 1: package org.openjdk.bench.java.lang; Missing copyright header test/micro/org/openjdk/bench/java/lang/StringOffsetByCodePoints.java line 9: > 7: @BenchmarkMode(Mode.AverageTime) > 8: @OutputTimeUnit(TimeUnit.NANOSECONDS) > 9: @Warmup(iterations = 10, time = 1000, timeUnit = TimeUnit.MILLISECONDS) For non-allocating microbenchmarks we usually get by with about 5 iterations of 1 second and same for warmup to produce stable results. Keeping runtime low ensures we can keep adding coverage to more APIs without incurring undue overhead ------------- PR: https://git.openjdk.org/jdk/pull/11350 From bpb at openjdk.org Wed Nov 30 20:48:12 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 30 Nov 2022 20:48:12 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v4] In-Reply-To: References: Message-ID: > `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8297632: Add verbiage to ZipInputStream::transferTo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11403/files - new: https://git.openjdk.org/jdk/pull/11403/files/67516279..558cbc8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11403&range=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11403.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11403/head:pull/11403 PR: https://git.openjdk.org/jdk/pull/11403 From redestad at openjdk.org Wed Nov 30 20:54:28 2022 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 30 Nov 2022 20:54:28 GMT Subject: RFR: 8297728: Cache invocation type rather than invoker in NamedFunction In-Reply-To: References: Message-ID: <1uIJ6OichzuPfIJVV1hPB5md5vRUY-goEbldWflhJuM=.7ecc9a13-79cf-443d-9e2a-4392b9decd22@github.com> On Tue, 29 Nov 2022 21:57:09 GMT, Claes Redestad wrote: > `java.lang.invoke.LambdaForm.NamedFunction` has an `invoker` field acting as a cache, but this field is only used for lambda form interpretation, thus not very performance sensitive. > > Since the invoker is already cached in the method type hierarchy we could replace it with a cache of the invocation type instead. This means cost to retrieve an invoker for lambda form interpretation is only slightly affected (a few ns/op that end up in the noise since interpretation already incur a >50ns/op overhead on even the simplest forms), while speeding up bytecode generation for `LF`s with `NamedFunction`s not holding a resolvedHandle. > > Being lazy about the creation of the type is not significantly beneficial right now, but is done in anticipation of future changes that may better defer bytecode spinning for `LambdaForm`s. Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11424 From redestad at openjdk.org Wed Nov 30 20:58:34 2022 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 30 Nov 2022 20:58:34 GMT Subject: Integrated: 8297728: Cache invocation type rather than invoker in NamedFunction In-Reply-To: References: Message-ID: <7Ddfh6PKntUrgQJxwUykiN8Fy58Yu2NNZEYYzs2FtNs=.6b6636d8-3272-4fb3-92f7-8b1db8a62542@github.com> On Tue, 29 Nov 2022 21:57:09 GMT, Claes Redestad wrote: > `java.lang.invoke.LambdaForm.NamedFunction` has an `invoker` field acting as a cache, but this field is only used for lambda form interpretation, thus not very performance sensitive. > > Since the invoker is already cached in the method type hierarchy we could replace it with a cache of the invocation type instead. This means cost to retrieve an invoker for lambda form interpretation is only slightly affected (a few ns/op that end up in the noise since interpretation already incur a >50ns/op overhead on even the simplest forms), while speeding up bytecode generation for `LF`s with `NamedFunction`s not holding a resolvedHandle. > > Being lazy about the creation of the type is not significantly beneficial right now, but is done in anticipation of future changes that may better defer bytecode spinning for `LambdaForm`s. This pull request has now been integrated. Changeset: 4485d4e5 Author: Claes Redestad URL: https://git.openjdk.org/jdk/commit/4485d4e517b6dece7a9eeb5cf9a2180d84956da3 Stats: 19 lines in 1 file changed: 9 ins; 6 del; 4 mod 8297728: Cache invocation type rather than invoker in NamedFunction Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/11424 From dlong at openjdk.org Wed Nov 30 21:39:20 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 30 Nov 2022 21:39:20 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v33] In-Reply-To: References: Message-ID: <_Gn9ItyEwKzyhunfxC5b6wz7BZzPg2qD_e-wvhEqR-Q=.5be37213-7be9-40c7-8503-392bacc1cfa9@github.com> On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Unused variable src/hotspot/cpu/aarch64/aarch64.ad line 3635: > 3633: } > 3634: } else if (_method->intrinsic_id() == vmIntrinsicID::_ensureMaterializedForStackWalk) { > 3635: __ nop(); Please add a comment explaining why the nop is needed or desirable here. src/hotspot/cpu/x86/x86_64.ad line 2174: > 2172: RELOC_DISP32); > 2173: } else if (_method->intrinsic_id() == vmIntrinsicID::_ensureMaterializedForStackWalk) { > 2174: __ addr_nop_5(); Needs a comment. I guess this is because of how call sizes are computed. ------------- PR: https://git.openjdk.org/jdk/pull/10952 From dlong at openjdk.org Wed Nov 30 21:43:13 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 30 Nov 2022 21:43:13 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v33] In-Reply-To: References: Message-ID: <00vRbThlo7WIZeqbqMNYNYQKiBH2aFP0O5d-swCOvtY=.f02f4b5a-fb86-4861-affd-000438b83b47@github.com> On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Unused variable src/hotspot/share/classfile/javaClasses.cpp line 1731: > 1729: } > 1730: > 1731: void java_lang_Thread::clear_scopedValueBindings(oop java_thread) { It looks like there is only one caller of this method that takes an oop. Would it make sense to have the caller check for the null oop, and assert that the oop is not null here? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From lancea at openjdk.org Wed Nov 30 21:48:35 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 30 Nov 2022 21:48:35 GMT Subject: RFR: 8297875: jar should not compress the manifest directory entry In-Reply-To: References: Message-ID: <99rKynYUWs5Xu5RvmKquhYqGCDfRtKv3Uc4IWB-pRMA=.59d110d3-401d-43f9-b95e-de8a3198c669@github.com> On Wed, 30 Nov 2022 18:48:30 GMT, Liam Miller-Cushon wrote: > This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations. I don't necessarily see anything wrong with the change. This code dates back to at least JDK 1.2.1. I am not sure their is an actual issue based on my read of the APP.NOTE and a quick look at the generated bytes, but I also do not see any harm with the change as to your point this is done for other directories via the jar tool as well as other zip tools such as info zip The test does not check to see if the method is stored. I would also consider converting the test to TestNG as you can leverage its assertXXX methods and remove the need for the doTest() method ------------- PR: https://git.openjdk.org/jdk/pull/11441 From dlong at openjdk.org Wed Nov 30 21:51:25 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 30 Nov 2022 21:51:25 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v33] In-Reply-To: References: Message-ID: On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Unused variable src/hotspot/share/prims/jvm.cpp line 1385: > 1383: vframeStream vfst(thread); > 1384: for(; !vfst.at_end(); vfst.next()) { > 1385: int loc = 0; Use -1 instead (see below)? src/hotspot/share/prims/jvm.cpp line 1400: > 1398: } > 1399: > 1400: if (loc != 0) { As 0 is normally a valid local number, how about using -1 to mean "not found"? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From dlong at openjdk.org Wed Nov 30 21:56:43 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 30 Nov 2022 21:56:43 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v33] In-Reply-To: References: Message-ID: <7w-QaPG38IyBYlx7Y92glF_u0ze0N5hP_TWS1HSFuVo=.d22eefc4-b13c-44f1-a031-d5d555bec396@github.com> On Thu, 24 Nov 2022 14:05:41 GMT, Andrew Haley wrote: >> JEP 429 implementation. > > Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: > > Unused variable I made a few minor suggestions, but overall the HotSpot changes look good. Nice job Andrew. ------------- Marked as reviewed by dlong (Reviewer). PR: https://git.openjdk.org/jdk/pull/10952 From mcimadamore at openjdk.org Wed Nov 30 21:56:51 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 30 Nov 2022 21:56:51 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v37] In-Reply-To: References: Message-ID: <60l3vr69yRpaCUeht5gNEVsf7ODpvdqFHpHdjxnfkAo=.a9b6e1de-4f38-4cf2-a840-e5cb249c522c@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/df8a4a63..198f30c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=36 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=35-36 Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From lancea at openjdk.org Wed Nov 30 21:59:40 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 30 Nov 2022 21:59:40 GMT Subject: RFR: 8297632: InputStream.transferTo() method should specify what the return value should be when the number of bytes transfered is larger than Long.MAX_VALUE [v4] In-Reply-To: References: Message-ID: <2IRvbgl9d6ReX5gtz4nAowNhl64lHQOvgAJE4ew1hzg=.8c8194c4-3a09-4512-bc02-063c8747213e@github.com> On Wed, 30 Nov 2022 20:48:12 GMT, Brian Burkhalter wrote: >> `java.io.InputStream::transferTo` could conceivably return a negative value if the count of bytes transferred overflows a `long`. Modify the method to limit the number of bytes transferred to `Long.MAX_VALUE` per invocation. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8297632: Add verbiage to ZipInputStream::transferTo Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11403 From cushon at openjdk.org Wed Nov 30 22:05:46 2022 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 30 Nov 2022 22:05:46 GMT Subject: RFR: 8297875: jar should not compress the manifest directory entry In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 18:48:30 GMT, Liam Miller-Cushon wrote: > This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations. Thanks for the review! > I am not sure their is an actual issue based on my read of the APP.NOTE and a quick look at the generated bytes, but I also do not see any harm with the change as to your point this is done for other directories via the jar tool as well as other zip tools such as info zip I agree APP.NOTE isn't completely clear on this. I think "directories ... must not include file data" could be read as saying that the uncompressed size must be zero, or that the uncompressed and compressed size should be zero. But I also agree with your summary that seems harmless and is consistent with the handling of other directories. It seems likely to me this was an oversight in the original implementation. > The test does not check to see if the method is stored. Done > I would also consider converting the test to TestNG as you can leverage its assertXXX methods and remove the need for the doTest() method Done ------------- PR: https://git.openjdk.org/jdk/pull/11441 From mcimadamore at openjdk.org Wed Nov 30 22:05:59 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 30 Nov 2022 22:05:59 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v38] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 70 commits: - Merge branch 'master' into PR_20 - Address review comments - Address review comments - Merge branch 'master' into PR_20 - Address review comment - Polish javadoc: * Make sure that first para of class javadoc is succinct and descriptive * Remove references to "access" var handle or "memory segment view" var handle (just use var handle) * Minor tweak to layout classes javadoc - use `@see` in value layouts instead of a dedicated para. * Other minor typos fixes - Address review comments - * remove unused Scoped interface * re-add trusting of final fields in layout class implementations * Fix BulkOps benchmark, which had alignment issues - Fix bit vs. byte mismatch in test - Fix wrong check in MemorySegment::spliterator/elements (The check which ensures that the segment size is multiple of spliterator element size is bogus) - ... and 60 more: https://git.openjdk.org/jdk/compare/4485d4e5...8b5dc0f0 ------------- Changes: https://git.openjdk.org/jdk/pull/10872/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=37 Stats: 13807 lines in 254 files changed: 5780 ins; 4448 del; 3579 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From dlong at openjdk.org Wed Nov 30 22:07:13 2022 From: dlong at openjdk.org (Dean Long) Date: Wed, 30 Nov 2022 22:07:13 GMT Subject: RFR: JDK-8286666: JEP 429: Implementation of Scoped Values (Incubator) [v33] In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 11:49:10 GMT, Andrew Haley wrote: >> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision: >> >> Unused variable > > src/jdk.incubator.concurrent/share/classes/jdk/incubator/concurrent/ScopedValue.java line 385: > >> 383: try { >> 384: JLA.setScopedValueBindings(newSnapshot); >> 385: JLA.ensureMaterializedForStackWalk(newSnapshot); > > Question: is it necessary here to invoke `ensureMaterializedForStackWalk()` It's really only there to prevent the new `Snapshot` from being scalar replaced. But we know that it cannot be scalar replaced, because it really does escape: a pointer to it is stored in the current `Thread`. So should we simply remove the call to `ensureMaterializedForStackWalk()`, on the grounds that it cannot have any effect? It does seem unnecessary here, but I'm not an expert on current and future C2 escape analysis. @vnkozlov, do you agree? ------------- PR: https://git.openjdk.org/jdk/pull/10952 From cushon at openjdk.org Wed Nov 30 22:09:22 2022 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 30 Nov 2022 22:09:22 GMT Subject: RFR: 8297875: jar should not compress the manifest directory entry [v2] In-Reply-To: References: Message-ID: <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com> > This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations. Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Use TestNG, and assert on the compression method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11441/files - new: https://git.openjdk.org/jdk/pull/11441/files/f634b82b..eaab9b03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11441&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11441&range=00-01 Stats: 18 lines in 1 file changed: 9 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11441.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11441/head:pull/11441 PR: https://git.openjdk.org/jdk/pull/11441 From lancea at openjdk.org Wed Nov 30 22:28:35 2022 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 30 Nov 2022 22:28:35 GMT Subject: RFR: 8297875: jar should not compress the manifest directory entry [v2] In-Reply-To: <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com> References: <_l7qaLS0EBSdDCO9lNkmWthX-Hb9ydWpdOVun3WewrQ=.2c203834-717c-4481-bac3-7c668cd4b2fc@github.com> Message-ID: On Wed, 30 Nov 2022 22:09:22 GMT, Liam Miller-Cushon wrote: >> This causes jar to not compress the `META-INF/` directory entry, for consistency with the handling of other directory entries and compliance with `APPNOTE.TXT`, and for compatibility with other zip implementations. > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Use TestNG, and assert on the compression method Thanks for the quick set up updates. a few minor nit comments to make the test feel more TestNG friendly and inline with a few of our other tests. Will approve tomorrow with some of these tweaks and giving time for some others to scan. Thank you again for your contribution, it is appreciated :-) test/jdk/tools/jar/ManifestDirectoryCompression.java line 52: > 50: > 51: /** Remove dirs & files needed for test. */ > 52: private static void cleanup(Path dir) { This can leverage the @afterMethod annotation if the code is reworked slightly to make it more TestNG friendly test/jdk/tools/jar/ManifestDirectoryCompression.java line 60: > 58: } > 59: Files.delete(dir); > 60: } catch (IOException e) { Have the method throw IOException and you do not need the catch block test/jdk/tools/jar/ManifestDirectoryCompression.java line 72: > 70: doTest(topDir.resolve("test.jar"), entry); > 71: } finally { > 72: cleanup(topDir); See comment above regarding cleanup() test/jdk/tools/jar/ManifestDirectoryCompression.java line 83: > 81: try (JarFile jarFile = new JarFile(jar.toFile())) { > 82: ZipEntry zipEntry = jarFile.getEntry("META-INF/"); > 83: assertEquals(zipEntry.getMethod(), ZipEntry.STORED); Probably worth verifying zipEntry is not null so you do not get an NPE ------------- PR: https://git.openjdk.org/jdk/pull/11441