From jrose at openjdk.java.net Tue Mar 1 00:39:05 2022 From: jrose at openjdk.java.net (John R Rose) Date: Tue, 1 Mar 2022 00:39:05 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline In-Reply-To: References: Message-ID: <3gIVQr-hE4zuzNj7zvRvw--Y5YSIn566f5xInWRL1Ys=.bfe31205-36ab-42fb-8c91-607bc0784f42@github.com> On Sat, 19 Feb 2022 05:51:52 GMT, Quan Anh Mai wrote: > Hi, > > `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. > > Should the other `requireNonNull` be `ForceInline` as well? > > Thank you very much. Very simple methods like this are almost always inlined, but I suppose there are depth cutoffs that may cause inlining to fail. Yes, it should always be inlined. The optimizer works hard to track null-ness conditions, and making this call go out of line "breaks the thread of thought" in the optimizer's reasoning about null. Yes, both versions of `O::cNN` should be marked this way; the only difference is in how the exception is constructed. (A similar point goes for index-checking functions, which are also force-inlined so that simple index checks of the form `i*K+L References: Message-ID: On Sat, 19 Feb 2022 05:51:52 GMT, Quan Anh Mai wrote: > Hi, > > `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. > > Should the other `requireNonNull` be `ForceInline` as well? > > Thank you very much. `Objects.requireNonNull` is also used on the critical path of VarHandles, and other places in `j.l.invoke` so I think this is generally beneficial beyond use by the Vector API. ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From forax at univ-mlv.fr Tue Mar 1 01:05:23 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 1 Mar 2022 02:05:23 +0100 (CET) Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline In-Reply-To: References: Message-ID: <1558997258.9492738.1646096723181.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Paul Sandoz" > To: "core-libs-dev" > Sent: Tuesday, March 1, 2022 1:48:02 AM > Subject: Re: RFR: 8282143: Objects.requireNonNull should be ForceInline > On Sat, 19 Feb 2022 05:51:52 GMT, Quan Anh Mai wrote: > >> Hi, >> >> `Objects.requireNonNull` may fail to be inlined. The call is expensive and may >> lead to objects escaping to the heap while the null check is cheap and is often >> elided. I have observed this when using the vector API when a call to >> `Objects.requireNonNull` leads to vectors being materialised in a hot loop. >> >> Should the other `requireNonNull` be `ForceInline` as well? >> >> Thank you very much. > > `Objects.requireNonNull` is also used on the critical path of VarHandles, and > other places in `j.l.invoke` so I think this is generally beneficial beyond use > by the Vector API. It is also use by javac when the JLS requires to emit a nullcheck, like for example when creating a method reference. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7543 From duke at openjdk.java.net Tue Mar 1 01:37:08 2022 From: duke at openjdk.java.net (liach) Date: Tue, 1 Mar 2022 01:37:08 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v11] In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 18:49:59 GMT, ExE Boss wrote: >> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: >> >> Update javadoc > > src/java.base/share/classes/java/util/Random.java line 93: > >> 91: >> 92: @SuppressWarnings("serial") >> 93: private static class RandomWrapper extends Random implements RandomGenerator { > > This?class should?also override?all the?default?methods in?`RandomGenerator` and?forward?them to?`this.generator`. The method overridden in this class are exactly those present in `RandomGenerator` itself, which are also the API methods of `Random`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Tue Mar 1 01:44:44 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Tue, 1 Mar 2022 01:44:44 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v12] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: fix wrong identation Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/60c1e382..0e48edf6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From joehw at openjdk.java.net Tue Mar 1 01:51:04 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 1 Mar 2022 01:51:04 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Message-ID: On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted. Was the following assessment in the bug report correct? "the symbol F in java.time.DateTimeFormatter is no use in any pattern. It just may cause an exception." If true, then it seems the compatibility risk would be low since pattern letter "F" as is currently defined is of no use. Also, the CSR summary needs to be a summary of the action to be taken, that is, changing the pattern definition. The current statement is similar to the problem statement. ------------- PR: https://git.openjdk.java.net/jdk/pull/7640 From darcy at openjdk.java.net Tue Mar 1 02:11:26 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Mar 2022 02:11:26 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v16] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy 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 24 additional commits since the last revision: - Make workding changes suggested in review feedback. - Merge branch 'master' into JDK-8266670 - Typo fix; add implSpec to Executable. - Appease jcheck. - Fix some bugs found by inspection, docs cleanup. - Merge branch 'master' into JDK-8266670 - Initial support for accessFlags methods - Add mask to access flag functionality. - Add test for location disjointness - Minor cleanup. - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b096a4cb...e63fb13e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/aa2b5eed..e63fb13e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=14-15 Stats: 8741 lines in 190 files changed: 6567 ins; 683 del; 1491 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Tue Mar 1 02:22:49 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 1 Mar 2022 02:22:49 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2] In-Reply-To: References: Message-ID: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> > Hi, > > `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. > > Should the other `requireNonNull` be `ForceInline` as well? > > Thank you very much. Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: the other ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7543/files - new: https://git.openjdk.java.net/jdk/pull/7543/files/bcd22b9d..b362bdca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7543&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7543&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7543.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7543/head:pull/7543 PR: https://git.openjdk.java.net/jdk/pull/7543 From david.holmes at oracle.com Tue Mar 1 02:28:55 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 1 Mar 2022 12:28:55 +1000 Subject: Future.isCancelled and thread interruption In-Reply-To: References: Message-ID: <18f47bfd-e724-c3fe-1053-662a8b4ed7a3@oracle.com> Hi, On 1/03/2022 4:17 am, Pushkar N Kulkarni wrote: > "Future.cancel(true)" cancels the receiver Future and also attempts to interrupt the executor thread that is running this task. However, not all threads may be interrupted. An exception are threads that executing one of the "restart-able blocking system calls" from libnet. > Such threads will ignore the thread interrupt(EINTR) and restart the blocking system call that was interrupted. See the system calls wrapped in the BLOCKING_IO_RETURN_INT macro: https://github.com/openjdk/jdk/blob/master/src/java.base/linux/native/libnet/linux_close.c#L352 You are mixing up two completely different notions of "interrupt". Thread.interrupt does not "interrupt" system calls - that only happens with signals. Thread.interrupt will not unblock low-level blocking I/O calls - like a socket connect. Only InterruptibleChannels provide some support for Thread.interrupt to break out of the I/O operation. David ----- > > The javadoc for "java.util.concurrent.Future.cancel(boolean mayInterruptIfRunning)" DOES clarify that this method is an "attempt" to cancel the Future, and that it has no effect if the "task is already completed or cancelled, or could not be cancelled for *some other reason*". It is also made clear that "the return value from this method does not necessarily indicate whether the task is now cancelled". This is good, in the context of this note. > > The javadoc also presents "Future.isCancelled()" as a definitive way to test if a Future was cancelled. However, it does not comment on the thread interruption attempted by Future.cancel(true). This might lead users to assume that if "Future.isCancelled()" returns true, the related executor thread was also successfully interrupted. This assumption would be invalid if the related executor thread was blocked in one of libnet's restart-able system calls (connect() could block for a couple of minutes). > > I am attaching a test program that reproduces the mentioned behaviour. The executor thread held a lock and it was assumed that when "Future.isCancelled()" returned true, the executor had been interrupted and the lock released. In reality, the lock was held for a longer time and it blocked the main thread where the invalid assumption was made. > > I am curious to know what others think of this matter! Any help/corrections/opinions will be appreciated. Thank you! > > ---------- > import java.net.*; > import java.util.concurrent.*; > > public class ConnectionTest { > private synchronized Socket connect(String host, int port) throws Exception { > InetSocketAddress address = new InetSocketAddress(host, port); > Socket s = new Socket(); > s.connect(address); // HERE: s.connect(address, T), with any T>0, would resolve the hang! > return s; > } > > private Socket connectToMain() throws Exception { > System.out.println("Connecting to main..."); > return connect("www.google.com", 81); > } > > private Socket connectToAlternate() throws Exception { > System.out.println("Connecting to alternate..."); > return connect("www.example.com", 80); > } > > public void test() throws Exception { > ExecutorService es = Executors.newFixedThreadPool(1); > Future f = es.submit(new Callable() { > public Socket call() throws Exception { > return connectToMain(); > } > }); > try { > f.get(2000, TimeUnit.MILLISECONDS); > System.out.println("Connected to main!"); > return; > } catch (TimeoutException e) { > System.out.println("Connection to main timed out, cancelling the Future with mayInterruptIfRunning = true"); > boolean ret = f.cancel(true); > System.out.println("Future.cancel(true) returned " + ret); > } > System.out.println("Is Future canceled? ..." + f.isCancelled()); > if (f.isCancelled()) { > connectToAlternate(); > System.out.println("Connected to alternate!"); > } > } > > public static void main(String [] args) throws Exception { > new ConnectionTest().test(); > } > } > ---------- > > -Pushkar > > > From naoto at openjdk.java.net Tue Mar 1 02:29:01 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Mar 2022 02:29:01 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Message-ID: On Tue, 1 Mar 2022 01:47:45 GMT, Joe Wang wrote: > Was the following assessment in the bug report correct? "the symbol F in java.time.DateTimeFormatter is no use in any pattern. It just may cause an exception." No, not correct. It is currently incorrectly tied with the `ChronoField.ALIGNED_DAY_OF_WEEK_IN_MONTH` field, and works as such. > If true, then it seems the compatibility risk would be low since pattern letter "F" as is currently defined is of no use. Thus, the risk should remain `medium`. > Also, the CSR summary needs to be a summary of the action to be taken, that is, changing the pattern definition. The current statement is similar to the problem statement. Thanks, modified. ------------- PR: https://git.openjdk.java.net/jdk/pull/7640 From duke at openjdk.java.net Tue Mar 1 02:33:06 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 1 Mar 2022 02:33:06 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2] In-Reply-To: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> References: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> Message-ID: On Tue, 1 Mar 2022 02:22:49 GMT, Quan Anh Mai wrote: >> Hi, >> >> `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. >> >> Should the other `requireNonNull` be `ForceInline` as well? >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > the other I have applied the change for the other one as well. Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From joehw at openjdk.java.net Tue Mar 1 03:10:10 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 1 Mar 2022 03:10:10 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Message-ID: On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7640 From ecki at zusammenkunft.net Tue Mar 1 03:35:13 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 1 Mar 2022 03:35:13 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: References: Message-ID: Alternatively you can make this ?first setter wins? (either globally or per thread), then you don?t have to care or check from where the call is coming. Could be even integrated with a system property similar to the securitymanager=allow. Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Kasper Nielsen Gesendet: Monday, February 28, 2022 9:23:11 PM An: Ethan McCue Cc: core-libs-dev Betreff: Re: Should System.exit be controlled by a Scope Local? Is there really a need to make this so complicated? In all the examples I've seen so far it would be fine to set system-exit restrictions up from the program's main class. So why not just restrict it to the main class by default? I assume this class is under the control of the user or an IDE/Application Server. Add this method to java.lang.Runtime void restrictExit(MethodHandles.Lookup lookup, IntConsumer interceptor) { if (lookup.lookupClass() != "JAVA_MAIN_CLASS" || !lookup.hasFullPrivilegeAccess()) { throw new IllegalArgumentException("Invalid Lookup class"); } ... Register interceptor to be called before System.exit ... } People could then call it, for example, from a static initializer block in the Main class. And use scope locals or whatever they want. static { Runtime.restrictExit(MethodHandles.lookup(), ...) } Ideally, everyone would be using the module system, And we would have some kind of "application module" concept, which would be the module containing the program's entry point. And which could have these special permissions by default. It might even be possible to delegate permissions to other modules if needed. /Kasper On Sat, 26 Feb 2022 at 22:27, Ethan McCue wrote: > I have a feeling this has been considered and I might just be articulating > the obvious - but: > > As called out in JEP 411, one of the remaining legitimate uses of the > Security Manager is to intercept calls to System.exit. This seems like a > decent use case for the Scope Local mechanism. > > > From jpai at openjdk.java.net Tue Mar 1 03:53:07 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 1 Mar 2022 03:53:07 GMT Subject: RFR: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale [v5] In-Reply-To: <_-XlZDme3lIVFOeuD17Ht6a5qiKxRLibm6EFex2YOn8=.efc1df68-8603-4c7a-b687-b4855f57cbd8@github.com> References: <_-XlZDme3lIVFOeuD17Ht6a5qiKxRLibm6EFex2YOn8=.efc1df68-8603-4c7a-b687-b4855f57cbd8@github.com> Message-ID: On Fri, 25 Feb 2022 08:44:42 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? >> >> As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: >> - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. >> - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. >> >> All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: >> >> >> Using locale: he for Properties#store(OutputStream) test >> test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure >> java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 >> at org.testng.Assert.fail(Assert.java:87) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) >> at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) >> at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) >> at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) >> at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) >> at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) >> at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) >> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) >> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) >> at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) >> at org.testng.TestRunner.privateRun(TestRunner.java:764) >> at org.testng.TestRunner.run(TestRunner.java:585) >> at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) >> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) >> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) >> at org.testng.SuiteRunner.run(SuiteRunner.java:286) >> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) >> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) >> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) >> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) >> at org.testng.TestNG.runSuites(TestNG.java:1069) >> at org.testng.TestNG.run(TestNG.java:1037) >> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) >> at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) >> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) >> at java.base/java.lang.reflect.Method.invoke(Method.java:577) >> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) >> at java.base/java.lang.Thread.run(Thread.java:828) >> Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 >> at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) >> at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) >> at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) >> ... 30 more >> >> (in the exception above a locale with language `he` is being used) >> >> The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > HashSet::new instead of new HashSet() in test Thank you Naoto and Roger for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From jpai at openjdk.java.net Tue Mar 1 03:53:07 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 1 Mar 2022 03:53:07 GMT Subject: Integrated: 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 14:09:50 GMT, Jaikiran Pai wrote: > Can I please get a review of this test only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8282023? > > As noted in that JBS issue these tests fail when the default locale under which those tests are run isn't `en_US`. Both these tests were introduced as part of https://bugs.openjdk.java.net/browse/JDK-8231640. At a high level, these test do the following: > - Use Properties.store(...) APIs to write out a properties file. This internally ends up writing a date comment via a call to `java.util.Date.toString()` method. > - The test then runs a few checks to make sure that the written out `Date` is an expected one. To run these checks it uses the `java.time.format.DateTimeFormatter` to parse the date comment out of the properties file. > > All this works fine when the default locale is (for example) `en_US`. However, when the default locale is (for example `en_CA` or even `hi_IN`) the tests fail with an exception in the latter step above while parsing the date comment using the `DateTimeFormatter` instance. The exception looks like: > > > Using locale: he for Properties#store(OutputStream) test > test PropertiesStoreTest.testStoreOutputStreamDateComment(he): failure > java.lang.AssertionError: Unexpected date comment: Mon Feb 21 19:10:31 IST 2022 > at org.testng.Assert.fail(Assert.java:87) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:255) > at PropertiesStoreTest.testStoreOutputStreamDateComment(PropertiesStoreTest.java:223) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132) > at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599) > at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174) > at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46) > at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822) > at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128) > at java.base/java.util.ArrayList.forEach(ArrayList.java:1511) > at org.testng.TestRunner.privateRun(TestRunner.java:764) > at org.testng.TestRunner.run(TestRunner.java:585) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:384) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337) > at org.testng.SuiteRunner.run(SuiteRunner.java:286) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1140) > at org.testng.TestNG.runSuites(TestNG.java:1069) > at org.testng.TestNG.run(TestNG.java:1037) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:577) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:828) > Caused by: java.time.format.DateTimeParseException: Text 'Mon Feb 21 19:10:31 IST 2022' could not be parsed at index 0 > at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2106) > at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1934) > at PropertiesStoreTest.testDateComment(PropertiesStoreTest.java:253) > ... 30 more > > (in the exception above a locale with language `he` is being used) > > The root cause of this failure lies (only) within the tests - the `DateTimeFormatter` used in the tests is locale sensitive and uses the current (`Locale.getDefault()`) locale by default for parsing the date text. This parsing fails because, although `Date.toString()` javadoc states nothing about locales, it does mention the exact characters that will be used to write out the date comment. In other words, this date comment written out is locale insensitive and as such when parsing using `DateTimeFormatter` a neutral locale is appropriate on the `DateTimeFormatter` instance. This PR thus changes the tests to use `Locale.ROOT` while parsing this date comment. Additionally, while I was at it, I updated the `PropertiesStoreTest` to automate the use of multiple different locales to reproduce this issue (automatically) and verify the fix. This pull request has now been integrated. Changeset: e4d9fc81 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/e4d9fc811e0ef0eb9b097e06525a1183445d8d79 Stats: 74 lines in 2 files changed: 45 ins; 2 del; 27 mod 8282023: PropertiesStoreTest and StoreReproducibilityTest jtreg failures due to en_CA locale Reviewed-by: naoto, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7558 From duke at openjdk.java.net Tue Mar 1 05:54:06 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 1 Mar 2022 05:54:06 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2] In-Reply-To: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> References: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> Message-ID: On Tue, 1 Mar 2022 02:22:49 GMT, Quan Anh Mai wrote: >> Hi, >> >> `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. >> >> Should the other `requireNonNull` be `ForceInline` as well? >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > the other I?think `@ForceInline` should?also be?applied to?the?overload that?takes the?message?supplier, and?probably also?`requireNonNullElse` and?`requireNonNullElseGet`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From darcy at openjdk.java.net Tue Mar 1 06:20:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 1 Mar 2022 06:20:07 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 06:22:42 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Adding descriptive comments. test/jdk/java/lang/Math/RoundTests.java line 32: > 30: public static void main(String... args) { > 31: int failures = 0; > 32: for (int i = 0; i < 100000; i++) { Is there an idiom to trigger the auto-vectorization, perhaps using command line arguments, that doesn't bloat the running time of this test? ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From pushkar.nk at in.ibm.com Tue Mar 1 06:38:42 2022 From: pushkar.nk at in.ibm.com (Pushkar N Kulkarni) Date: Tue, 1 Mar 2022 06:38:42 +0000 Subject: Future.isCancelled and thread interruption In-Reply-To: <18f47bfd-e724-c3fe-1053-662a8b4ed7a3@oracle.com> References: <18f47bfd-e724-c3fe-1053-662a8b4ed7a3@oracle.com> Message-ID: Hi David, Thank you. So, I had the wrong notion of Thread.interrupt() also causing the signalling of the underlying OS thread. With that corrected, things have started making sense. Appreciate you taking the time to respond! ?On 01/03/22, 7:59 AM, "David Holmes" wrote: Hi, On 1/03/2022 4:17 am, Pushkar N Kulkarni wrote: > "Future.cancel(true)" cancels the receiver Future and also attempts to interrupt the executor thread that is running this task. However, not all threads may be interrupted. An exception are threads that executing one of the "restart-able blocking system calls" from libnet. > Such threads will ignore the thread interrupt(EINTR) and restart the blocking system call that was interrupted. See the system calls wrapped in the BLOCKING_IO_RETURN_INT macro: https://github.com/openjdk/jdk/blob/master/src/java.base/linux/native/libnet/linux_close.c#L352 You are mixing up two completely different notions of "interrupt". Thread.interrupt does not "interrupt" system calls - that only happens with signals. Thread.interrupt will not unblock low-level blocking I/O calls - like a socket connect. Only InterruptibleChannels provide some support for Thread.interrupt to break out of the I/O operation. David ----- > > The javadoc for "java.util.concurrent.Future.cancel(boolean mayInterruptIfRunning)" DOES clarify that this method is an "attempt" to cancel the Future, and that it has no effect if the "task is already completed or cancelled, or could not be cancelled for *some other reason*". It is also made clear that "the return value from this method does not necessarily indicate whether the task is now cancelled". This is good, in the context of this note. > > The javadoc also presents "Future.isCancelled()" as a definitive way to test if a Future was cancelled. However, it does not comment on the thread interruption attempted by Future.cancel(true). This might lead users to assume that if "Future.isCancelled()" returns true, the related executor thread was also successfully interrupted. This assumption would be invalid if the related executor thread was blocked in one of libnet's restart-able system calls (connect() could block for a couple of minutes). > > I am attaching a test program that reproduces the mentioned behaviour. The executor thread held a lock and it was assumed that when "Future.isCancelled()" returned true, the executor had been interrupted and the lock released. In reality, the lock was held for a longer time and it blocked the main thread where the invalid assumption was made. > > I am curious to know what others think of this matter! Any help/corrections/opinions will be appreciated. Thank you! > > ---------- > import java.net.*; > import java.util.concurrent.*; > > public class ConnectionTest { > private synchronized Socket connect(String host, int port) throws Exception { > InetSocketAddress address = new InetSocketAddress(host, port); > Socket s = new Socket(); > s.connect(address); // HERE: s.connect(address, T), with any T>0, would resolve the hang! > return s; > } > > private Socket connectToMain() throws Exception { > System.out.println("Connecting to main..."); > return connect("www.google.com", 81); > } > > private Socket connectToAlternate() throws Exception { > System.out.println("Connecting to alternate..."); > return connect("www.example.com", 80); > } > > public void test() throws Exception { > ExecutorService es = Executors.newFixedThreadPool(1); > Future f = es.submit(new Callable() { > public Socket call() throws Exception { > return connectToMain(); > } > }); > try { > f.get(2000, TimeUnit.MILLISECONDS); > System.out.println("Connected to main!"); > return; > } catch (TimeoutException e) { > System.out.println("Connection to main timed out, cancelling the Future with mayInterruptIfRunning = true"); > boolean ret = f.cancel(true); > System.out.println("Future.cancel(true) returned " + ret); > } > System.out.println("Is Future canceled? ..." + f.isCancelled()); > if (f.isCancelled()) { > connectToAlternate(); > System.out.println("Connected to alternate!"); > } > } > > public static void main(String [] args) throws Exception { > new ConnectionTest().test(); > } > } > ---------- > > -Pushkar > > > From scolebourne at openjdk.java.net Tue Mar 1 07:44:24 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Tue, 1 Mar 2022 07:44:24 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Message-ID: On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted. Although there is incompatibility, I believe a fix is the correct choice. The issue arose because of the poor description of the field in LDML. ------------- Marked as reviewed by scolebourne (Author). PR: https://git.openjdk.java.net/jdk/pull/7640 From chegar at openjdk.java.net Tue Mar 1 08:13:57 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 1 Mar 2022 08:13:57 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character [v3] In-Reply-To: References: Message-ID: > The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when using a module finder with a custom file > system that has a path-separator character that differs from that of the > default file system, e.g. the zip file system (which uses '/', > rather than '\' ). > > Rather than adding a new test for this, I deciced to just modify an > existing one. The existing test exercises the module finder with a > custom file system, but does so with modules have trivial single-level > packages names. I just expanded the module to have a subpackage. This > is sufficient to reproduce the bug, and verify the fix. > > [*] > > java.lang.module.FindException: Error reading module: /m2 > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) > at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) > at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) > at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) > at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) > at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) > at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) > at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) > at ... > Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module > at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) > at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) > at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) > at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) > ... 36 more Chris Hegarty 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: - Merge branch 'openjdk:master' into modulefinder_separator_win - update copyright year - add tag with OrigBugId 8178380, and bugFixId 8282444 - fix file separator in module finder with custom fs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7632/files - new: https://git.openjdk.java.net/jdk/pull/7632/files/220c43c2..a7cbfd0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7632&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7632&range=01-02 Stats: 3764 lines in 134 files changed: 3088 ins; 449 del; 227 mod Patch: https://git.openjdk.java.net/jdk/pull/7632.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7632/head:pull/7632 PR: https://git.openjdk.java.net/jdk/pull/7632 From duke at openjdk.java.net Tue Mar 1 08:16:06 2022 From: duke at openjdk.java.net (Maxim Kartashev) Date: Tue, 1 Mar 2022 08:16:06 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 21:30:27 GMT, Roger Riggs wrote: >> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a new line to the end of test file for JDK-8282008 > > (I'm still working on a more nuanced fix that works with .exe, .cmd, and with allowAmbiguousCommands both true and false). > > The suggested workaround was to remove the application quotes and let ProcessBuilder do the quoting. > That resulted in an extra backslash "\" at the end of a file path. In my investigation, the extra "\" doesn't prevent the > string from being correctly used as a directory path in either VisualBasic or cmd.exe. > So I'm curious, in the original application that uncovered this problem, what is/was reported as the error? > Was the original application retested with the workaround? > > The case of the backslash at the end of an argument occurs mainly in a directory path. > Yes, the argument is different, but does it make a difference that matters in the context in which it appears. @RogerRiggs Our use case was something like this `java -classpath "C:\Program Files\MySQL\JDBC\" ...`. More specifically, while this works after JDK-8250568 (the string ends with `"`) ProcessBuilder("java.exe", "-classpath", ""C:\\New folder"", "Test", "test"); this doesn't and, as I understand, shouldn't (the string ends with `"`): ProcessBuilder("java.exe", "-classpath", ""C:\\New folder\\"", "Test", "test"); and produces errors like these Error: Could not find or load main class folder"" Test test Caused by: java.lang.ClassNotFoundException: folder"" Test test However, the following still doesn't work, but, I believe, should (the string ends with `\"`): ProcessBuilder("java.exe", "-classpath", ""C:\\New folder\\\\"", "Test", "test"); ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From dfuchs at openjdk.java.net Tue Mar 1 09:58:06 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 1 Mar 2022 09:58:06 GMT Subject: RFR: 8282444: Module finder incorrectly assumes default file system path-separator character [v3] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 08:13:57 GMT, Chris Hegarty wrote: >> The module finder implementation incorrectly uses the path-separator >> character from the default file system, when mapping the relative path >> of an entry in an exploded module to a package name. This causes >> problems on Windows [*] when using a module finder with a custom file >> system that has a path-separator character that differs from that of the >> default file system, e.g. the zip file system (which uses '/', >> rather than '\' ). >> >> Rather than adding a new test for this, I deciced to just modify an >> existing one. The existing test exercises the module finder with a >> custom file system, but does so with modules have trivial single-level >> packages names. I just expanded the module to have a subpackage. This >> is sufficient to reproduce the bug, and verify the fix. >> >> [*] >> >> java.lang.module.FindException: Error reading module: /m2 >> at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) >> at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) >> at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) >> at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) >> at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) >> at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) >> at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) >> at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) >> at ... >> Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module >> at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) >> at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) >> at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) >> at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) >> at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) >> ... 36 more > > Chris Hegarty 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: > > - Merge branch 'openjdk:master' into modulefinder_separator_win > - update copyright year > - add tag with OrigBugId 8178380, and bugFixId 8282444 > - fix file separator in module finder with custom fs Not an expert of the area but the proposed changes look good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7632 From redestad at openjdk.java.net Tue Mar 1 10:24:14 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 1 Mar 2022 10:24:14 GMT Subject: Integrated: 8282047: Enhance StringDecode/Encode microbenchmarks In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 15:11:11 GMT, Claes Redestad wrote: > Splitting out these micro changes from #7231 > > - Clean up and simplify setup and code > - Add variants with different inputs with varying lengths and encoding weights, but also relevant mixes of each so that we both cover interesting corner cases but also verify that performance behave when there's a multitude of input shapes. Both simple and mixed variants are interesting diagnostic tools. > - Drop all charsets from the default run configuration except UTF-8. Motivation: Defaults should give good coverage but try to keep runtimes at bay. Additionally if the charset tested can't encode the higher codepoints used in these micros the results might be misleading. If you for example test using ISO-8859-1 the UTF-16 bytes in StringDecode.decodeUTF16 will have all been replaced by `?`, so the test is effectively the same as testing ASCII-only. This pull request has now been integrated. Changeset: d4d12ad1 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/d4d12ad1d92ae6d353ce9e16b1b72e6416874cd6 Stats: 358 lines in 2 files changed: 218 ins; 71 del; 69 mod 8282047: Enhance StringDecode/Encode microbenchmarks Reviewed-by: bchristi ------------- PR: https://git.openjdk.java.net/jdk/pull/7516 From chegar at openjdk.java.net Tue Mar 1 10:41:09 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Tue, 1 Mar 2022 10:41:09 GMT Subject: Integrated: 8282444: Module finder incorrectly assumes default file system path-separator character In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 11:12:17 GMT, Chris Hegarty wrote: > The module finder implementation incorrectly uses the path-separator > character from the default file system, when mapping the relative path > of an entry in an exploded module to a package name. This causes > problems on Windows [*] when using a module finder with a custom file > system that has a path-separator character that differs from that of the > default file system, e.g. the zip file system (which uses '/', > rather than '\' ). > > Rather than adding a new test for this, I deciced to just modify an > existing one. The existing test exercises the module finder with a > custom file system, but does so with modules have trivial single-level > packages names. I just expanded the module to have a subpackage. This > is sufficient to reproduce the bug, and verify the fix. > > [*] > > java.lang.module.FindException: Error reading module: /m2 > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:350) > at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284) > at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232) > at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190) > at java.base/jdk.internal.module.ModulePath.findAll(ModulePath.java:166) > at ModulesInCustomFileSystem.listAllModules(ModulesInCustomFileSystem.java:108) > at ModulesInCustomFileSystem.testZipFileSystem(ModulesInCustomFileSystem.java:97) > at ModulesInCustomFileSystem.testExplodedModulesInZipFileSystem(ModulesInCustomFileSystem.java:68) > at ... > Caused by: java.lang.module.InvalidModuleDescriptorException: Package q.r not found in module > at java.base/jdk.internal.module.ModuleInfo.invalidModuleDescriptor(ModuleInfo.java:1212) > at java.base/jdk.internal.module.ModuleInfo.doRead(ModuleInfo.java:330) > at java.base/jdk.internal.module.ModuleInfo.read(ModuleInfo.java:129) > at java.base/jdk.internal.module.ModulePath.readExplodedModule(ModulePath.java:689) > at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:320) > ... 36 more This pull request has now been integrated. Changeset: 369291b2 Author: Chris Hegarty URL: https://git.openjdk.java.net/jdk/commit/369291b265e13d625c5f465da9b1854c0d70c435 Stats: 10 lines in 5 files changed: 2 ins; 0 del; 8 mod 8282444: Module finder incorrectly assumes default file system path-separator character Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7632 From lancea at openjdk.java.net Tue Mar 1 11:26:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 1 Mar 2022 11:26:06 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Message-ID: <5Qz9140XHsXdewRRvFmblwa2fXvSaWIbxzBHgBbXjiI=.206a3e0d-04cb-4a64-8bd4-db6137ac7b88@github.com> On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted. I think the change makes sense. Are there any TCK tests that need to be modified or Added? I made a very quick scan of the open/test/jdk/java/time/tck/java/time/ dirs and did not see any tests but of course I could have missed it ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7640 From aph-open at littlepinkcloud.com Tue Mar 1 11:45:44 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 1 Mar 2022 11:45:44 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <68ea5542-0866-8583-938f-51b2f5512088@littlepinkcloud.com> References: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> <68ea5542-0866-8583-938f-51b2f5512088@littlepinkcloud.com> Message-ID: <4074cee5-7f6d-889e-9343-52d4894f5961@littlepinkcloud.com> On 2/28/22 15:32, Andrew Haley wrote: > > I think all we'd need is a set of capabilities bound to a scope local > at thread startup, and I guess it'd default to "all capabilities". > Trusted code could then override any of those capabilities. > > We'd have to make sure that capabilities were inherited by threads, > and we'd have to think very carefully about thread pools. The problem > there is that while it would (I guess) make sense to prevent all code > executing in thread pools from calling System.exit(), there's an > obvious compatibility problem if it can't. Although... there certainly is some potential profit in restricted thread pools, which have no compatibility problems because it'd be a new feature. I think this solves the problem Alan Bateman raised too. Sure, you wouldn't be able to use the default thread pool, but that's no big deal, I would have thought. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph-open at littlepinkcloud.com Tue Mar 1 13:01:28 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 1 Mar 2022 13:01:28 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <4074cee5-7f6d-889e-9343-52d4894f5961@littlepinkcloud.com> References: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> <68ea5542-0866-8583-938f-51b2f5512088@littlepinkcloud.com> <4074cee5-7f6d-889e-9343-52d4894f5961@littlepinkcloud.com> Message-ID: <92191c36-718b-94b8-db42-2d0306d4906a@littlepinkcloud.com> On 3/1/22 11:45, Andrew Haley wrote: > Sure, you wouldn't > be able to use the default thread pool, but that's no big deal, I would have > thought. I'm sorry, I'll say that again. :-) I meant to say "you wouldn't be able to use the default thread pool if you wanted to use threads with some restrictions (e.g those that couldn't invoke System.exit()). -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rriggs at openjdk.java.net Tue Mar 1 14:44:08 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Mar 2022 14:44:08 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Message-ID: On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7640 From rriggs at openjdk.java.net Tue Mar 1 14:53:04 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 1 Mar 2022 14:53:04 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v3] In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 17:21:48 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Add a new line to the end of test file for JDK-8282008 Thanks for the example, though my question was in the case in which the extra quotes were not included by the app. For example, ProcessBuilder("java.exe", "-classpath", "C:\\New folder\", "Test", "test"); I thought the troublesome case was specific to VB/WScript being invoked with ".exe" quoting but WSCRIPT interpreting the command line string using simple quoting with no escapes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From jbhateja at openjdk.java.net Tue Mar 1 17:07:58 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 1 Mar 2022 17:07:58 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v10] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Review comments resolved.` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/54d4ea36..3b90ae53 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=08-09 Stats: 12 lines in 2 files changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From naoto at openjdk.java.net Tue Mar 1 17:53:11 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 1 Mar 2022 17:53:11 GMT Subject: RFR: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: <5Qz9140XHsXdewRRvFmblwa2fXvSaWIbxzBHgBbXjiI=.206a3e0d-04cb-4a64-8bd4-db6137ac7b88@github.com> References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> <5Qz9140XHsXdewRRvFmblwa2fXvSaWIbxzBHgBbXjiI=.206a3e0d-04cb-4a64-8bd4-db6137ac7b88@github.com> Message-ID: <6v6TAncUWuG62AgTH1Kr4Ip9sGhhtD-1kl3fWfW4eKA=.023fd2eb-93ed-4d8d-94d8-deb5c4328200@github.com> On Tue, 1 Mar 2022 11:22:35 GMT, Lance Andersen wrote: > Are there any TCK tests that need to be modified or Added? I made a very quick scan of the open/test/jdk/java/time/tck/java/time/ dirs and did not see any tests but of course I could have missed it There are test cases in the `TCK` directory that only verify its validity, such as number of digits. Those tests pass with this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/7640 From sean.mullan at oracle.com Tue Mar 1 18:17:07 2022 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 1 Mar 2022 13:17:07 -0500 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <92191c36-718b-94b8-db42-2d0306d4906a@littlepinkcloud.com> References: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> <68ea5542-0866-8583-938f-51b2f5512088@littlepinkcloud.com> <4074cee5-7f6d-889e-9343-52d4894f5961@littlepinkcloud.com> <92191c36-718b-94b8-db42-2d0306d4906a@littlepinkcloud.com> Message-ID: <924583af-919c-56b6-d875-a534f277aaed@oracle.com> On 3/1/22 8:01 AM, Andrew Haley wrote: > On 3/1/22 11:45, Andrew Haley wrote: >> Sure, you wouldn't >> be able to use the default thread pool, but that's no big deal, I would have >> thought. > > I'm sorry, I'll say that again. :-) > > > I meant to say "you wouldn't be able to use the default thread pool if > you wanted to use threads with some restrictions (e.g those that couldn't > invoke System.exit()). Can you explain in a little more detail as to what the compatibility issues are with preventing threads in thread pools from calling System.exit? Thanks, Sean From kvn at openjdk.java.net Tue Mar 1 18:35:11 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 1 Mar 2022 18:35:11 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Resolve merge conflict > - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) > - aarch64: fix issue with short inputs divisible by wordSize > - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. > - Revert micro changes, split out to #7516 > - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives > - Merge branch 'master' into count_positives > - Restore partial vector checks in AVX2 and SSE intrinsic variants > - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral > - Simplify changes to encodeUTF8 > - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce Looks good. @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7231 From lucy at openjdk.java.net Tue Mar 1 18:41:11 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 1 Mar 2022 18:41:11 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Resolve merge conflict > - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) > - aarch64: fix issue with short inputs divisible by wordSize > - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. > - Revert micro changes, split out to #7516 > - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives > - Merge branch 'master' into count_positives > - Restore partial vector checks in AVX2 and SSE intrinsic variants > - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral > - Simplify changes to encodeUTF8 > - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce @cl4ea How do you plan to proceed with the PPC (PR#7430) and s390 (PR#7604) intrinsic implementations? We (Martin and myself) would not object if you would just integrate the changes into this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Tue Mar 1 19:15:04 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 1 Mar 2022 19:15:04 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 18:32:00 GMT, Vladimir Kozlov wrote: > @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes. Note that the aarch64 changes I've put in for now implements `countPositives` to return `0` if there's a negative value anywhere, otherwise `len`. This way we can remove the intrinsic scaffolding for `hasNegatives` once I integrate s390 and ppc changes, but since no precise calculation is implemented for aarch64 then there's no speed-up on micros such as `encodeLatin1LongEnd` for now. I would like to defer such optimization work to a follow-up. @RealLucy yes, I'd like to integrate your changes into this patch and drop the `HasNegativesNode` et.c. You mentioned in e-mail some issue with the code generation on s390 - has that been resolved or identified? ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From psandoz at openjdk.java.net Tue Mar 1 19:38:06 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 1 Mar 2022 19:38:06 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2] In-Reply-To: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> References: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> Message-ID: On Tue, 1 Mar 2022 02:22:49 GMT, Quan Anh Mai wrote: >> Hi, >> >> `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. >> >> Should the other `requireNonNull` be `ForceInline` as well? >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > the other Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From lucy at openjdk.java.net Tue Mar 1 22:05:04 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 1 Mar 2022 22:05:04 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 19:12:17 GMT, Claes Redestad wrote: >> @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes. > >> @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes. > > Note that the aarch64 changes I've put in for now implements `countPositives` to return `0` if there's a negative value anywhere, otherwise `len`. This way we can remove the intrinsic scaffolding for `hasNegatives` once I integrate s390 and ppc changes, but since no precise calculation is implemented for aarch64 then there's no speed-up on micros such as `encodeLatin1LongEnd` for now. I would like to defer such optimization work to a follow-up. > > @RealLucy yes, I'd like to integrate your changes into this patch and drop the `HasNegativesNode` et.c. You mentioned in e-mail some issue with the code generation on s390 - has that been resolved or identified? @cl4es This issue in code generation (checking the intrinsic return value for < 0 where it only can be >= 0) is not specific to s390. It is as well visible on x86_64 and on ppc. It happens with the SPECjvm2008 sub-benchmark compiler.sunflow. What's specific to s390 is the fact that this obviously erroneous check causes the benchmark to fail. x86_64 and ppc seem to be immune. Where the immunity comes from is not yet understood. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From valeriep at openjdk.java.net Wed Mar 2 00:21:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 00:21:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA Message-ID: It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: - SHA-384 for secure hashing - AES-256 for symmetric encryption - RSA with 3072 bit keys for digital signatures and for key exchange - Diffie Hellman (DH) with 3072 bit keys for key exchange - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? Thanks! ------------- Commit messages: - 8267319: Use larger default key sizes and algorithms based on CNSA Changes: https://git.openjdk.java.net/jdk/pull/7652/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267319 Stats: 479 lines in 29 files changed: 321 ins; 6 del; 152 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From duke at openjdk.java.net Wed Mar 2 00:35:59 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Wed, 2 Mar 2022 00:35:59 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2] In-Reply-To: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> References: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> Message-ID: <2retYvIyxLXZiRORJSVrT0roquRZVYf7UnhK9mLXdUY=.a6e91817-45e7-4969-ac37-732e4206b463@github.com> On Tue, 1 Mar 2022 02:22:49 GMT, Quan Anh Mai wrote: >> Hi, >> >> `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. >> >> Should the other `requireNonNull` be `ForceInline` as well? >> >> Thank you very much. > > Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: > > the other Thanks a lot for your reviews, do I need a second review for this? @ExE-Boss IMO generally we only decorate `ForceInline` on functions of which inlining is crucial since inlining decision is a hard problem and often not solvable from the local point of view, especially from the callee's one. ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From duke at openjdk.java.net Wed Mar 2 00:49:06 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Wed, 2 Mar 2022 00:49:06 GMT Subject: Integrated: 8282143: Objects.requireNonNull should be ForceInline In-Reply-To: References: Message-ID: On Sat, 19 Feb 2022 05:51:52 GMT, Quan Anh Mai wrote: > Hi, > > `Objects.requireNonNull` may fail to be inlined. The call is expensive and may lead to objects escaping to the heap while the null check is cheap and is often elided. I have observed this when using the vector API when a call to `Objects.requireNonNull` leads to vectors being materialised in a hot loop. > > Should the other `requireNonNull` be `ForceInline` as well? > > Thank you very much. This pull request has now been integrated. Changeset: fc52a218 Author: Quan Anh Mai Committer: Paul Sandoz URL: https://git.openjdk.java.net/jdk/commit/fc52a2182a9debc04b2ac302801b3d61989f54ec Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8282143: Objects.requireNonNull should be ForceInline Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From psandoz at openjdk.java.net Wed Mar 2 00:49:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Mar 2022 00:49:05 GMT Subject: RFR: 8282143: Objects.requireNonNull should be ForceInline [v2] In-Reply-To: <2retYvIyxLXZiRORJSVrT0roquRZVYf7UnhK9mLXdUY=.a6e91817-45e7-4969-ac37-732e4206b463@github.com> References: <9Wnr7zcSU7d2eWq0jAOIZUiuMWpq4cc7hnu-veGl8sM=.7553eddb-5a88-4caa-8a11-6f6b5fd03d02@github.com> <2retYvIyxLXZiRORJSVrT0roquRZVYf7UnhK9mLXdUY=.a6e91817-45e7-4969-ac37-732e4206b463@github.com> Message-ID: On Wed, 2 Mar 2022 00:32:46 GMT, Quan Anh Mai wrote: >> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision: >> >> the other > > Thanks a lot for your reviews, do I need a second review for this? > @ExE-Boss IMO generally we only decorate `ForceInline` on functions of which inlining is crucial since inlining decision is a hard problem and often not solvable from the local point of view, especially from the callee's one. @merykitty it's good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7543 From smarks at openjdk.java.net Wed Mar 2 01:47:59 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 2 Mar 2022 01:47:59 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: <9HiZ4sHd0jS7asQFUxOEK8MNKdfjfb4a8zhntVACDHA=.98ec5cf9-8228-4363-9f61-263f56ddd620@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> <9HiZ4sHd0jS7asQFUxOEK8MNKdfjfb4a8zhntVACDHA=.98ec5cf9-8228-4363-9f61-263f56ddd620@github.com> Message-ID: On Sun, 20 Feb 2022 19:50:01 GMT, liach wrote: >> @liach Hi. please have a look at the latest commit. >> do you think it be better now? > > Oops, didn't notice there was this helpful `init` method. Does look much more straightforward now. I'm starting to look at this again. First, a quick note -- I don't think there should be any IdentityHashMap changes here. That uses a completely different internal structure and allocation policy, and it's kind of a distraction from the main point of this change. (As the preceding chain of comments illustrates.) There is a question of whether IdentityHashMap ought to "allow for some growth" when copying a map, but it's hard to see how much of a problem this really is. I'd suggest focusing on getting this change done, and then (if you still have energy) to try to eradicate the `(int) (expected / 0.75) + 1` idiom that's sprinkled around the JDK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From jbhateja at openjdk.java.net Wed Mar 2 02:44:41 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 2 Mar 2022 02:44:41 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v11] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Removing +LogCompilation flag. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/3b90ae53..57b1b13a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From xgong at openjdk.java.net Wed Mar 2 03:46:27 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 2 Mar 2022 03:46:27 GMT Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate feature Message-ID: The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature. This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE: mov z19.d, #0 cmpgt p1.d, p7/z, z19.d, z17.d and p0.b, p7/z, p1.b, p0.b are optimized to: mov z19.d, #0 cmpgt p0.d, p0/z, z19.d, z17.d Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2. ------------- Commit messages: - 8282432: Optimize masked "test" Vector API with predicate feature Changes: https://git.openjdk.java.net/jdk/pull/7654/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7654&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282432 Stats: 1233 lines in 70 files changed: 590 ins; 7 del; 636 mod Patch: https://git.openjdk.java.net/jdk/pull/7654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7654/head:pull/7654 PR: https://git.openjdk.java.net/jdk/pull/7654 From ascarpino at openjdk.java.net Wed Mar 2 04:06:00 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Wed, 2 Mar 2022 04:06:00 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! I have some compatibility concerns about the AES change breaking code that expects a SecretKeySpec of 16 bytes. I can see situations where '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will throw an exception. I haven't looked at other modes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From ihse at openjdk.java.net Wed Mar 2 13:12:52 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 2 Mar 2022 13:12:52 GMT Subject: RFR: 8209784: Include hsdis in the JDK [v2] In-Reply-To: References: Message-ID: > This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. > > The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Somehow the tabs got converted to spaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7578/files - new: https://git.openjdk.java.net/jdk/pull/7578/files/0f19696e..6839f911 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7578&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7578&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7578.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7578/head:pull/7578 PR: https://git.openjdk.java.net/jdk/pull/7578 From erikj at openjdk.java.net Wed Mar 2 13:53:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Mar 2022 13:53:05 GMT Subject: RFR: 8209784: Include hsdis in the JDK [v2] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 13:12:52 GMT, Magnus Ihse Bursie wrote: >> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. >> >> The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Somehow the tabs got converted to spaces Top level install-hsdis needs to depend on jdk-image. ------------- Changes requested by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7578 From redestad at openjdk.java.net Wed Mar 2 14:12:31 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 2 Mar 2022 14:12:31 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v7] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Narrow the bottom_type of CountPositivesNode (always results in a positive int value) - Merge master - Resolve merge conflict - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) - aarch64: fix issue with short inputs divisible by wordSize - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. - Revert micro changes, split out to #7516 - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives - Merge branch 'master' into count_positives - Restore partial vector checks in AVX2 and SSE intrinsic variants - ... and 21 more: https://git.openjdk.java.net/jdk/compare/d4d12ad1...7789349a ------------- Changes: https://git.openjdk.java.net/jdk/pull/7231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=06 Stats: 527 lines in 29 files changed: 309 ins; 49 del; 169 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Wed Mar 2 14:12:33 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 2 Mar 2022 14:12:33 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 14:19:20 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: > > - Resolve merge conflict > - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) > - aarch64: fix issue with short inputs divisible by wordSize > - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. > - Revert micro changes, split out to #7516 > - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives > - Merge branch 'master' into count_positives > - Restore partial vector checks in AVX2 and SSE intrinsic variants > - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral > - Simplify changes to encodeUTF8 > - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce > Making the `bottom_type()` of `CountPositivesNode` more precise (`TypeInt::INT` -> `TypeInt::POS`) might help, then. Seems like something we want to do regardless. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From aph at openjdk.java.net Wed Mar 2 14:28:06 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 2 Mar 2022 14:28:06 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 19:12:17 GMT, Claes Redestad wrote: > > @theRealAph , @a74nh or someone familiar with aarch64 code, please review aarch64 changes. > > Note that the aarch64 changes I've put in for now implements `countPositives` to return `0` if there's a negative value anywhere, otherwise `len`. This way we can remove the intrinsic scaffolding for `hasNegatives` once I integrate s390 and ppc Sure. And we don't have to check which of the 8 bytes in a word has its top bit set, so we don't have to do any more work, just return the count when we stopped searching. So there's no possible performance regression on AArch64 as far as I can see. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From jlaskey at openjdk.java.net Wed Mar 2 15:23:30 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 2 Mar 2022 15:23:30 GMT Subject: RFR: 8282551: Properly initialize L32X64MixRandom state In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 01:39:52 GMT, Devin Smith wrote: > Did a cursory review of the other generators, they seem to set the state correctly. Marked as reviewed by jlaskey (Reviewer). I'll sponsor this change when you receive your OCA. ------------- PR: https://git.openjdk.java.net/jdk/pull/7120 From duke at openjdk.java.net Wed Mar 2 15:23:30 2022 From: duke at openjdk.java.net (Devin Smith) Date: Wed, 2 Mar 2022 15:23:30 GMT Subject: RFR: 8282551: Properly initialize L32X64MixRandom state In-Reply-To: References: Message-ID: <-3q-EOOLQZQgJCyxYos1X2NtQIAcFcWx9DR4uGz5WKU=.518734ce-d17c-4ec1-bc3b-316225821e44@github.com> On Tue, 18 Jan 2022 01:39:52 GMT, Devin Smith wrote: > Did a cursory review of the other generators, they seem to set the state correctly. @JimLaskey would it be possible to create an issue and review this change? I don't have an account on the OpenJDK issue tracker. I'm not sure how to move this forward, or get the attention of the people responsible for this code. I see @turbanoff you liked and may be involved w/ OpenJDK? ------------- PR: https://git.openjdk.java.net/jdk/pull/7120 From duke at openjdk.java.net Wed Mar 2 15:23:29 2022 From: duke at openjdk.java.net (Devin Smith) Date: Wed, 2 Mar 2022 15:23:29 GMT Subject: RFR: 8282551: Properly initialize L32X64MixRandom state Message-ID: Did a cursory review of the other generators, they seem to set the state correctly. ------------- Commit messages: - [PATCH] Properly initialize L32X64MixRandom state Changes: https://git.openjdk.java.net/jdk/pull/7120/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7120&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282551 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7120.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7120/head:pull/7120 PR: https://git.openjdk.java.net/jdk/pull/7120 From djelinski at openjdk.java.net Wed Mar 2 15:23:32 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 2 Mar 2022 15:23:32 GMT Subject: RFR: 8282551: Properly initialize L32X64MixRandom state In-Reply-To: <-3q-EOOLQZQgJCyxYos1X2NtQIAcFcWx9DR4uGz5WKU=.518734ce-d17c-4ec1-bc3b-316225821e44@github.com> References: <-3q-EOOLQZQgJCyxYos1X2NtQIAcFcWx9DR4uGz5WKU=.518734ce-d17c-4ec1-bc3b-316225821e44@github.com> Message-ID: On Mon, 21 Feb 2022 19:43:52 GMT, Devin Smith wrote: >> Did a cursory review of the other generators, they seem to set the state correctly. > > I'm not sure how to move this forward, or get the attention of the people responsible for this code. I see @turbanoff you liked and may be involved w/ OpenJDK? Hi @devinrsmith, pull requests in openjdk organization are not actively monitored. You should send a note to [core-libs-dev](https://mail.openjdk.java.net/mailman/listinfo/core-libs-dev) (subscription required), and someone will guide you from there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7120 From djelinski at openjdk.java.net Wed Mar 2 15:23:34 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 2 Mar 2022 15:23:34 GMT Subject: RFR: 8282551: Properly initialize L32X64MixRandom state In-Reply-To: References: Message-ID: <_3wis3IeVr7PJrpQULyr8SWr7eomdPEbbJuMczOzofI=.a7617a9c-1166-4d13-8f0c-38cc5115ea17@github.com> On Tue, 18 Jan 2022 01:39:52 GMT, Devin Smith wrote: > Did a cursory review of the other generators, they seem to set the state correctly. Created https://bugs.openjdk.java.net/browse/JDK-8282551 for this. @devinrsmith please change the issue title to `8282551: Properly initialize L32X64MixRandom state`, then it should be picked up by bots. ------------- PR: https://git.openjdk.java.net/jdk/pull/7120 From duke at openjdk.java.net Wed Mar 2 15:30:06 2022 From: duke at openjdk.java.net (Devin Smith) Date: Wed, 2 Mar 2022 15:30:06 GMT Subject: RFR: 8282551: Properly initialize L32X64MixRandom state In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 01:39:52 GMT, Devin Smith wrote: > Did a cursory review of the other generators, they seem to set the state correctly. Thanks for the help. I signed the OCA on Jan 17, 2022 and got confirmation it was approved on Jan 20, 2022. ------------- PR: https://git.openjdk.java.net/jdk/pull/7120 From maurizio.cimadamore at oracle.com Wed Mar 2 16:19:46 2022 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 2 Mar 2022 16:19:46 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <924583af-919c-56b6-d875-a534f277aaed@oracle.com> References: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> <68ea5542-0866-8583-938f-51b2f5512088@littlepinkcloud.com> <4074cee5-7f6d-889e-9343-52d4894f5961@littlepinkcloud.com> <92191c36-718b-94b8-db42-2d0306d4906a@littlepinkcloud.com> <924583af-919c-56b6-d875-a534f277aaed@oracle.com> Message-ID: <8c5253e6-a84d-09f1-450c-8431943b4e87@oracle.com> On 01/03/2022 18:17, Sean Mullan wrote: > > > On 3/1/22 8:01 AM, Andrew Haley wrote: >> On 3/1/22 11:45, Andrew Haley wrote: >>> Sure, you wouldn't >>> be able to use the default thread pool, but that's no big deal, I >>> would have >>> thought. >> >> I'm sorry, I'll say that again. :-) >> >> >> I meant to say "you wouldn't be able to use the default thread pool if >> you wanted to use threads with some restrictions (e.g those that >> couldn't >> invoke System.exit()). > > Can you explain in a little more detail as to what the compatibility > issues are with preventing threads in thread pools from calling > System.exit? AFAIU, I believe the issue is that threads in the default pool are created early, so they don't see the scope local which overrides the semantics of System.exit. Only threads created _after_ the scope local is set would see the overridden/restricted semantics. Maurizio > > Thanks, > Sean From kcr at openjdk.java.net Wed Mar 2 16:37:02 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Mar 2022 16:37:02 GMT Subject: RFR: 8282551: Properly initialize L32X64MixRandom state In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 15:26:35 GMT, Devin Smith wrote: > Thanks for the help. I signed the OCA on Jan 17, 2022 and got confirmation it was approved on Jan 20, 2022. Correct. Reviewers may know that this has been recorded if the PR has no `oca` label (you can see above that the `oca` label was removed on Jan 20). ------------- PR: https://git.openjdk.java.net/jdk/pull/7120 From duke at openjdk.java.net Wed Mar 2 16:46:08 2022 From: duke at openjdk.java.net (Devin Smith) Date: Wed, 2 Mar 2022 16:46:08 GMT Subject: Integrated: 8282551: Properly initialize L32X64MixRandom state In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 01:39:52 GMT, Devin Smith wrote: > Did a cursory review of the other generators, they seem to set the state correctly. This pull request has now been integrated. Changeset: ce18ff85 Author: Devin Smith Committer: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/ce18ff8527cc51805bf11c50c050ea64c3f9dec0 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8282551: Properly initialize L32X64MixRandom state Reviewed-by: jlaskey ------------- PR: https://git.openjdk.java.net/jdk/pull/7120 From mchung at openjdk.java.net Wed Mar 2 17:10:29 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Mar 2022 17:10:29 GMT Subject: RFR: 8282515: More clean up on NativeLibraries just for JNI library use Message-ID: This patch further cleans up NativeLibraries just for JNI library use. RawNativeLibraries implements its own native load and unload methods. In addition, this also fixes the implementation of `RawNativeLibraries::load` not to throw UnsatisfiedLinkError if a library cannot be loaded for any reason but instead returns null. ------------- Commit messages: - 8282515: More clean up on NativeLibraries just for JNI library use Changes: https://git.openjdk.java.net/jdk/pull/7661/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7661&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282515 Stats: 275 lines in 6 files changed: 175 ins; 28 del; 72 mod Patch: https://git.openjdk.java.net/jdk/pull/7661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7661/head:pull/7661 PR: https://git.openjdk.java.net/jdk/pull/7661 From mcimadamore at openjdk.java.net Wed Mar 2 17:19:58 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 2 Mar 2022 17:19:58 GMT Subject: RFR: 8282515: More clean up on NativeLibraries just for JNI library use In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 17:04:01 GMT, Mandy Chung wrote: > This patch further cleans up NativeLibraries just for JNI library use. RawNativeLibraries implements its own native load and unload methods. In addition, this also fixes the implementation of `RawNativeLibraries::load` not to throw UnsatisfiedLinkError if a library cannot be loaded for any reason but instead returns null. Looks good - thanks for cleaning up further. I think separating the library implementation makes a lot of sense. There's some duplication at the native level, but that's acceptable IMHO - and probably better than having a shared piece of logic that can work in two very different modes. src/java.base/share/native/libjava/RawNativeLibraries.c line 98: > 96: JVM_UnloadLibrary(handle); > 97: JNU_ReleaseStringPlatformChars(env, name, cname); > 98: } Watch out for the newline ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7661 From mchung at openjdk.java.net Wed Mar 2 17:53:48 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Mar 2022 17:53:48 GMT Subject: RFR: 8282515: More clean up on NativeLibraries just for JNI library use [v2] In-Reply-To: References: Message-ID: > This patch further cleans up NativeLibraries just for JNI library use. RawNativeLibraries implements its own native load and unload methods. In addition, this also fixes the implementation of `RawNativeLibraries::load` not to throw UnsatisfiedLinkError if a library cannot be loaded for any reason but instead returns null. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: fix no newline at end of file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7661/files - new: https://git.openjdk.java.net/jdk/pull/7661/files/eae60a40..cbdc39ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7661&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7661&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7661.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7661/head:pull/7661 PR: https://git.openjdk.java.net/jdk/pull/7661 From mchung at openjdk.java.net Wed Mar 2 17:53:49 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Mar 2022 17:53:49 GMT Subject: RFR: 8282515: More clean up on NativeLibraries just for JNI library use In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 17:04:01 GMT, Mandy Chung wrote: > This patch further cleans up NativeLibraries just for JNI library use. RawNativeLibraries implements its own native load and unload methods. In addition, this also fixes the implementation of `RawNativeLibraries::load` not to throw UnsatisfiedLinkError if a library cannot be loaded for any reason but instead returns null. Thanks for the review. I also think this is better and cleaner separation. The duplicated native code is small and they just call `JVM_LoadLibrary` and `JVM_UnloadLibrary` that makes it very clear what this native method does. ------------- PR: https://git.openjdk.java.net/jdk/pull/7661 From erikj at openjdk.java.net Wed Mar 2 18:04:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Mar 2022 18:04:17 GMT Subject: RFR: 8209784: Include hsdis in the JDK [v3] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 14:30:43 GMT, Magnus Ihse Bursie wrote: >> This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. >> >> The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > install-hsdis needs to depend on jdk-image Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7578 From ihse at openjdk.java.net Wed Mar 2 18:22:06 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 2 Mar 2022 18:22:06 GMT Subject: Integrated: 8209784: Include hsdis in the JDK In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 16:10:22 GMT, Magnus Ihse Bursie wrote: > This PR adds a new configure argument, `--enable-hsdis-bundling`. Setting this, together with a valid backend using `--with-hsdis`, will bundle the generated hsdis library with the JDK. > > The PR also includes a refactoring of the hsdis handling in autoconf, breaking it out to a separate file `lib-hsdis.gmk`, and breaking the functionality up in separate functions per backend. This pull request has now been integrated. Changeset: b6c35ae4 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/b6c35ae44aeb31deb7a15ee2939156ed00b3df52 Stats: 676 lines in 8 files changed: 386 ins; 276 del; 14 mod 8209784: Include hsdis in the JDK Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/7578 From duke at openjdk.java.net Wed Mar 2 18:42:10 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 2 Mar 2022 18:42:10 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v21] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6mFYWoJaIc5HYadyTYfUgq5a69OwVSgWfo1RiemERIg=.e18aeb23-3596-4ae4-bcfa-1152c2f5117c@github.com> <9HiZ4sHd0jS7asQFUxOEK8MNKdfjfb4a8zhntVACDHA=.98ec5cf9-8228-4363-9f61-263f56ddd620@github.com> Message-ID: On Wed, 2 Mar 2022 01:44:24 GMT, Stuart Marks wrote: > I'm starting to look at this again. First, a quick note -- I don't think there should be any IdentityHashMap changes here. That uses a completely different internal structure and allocation policy, and it's kind of a distraction from the main point of this change. (As the preceding chain of comments illustrates.) > > There is a question of whether IdentityHashMap ought to "allow for some growth" when copying a map, but it's hard to see how much of a problem this really is. I'd suggest focusing on getting this change done, and then (if you still have energy) to try to eradicate the `(int) (expected / 0.75) + 1` idiom that's sprinkled around the JDK. OK, will split this part from this pr. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Wed Mar 2 18:48:46 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 2 Mar 2022 18:48:46 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v23] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: revert changes to IdentityHashMap ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/e724cc04..475e040f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=22 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=21-22 Stats: 16 lines in 2 files changed: 0 ins; 13 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Wed Mar 2 18:48:48 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 2 Mar 2022 18:48:48 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v19] In-Reply-To: <7n0zRL2aNC--r9BVCQ0whdD7h_Auy091iVRe4t4tFEM=.f3b8b1c8-7fe0-4d8b-87ff-b5dc839fb7c0@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <1AW2iddnLOTU-np_YhZgGuFx9MLgl0yX4qKtPFiFELM=.4f4c8a42-1ffa-4dfe-acb0-df1487d6a49c@github.com> <7n0zRL2aNC--r9BVCQ0whdD7h_Auy091iVRe4t4tFEM=.f3b8b1c8-7fe0-4d8b-87ff-b5dc839fb7c0@github.com> Message-ID: On Fri, 18 Feb 2022 18:32:31 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with two additional commits since the last revision: >> >> - migrate to junit >> - change threshold > > Sigh. (I'm sighing at the author of the Enum/ConstantDirectoryOptimalCapacity.java test, not you.) What a mess. See https://bugs.openjdk.java.net/browse/JDK-8282120 which I just filed. The broken test and the OptimalCapacity utilities are mostly useless, so the change to that test and Class.java should be removed this PR, and the test added to the Problem List so it doesn't get run anymore. See test/jdk/ProblemList.txt and add an entry for the now-failing test, with a reference to 8282120. > > I don't think I'll have time to look at the junit rewrite and to run this through our internal build/test system today, so sorry, this may need to wait a week. @stuart-marks changes to IdentityHashMap reverted. please review again. thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Wed Mar 2 19:16:26 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 2 Mar 2022 19:16:26 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame Message-ID: The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: final ClassLoader loader = (caller != null) ? caller.getClassLoader() : getLoader(getCallerModule(caller)); A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. The javadoc was updated for the caller sensitive methods changed. ------------- Commit messages: - Use the unnamed module defined to the system class loader instead of the - JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame Changes: https://git.openjdk.java.net/jdk/pull/7663/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280902 Stats: 265 lines in 4 files changed: 254 ins; 3 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663 PR: https://git.openjdk.java.net/jdk/pull/7663 From psandoz at openjdk.java.net Wed Mar 2 19:17:04 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 2 Mar 2022 19:17:04 GMT Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate feature In-Reply-To: References: Message-ID: <3Eb4XMw6WAiao9pQW6BfchjrwQ4qju9nL8hG0HL9psk=.aa63fea9-c727-4a34-9b87-e78fea9d027a@github.com> On Wed, 2 Mar 2022 02:50:27 GMT, Xiaohong Gong wrote: > The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature. > > This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE: > > mov z19.d, #0 > cmpgt p1.d, p7/z, z19.d, z17.d > and p0.b, p7/z, p1.b, p0.b > > are optimized to: > > mov z19.d, #0 > cmpgt p0.d, p0/z, z19.d, z17.d > > Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java line 1737: > 1735: , > 1736: M2 extends VectorMask> > 1737: M1 testTemplate(Class maskType, Test op, M2 mask) { Can we simplify by making some code FP specific? - the mask `cast` can be applied in this method rather than in the caller, simplifying the signature - for clarify, vector `viewAsIntegralLanes` is only needed for FP (update would be required for the non-mask template). src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java line 1766: > 1764: throw new AssertionError(op); > 1765: } > 1766: return maskType.cast(m.cast(this.vspecies())); Suggestion: return maskType.cast(m.cast(vsp)); Same for non-mask template too. test/jdk/jdk/incubator/vector/templates/Unit-Test.template line 29: > 27: VectorMask<$Wideboxtype$> vmask = VectorMask.fromArray(SPECIES, mask, 0); > 28: > 29: for (int ic = 0; ic < INVOC_COUNT; ic++) { Can you remove `SmokeTest` from the method name. ------------- PR: https://git.openjdk.java.net/jdk/pull/7654 From naoto at openjdk.java.net Wed Mar 2 19:55:13 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 2 Mar 2022 19:55:13 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing wrote: > The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. Looks good to me. I believe a CSR is needed for this change. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7663 From mchung at openjdk.java.net Wed Mar 2 20:34:08 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Mar 2022 20:34:08 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame In-Reply-To: References: Message-ID: <7oA9HtlO1-ONvq9YAJX1GXghSrvk534cGlyRkW0Wa8w=.bbc15ace-7028-4f7c-9386-ee7181fabb9a@github.com> On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing wrote: > The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. Instead of sprinkling the null caller text in the javadoc in each `getBundle` method, we can specify that that in the class specification, for example, after the "Resource bundles in other modules and class path" section. In cases where the {@code getBundle} factory method is called from a context where there is no caller frame on the stack (e.g. when called directly from a JNI attached thread), the caller module is default to the unnamed module for the {@linkplain ClassLoader#getSystemClassLoader system class loader}. What do you think? src/java.base/share/classes/java/util/ResourceBundle.java line 1588: > 1586: Control control) { > 1587: final ClassLoader loader = (caller != null) ? > 1588: caller.getClassLoader() : getLoader(getCallerModule(caller)); Suggestion: ClassLoader loader = getLoader(getCallerModule(caller)); This can be simplified as above. I would drop `final` too as it only adds noise to the code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7663 From darcy at openjdk.java.net Wed Mar 2 20:36:27 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 2 Mar 2022 20:36:27 GMT Subject: RFR: JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method Message-ID: Refactoring of Method and Constructor to share a single empty array for parameters and exceptions as well as type variables. Existing core reflection regression tests pass with the change. ------------- Commit messages: - JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method Changes: https://git.openjdk.java.net/jdk/pull/7667/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7667&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8177107 Stats: 15 lines in 3 files changed: 9 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7667.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7667/head:pull/7667 PR: https://git.openjdk.java.net/jdk/pull/7667 From darcy at openjdk.java.net Wed Mar 2 20:42:09 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 2 Mar 2022 20:42:09 GMT Subject: RFR: JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 20:28:45 GMT, Joe Darcy wrote: > Refactoring of Method and Constructor to share a single empty array for parameters and exceptions as well as type variables. > > Existing core reflection regression tests pass with the change. PS I'll update the copyrights before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7667 From duke at openjdk.java.net Wed Mar 2 21:31:58 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 2 Mar 2022 21:31:58 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v2] In-Reply-To: References: Message-ID: > The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/util/ResourceBundle.java Co-authored-by: Mandy Chung ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7663/files - new: https://git.openjdk.java.net/jdk/pull/7663/files/30778063..9e8fb193 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663 PR: https://git.openjdk.java.net/jdk/pull/7663 From duke at openjdk.java.net Wed Mar 2 21:53:01 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 2 Mar 2022 21:53:01 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v3] In-Reply-To: References: Message-ID: <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com> > The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: suggested changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7663/files - new: https://git.openjdk.java.net/jdk/pull/7663/files/9e8fb193..eeb2d0fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=01-02 Stats: 48 lines in 1 file changed: 6 ins; 41 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663 PR: https://git.openjdk.java.net/jdk/pull/7663 From valeriep at openjdk.java.net Wed Mar 2 22:30:07 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 2 Mar 2022 22:30:07 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 04:02:45 GMT, Anthony Scarpino wrote: > I have some compatibility concerns about the AES change breaking code that expects a SecretKeySpec of 16 bytes. I can see situations where '.getEncoded()' returns a byte[32] when user code expects a byte[16]. Also, I'm pretty sure passing a 32 byte SecretKeySpec into an AES_128_GCM op will throw an exception. I haven't looked at other modes. Well, I am not sure how specifying a 32-byte SecretKeySpec (instance of a SecretKey) with AES Cipher would trigger AES_128_GCM op? Shouldn't the keysize be detected when Cipher.init() is called and then invoking the right op? True that this default key size change would impact callers who do not specify key size but then made the assumption of key being 16-byte. Well, the key generator javadoc did warn about not setting a default, i.e. different providers may have different default key size and that the default key size may change later for the same provider. So, it's not like we have not warned about it... ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From mchung at openjdk.java.net Wed Mar 2 22:44:16 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Mar 2022 22:44:16 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v3] In-Reply-To: <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com> References: <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com> Message-ID: On Wed, 2 Mar 2022 21:53:01 GMT, Tim Prinzing wrote: >> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. >> >> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: >> >> final ClassLoader loader = (caller != null) ? >> caller.getClassLoader() : getLoader(getCallerModule(caller)); >> >> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. >> >> The javadoc was updated for the caller sensitive methods changed. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > suggested changes Thanks for the update. src/java.base/share/classes/java/util/ResourceBundle.java line 1567: > 1565: * module will be used. > 1566: * @param caller > 1567: * @return Maybe you intended to make this `/* .... */` instead of javadoc? no need to have `@param` and `@return` for this simple method. src/java.base/share/classes/java/util/ResourceBundle.java line 2251: > 2249: @CallerSensitive > 2250: public static final void clearCache() { > 2251: final Module callerModule = getCallerModule(Reflection.getCallerClass()); nit: final can be dropped here. test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/NullCallerResourceBundle.java line 52: > 50: import java.nio.file.Paths; > 51: import java.util.Properties; > 52: import java.util.ResourceBundle; nit: good to keep the imports in alphabetic order. test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/NullCallerResourceBundle.java line 74: > 72: > 73: // set up shared library path > 74: final String sharedLibraryPathEnvName = Platform.sharedLibraryPathVariableName(); Nit: `final` adds noise but no other value to the test. Can consider dropping it. test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/NullCallerResourceBundle.java line 89: > 87: > 88: > 89: private static void makePropertiesFile() throws IOException { This can be removed? test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/exeNullCallerResourceBundle.c line 28: > 26: > 27: #include "jni.h" > 28: #undef NDEBUG is this line unintended? ------------- PR: https://git.openjdk.java.net/jdk/pull/7663 From lucy at openjdk.java.net Wed Mar 2 22:44:24 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 2 Mar 2022 22:44:24 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 14:06:10 GMT, Claes Redestad 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 29 commits: >> >> - Resolve merge conflict >> - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) >> - aarch64: fix issue with short inputs divisible by wordSize >> - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. >> - Revert micro changes, split out to #7516 >> - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives >> - Merge branch 'master' into count_positives >> - Restore partial vector checks in AVX2 and SSE intrinsic variants >> - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral >> - Simplify changes to encodeUTF8 >> - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce > >> > > Making the `bottom_type()` of `CountPositivesNode` more precise (`TypeInt::INT` -> `TypeInt::POS`) might help, then. Seems like something we want to do regardless. @cl4es Looks like you forgot to remove the "@IntrinsicCandidate" annotation for has_negatives. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From mchung at openjdk.java.net Wed Mar 2 22:48:05 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 2 Mar 2022 22:48:05 GMT Subject: RFR: JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 20:28:45 GMT, Joe Darcy wrote: > Refactoring of Method and Constructor to share a single empty array for parameters and exceptions as well as type variables. > > Existing core reflection regression tests pass with the change. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7667 From sviswanathan at openjdk.java.net Wed Mar 2 23:27:08 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 2 Mar 2022 23:27:08 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: <1K0c0y8K8bVNJEFMyTQSxwdgJlx9E2N8uhHC7O9sfyM=.c4ead8b5-abe0-42f4-ae10-aa24425eb75d@github.com> <8mhsd-DL1IccFiqrRigKdck8OJg79sjKgaYXrHc4zwY=.c92cb7f5-8e54-42ab-84f1-9cfa1ce76779@github.com> Message-ID: On Sat, 26 Feb 2022 03:38:32 GMT, Quan Anh Mai wrote: >> I believe the indefinite value should be 2^(w - 1) (a.k.a 0x80000000) and the documentation is typoed. If you look at `cvtss2si`, the indefinite value is also written as 2^w - 1 but yet in `MacroAssembler::convert_f2i` we compare it with 0x80000000. In addition, choosing -1 as an indefinite value is weird enough and to complicate it as 2^w - 1 is really unusual. > > `MacroAssembler::convert_f2i` > > https://github.com/openjdk/jdk/blob/c5c6058fd57d4b594012035eaf18a57257f4ad85/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L8919 @jatin-bhateja @merykitty You are right, on overflow we observe 2^(w - 1) i.e. 0x8000 0000 so using vector_float_signflip() is correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From sviswanathan at openjdk.java.net Wed Mar 2 23:32:05 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 2 Mar 2022 23:32:05 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v11] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Removing +LogCompilation flag. Marked as reviewed by sviswanathan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From sviswanathan at openjdk.java.net Wed Mar 2 23:32:06 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 2 Mar 2022 23:32:06 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: On Sat, 26 Feb 2022 04:55:08 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Adding descriptive comments. > > As per SDM, if post conversion a floating point number is non-representable in destination format e.g. a floating point value 3.4028235E10 post integer conversion will overflow the value range of integer primitive type, hence a -0.0 value or 0x80000000 is returned here. Similarly for +/- NaN and +/-Inf post conversion value returns is -0.0. All these cases i.e. post conversion non-representable floating point values and NaN/Inf values are handled in a special manner where algorithm first performs an unordered comparison b/w original source value and returns a 0 in case of NaN, this weeds out the NaN case and for rest of the special values we check the MSB bit of the source and either return an Integer.MAX_VALUE for +ve numbers or a Integer.MIN_VALUE to adhere to the semantics of Math.round API. > > Existing tests were enhanced to cover various special cases (NaN/Inf/+ve/-ve value/values which may be inexact after adding 0.5/ values which post conversion overflow integer value range). @jatin-bhateja The patch looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From sviswanathan at openjdk.java.net Wed Mar 2 23:32:07 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 2 Mar 2022 23:32:07 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: On Sat, 26 Feb 2022 01:07:47 GMT, Sandhya Viswanathan wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Adding descriptive comments. > > src/hotspot/cpu/x86/x86.ad line 7295: > >> 7293: __ vector_round_double_evex($dst$$XMMRegister, $src$$XMMRegister, $xtmp1$$XMMRegister, >> 7294: $xtmp2$$XMMRegister, $ktmp1$$KRegister, $ktmp2$$KRegister, >> 7295: ExternalAddress(vector_double_signflip()), new_mxcsr, $scratch$$Register, vlen_enc); > > The vector_double_signflip() here should be replaced by vector_all_bits_set(). > vcvtpd2qq description: > If a converted result cannot be represented in the destination > format, the floating-point invalid exception is raised, and if this exception is masked, the indefinite integer value > (2w-1, where w represents the number of bits in the destination format) is returned. The overflow value observed is 2^(w-1) so using vector_double_signflip() is correct, please ignore this comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From mchung at openjdk.java.net Thu Mar 3 01:54:08 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Mar 2022 01:54:08 GMT Subject: Integrated: 8282515: More clean up on NativeLibraries just for JNI library use In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 17:04:01 GMT, Mandy Chung wrote: > This patch further cleans up NativeLibraries just for JNI library use. RawNativeLibraries implements its own native load and unload methods. In addition, this also fixes the implementation of `RawNativeLibraries::load` not to throw UnsatisfiedLinkError if a library cannot be loaded for any reason but instead returns null. This pull request has now been integrated. Changeset: 02aa7cef Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/02aa7cef0a9b9de1ee9a136c5641b498c0c3e5cc Stats: 276 lines in 6 files changed: 176 ins; 28 del; 72 mod 8282515: More clean up on NativeLibraries just for JNI library use Reviewed-by: mcimadamore ------------- PR: https://git.openjdk.java.net/jdk/pull/7661 From xliu at openjdk.java.net Thu Mar 3 02:44:15 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 3 Mar 2022 02:44:15 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings Message-ID: If AbstractStringBuilder only grow, the inflated value which is encoded in UTF16 can't be compressed. toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress. java.io.BufferedRead::readLine() is a case that StringBuilder grows only. ------------- Commit messages: - Add a microbenchmark. - 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings Changes: https://git.openjdk.java.net/jdk/pull/7671/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282429 Stats: 44 lines in 5 files changed: 37 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671 From jbhateja at openjdk.java.net Thu Mar 3 05:46:09 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 3 Mar 2022 05:46:09 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: References: Message-ID: <3JoM4khNMz85gwfyxZeBNxJCZ_B7826cc-iO4pHtTJM=.5b21a96e-b2f5-4093-a763-eec2b6d77a2e@github.com> On Wed, 19 Jan 2022 22:09:26 GMT, Joe Darcy wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Adding a test for scalar intrinsification. > > The testing for this PR doesn't look adequate to me. I don't see any testing for the values where the behavior of round has been redefined at points in the last decade. See JDK-8010430 and JDK-6430675, both of which have regression tests in the core libs area. Thanks. Hi @jddarcy , can you kindly validate your feedback, it has been incorporated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From smarks at openjdk.java.net Thu Mar 3 06:38:00 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 3 Mar 2022 06:38:00 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v23] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Wed, 2 Mar 2022 18:48:46 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > revert changes to IdentityHashMap src/java.base/share/classes/java/util/HashMap.java line 498: > 496: if (s > 0) { > 497: if (table == null) { // pre-size > 498: double dt = Math.ceil(s / loadFactor); Quick update on this. The division must be done in double, not float, before being passed to `Math.ceil`. I'd recommend casting the load factor to double: double dt = Math.ceil(s / (double) loadFactor); The reason is that the significand of a float has only 24 bits, so the low order 8 bits of the eventual `int` will end up being zeroes even when they have some significant values. This starts to occur at larger sizes. For example, if `s` is 25165825, the result is 33554434.0 with double division but it's only 33554432.0 with float division. This latter value is too small, so if it were used the HashMap would need to be resized when `s` mappings are added. Similar changes should be made in `readObject` below and in `WeakHashMap`. I haven't had a chance to look at the test yet, sorry. You might want think about how to test for cases like this. Don't go off the deep end though. I don't think we want to have a test that creates lots of maps with 25 million entries, and we also don't want to duplicate the computations in the test itself like the Enum ConstantDirectory test does. src/java.base/share/classes/java/util/HashMap.java line 1530: > 1528: // use defaults > 1529: } else if (mappings > 0) { > 1530: double dc = Math.ceil(mappings / lf); As above, cast `lf` to `double`. src/java.base/share/classes/java/util/WeakHashMap.java line 252: > 250: */ > 251: public WeakHashMap(Map m) { > 252: this(Math.max((int) Math.ceil(m.size() / 0.75), Use `(double) DEFAULT_LOAD_FACTOR` in the denominator. src/java.base/share/classes/java/util/WeakHashMap.java line 558: > 556: */ > 557: if (numKeysToBeAdded > threshold) { > 558: int targetCapacity = (int)Math.ceil(numKeysToBeAdded / loadFactor); Cast to double here too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From djelinski at openjdk.java.net Thu Mar 3 08:11:05 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 3 Mar 2022 08:11:05 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 02:36:58 GMT, Xin Liu wrote: > If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. > toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). > > java.io.BufferedRead::readLine() is a case that StringBuilder grows only. > > In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. > > Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. > > Before: > > $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms > > > After > > $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 546: > 544: StringUTF16.putCharSB(value, index, ch); > 545: } > 546: growOnly = false; Any changes that take place while the string is still latin1 do not make it potentially compressible. You could move this assignment to the `else` clause for some additional possible performance boost. But then the variable name would be misleading. ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From xgong at openjdk.java.net Thu Mar 3 08:12:46 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 3 Mar 2022 08:12:46 GMT Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate feature [v2] In-Reply-To: References: Message-ID: > The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature. > > This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE: > > mov z19.d, #0 > cmpgt p1.d, p7/z, z19.d, z17.d > and p0.b, p7/z, p1.b, p0.b > > are optimized to: > > mov z19.d, #0 > cmpgt p0.d, p0/z, z19.d, z17.d > > Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2. Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Simply the testTemplate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7654/files - new: https://git.openjdk.java.net/jdk/pull/7654/files/41a9d56f..c90d2f49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7654&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7654&range=00-01 Stats: 197 lines in 49 files changed: 13 ins; 33 del; 151 mod Patch: https://git.openjdk.java.net/jdk/pull/7654.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7654/head:pull/7654 PR: https://git.openjdk.java.net/jdk/pull/7654 From xgong at openjdk.java.net Thu Mar 3 08:12:48 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 3 Mar 2022 08:12:48 GMT Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate feature In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 02:50:27 GMT, Xiaohong Gong wrote: > The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature. > > This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE: > > mov z19.d, #0 > cmpgt p1.d, p7/z, z19.d, z17.d > and p0.b, p7/z, p1.b, p0.b > > are optimized to: > > mov z19.d, #0 > cmpgt p0.d, p0/z, z19.d, z17.d > > Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2. Hi @PaulSandoz , thanks for your review! All the comments have been address. Could you please take a look at it again? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7654 From djelinski at openjdk.java.net Thu Mar 3 08:14:05 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Thu, 3 Mar 2022 08:14:05 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 02:36:58 GMT, Xin Liu wrote: > If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. > toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). > > java.io.BufferedRead::readLine() is a case that StringBuilder grows only. > > In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. > > Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. > > Before: > > $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms > > > After > > $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms src/java.base/share/classes/java/lang/StringBuffer.java line 715: > 713: public synchronized String toString() { > 714: if (toStringCache == null) { > 715: return toStringCache = new String(this); When you modify a method labeled `IntrinsicCandidate`, you should probably modify the intrinsic as well ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From lancea at openjdk.java.net Thu Mar 3 11:25:37 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Mar 2022 11:25:37 GMT Subject: RFR: 8280404: Unexpected exception thrown when CEN file entry comment length is not valid Message-ID: Hi all, This PR addresses an issue where an unexpected exception is thrown when the CEN file entry comment length is not correct. Mach5 tiers 1 - 3 run clean with this change. ------------- Commit messages: - Correct bug number in test - Validate comment if it exists when processing the CEN Changes: https://git.openjdk.java.net/jdk/pull/7673/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7673&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280404 Stats: 353 lines in 2 files changed: 352 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7673.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7673/head:pull/7673 PR: https://git.openjdk.java.net/jdk/pull/7673 From redestad at openjdk.java.net Thu Mar 3 12:04:47 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 12:04:47 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Document that it's allowed for implementations to return values less than the exact count (iff there are negative bytes) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/3207c098..85be36ae Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=07-08 Stats: 11 lines in 2 files changed: 5 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From alanb at openjdk.java.net Thu Mar 3 12:07:06 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 3 Mar 2022 12:07:06 GMT Subject: RFR: 8280404: Unexpected exception thrown when CEN file entry comment length is not valid In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 11:19:12 GMT, Lance Andersen wrote: > Hi all, > > This PR addresses an issue where an unexpected exception is thrown when the CEN file entry comment length is not correct. > > Mach5 tiers 1 - 3 run clean with this change. src/java.base/share/classes/java/util/zip/ZipFile.java line 1214: > 1212: int elen = CENEXT(cen, pos); > 1213: int start = entryPos + nlen + elen; > 1214: zcp.toString(cen, start, clen); The change look okay but you may want to put another comment on zcp.toString to say that it may throw, otherwise something looking at the code might wonder if it can be removed as the returned String is not used. ------------- PR: https://git.openjdk.java.net/jdk/pull/7673 From redestad at openjdk.java.net Thu Mar 3 12:14:10 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 12:14:10 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v6] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 14:06:10 GMT, Claes Redestad 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 29 commits: >> >> - Resolve merge conflict >> - Fix TestCountPositives to correctly allow 0 return when expected != len (for now) >> - aarch64: fix issue with short inputs divisible by wordSize >> - Switch aarch64 intrinsic to a variant of countPositives returning len or zero as a first step. >> - Revert micro changes, split out to #7516 >> - Merge branch 'master' of https://github.com/cl4es/jdk into count_positives >> - Merge branch 'master' into count_positives >> - Restore partial vector checks in AVX2 and SSE intrinsic variants >> - Let countPositives use hasNegatives to allow ports not implementing the countPositives intrinsic to stay neutral >> - Simplify changes to encodeUTF8 >> - ... and 19 more: https://git.openjdk.java.net/jdk/compare/5035bf5e...685795ce > >> > > Making the `bottom_type()` of `CountPositivesNode` more precise (`TypeInt::INT` -> `TypeInt::POS`) might help, then. Seems like something we want to do regardless. > @cl4es Looks like you forgot to remove the "@IntrinsicCandidate" annotation for has_negatives. I was going back and forth on this since the annotation might be used as a useful marker by other JVM implementors, so wasn't sure if removing the annotation would need to go through a deprecation cycle. I've removed it now; let's see if there are any objections to that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From tanksherman27 at gmail.com Thu Mar 3 12:33:48 2022 From: tanksherman27 at gmail.com (Jules W.) Date: Thu, 3 Mar 2022 20:33:48 +0800 Subject: PriorityQueue PR requiring review Message-ID: Hi all, A new PR that adds methods to PriorityQueue was created some time ago at https://github.com/openjdk/jdk/pull/6938 but has no corresponding issue. As I'm not too familiar with this part of the JDK I'm querying this mailing list for anyone to properly review the PR before I create an issue for it in the JBS best regards, Julian Waters From aph at openjdk.java.net Thu Mar 3 12:34:07 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 3 Mar 2022 12:34:07 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 12:04:47 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Document that it's allowed for implementations to return values less than the exact count (iff there are negative bytes) > * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already? ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From david.holmes at oracle.com Thu Mar 3 12:45:09 2022 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Mar 2022 22:45:09 +1000 Subject: PriorityQueue PR requiring review In-Reply-To: References: Message-ID: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> Hi Julian, On 3/03/2022 10:33 pm, Jules W. wrote: > Hi all, > > A new PR that adds methods to PriorityQueue was created some time ago at > https://github.com/openjdk/jdk/pull/6938 but has no corresponding issue. As > I'm not too familiar with this part of the JDK I'm querying this mailing > list for anyone to properly review the PR before I create an issue for it > in the JBS First you need an issue, then you review a PR. Your PR would not be seen by anyone unless they go looking for it, as without the association with an issue, the system will not send the email to the mailing lists. I see someone is helping you create the issue so things should progress in that sense. But note the bar for adding to a public API is set very high. Cheers, David > best regards, > Julian Waters From david.holmes at oracle.com Thu Mar 3 12:47:23 2022 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Mar 2022 22:47:23 +1000 Subject: PriorityQueue PR requiring review In-Reply-To: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> References: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> Message-ID: <21e53591-1afa-ff89-731c-781bec2b6c13@oracle.com> Sorry Julian, I see now you were the person aiding the person who created the PR. David On 3/03/2022 10:45 pm, David Holmes wrote: > Hi Julian, > > On 3/03/2022 10:33 pm, Jules W. wrote: >> Hi all, >> >> A new PR that adds methods to PriorityQueue was created some time ago at >> https://github.com/openjdk/jdk/pull/6938 but has no corresponding >> issue. As >> I'm not too familiar with this part of the JDK I'm querying this mailing >> list for anyone to properly review the PR before I create an issue for it >> in the JBS > > First you need an issue, then you review a PR. Your PR would not be seen > by anyone unless they go looking for it, as without the association with > an issue, the system will not send the email to the mailing lists. > > I see someone is helping you create the issue so things should progress > in that sense. But note the bar for adding to a public API is set very > high. > > Cheers, > David > >> best regards, >> Julian Waters From tanksherman27 at gmail.com Thu Mar 3 12:47:55 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 3 Mar 2022 20:47:55 +0800 Subject: PriorityQueue PR requiring review In-Reply-To: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> References: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> Message-ID: Hi David, I did not create the PR, I'm instead asking for others to review it before I help the author create the issue on the JBS. Should I just go ahead and create the issue for them? best regards, Julian On Thu, Mar 3, 2022 at 8:45 PM David Holmes wrote: > Hi Julian, > > On 3/03/2022 10:33 pm, Jules W. wrote: > > Hi all, > > > > A new PR that adds methods to PriorityQueue was created some time ago at > > https://github.com/openjdk/jdk/pull/6938 but has no corresponding > issue. As > > I'm not too familiar with this part of the JDK I'm querying this mailing > > list for anyone to properly review the PR before I create an issue for it > > in the JBS > > First you need an issue, then you review a PR. Your PR would not be seen > by anyone unless they go looking for it, as without the association with > an issue, the system will not send the email to the mailing lists. > > I see someone is helping you create the issue so things should progress > in that sense. But note the bar for adding to a public API is set very > high. > > Cheers, > David > > > best regards, > > Julian Waters > From tanksherman27 at gmail.com Thu Mar 3 12:48:32 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 3 Mar 2022 20:48:32 +0800 Subject: PriorityQueue PR requiring review In-Reply-To: <21e53591-1afa-ff89-731c-781bec2b6c13@oracle.com> References: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> <21e53591-1afa-ff89-731c-781bec2b6c13@oracle.com> Message-ID: Hi David, No worries :) regards, Julian On Thu, Mar 3, 2022 at 8:47 PM David Holmes wrote: > Sorry Julian, I see now you were the person aiding the person who > created the PR. > > David > > On 3/03/2022 10:45 pm, David Holmes wrote: > > Hi Julian, > > > > On 3/03/2022 10:33 pm, Jules W. wrote: > >> Hi all, > >> > >> A new PR that adds methods to PriorityQueue was created some time ago at > >> https://github.com/openjdk/jdk/pull/6938 but has no corresponding > >> issue. As > >> I'm not too familiar with this part of the JDK I'm querying this mailing > >> list for anyone to properly review the PR before I create an issue for > it > >> in the JBS > > > > First you need an issue, then you review a PR. Your PR would not be seen > > by anyone unless they go looking for it, as without the association with > > an issue, the system will not send the email to the mailing lists. > > > > I see someone is helping you create the issue so things should progress > > in that sense. But note the bar for adding to a public API is set very > > high. > > > > Cheers, > > David > > > >> best regards, > >> Julian Waters > From redestad at openjdk.java.net Thu Mar 3 12:49:06 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 12:49:06 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: References: Message-ID: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com> On Thu, 3 Mar 2022 12:30:29 GMT, Andrew Haley wrote: > > ``` > > * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > ``` > > I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already? Still looking into it in detail, but the shape of the code at the bytecode level is different, so generated code looks quite different, which means the logical branches can be laid out differently, or just placed in a different order. The 5% in this particular test could easily be due to getting a different order of the tests for determining if a byte is ascii or latin1. I'm also in the process of measuring in detail after narrowing down the `bottom_type()` of the intrinsic and a few other recent fixes that could affect code generation in C2. Will also benchmark on aarch64 and report back. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From david.holmes at oracle.com Thu Mar 3 12:57:32 2022 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Mar 2022 22:57:32 +1000 Subject: PriorityQueue PR requiring review In-Reply-To: References: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> Message-ID: On 3/03/2022 10:47 pm, Julian Waters wrote: > Hi David, > > I did not create the PR, I'm instead asking for others to review it > before I help the author create the issue on the JBS. Should I just go > ahead and create the issue for them? The best thing would be for the PR creator to discuss the proposed API addition on the mailing list first. I have a fairly good idea what the outcome of that discussion will be but ... :) Cheers, David > best regards, > Julian > > On Thu, Mar 3, 2022 at 8:45 PM David Holmes > wrote: > > Hi Julian, > > On 3/03/2022 10:33 pm, Jules W. wrote: > > Hi all, > > > > A new PR that adds methods to PriorityQueue was created some time > ago at > > https://github.com/openjdk/jdk/pull/6938 > but has no corresponding > issue. As > > I'm not too familiar with this part of the JDK I'm querying this > mailing > > list for anyone to properly review the PR before I create an > issue for it > > in the JBS > > First you need an issue, then you review a PR. Your PR would not be > seen > by anyone unless they go looking for it, as without the association > with > an issue, the system will not send the email to the mailing lists. > > I see someone is helping you create the issue so things should progress > in that sense. But note the bar for adding to a public API is set > very high. > > Cheers, > David > > > best regards, > > Julian Waters > From tanksherman27 at gmail.com Thu Mar 3 13:02:22 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 3 Mar 2022 21:02:22 +0800 Subject: PriorityQueue PR requiring review In-Reply-To: References: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> Message-ID: I understand, I'll notify the author about this. I'm not sure if they'll be alright with discussing on the mailing lists though, since they have expressed that they prefer discussing it on the PR itself best regards, Julian Waters On Thu, Mar 3, 2022 at 8:57 PM David Holmes wrote: > On 3/03/2022 10:47 pm, Julian Waters wrote: > > Hi David, > > > > I did not create the PR, I'm instead asking for others to review it > > before I help the author create the issue on the JBS. Should I just go > > ahead and create the issue for them? > > The best thing would be for the PR creator to discuss the proposed API > addition on the mailing list first. I have a fairly good idea what the > outcome of that discussion will be but ... :) > > Cheers, > David > > > best regards, > > Julian > > > > On Thu, Mar 3, 2022 at 8:45 PM David Holmes > > wrote: > > > > Hi Julian, > > > > On 3/03/2022 10:33 pm, Jules W. wrote: > > > Hi all, > > > > > > A new PR that adds methods to PriorityQueue was created some time > > ago at > > > https://github.com/openjdk/jdk/pull/6938 > > but has no corresponding > > issue. As > > > I'm not too familiar with this part of the JDK I'm querying this > > mailing > > > list for anyone to properly review the PR before I create an > > issue for it > > > in the JBS > > > > First you need an issue, then you review a PR. Your PR would not be > > seen > > by anyone unless they go looking for it, as without the association > > with > > an issue, the system will not send the email to the mailing lists. > > > > I see someone is helping you create the issue so things should > progress > > in that sense. But note the bar for adding to a public API is set > > very high. > > > > Cheers, > > David > > > > > best regards, > > > Julian Waters > > > From lucy at openjdk.java.net Thu Mar 3 13:25:03 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 3 Mar 2022 13:25:03 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com> References: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com> Message-ID: On Thu, 3 Mar 2022 12:45:51 GMT, Claes Redestad wrote: >>> * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). >> >> I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already? > >> > ``` >> > * There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). >> > ``` >> >> I'm not sure that we can disregard such cases. You're probably right, but it'd be interesting to know the actual cause of the problem, perhaps with perfasm. Or do you know already? > > Still looking into it in detail, but the shape of the code at the bytecode level is different, so generated code looks quite different, which means the logical branches can be laid out differently, or just placed in a different order. The 5% in this particular test could easily be due to getting a different order of the tests for determining if a byte is ascii or latin1. > > I'm also in the process of measuring in detail after narrowing down the `bottom_type()` of the intrinsic and a few other recent fixes that could affect code generation in C2. Will also benchmark on aarch64 and report back. > > @cl4es Looks like you forgot to remove the "@IntrinsicCandidate" annotation for has_negatives. > > I was going back and forth ... Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying... ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Thu Mar 3 13:35:02 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 13:35:02 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: References: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com> Message-ID: On Thu, 3 Mar 2022 13:21:36 GMT, Lutz Schmidt wrote: > Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying... Doh, I had no idea the presence of `@IntrinsicCandidate` was mandating the VM has an intrinsic implementation these days (Why?! Not much of a _candidate_ if it's required..). I also seem to have built-and-tested locally without that patch properly applied. Sorry for the noise, should be fixed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From duke at openjdk.java.net Thu Mar 3 13:55:01 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 3 Mar 2022 13:55:01 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v3] In-Reply-To: References: <9edBzfTHw8OYJ7z9605AmBZ5uKfYY_DgayK9YUX_We4=.dd6923be-2a4f-4d9b-a96f-539d43afd4b1@github.com> Message-ID: On Wed, 2 Mar 2022 22:21:03 GMT, Mandy Chung wrote: >> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: >> >> suggested changes > > test/jdk/java/util/ResourceBundle/exeNullCallerResourceBundle/exeNullCallerResourceBundle.c line 28: > >> 26: >> 27: #include "jni.h" >> 28: #undef NDEBUG > > is this line unintended? Forcing the assert() seems like a good idea in a test ------------- PR: https://git.openjdk.java.net/jdk/pull/7663 From redestad at openjdk.java.net Thu Mar 3 13:58:55 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 13:58:55 GMT Subject: RFR: JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method In-Reply-To: References: Message-ID: <9inRb7fmBb_VoliqGz6uG9d7tE5WOpVbckCYZah-ZYY=.6e7438b2-c620-4b3d-96cf-38880a37cc02@github.com> On Wed, 2 Mar 2022 20:28:45 GMT, Joe Darcy wrote: > Refactoring of Method and Constructor to share a single empty array for parameters and exceptions as well as type variables. > > Existing core reflection regression tests pass with the change. src/java.base/share/classes/java/lang/reflect/Executable.java line 59: > 57: > 58: @SuppressWarnings({"rawtypes"}) > 59: static final TypeVariable[] NO_TYPE_VARS = new TypeVariable[0]; Since you asked me offline about some startup noise from this patch I took a look. This line might be another small contributor, since it means we're loading `jlr.TypeVariable` on JVM bootstrap. It would be nice if we could move this to `TypeVariable`, but we don't support private/package-private interface fields for some reason. Shouldn't we though, now that we have private interface fields, etc..? ------------- PR: https://git.openjdk.java.net/jdk/pull/7667 From redestad at openjdk.java.net Thu Mar 3 14:08:02 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 14:08:02 GMT Subject: RFR: JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method In-Reply-To: References: Message-ID: <1aQHMi0rWCPhIDXrbGSUrSMxGQ_vG_JjgDWs86nHudQ=.5de835a0-2513-4e04-8302-12f8db68d26e@github.com> On Wed, 2 Mar 2022 20:28:45 GMT, Joe Darcy wrote: > Refactoring of Method and Constructor to share a single empty array for parameters and exceptions as well as type variables. > > Existing core reflection regression tests pass with the change. src/java.base/share/classes/java/lang/reflect/Executable.java line 61: > 59: static final TypeVariable[] NO_TYPE_VARS = new TypeVariable[0]; > 60: > 61: static final Class[] NO_TYPES = new Class[0]; Less concerning since it doesn't add extra classloading, but I note that we have similar constants in a few places, including `j.l.Class.EMPTY_CLASS_ARRAY` and `j.l.r.ProxyGenerator.EMPTY_CLASS_ARRAY`. Perhaps would make sense to consolidate these into a single place/instance (and use consistent names) ------------- PR: https://git.openjdk.java.net/jdk/pull/7667 From redestad at openjdk.java.net Thu Mar 3 14:34:02 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 14:34:02 GMT Subject: RFR: JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 20:28:45 GMT, Joe Darcy wrote: > Refactoring of Method and Constructor to share a single empty array for parameters and exceptions as well as type variables. > > Existing core reflection regression tests pass with the change. This is also only a partial solution, since the initial array is created and injected by the VM on a "root" Constructor/Method, see for example the code for new method: https://github.com/openjdk/jdk/blob/5c187e34a58769a129a0aae9e4937907c9060202/src/hotspot/share/runtime/reflection.cpp#L778 Depending on usage pattern most of the Constructor/Method objects created are such root objects (often created in bulk), and only those exposed to user code via a copy will benefit from this particular enhancement. Which might be a good optimization when getting the same Constructor/Method from the same class over and over. - Can we skip the `.clone()` when propagating these from a root object to one we'll expose? We have internal `getShared...` methods for that purpose. - If we update the JVM code to inject a reference to `Class.EMPTY_CLASS_ARRAY` and we can skip the `.clone()`ing as per above we should see a decent benefit overall. ------------- Changes requested by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7667 From aph at openjdk.java.net Thu Mar 3 14:40:58 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 3 Mar 2022 14:40:58 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: References: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com> Message-ID: On Thu, 3 Mar 2022 13:31:35 GMT, Claes Redestad wrote: > > Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying... > > Doh, I had no idea the presence of `@IntrinsicCandidate` was mandating the VM has an intrinsic implementation these days (Why?! Not much of a _candidate_ if it's required..). I don't think the intrinsic has to be implemented on every target, but AFAICR it does have to be declared as an intrinsic in HotSpot. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From lucy at openjdk.java.net Thu Mar 3 14:47:02 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 3 Mar 2022 14:47:02 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: References: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com> Message-ID: On Thu, 3 Mar 2022 14:37:34 GMT, Andrew Haley wrote: > > > Well, it just didn't build. With the annotation being present, you also need an intrinsic implementation. That's what the error message is saying... > > > > > > Doh, I had no idea the presence of `@IntrinsicCandidate` was mandating the VM has an intrinsic implementation these days (Why?! Not much of a _candidate_ if it's required..). > > I don't think the intrinsic has to be implemented on every target, but AFAICR it does have to be declared as an intrinsic in HotSpot. Yes, sorry for the imprecise wording: the declaration must be there. Use of the intrinsic is then controlled via has_match_rule(opcode) and match_rule_supported(opcode). ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Thu Mar 3 14:51:01 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 3 Mar 2022 14:51:01 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v9] In-Reply-To: References: <-aKM_9WIEXh3vMlugSMg2Sprs5KMCZKh_3zoD5uaBvw=.7a096135-f215-4a52-8660-73dddef19c38@github.com> Message-ID: On Thu, 3 Mar 2022 14:43:52 GMT, Lutz Schmidt wrote: > I don't think the intrinsic has to be implemented on every target, but AFAICR it does have to be declared as an intrinsic in HotSpot. Yeah, I got confused. To me it looks like a declaration of intent, and thought the only strict requirement was that HotSpot can't define an intrinsic if there's no annotation. It also seems odd to hardwire it to what HotSpot does - wasn't the purpose of renaming from `@HotSpotIntrinsicCandidate` to decouple things a bit better? Either way.. I'm re-running tests and benchmarks and seeing if I can improve the aarch64 impl to return a decent approximation rather than always-0 when there are negative bytes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From amenkov at openjdk.java.net Thu Mar 3 15:14:38 2022 From: amenkov at openjdk.java.net (Alex Menkov) Date: Thu, 3 Mar 2022 15:14:38 GMT Subject: RFR: 8282241: Invalid generic signature for redefined classes Message-ID: JDK-8238048 (fixed in jdk15) moved major_version, minor_version, generic_signature_index and source_file_name_index from InstanceKlass to ConstantPool. We still have some incorrect code in CP merge during class redefinition. rewrite_cp_refs(scratch_class) updates generic_signature_index and source_file_name_index in the scratch_cp, so we need to copy the attributes (merge_cp->copy_fields(scratch_cp())) after rewrite_cp_refs. In redefine_single_class we don't need to copy source_file_name_index because it's a CP property and we swap CPs. So this copying actually sets the value from old class. tested: - test/jdk/java/lang/instrument - test/hotspot/jtreg/serviceability/jvmti/RedefineClasses - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RedefineClasses - test/hotspot/jtreg/vmTestbase/nsk/jvmti/RetransformClasses ------------- Commit messages: - JDK-8282241 Changes: https://git.openjdk.java.net/jdk/pull/7676/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7676&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282241 Stats: 249 lines in 2 files changed: 239 ins; 7 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7676.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7676/head:pull/7676 PR: https://git.openjdk.java.net/jdk/pull/7676 From omikhaltcova at openjdk.java.net Thu Mar 3 15:38:44 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 3 Mar 2022 15:38:44 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v4] In-Reply-To: References: Message-ID: > This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. > > For example, it's needed to execute the following command on Windows: > `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` > it's equal to: > `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` > > While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. > > private static String unQuote(String str) { > .. > if (str.endsWith("\\"")) { > return str; // not properly quoted, treat as unquoted > } > .. > } > > > that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. > As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: > > pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test > (jdk.lang.Process.allowAmbiguousCommands = true) > pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test > (jdk.lang.Process.allowAmbiguousCommands = false) > > > Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: Reverted addition of the test via echo ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7504/files - new: https://git.openjdk.java.net/jdk/pull/7504/files/0eceecac..8cbdfe77 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7504&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7504&range=02-03 Stats: 89 lines in 1 file changed: 0 ins; 89 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7504.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7504/head:pull/7504 PR: https://git.openjdk.java.net/jdk/pull/7504 From duke at openjdk.java.net Thu Mar 3 15:46:37 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 3 Mar 2022 15:46:37 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v24] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: cast several float to double before calculation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/475e040f..d168ad4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=22-23 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Mar 3 15:51:07 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 3 Mar 2022 15:51:07 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v19] In-Reply-To: <7n0zRL2aNC--r9BVCQ0whdD7h_Auy091iVRe4t4tFEM=.f3b8b1c8-7fe0-4d8b-87ff-b5dc839fb7c0@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <1AW2iddnLOTU-np_YhZgGuFx9MLgl0yX4qKtPFiFELM=.4f4c8a42-1ffa-4dfe-acb0-df1487d6a49c@github.com> <7n0zRL2aNC--r9BVCQ0whdD7h_Auy091iVRe4t4tFEM=.f3b8b1c8-7fe0-4d8b-87ff-b5dc839fb7c0@github.com> Message-ID: On Fri, 18 Feb 2022 18:32:31 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with two additional commits since the last revision: >> >> - migrate to junit >> - change threshold > > Sigh. (I'm sighing at the author of the Enum/ConstantDirectoryOptimalCapacity.java test, not you.) What a mess. See https://bugs.openjdk.java.net/browse/JDK-8282120 which I just filed. The broken test and the OptimalCapacity utilities are mostly useless, so the change to that test and Class.java should be removed this PR, and the test added to the Problem List so it doesn't get run anymore. See test/jdk/ProblemList.txt and add an entry for the now-failing test, with a reference to 8282120. > > I don't think I'll have time to look at the junit rewrite and to run this through our internal build/test system today, so sorry, this may need to wait a week. @stuart-marks changes done, floats converted to doubles before calculations. please have a look. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From tanksherman27 at gmail.com Thu Mar 3 11:59:13 2022 From: tanksherman27 at gmail.com (Jules W.) Date: Thu, 3 Mar 2022 19:59:13 +0800 Subject: New methods in PriorityQueue Message-ID: Hi all, A new PR that adds methods to PriorityQueue was created some time ago at https://github.com/openjdk/jdk/pull/6938 but has no corresponding issue. As I'm not too familiar with this part of the JDK I'm querying this mailing list for anyone to properly review the PR before I create an issue for it in the JBS best regards, Julian Waters From duke at openjdk.java.net Thu Mar 3 16:55:46 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Thu, 3 Mar 2022 16:55:46 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v4] In-Reply-To: References: Message-ID: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com> > The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: more suggested changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7663/files - new: https://git.openjdk.java.net/jdk/pull/7663/files/eeb2d0fa..45f9b37b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=02-03 Stats: 31 lines in 2 files changed: 2 ins; 13 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/7663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663 PR: https://git.openjdk.java.net/jdk/pull/7663 From psandoz at openjdk.java.net Thu Mar 3 17:43:06 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 3 Mar 2022 17:43:06 GMT Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate feature [v2] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 08:12:46 GMT, Xiaohong Gong wrote: >> The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature. >> >> This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE: >> >> mov z19.d, #0 >> cmpgt p1.d, p7/z, z19.d, z17.d >> and p0.b, p7/z, p1.b, p0.b >> >> are optimized to: >> >> mov z19.d, #0 >> cmpgt p0.d, p0/z, z19.d, z17.d >> >> Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2. > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Simply the testTemplate I guess the following: `mask.cast(IntVector.species(shape())` is more efficient than: `m.cast(vspecies().asIntegral()))` ? ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7654 From lancea at openjdk.java.net Thu Mar 3 17:46:53 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Mar 2022 17:46:53 GMT Subject: RFR: 8280404: Unexpected exception thrown when CEN file entry comment length is not valid [v2] In-Reply-To: References: Message-ID: > Hi all, > > This PR addresses an issue where an unexpected exception is thrown when the CEN file entry comment length is not correct. > > Mach5 tiers 1 - 3 run clean with this change. Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: Add comment indicating that zcp.toString could throw an Exception ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7673/files - new: https://git.openjdk.java.net/jdk/pull/7673/files/d60b7f23..2104e84a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7673&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7673&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7673.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7673/head:pull/7673 PR: https://git.openjdk.java.net/jdk/pull/7673 From psandoz at openjdk.java.net Thu Mar 3 17:49:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 3 Mar 2022 17:49:05 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v4] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 04:22:34 GMT, Tagir F. Valeev wrote: >> Tagir F. Valeev has updated the pull request incrementally with one additional commit since the last revision: >> >> Benchmark to demonstrate the patch usefulness > > I added a microbenchmark to demonstrate the speed improvement achievable by this patch. For demonstration, I used `Pattern.splitAsStream` source (though as listed in JDK-8280915, many other standard sources are also affected). For downstream operation I selected `BigInteger.pow(1000)` which is moderately CPU-intensive (takes ~10us on my machine for input numbers within 1000..2000). The benchmarking results are as follows (my machine has 8 cores). Here's non-patched version: > > > Benchmark (size) Mode Cnt Score Error Units > sumOf1000thPowers 10 avgt 30 100.367 ? 0.793 us/op > sumOf1000thPowers 100 avgt 30 963.857 ? 6.252 us/op > sumOf1000thPowers 1000 avgt 30 10012.923 ? 81.091 us/op > sumOf1000thPowers 10000 avgt 30 99546.370 ? 625.105 us/op > sumOf1000thPowersParallel 10 avgt 30 104.561 ? 1.118 us/op > sumOf1000thPowersParallel 100 avgt 30 995.400 ? 26.116 us/op > sumOf1000thPowersParallel 1000 avgt 30 9969.296 ? 85.166 us/op > sumOf1000thPowersParallel 10000 avgt 30 55856.516 ? 2315.530 us/op > > > We observe that the results depend on the input size linearly for sequential run, which is quite expected. Parallel doesn't help at all for size = 10, 100, and 1000, which validates my claim that these spliterators cannot split at all for sizes <= 1024. For size = 10000, parallel version starts performing somewhat better (1.78x), though it's not nearly close to the available machine parallelism. > > Here's patched version: > > > Benchmark (size) Mode Cnt Score Error Units > sumOf1000thPowers 10 avgt 30 101.380 ? 0.961 us/op > sumOf1000thPowers 100 avgt 30 970.843 ? 8.360 us/op > sumOf1000thPowers 1000 avgt 30 9837.397 ? 93.656 us/op > sumOf1000thPowers 10000 avgt 30 97741.823 ? 1276.116 us/op > sumOf1000thPowersParallel 10 avgt 30 41.597 ? 0.910 us/op > sumOf1000thPowersParallel 100 avgt 30 189.735 ? 1.911 us/op > sumOf1000thPowersParallel 1000 avgt 30 1776.337 ? 31.034 us/op > sumOf1000thPowersParallel 10000 avgt 30 17685.723 ? 127.846 us/op > > > We observe no regression for sequential run and drastic improvement for parallel. Even for size = 10, we see 2.46x speedup and 41 us total time. For bigger sizes, we see 5.11x..5.54x speedup. > > Please review my patch. I'll be happy to discuss any concerns about this optimization you may have. Thanks in advance! > @amaembo It's on my queue to review, i may get to it tomorrow, otherwise next week. I took last week off at short notice, since it was the school holidays. Looking today. ------------- PR: https://git.openjdk.java.net/jdk/pull/7279 From joehw at openjdk.java.net Thu Mar 3 17:57:26 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 3 Mar 2022 17:57:26 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice Message-ID: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Update BCEL md to include the copyright notice. ------------- Commit messages: - 8282583: Update BCEL md to include the copyright notice Changes: https://git.openjdk.java.net/jdk/pull/7681/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7681&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282583 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7681.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7681/head:pull/7681 PR: https://git.openjdk.java.net/jdk/pull/7681 From roger.riggs at oracle.com Thu Mar 3 18:18:38 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 3 Mar 2022 13:18:38 -0500 Subject: New methods in PriorityQueue In-Reply-To: References: Message-ID: Hi Julian, Modifying the priorities of elements in the PriorityQueue violates the invariants of the PriorityQueue established at insertion and maintained at removal by the Comparator. To maintain the invariant the element should be removed, its priority modified, and re-inserted. An API to manually manipulate the order is inconsistent with the design of PriorityQueue. Regards, Roger On 3/3/22 6:59 AM, Jules W. wrote: > Hi all, > > A new PR that adds methods to PriorityQueue was created some time ago at > https://github.com/openjdk/jdk/pull/6938 but has no corresponding issue. As > I'm not too familiar with this part of the JDK I'm querying this mailing > list for anyone to properly review the PR before I create an issue for it > in the JBS > > best regards, > Julian Waters From lancea at openjdk.java.net Thu Mar 3 18:18:59 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Mar 2022 18:18:59 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice In-Reply-To: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Message-ID: On Thu, 3 Mar 2022 17:51:31 GMT, Joe Wang wrote: > Update BCEL md to include the copyright notice. Looks fine. I assume the 2020 vs 2022 is intentional? ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7681 From xliu at openjdk.java.net Thu Mar 3 18:19:00 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 3 Mar 2022 18:19:00 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 08:07:53 GMT, Daniel Jeli?ski wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 546: > >> 544: StringUTF16.putCharSB(value, index, ch); >> 545: } >> 546: growOnly = false; > > Any changes that take place while the string is still latin1 do not make it potentially compressible. You could move this assignment to the `else` clause for some additional possible performance boost. But then the variable name would be misleading. yes, I really hesitate about that. 'growOnly' is an attribute of current AbstractStringBuilder. if we ignore latin-1 path, it breaks the invariant. Maybe we rename it 'isCompressible'? ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From iris at openjdk.java.net Thu Mar 3 18:21:58 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 3 Mar 2022 18:21:58 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice In-Reply-To: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Message-ID: On Thu, 3 Mar 2022 17:51:31 GMT, Joe Wang wrote: > Update BCEL md to include the copyright notice. Confirm 2020, not 2022. Otherwise, looks good. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7681 From lancea at openjdk.java.net Thu Mar 3 18:43:01 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Mar 2022 18:43:01 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice In-Reply-To: References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Message-ID: On Thu, 3 Mar 2022 18:35:05 GMT, Joe Wang wrote: > Yes, it's 2020. The latest release, 6.5.0, was released in 2020. The text comes from the NOTICE.txt file in the BCEL 6.5.0 release. Thank you for the confirmation Joe! ------------- PR: https://git.openjdk.java.net/jdk/pull/7681 From joehw at openjdk.java.net Thu Mar 3 18:43:00 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 3 Mar 2022 18:43:00 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice In-Reply-To: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Message-ID: On Thu, 3 Mar 2022 17:51:31 GMT, Joe Wang wrote: > Update BCEL md to include the copyright notice. Yes, it's 2020. The latest release, 6.5.0, was released in 2020. The text comes from the NOTICE.txt file in the BCEL 6.5.0 release. ------------- PR: https://git.openjdk.java.net/jdk/pull/7681 From joehw at openjdk.java.net Thu Mar 3 18:43:01 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 3 Mar 2022 18:43:01 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice In-Reply-To: References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Message-ID: On Thu, 3 Mar 2022 18:36:32 GMT, Lance Andersen wrote: > > Yes, it's 2020. The latest release, 6.5.0, was released in 2020. The text comes from the NOTICE.txt file in the BCEL 6.5.0 release. > > Thank you for the confirmation Joe! Thanks Lance, and Iris! ------------- PR: https://git.openjdk.java.net/jdk/pull/7681 From naoto at openjdk.java.net Thu Mar 3 19:40:27 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Mar 2022 19:40:27 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate Message-ID: Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. ------------- Commit messages: - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate Changes: https://git.openjdk.java.net/jdk/pull/7683/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279185 Stats: 250 lines in 12 files changed: 216 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683 PR: https://git.openjdk.java.net/jdk/pull/7683 From ascarpino at openjdk.java.net Thu Mar 3 20:14:02 2022 From: ascarpino at openjdk.java.net (Anthony Scarpino) Date: Thu, 3 Mar 2022 20:14:02 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Fair point that the keysize would determine the algorithm used and the default key sizes for keygen. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From mchung at openjdk.java.net Thu Mar 3 21:45:04 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Mar 2022 21:45:04 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v4] In-Reply-To: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com> References: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com> Message-ID: On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing wrote: >> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. >> >> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: >> >> final ClassLoader loader = (caller != null) ? >> caller.getClassLoader() : getLoader(getCallerModule(caller)); >> >> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. >> >> The javadoc was updated for the caller sensitive methods changed. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > more suggested changes Marked as reviewed by mchung (Reviewer). src/java.base/share/classes/java/util/ResourceBundle.java line 1570: > 1568: Module callerModule = (caller != null) ? caller.getModule() > 1569: : ClassLoader.getSystemClassLoader().getUnnamedModule(); > 1570: return callerModule; nit: `callerModule` variable is not needed. It can simply do: return (caller != null) ? caller.getModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); ------------- PR: https://git.openjdk.java.net/jdk/pull/7663 From mchung at openjdk.java.net Thu Mar 3 22:03:29 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Mar 2022 22:03:29 GMT Subject: RFR: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 Message-ID: This fixes a bug in JDK-8282515 that `NativeLibraries::findEntry0` reads the handle from the given native library instance with the field ID for `NativeLibraryImpl::handle` which is wrong for `RawNativeLibraryImpl`. The `NativeLibraries::findEntry0` now takes the handle of the library instead and that can be used to look up symbols in the native library loaded by System::loadLibrary and also RawNativeLibraries. Tier 1-4 testing is in progress. ------------- Commit messages: - 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 Changes: https://git.openjdk.java.net/jdk/pull/7684/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7684&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282608 Stats: 15 lines in 3 files changed: 0 ins; 7 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7684.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7684/head:pull/7684 PR: https://git.openjdk.java.net/jdk/pull/7684 From mcimadamore at openjdk.java.net Thu Mar 3 22:18:00 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 3 Mar 2022 22:18:00 GMT Subject: RFR: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 21:57:19 GMT, Mandy Chung wrote: > This fixes a bug in JDK-8282515 that `NativeLibraries::findEntry0` reads the handle from the given native library instance with the field ID for `NativeLibraryImpl::handle` which is wrong for `RawNativeLibraryImpl`. The `NativeLibraries::findEntry0` now takes the handle of the library instead and that can be used to look up symbols in the native library loaded by System::loadLibrary and also RawNativeLibraries. > > Tier 1-4 testing is in progress. Fix looks good - sorry I missed it yesterday. I left a minor, optional, cosmetic comment. src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line 38: > 36: import java.util.concurrent.ConcurrentHashMap; > 37: > 38: import static jdk.internal.loader.NativeLibraries.findEntry0; We have `NativeLibraries` and `RawNativeLibraries` which are unrelated classes. Then we have `NativeLibraryImpl` and `RawNativeLibraryImpl` which shared a common super type (`NativeLibrary`). I find it mildly asymmetric to put the `find0` native method in `NativeLibraries` since that's not the supertype of `RawNativeLibraries`. Is there common code between the two XYZLibraries classes that can be shared? If so, maybe `find0` can go in that common supertype - if not, maybe it's better to put `find0` in `NativeLibrary` itself? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7684 From xliu at openjdk.java.net Thu Mar 3 22:23:06 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 3 Mar 2022 22:23:06 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 08:11:19 GMT, Daniel Jeli?ski wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > src/java.base/share/classes/java/lang/StringBuffer.java line 715: > >> 713: public synchronized String toString() { >> 714: if (toStringCache == null) { >> 715: return toStringCache = new String(this); > > When you modify a method labeled `IntrinsicCandidate`, you should probably modify the intrinsic as well _StringBuilder_toString and _StringBuffer_toString are intrinsics indeed, but they are only used for method recognition in c2/StringOpts. C2 doesn't expand them. if StringOpts misses, C2 will inline these 2 methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From joehw at openjdk.java.net Thu Mar 3 22:34:43 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 3 Mar 2022 22:34:43 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice [v2] In-Reply-To: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Message-ID: <7b-M0DUs4rb3uQqhW6kHqE3m1uE9lrWDASrsbbkmMoA=.28a567e9-6e4d-4156-926f-f5e8e588d0b3@github.com> > Update BCEL md to include the copyright notice. Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove the section that's no longer in the notice file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7681/files - new: https://git.openjdk.java.net/jdk/pull/7681/files/be8b704c..0e025466 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7681&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7681&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7681.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7681/head:pull/7681 PR: https://git.openjdk.java.net/jdk/pull/7681 From mchung at openjdk.java.net Thu Mar 3 22:39:59 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Mar 2022 22:39:59 GMT Subject: RFR: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 22:14:15 GMT, Maurizio Cimadamore wrote: >> This fixes a bug in JDK-8282515 that `NativeLibraries::findEntry0` reads the handle from the given native library instance with the field ID for `NativeLibraryImpl::handle` which is wrong for `RawNativeLibraryImpl`. The `NativeLibraries::findEntry0` now takes the handle of the library instead and that can be used to look up symbols in the native library loaded by System::loadLibrary and also RawNativeLibraries. >> >> Tier 1-4 testing is in progress. > > src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line 38: > >> 36: import java.util.concurrent.ConcurrentHashMap; >> 37: >> 38: import static jdk.internal.loader.NativeLibraries.findEntry0; > > We have `NativeLibraries` and `RawNativeLibraries` which are unrelated classes. Then we have `NativeLibraryImpl` and `RawNativeLibraryImpl` which shared a common super type (`NativeLibrary`). I find it mildly asymmetric to put the `find0` native method in `NativeLibraries` since that's not the supertype of `RawNativeLibraries`. Is there common code between the two XYZLibraries classes that can be shared? If so, maybe `find0` can go in that common supertype - if not, maybe it's better to put `find0` in `NativeLibrary` itself? I agree it's asymmetric to put the native method in `NativeLibraries`. `NativeLibrary` would be a better place for `findEntry0`. I will also turn `NativeLibrary` to an abstract class to make `findEntry0` is package-private static method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7684 From naoto at openjdk.java.net Thu Mar 3 22:57:05 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 3 Mar 2022 22:57:05 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice [v2] In-Reply-To: <7b-M0DUs4rb3uQqhW6kHqE3m1uE9lrWDASrsbbkmMoA=.28a567e9-6e4d-4156-926f-f5e8e588d0b3@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> <7b-M0DUs4rb3uQqhW6kHqE3m1uE9lrWDASrsbbkmMoA=.28a567e9-6e4d-4156-926f-f5e8e588d0b3@github.com> Message-ID: On Thu, 3 Mar 2022 22:34:43 GMT, Joe Wang wrote: >> Update BCEL md to include the copyright notice. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove the section that's no longer in the notice file Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7681 From lancea at openjdk.java.net Thu Mar 3 22:57:05 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 3 Mar 2022 22:57:05 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice [v2] In-Reply-To: <7b-M0DUs4rb3uQqhW6kHqE3m1uE9lrWDASrsbbkmMoA=.28a567e9-6e4d-4156-926f-f5e8e588d0b3@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> <7b-M0DUs4rb3uQqhW6kHqE3m1uE9lrWDASrsbbkmMoA=.28a567e9-6e4d-4156-926f-f5e8e588d0b3@github.com> Message-ID: On Thu, 3 Mar 2022 22:34:43 GMT, Joe Wang wrote: >> Update BCEL md to include the copyright notice. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove the section that's no longer in the notice file Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7681 From iris at openjdk.java.net Thu Mar 3 23:20:05 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 3 Mar 2022 23:20:05 GMT Subject: RFR: 8282583: Update BCEL md to include the copyright notice [v2] In-Reply-To: <7b-M0DUs4rb3uQqhW6kHqE3m1uE9lrWDASrsbbkmMoA=.28a567e9-6e4d-4156-926f-f5e8e588d0b3@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> <7b-M0DUs4rb3uQqhW6kHqE3m1uE9lrWDASrsbbkmMoA=.28a567e9-6e4d-4156-926f-f5e8e588d0b3@github.com> Message-ID: On Thu, 3 Mar 2022 22:34:43 GMT, Joe Wang wrote: >> Update BCEL md to include the copyright notice. > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove the section that's no longer in the notice file Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7681 From mchung at openjdk.java.net Thu Mar 3 23:29:31 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 3 Mar 2022 23:29:31 GMT Subject: RFR: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 [v2] In-Reply-To: References: Message-ID: > This fixes a bug in JDK-8282515 that `NativeLibraries::findEntry0` reads the handle from the given native library instance with the field ID for `NativeLibraryImpl::handle` which is wrong for `RawNativeLibraryImpl`. The `NativeLibraries::findEntry0` now takes the handle of the library instead and that can be used to look up symbols in the native library loaded by System::loadLibrary and also RawNativeLibraries. > > Tier 1-4 testing is in progress. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Move findEntry0 to NativeLibrary ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7684/files - new: https://git.openjdk.java.net/jdk/pull/7684/files/419159fe..61711d91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7684&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7684&range=00-01 Stats: 22 lines in 4 files changed: 6 ins; 8 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7684.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7684/head:pull/7684 PR: https://git.openjdk.java.net/jdk/pull/7684 From psandoz at openjdk.java.net Thu Mar 3 23:52:05 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Thu, 3 Mar 2022 23:52:05 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v5] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 04:30:34 GMT, Tagir F. Valeev wrote: >> See the bug description for details. >> >> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. >> >> No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. >> >> I added a simple test using an artificial collector to ensure that at least two non-empty parts are created when parallelizing Stream.iterate source. More testing ideas are welcome. > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Cosmetic fixes For unknown-sized iterators we have to bias towards some strategy (recognizing that the source is a poor choice for parallelism). Currently the "peeled" split containing an array of elements (copied from the iterator) is never split, since the array length will never in practice be greater than the size threshold. The parallelism is derived from the splits of the iterator, and this is biased towards a large number of elements. In your approach each "peeled" split effectively gets to use half of the total parallelism. Over subsequent splits of the source that's gonna over provision tasks, specifically after two splits (or 2 * 2^10 + 2^10 elements), and this is biased towards a smaller number of elements. In the issue you point out a number of relevant stream sources. In practice they are unlikely to have millions of elements, and probably more likely fitting into the first few steps of the arithmetic splitting sequence. If the cost-per-element is reasonably high that would overcome any over provisioning. Overall it looks reasonable. I ran it through tier 1/2 testing and there were no failures. If you don't mind I would like to let this percolate a little in my mind (i.e. sleep on it for a day or two). ------------- PR: https://git.openjdk.java.net/jdk/pull/7279 From smarks at openjdk.java.net Fri Mar 4 01:14:05 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Mar 2022 01:14:05 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v24] In-Reply-To: <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> Message-ID: On Thu, 3 Mar 2022 15:46:37 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > cast several float to double before calculation src/java.base/share/classes/java/util/WeakHashMap.java line 469: > 467: Entry e = tab[i]; > 468: tab[i] = new Entry<>(k, value, queue, h, e); > 469: if (++size > threshold) Good catch here, by the way. The old code clearly expanded the map prematurely. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From david.holmes at oracle.com Fri Mar 4 01:14:00 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Mar 2022 11:14:00 +1000 Subject: PriorityQueue PR requiring review In-Reply-To: References: <16f37970-d569-dbbc-664f-dada176d589d@oracle.com> Message-ID: <1e5d6f98-f3e4-aa51-778f-64e81cc2cc1d@oracle.com> On 3/03/2022 11:02 pm, Julian Waters wrote: > I understand, I'll notify the author about this. I'm not sure if they'll > be alright with discussing on the mailing lists though, since they have > expressed that they prefer discussing it on the PR itself That's not the way OpenJDK works, and anything in the PR (once properly setup) goes to the mailing list anyway. https://openjdk.java.net/contribute/ Cheers, David > best regards, > Julian Waters > > On Thu, Mar 3, 2022 at 8:57 PM David Holmes > wrote: > > On 3/03/2022 10:47 pm, Julian Waters wrote: > > Hi David, > > > > I did not create the PR, I'm instead asking for others to review it > > before I help the author create the issue on the JBS. Should I > just go > > ahead and create the issue for them? > > The best thing would be for the PR creator to discuss the proposed API > addition on the mailing list first. I have a fairly good idea what the > outcome of that discussion will be but ... :) > > Cheers, > David > > > best regards, > > Julian > > > > On Thu, Mar 3, 2022 at 8:45 PM David Holmes > > > >> wrote: > > > >? ? ?Hi Julian, > > > >? ? ?On 3/03/2022 10:33 pm, Jules W. wrote: > >? ? ? > Hi all, > >? ? ? > > >? ? ? > A new PR that adds methods to PriorityQueue was created > some time > >? ? ?ago at > >? ? ? > https://github.com/openjdk/jdk/pull/6938 > > >? ? ? > but has no corresponding > >? ? ?issue. As > >? ? ? > I'm not too familiar with this part of the JDK I'm > querying this > >? ? ?mailing > >? ? ? > list for anyone to properly review the PR before I create an > >? ? ?issue for it > >? ? ? > in the JBS > > > >? ? ?First you need an issue, then you review a PR. Your PR would > not be > >? ? ?seen > >? ? ?by anyone unless they go looking for it, as without the > association > >? ? ?with > >? ? ?an issue, the system will not send the email to the mailing > lists. > > > >? ? ?I see someone is helping you create the issue so things > should progress > >? ? ?in that sense. But note the bar for adding to a public API is set > >? ? ?very high. > > > >? ? ?Cheers, > >? ? ?David > > > >? ? ? > best regards, > >? ? ? > Julian Waters > > > From dholmes at openjdk.java.net Fri Mar 4 01:29:59 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 4 Mar 2022 01:29:59 GMT Subject: RFR: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 [v2] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 23:29:31 GMT, Mandy Chung wrote: >> This fixes a bug in JDK-8282515 that `NativeLibraries::findEntry0` reads the handle from the given native library instance with the field ID for `NativeLibraryImpl::handle` which is wrong for `RawNativeLibraryImpl`. The `NativeLibraries::findEntry0` now takes the handle of the library instead and that can be used to look up symbols in the native library loaded by System::loadLibrary and also RawNativeLibraries. >> >> Tier 1-4 testing is in progress. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Move findEntry0 to NativeLibrary HI Mandy, This looks reasonable to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7684 From smarks at openjdk.java.net Fri Mar 4 02:31:07 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Mar 2022 02:31:07 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v24] In-Reply-To: <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> Message-ID: <7ZEhdJX3sLr8tLhWLdvtV0B7iyrdhyZ4NFyVSA9wtl0=.fb302f1e-2019-4a95-bb6f-b24988174181@github.com> On Thu, 3 Mar 2022 15:46:37 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > cast several float to double before calculation OK, I took a look at HashMapsPutAllOverAllocateTableTest.java. It's certainly a good start at testing stuff in this area. However, I notice that test/jdk/java/util/HashMap/WhiteBoxResizeTest.java already exists and tests kind-of similar things. I think it would be preferable to enhance this test with additional assertions since it already has a bunch of machinery to inspect the various internals. It tests both HashMap and LinkedHashMap, so I think it would be ok to add a WeakHashMap test here as well. I note however that it relies on LinkedHashMap being a subclass of HashMap, which WeakHashMap is not, and so there will be a certain amount of messiness adding in the handling for WeakHashMap. Once this is in place though I think adding the additional test cases would fit in well here. In particular, it should be possible to test the proper table lengths for the copy-constructor and putAll cases (from your original bug report) as well as the premature table expansion in WeakHashMap. This test could use some cleanup as well. For example, the capacityTestInitialCapacity() method has a list of suppliers that it loops over. This is probably better expressed as a data provider driving a test method that tests one case. There's a bit of an art to setting this up. TestNG wants each test case to be `Object[][]` which is kind of a pain if you want to use a lambda. A trick is to have a method that returns `Object[]` representing one test case, and have the parameters of this method provide the target types for the lambdas. For example: Object[] testcase(String label, Supplier> s, Consumer> c, int expectedCapacity) { return new Object[] { label, s, c, expectedCapacity }; } and then have the actual data provider just be a series of calls to this method in an array literal: @DataProvider public Object[][] allCases() { return new Object[][] { testcase("HMputAll", () -> new HashMap<>(), m -> m.putAll(MAP12), 16), testcase("WHMputAll", () -> new WeakHashMap<>(), m -> m.putAll(MAP12), 16), testcase("HMcopyctor", () -> new HashMap<>(MAP12), m -> { }, 16), testcase("WHMcopyctor", () -> new WeakHashMap<>(MAP12), m -> { }, 16), }; } This lets you write the lambdas without a cast that provides the target type. The test method calls the supplier, passes the map to the consumer, gets the table length, and asserts that it's equal to the expected length. Note that I've set this up with separate supplier and consumer in order to accommodate both the copy constructor cases and the putAll cases. Finally, the label string isn't used by the test method, but it's useful if one of the cases fails. TestNG will print out the arguments of a failing case and the label helps a lot here, as the string form of the lambda is basically unintelligible. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From joehw at openjdk.java.net Fri Mar 4 03:19:03 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 4 Mar 2022 03:19:03 GMT Subject: Integrated: 8282583: Update BCEL md to include the copyright notice In-Reply-To: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> References: <4wt3AvYo-JWfQ0vx3XfPFWrnaZhzt363OqzF_6uq4YE=.02919575-4228-45b9-9ea2-90be05a13f5e@github.com> Message-ID: On Thu, 3 Mar 2022 17:51:31 GMT, Joe Wang wrote: > Update BCEL md to include the copyright notice. This pull request has now been integrated. Changeset: 8478173d Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/8478173d837113bf603aadb614badd461f474250 Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod 8282583: Update BCEL md to include the copyright notice Reviewed-by: lancea, iris, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7681 From mchung at openjdk.java.net Fri Mar 4 03:45:07 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 4 Mar 2022 03:45:07 GMT Subject: Integrated: 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 21:57:19 GMT, Mandy Chung wrote: > This fixes a bug in JDK-8282515 that `NativeLibraries::findEntry0` reads the handle from the given native library instance with the field ID for `NativeLibraryImpl::handle` which is wrong for `RawNativeLibraryImpl`. The `NativeLibraries::findEntry0` now takes the handle of the library instead and that can be used to look up symbols in the native library loaded by System::loadLibrary and also RawNativeLibraries. > > Tier 1-4 testing is in progress. This pull request has now been integrated. Changeset: 7e1c67d4 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/7e1c67d4af76eba688927a24d711181570e965ef Stats: 33 lines in 4 files changed: 6 ins; 15 del; 12 mod 8282608: RawNativeLibraryImpl can't be passed to NativeLibraries::findEntry0 Reviewed-by: mcimadamore, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7684 From naoto at openjdk.java.net Fri Mar 4 05:02:37 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 05:02:37 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v2] In-Reply-To: References: Message-ID: > Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: copyright year fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7683/files - new: https://git.openjdk.java.net/jdk/pull/7683/files/28d93903..12c6212a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683 PR: https://git.openjdk.java.net/jdk/pull/7683 From stuart.marks at oracle.com Fri Mar 4 05:37:40 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 3 Mar 2022 21:37:40 -0800 Subject: New methods in PriorityQueue In-Reply-To: References: Message-ID: I agree with Roger. Let me amplify this. The general rule for collections that use hashes and comparison methods (such as HashMap and TreeMap, as well as PriorityQueue) is that one mustn't mutate any element that resides in such a collection in any way that changes the results of hashCode, equals, or the comparison method. It's a bad precedent to add APIs that seem to support such mutation. As Roger said, the supported way of doing this is to remove, mutate, and then reinsert. It seems like it might be safe to mutate an element, only temporarily violating the PQ's invariants until the mutated element is sifted into the correct position. However, even a "temporary" violation is exceedingly dangerous. If some other modification is made to the PQ while it's in this state, it could end up permanently corrupting the PQ. Managing such a situation would need to be handled exceedingly carefully. As such, this seems like a highly specialized use case, thus the proposal isn't suitable as a general-purpose API. s'marks On 3/3/22 10:18 AM, Roger Riggs wrote: > Hi Julian, > > Modifying the priorities of elements in the PriorityQueue violates the > invariants of the PriorityQueue established at insertion and maintained > at removal by the Comparator. > > To maintain the invariant the element should be removed, its priority modified, > and re-inserted. > > An API to manually manipulate the order is inconsistent with the design of > PriorityQueue. > > Regards, Roger > > > On 3/3/22 6:59 AM, Jules W. wrote: >> Hi all, >> >> A new PR that adds methods to PriorityQueue was created some time ago at >> https://github.com/openjdk/jdk/pull/6938 but has no corresponding issue. As >> I'm not too familiar with this part of the JDK I'm querying this mailing >> list for anyone to properly review the PR before I create an issue for it >> in the JBS >> >> best regards, >> Julian Waters > From darcy at openjdk.java.net Fri Mar 4 05:53:03 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Mar 2022 05:53:03 GMT Subject: RFR: JDK-8177107: Reduce memory footprint of java.lang.reflect.Constructor/Method In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 14:30:34 GMT, Claes Redestad wrote: > This is also only a partial solution, since the initial array is created and injected by the VM on a "root" Constructor/Method, see for example the code for new method: > > https://github.com/openjdk/jdk/blob/5c187e34a58769a129a0aae9e4937907c9060202/src/hotspot/share/runtime/reflection.cpp#L778 > > Depending on usage pattern most of the Constructor/Method objects created are such root objects (often created in bulk), and only those exposed to user code via a copy will benefit from this particular enhancement. Which might be a good optimization when getting the same Constructor/Method from the same class over and over. > > * Can we skip the `.clone()` when propagating these from a root object to one we'll expose? We have internal `getShared...` methods for that purpose. > > * If we update the JVM code to inject a reference to `Class.EMPTY_CLASS_ARRAY` and we can skip the `.clone()`ing as per above we should see a decent benefit overall. I did also wonder to myself off-list if this style of optimization would be better handled in the JVM were the arrays of arguments are created. If so, I wouldn't feel comfortable implementing that in HotSpot sources myself. > src/java.base/share/classes/java/lang/reflect/Executable.java line 59: > >> 57: >> 58: @SuppressWarnings({"rawtypes"}) >> 59: static final TypeVariable[] NO_TYPE_VARS = new TypeVariable[0]; > > Since you asked me offline about some startup noise from this patch I took a look. This line might be another small contributor, since it means we're loading `jlr.TypeVariable` on JVM bootstrap. It would be nice if we could move this to `TypeVariable`, but we don't support private/package-private interface fields for some reason. Shouldn't we though, now that we have private interface fields, etc..? IIRC, Java language-level private interface fields are on the to-do list, but are not a high priority. > src/java.base/share/classes/java/lang/reflect/Executable.java line 61: > >> 59: static final TypeVariable[] NO_TYPE_VARS = new TypeVariable[0]; >> 60: >> 61: static final Class[] NO_TYPES = new Class[0]; > > Less concerning since it doesn't add extra classloading, but I note that we have similar constants in a few places, including `j.l.Class.EMPTY_CLASS_ARRAY` and `j.l.r.ProxyGenerator.EMPTY_CLASS_ARRAY`. Perhaps would make sense to consolidate these into a single place/instance (and use consistent names) A consolidated location like a non-instantiable java.lang.reflect.EmptyHolder class with static fields? (Exact name subject to bike shedding.) ------------- PR: https://git.openjdk.java.net/jdk/pull/7667 From darcy at openjdk.java.net Fri Mar 4 06:10:09 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Mar 2022 06:10:09 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 06:17:06 GMT, Joe Darcy wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Adding descriptive comments. > > test/jdk/java/lang/Math/RoundTests.java line 32: > >> 30: public static void main(String... args) { >> 31: int failures = 0; >> 32: for (int i = 0; i < 100000; i++) { > > Is there an idiom to trigger the auto-vectorization, perhaps using command line arguments, that doesn't bloat the running time of this test? IMO RoundTests should have a explicit @run tag without any VM options as well. Do the added VM options run on all platforms in question? What is the approximate time to run the test run compared to before? ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From tanksherman27 at gmail.com Fri Mar 4 07:08:27 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Fri, 4 Mar 2022 15:08:27 +0800 Subject: New methods in PriorityQueue In-Reply-To: References: Message-ID: Hi all, I apologize for the confusion, it seems like something went awry on my end with the mailing lists, since there are apparently now 2 copies of the same thread with different names. I guess I'll just go with this one, since the technical discussion is going on here. To clarify, I wasn't the one who created the PR, I'll relay the feedback to the author since I'm not really in the position to give any feedback myself, given my inexperience with this area of the JDK. Thank you Stuart and Roger for the replies, have a great day! :) best regards, Julian On Fri, Mar 4, 2022 at 1:37 PM Stuart Marks wrote: > I agree with Roger. Let me amplify this. > > The general rule for collections that use hashes and comparison methods > (such as > HashMap and TreeMap, as well as PriorityQueue) is that one mustn't mutate > any > element that resides in such a collection in any way that changes the > results of > hashCode, equals, or the comparison method. It's a bad precedent to add > APIs that > seem to support such mutation. As Roger said, the supported way of doing > this is to > remove, mutate, and then reinsert. > > It seems like it might be safe to mutate an element, only temporarily > violating the > PQ's invariants until the mutated element is sifted into the correct > position. > However, even a "temporary" violation is exceedingly dangerous. If some > other > modification is made to the PQ while it's in this state, it could end up > permanently > corrupting the PQ. > > Managing such a situation would need to be handled exceedingly carefully. > As such, > this seems like a highly specialized use case, thus the proposal isn't > suitable as a > general-purpose API. > > s'marks > > > On 3/3/22 10:18 AM, Roger Riggs wrote: > > Hi Julian, > > > > Modifying the priorities of elements in the PriorityQueue violates the > > invariants of the PriorityQueue established at insertion and maintained > > at removal by the Comparator. > > > > To maintain the invariant the element should be removed, its priority > modified, > > and re-inserted. > > > > An API to manually manipulate the order is inconsistent with the design > of > > PriorityQueue. > > > > Regards, Roger > > > > > > On 3/3/22 6:59 AM, Jules W. wrote: > >> Hi all, > >> > >> A new PR that adds methods to PriorityQueue was created some time ago at > >> https://github.com/openjdk/jdk/pull/6938 but has no corresponding > issue. As > >> I'm not too familiar with this part of the JDK I'm querying this mailing > >> list for anyone to properly review the PR before I create an issue for > it > >> in the JBS > >> > >> best regards, > >> Julian Waters > > > From volker.simonis at gmail.com Fri Mar 4 10:04:19 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 4 Mar 2022 11:04:19 +0100 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) Message-ID: `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*k*`]` (where *k* is the number of inflated bytes). >From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but could be easily fixed to run with alternative implementations as well. What should/can be done to solve this problem? I think we have three options: 1. Relax the specification of `InflaterInputStream::read(..)` and specifically note in the API documentation that a call to `InflaterInputStream::read(byte[] b, int off, int len)` may write more than *k* characters into `b` where *k* is the returned number of inflated bytes. Notice that there's a precedence for this approach in `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden method of InputStream, returns -1 instead of zero if the end of the stream has been reached and len==0*". 2. Tighten the specification of `Inflater::read(byte[] b, int off, int len)` to explicitly forbid any writes into the output array `b` beyond the inflated bytes. 3. Change the implementation of `InflaterInputStream::read(..)` to call `Inflater::read(..)` with a temporary buffer and only copy the nu,ber of inflated bytes into `InflaterInputStream::read(..)`'s output buffer. I think we all agree that this is only a theoretic option because of its unacceptable performance regression. I personally favor option 1 but I'm interested in your opinions? Thank you and best regards, Volker From zgu at openjdk.java.net Fri Mar 4 13:32:31 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 4 Mar 2022 13:32:31 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() Message-ID: Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` Test: - [x] jdk_desktop on Linux x86_64 ------------- Commit messages: - 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() Changes: https://git.openjdk.java.net/jdk/pull/7691/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7691&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282628 Stats: 21 lines in 2 files changed: 18 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7691.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7691/head:pull/7691 PR: https://git.openjdk.java.net/jdk/pull/7691 From roger.riggs at oracle.com Fri Mar 4 15:02:59 2022 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 4 Mar 2022 10:02:59 -0500 Subject: New methods in PriorityQueue In-Reply-To: References: Message-ID: <7f65b02f-837a-412a-c587-69c097e8876b@oracle.com> Hi Julian, Thanks for facilitating the communication, I probably should have dropped you from the reply as it was intended for the list in general as well as the PR submitter. Thanks, Roger On 3/4/22 2:08 AM, Julian Waters wrote: > Hi all, > > I apologize for the confusion, it seems like something went awry on my end > with the mailing lists, since there are apparently now 2 copies of the same > thread with different names. I guess I'll just go with this one, since the > technical discussion is going on here. > > To clarify, I wasn't the one who created the PR, I'll relay the feedback to > the author since I'm not really in the position to give any feedback > myself, given my inexperience with this area of the JDK. > > Thank you Stuart and Roger for the replies, have a great day! :) > > best regards, > Julian > > > > On Fri, Mar 4, 2022 at 1:37 PM Stuart Marks wrote: > >> I agree with Roger. Let me amplify this. >> >> The general rule for collections that use hashes and comparison methods >> (such as >> HashMap and TreeMap, as well as PriorityQueue) is that one mustn't mutate >> any >> element that resides in such a collection in any way that changes the >> results of >> hashCode, equals, or the comparison method. It's a bad precedent to add >> APIs that >> seem to support such mutation. As Roger said, the supported way of doing >> this is to >> remove, mutate, and then reinsert. >> >> It seems like it might be safe to mutate an element, only temporarily >> violating the >> PQ's invariants until the mutated element is sifted into the correct >> position. >> However, even a "temporary" violation is exceedingly dangerous. If some >> other >> modification is made to the PQ while it's in this state, it could end up >> permanently >> corrupting the PQ. >> >> Managing such a situation would need to be handled exceedingly carefully. >> As such, >> this seems like a highly specialized use case, thus the proposal isn't >> suitable as a >> general-purpose API. >> >> s'marks >> >> >> On 3/3/22 10:18 AM, Roger Riggs wrote: >>> Hi Julian, >>> >>> Modifying the priorities of elements in the PriorityQueue violates the >>> invariants of the PriorityQueue established at insertion and maintained >>> at removal by the Comparator. >>> >>> To maintain the invariant the element should be removed, its priority >> modified, >>> and re-inserted. >>> >>> An API to manually manipulate the order is inconsistent with the design >> of >>> PriorityQueue. >>> >>> Regards, Roger >>> >>> >>> On 3/3/22 6:59 AM, Jules W. wrote: >>>> Hi all, >>>> >>>> A new PR that adds methods to PriorityQueue was created some time ago at >>>> https://github.com/openjdk/jdk/pull/6938 but has no corresponding >> issue. As >>>> I'm not too familiar with this part of the JDK I'm querying this mailing >>>> list for anyone to properly review the PR before I create an issue for >> it >>>> in the JBS >>>> >>>> best regards, >>>> Julian Waters From duke at openjdk.java.net Fri Mar 4 16:23:07 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 4 Mar 2022 16:23:07 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v24] In-Reply-To: <7ZEhdJX3sLr8tLhWLdvtV0B7iyrdhyZ4NFyVSA9wtl0=.fb302f1e-2019-4a95-bb6f-b24988174181@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> <7ZEhdJX3sLr8tLhWLdvtV0B7iyrdhyZ4NFyVSA9wtl0=.fb302f1e-2019-4a95-bb6f-b24988174181@github.com> Message-ID: On Fri, 4 Mar 2022 02:27:53 GMT, Stuart Marks wrote: > OK, I took a look at HashMapsPutAllOverAllocateTableTest.java. It's certainly a good start at testing stuff in this area. However, I notice that > > ``` > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java > ``` > > already exists and tests kind-of similar things. I think it would be preferable to enhance this test with additional assertions since it already has a bunch of machinery to inspect the various internals. It tests both HashMap and LinkedHashMap, so I think it would be ok to add a WeakHashMap test here as well. I note however that it relies on LinkedHashMap being a subclass of HashMap, which WeakHashMap is not, and so there will be a certain amount of messiness adding in the handling for WeakHashMap. > > Once this is in place though I think adding the additional test cases would fit in well here. In particular, it should be possible to test the proper table lengths for the copy-constructor and putAll cases (from your original bug report) as well as the premature table expansion in WeakHashMap. > > This test could use some cleanup as well. For example, the capacityTestInitialCapacity() method has a list of suppliers that it loops over. This is probably better expressed as a data provider driving a test method that tests one case. There's a bit of an art to setting this up. TestNG wants each test case to be `Object[][]` which is kind of a pain if you want to use a lambda. A trick is to have a method that returns `Object[]` representing one test case, and have the parameters of this method provide the target types for the lambdas. For example: > > ``` > Object[] testcase(String label, Supplier> s, Consumer> c, int expectedCapacity) { > return new Object[] { label, s, c, expectedCapacity }; > } > ``` > > and then have the actual data provider just be a series of calls to this method in an array literal: > > ``` > @DataProvider > public Object[][] allCases() { > return new Object[][] { > testcase("HMputAll", () -> new HashMap<>(), m -> m.putAll(MAP12), 16), > testcase("WHMputAll", () -> new WeakHashMap<>(), m -> m.putAll(MAP12), 16), > testcase("HMcopyctor", () -> new HashMap<>(MAP12), m -> { }, 16), > testcase("WHMcopyctor", () -> new WeakHashMap<>(MAP12), m -> { }, 16), > }; > } > ``` > > This lets you write the lambdas without a cast that provides the target type. > > The test method calls the supplier, passes the map to the consumer, gets the table length, and asserts that it's equal to the expected length. Note that I've set this up with separate supplier and consumer in order to accommodate both the copy constructor cases and the putAll cases. Finally, the label string isn't used by the test method, but it's useful if one of the cases fails. TestNG will print out the arguments of a failing case and the label helps a lot here, as the string form of the lambda is basically unintelligible. @stuart-marks I see codes WhiteBoxResizeTest. If you want to add some class who not extend HashMap into it, it need to change very much contents, nearly a rewrite. Though if you really want this I would like to have a try. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From luhenry at openjdk.java.net Fri Mar 4 16:25:22 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Fri, 4 Mar 2022 16:25:22 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops Message-ID: Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` Benchmark (size) Mode Cnt Score Error Units StringHashCode.Algorithm.scalar 0 avgt 1.799 ns/op StringHashCode.Algorithm.scalar 1 avgt 3.233 ns/op StringHashCode.Algorithm.scalar 10 avgt 6.617 ns/op StringHashCode.Algorithm.scalar 100 avgt 61.481 ns/op StringHashCode.Algorithm.scalar 1000 avgt 631.690 ns/op StringHashCode.Algorithm.scalar 10000 avgt 6293.611 ns/op StringHashCode.Algorithm.scalarUnrolled8 0 avgt 1.890 ns/op StringHashCode.Algorithm.scalarUnrolled8 1 avgt 3.494 ns/op StringHashCode.Algorithm.scalarUnrolled8 10 avgt 9.050 ns/op StringHashCode.Algorithm.scalarUnrolled8 100 avgt 31.725 ns/op StringHashCode.Algorithm.scalarUnrolled8 1000 avgt 321.031 ns/op StringHashCode.Algorithm.scalarUnrolled8 10000 avgt 3203.838 ns/op StringHashCode.Algorithm.scalarUnrolled16 0 avgt 1.953 ns/op StringHashCode.Algorithm.scalarUnrolled16 1 avgt 3.485 ns/op StringHashCode.Algorithm.scalarUnrolled16 10 avgt 7.041 ns/op StringHashCode.Algorithm.scalarUnrolled16 100 avgt 30.975 ns/op StringHashCode.Algorithm.scalarUnrolled16 1000 avgt 316.616 ns/op StringHashCode.Algorithm.scalarUnrolled16 10000 avgt 3208.658 ns/op At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf ------------- Commit messages: - 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops Changes: https://git.openjdk.java.net/jdk/pull/7700/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282664 Stats: 168 lines in 4 files changed: 165 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7700.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700 PR: https://git.openjdk.java.net/jdk/pull/7700 From stuefe at openjdk.java.net Fri Mar 4 16:51:05 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 4 Mar 2022 16:51:05 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 Looks good. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7691 From duke at openjdk.java.net Fri Mar 4 16:56:25 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 16:56:25 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines Message-ID: Hi I have reviewed the code for removing double semicolons at the end of lines all the best matteo ------------- Commit messages: - Removed double semicolon at the end of lines Changes: https://git.openjdk.java.net/jdk/pull/7268/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7268&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282657 Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod Patch: https://git.openjdk.java.net/jdk/pull/7268.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7268/head:pull/7268 PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 16:56:25 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 16:56:25 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Hi I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted. Now: what is the next step? This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code. ciao matteo ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From jwaters at openjdk.java.net Fri Mar 4 16:56:26 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Fri, 4 Mar 2022 16:56:26 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 25 Feb 2022 15:40:09 GMT, Matteo Baccan wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > Hi > > I have pushed this PR about 1 month ago. Only 3 days ago OCA was accepted. > Now: what is the next step? > > This is a cleanup PR that removes some double semicolons at the end of some lines inside the JDK code. > > ciao > matteo Hi @matteobaccan The next step would be to create a relevant issue on the tracker and set it to track this PR. Since you don't have the ability to create new issues on the JBS yet I'll help you create one, please rename your PR title to 8282657 and the system should take care of the rest and automatically mark your PR as ready for review after setting it to track the corresponding JBS entry. Cheers, Julian ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From naoto at openjdk.java.net Fri Mar 4 17:01:07 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 17:01:07 GMT Subject: Integrated: 8282081: java.time.DateTimeFormatter: wrong definition of symbol F In-Reply-To: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> References: <5ITr32FQZzX5oQf2jgdAVR9ZVkAw7OXNwVop8SjPypQ=.a031176f-e25e-4253-870d-66828b535de0@github.com> Message-ID: On Mon, 28 Feb 2022 23:17:57 GMT, Naoto Sato wrote: > Fixing the definition and implementation of the pattern symbol `F`. Although it is an incompatible change, I believe it is worth the fix. For that, a CSR has been drafted. This pull request has now been integrated. Changeset: 733c7907 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/733c7907b0059cc734fd1aa5b8d31f9c3e2e3079 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8282081: java.time.DateTimeFormatter: wrong definition of symbol F Reviewed-by: joehw, scolebourne, lancea, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7640 From rriggs at openjdk.java.net Fri Mar 4 17:04:02 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 17:04:02 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 15:54:14 GMT, Ludovic Henry wrote: > Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. > > Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` > > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.scalar 0 avgt 1.799 ns/op > StringHashCode.Algorithm.scalar 1 avgt 3.233 ns/op > StringHashCode.Algorithm.scalar 10 avgt 6.617 ns/op > StringHashCode.Algorithm.scalar 100 avgt 61.481 ns/op > StringHashCode.Algorithm.scalar 1000 avgt 631.690 ns/op > StringHashCode.Algorithm.scalar 10000 avgt 6293.611 ns/op > StringHashCode.Algorithm.scalarUnrolled8 0 avgt 1.890 ns/op > StringHashCode.Algorithm.scalarUnrolled8 1 avgt 3.494 ns/op > StringHashCode.Algorithm.scalarUnrolled8 10 avgt 9.050 ns/op > StringHashCode.Algorithm.scalarUnrolled8 100 avgt 31.725 ns/op > StringHashCode.Algorithm.scalarUnrolled8 1000 avgt 321.031 ns/op > StringHashCode.Algorithm.scalarUnrolled8 10000 avgt 3203.838 ns/op > StringHashCode.Algorithm.scalarUnrolled16 0 avgt 1.953 ns/op > StringHashCode.Algorithm.scalarUnrolled16 1 avgt 3.485 ns/op > StringHashCode.Algorithm.scalarUnrolled16 10 avgt 7.041 ns/op > StringHashCode.Algorithm.scalarUnrolled16 100 avgt 30.975 ns/op > StringHashCode.Algorithm.scalarUnrolled16 1000 avgt 316.616 ns/op > StringHashCode.Algorithm.scalarUnrolled16 10000 avgt 3208.658 ns/op > > > At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. > > [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf This straight forward enough. But I wonder if this should be a hotspot intrinsic and be able to take advantage vector machine instructions. I'd also expect there is an existing test that checks the value of String.hashCode. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From lancea at openjdk.java.net Fri Mar 4 17:07:59 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 4 Mar 2022 17:07:59 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo The changes look OK. The copyright year probably should be updated as part of this PR ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 17:14:05 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Fri, 4 Mar 2022 17:14:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Hi Lance I can make a second commit updating the copyright year Tell me if this is necessary ciao matteo ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 17:17:06 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 4 Mar 2022 17:17:06 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v24] In-Reply-To: <7ZEhdJX3sLr8tLhWLdvtV0B7iyrdhyZ4NFyVSA9wtl0=.fb302f1e-2019-4a95-bb6f-b24988174181@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> <7ZEhdJX3sLr8tLhWLdvtV0B7iyrdhyZ4NFyVSA9wtl0=.fb302f1e-2019-4a95-bb6f-b24988174181@github.com> Message-ID: On Fri, 4 Mar 2022 02:27:53 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> cast several float to double before calculation > > OK, I took a look at HashMapsPutAllOverAllocateTableTest.java. It's certainly a good start at testing stuff in this area. However, I notice that > > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java > > already exists and tests kind-of similar things. I think it would be preferable to enhance this test with additional assertions since it already has a bunch of machinery to inspect the various internals. It tests both HashMap and LinkedHashMap, so I think it would be ok to add a WeakHashMap test here as well. I note however that it relies on LinkedHashMap being a subclass of HashMap, which WeakHashMap is not, and so there will be a certain amount of messiness adding in the handling for WeakHashMap. > > Once this is in place though I think adding the additional test cases would fit in well here. In particular, it should be possible to test the proper table lengths for the copy-constructor and putAll cases (from your original bug report) as well as the premature table expansion in WeakHashMap. > > This test could use some cleanup as well. For example, the capacityTestInitialCapacity() method has a list of suppliers that it loops over. This is probably better expressed as a data provider driving a test method that tests one case. There's a bit of an art to setting this up. TestNG wants each test case to be `Object[][]` which is kind of a pain if you want to use a lambda. A trick is to have a method that returns `Object[]` representing one test case, and have the parameters of this method provide the target types for the lambdas. For example: > > Object[] testcase(String label, Supplier> s, Consumer> c, int expectedCapacity) { > return new Object[] { label, s, c, expectedCapacity }; > } > > and then have the actual data provider just be a series of calls to this method in an array literal: > > @DataProvider > public Object[][] allCases() { > return new Object[][] { > testcase("HMputAll", () -> new HashMap<>(), m -> m.putAll(MAP12), 16), > testcase("WHMputAll", () -> new WeakHashMap<>(), m -> m.putAll(MAP12), 16), > testcase("HMcopyctor", () -> new HashMap<>(MAP12), m -> { }, 16), > testcase("WHMcopyctor", () -> new WeakHashMap<>(MAP12), m -> { }, 16), > }; > } > > This lets you write the lambdas without a cast that provides the target type. > > The test method calls the supplier, passes the map to the consumer, gets the table length, and asserts that it's equal to the expected length. Note that I've set this up with separate supplier and consumer in order to accommodate both the copy constructor cases and the putAll cases. Finally, the label string isn't used by the test method, but it's useful if one of the cases fails. TestNG will print out the arguments of a failing case and the label helps a lot here, as the string form of the lambda is basically unintelligible. @stuart-marks done but cannot pass that test, because WeakHashMap have no such mechanism that do not create table[] when empty, only create it when first element exist, but HashMap do. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 4 17:17:06 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 4 Mar 2022 17:17:06 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v24] In-Reply-To: <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <69eK3Jbr8VSTd-HYHy_tzM87isyMbFd67Z3slXeWNSA=.1ae263d3-4fa2-424b-9721-48f6bb94b561@github.com> Message-ID: <5XBR7XIR8M9DgAvMftbpiRo3mXlqNHYCBZTpKvAHs_M=.ae84a941-5675-400c-b845-99036786ea73@github.com> On Thu, 3 Mar 2022 15:46:37 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > cast several float to double before calculation I would ping the test codes here and you can run jtreg to see. /* * Copyright (c) 2018, Red Hat, Inc. 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 * under the terms of the GNU General Public License version 2 only, as * published by the Free Software Foundation. * * This code is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License * version 2 for more details (a copy is included in the LICENSE file that * accompanied this code). * * You should have received a copy of the GNU General Public License version * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. * * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA * or visit www.oracle.com if you need additional information or have any * questions. */ import org.testng.annotations.Test; import java.lang.invoke.MethodHandle; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; import java.lang.invoke.VarHandle; import java.lang.reflect.Array; import java.lang.reflect.Field; import java.util.HashMap; import java.util.LinkedHashMap; import java.util.List; import java.util.Map; import java.util.Objects; import java.util.WeakHashMap; import java.util.concurrent.ThreadLocalRandom; import java.util.function.Supplier; import java.util.stream.IntStream; import static java.util.stream.Collectors.toMap; import static org.testng.Assert.assertEquals; /* * @test * @bug 8210280 * @modules java.base/java.util:open * @summary White box tests for HashMap internals around table resize * @run testng WhiteBoxResizeTest * @key randomness */ public class WhiteBoxResizeTest { final ThreadLocalRandom rnd = ThreadLocalRandom.current(); final MethodHandle TABLE_SIZE_FOR; final VarHandle THRESHOLD; final VarHandle TABLE; public WhiteBoxResizeTest() throws ReflectiveOperationException { Class mClass = HashMap.class; String nodeClassName = mClass.getName() + "$Node"; Class nodeArrayClass = Class.forName("[L" + nodeClassName + ";"); MethodHandles.Lookup lookup = MethodHandles.privateLookupIn(mClass, MethodHandles.lookup()); TABLE = lookup.findVarHandle(mClass, "table", nodeArrayClass); this.TABLE_SIZE_FOR = lookup.findStatic( mClass, "tableSizeFor", MethodType.methodType(int.class, int.class)); this.THRESHOLD = lookup.findVarHandle(mClass, "threshold", int.class); } int tableSizeFor(int n) { try { return (int) TABLE_SIZE_FOR.invoke(n); } catch (Throwable t) { throw new AssertionError(t); } } @Test public void testTableSizeFor() { assertEquals(tableSizeFor(0), 1); assertEquals(tableSizeFor(1), 1); assertEquals(tableSizeFor(2), 2); assertEquals(tableSizeFor(3), 4); assertEquals(tableSizeFor(15), 16); assertEquals(tableSizeFor(16), 16); assertEquals(tableSizeFor(17), 32); int maxSize = 1 << 30; assertEquals(tableSizeFor(maxSize - 1), maxSize); assertEquals(tableSizeFor(maxSize), maxSize); assertEquals(tableSizeFor(maxSize + 1), maxSize); assertEquals(tableSizeFor(Integer.MAX_VALUE), maxSize); } @Test public void capacityTestDefaultConstructor() throws NoSuchFieldException, IllegalAccessException { capacityTestDefaultConstructor(new HashMap<>()); capacityTestDefaultConstructor(new LinkedHashMap<>()); capacityTestDefaultConstructor(new WeakHashMap<>()); } public static int getArrayLength(Map map) throws IllegalAccessException { Field field = null; Class mapClass = map.getClass(); while (!Map.class.equals(mapClass)) { try { field = mapClass.getDeclaredField("table"); break; } catch (NoSuchFieldException ignored){ } mapClass = mapClass.getSuperclass(); } Objects.requireNonNull(field); field.setAccessible(true); Object table = field.get(map); if (table == null) { return -1; } return Array.getLength(table); } void capacityTestDefaultConstructor( Map map ) throws IllegalAccessException { assertEquals(getArrayLength(map), -1); map.put(1, 1); assertEquals(getArrayLength(map), 16); // default initial capacity map.putAll(IntStream.range(0, 64).boxed().collect(toMap(i -> i, i -> i))); assertEquals(getArrayLength(map), 128); } @Test public void capacityTestInitialCapacity() throws NoSuchFieldException, IllegalAccessException { int initialCapacity = rnd.nextInt(2, 128); List>> suppliers = List.of( () -> new HashMap<>(initialCapacity), () -> new HashMap<>(initialCapacity, 0.75f), () -> new LinkedHashMap<>(initialCapacity), () -> new LinkedHashMap<>(initialCapacity, 0.75f), () -> new WeakHashMap<>(initialCapacity), () -> new WeakHashMap<>(initialCapacity, 0.75f)); for (Supplier> supplier : suppliers) { Map map = supplier.get(); assertEquals(-1, getArrayLength(map)); map.put(1, 1); assertEquals(getArrayLength(map), tableSizeFor(initialCapacity)); } } } I do think creating such mechanism for WeakHashMap is benifitial, and would like to do it in another pr, but that sounds not much related to this issue. Let's do this first and then we do that next. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From redestad at openjdk.java.net Fri Mar 4 17:18:06 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 4 Mar 2022 17:18:06 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 15:54:14 GMT, Ludovic Henry wrote: > Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. > > Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` > > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.scalar 0 avgt 1.799 ns/op > StringHashCode.Algorithm.scalar 1 avgt 3.233 ns/op > StringHashCode.Algorithm.scalar 10 avgt 6.617 ns/op > StringHashCode.Algorithm.scalar 100 avgt 61.481 ns/op > StringHashCode.Algorithm.scalar 1000 avgt 631.690 ns/op > StringHashCode.Algorithm.scalar 10000 avgt 6293.611 ns/op > StringHashCode.Algorithm.scalarUnrolled8 0 avgt 1.890 ns/op > StringHashCode.Algorithm.scalarUnrolled8 1 avgt 3.494 ns/op > StringHashCode.Algorithm.scalarUnrolled8 10 avgt 9.050 ns/op > StringHashCode.Algorithm.scalarUnrolled8 100 avgt 31.725 ns/op > StringHashCode.Algorithm.scalarUnrolled8 1000 avgt 321.031 ns/op > StringHashCode.Algorithm.scalarUnrolled8 10000 avgt 3203.838 ns/op > StringHashCode.Algorithm.scalarUnrolled16 0 avgt 1.953 ns/op > StringHashCode.Algorithm.scalarUnrolled16 1 avgt 3.485 ns/op > StringHashCode.Algorithm.scalarUnrolled16 10 avgt 7.041 ns/op > StringHashCode.Algorithm.scalarUnrolled16 100 avgt 30.975 ns/op > StringHashCode.Algorithm.scalarUnrolled16 1000 avgt 316.616 ns/op > StringHashCode.Algorithm.scalarUnrolled16 10000 avgt 3208.658 ns/op > > > At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. > > [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf My only comment is that I'd like to see some benchmark verifying also the UTF-16 code path. It should see a similar speed-up, but adding plenty of calls might mess up compilation and inlining. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From rriggs at openjdk.java.net Fri Mar 4 17:20:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 17:20:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot. And corresponding tests. This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers. If you had ask ahead of time, I would have suggested finding something with more value. ------------- Changes requested by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Fri Mar 4 17:30:48 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 4 Mar 2022 17:30:48 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v25] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refine test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/d168ad4b..261ae627 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=24 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=23-24 Stats: 60 lines in 1 file changed: 42 ins; 0 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From luhenry at openjdk.java.net Fri Mar 4 17:33:23 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Fri, 4 Mar 2022 17:33:23 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:01:05 GMT, Roger Riggs wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalar 0 avgt 1.799 ns/op >> StringHashCode.Algorithm.scalar 1 avgt 3.233 ns/op >> StringHashCode.Algorithm.scalar 10 avgt 6.617 ns/op >> StringHashCode.Algorithm.scalar 100 avgt 61.481 ns/op >> StringHashCode.Algorithm.scalar 1000 avgt 631.690 ns/op >> StringHashCode.Algorithm.scalar 10000 avgt 6293.611 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 0 avgt 1.890 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 1 avgt 3.494 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 10 avgt 9.050 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 100 avgt 31.725 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 1000 avgt 321.031 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 10000 avgt 3203.838 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 0 avgt 1.953 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 1 avgt 3.485 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 10 avgt 7.041 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 100 avgt 30.975 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 1000 avgt 316.616 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 10000 avgt 3208.658 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > This straight forward enough. But I wonder if this should be a hotspot intrinsic and be able to take advantage vector machine instructions. > I'd also expect there is an existing test that checks the value of String.hashCode. @RogerRiggs I would be happy to do such work. As it would be a bigger change, are you suggesting that it could be done or that it should be done as an intrinsic? @cl4es adding that right now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From luhenry at openjdk.java.net Fri Mar 4 17:44:44 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Fri, 4 Mar 2022 17:44:44 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: > Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. > > Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. > > Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` > > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.scalar 0 avgt 1.799 ns/op > StringHashCode.Algorithm.scalar 1 avgt 3.233 ns/op > StringHashCode.Algorithm.scalar 10 avgt 6.617 ns/op > StringHashCode.Algorithm.scalar 100 avgt 61.481 ns/op > StringHashCode.Algorithm.scalar 1000 avgt 631.690 ns/op > StringHashCode.Algorithm.scalar 10000 avgt 6293.611 ns/op > StringHashCode.Algorithm.scalarUnrolled8 0 avgt 1.890 ns/op > StringHashCode.Algorithm.scalarUnrolled8 1 avgt 3.494 ns/op > StringHashCode.Algorithm.scalarUnrolled8 10 avgt 9.050 ns/op > StringHashCode.Algorithm.scalarUnrolled8 100 avgt 31.725 ns/op > StringHashCode.Algorithm.scalarUnrolled8 1000 avgt 321.031 ns/op > StringHashCode.Algorithm.scalarUnrolled8 10000 avgt 3203.838 ns/op > StringHashCode.Algorithm.scalarUnrolled16 0 avgt 1.953 ns/op > StringHashCode.Algorithm.scalarUnrolled16 1 avgt 3.485 ns/op > StringHashCode.Algorithm.scalarUnrolled16 10 avgt 7.041 ns/op > StringHashCode.Algorithm.scalarUnrolled16 100 avgt 30.975 ns/op > StringHashCode.Algorithm.scalarUnrolled16 1000 avgt 316.616 ns/op > StringHashCode.Algorithm.scalarUnrolled16 10000 avgt 3208.658 ns/op > > > At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. > > [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: Add UTF-16 benchmarks ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7700/files - new: https://git.openjdk.java.net/jdk/pull/7700/files/f7dda1d9..8e2e59bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7700&range=00-01 Stats: 119 lines in 1 file changed: 70 ins; 7 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/7700.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7700/head:pull/7700 PR: https://git.openjdk.java.net/jdk/pull/7700 From luhenry at openjdk.java.net Fri Mar 4 17:44:45 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Fri, 4 Mar 2022 17:44:45 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:14:34 GMT, Claes Redestad wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalar 0 avgt 1.799 ns/op >> StringHashCode.Algorithm.scalar 1 avgt 3.233 ns/op >> StringHashCode.Algorithm.scalar 10 avgt 6.617 ns/op >> StringHashCode.Algorithm.scalar 100 avgt 61.481 ns/op >> StringHashCode.Algorithm.scalar 1000 avgt 631.690 ns/op >> StringHashCode.Algorithm.scalar 10000 avgt 6293.611 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 0 avgt 1.890 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 1 avgt 3.494 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 10 avgt 9.050 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 100 avgt 31.725 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 1000 avgt 321.031 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 10000 avgt 3203.838 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 0 avgt 1.953 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 1 avgt 3.485 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 10 avgt 7.041 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 100 avgt 30.975 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 1000 avgt 316.616 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 10000 avgt 3208.658 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > My only comment is that I'd like to see some benchmark verifying also the UTF-16 code path. It should see a similar speed-up, but adding plenty of calls might mess up compilation and inlining. @cl4es I've added the UTF-16 benchmarks. I'm running them on my machine and should have the results in ~5 hours. I'll update the PR description once I've these numbers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From duke at openjdk.java.net Fri Mar 4 17:47:02 2022 From: duke at openjdk.java.net (liach) Date: Fri, 4 Mar 2022 17:47:02 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v25] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 4 Mar 2022 17:30:48 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refine test nitpick for the test code: for better performance, move method handle and var handle to static final fields so the jvm can run faster ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From ihse at openjdk.java.net Fri Mar 4 17:50:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 4 Mar 2022 17:50:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:17:12 GMT, Roger Riggs wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > We usually request that these be be broken up by area to attract the appropriate reviewers and avoid eye-strain. The client modules are usually separated out, as are hotspot. > And corresponding tests. > This kind of change is pretty low value for the code base and requires the involvement of quite a few reviewers. > If you had ask ahead of time, I would have suggested finding something with more value. @RogerRiggs Otoh, this change is really trivial. I have verified that all changes are replacing trailing ";;" in Java code. These are all clearly typos. I think it's nice that we try to strive for a high quality, and while you are correct this is maybe not the most pressing issue, I think it's nice to get a cleanup like this done. I'd argue that this is a trivial change. If you are worried, let's get a couple of more reviewers. I can't see the need to split this up per area. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From jlaskey at openjdk.java.net Fri Mar 4 18:01:25 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 4 Mar 2022 18:01:25 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly Message-ID: Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. @Benchmark public void bigDecimalDefaultLocale() { result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); } @Benchmark public void bigDecimalLocaleAlternate() { result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); } @Benchmark public void bigDecimalThaiLocale() { result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); } @Benchmark public void integerDefaultLocale() { result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); } @Benchmark public void integerLocaleAlternate() { result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); } @Benchmark public void integerThaiLocale() { result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); } Before: Benchmark Mode Cnt Score Error Units MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s After: Benchmark Mode Cnt Score Error Units MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s ------------- Commit messages: - Better caching of DecimalFormatSymbols Changes: https://git.openjdk.java.net/jdk/pull/7703/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282625 Stats: 60 lines in 2 files changed: 27 ins; 27 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From duke at openjdk.java.net Fri Mar 4 18:21:06 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 4 Mar 2022 18:21:06 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v25] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 4 Mar 2022 17:43:25 GMT, liach wrote: > nitpick for the test code: for better performance, move method handle and var handle to static final fields so the jvm can run faster will do it when we really migrate this test, but it should be done in another pr when I add WeakHashMap's table's delay creation mechenism. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 4 18:54:03 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Fri, 4 Mar 2022 18:54:03 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: <1CPBFrGD_5bmMT1gPirwgkx7p5eqqwS_b-fVS82mCFM=.a2fea4a1-7fd2-4393-9088-2441660ebbbc@github.com> On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalar 0 avgt 1.799 ns/op >> StringHashCode.Algorithm.scalar 1 avgt 3.233 ns/op >> StringHashCode.Algorithm.scalar 10 avgt 6.617 ns/op >> StringHashCode.Algorithm.scalar 100 avgt 61.481 ns/op >> StringHashCode.Algorithm.scalar 1000 avgt 631.690 ns/op >> StringHashCode.Algorithm.scalar 10000 avgt 6293.611 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 0 avgt 1.890 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 1 avgt 3.494 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 10 avgt 9.050 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 100 avgt 31.725 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 1000 avgt 321.031 ns/op >> StringHashCode.Algorithm.scalarUnrolled8 10000 avgt 3203.838 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 0 avgt 1.953 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 1 avgt 3.485 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 10 avgt 7.041 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 100 avgt 30.975 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 1000 avgt 316.616 ns/op >> StringHashCode.Algorithm.scalarUnrolled16 10000 avgt 3208.658 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks May you print out the generated code? My wild guess is that the updated version is still scalar, the improvement comes from dependency breakdown. I suggest hoisting the accumulation out of the main loop to achieve maximal scalar throughput. A small experiment on my machine shows improvement over your approach. int c0 = 0, c1 = 0, c2 = 0, c3 = 0; int i = 0, len = value.length; for (; i < (len & (~3)); i += 4) { c3 = c3 * 92351 + (value[i + 3] & 0xff); c2 = c2 * 92351 + (value[i + 2] & 0xff); c1 = c1 * 92351 + (value[i + 1] & 0xff); c0 = c0 * 92351 + (value[i] & 0xff); } int h = c3 * 29791 + c2 * 961 + c1 * 31 + c0; for (; i < len; i++) { h = h * 31 + (value[i] & 0xff); } return h; Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From jbhateja at openjdk.java.net Fri Mar 4 19:08:09 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 4 Mar 2022 19:08:09 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: References: Message-ID: <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com> On Fri, 4 Mar 2022 06:06:52 GMT, Joe Darcy wrote: >> test/jdk/java/lang/Math/RoundTests.java line 32: >> >>> 30: public static void main(String... args) { >>> 31: int failures = 0; >>> 32: for (int i = 0; i < 100000; i++) { >> >> Is there an idiom to trigger the auto-vectorization, perhaps using command line arguments, that doesn't bloat the running time of this test? > > IMO RoundTests should have a explicit @run tag without any VM options as well. > > Do the added VM options run on all platforms in question? What is the approximate time to run the test run compared to before? Hi @jddarcy , Test has been modified on the same lines using generic options which manipulate compilation thresholds and agnostic to target platforms. * @run main/othervm -XX:Tier3CompileThreshold=100 -XX:CompileThresholdScaling=0.01 -XX:+TieredCompilation RoundTests Verified that RoundTests::test* methods gets compiled by c2. Test execution time with and without change is almost same ~7.80sec over Skylake-server. Regards ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From naoto at openjdk.java.net Fri Mar 4 19:10:06 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 19:10:06 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly In-Reply-To: References: Message-ID: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> On Fri, 4 Mar 2022 17:54:20 GMT, Jim Laskey wrote: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Good to see the performance improvement. Since you are adding a new public method, a CSR is needed for this change. src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 194: > 192: * Gets the locale used to create this table. > 193: * > 194: * @return the the locale used to create this table `table` does not read right here, also `@since 19` is needed. src/java.base/share/classes/java/util/Formatter.java line 2016: > 2014: static DecimalFormatSymbols getDecimalFormatSymbols(Locale locale) { > 2015: DecimalFormatSymbols dfs = DFS; > 2016: if (dfs != null && dfs.getLocale() == locale) { `Locale` should be compared using `equals()`. src/java.base/share/classes/java/util/Formatter.java line 2026: > 2024: // Caching zero. > 2025: static char getZero(Locale locale) { > 2026: return locale == null ? '0' : getDecimalFormatSymbols(locale).getZeroDigit(); While we are at it, it would be beneficial to cache locale-dependent grouping and decimal separators too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From prr at openjdk.java.net Fri Mar 4 19:10:06 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 4 Mar 2022 19:10:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by prr (Reviewer). Looks like there's only one client source code file touched Most of the client changes are only in jtreg tests - and this is very trivial, so I'm OK with them being included here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From jlaskey at openjdk.java.net Fri Mar 4 19:22:02 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 4 Mar 2022 19:22:02 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly In-Reply-To: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> Message-ID: On Fri, 4 Mar 2022 18:59:56 GMT, Naoto Sato wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 194: > >> 192: * Gets the locale used to create this table. >> 193: * >> 194: * @return the the locale used to create this table > > `table` does not read right here, also `@since 19` is needed. Noted. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From rriggs at openjdk.java.net Fri Mar 4 19:33:06 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 19:33:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From jlaskey at openjdk.java.net Fri Mar 4 19:38:07 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 4 Mar 2022 19:38:07 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly In-Reply-To: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> Message-ID: On Fri, 4 Mar 2022 19:00:54 GMT, Naoto Sato wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > src/java.base/share/classes/java/util/Formatter.java line 2016: > >> 2014: static DecimalFormatSymbols getDecimalFormatSymbols(Locale locale) { >> 2015: DecimalFormatSymbols dfs = DFS; >> 2016: if (dfs != null && dfs.getLocale() == locale) { > > `Locale` should be compared using `equals()`. I know this looks wrong and I debated with myself about it, but 1) Locale equals is complex 2) many Locales are global constants 3) there is a 1-1 correspondence of DecimalFormatSymbols to locale. AFAIK even If two locales describe the same configuration there will be two distinct DecimalFormatSymbols. Is this not the case? I can add a comment to indicate that this is was deliberate decision. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From prr at openjdk.java.net Fri Mar 4 19:42:08 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 4 Mar 2022 19:42:08 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 I've increased the number of reviewers because as well as the current reviewer it should have (1) a reviewer from the client team (2) a reviewer from whoever owns jni_util.h If there were no change to that file it would have been simpler. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From iris at openjdk.java.net Fri Mar 4 19:43:03 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 4 Mar 2022 19:43:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Nice tidy of the code. Is there anything that can be done to prevent re-introduction of this trivial problem? Perhaps a new Skara bot jcheck option similar to what is already in place for trailing whitespace? ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From naoto at openjdk.java.net Fri Mar 4 19:54:04 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 19:54:04 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly In-Reply-To: References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> Message-ID: <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com> On Fri, 4 Mar 2022 19:33:07 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/util/Formatter.java line 2016: >> >>> 2014: static DecimalFormatSymbols getDecimalFormatSymbols(Locale locale) { >>> 2015: DecimalFormatSymbols dfs = DFS; >>> 2016: if (dfs != null && dfs.getLocale() == locale) { >> >> `Locale` should be compared using `equals()`. > > I know this looks wrong and I debated with myself about it, but 1) Locale equals is complex 2) many Locales are global constants 3) there is a 1-1 correspondence of DecimalFormatSymbols to locale. AFAIK even If two locales describe the same configuration there will be two distinct DecimalFormatSymbols. Is this not the case? I can add a comment to indicate that this is was deliberate decision. I am afraid people are still using constructors for creating a locale, instead of the factory method that was added later. Since `new Locale("en") == new Locale("en")` returns `false`, I'd still expect `equals()` to compare locales. As to the constants, the number of them is relatively small, IMO. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From wetmore at openjdk.java.net Fri Mar 4 19:56:03 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Fri, 4 Mar 2022 19:56:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: <1X39o4ON1uvbSXAp_r66zAmSy6sWZFKaP7-M54vAqX0=.d6abe0d5-9dd2-409b-91df-255d838196cb@github.com> On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo LGTM also. Similar suggestion for updating copyrights. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From rriggs at openjdk.java.net Fri Mar 4 20:04:02 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 20:04:02 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly In-Reply-To: <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com> References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com> Message-ID: On Fri, 4 Mar 2022 19:50:29 GMT, Naoto Sato wrote: >> I know this looks wrong and I debated with myself about it, but 1) Locale equals is complex 2) many Locales are global constants 3) there is a 1-1 correspondence of DecimalFormatSymbols to locale. AFAIK even If two locales describe the same configuration there will be two distinct DecimalFormatSymbols. Is this not the case? I can add a comment to indicate that this is was deliberate decision. > > I am afraid people are still using constructors for creating a locale, instead of the factory method that was added later. Since `new Locale("en") == new Locale("en")` returns `false`, I'd still expect `equals()` to compare locales. As to the constants, the number of them is relatively small, IMO. As a separate/future issue, perhaps the constructors should be deprecated to nudge people to using the static `getInstance` methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From smarks at openjdk.java.net Fri Mar 4 20:09:07 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Mar 2022 20:09:07 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v25] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 4 Mar 2022 17:30:48 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refine test > I see codes WhiteBoxResizeTest. If you want to add some class who not extend HashMap into it, it need to change very much contents, nearly a rewrite. Though if you really want this I would like to have a try. > done but cannot pass that test, because WeakHashMap have no such mechanism that do not create table[] when empty, only create it when first element exist, but HashMap do. Yes, I'd like for the WhiteBoxResizeTest to continue to test (most of) what it's currently testing, in addition to new tests for the cases you're fixing here. The commonality here is that they're all hash tables using separate chaining, they use power-of-two table sizes, and they have a load factor that governs when the table is resized. The alternative is to have another test somewhere else that tests things that are very similar and that might or might not overlap in some ways. In addition, if we end up with a really comprehensive set of tests here in WhiteBoxResizeTest, it might reduce the need for the Enum/ConstantDirectoryOptimalCapacity.java test and the stuff in the test library that it uses. (But again, that cleanup should be separate from this.) That said, I agree, WhiteBoxResizeTest will need some rewriting. There are two main areas that need some attention: infrastructure to get internals like the `table` field, and handling of test cases themselves. (Also, I agree, let's not add lazy initialization to WeakHashMap as part of this PR. This can be handled by refactoring the test cases; see below.) For getting at the HashMap internals, the test has kind of an internal API `table()` that just gets the contents of the `table` field. Clearly this needs to be adjusted to deal with WeakHashMap vs. HashMap. This can be done in a variety of ways, e.g., by reflection, or by looking up a method handle from a preloaded map of classes to method handles. I'd encourage you to try the latter, as it's more easily extensible in the future should we decide to add Hashtable or ConcurrentHashMap here. Then, the test cases need to be pulled apart. For example, there is this: void capacityTestDefaultConstructor(HashMap map) { assertNull(table(map)); map.put(1, 1); assertEquals(capacity(map), 16); // default initial capacity map.putAll(IntStream.range(0, 64).boxed().collect(toMap(i -> i, i -> i))); assertEquals(capacity(map), 128); } This actually tests three things: 1) table is lazily allocated, 2) default capacity is 16, and 3) using putAll to populate the map with 64 elements results in a table size of 128. This should really be broken into three separate test methods. Once they're separated, the lazy allocation test should only called for HashMap and LinkedHashMap but not WeakHashMap. Then there is this: @Test public void capacityTestInitialCapacity() { int initialCapacity = rnd.nextInt(2, 128); List>> suppliers = List.of( () -> new HashMap<>(initialCapacity), () -> new HashMap<>(initialCapacity, 0.75f), () -> new LinkedHashMap<>(initialCapacity), () -> new LinkedHashMap<>(initialCapacity, 0.75f)); for (Supplier> supplier : suppliers) { HashMap map = supplier.get(); assertNull(table(map)); map.put(1, 1); assertEquals(capacity(map), tableSizeFor(initialCapacity)); } } This too needs to be pulled apart, as it's also testing different cases. The lazy-allocation cases should be moved to new cases of the lazy allocation test created above. What remains is cases that test whether the actual table size is the right size for the requested capacity. This is uncomfortably close to a test that checks the system-under-test against itself. Also, it's not clear to me the value of using random values here. Seems to me that it would be better to have a small list of edge cases to make sure that the table length resulting from a particular capacity request mathces what we expect. For example: requested expected 15 16 16 16 17 32 (I think I got those numbers right.) Once these test methods have been straightened out, it should be clearer how to add the test cases we're interested in. Specifically, 1. putting N mappings into a map using `put()` in a loop results in a table of the expected length; 2. putting N mappings into a map using `putAll(mapWithNMappings)` results in a table of the expected length; 3. creating a map with N mappings using the copy constructor results in a table of the expected length. This is a lot to do all at once. It might be reasonable to work incrementally, for example, first working on the MethodHandle infrastructure to deal with different Map classes. I can provide you with some code snippets if it's helpful. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 4 20:29:03 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 4 Mar 2022 20:29:03 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v25] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <6ahMrE0wwqVNLFuAGAkN0i1JYPLh3LykTO5f0iHwRms=.face5bf5-2aa7-40af-8629-d2c5354dd560@github.com> On Fri, 4 Mar 2022 20:05:23 GMT, Stuart Marks wrote: > This actually tests three things: 1) table is lazily allocated, 2) default capacity is 16, and 3) using putAll to populate the map with 64 elements results in a table size of 128. This should really be broken into three separate test methods. Once they're separated, the lazy allocation test should only called for HashMap and LinkedHashMap but not WeakHashMap. @stuart-marks would you mind if I break WhiteBoxResizeTest class into several smaller Test classes, each focus on one of the test points you said? If we split it into several tests, it would be more clear than sqruash into one test class, and we can make it parameterilized tests. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From jlaskey at openjdk.java.net Fri Mar 4 20:56:47 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 4 Mar 2022 20:56:47 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v2] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Use Locale equals, add support for decimal/grouping separators and fix comments in DecimalFormatSymbols.getLocale ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/ac2105f3..50944ba0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=00-01 Stats: 29 lines in 2 files changed: 14 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From smarks at openjdk.java.net Fri Mar 4 21:06:07 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 4 Mar 2022 21:06:07 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v25] In-Reply-To: <6ahMrE0wwqVNLFuAGAkN0i1JYPLh3LykTO5f0iHwRms=.face5bf5-2aa7-40af-8629-d2c5354dd560@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6ahMrE0wwqVNLFuAGAkN0i1JYPLh3LykTO5f0iHwRms=.face5bf5-2aa7-40af-8629-d2c5354dd560@github.com> Message-ID: On Fri, 4 Mar 2022 20:23:38 GMT, XenoAmess wrote: > would you mind if I break WhiteBoxResizeTest class into several smaller Test classes, each focus on one of the test points you said? Well, separate classes wouldn't be the approach that I'd take myself. However, I'm interested in you continuing to make progress on this, so if you'd prefer separate classes, then go ahead. However, I reserve the right to propose refactorings that merge things back into a single class. :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From jlaskey at openjdk.java.net Fri Mar 4 21:17:50 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 4 Mar 2022 21:17:50 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Too many 'the' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/50944ba0..9ac0c283 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From rriggs at openjdk.java.net Fri Mar 4 21:26:00 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 21:26:00 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com> Message-ID: On Fri, 4 Mar 2022 20:00:54 GMT, Roger Riggs wrote: >> I am afraid people are still using constructors for creating a locale, instead of the factory method that was added later. Since `new Locale("en") == new Locale("en")` returns `false`, I'd still expect `equals()` to compare locales. As to the constants, the number of them is relatively small, IMO. > > As a separate/future issue, perhaps the constructors should be deprecated to nudge people to using the static `getInstance` methods. Would it be just as effective and improve performance more broadly to cache in DecimalFormatSymbols.getInstance()? Declarations should be private unless there is a package need. In this case, the only access to should be via the method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From rriggs at openjdk.java.net Fri Mar 4 21:26:01 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 21:26:01 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Too many 'the' src/java.base/share/classes/java/util/Formatter.java line 2025: > 2023: > 2024: // Caching zero. > 2025: static char getZero(Locale locale) { Perhaps should be private. The comment says caching zero, but its really the DecimalFormatSymbols that are cached. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From joehw at openjdk.java.net Fri Mar 4 21:30:01 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 4 Mar 2022 21:30:01 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 05:02:37 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > copyright year fix Is the public API change, adding the isIsoLike() method, necessary? It seems to me we already have the isSupported method? for that purpose and plus isSupportedBy? from the IsoFields. Would making sure the IsoFields are supported at the implementation level be sufficient? ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From darcy at openjdk.java.net Fri Mar 4 21:33:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 4 Mar 2022 21:33:07 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From dholmes at openjdk.java.net Fri Mar 4 21:34:07 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 4 Mar 2022 21:34:07 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 I would have just inlined JNU_CHECK_EXCEPTION and added the cleanup code directly. The additional macro wasn't really necessary and would not really be usable for any kind of general cleanup actions beyond a one-liner. But it is okay. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7691 From naoto at openjdk.java.net Fri Mar 4 21:35:14 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 21:35:14 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Too many 'the' src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192: > 190: > 191: /** > 192: * Gets the locale used to create this instance. Nit: Since `@return` has the same description, `{@return ...}` can be used here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From rriggs at openjdk.java.net Fri Mar 4 21:42:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 4 Mar 2022 21:42:05 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 05:02:37 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > copyright year fix src/java.base/share/classes/java/time/chrono/Chronology.java line 792: > 790: * @since 19 > 791: */ > 792: default boolean isIsoLike() { Maybe a bit late for a name change... How about the method name being: `supportsIsoFields()`. IsoLike seem pretty wishy washy. src/java.base/share/classes/java/time/chrono/IsoChronology.java line 682: > 680: //----------------------------------------------------------------------- > 681: /** > 682: * {@inheritDoc} I would rather see the statement indicating that ISOChronology returns true; not a generic sentence. (For each of the Chronologies). "IsoChronology supports ISO based fields, such as DAY_OF_QUARTER and QUARTER_OF_YEAR." src/java.base/share/classes/java/time/temporal/IsoFields.java line 599: > 597: private static void ensureIsoLike(TemporalAccessor temporal) { > 598: if (!isIsoLike(temporal)) { > 599: throw new DateTimeException("Resolve requires ISO-like Chronology"); Would the exception be easier to debug with if it mentioned the chronology that is not ISO-like? test/jdk/java/time/test/java/time/temporal/TestIsoWeekFields.java line 132: > 130: public void test_Unit_isSupportedBy_ISO() { > 131: assertEquals(IsoFields.WEEK_BASED_YEARS.isSupportedBy(LocalDate.now()),true); > 132: assertEquals(IsoFields.WEEK_BASED_YEARS.isSupportedBy(ThaiBuddhistDate.now()),true); Typically, comma (",") is followed by space. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From naoto at openjdk.java.net Fri Mar 4 21:54:04 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 21:54:04 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 05:02:37 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > copyright year fix > ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From naoto at openjdk.java.net Fri Mar 4 21:57:56 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 21:57:56 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 21:26:57 GMT, Joe Wang wrote: > Is the public API change, adding the isIsoLike() method, necessary? Yes, I believe so. Without a means to tell whether the `TemporalAccessor`, such as `LocalDate`, supports `IsoFields`, `IsoFields` would have to hard-code which temporal accessor is supporting `IsoFields` fields. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From zgu at openjdk.java.net Fri Mar 4 21:57:58 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Fri, 4 Mar 2022 21:57:58 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 21:30:53 GMT, David Holmes wrote: > I would have just inlined JNU_CHECK_EXCEPTION and added the cleanup code directly. The additional macro wasn't really necessary and would not really be usable for any kind of general cleanup actions beyond a one-liner. > > But it is okay. > > Thanks. Thanks for the review, @dholmes-ora . The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From naoto at openjdk.java.net Fri Mar 4 23:05:56 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 4 Mar 2022 23:05:56 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v3] In-Reply-To: References: Message-ID: > Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Addresses review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7683/files - new: https://git.openjdk.java.net/jdk/pull/7683/files/12c6212a..e0b329d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=01-02 Stats: 52 lines in 10 files changed: 11 ins; 0 del; 41 mod Patch: https://git.openjdk.java.net/jdk/pull/7683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683 PR: https://git.openjdk.java.net/jdk/pull/7683 From stuart.marks at oracle.com Sat Mar 5 00:58:30 2022 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 4 Mar 2022 16:58:30 -0800 Subject: Replace simple iterations of Map.entrySet with Map.forEach calls In-Reply-To: References: Message-ID: <6900aa48-2eb5-d93e-f4ab-9c9d216ed99f@oracle.com> Hi, I have to say I'm pretty skeptical of this change overall. It sounds like the main issue is iterating over the entrySet of a map that might be modified concurrently. The bug report says > for concurrent maps, regular iteration of entrySet may fail spontaneously This isn't true for ConcurrentHashMap or ConcurrentSkipListMap, which have weakly consistent iterators that won't error out. It *is* true for synchronizedMap, which can throw ConcurrentModificationException if the map is modified during iteration. I guess that's mostly what you're referring to. The problem with synchronizedMap (and the other synchronized wrappers) is that they require external synchronization around iteration, and it's pretty much impossible to cover all the cases where iteration occurs. It's used everywhere outside the JDK. Even within the JDK, it appears quite frequently and is hard to avoid. For example, consider collection.addAll(synchronizedMap.keySet()) AbstractCollection::addAll iterates its argument, and this is inherited in a bunch of places. The root of the problem is that the synchronized wrappers support concurrent updating only in a very narrow range of use cases. If people have trouble with concurrent map updating, they need to use a real concurrent data structure, or they need to put everything inside their own class and have it do locking around higher-level operations. Replacing a few entrySet iteration cases with Map::forEach doesn't help anything. s'marks On 2/22/22 3:09 PM, - wrote: > Hello, > In the patch for 8281631 , > xenoamess intentionally avoided > repeatedly > calling Map::size, for it may not be constant-timed due to being > concurrent. This alerted me that the for loops on Map::entrySet may be > similarly not thread-safe. > > I believe that we should migrate for loop on Map::entrySet to Map::forEach > calls; concurrent map callees usually have dedicated logic > > to mitigate such thread-safety issues. Synchronized map > > callees are benefitted too. > > Another lesser benefit is reduced object allocation for iteration. While > the most popular implementations (HashMap, LinkedHashMap, WeakHashMap, > TreeMap) don't need to allocate entries for iteration, many other (EnumMap, > IdentityHashMap, concurrent maps) do, and iterating those maps with forEach > is less costly. (Note that 8170826 > takes care of > implementing proper forEach in EnumMap) > > A JBS issue has already been submitted at > https://bugs.openjdk.java.net/browse/JDK-8282178, and I have prepared a > patch. This patch modifies the putAll implementations of a few JDK maps to > let the callee feed entries through Map::forEach to be put into the maps. > Two places of Map::entrySet calls in Collectors has also been updated. > > For most other existing usages in the JDK, I don't think they will benefit > from such a migration: They mostly iterate on the entryset of the popular > implementations that already host entries and are single-threaded, and I > don't think it's in our best interest to touch those use cases. > > So, here are my questions: > 1. Is such a concept of replacing Map::entrySet calls with Map::forEach > calls reasonable, or is there any fundamental flaw? > If the concept sounds good, I will submit a patch, so we can answer > 2. Is the changes implemented correct for this concept, i.e. targeting code > where users supply callee maps? > > Best regards > From darcy at openjdk.java.net Sat Mar 5 03:09:18 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 5 Mar 2022 03:09:18 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException Message-ID: Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 ------------- Commit messages: - JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException Changes: https://git.openjdk.java.net/jdk/pull/7711/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282696 Stats: 92 lines in 4 files changed: 60 ins; 13 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7711/head:pull/7711 PR: https://git.openjdk.java.net/jdk/pull/7711 From darcy at openjdk.java.net Sat Mar 5 03:14:36 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 5 Mar 2022 03:14:36 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v2] In-Reply-To: References: Message-ID: > Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. > > Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. > > Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Retrofit another location. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7711/files - new: https://git.openjdk.java.net/jdk/pull/7711/files/afc1d016..7ff24c26 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7711/head:pull/7711 PR: https://git.openjdk.java.net/jdk/pull/7711 From smarks at openjdk.java.net Sat Mar 5 03:19:10 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 5 Mar 2022 03:19:10 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v12] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 01:44:44 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > fix wrong identation > > Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> Hi, I'm getting back to this after returning from vacation. Some of the suggestions made by various people are good and should be applied to this PR. In particular: * Add a private Random constructor that avoids calling `setSeed`. The suggestion from @liach to have it take a `Void` parameter is a good one. Then, have the wrapper's constructor call `super(null)`. This allows you to get rid of the `initialized` variable, and `setSeed` can simply throw unconditionally. * The code path from `Random::from` to the wrapper can be simplified; it looks like there's an extra method here. Probably just have `Random::from` check if the arg is instanceof Random and return it, otherwise it can call the `RandomWrapper` constructor. * Make sure there's a null check as well, probably in the RW constructor. * Make the wrapper a final class, out of an abundance of caution, to reduce the risk of some serialization attacks. Regarding serialization. As far as I can see, none of the new RandomGenerator implementations are serializable. A possibility would be to make the wrapper "conditionally serializable" in case the RG it contains is serializable; but this is impossible to test since we don't have any serializable RG implementations. Thus it seems pointless for the wrapper to support serialization, and it should be disabled. Don't add `serialVersionUID`, and leave the serial warning suppression. To disable serialization, add these methods to the wrapper class: /** * Throws {@code NotSerializableException}. * @param s the object input stream * @throws NotSerializableException always */ @Serial private void readObject(ObjectInputStream s) throws NotSerializableException { throw new NotSerializableException("not serializable"); } /** * Throws {@code NotSerializableException}. * @param s the object output stream * @throws NotSerializableException always */ @Serial private void writeObject(ObjectOutputStream s) throws NotSerializableException { throw new NotSerializableException("not serializable"); } Here's a suggestion for the spec of the public `from` method. Note, it's not necessary to link to `Random` because this method is inside the Random class. /** * Returns an instance of {@code Random} that delegates method calls to the{@link RandomGenerator} * argument. If the generator is an instance of {@code Random}, it is returned. Otherwise, this method * returns an instance of {@code Random} that delegates all methods except {@code setSeed} to the generator. * The returned instance's {@code setSeed} method always throws {@link UnsupportedOperationException}. * The returned instance is not serializable. * * @param generator the {@code RandomGenerator} calls are delegated to * @return the delegating {@code Random} instance */ ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From rriggs at openjdk.java.net Sat Mar 5 03:24:07 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Sat, 5 Mar 2022 03:24:07 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v2] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 03:14:36 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. >> >> Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. >> >> Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Retrofit another location. Changes requested by rriggs (Reviewer). src/java.base/share/classes/java/io/InvalidObjectException.java line 63: > 61: */ > 62: public InvalidObjectException(String reason, Throwable cause) { > 63: super(reason); Should this be: `super(reason, cause)`? src/java.base/share/classes/java/io/ObjectInputStream.java line 2218: > 2216: throw new InvalidObjectException("enum constant " + > 2217: name + " does not exist in " + > 2218: cl, ex); Can this be reflowed to be on two lines instead of 3? Your call. ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From darcy at openjdk.java.net Sat Mar 5 03:24:07 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 5 Mar 2022 03:24:07 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v2] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 03:14:33 GMT, Roger Riggs wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Retrofit another location. > > src/java.base/share/classes/java/io/InvalidObjectException.java line 63: > >> 61: */ >> 62: public InvalidObjectException(String reason, Throwable cause) { >> 63: super(reason); > > Should this be: `super(reason, cause)`? Yes; good catch -- will fix in the next push. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From darcy at openjdk.java.net Sat Mar 5 03:29:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 5 Mar 2022 03:29:44 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3] In-Reply-To: References: Message-ID: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> > Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. > > Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. > > Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 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.java.net/jdk/pull/7711/files - new: https://git.openjdk.java.net/jdk/pull/7711/files/7ff24c26..2b2219eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7711/head:pull/7711 PR: https://git.openjdk.java.net/jdk/pull/7711 From liangchenblue at gmail.com Sat Mar 5 04:43:27 2022 From: liangchenblue at gmail.com (-) Date: Fri, 4 Mar 2022 22:43:27 -0600 Subject: Replace simple iterations of Map.entrySet with Map.forEach calls In-Reply-To: <6900aa48-2eb5-d93e-f4ab-9c9d216ed99f@oracle.com> References: <6900aa48-2eb5-d93e-f4ab-9c9d216ed99f@oracle.com> Message-ID: Sounds reasonable. Then how about the claims on performance improvement, especially for maps that have to create entry objects on entry set iteration? In my few jmh benchmarks run, it seems adding from identity hash map at least is sped up, while most other maps have no significant difference. On Fri, Mar 4, 2022 at 6:58 PM Stuart Marks wrote: > Hi, I have to say I'm pretty skeptical of this change overall. > > It sounds like the main issue is iterating over the entrySet of a map that > might be > modified concurrently. The bug report says > > > for concurrent maps, regular iteration of entrySet may fail > spontaneously > > This isn't true for ConcurrentHashMap or ConcurrentSkipListMap, which have > weakly > consistent iterators that won't error out. It *is* true for > synchronizedMap, which > can throw ConcurrentModificationException if the map is modified during > iteration. I > guess that's mostly what you're referring to. > > The problem with synchronizedMap (and the other synchronized wrappers) is > that they > require external synchronization around iteration, and it's pretty much > impossible > to cover all the cases where iteration occurs. It's used everywhere > outside the JDK. > Even within the JDK, it appears quite frequently and is hard to avoid. For > example, > consider > > collection.addAll(synchronizedMap.keySet()) > > AbstractCollection::addAll iterates its argument, and this is inherited in > a bunch > of places. > > The root of the problem is that the synchronized wrappers support > concurrent > updating only in a very narrow range of use cases. If people have trouble > with > concurrent map updating, they need to use a real concurrent data > structure, or they > need to put everything inside their own class and have it do locking > around > higher-level operations. Replacing a few entrySet iteration cases with > Map::forEach > doesn't help anything. > > s'marks > > > > On 2/22/22 3:09 PM, - wrote: > > Hello, > > In the patch for 8281631 < > https://bugs.openjdk.java.net/browse/JDK-8281631>, > > xenoamess intentionally avoided > > > repeatedly > > calling Map::size, for it may not be constant-timed due to being > > concurrent. This alerted me that the for loops on Map::entrySet may be > > similarly not thread-safe. > > > > I believe that we should migrate for loop on Map::entrySet to > Map::forEach > > calls; concurrent map callees usually have dedicated logic > > < > https://github.com/openjdk/jdk/blob/2557ef8a02fe19784bd5e605b11d6bd574cde2c2/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java#L119 > > > > to mitigate such thread-safety issues. Synchronized map > > < > https://github.com/openjdk/jdk/blob/2557ef8a02fe19784bd5e605b11d6bd574cde2c2/src/java.base/share/classes/java/util/Collections.java#L2735 > > > > callees are benefitted too. > > > > Another lesser benefit is reduced object allocation for iteration. While > > the most popular implementations (HashMap, LinkedHashMap, WeakHashMap, > > TreeMap) don't need to allocate entries for iteration, many other > (EnumMap, > > IdentityHashMap, concurrent maps) do, and iterating those maps with > forEach > > is less costly. (Note that 8170826 > > takes care of > > implementing proper forEach in EnumMap) > > > > A JBS issue has already been submitted at > > https://bugs.openjdk.java.net/browse/JDK-8282178, and I have prepared a > > patch. This patch modifies the putAll implementations of a few JDK maps > to > > let the callee feed entries through Map::forEach to be put into the maps. > > Two places of Map::entrySet calls in Collectors has also been updated. > > > > For most other existing usages in the JDK, I don't think they will > benefit > > from such a migration: They mostly iterate on the entryset of the popular > > implementations that already host entries and are single-threaded, and I > > don't think it's in our best interest to touch those use cases. > > > > So, here are my questions: > > 1. Is such a concept of replacing Map::entrySet calls with Map::forEach > > calls reasonable, or is there any fundamental flaw? > > If the concept sounds good, I will submit a patch, so we can answer > > 2. Is the changes implemented correct for this concept, i.e. targeting > code > > where users supply callee maps? > > > > Best regards > > > From dholmes at openjdk.java.net Sat Mar 5 05:32:05 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 5 Mar 2022 05:32:05 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 21:54:57 GMT, Zhengyu Gu wrote: > The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code. That's to allow for general use by C or C++ source files. But you are only needing this in a C source file so you would only need the C variant of the calling syntax. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From dholmes at openjdk.java.net Sat Mar 5 05:52:04 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Sat, 5 Mar 2022 05:52:04 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: <2NJw-71OOOvNs9519H__uYdXQnJm23L-Ez4jKoAuKrk=.c277d644-fd63-442e-99a1-6d3d66cb3405@github.com> On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo I eyeballed the diff file and all seems okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7268 From jwaters at openjdk.java.net Sat Mar 5 06:52:13 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Sat, 5 Mar 2022 06:52:13 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo Nice, good work matteo Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Sat Mar 5 07:22:03 2022 From: duke at openjdk.java.net (Jan =?UTF-8?B?U2NobMO2w59pbg==?=) Date: Sat, 5 Mar 2022 07:22:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo This PR changes a comment in javax/swing/RepaintManager.java. This commented out code should be removed altogether in another PR? Because its an System.out.println and because its commented out code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From luhenry at openjdk.java.net Sat Mar 5 09:13:01 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Sat, 5 Mar 2022 09:13:01 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:14:34 GMT, Claes Redestad wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > My only comment is that I'd like to see some benchmark verifying also the UTF-16 code path. It should see a similar speed-up, but adding plenty of calls might mess up compilation and inlining. @cl4es I've updated the description with the results. StringUTF16 isn't adversely impacted by additional method calls. @merykitty The way to use an accumulator is to do it like https://richardstartin.github.io/posts/vectorised-polynomial-hash-codes. I'll implement the `hashCodeVectorAPINoDependencies` algorithm as an intrinsic next and check the performance. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From forax at univ-mlv.fr Sat Mar 5 10:58:11 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Sat, 5 Mar 2022 11:58:11 +0100 (CET) Subject: Replace simple iterations of Map.entrySet with Map.forEach calls In-Reply-To: <6900aa48-2eb5-d93e-f4ab-9c9d216ed99f@oracle.com> References: <6900aa48-2eb5-d93e-f4ab-9c9d216ed99f@oracle.com> Message-ID: <2111724599.11738065.1646477891613.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Stuart Marks" > To: "-" , "core-libs-dev" > Sent: Saturday, March 5, 2022 1:58:30 AM > Subject: Re: Replace simple iterations of Map.entrySet with Map.forEach calls > Hi, I have to say I'm pretty skeptical of this change overall. > > It sounds like the main issue is iterating over the entrySet of a map that might > be > modified concurrently. The bug report says > > > for concurrent maps, regular iteration of entrySet may fail spontaneously > > This isn't true for ConcurrentHashMap or ConcurrentSkipListMap, which have > weakly > consistent iterators that won't error out. It *is* true for synchronizedMap, > which > can throw ConcurrentModificationException if the map is modified during > iteration. I > guess that's mostly what you're referring to. > > The problem with synchronizedMap (and the other synchronized wrappers) is that > they > require external synchronization around iteration, and it's pretty much > impossible > to cover all the cases where iteration occurs. It's used everywhere outside the > JDK. > Even within the JDK, it appears quite frequently and is hard to avoid. For > example, > consider > > collection.addAll(synchronizedMap.keySet()) > > AbstractCollection::addAll iterates its argument, and this is inherited in a > bunch > of places. > > The root of the problem is that the synchronized wrappers support concurrent > updating only in a very narrow range of use cases. If people have trouble with > concurrent map updating, they need to use a real concurrent data structure, or > they > need to put everything inside their own class and have it do locking around > higher-level operations. Replacing a few entrySet iteration cases with > Map::forEach > doesn't help anything. Hi DrDeprecator, i wonder if we should not deprecate the method synchronized*, usually they cause more harm than good for the reason you explain. > > s'marks R?mi > > > > On 2/22/22 3:09 PM, - wrote: >> Hello, >> In the patch for 8281631 , >> xenoamess intentionally avoided >> repeatedly >> calling Map::size, for it may not be constant-timed due to being >> concurrent. This alerted me that the for loops on Map::entrySet may be >> similarly not thread-safe. >> >> I believe that we should migrate for loop on Map::entrySet to Map::forEach >> calls; concurrent map callees usually have dedicated logic >> >> to mitigate such thread-safety issues. Synchronized map >> >> callees are benefitted too. >> >> Another lesser benefit is reduced object allocation for iteration. While >> the most popular implementations (HashMap, LinkedHashMap, WeakHashMap, >> TreeMap) don't need to allocate entries for iteration, many other (EnumMap, >> IdentityHashMap, concurrent maps) do, and iterating those maps with forEach >> is less costly. (Note that 8170826 >> takes care of >> implementing proper forEach in EnumMap) >> >> A JBS issue has already been submitted at >> https://bugs.openjdk.java.net/browse/JDK-8282178, and I have prepared a >> patch. This patch modifies the putAll implementations of a few JDK maps to >> let the callee feed entries through Map::forEach to be put into the maps. >> Two places of Map::entrySet calls in Collectors has also been updated. >> >> For most other existing usages in the JDK, I don't think they will benefit >> from such a migration: They mostly iterate on the entryset of the popular >> implementations that already host entries and are single-threaded, and I >> don't think it's in our best interest to touch those use cases. >> >> So, here are my questions: >> 1. Is such a concept of replacing Map::entrySet calls with Map::forEach >> calls reasonable, or is there any fundamental flaw? >> If the concept sounds good, I will submit a patch, so we can answer >> 2. Is the changes implemented correct for this concept, i.e. targeting code >> where users supply callee maps? >> >> Best regards From duke at openjdk.java.net Sat Mar 5 13:14:20 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sat, 5 Mar 2022 13:14:20 GMT Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure Message-ID: `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from. ------------- Commit messages: - 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure Changes: https://git.openjdk.java.net/jdk/pull/7714/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282701 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7714.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7714/head:pull/7714 PR: https://git.openjdk.java.net/jdk/pull/7714 From duke at openjdk.java.net Sat Mar 5 13:31:08 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 5 Mar 2022 13:31:08 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v16] In-Reply-To: References: Message-ID: On Tue, 1 Mar 2022 02:11:26 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy 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 24 additional commits since the last revision: > > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - Add test for location disjointness > - Minor cleanup. > - ... and 14 more: https://git.openjdk.java.net/jdk/compare/dd292402...e63fb13e src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 44: > 42: * not have an access flag, such as {@code sealed} (JVMS > 43: * {@jvms 4.7.31}) and some access flags have no corresponding > 44: * modifier, such as {@linkplain SYNTHETIC synthetic}. Wrong?indentation: Suggestion: * modifier, such as {@linkplain SYNTHETIC synthetic}. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From jpai at openjdk.java.net Sat Mar 5 14:23:59 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sat, 5 Mar 2022 14:23:59 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Too many 'the' src/java.base/share/classes/java/util/Formatter.java line 2012: > 2010: public final class Formatter implements Closeable, Flushable { > 2011: // Caching DecimalFormatSymbols > 2012: static DecimalFormatSymbols DFS = null; Hello Jim, The javadoc of `Formatter` states: > > Formatters are not necessarily safe for multithreaded access. Thread safety is optional and is the responsibility of users of methods in this class. > So I would think that user applications would typically be synchronizing on the instance of a `Formatter` for any multi-threaded use of a formatter instance. If I'm reading this changed code correctly, it's now possible that 2 separate instances of a `Formatter` being concurrently accessed (i.e. in different threads) will now try and update/use this cached class level `static` state `DFS`. That would thus require some kind of thread safety semantics to be implemented for this new `getDecimalFormatSymbols(Locale)` method, isn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From ecki at zusammenkunft.net Sat Mar 5 16:21:26 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 5 Mar 2022 16:21:26 +0000 Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure In-Reply-To: References: Message-ID: Should probably explain why it removes the private modifier? Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von ?????? ??????? Gesendet: Saturday, March 5, 2022 2:14:20 PM An: core-libs-dev at openjdk.java.net Betreff: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure `Class.getInterfaces(false)` does not clone underlying array and can be used in cases when the returned array is only read from. ------------- Commit messages: - 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure Changes: https://git.openjdk.java.net/jdk/pull/7714/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7714&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282701 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7714.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7714/head:pull/7714 PR: https://git.openjdk.java.net/jdk/pull/7714 From liangchenblue at gmail.com Sat Mar 5 16:28:45 2022 From: liangchenblue at gmail.com (-) Date: Sat, 5 Mar 2022 10:28:45 -0600 Subject: RFR: 8282701: Use Class.getInterfaces(false) where possible to reduce allocation pressure In-Reply-To: References: Message-ID: This method is now called in java.lang.ClassLoader, which can only call package-private java.lang.Class methods. This is a safe change as this won't expose the raw array to any untrusted code. On Sat, Mar 5, 2022 at 10:22 AM Bernd Eckenfels wrote: > Should probably explain why it removes the private modifier? > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ________________________________ > Von: core-libs-dev im Auftrag von > ?????? ??????? > Gesendet: Saturday, March 5, 2022 2:14:20 PM > An: core-libs-dev at openjdk.java.net > Betreff: RFR: 8282701: Use Class.getInterfaces(false) where possible to > reduce allocation pressure > > `Class.getInterfaces(false)` does not clone underlying array and can be > used in cases when the returned array is only read from. > > ------------- > > Commit messages: > - 8282701: Use Class.getInterfaces(false) where possible to reduce > allocation pressure > > Changes: https://git.openjdk.java.net/jdk/pull/7714/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7714&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8282701 > Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod > Patch: https://git.openjdk.java.net/jdk/pull/7714.diff > Fetch: git fetch https://git.openjdk.java.net/jdk > pull/7714/head:pull/7714 > > PR: https://git.openjdk.java.net/jdk/pull/7714 > From lancea at openjdk.java.net Sat Mar 5 16:51:57 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 5 Mar 2022 16:51:57 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3] In-Reply-To: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> References: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> Message-ID: On Sat, 5 Mar 2022 03:29:44 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. >> >> Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. >> >> Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From aturbanov at openjdk.java.net Sat Mar 5 17:39:05 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sat, 5 Mar 2022 17:39:05 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3] In-Reply-To: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> References: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> Message-ID: On Sat, 5 Mar 2022 03:29:44 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. >> >> Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. >> >> Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 > > 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/io/InvalidObjectException.java line 62: > 60: * @since 19 > 61: */ > 62: public InvalidObjectException(String reason, Throwable cause) { strange double space after `public` ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From duke at openjdk.java.net Sat Mar 5 18:17:59 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 5 Mar 2022 18:17:59 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v26] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <6CiuVUOPH27TauEgiT60T3s-xEIjt9y7NOENkyhNlPc=.a8d631a6-9a23-4538-8d0b-f86fcb171370@github.com> > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with three additional commits since the last revision: - refactor tests - refactor tests - refactor WhiteBoxResizeTest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/261ae627..a4ca31d2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=25 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=24-25 Stats: 871 lines in 7 files changed: 534 ins; 337 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sat Mar 5 19:06:03 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 5 Mar 2022 19:06:03 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refactor tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/a4ca31d2..49aeef20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=26 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=25-26 Stats: 223 lines in 2 files changed: 0 ins; 0 del; 223 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sat Mar 5 19:32:08 2022 From: duke at openjdk.java.net (liach) Date: Sat, 5 Mar 2022 19:32:08 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Sat, 5 Mar 2022 19:06:03 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refactor tests test/jdk/java/util/HashMap/WhiteBoxHashMapTestUtil.java line 46: > 44: Class mClass = HashMap.class; > 45: String nodeClassName = mClass.getName() + "$Node"; > 46: Class nodeArrayClass = Class.forName("[L" + nodeClassName + ";"); this looks wrong, and the class instance is used nowhere later. should probably be removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sat Mar 5 19:39:41 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sat, 5 Mar 2022 19:39:41 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v13] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with three additional commits since the last revision: - Change variable name - Do not allow serialization - Changes proposed by Stuart Marks, ExE Boss and liach ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/0e48edf6..5c5bd873 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=11-12 Stats: 43 lines in 1 file changed: 23 ins; 2 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sat Mar 5 19:48:47 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sat, 5 Mar 2022 19:48:47 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v14] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: Fix wrong whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/5c5bd873..87236da7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=12-13 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sat Mar 5 19:50:07 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 5 Mar 2022 19:50:07 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Sat, 5 Mar 2022 19:29:17 GMT, liach wrote: > this looks wrong, and the class instance is used nowhere later. should probably be removed. @liach already removed in the latest commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sat Mar 5 19:50:13 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sat, 5 Mar 2022 19:50:13 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v13] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 19:39:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with three additional commits since the last revision: > > - Change variable name > - Do not allow serialization > - Changes proposed by Stuart Marks, ExE Boss and liach Applied the suggestions made, all tests passed ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From darcy at openjdk.java.net Sat Mar 5 19:54:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 5 Mar 2022 19:54:44 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: > This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. > > Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). > > The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. > > With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. > > This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. > > The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. Joe Darcy 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 26 additional commits since the last revision: - Respond to review feedback. - Merge branch 'master' into JDK-8266670 - Make workding changes suggested in review feedback. - Merge branch 'master' into JDK-8266670 - Typo fix; add implSpec to Executable. - Appease jcheck. - Fix some bugs found by inspection, docs cleanup. - Merge branch 'master' into JDK-8266670 - Initial support for accessFlags methods - Add mask to access flag functionality. - ... and 16 more: https://git.openjdk.java.net/jdk/compare/7c47831d...14980605 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/e63fb13e..14980605 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=15-16 Stats: 11263 lines in 322 files changed: 7362 ins; 2509 del; 1392 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445 From liangchenblue at gmail.com Sat Mar 5 20:45:20 2022 From: liangchenblue at gmail.com (-) Date: Sat, 5 Mar 2022 14:45:20 -0600 Subject: Replace simple iterations of Map.entrySet with Map.forEach calls In-Reply-To: References: <6900aa48-2eb5-d93e-f4ab-9c9d216ed99f@oracle.com> Message-ID: I've made a benchmark with visualized results on putting a map of a few elements into a hash map via putAll, put in forEach, put in for entrySet loop, and put in for keySet loop with Map.get calls on JDK 17. Aside from regular "putAll", which is the fastest because hash map preemptively expanded the table and has custom optimizations, the rest of the result shows that forEach is largely the same for maps that already store contents as Entry instances and significantly faster for IdentityHashMap, the only one that does not store contents as Entry objects. Hence, I believe the performance benefit from the replacement is real. stuart, mind evaluate my claim? On Fri, Mar 4, 2022 at 10:43 PM - wrote: > Sounds reasonable. Then how about the claims on performance improvement, > especially for maps that have to create entry objects on entry set > iteration? In my few jmh benchmarks run, it seems adding from identity hash > map at least is sped up, while most other maps have no significant > difference. > > On Fri, Mar 4, 2022 at 6:58 PM Stuart Marks > wrote: > >> Hi, I have to say I'm pretty skeptical of this change overall. >> >> It sounds like the main issue is iterating over the entrySet of a map >> that might be >> modified concurrently. The bug report says >> >> > for concurrent maps, regular iteration of entrySet may fail >> spontaneously >> >> This isn't true for ConcurrentHashMap or ConcurrentSkipListMap, which >> have weakly >> consistent iterators that won't error out. It *is* true for >> synchronizedMap, which >> can throw ConcurrentModificationException if the map is modified during >> iteration. I >> guess that's mostly what you're referring to. >> >> The problem with synchronizedMap (and the other synchronized wrappers) is >> that they >> require external synchronization around iteration, and it's pretty much >> impossible >> to cover all the cases where iteration occurs. It's used everywhere >> outside the JDK. >> Even within the JDK, it appears quite frequently and is hard to avoid. >> For example, >> consider >> >> collection.addAll(synchronizedMap.keySet()) >> >> AbstractCollection::addAll iterates its argument, and this is inherited >> in a bunch >> of places. >> >> The root of the problem is that the synchronized wrappers support >> concurrent >> updating only in a very narrow range of use cases. If people have trouble >> with >> concurrent map updating, they need to use a real concurrent data >> structure, or they >> need to put everything inside their own class and have it do locking >> around >> higher-level operations. Replacing a few entrySet iteration cases with >> Map::forEach >> doesn't help anything. >> >> s'marks >> >> >> >> On 2/22/22 3:09 PM, - wrote: >> > Hello, >> > In the patch for 8281631 < >> https://bugs.openjdk.java.net/browse/JDK-8281631>, >> > xenoamess intentionally avoided >> > >> repeatedly >> > calling Map::size, for it may not be constant-timed due to being >> > concurrent. This alerted me that the for loops on Map::entrySet may be >> > similarly not thread-safe. >> > >> > I believe that we should migrate for loop on Map::entrySet to >> Map::forEach >> > calls; concurrent map callees usually have dedicated logic >> > < >> https://github.com/openjdk/jdk/blob/2557ef8a02fe19784bd5e605b11d6bd574cde2c2/src/java.base/share/classes/java/util/concurrent/ConcurrentMap.java#L119 >> > >> > to mitigate such thread-safety issues. Synchronized map >> > < >> https://github.com/openjdk/jdk/blob/2557ef8a02fe19784bd5e605b11d6bd574cde2c2/src/java.base/share/classes/java/util/Collections.java#L2735 >> > >> > callees are benefitted too. >> > >> > Another lesser benefit is reduced object allocation for iteration. While >> > the most popular implementations (HashMap, LinkedHashMap, WeakHashMap, >> > TreeMap) don't need to allocate entries for iteration, many other >> (EnumMap, >> > IdentityHashMap, concurrent maps) do, and iterating those maps with >> forEach >> > is less costly. (Note that 8170826 >> > takes care of >> > implementing proper forEach in EnumMap) >> > >> > A JBS issue has already been submitted at >> > https://bugs.openjdk.java.net/browse/JDK-8282178, and I have prepared a >> > patch. This patch modifies the putAll implementations of a few JDK maps >> to >> > let the callee feed entries through Map::forEach to be put into the >> maps. >> > Two places of Map::entrySet calls in Collectors has also been updated. >> > >> > For most other existing usages in the JDK, I don't think they will >> benefit >> > from such a migration: They mostly iterate on the entryset of the >> popular >> > implementations that already host entries and are single-threaded, and I >> > don't think it's in our best interest to touch those use cases. >> > >> > So, here are my questions: >> > 1. Is such a concept of replacing Map::entrySet calls with Map::forEach >> > calls reasonable, or is there any fundamental flaw? >> > If the concept sounds good, I will submit a patch, so we can answer >> > 2. Is the changes implemented correct for this concept, i.e. targeting >> code >> > where users supply callee maps? >> > >> > Best regards >> > >> > From duke at openjdk.java.net Sat Mar 5 21:33:01 2022 From: duke at openjdk.java.net (Marcono1234) Date: Sat, 5 Mar 2022 21:33:01 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v14] In-Reply-To: References: Message-ID: <6RH4kWy7ti-hSyZnp9r14Iygat5p-dHCLDbuzueI_vI=.39fd470b-c893-4e90-906a-2ccc5557e6bc@github.com> On Sat, 5 Mar 2022 19:48:47 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Fix wrong whitespace Would it make sense to override `next(int)` to always throw an exception? Even though it should not be possible for a user to call the method on the wrapper, it might be better to be on the safe side; for example in case a new `Random` method which depends on `next(int)` is added in the future (even though this is unlikely). src/java.base/share/classes/java/util/Random.java line 306: > 304: > 305: /** > 306: * Returns an instance of {@code Random} that delegates method calls to the{@link RandomGenerator} Suggestion: * Returns an instance of {@code Random} that delegates method calls to the {@link RandomGenerator} (please apply this change manually and don't click the 'commit' button, to not include me as author in this PR) ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sun Mar 6 01:39:02 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sun, 6 Mar 2022 01:39:02 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v15] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: Update javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/87236da7..d6376b29 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From aph at openjdk.java.net Sun Mar 6 09:35:08 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Sun, 6 Mar 2022 09:35:08 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v11] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Removing +LogCompilation flag. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4157: > 4155: ExternalAddress mxcsr_std(StubRoutines::x86::addr_mxcsr_std()); > 4156: ldmxcsr(new_mxcsr); > 4157: movl(scratch, 1056964608); What is 1056964608 ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Mar 6 11:47:01 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 6 Mar 2022 11:47:01 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v11] In-Reply-To: References: Message-ID: <78mhhL5dqkY5LQY2U2i_DF6MvgYBQiDIrieGcBOCGAA=.ec16edf8-24d2-4658-92ff-5d20f03e7620@github.com> On Sun, 6 Mar 2022 09:31:27 GMT, Andrew Haley wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Removing +LogCompilation flag. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4157: > >> 4155: ExternalAddress mxcsr_std(StubRoutines::x86::addr_mxcsr_std()); >> 4156: ldmxcsr(new_mxcsr); >> 4157: movl(scratch, 1056964608); > > What is 1056964608 ? Raw bits corresponding to floating point value 0.5f. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From aturbanov at openjdk.java.net Sun Mar 6 13:36:04 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sun, 6 Mar 2022 13:36:04 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3] In-Reply-To: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> References: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> Message-ID: On Sat, 5 Mar 2022 03:29:44 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. >> >> Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. >> >> Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 > > 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/io/InvalidObjectException.java line 48: > 46: * @see ObjectInputValidation > 47: */ > 48: public InvalidObjectException(String reason) { Suggestion: public InvalidObjectException(String reason) { ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From aph at openjdk.java.net Sun Mar 6 13:52:00 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Sun, 6 Mar 2022 13:52:00 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v11] In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 02:44:41 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Removing +LogCompilation flag. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4157: > 4155: ExternalAddress mxcsr_std(StubRoutines::x86::addr_mxcsr_std()); > 4156: ldmxcsr(new_mxcsr); > 4157: movl(scratch, 1056964608); Suggestion: movl(scratch, 1056964608); // Raw bits corresponding to floating point value 0.5f. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jpai at openjdk.java.net Sun Mar 6 15:04:06 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 6 Mar 2022 15:04:06 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 14:20:40 GMT, Jaikiran Pai wrote: > will now try and update/use this cached class level static state DFS. That would thus require some kind of thread safety semantics to be implemented for this new getDecimalFormatSymbols(Locale) method, isn't it? A bit more closer look at the code and it appears to me that the use of : DecimalFormatSymbols dfs = DFS; and then working off that local variable prevents any kind of race issues that might be caused due to multi-thread access. Of course it still means that multiple threads might still go ahead and do a: dfs = DecimalFormatSymbols.getInstance(locale); on first access (when `DFS` is null) but that in itself should be harmless. If this is intentional (which I suspect it is), should some comment be added in this method explaining this multi-thread access detail? ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From tanksherman27 at gmail.com Sun Mar 6 16:46:15 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Mon, 7 Mar 2022 00:46:15 +0800 Subject: New methods in PriorityQueue In-Reply-To: References: Message-ID: Hi Stuart and Roger, thanks for your patience, Attached below is the response from the author: @TheShermanTanker Cool. Thank you very much for relaying the messages from the list here! All right, I understand the concerns. My first thought about how to address them would be a functional API. Something like this: /** * Applies the re-prioritization function {@code mutator} * to the item x and relocates it to its proper place in the queue. * * If the item's priority is raised by the {@code mutator}, * it will potentially be moved closer to the start. * * If the item's priority is lowered by the {@code mutator}, * it will potentially be moved closer to the end. * * If the {@code mutator} does not change the item's priority * it will not be moved. * * The call has no effect if the item cannot be found in the queue * by referential equality. * * @param x the item to sift up * @param mutator a function to be applied to x to change its priority */ public void rePrioritize(E x, Consumer mutator) { ... } As it is already documented on the class that it is not thread-save, this should get past those concerns then, shouldn't it? If yes, the next thing to do for me, would be to get creative and implement this in a manner that is equally performant than the original suggestion (e.g. much faster than remove(), mutate(), add()). I am sure that this could be done. If an item's priority was an int or long, it would be trivial. But since items are only comparable, the implementation would be, well, non-trivial. But before I start wrecking my brain about the implementation, let me take a break here and re-focus. As said, I understand the concerns that have been raised against the initial suggestion (e.g. this PR). And even though an attempt at finding a working solution has not been discouraged so far, at the moment I don't a big enough upside of having these methods available in the API as well, that would justify the investment for me. When making this PR, my motivation was also (1.) that I was curious about the reasons why they are missing and (2.) about the JDK PR process in general. And this curiosity has been satisfied. 1. I was not really aware about the requirements of the API user to maintain the "invariants of the PriorityQueue" while using it. (Btw. I have not found any explicitly documentation of the concept of "[collection] invariants" or "[t]he general rule for collections that use [...] comparison methods" on the class or the add() method. Does anybody think it would make sense to fix that or did I just not see it, maybe elsewhere?) 2. I am convinced that the PR approval process works well and and will recommend anyone that has a real / legitimate need to have a change merged, to have the discussion. Thank you very much to Roger and Stuart as well as to @TheShermanTanker! best regards, Julian On Fri, Mar 4, 2022 at 3:08 PM Julian Waters wrote: > Hi all, > > I apologize for the confusion, it seems like something went awry on my end > with the mailing lists, since there are apparently now 2 copies of the same > thread with different names. I guess I'll just go with this one, since the > technical discussion is going on here. > > To clarify, I wasn't the one who created the PR, I'll relay the feedback > to the author since I'm not really in the position to give any feedback > myself, given my inexperience with this area of the JDK. > > Thank you Stuart and Roger for the replies, have a great day! :) > > best regards, > Julian > > > > On Fri, Mar 4, 2022 at 1:37 PM Stuart Marks > wrote: > >> I agree with Roger. Let me amplify this. >> >> The general rule for collections that use hashes and comparison methods >> (such as >> HashMap and TreeMap, as well as PriorityQueue) is that one mustn't mutate >> any >> element that resides in such a collection in any way that changes the >> results of >> hashCode, equals, or the comparison method. It's a bad precedent to add >> APIs that >> seem to support such mutation. As Roger said, the supported way of doing >> this is to >> remove, mutate, and then reinsert. >> >> It seems like it might be safe to mutate an element, only temporarily >> violating the >> PQ's invariants until the mutated element is sifted into the correct >> position. >> However, even a "temporary" violation is exceedingly dangerous. If some >> other >> modification is made to the PQ while it's in this state, it could end up >> permanently >> corrupting the PQ. >> >> Managing such a situation would need to be handled exceedingly carefully. >> As such, >> this seems like a highly specialized use case, thus the proposal isn't >> suitable as a >> general-purpose API. >> >> s'marks >> >> >> On 3/3/22 10:18 AM, Roger Riggs wrote: >> > Hi Julian, >> > >> > Modifying the priorities of elements in the PriorityQueue violates the >> > invariants of the PriorityQueue established at insertion and maintained >> > at removal by the Comparator. >> > >> > To maintain the invariant the element should be removed, its priority >> modified, >> > and re-inserted. >> > >> > An API to manually manipulate the order is inconsistent with the design >> of >> > PriorityQueue. >> > >> > Regards, Roger >> > >> > >> > On 3/3/22 6:59 AM, Jules W. wrote: >> >> Hi all, >> >> >> >> A new PR that adds methods to PriorityQueue was created some time ago >> at >> >> https://github.com/openjdk/jdk/pull/6938 but has no corresponding >> issue. As >> >> I'm not too familiar with this part of the JDK I'm querying this >> mailing >> >> list for anyone to properly review the PR before I create an issue for >> it >> >> in the JBS >> >> >> >> best regards, >> >> Julian Waters >> > >> > From scolebourne at openjdk.java.net Sun Mar 6 17:20:03 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Sun, 6 Mar 2022 17:20:03 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v3] In-Reply-To: References: Message-ID: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com> On Fri, 4 Mar 2022 23:05:56 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Addresses review comments src/java.base/share/classes/java/time/chrono/Chronology.java line 794: > 792: * @since 19 > 793: */ > 794: default boolean supportsIsoFields() { I'm not a fan of this name, as it is inconsistent with the rest of JSR310 API, which uses an `is` prefix for booleans. I suggested `isIsoLike` because the key question is whether the chronology is "like" ISO. I would also be OK with `isBasedOnIso`, `isDerivedFromIso`, `isIsoBased` or something similar. Another risk here is limiting the method to refer only to `IsoFields`. While that is the use case here, it isn't the case that the only fields that might be affected are in `IsoFields`. Third parties may have their own fields that are suitable for use with an ISO-like chronology. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From darcy at openjdk.java.net Sun Mar 6 17:28:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 6 Mar 2022 17:28:44 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3] In-Reply-To: References: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> Message-ID: On Sat, 5 Mar 2022 17:36:20 GMT, Andrey Turbanov 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/io/InvalidObjectException.java line 62: > >> 60: * @since 19 >> 61: */ >> 62: public InvalidObjectException(String reason, Throwable cause) { > > strange double space after `public` Fixed in subsequent push; thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From darcy at openjdk.java.net Sun Mar 6 17:28:42 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 6 Mar 2022 17:28:42 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v4] In-Reply-To: References: Message-ID: > Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. > > Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. > > Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Fix whitespace. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7711/files - new: https://git.openjdk.java.net/jdk/pull/7711/files/2b2219eb..80f97dcc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7711/head:pull/7711 PR: https://git.openjdk.java.net/jdk/pull/7711 From aturbanov at openjdk.java.net Sun Mar 6 17:35:05 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sun, 6 Mar 2022 17:35:05 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v3] In-Reply-To: References: <35sW6GX2FMeXZHq8WsSaYYyVeEvlrRF_zU882_nR7C0=.bb627451-abd4-45f9-afe0-ea33d56e6aae@github.com> Message-ID: On Sun, 6 Mar 2022 17:24:23 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/io/InvalidObjectException.java line 62: >> >>> 60: * @since 19 >>> 61: */ >>> 62: public InvalidObjectException(String reason, Throwable cause) { >> >> strange double space after `public` > > Fixed in subsequent push; thanks. Hm. I see it still there) ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From lancea at openjdk.java.net Sun Mar 6 18:21:57 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 6 Mar 2022 18:21:57 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v4] In-Reply-To: References: Message-ID: On Sun, 6 Mar 2022 17:28:42 GMT, Joe Darcy wrote: >> Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. >> >> Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. >> >> Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. >> >> Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespace. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From naoto at openjdk.java.net Mon Mar 7 00:37:07 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Mar 2022 00:37:07 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: <9g47OUC6AaV2e1baWOmanc9ISVbA5hZKq2IdjYWw36s=.3d31f016-047e-4f60-a5e0-0113783bda43@github.com> On Sun, 6 Mar 2022 15:00:47 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/Formatter.java line 2012: >> >>> 2010: public final class Formatter implements Closeable, Flushable { >>> 2011: // Caching DecimalFormatSymbols >>> 2012: static DecimalFormatSymbols DFS = null; >> >> Hello Jim, >> The javadoc of `Formatter` states: >> >>> >>> Formatters are not necessarily safe for multithreaded access. Thread safety is optional and is the responsibility of users of methods in this class. >>> >> >> So I would think that user applications would typically be synchronizing on the instance of a `Formatter` for any multi-threaded use of a formatter instance. >> >> If I'm reading this changed code correctly, even if user applications have properly synchronized on a `Formatter` instance, it's now possible that 2 separate instances of a `Formatter` being concurrently accessed (i.e. in different threads) will now try and update/use this cached class level `static` state `DFS`. That would thus require some kind of thread safety semantics to be implemented for this new `getDecimalFormatSymbols(Locale)` method, isn't it? > >> will now try and update/use this cached class level static state DFS. That would thus require some kind of thread safety semantics to be implemented for this new getDecimalFormatSymbols(Locale) method, isn't it? > > A bit more closer look at the code and it appears to me that the use of : > > DecimalFormatSymbols dfs = DFS; > > and then working off that local variable prevents any kind of race issues that might be caused due to multi-thread access. Of course it still means that multiple threads might still go ahead and do a: > > dfs = DecimalFormatSymbols.getInstance(locale); > > on first access (when `DFS` is null) but that in itself should be harmless. > > If this is intentional (which I suspect it is), should some comment be added in this method explaining this multi-thread access detail? Initially, I thought of the same thing (not the `Formatter` but `DecimalFormatSymbols` itself, as it is also not thread safe), but I concluded it was OK, as there is no mutation going on. I agree with Jaikiran that some comments might help here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From duke at openjdk.java.net Mon Mar 7 00:59:22 2022 From: duke at openjdk.java.net (XenoAmess) Date: Mon, 7 Mar 2022 00:59:22 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v25] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <6ahMrE0wwqVNLFuAGAkN0i1JYPLh3LykTO5f0iHwRms=.face5bf5-2aa7-40af-8629-d2c5354dd560@github.com> Message-ID: On Fri, 4 Mar 2022 21:02:50 GMT, Stuart Marks wrote: >>> This actually tests three things: 1) table is lazily allocated, 2) default capacity is 16, and 3) using putAll to populate the map with 64 elements results in a table size of 128. This should really be broken into three separate test methods. Once they're separated, the lazy allocation test should only called for HashMap and LinkedHashMap but not WeakHashMap. >> >> @stuart-marks would you mind if I break WhiteBoxResizeTest class into several smaller Test classes, each focus on one of the test points you said? >> If we split it into several tests, it would be more clear than sqruash into one test class, and we can make it parameterilized tests. > >> would you mind if I break WhiteBoxResizeTest class into several smaller Test classes, each focus on one of the test points you said? > > Well, separate classes wouldn't be the approach that I'd take myself. However, I'm interested in you continuing to make progress on this, so if you'd prefer separate classes, then go ahead. However, I reserve the right to propose refactorings that merge things back into a single class. :-) @stuart-marks done. please find some time for review. thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From naoto at openjdk.java.net Mon Mar 7 01:31:06 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Mar 2022 01:31:06 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v3] In-Reply-To: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com> References: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com> Message-ID: On Sun, 6 Mar 2022 17:12:31 GMT, Stephen Colebourne wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Addresses review comments > > src/java.base/share/classes/java/time/chrono/Chronology.java line 794: > >> 792: * @since 19 >> 793: */ >> 794: default boolean supportsIsoFields() { > > I'm not a fan of this name, as it is inconsistent with the rest of JSR310 API, which uses an `is` prefix for booleans. I suggested `isIsoLike` because the key question is whether the chronology is "like" ISO. I would also be OK with `isBasedOnIso`, `isDerivedFromIso`, `isIsoBased` or something similar. Another risk here is limiting the method to refer only to `IsoFields`. While that is the use case here, it isn't the case that the only fields that might be affected are in `IsoFields`. Third parties may have their own fields that are suitable for use with an ISO-like chronology. OK, I propose `isIsoBased()` for the name, which I initially thought of. If there is no objection, I will modify the spec/impl. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From xgong at openjdk.java.net Mon Mar 7 01:31:04 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 7 Mar 2022 01:31:04 GMT Subject: RFR: 8282432: Optimize masked "test" Vector API with predicate feature [v2] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 17:40:13 GMT, Paul Sandoz wrote: > I guess the following: `mask.cast(IntVector.species(shape())` is more efficient than: `m.cast(vspecies().asIntegral()))` ? Yeah, that's one point. Another main reason is `m.cast(vspecies().asIntegral()))` cannot be handled well in the superclass due to the java generic issues. Thanks for the reiview @PaulSandoz ! ------------- PR: https://git.openjdk.java.net/jdk/pull/7654 From rriggs at openjdk.java.net Mon Mar 7 03:04:05 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Mar 2022 03:04:05 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v3] In-Reply-To: References: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com> Message-ID: On Mon, 7 Mar 2022 01:27:39 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/time/chrono/Chronology.java line 794: >> >>> 792: * @since 19 >>> 793: */ >>> 794: default boolean supportsIsoFields() { >> >> I'm not a fan of this name, as it is inconsistent with the rest of JSR310 API, which uses an `is` prefix for booleans. I suggested `isIsoLike` because the key question is whether the chronology is "like" ISO. I would also be OK with `isBasedOnIso`, `isDerivedFromIso`, `isIsoBased` or something similar. Another risk here is limiting the method to refer only to `IsoFields`. While that is the use case here, it isn't the case that the only fields that might be affected are in `IsoFields`. Third parties may have their own fields that are suitable for use with an ISO-like chronology. > > OK, I propose `isIsoBased()` for the name, which I initially thought of. If there is no objection, I will modify the spec/impl. Is `IsoBased` is fine with me. "isISOLike" is too vague. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From darcy at openjdk.java.net Mon Mar 7 04:35:33 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Mar 2022 04:35:33 GMT Subject: RFR: JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException [v5] In-Reply-To: References: Message-ID: <6sh1fPQa3QW-q_48gGd2FwuMjTf6ko3FWADT4pnZgpg=.2085e270-d678-4704-a4f8-39c54de7a869@github.com> > Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. > > Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. > > Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 Joe Darcy 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: - Add regression tests. - Merge branch 'master' into JDK-8282696 - Fix more whitespace. - Fix whitespace. - Respond to review feedback. - Retrofit another location. - JDK-8282696: Add constructors take a cause to InvalidObjectException and InvalidClassException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7711/files - new: https://git.openjdk.java.net/jdk/pull/7711/files/80f97dcc..2de370f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=03-04 Stats: 1346 lines in 43 files changed: 1187 ins; 49 del; 110 mod Patch: https://git.openjdk.java.net/jdk/pull/7711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7711/head:pull/7711 PR: https://git.openjdk.java.net/jdk/pull/7711 From zjx001202 at gmail.com Mon Mar 7 05:33:16 2022 From: zjx001202 at gmail.com (Glavo) Date: Mon, 7 Mar 2022 13:33:16 +0800 Subject: Wrong behavior of standard IO library when interacting with Samba (very serious) Message-ID: I am a Java application developer. I noticed that when my program runs on Windows in a samba shared folder (mounted as a drive, or accessed via a UNC path), the Java standard IO library has some unusual behavior. Note that these issues only occur when accessing a folder shared by *Samba*, but not for the folder shared via SMB by another Windows host. One of the bugs was reported years ago (JDK-8154915): `Files.isWritable` always returns false for files shared by samba. It's worth noting for this question that `File::canWrite()`'s behavior is normal. (So in my program I pass `!Files.isWritable(p) && p.toFile().canWrite()` to detect if it's shared by samba and give the user a warning) This problem keeps showing up on several of my devices, so it should be fine to reproduce. The reason it wasn't resolved seems to be that the OpenJDK maintainers didn't understand that it came up when interacting with Samba (not just SMB). In addition to this, there is another, more significant problem: After a series of IO operations, Java will recognize a normal folder as a regular file, not a folder. This vicious bug hinders the possibility of our program running on Samba shared folders, and I can't find a workaround to make the program work temporarily. I've spent many days catching this bug, it always appears on our program, but I'm currently unable to find a minimal reproducer that reproduces it stably. After this bug occurs, the folder affected by the bug will have the following properties: 1. It is only misidentified in the current JVM process, other processes are not affected. 2. This JVM process continues to recognize errors until the JVM is restarted. 3. For this folder, `Files.exists` will return false, but `File::exists()` will return true. 4. Although `Files.exists` thinks it does not exist, `Files.readAttributes` can still return the result normally. 5. In its BasicFileAttributes, `isRegularFile` is true and `isDirectory` is false. 6. For this folder, `File::isFile` returns true, and `File.isDirectory` returns false. 7. After this bug occurs, without exiting the JVM process, and opening the parent of this folder in the Windows Explorer, the JVM process correctly recognizes it as a folder again. We can always reproduce it in we open source third-party Minecraft launchers: https://github.com/huanghongxun/HMCL Reproducing it in HMCL is very simple, just put HMCL in a samba shared folder and start it, then install any version of Minecraft in it, and it will fail to install because of this bug. However, I can't extract a minimal reproducer from it that can reproduce it stably. I've observed that one of the possibilities for the bug is to use `Files.copy` to copy a file into this folder and fail because the file already exists. After this failed copy, the bug appeared on the parent folder of the target file. According to this, I provide a reproducer: https://github.com/Glavo/nio-samba-bug-report But strangely, it reproduces stably on a folder shared by my Ubuntu computer, but only occasionally reproduces it once in a folder shared by my TrueNAS SCALA NAS. This is a very vicious bug and I can't find a workaround to get around it, so I hope someone can work with me on it and fix it. I'll do what I can to help, such as a test environment. From sverre.moe at gmail.com Mon Mar 7 07:30:44 2022 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 7 Mar 2022 08:30:44 +0100 Subject: JDK-17: Wndows jpackage destination directory not writable In-Reply-To: <06cd2184-5567-76e5-dba3-eb7fd628582c@oracle.com> References: <6e1e209f-1919-c98a-0b86-0a6453ce5bba@oracle.com> <06cd2184-5567-76e5-dba3-eb7fd628582c@oracle.com> Message-ID: If anyone wants to try to reproduce this, here is the Dockerfile I used to create the Windows docker image # escape=` FROM mcr.microsoft.com/windows:1903 AS jdk17 # $ProgressPreference: https://github.com/PowerShell/PowerShell/issues/2138#issuecomment-251261324 SHELL [ "powershell", "-Command", "$ErrorActionPreference = 'Stop'; $ProgressPreference = 'SilentlyContinue';" ] ENV JAVA_HOME='C:\Program Files\Java\jdk-17' # Install OpenJDK 17 ADD https://api.adoptium.net/v3/installer/latest/17/ga/windows/x64/jdk/hotspot/normal/adoptium?project=jdk C:\Temp\openjdk17.msi RUN Start-Process -Wait -FilePath msiexec -ArgumentList /i, "C:\Temp\openjdk17.msi", "'ADDLOCAL=\"FeatureMain,FeatureEnvironment,FeatureJarFileRunWith,FeatureJavaHome\"'", "'INSTALLDIR=\"C:\Program Files\Java\jdk-17\"'", /quiet, /norestart -Verb RunAs # Set JAVA_HOME and Update PATH to Java 17 RUN $newPath = ('{0}\bin;{1}' -f $env:JAVA_HOME, $env:PATH); ` [Environment]::SetEnvironmentVariable('PATH', $newPath, [EnvironmentVariableTarget]::Machine); ` [Environment]::SetEnvironmentVariable('JAVA_HOME', ${JAVA_HOME}, [EnvironmentVariableTarget]::Machine); # Enable Windows Feature .NET Framework Runtime 3.5. Needed for installing Wix Toolset. RUN Set-Service -Name wuauserv -StartupType "Manual"; ` Enable-WindowsOptionalFeature -Online -FeatureName "NetFx3" -All; # Install Chocolatey RUN Set-ExecutionPolicy Bypass -Scope Process -Force; ` [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; ` Invoke-Expression ((New-Object System.Net.WebClient).DownloadString(' https://community.chocolatey.org/install.ps1')) # Install Windows 10 SDK. ENV SIGNTOOLPATH="C:\Program Files (x86)\Windows Kits\10\App Certification Kit" RUN choco feature enable -n allowGlobalConfirmation; ` choco install windows-sdk-10.1; ` $newPath = ('{0};{1}' -f $env:SIGNTOOLPATH, $env:PATH); ` [Environment]::SetEnvironmentVariable('PATH', $newPath, [EnvironmentVariableTarget]::Machine); # Install WiX Toolset. ENV WIXPATH="C:\Program Files (x86)\WiX Toolset v3.11" RUN choco feature enable -n allowGlobalConfirmation; ` choco install wixtoolset; ` $newPath = ('{0}\bin;{1}' -f $env:WIXPATH, $env:PATH); ` [Environment]::SetEnvironmentVariable('PATH', $newPath, [EnvironmentVariableTarget]::Machine); /Sverre fre. 18. feb. 2022 kl. 19:33 skrev Alexey Semenyuk < alexey.semenyuk at oracle.com>: > Hi Sverre, > > Interesting, I don't see changes in jpackage code related to the issue. In > particular jdk.jpackage.internal.IOUtils.writableOutputDir() function is > the same in JDK14, JDK17, and mainline. > > - Alexey > > On 2/18/2022 8:31 AM, Sverre Moe wrote: > > I executed our JDK11 docker image, which works fine with JDK11 and JDK14 > (for jpackage support). > Then I installed the JDK17 MSI package, changed JAVA_HOME and PATH. > Building our application now with JDK17 it still cannot write to the > "build/native" jpackage output directory. > > Leads me to conclude something has changed in jpackage between JDK14 and > JDK17. > I modified my gradle configuration, to use jpackage from JDK14 when > packaging my JDK17 built application. > It works using JDK14 jpackage to package our JDK17 application. > > Using the JDK17 jpackage directly in Windows works fine. It is only in the > Docker container that it does not work. > > /Sverre > > > > tir. 5. okt. 2021 kl. 11:55 skrev Sverre Moe : > > > I ran cacls after the failed jpackage. > > C:\temp\my-javafx-application>cacls build > C:\temp\my-javafx-application\build F > CREATOR OWNER:(OI)(CI)(IO)F > R > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)R > > C:\temp\my-javafx-application>cacls build\native > C:\temp\my-javafx-application\build\native F > CREATOR OWNER:(OI)(CI)(IO)F > R > CREATOR GROUP:(OI)(CI)(IO)R > Everyone:(OI)(CI)R > > > As cacls was deprecated it suggested to use icacls instead: > > C:\temp\my-javafx-application>icacls build > build S-1-5-21-406077803-2019195645-689573112-1003:(I)(F) > CREATOR OWNER:(I)(OI)(CI)(IO)(F) > S-1-5-21-406077803-2019195645-689573112-513:(I)(RX) > CREATOR GROUP:(I)(OI)(CI)(IO)(RX) > Everyone:(I)(OI)(CI)(RX) > > Successfully processed 1 files; Failed processing 0 files > > C:\temp\my-javafx-application>icacls build\native > build\native S-1-5-83-1-1537791174-1084404783-2478187907-2577323605:(I)(F) > CREATOR OWNER:(I)(OI)(CI)(IO)(F) > S-1-5-83-0:(I)(RX) > CREATOR GROUP:(I)(OI)(CI)(IO)(RX) > Everyone:(I)(OI)(CI)(RX) > > Successfully processed 1 files; Failed processing 0 files > > Running attrib on the workspace, and build dirs: > > C:\Temp\my-javafx-application>attrib > A C:\Temp\my-javafx-application\.description > A C:\Temp\my-javafx-application\.gitignore > A C:\Temp\my-javafx-application\build.gradle > A C:\Temp\my-javafx-application\gradle.properties > A C:\Temp\my-javafx-application\gradlew > A C:\Temp\my-javafx-application\gradlew.bat > A C:\Temp\my-javafx-application\Jenkinsfile > A C:\Temp\my-javafx-application\packager.gradle > A C:\Temp\my-javafx-application\README.adoc > A C:\Temp\my-javafx-application\settings.gradle > A C:\Temp\my-javafx-application\spotless.gradle > > C:\Temp\my-javafx-application>attrib build > C:\Temp\my-javafx-application\build > > C:\Temp\meos-dashboard>attrib build\native > C:\Temp\my-javafx-application\build\native > > /Sverre > > tir. 5. okt. 2021 kl. 10:41 skrev Alan Bateman : > > > On 05/10/2021 08:54, Sverre Moe wrote: > > With JDK 17, jpackage fails to write to the destination directory on > Windows. > > It worked fine with JDK 11 (with jpackage from JDK14) and Docker. > > Only happens on Windows docker. Running directly on WIndows it works > > with > > JDK 17. > > What has changed with jpackage that it no longer can write to the > destination directory when running in Docker? > Is it a regression/bug with jpackage? > > > I don't know what has changed in jpackage, maybe it didn't check for > write access previously. However, the error you are seeing suggests > there may be a lower-level issue, maybe a driver issue. It would be > useful if you could print out the DACL (using cacls is okay) and the DOS > attributes. > > -Alan > > > > From scolebourne at openjdk.java.net Mon Mar 7 08:27:59 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Mon, 7 Mar 2022 08:27:59 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 21:17:50 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Too many 'the' Just to note that there is also some caching in `DecimalStyle`. It might be possible to reuse `DecimalStyle` here (if it was extended to support grouping separators). ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From Alan.Bateman at oracle.com Mon Mar 7 08:28:29 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 7 Mar 2022 08:28:29 +0000 Subject: Wrong behavior of standard IO library when interacting with Samba (very serious) In-Reply-To: References: Message-ID: On 07/03/2022 05:33, Glavo wrote: > I am a Java application developer. I noticed that when my program runs on > Windows in a samba shared folder (mounted as a drive, or accessed via a UNC > path), the Java standard IO library has some unusual behavior. > Note that these issues only occur when accessing a folder shared by > *Samba*, but not for the folder shared via SMB by another Windows host. > > One of the bugs was reported years ago (JDK-8154915): `Files.isWritable` > always returns false for files shared by samba. It's worth noting for this > question that `File::canWrite()`'s behavior is normal. > (So in my program I pass `!Files.isWritable(p) && p.toFile().canWrite()` to > detect if it's shared by samba and give the user a warning) > This problem keeps showing up on several of my devices, so it should be > fine to reproduce. The reason it wasn't resolved seems to be that the > OpenJDK maintainers didn't understand that it came up when interacting with > Samba (not just SMB). Testing if a file is writable, without side effects, can be complicated on Windows. File.canXXX only looks at the DOS attribute so can't give an accurate result. Files.isWritable examines the DACL, the legacy DOS attribute, and whether the volume is read-only, so there is more to go wrong. We've looked at many Windows <--> SAMBA interop issues over the years and it's always been that the Windows calls were failing or returning results that suggested the file had a DACL with 0 entries. I can't tell from your mail where the issue is but some of the behavior you report in your mail is very unusual. The JDK does not cache results so if you are saying that it requires restarting the JDK then it suggests an issue at a lower level. -Alan From alanb at openjdk.java.net Mon Mar 7 09:37:02 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 7 Mar 2022 09:37:02 GMT Subject: RFR: 8280404: Unexpected exception thrown when CEN file entry comment length is not valid [v2] In-Reply-To: References: Message-ID: <3dZLEzSs2ZYk2vyMw4a3ttYxp5gu6z-mQFN1vEe3zYs=.06ed113e-08ef-4435-9f94-795f7a3fde99@github.com> On Thu, 3 Mar 2022 17:46:53 GMT, Lance Andersen wrote: >> Hi all, >> >> This PR addresses an issue where an unexpected exception is thrown when the CEN file entry comment length is not correct. >> >> Mach5 tiers 1 - 3 run clean with this change. > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Add comment indicating that zcp.toString could throw an Exception Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7673 From david.holmes at oracle.com Mon Mar 7 10:54:56 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Mar 2022 20:54:56 +1000 Subject: Wrong behavior of standard IO library when interacting with Samba (very serious) In-Reply-To: References: Message-ID: On 7/03/2022 6:28 pm, Alan Bateman wrote: > On 07/03/2022 05:33, Glavo wrote: >> I am a Java application developer. I noticed that when my program runs on >> Windows in a samba shared folder (mounted as a drive, or accessed via >> a UNC >> path), the Java standard IO library has some unusual behavior. >> Note that these issues only occur when accessing a folder shared by >> *Samba*, but not for the folder shared via SMB by another Windows host. >> >> One of the bugs was reported years ago (JDK-8154915): `Files.isWritable` >> always returns false for files shared by samba. It's worth noting for >> this >> question that `File::canWrite()`'s behavior is normal. >> (So in my program I pass `!Files.isWritable(p) && >> p.toFile().canWrite()` to >> detect if it's shared by samba and give the user a warning) >> This problem keeps showing up on several of my devices, so it should be >> fine to reproduce. The reason it wasn't resolved seems to be that the >> OpenJDK maintainers didn't understand that it came up when interacting >> with >> Samba (not just SMB). > Testing if a file is writable, without side effects, can be complicated > on Windows. File.canXXX only looks at the DOS attribute so can't give an > accurate result. Files.isWritable examines the DACL, the legacy DOS > attribute, and whether the volume is read-only, so there is more to go > wrong. We've looked at many Windows <--> SAMBA interop issues over the > years and it's always been that the Windows calls were failing or > returning results that suggested the file had a DACL with 0 entries. That sounds similar to this old (but still open) SAMBA bug report: https://bugzilla.samba.org/show_bug.cgi?id=7973 David ----- > I > can't tell from your mail where the issue is but some of the behavior > you report in your mail is very unusual. The JDK does not cache results > so if you are saying that it requires restarting the JDK then it > suggests an issue at a lower level. > > -Alan From plevart at openjdk.java.net Mon Mar 7 11:26:09 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 7 Mar 2022 11:26:09 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy 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 26 additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8266670 > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/b40644f8...14980605 Changes requested by plevart (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From djelinski at openjdk.java.net Mon Mar 7 12:14:04 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Mon, 7 Mar 2022 12:14:04 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 02:36:58 GMT, Xin Liu wrote: > If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. > toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). > > java.io.BufferedRead::readLine() is a case that StringBuilder grows only. > > In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. > > Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. > > Before: > > $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms > > > After > > $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms src/java.base/share/classes/java/lang/String.java line 1446: > 1444: */ > 1445: public String(StringBuffer buffer) { > 1446: this(buffer, null); This method is no longer synchronized on StringBuffer ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From plevart at openjdk.java.net Mon Mar 7 11:26:10 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 7 Mar 2022 11:26:10 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12] In-Reply-To: References: Message-ID: On Mon, 28 Feb 2022 18:20:13 GMT, ExE Boss wrote: >> It does because of the AccessFlags.MODULE constant. > >> It does because of the AccessFlags.MODULE constant. > > But?that?s exactly?what the?unqualified `MODULE`?identifier refers?to, and?there?s no?other bare?`MODULE`?identifier in?scope that?would?shadow the?`AccessFlag.MODULE`?constant from?the?POV of?`AccessFlag.LocationToFlags`. This is just implementation detail, but I think the reverse mapping from Location to AccessFlag(s) could be established implicitly during the initialization of the AccessFlag enum since it is only used from within code of that enum class. Like this: Index: src/java.base/share/classes/java/lang/reflect/AccessFlag.java IDEA additional info: Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP <+>UTF-8 =================================================================== diff --git a/src/java.base/share/classes/java/lang/reflect/AccessFlag.java b/src/java.base/share/classes/java/lang/reflect/AccessFlag.java --- a/src/java.base/share/classes/java/lang/reflect/AccessFlag.java (revision 1498060544413cb67de8b1a82fbbf15d388d62c3) +++ b/src/java.base/share/classes/java/lang/reflect/AccessFlag.java (date 1646651355828) @@ -26,8 +26,13 @@ package java.lang.reflect; import java.util.Collections; +import java.util.EnumMap; +import java.util.EnumSet; +import java.util.HashMap; import java.util.Map; import java.util.Set; +import java.util.function.Function; + import static java.util.Map.entry; /** @@ -248,6 +253,14 @@ this.mask = mask; this.sourceModifier = sourceModifier; this.locations = locations; + for (var location : locations) { + LocationToFlags.MAP.computeIfAbsent(location, new Function<>() { + @Override + public Set apply(Location location) { + return EnumSet.noneOf(AccessFlag.class); + } + }).add(this); + } } /** @@ -283,7 +296,7 @@ */ public static Set maskToAccessFlags(int mask, Location location) { Set result = java.util.EnumSet.noneOf(AccessFlag.class); - for (var accessFlag : LocationToFlags.locationToFlags.get(location)) { + for (var accessFlag : LocationToFlags.MAP.get(location)) { int accessMask = accessFlag.mask(); if ((mask & accessMask) != 0) { result.add(accessFlag); @@ -363,34 +376,7 @@ } private static class LocationToFlags { - private static Map> locationToFlags = - Map.ofEntries(entry(Location.CLASS, - Set.of(PUBLIC, FINAL, SUPER, - INTERFACE, ABSTRACT, - SYNTHETIC, ANNOTATION, - ENUM, AccessFlag.MODULE)), - entry(Location.FIELD, - Set.of(PUBLIC, PRIVATE, PROTECTED, - STATIC, FINAL, VOLATILE, - TRANSIENT, SYNTHETIC, ENUM)), - entry(Location.METHOD, - Set.of(PUBLIC, PRIVATE, PROTECTED, - STATIC, FINAL, SYNCHRONIZED, - BRIDGE, VARARGS, NATIVE, - ABSTRACT, STRICT, SYNTHETIC)), - entry(Location.INNER_CLASS, - Set.of(PUBLIC, PRIVATE, PROTECTED, - STATIC, FINAL, INTERFACE, ABSTRACT, - SYNTHETIC, ANNOTATION, ENUM)), - entry(Location.METHOD_PARAMETER, - Set.of(FINAL, SYNTHETIC, MANDATED)), - entry(Location.MODULE, - Set.of(OPEN, SYNTHETIC, MANDATED)), - entry(Location.MODULE_REQUIRES, - Set.of(TRANSITIVE, STATIC_PHASE, SYNTHETIC, MANDATED)), - entry(Location.MODULE_EXPORTS, - Set.of(SYNTHETIC, MANDATED)), - entry(Location.MODULE_OPENS, - Set.of(SYNTHETIC, MANDATED))); + private static final Map> MAP = + new EnumMap<>(Location.class); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From plevart at openjdk.java.net Mon Mar 7 12:47:06 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Mon, 7 Mar 2022 12:47:06 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy 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 26 additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8266670 > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/6eb09aa6...14980605 The mapping from Location to AccessFlag(s) could be implemented event without using a Map. You just have to be careful not to use EnumSet for that (i.e. before AccessFlag enum constants are fully initialized) - an ArrayList is better for this case anyway. Also, conversion from ModuleDescriptor modifier(s) to AccessFlag(s) could be done without first creating a bitmask and then re-constructing a set of AccessFlag(s) from it. Reflective object modifiers can only be translated via bitmask, but various ModuleDescriptor Modifier(s) may have a direct mapping to corresponding AccessFlag(s). For example: https://github.com/plevart/jdk/commit/5a3cd8f6851a0deae7e3e5028bba9a51d7863929 ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From jlaskey at openjdk.java.net Mon Mar 7 13:08:08 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 13:08:08 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com> Message-ID: On Fri, 4 Mar 2022 21:14:26 GMT, Roger Riggs wrote: >> As a separate/future issue, perhaps the constructors should be deprecated to nudge people to using the static `getInstance` methods. > > Would it be just as effective and improve performance more broadly to cache in DecimalFormatSymbols.getInstance()? > > Declarations should be private unless there is a package need. > In this case, the only access to should be via the method. Will investigate ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Mon Mar 7 13:08:10 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 13:08:10 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> Message-ID: On Fri, 4 Mar 2022 19:02:29 GMT, Naoto Sato wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Too many 'the' > > src/java.base/share/classes/java/util/Formatter.java line 2026: > >> 2024: // Caching zero. >> 2025: static char getZero(Locale locale) { >> 2026: return locale == null ? '0' : getDecimalFormatSymbols(locale).getZeroDigit(); > > While we are at it, it would be beneficial to cache locale-dependent grouping and decimal separators too. Noted ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Mon Mar 7 13:20:08 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 13:20:08 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 08:25:19 GMT, Stephen Colebourne wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Too many 'the' > > Just to note that there is also some caching in `DecimalStyle`. It might be possible to reuse `DecimalStyle` here (if it was extended to support grouping separators). @jodastephen True that. It would also be nice if `DecimalFormatSymbols` also contained grouping size. Will investigate but will use a separate PR for the fallout. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Mon Mar 7 13:20:09 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 13:20:09 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: <9g47OUC6AaV2e1baWOmanc9ISVbA5hZKq2IdjYWw36s=.3d31f016-047e-4f60-a5e0-0113783bda43@github.com> References: <9g47OUC6AaV2e1baWOmanc9ISVbA5hZKq2IdjYWw36s=.3d31f016-047e-4f60-a5e0-0113783bda43@github.com> Message-ID: <4LdL1Bc2Gt0OAiNRMgCO0hcdgJyLvnPF44cQ3TazojU=.ae0e8d65-6b45-4a14-b7b0-7094658c7a51@github.com> On Mon, 7 Mar 2022 00:33:53 GMT, Naoto Sato wrote: >>> will now try and update/use this cached class level static state DFS. That would thus require some kind of thread safety semantics to be implemented for this new getDecimalFormatSymbols(Locale) method, isn't it? >> >> A bit more closer look at the code and it appears to me that the use of : >> >> DecimalFormatSymbols dfs = DFS; >> >> and then working off that local variable prevents any kind of race issues that might be caused due to multi-thread access. Of course it still means that multiple threads might still go ahead and do a: >> >> dfs = DecimalFormatSymbols.getInstance(locale); >> >> on first access (when `DFS` is null) but that in itself should be harmless. >> >> If this is intentional (which I suspect it is), should some comment be added in this method explaining this multi-thread access detail? > > Initially, I thought of the same thing (not the `Formatter` but `DecimalFormatSymbols` itself, as it is also not thread safe), but I concluded it was OK, as there is no mutation going on. I agree with Jaikiran that some comments might help here. Noted ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Mon Mar 7 13:20:10 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 13:20:10 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 20:04:42 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Too many 'the' > > src/java.base/share/classes/java/util/Formatter.java line 2025: > >> 2023: >> 2024: // Caching zero. >> 2025: static char getZero(Locale locale) { > > Perhaps should be private. > The comment says caching zero, but its really the DecimalFormatSymbols that are cached. Noted. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From erikj at openjdk.java.net Mon Mar 7 13:44:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Mar 2022 13:44:05 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 06:49:16 GMT, Julian Waters wrote: > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From jlaskey at openjdk.java.net Mon Mar 7 14:27:07 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 14:27:07 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v3] In-Reply-To: References: <_OveNxI3iuyzJzmLFlJLU_H1FuX74b2DpNz-UdnTFY4=.92f7279f-0804-4ed8-b86d-82bc3fd8d931@github.com> <5WSFTsYa4eNkx0iHsWQdi5cA1mJyLSDswFimK4q-f_M=.c164e21d-d30d-4c2d-9847-ea1cb007603f@github.com> Message-ID: On Mon, 7 Mar 2022 13:05:09 GMT, Jim Laskey wrote: >> Would it be just as effective and improve performance more broadly to cache in DecimalFormatSymbols.getInstance()? >> >> Declarations should be private unless there is a package need. >> In this case, the only access to should be via the method. > > Will investigate Performance is on par when cached in DecimalFormatSymbols. Will switch to that direction. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Mon Mar 7 14:45:44 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 14:45:44 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v4] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation. - Edits from PR comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/9ac0c283..fcbf66a2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=02-03 Stats: 36 lines in 2 files changed: 17 ins; 9 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From darcy at openjdk.java.net Mon Mar 7 14:52:09 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Mar 2022 14:52:09 GMT Subject: RFR: JDK-8282696: Add constructors taking a cause to InvalidObjectException and InvalidClassException [v6] In-Reply-To: References: Message-ID: > Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. > > Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. > > Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Reflow per review comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7711/files - new: https://git.openjdk.java.net/jdk/pull/7711/files/2de370f7..2aeb7f03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7711&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7711/head:pull/7711 PR: https://git.openjdk.java.net/jdk/pull/7711 From darcy at openjdk.java.net Mon Mar 7 14:52:10 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Mar 2022 14:52:10 GMT Subject: Integrated: JDK-8282696: Add constructors taking a cause to InvalidObjectException and InvalidClassException In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 02:57:47 GMT, Joe Darcy wrote: > Occasionally in core-libs we've discussed whether or not to do a pass over the exception classes and proactively add any of four missing convention constructors per java.lang.Throwable (no-arg, string, cause, cause and string). Last time this came up, we decided a wide-scale effort wasn't worthwhile. > > Prompted by some other recent work, I decided to take a quick look at the dual-approach: grep for calls to initCause in java.base and seeing which exception classes repeated were initCaused. Those exception classes are good candidates for cause-taking constructors. > > Two such exception classes area InvalidObjectException and InvalidClassException, along with their superclass ObjectStreamException. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282697 This pull request has now been integrated. Changeset: 104e3cb2 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/104e3cb24b4de5512abf9f5491f9c530b26838d3 Stats: 212 lines in 7 files changed: 176 ins; 14 del; 22 mod 8282696: Add constructors taking a cause to InvalidObjectException and InvalidClassException Reviewed-by: lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7711 From jlaskey at openjdk.java.net Mon Mar 7 14:52:16 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 14:52:16 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v5] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Drop DecimalFormatSymbols.getLocale change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/fcbf66a2..b93cdb03 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=03-04 Stats: 9 lines in 1 file changed: 0 ins; 9 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From duke at openjdk.java.net Mon Mar 7 15:17:31 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Mon, 7 Mar 2022 15:17:31 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption Message-ID: `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): - `MethodHandles.longestParameterList()` never returns null - parameter types are never null - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null - exceptions types of method signature are never null ------------- Commit messages: - 8282662: Use List/Set.of() factory methods to save memory Changes: https://git.openjdk.java.net/jdk/pull/7729/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282662 Stats: 22 lines in 8 files changed: 1 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From dfuchs at openjdk.java.net Mon Mar 7 15:29:01 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 7 Mar 2022 15:29:01 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: <1oi34GhExojhpCh4STwXlzAJVSkLi4Re1qd-0koYt4g=.6b0cd860-3171-4244-9143-772493e101bd@github.com> On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? wrote: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null There's also another difference: they have different serial forms. From my cursory inspection it doesn't look like the returned list are put in serializable fields but it could be good to double check it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Mon Mar 7 15:57:05 2022 From: duke at openjdk.java.net (liach) Date: Mon, 7 Mar 2022 15:57:05 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? wrote: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From redestad at openjdk.java.net Mon Mar 7 16:09:58 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Mar 2022 16:09:58 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com> On Mon, 7 Mar 2022 15:54:02 GMT, liach wrote: > Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it? A good observation. In a couple of these places we could probably use `JavaUtilCollectionAccess.listFromTrustedArray` to avoid such copies. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From lancea at openjdk.java.net Mon Mar 7 16:14:11 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Mar 2022 16:14:11 GMT Subject: Integrated: 8280404: Unexpected exception thrown when CEN file entry comment length is not valid In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 11:19:12 GMT, Lance Andersen wrote: > Hi all, > > This PR addresses an issue where an unexpected exception is thrown when the CEN file entry comment length is not correct. > > Mach5 tiers 1 - 3 run clean with this change. This pull request has now been integrated. Changeset: f0995abe Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/f0995abe62b81cf9c96cc07caa0ac27d00c96ff1 Stats: 355 lines in 2 files changed: 354 ins; 0 del; 1 mod 8280404: Unexpected exception thrown when CEN file entry comment length is not valid Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7673 From jwaters at openjdk.java.net Mon Mar 7 16:24:00 2022 From: jwaters at openjdk.java.net (Julian Waters) Date: Mon, 7 Mar 2022 16:24:00 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 13:40:48 GMT, Erik Joelsson wrote: > > Should I change the JBS issue title to match the PR title, or is it preferred for the PR title to change? > > They need to match. You can either do it manually, or change the title to just the bug number and the bot will change it for you. Alright, I can't change the title of the PR, I guess it'll be easier for me to change the issue instead ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From lancea at openjdk.java.net Mon Mar 7 16:43:08 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Mar 2022 16:43:08 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo What problem are you having editing the PR header? You should be able to do so as the author of the PR ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From rriggs at openjdk.java.net Mon Mar 7 16:50:03 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Mar 2022 16:50:03 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v4] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 15:38:44 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Reverted addition of the test via echo As an alternative fix, please take a look at Draft PR: https://github.com/openjdk/jdk/pull/7709. In the default handling of arguments, the check for what is quoted is reverted to prior to 8255068. First and last quotes are sufficient to identify a "quoted" string. The check for a backslash ("\") is removed. This original check is sufficient for `jdk.lang.Process.allowAmbiguousCommands = true`. For the case where the system property `jdk.lang.Process.allowAmbiguousCommands = false` and the argument has first and last quotes, a backslash ("\") before the final quote must not allow the quote to interpreted as a literal quote and merge the following argument. The backslashes will doubled to prevent the interpretation of the quote as a literal. This is the correct encoding if the command uses the ".exe" encoding, when reparsing the arguments the doubled backslashes are reduced to the original contents. When the command is using the simpler parsing that does not support literal quotes, the backslash before the quote is typically is a trailing backslash on a file path and in that case the additional backslash is redundant and has no effect on the interpretation of the argument as a directory path. The PR includes a test of the 12 combinations of invoking an "java"/.exe program, a .cmd script, and a Visual Basic script (which uses the .exe rules but different command line parser); with and without application quotes and compares the actual results with the expected arguments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From kcr at openjdk.java.net Mon Mar 7 16:52:07 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 16:52:07 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote: > What problem are you having editing the PR header? You should be able to do so as the author of the PR Exactly. You should see an "Edit" button near the right edge of the PR title. See the attached image: ![PR-title](https://user-images.githubusercontent.com/34689748/157079404-eadbe8be-ae94-41e0-b17b-0d1a8026b9da.png) ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 16:56:06 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 16:56:06 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo But as the JBS title and PR title now match, this is a moot point. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From jlaskey at openjdk.java.net Mon Mar 7 17:09:37 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 17:09:37 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v6] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Correct caching test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/b93cdb03..bf797539 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From joehw at openjdk.java.net Mon Mar 7 17:08:06 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Mar 2022 17:08:06 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v3] In-Reply-To: References: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com> Message-ID: On Mon, 7 Mar 2022 03:00:45 GMT, Roger Riggs wrote: >> OK, I propose `isIsoBased()` for the name, which I initially thought of. If there is no objection, I will modify the spec/impl. > > Is `IsoBased` is fine with me. "isISOLike" is too vague. That matches the javadoc as well, that it "supports ISO based fields". ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From rreddy at openjdk.java.net Mon Mar 7 17:13:33 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Mon, 7 Mar 2022 17:13:33 GMT Subject: RFR: 8281093: Violating Attribute-Value Normalization in the XML specification 1.0 Message-ID: This fix is for violation of XML specification on Attribute-Value normalization for external entities having character "\r". While normalizing entity with '\r', we should be checking if the entity is external before changing the position and offset. "isExternal()" check is missed in the new method : normalizeNewlines(short version, XMLString buffer, boolean append,boolean storeWS, NameType nt). . ------------- Commit messages: - 8281093: Violating Attribute-Value Normalization in the XML specification 1.0 Changes: https://git.openjdk.java.net/jdk/pull/7731/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7731&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8281093 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7731.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7731/head:pull/7731 PR: https://git.openjdk.java.net/jdk/pull/7731 From ihse at openjdk.java.net Mon Mar 7 17:18:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 7 Mar 2022 17:18:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 16:40:15 GMT, Lance Andersen wrote: >> Hi >> >> I have reviewed the code for removing double semicolons at the end of lines >> >> all the best >> matteo > > What problem are you having editing the PR header? You should be able to do so as the author of the PR @LanceAndersen @kevinrushforth TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From kcr at openjdk.java.net Mon Mar 7 17:18:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Mar 2022 17:18:03 GMT Subject: RFR: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 17:12:25 GMT, Magnus Ihse Bursie wrote: > TheShermanTanker is not the author of this PR, he's just assisting the author by creating the JBS issue. Ah, that explains it then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From joehw at openjdk.java.net Mon Mar 7 17:57:59 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Mar 2022 17:57:59 GMT Subject: RFR: 8281093: Violating Attribute-Value Normalization in the XML specification 1.0 In-Reply-To: References: Message-ID: <1V-c_lTWCtAInbdmqCVqPzZAMq4ZrgwxbcPiOLjKfdk=.21a888fa-5ce2-4533-9e88-d3310cc0438c@github.com> On Mon, 7 Mar 2022 17:07:20 GMT, Ravi Reddy wrote: > This fix is for violation of XML specification on Attribute-Value normalization for external entities having character "\r". > > While normalizing entity with '\r', we should be checking if the entity is external before changing the position and offset. "isExternal()" check is missed in the new method : > normalizeNewlines(short version, XMLString buffer, boolean append,boolean storeWS, NameType nt). > . Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7731 From naoto at openjdk.java.net Mon Mar 7 18:20:43 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Mar 2022 18:20:43 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v4] In-Reply-To: References: Message-ID: > Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. Naoto Sato 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: - Renamed the new method - Merge branch 'master' into JDK-8279185 - Addresses review comments - copyright year fix - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7683/files - new: https://git.openjdk.java.net/jdk/pull/7683/files/e0b329d7..530ed40e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7683&range=02-03 Stats: 12800 lines in 349 files changed: 8488 ins; 2645 del; 1667 mod Patch: https://git.openjdk.java.net/jdk/pull/7683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7683/head:pull/7683 PR: https://git.openjdk.java.net/jdk/pull/7683 From naoto at openjdk.java.net Mon Mar 7 18:26:09 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Mar 2022 18:26:09 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v3] In-Reply-To: References: <4nAOf2AENiKU37ZLzi8v3S3F1Bt0P-brk3heRfKNc5E=.a1c75e93-2243-4566-948d-9e0f96ae90d8@github.com> Message-ID: <8ibI3t0cbrKyoDcNX0XPkIXKecA12_eHCQvHH6LU4KM=.83ec1895-35c4-49c4-927b-71c3ceca2fca@github.com> On Mon, 7 Mar 2022 17:04:25 GMT, Joe Wang wrote: >> Is `IsoBased` is fine with me. "isISOLike" is too vague. > > That matches the javadoc as well, that it "supports ISO based fields". Renamed the new method to `isIsoBased()`. Modified the CSR accordingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From joehw at openjdk.java.net Mon Mar 7 18:34:05 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Mon, 7 Mar 2022 18:34:05 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v4] In-Reply-To: References: Message-ID: <7sYLKTu76eFlmU46Pp6qmZENqYF1yUqvdgAsnVsrIQw=.9b5b2f51-ee65-4ec1-b515-e5d01ae1fca4@github.com> On Mon, 7 Mar 2022 18:20:43 GMT, Naoto Sato wrote: >> Supporting `IsoFields` temporal fields in chronologies that are similar to ISO chronology. Corresponding CSR has also been drafted. > > Naoto Sato 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: > > - Renamed the new method > - Merge branch 'master' into JDK-8279185 > - Addresses review comments > - copyright year fix > - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate src/java.base/share/classes/java/time/chrono/IsoChronology.java line 689: > 687: */ > 688: @Override > 689: public boolean isIsoBased() { Is this meant to be 'default'? The CSR indicated adding default methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From naoto at openjdk.java.net Mon Mar 7 18:50:07 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Mar 2022 18:50:07 GMT Subject: RFR: 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate [v4] In-Reply-To: <7sYLKTu76eFlmU46Pp6qmZENqYF1yUqvdgAsnVsrIQw=.9b5b2f51-ee65-4ec1-b515-e5d01ae1fca4@github.com> References: <7sYLKTu76eFlmU46Pp6qmZENqYF1yUqvdgAsnVsrIQw=.9b5b2f51-ee65-4ec1-b515-e5d01ae1fca4@github.com> Message-ID: On Mon, 7 Mar 2022 18:30:28 GMT, Joe Wang wrote: >> Naoto Sato 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: >> >> - Renamed the new method >> - Merge branch 'master' into JDK-8279185 >> - Addresses review comments >> - copyright year fix >> - 8279185: Support for IsoFields in JapaneseDate/MinguoDate/ThaiBuddhistDate > > src/java.base/share/classes/java/time/chrono/IsoChronology.java line 689: > >> 687: */ >> 688: @Override >> 689: public boolean isIsoBased() { > > Is this meant to be 'default'? The CSR indicated adding default methods. The `default` method has been added to `java.time.chrono.Chronology` interface. This is its overridden method implemented in `IsoChronology` concrete class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7683 From rreddy at openjdk.java.net Mon Mar 7 19:40:09 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Mon, 7 Mar 2022 19:40:09 GMT Subject: Integrated: 8281093: Violating Attribute-Value Normalization in the XML specification 1.0 In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 17:07:20 GMT, Ravi Reddy wrote: > This fix is for violation of XML specification on Attribute-Value normalization for external entities having character "\r". > > While normalizing entity with '\r', we should be checking if the entity is external before changing the position and offset. "isExternal()" check is missed in the new method : > normalizeNewlines(short version, XMLString buffer, boolean append,boolean storeWS, NameType nt). > . This pull request has now been integrated. Changeset: 3996782c Author: Ravi Reddy Committer: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/3996782c5af7b0396d5133fab457c507758d9340 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8281093: Violating Attribute-Value Normalization in the XML specification 1.0 Reviewed-by: joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/7731 From rriggs at openjdk.java.net Mon Mar 7 19:49:17 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Mar 2022 19:49:17 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy 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 26 additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8266670 > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/aa899b84...14980605 src/java.base/share/classes/java/lang/Class.java line 1334: > 1332: // allows PRIVATE, PROTECTED, and STATIC, which are not > 1333: // allowed on Location.CLASS. > 1334: return AccessFlag.maskToAccessFlags(getModifiers(), Computing and creating the Set every time seems like a high overhead operation (compared to getModifiers()). Caching either here (in the Member) or in AccessFlag.maskToAccessFlags would be desirable. Caching is idempotent so it should not need synchronization. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From psandoz at openjdk.java.net Mon Mar 7 20:06:03 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Mon, 7 Mar 2022 20:06:03 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: <5HJGUVC8INFEs4N09Ea0DaXEfn0KUecBt0Cal4uuo1Q=.7daf7c68-faab-4246-a4a7-2dbd75e03c84@github.com> On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks I think we should explore an intrinsic that also covers `Arrays.hashCode` too, as that will have the broader impact. It may be possible to express the intrinsic in say `ArraysSupport` as: @IntrinsicCandidate public long hashCode(Object o, int offset, int length, Class type, boolean unsigned) { return 0; } then used as: public static int hashCode(byte[] a) { if (a == null) return 0; long v = ArraysSupport.hashCode(a, BYTE_OFFSET, a.length, byte.class, false); result = v & 0xFFFF_FFFF; int i = (int) (v >> 32) for (; i < a.length; i++) { result = 31 * result + a[i]; } return result; } Allowing for the intrinsic to return a "remainder" may simply its implementation (avoid having to do the tail). ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From jlaskey at openjdk.java.net Mon Mar 7 20:36:36 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 20:36:36 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v7] In-Reply-To: References: Message-ID: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with four additional commits since the last revision: - Add comment about DecimalFormatSymbols being mutable objects. - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. - Revert "Drop DecimalFormatSymbols.getLocale change" This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. - Revert "Correct caching test" This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/bf797539..89354a0e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=05-06 Stats: 34 lines in 2 files changed: 17 ins; 14 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Mon Mar 7 20:36:38 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 7 Mar 2022 20:36:38 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v6] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 17:09:37 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Correct caching test Interesting fishing trip. DecimalFormatSymbols are mutable objects. As are NumberFormat/DecimalFormal. Hence, caching in the Formatter is the correct location. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From rriggs at openjdk.java.net Mon Mar 7 21:29:01 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 7 Mar 2022 21:29:01 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v7] In-Reply-To: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> References: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> Message-ID: On Mon, 7 Mar 2022 20:36:36 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment about DecimalFormatSymbols being mutable objects. > - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." > > This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. > - Revert "Drop DecimalFormatSymbols.getLocale change" > > This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. > - Revert "Correct caching test" > > This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. LGTM src/java.base/share/classes/java/util/Formatter.java line 4550: > 4548: > 4549: if (l == null || l.equals(Locale.US)) { > 4550: grpSize = 3; unintentional indentation ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7703 From darcy at openjdk.java.net Mon Mar 7 21:37:08 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 7 Mar 2022 21:37:08 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: <9wbBzHZQeEiFwigJaOIMi2mpJ-Is8l4w7kIzwt1RFD4=.b9f1d553-7a3f-4192-94bb-43cf9f37b2f4@github.com> On Mon, 7 Mar 2022 18:20:23 GMT, Roger Riggs wrote: >> Joe Darcy 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 26 additional commits since the last revision: >> >> - Respond to review feedback. >> - Merge branch 'master' into JDK-8266670 >> - Make workding changes suggested in review feedback. >> - Merge branch 'master' into JDK-8266670 >> - Typo fix; add implSpec to Executable. >> - Appease jcheck. >> - Fix some bugs found by inspection, docs cleanup. >> - Merge branch 'master' into JDK-8266670 >> - Initial support for accessFlags methods >> - Add mask to access flag functionality. >> - ... and 16 more: https://git.openjdk.java.net/jdk/compare/36b93dbf...14980605 > > src/java.base/share/classes/java/lang/Class.java line 1334: > >> 1332: // allows PRIVATE, PROTECTED, and STATIC, which are not >> 1333: // allowed on Location.CLASS. >> 1334: return AccessFlag.maskToAccessFlags(getModifiers(), > > Computing and creating the Set every time seems like a high overhead operation (compared to getModifiers()). > Caching either here (in the Member) or in AccessFlag.maskToAccessFlags would be desirable. > Caching is idempotent so it should not need synchronization. For this phase of the work, I was trying to avoid premature optimization of building caches, etc. Such refinement should certainly be considered later on. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Mon Mar 7 21:37:05 2022 From: duke at openjdk.java.net (Matteo Baccan) Date: Mon, 7 Mar 2022 21:37:05 GMT Subject: Integrated: 8282657: Code cleanup: removing double semicolons at the end of lines In-Reply-To: References: Message-ID: On Fri, 28 Jan 2022 14:39:31 GMT, Matteo Baccan wrote: > Hi > > I have reviewed the code for removing double semicolons at the end of lines > > all the best > matteo This pull request has now been integrated. Changeset: ccad3923 Author: Matteo Baccan Committer: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/ccad39237ab860c5c5579537f740177e3f1adcc9 Stats: 93 lines in 82 files changed: 0 ins; 0 del; 93 mod 8282657: Code cleanup: removing double semicolons at the end of lines Reviewed-by: lancea, rriggs, ihse, prr, iris, wetmore, darcy, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7268 From duke at openjdk.java.net Mon Mar 7 21:43:58 2022 From: duke at openjdk.java.net (Richard Startin) Date: Mon, 7 Mar 2022 21:43:58 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks Great to see this taken up. As it?s implemented here, it?s still scalar, but the unroll prevents a strength reduction of the multiplication in the loop from result = 31 * result + element; to: result = (result << 5) - result + element which creates a data dependency and slows the loop down. This was first reported by Peter Levart here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028898.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From naoto at openjdk.java.net Mon Mar 7 21:52:04 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 7 Mar 2022 21:52:04 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v7] In-Reply-To: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> References: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> Message-ID: On Mon, 7 Mar 2022 20:36:36 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment about DecimalFormatSymbols being mutable objects. > - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." > > This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. > - Revert "Drop DecimalFormatSymbols.getLocale change" > > This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. > - Revert "Correct caching test" > > This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. Looks good. Since you are adding a new API, I would expect some unit tests for `DecimalFormatSymbols.getLocale()` method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From igraves at openjdk.java.net Mon Mar 7 22:29:29 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Mon, 7 Mar 2022 22:29:29 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v2] In-Reply-To: References: Message-ID: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> > Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - merging master - Catching erronious setting of matcher.hitEnd ------------- Changes: https://git.openjdk.java.net/jdk/pull/7466/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7466&range=01 Stats: 29 lines in 2 files changed: 27 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7466/head:pull/7466 PR: https://git.openjdk.java.net/jdk/pull/7466 From bpb at openjdk.java.net Mon Mar 7 22:46:03 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 7 Mar 2022 22:46:03 GMT Subject: RFR: JDK-8282144 RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 14:47:50 GMT, Jim Laskey wrote: > Class: ./java.base/share/classes/jdk/internal/util/random/RandomSupport.java > Method: public static long[] convertSeedBytesToLongs(byte[] seed, int n, int z) > > The method attempts to create an array of longs by consuming the input bytes most significant bit first. New bytes are appended to the existing long using the OR operator on the signed byte. Due to sign extension this will overwrite all the existing bits from 63 to 8 if the next byte is negative. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7614 From bpb at openjdk.java.net Mon Mar 7 22:46:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 7 Mar 2022 22:46:04 GMT Subject: RFR: JDK-8282144 RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes In-Reply-To: References: Message-ID: On Sun, 27 Feb 2022 22:30:44 GMT, Jim Laskey wrote: >> test/jdk/java/util/Random/T8282144.java line 39: >> >>> 37: public class T8282144 { >>> 38: public static void main(String[] args) { >>> 39: RandomGenerator rng = RandomGeneratorFactory.of("L64X128MixRandom").create(42); >> >> Does `rng` always produce the same sequence? If so, then perhaps the seed, `42`, should be a random value that is printed. > > 42 was chosen because its is known to produce negative byte values, other random values might not. OK >> test/jdk/java/util/Random/T8282144.java line 52: >> >>> 50: for (int k = 0; k < existing.length; k++) { >>> 51: if (existing[k] != testing[k]) { >>> 52: throw new RuntimeException("convertSeedBytesToLongs incorrect"); >> >> Should `i`, `j`, and `k` be included in the exception message? > > Correctness is binary - either it works or it doesn't. The values of i, j, k would not assist in isolating issues. Might add to confusion if displayed. Understood. ------------- PR: https://git.openjdk.java.net/jdk/pull/7614 From redestad at openjdk.java.net Mon Mar 7 23:08:49 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Mar 2022 23:08:49 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v10] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Better implementation for aarch64 returning roughly the count of positive bytes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/85be36ae..81ef04ec Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=08-09 Stats: 34 lines in 3 files changed: 13 ins; 3 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From lancea at openjdk.java.net Mon Mar 7 23:09:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 7 Mar 2022 23:09:06 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v2] In-Reply-To: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> References: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> Message-ID: On Mon, 7 Mar 2022 22:29:29 GMT, Ian Graves wrote: >> Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. > > Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - merging master > - Catching erronious setting of matcher.hitEnd src/java.base/share/classes/java/util/regex/Pattern.java line 4009: > 4007: return false; > 4008: } > 4009: else { Is there a reason the "else" starts on its own line? ------------- PR: https://git.openjdk.java.net/jdk/pull/7466 From redestad at openjdk.java.net Mon Mar 7 23:13:36 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 7 Mar 2022 23:13:36 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v11] In-Reply-To: References: Message-ID: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com> > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: - use 32-bit mask to calculate correct remainder value - ary1 not required to have USE_KILL effect ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/81ef04ec..934b5b8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=09-10 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From xliu at openjdk.java.net Mon Mar 7 23:36:41 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 7 Mar 2022 23:36:41 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v2] In-Reply-To: References: Message-ID: > If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. > toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). > > java.io.BufferedRead::readLine() is a case that StringBuilder grows only. > > In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. > > Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. > > Before: > > $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms > > > After > > $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms Xin Liu has updated the pull request incrementally with one additional commit since the last revision: make sure String(StringBuffer) is still synchronized. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7671/files - new: https://git.openjdk.java.net/jdk/pull/7671/files/b2373e77..a5e3a162 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671 From xliu at openjdk.java.net Tue Mar 8 00:16:04 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 8 Mar 2022 00:16:04 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 12:10:51 GMT, Daniel Jeli?ski wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> make sure String(StringBuffer) is still synchronized. > > src/java.base/share/classes/java/lang/String.java line 1446: > >> 1444: */ >> 1445: public String(StringBuffer buffer) { >> 1446: this(buffer, null); > > This method is no longer synchronized on StringBuffer you're right. fixed in revision#2. this could be very tricky to discover. thanks for the head-up! ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From darcy at openjdk.java.net Tue Mar 8 00:23:15 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 8 Mar 2022 00:23:15 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy 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 26 additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8266670 > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/012ab186...14980605 > The mapping from Location to AccessFlag(s) could be implemented event without using a Map. You just have to be careful not to use EnumSet for that (i.e. before AccessFlag enum constants are fully initialized) - an ArrayList is better for this case anyway. Also, conversion from ModuleDescriptor modifier(s) to AccessFlag(s) could be done without first creating a bitmask and then re-constructing a set of AccessFlag(s) from it. Reflective object modifiers can only be translated via bitmask, but various ModuleDescriptor Modifier(s) may have a direct mapping to corresponding AccessFlag(s). For example: > > [plevart at 5a3cd8f](https://github.com/plevart/jdk/commit/5a3cd8f6851a0deae7e3e5028bba9a51d7863929) Yes, I made the same observation for the module-related modifiers when coding this up; I'll look to add some API support to avoid the need to detour through bitmasks. To get the public API worked out, I wanted to avoid complications in inter-dependent class initialization. Thanks for suggesting an alternative; I'll consider that when I resume work on this PR (need to start writing some tests...) Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From rriggs at openjdk.java.net Tue Mar 8 01:30:11 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Mar 2022 01:30:11 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v2] In-Reply-To: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> References: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> Message-ID: <6ypZVncDg8B2MY0BQDfhVQaAcYaybjfN5rGpswIaG-o=.f63543c1-08b6-4f0e-a142-02fd8325dcc9@github.com> On Mon, 7 Mar 2022 22:29:29 GMT, Ian Graves wrote: >> Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. > > Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - merging master > - Catching erronious setting of matcher.hitEnd LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7466 From jincheng at ca.ibm.com Tue Mar 8 02:59:05 2022 From: jincheng at ca.ibm.com (Cheng Jin) Date: Tue, 8 Mar 2022 02:59:05 +0000 Subject: Please help backport the fix with the XSLT compiler in JDK18 to JDK11 & JDK17 Message-ID: Hi there, I notice the issue with the XSLT compiler (https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java) I raised later last year at https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/083135.html has been fixed in JDK18 via https://bugs.openjdk.java.net/browse/JDK-8276657. Could you help backport the fix to JDK11 and JDK17 give both of them share the same issue in code? Many thanks. Best Regards Cheng Jin From jpai at openjdk.java.net Tue Mar 8 03:54:07 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 8 Mar 2022 03:54:07 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v2] In-Reply-To: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> References: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> Message-ID: On Mon, 7 Mar 2022 22:29:29 GMT, Ian Graves wrote: >> Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. > > Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - merging master > - Catching erronious setting of matcher.hitEnd test/jdk/java/util/regex/RegExTest.java line 4568: > 4566: > 4567: var matcher1 = Pattern.compile(pat1).matcher(testInput); > 4568: var matcher2 = Pattern.compile(pat2).matcher(testInput); Hello Ian, The JBS issue notes that the bug is only noticed when the `Pattern.CANON_EQ` is used. The javadoc of this `CANON_EQ` states that this isn't enabled by default. Do you think this test should also include matchers which use Pattern(s) with this `CANON_EQ` explicitly enabled? ------------- PR: https://git.openjdk.java.net/jdk/pull/7466 From igraves at openjdk.java.net Tue Mar 8 04:05:41 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 04:05:41 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS Message-ID: Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters ------------- Commit messages: - Fixing bad javadoc - Merge remote-tracking branch 'upstream/master' into bug-8264160 - Updating spec - Proposed change for \b metacharacter Changes: https://git.openjdk.java.net/jdk/pull/7539/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264160 Stats: 78 lines in 2 files changed: 60 ins; 6 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7539/head:pull/7539 PR: https://git.openjdk.java.net/jdk/pull/7539 From igraves at openjdk.java.net Tue Mar 8 04:08:03 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 04:08:03 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v3] In-Reply-To: References: Message-ID: <8JCvYi02SI6E74WIgaTaCHZjyt7UhcGYOWAKZGueEa8=.08982a57-ed1f-4675-a83e-4a314018e805@github.com> > Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Removing errant newline ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7466/files - new: https://git.openjdk.java.net/jdk/pull/7466/files/cf8ffd6c..0d23365f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7466&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7466&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7466/head:pull/7466 PR: https://git.openjdk.java.net/jdk/pull/7466 From igraves at openjdk.java.net Tue Mar 8 04:08:04 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 04:08:04 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v3] In-Reply-To: References: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> Message-ID: On Mon, 7 Mar 2022 23:05:55 GMT, Lance Andersen wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing errant newline > > src/java.base/share/classes/java/util/regex/Pattern.java line 4009: > >> 4007: return false; >> 4008: } >> 4009: else { > > Is there a reason the "else" starts on its own line? I must love Enter too much. Thanks for the catch! ------------- PR: https://git.openjdk.java.net/jdk/pull/7466 From igraves at openjdk.java.net Tue Mar 8 04:23:43 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 04:23:43 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v4] In-Reply-To: References: Message-ID: > Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Adding back some missing CANON_EQ flags ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7466/files - new: https://git.openjdk.java.net/jdk/pull/7466/files/0d23365f..98c3d6fd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7466&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7466&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7466.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7466/head:pull/7466 PR: https://git.openjdk.java.net/jdk/pull/7466 From igraves at openjdk.java.net Tue Mar 8 04:23:48 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 04:23:48 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v2] In-Reply-To: References: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> Message-ID: On Tue, 8 Mar 2022 03:49:43 GMT, Jaikiran Pai wrote: >> Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: >> >> - merging master >> - Catching erronious setting of matcher.hitEnd > > test/jdk/java/util/regex/RegExTest.java line 4568: > >> 4566: >> 4567: var matcher1 = Pattern.compile(pat1).matcher(testInput); >> 4568: var matcher2 = Pattern.compile(pat2).matcher(testInput); > > Hello Ian, > The JBS issue notes that the bug is only noticed when the `Pattern.CANON_EQ` is used. The javadoc of this `CANON_EQ` states that this isn't enabled by default. Do you think this test should also include matchers which use Pattern(s) with this `CANON_EQ` explicitly enabled? Oh wow yes. Thanks for this catch. I was rewriting the tests to fit this mold and left the flags out. Added them back in. Thanks again! ------------- PR: https://git.openjdk.java.net/jdk/pull/7466 From jpai at openjdk.java.net Tue Mar 8 04:31:09 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 8 Mar 2022 04:31:09 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v2] In-Reply-To: References: <3ReG47q2Gq0Hmycy2ZXXBNG3cLohl1OZV_l2BZ3STEM=.2ee9e259-d757-49cd-ad85-a887ff3f6bd3@github.com> Message-ID: On Tue, 8 Mar 2022 04:20:17 GMT, Ian Graves wrote: >> test/jdk/java/util/regex/RegExTest.java line 4568: >> >>> 4566: >>> 4567: var matcher1 = Pattern.compile(pat1).matcher(testInput); >>> 4568: var matcher2 = Pattern.compile(pat2).matcher(testInput); >> >> Hello Ian, >> The JBS issue notes that the bug is only noticed when the `Pattern.CANON_EQ` is used. The javadoc of this `CANON_EQ` states that this isn't enabled by default. Do you think this test should also include matchers which use Pattern(s) with this `CANON_EQ` explicitly enabled? > > Oh wow yes. Thanks for this catch. I was rewriting the tests to fit this mold and left the flags out. Added them back in. Thanks again! Thank you Ian, the changed version of the test looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7466 From jpai at openjdk.java.net Tue Mar 8 05:05:05 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 8 Mar 2022 05:05:05 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v7] In-Reply-To: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> References: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> Message-ID: On Mon, 7 Mar 2022 20:36:36 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with four additional commits since the last revision: > > - Add comment about DecimalFormatSymbols being mutable objects. > - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." > > This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. > - Revert "Drop DecimalFormatSymbols.getLocale change" > > This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. > - Revert "Correct caching test" > > This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. src/java.base/share/classes/java/util/Formatter.java line 2019: > 2017: return dfs; > 2018: } > 2019: // Fetch a new local instance of DecimalFormatSymbols. Note that DFS are mutatble Thank you Jim for these comments about multi-threaded access. Looks good to me. One minor typo on this line - "mutatble" should have been "mutable". ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From zjx001202 at gmail.com Tue Mar 8 06:20:08 2022 From: zjx001202 at gmail.com (Glavo) Date: Tue, 8 Mar 2022 14:20:08 +0800 Subject: Wrong behavior of standard IO library when interacting with Samba (very serious) In-Reply-To: References: Message-ID: Regarding the issue with isWritable, I came across this post after investigating: https://devblogs.microsoft.com/oldnewthing/20060202-00/?p=32413 This does seem to be a Windows `AccessCheck` problem, and there is almost no solution. For this reason, isWritable is not very useful. While you may not be able to fix it, I request an update to isWritable's Javadoc describing the limitations of this method. Its actual function is easily misunderstood, and I feel that users should be told in the documentation that it is recommended to try writing directly instead of checking with this method first. In addition to the problems mentioned here, I've also encountered some rarer problems, such as the bizarre AccessDeniedException. These issues don't seem to be reproducible on all machines, I'll investigate them further. If anyone is interested in these issues, I can provide a reproduction environment to help you test, thank you. On Mon, Mar 7, 2022 at 4:28 PM Alan Bateman wrote: > On 07/03/2022 05:33, Glavo wrote: > > I am a Java application developer. I noticed that when my program runs on > > Windows in a samba shared folder (mounted as a drive, or accessed via a > UNC > > path), the Java standard IO library has some unusual behavior. > > Note that these issues only occur when accessing a folder shared by > > *Samba*, but not for the folder shared via SMB by another Windows host. > > > > One of the bugs was reported years ago (JDK-8154915): `Files.isWritable` > > always returns false for files shared by samba. It's worth noting for > this > > question that `File::canWrite()`'s behavior is normal. > > (So in my program I pass `!Files.isWritable(p) && p.toFile().canWrite()` > to > > detect if it's shared by samba and give the user a warning) > > This problem keeps showing up on several of my devices, so it should be > > fine to reproduce. The reason it wasn't resolved seems to be that the > > OpenJDK maintainers didn't understand that it came up when interacting > with > > Samba (not just SMB). > Testing if a file is writable, without side effects, can be complicated > on Windows. File.canXXX only looks at the DOS attribute so can't give an > accurate result. Files.isWritable examines the DACL, the legacy DOS > attribute, and whether the volume is read-only, so there is more to go > wrong. We've looked at many Windows <--> SAMBA interop issues over the > years and it's always been that the Windows calls were failing or > returning results that suggested the file had a DACL with 0 entries. I > can't tell from your mail where the issue is but some of the behavior > you report in your mail is very unusual. The JDK does not cache results > so if you are saying that it requires restarting the JDK then it > suggests an issue at a lower level. > > -Alan > From duke at openjdk.java.net Tue Mar 8 08:28:06 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 8 Mar 2022 08:28:06 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v12] In-Reply-To: References: Message-ID: <61XTFZoyQLQpYvSzJvCURZpCIZHTL5m8ZlpUHXrdkXk=.535b4795-8f6a-49d3-bb29-8a0f6f090ca3@github.com> On Mon, 7 Mar 2022 11:22:29 GMT, Peter Levart wrote: >>> It does because of the AccessFlags.MODULE constant. >> >> But?that?s exactly?what the?unqualified `MODULE`?identifier refers?to, and?there?s no?other bare?`MODULE`?identifier in?scope that?would?shadow the?`AccessFlag.MODULE`?constant from?the?POV of?`AccessFlag.LocationToFlags`. > > This is just implementation detail, but I think the reverse mapping from Location to AccessFlag(s) could be established implicitly during the initialization of the AccessFlag enum since it is only used from within code of that enum class. Like this: > > > Index: src/java.base/share/classes/java/lang/reflect/AccessFlag.java > IDEA additional info: > Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP > <+>UTF-8 > =================================================================== > diff --git a/src/java.base/share/classes/java/lang/reflect/AccessFlag.java b/src/java.base/share/classes/java/lang/reflect/AccessFlag.java > --- a/src/java.base/share/classes/java/lang/reflect/AccessFlag.java (revision 1498060544413cb67de8b1a82fbbf15d388d62c3) > +++ b/src/java.base/share/classes/java/lang/reflect/AccessFlag.java (date 1646651355828) > @@ -26,8 +26,13 @@ > package java.lang.reflect; > > import java.util.Collections; > +import java.util.EnumMap; > +import java.util.EnumSet; > +import java.util.HashMap; > import java.util.Map; > import java.util.Set; > +import java.util.function.Function; > + > import static java.util.Map.entry; > > /** > @@ -248,6 +253,14 @@ > this.mask = mask; > this.sourceModifier = sourceModifier; > this.locations = locations; > + for (var location : locations) { > + LocationToFlags.MAP.computeIfAbsent(location, new Function<>() { > + @Override > + public Set apply(Location location) { > + return EnumSet.noneOf(AccessFlag.class); > + } > + }).add(this); > + } > } > > /** > @@ -283,7 +296,7 @@ > */ > public static Set maskToAccessFlags(int mask, Location location) { > Set result = java.util.EnumSet.noneOf(AccessFlag.class); > - for (var accessFlag : LocationToFlags.locationToFlags.get(location)) { > + for (var accessFlag : LocationToFlags.MAP.get(location)) { > int accessMask = accessFlag.mask(); > if ((mask & accessMask) != 0) { > result.add(accessFlag); > @@ -363,34 +376,7 @@ > } > > private static class LocationToFlags { > - private static Map> locationToFlags = > - Map.ofEntries(entry(Location.CLASS, > - Set.of(PUBLIC, FINAL, SUPER, > - INTERFACE, ABSTRACT, > - SYNTHETIC, ANNOTATION, > - ENUM, AccessFlag.MODULE)), > - entry(Location.FIELD, > - Set.of(PUBLIC, PRIVATE, PROTECTED, > - STATIC, FINAL, VOLATILE, > - TRANSIENT, SYNTHETIC, ENUM)), > - entry(Location.METHOD, > - Set.of(PUBLIC, PRIVATE, PROTECTED, > - STATIC, FINAL, SYNCHRONIZED, > - BRIDGE, VARARGS, NATIVE, > - ABSTRACT, STRICT, SYNTHETIC)), > - entry(Location.INNER_CLASS, > - Set.of(PUBLIC, PRIVATE, PROTECTED, > - STATIC, FINAL, INTERFACE, ABSTRACT, > - SYNTHETIC, ANNOTATION, ENUM)), > - entry(Location.METHOD_PARAMETER, > - Set.of(FINAL, SYNTHETIC, MANDATED)), > - entry(Location.MODULE, > - Set.of(OPEN, SYNTHETIC, MANDATED)), > - entry(Location.MODULE_REQUIRES, > - Set.of(TRANSITIVE, STATIC_PHASE, SYNTHETIC, MANDATED)), > - entry(Location.MODULE_EXPORTS, > - Set.of(SYNTHETIC, MANDATED)), > - entry(Location.MODULE_OPENS, > - Set.of(SYNTHETIC, MANDATED))); > + private static final Map> MAP = > + new EnumMap<>(Location.class); > } > } @plevart In?your?code, you?might?want to?avoid?allocating a?new?`Function`?instance for?every?call of?`LocationToFlags.MAP.computeIfAbsent(?)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From serb at openjdk.java.net Tue Mar 8 09:24:08 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 8 Mar 2022 09:24:08 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 src/java.desktop/unix/native/common/awt/fontpath.c line 938: > 936: while ((cnt < max) && (cacheDir = (*FcStrListNext)(cacheDirs))) { > 937: jstr = (*env)->NewStringUTF(env, (const char*)cacheDir); > 938: JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs)); I think you do not need to create an additional macro here, just inline it and call "(*FcStrListDone)(cacheDirs);" directly. Something like: if (IS_NULL(jstr) { (*FcStrListDone)(cacheDirs); return; } Note that the "IS_NULL" is used in this file after NewStringUTF. Any objections? src/java.desktop/unix/native/common/awt/fontpath.c line 940: > 938: JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs)); > 939: > 940: (*env)->SetObjectArrayElement(env, cacheDirArray, cnt++, jstr); Probably we should add the check+cleanup after the SetObjectArrayElement? Otherwise, we may call NewStringUTF while an exception is raised by the SetObjectArrayElement. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From jpai at openjdk.java.net Tue Mar 8 10:57:25 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 8 Mar 2022 10:57:25 GMT Subject: RFR: 8282572: EnumSet should be a sealed class Message-ID: Can I please get a review of this change which proposes to implement the enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any sub-classes of their own. In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` and `RegularEnumSet` are the two permitted sub classes. Both of these sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for these 2 sub-classes was an option too. But I decided to start with the more restrictive option since we don't have any other sub-classes and if and when we do have their sub-classes, it's possible to change them to `non-sealed`. The `EnumSet` class implements the `java.io.Serializable` interface. As part of this change, manual tests have been run to make sure that changing this class to `sealed` and marking the sub-classes as `final` don't break any serialization/deserialization semantics, across Java version and/or user application versions. `tier1` testing across various platforms is currently in progress. ------------- Commit messages: - 8282572: EnumSet should be a sealed class Changes: https://git.openjdk.java.net/jdk/pull/7741/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7741&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282572 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7741.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7741/head:pull/7741 PR: https://git.openjdk.java.net/jdk/pull/7741 From lancea at openjdk.java.net Tue Mar 8 11:24:14 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Mar 2022 11:24:14 GMT Subject: RFR: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. [v4] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 04:23:43 GMT, Ian Graves wrote: >> Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Adding back some missing CANON_EQ flags Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7466 From sundar at openjdk.java.net Tue Mar 8 11:48:10 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 8 Mar 2022 11:48:10 GMT Subject: RFR: 8282572: EnumSet should be a sealed class In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 10:50:35 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to implement the enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? > > The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any sub-classes of their own. > > In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` and `RegularEnumSet` are the two permitted sub classes. Both of these sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for these 2 sub-classes was an option too. But I decided to start with the more restrictive option since we don't have any other sub-classes and if and when we do have their sub-classes, it's possible to change them to `non-sealed`. > > The `EnumSet` class implements the `java.io.Serializable` interface. As part of this change, manual tests have been run to make sure that changing this class to `sealed` and marking the sub-classes as `final` don't break any serialization/deserialization semantics, across Java version and/or user application versions. > > `tier1` testing across various platforms is currently in progress. Do we need a CSR as a public class is changed from non-sealed to sealed? (Although the constructor has been package-private and hence it will not affect any non-dk code as noted by Jaikiran via private conversation. Only reflection will be able to see the difference of non-sealed to sealed change). ------------- PR: https://git.openjdk.java.net/jdk/pull/7741 From lancea at openjdk.java.net Tue Mar 8 11:50:04 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Mar 2022 11:50:04 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS In-Reply-To: References: Message-ID: On Fri, 18 Feb 2022 19:47:09 GMT, Ian Graves wrote: > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters Have not gone through the javadoc changes in detail yet but plan to, only scanned it just now On a quick skim of the test, it could use some TLC which you might consider doing now or later. It would be really good for future maintainers if there was a comment which introduced each test as to what it was trying to exercise (not just a bug number). Same with some of the private helper methods. You probably want to include your bug number in the @bug declaration which starts on line 27 test/jdk/java/util/regex/RegExTest.java line 4557: > 4555: > 4556: //This test is for 8264160 > 4557: public static void wordBoundaryInconsistencies() { There should be an `@Test` I believe as unless I missed it, this method is not called anywhere else ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From lancea at openjdk.java.net Tue Mar 8 11:56:00 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Mar 2022 11:56:00 GMT Subject: RFR: 8282572: EnumSet should be a sealed class In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 11:45:13 GMT, Athijegannathan Sundararajan wrote: > Do we need a CSR as a public class is changed from non-sealed to sealed? > > (Although the constructor has been package-private and hence it will not affect any non-dk code as noted by Jaikiran via private conversation. Only reflection will be able to see the difference of non-sealed to sealed change). Yes there should be a CSR(see: https://bugs.openjdk.java.net/browse/JDK-8282131 as an example) for this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7741 From dholmes at openjdk.java.net Tue Mar 8 12:23:57 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Mar 2022 12:23:57 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 09:20:19 GMT, Sergey Bylokhov wrote: >> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` >> >> Test: >> >> - [x] jdk_desktop on Linux x86_64 > > src/java.desktop/unix/native/common/awt/fontpath.c line 940: > >> 938: JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs)); >> 939: >> 940: (*env)->SetObjectArrayElement(env, cacheDirArray, cnt++, jstr); > > Probably we should add the check+cleanup after the SetObjectArrayElement? Otherwise, we may call NewStringUTF while an exception is raised by the SetObjectArrayElement. ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From dholmes at openjdk.java.net Tue Mar 8 12:34:06 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 8 Mar 2022 12:34:06 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 09:18:01 GMT, Sergey Bylokhov wrote: >> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` >> >> Test: >> >> - [x] jdk_desktop on Linux x86_64 > > src/java.desktop/unix/native/common/awt/fontpath.c line 938: > >> 936: while ((cnt < max) && (cacheDir = (*FcStrListNext)(cacheDirs))) { >> 937: jstr = (*env)->NewStringUTF(env, (const char*)cacheDir); >> 938: JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs)); > > I think you do not need to create an additional macro here, just inline it and call "(*FcStrListDone)(cacheDirs);" directly. Something like: > > if (IS_NULL(jstr) { > (*FcStrListDone)(cacheDirs); > return; > } > > Note that the "IS_NULL" is used in this file after NewStringUTF. Any objections? Good catch! Elsewhere in this file IS_NULL is always used to check NewStringUTF, so the existing code was inconsistent in checking for a pending exception. Checking for NULL and checking for a pending exception are logically equivalent as long as the passed in pointer is not NULL. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From duke at openjdk.java.net Tue Mar 8 12:36:58 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 8 Mar 2022 12:36:58 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com> References: <5rD36eq_-TWuXrSn0wSLTK9pRhPeN10fYvOPIAEyMX0=.759b18cb-687c-4a7f-97ea-20a06e8dc436@github.com> Message-ID: On Mon, 7 Mar 2022 16:06:44 GMT, Claes Redestad wrote: > Notice list.of will have the downside of copying the input array when the size is not small while arrays aslist does not. Is the tradeoff worth it? Good point, I see risky changes in this PR: - `ProxyGenerator` - `Proxy` - `MethodType` - `FileTreeIterator` As of `ProxyGenerator.ProxyMethod` at start-up time of my Spring Boot -based application there are 2696 invocations of `ProxyGenerator.ProxyMethod.generateMethod()` and 0 of them was for `exceptionTypes.length > 2`. This is expectable as the majority of the methods declare either 0, or 1-2 exceptions. As of `Proxy.getProxyConstructor()` in my application I have 1417 invocations of `List.of()` and 599 of them are with `intfsArray.length > 2`. There were no invocations of `Proxy.defaultMethodHandle()` so I have no statistics. For `MethodType` there were 0 invocations, and I have no statistics, but as of my experience most of the methods have 0-2 parameters. In case of `FileTreeIterator` incoming vararg is always of length either 0 or 1, as `FileVisitOption` enum has only one item. So I suggest to apply something like `intfsArray.length < 2 ? List.of(intfsArray) : Arrays.asList(intfsArray)` keeping the rest of the code as is. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From jpai at openjdk.java.net Tue Mar 8 12:57:01 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 8 Mar 2022 12:57:01 GMT Subject: RFR: 8282572: EnumSet should be a sealed class In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 10:50:35 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to implement the enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? > > The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any sub-classes of their own. > > In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` and `RegularEnumSet` are the two permitted sub classes. Both of these sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for these 2 sub-classes was an option too. But I decided to start with the more restrictive option since we don't have any other sub-classes and if and when we do have their sub-classes, it's possible to change them to `non-sealed`. > > The `EnumSet` class implements the `java.io.Serializable` interface. As part of this change, manual tests have been run to make sure that changing this class to `sealed` and marking the sub-classes as `final` don't break any serialization/deserialization semantics, across Java version and/or user application versions. > > `tier1` testing across various platforms is currently in progress. I've created the CSR here https://bugs.openjdk.java.net/browse/JDK-8282795 ------------- PR: https://git.openjdk.java.net/jdk/pull/7741 From jlaskey at openjdk.java.net Tue Mar 8 13:09:36 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 13:09:36 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v8] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add unit test for DecimalFormatSymbols.getLocale() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/89354a0e..d1879a7a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=06-07 Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Tue Mar 8 13:19:39 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 13:19:39 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v9] In-Reply-To: References: Message-ID: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com> > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Correct indentation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/d1879a7a..dfcc1ec2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Tue Mar 8 13:19:42 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 13:19:42 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v7] In-Reply-To: References: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> Message-ID: On Tue, 8 Mar 2022 05:01:56 GMT, Jaikiran Pai wrote: >> Jim Laskey has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add comment about DecimalFormatSymbols being mutable objects. >> - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." >> >> This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. >> - Revert "Drop DecimalFormatSymbols.getLocale change" >> >> This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. >> - Revert "Correct caching test" >> >> This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. > > src/java.base/share/classes/java/util/Formatter.java line 2019: > >> 2017: return dfs; >> 2018: } >> 2019: // Fetch a new local instance of DecimalFormatSymbols. Note that DFS are mutatble > > Thank you Jim for these comments about multi-threaded access. Looks good to me. > One minor typo on this line - "mutatble" should have been "mutable". Noted ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Tue Mar 8 13:19:44 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 13:19:44 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v7] In-Reply-To: References: <05KmMblunBhtSlExDjDal0WjUsrSVL0YdfTh_MnV93E=.14df93ca-09c9-4241-9f85-23f305676453@github.com> Message-ID: <0HER9ZjhBSGPwEVG5ztPz9Uxk3lPxWbs2c3IFtxsboo=.890bd855-4c76-4fea-9596-a31bd92625df@github.com> On Mon, 7 Mar 2022 21:24:32 GMT, Roger Riggs wrote: >> Jim Laskey has updated the pull request incrementally with four additional commits since the last revision: >> >> - Add comment about DecimalFormatSymbols being mutable objects. >> - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." >> >> This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. >> - Revert "Drop DecimalFormatSymbols.getLocale change" >> >> This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. >> - Revert "Correct caching test" >> >> This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. > > src/java.base/share/classes/java/util/Formatter.java line 4550: > >> 4548: >> 4549: if (l == null || l.equals(Locale.US)) { >> 4550: grpSize = 3; > > unintentional indentation Noted ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Tue Mar 8 13:29:08 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 13:29:08 GMT Subject: Integrated: JDK-8282144 RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 14:47:50 GMT, Jim Laskey wrote: > Class: ./java.base/share/classes/jdk/internal/util/random/RandomSupport.java > Method: public static long[] convertSeedBytesToLongs(byte[] seed, int n, int z) > > The method attempts to create an array of longs by consuming the input bytes most significant bit first. New bytes are appended to the existing long using the OR operator on the signed byte. Due to sign extension this will overwrite all the existing bits from 63 to 8 if the next byte is negative. This pull request has now been integrated. Changeset: 5fab27e1 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/5fab27e1b8fdf2ea27cb3b349bd339a4a6ec828b Stats: 72 lines in 2 files changed: 71 ins; 0 del; 1 mod 8282144: RandomSupport.convertSeedBytesToLongs sign extension overwrites previous bytes Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7614 From aivanov at openjdk.java.net Tue Mar 8 13:40:57 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 8 Mar 2022 13:40:57 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 12:20:38 GMT, David Holmes wrote: >> src/java.desktop/unix/native/common/awt/fontpath.c line 940: >> >>> 938: JNU_CHECK_EXCEPTION_AND_CLEANUP(env, (*FcStrListDone)(cacheDirs)); >>> 939: >>> 940: (*env)->SetObjectArrayElement(env, cacheDirArray, cnt++, jstr); >> >> Probably we should add the check+cleanup after the SetObjectArrayElement? Otherwise, we may call NewStringUTF while an exception is raised by the SetObjectArrayElement. > > ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds. Can `SetObjectElementArray` raise an exception? The index is within the array length and we store a string. I assume `cacheDirArray` is a string array. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From redestad at openjdk.java.net Tue Mar 8 13:54:02 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Mar 2022 13:54:02 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v11] In-Reply-To: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com> References: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com> Message-ID: On Mon, 7 Mar 2022 23:13:36 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - use 32-bit mask to calculate correct remainder value > - ary1 not required to have USE_KILL effect aarch64: https://jmh.morethan.io/?gists=281ac3c29ef85f9f64c0440cd7f8c247,0a2c7d3b803f9cd5799f6af95eb6a90a Brings decent gains on the "sunshine case" and the mixed microbenchmarks, but there are a few glaring exceptions which I'm still investigating. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From jlaskey at openjdk.java.net Tue Mar 8 14:11:39 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 14:11:39 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier Message-ID: We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. See JBS for details. ------------- Commit messages: - Introduce java.lang.runtime.Carrier Changes: https://git.openjdk.java.net/jdk/pull/7744/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282798 Stats: 1085 lines in 2 files changed: 1085 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From ihse at openjdk.java.net Tue Mar 8 14:08:10 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 8 Mar 2022 14:08:10 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v4] In-Reply-To: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com> References: <1BNjh6K5tsRX1r4E_VWIW2VhkJOP8kfqIb9H_ixmBEs=.fd300f48-ec19-4d26-8e02-7138eb0a816e@github.com> Message-ID: On Thu, 3 Mar 2022 16:55:46 GMT, Tim Prinzing wrote: >> The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. >> >> The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: >> >> final ClassLoader loader = (caller != null) ? >> caller.getClassLoader() : getLoader(getCallerModule(caller)); >> >> A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. >> >> The javadoc was updated for the caller sensitive methods changed. > > Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision: > > more suggested changes Build changes look good. Can't say anything about the rest. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7663 From duke at openjdk.java.net Tue Mar 8 14:35:12 2022 From: duke at openjdk.java.net (liach) Date: Tue, 8 Mar 2022 14:35:12 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption In-Reply-To: References: Message-ID: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? wrote: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null Calling `Arrays.asList` vs `List.of` on a switch on the array length seems like an overkill for such a simple thing. Imo the safest changes are where we know the input array length is going to be 1 or 2. src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70: > 68: throws IOException > 69: { > 70: this.walker = new FileTreeWalker(List.of(options), maxDepth); Relates to https://bugs.openjdk.java.net/browse/JDK-8145048 src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java line 79: > 77: containerBeforeContainee(annotations, annoClass); > 78: > 79: result.addAll((indirectFirst ? 0 : 1), List.of(indirect)); This `indirect` is most likely to be of size > 2 ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From forax at univ-mlv.fr Tue Mar 8 15:04:21 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 8 Mar 2022 16:04:21 +0100 (CET) Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: <733963846.13126867.1646751861690.JavaMail.zimbra@u-pem.fr> Hi Jim, I believe that there is a mismatch about what is needed for the pattern matching and the API you propose. The Carrier API allows to map one tuple of types to one storage representation based on ints, longs and references. But what we need is to have several shapes for the same storage, mapping is not one to one but many to one, more like how unions are mapped in C. For a switch, if we have several cases, each one need it's own shape to store the bindings but at the same time we also need one field to be the same for all shapes (the field of type int indicating which case match) so one storage but many shapes. R?mi ----- Original Message ----- > From: "Jim Laskey" > To: "core-libs-dev" > Sent: Tuesday, March 8, 2022 3:11:39 PM > Subject: RFR: JDK-8282798 java.lang.runtime.Carrier > We propose to provide a runtime anonymous carrier class object generator; > java.lang.runtime.Carrier. This generator class is designed to share anonymous > classes when shapes are similar. For example, if several clients require > objects containing two integer fields, then Carrier will ensure that each > client generates carrier objects using the same underlying anonymous class. > > See JBS for details. > > ------------- > > Commit messages: > - Introduce java.lang.runtime.Carrier > > Changes: https://git.openjdk.java.net/jdk/pull/7744/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8282798 > Stats: 1085 lines in 2 files changed: 1085 ins; 0 del; 0 mod > Patch: https://git.openjdk.java.net/jdk/pull/7744.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 > > PR: https://git.openjdk.java.net/jdk/pull/7744 From redestad at openjdk.java.net Tue Mar 8 15:18:04 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Mar 2022 15:18:04 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks An awkward effect of this implementation is that it perturbs results on small Strings a bit. Adding a branch in the trivial case, but also regressing on certain lengths (try size=7). The added complexity seem to be no issue for JITs in these microbenchmarks, but I worry that the increased code size might play tricks with inlining heuristics in real applications. After chatting a bit with @richardstartin regarding the observation that preventing a strength reduction on the constant 31 value being part of the improvement I devised an experiment which simply makes the 31 non-constant as to disable the strength reduction: private static int base = 31; @Benchmark public int scalarLatin1_NoStrengthReduction() { int h = 0; int i = 0, len = latin1.length; for (; i < len; i++) { h = base * h + (latin1[i] & 0xff); } return h; } Interestingly results of that get planted in the middle of the baseline on large inputs, while avoiding most of the irregularities on small inputs compared to manually unrolled versions: Benchmark (size) Mode Cnt Score Error Units StringHashCode.Algorithm.scalarLatin1 1 avgt 3 2.910 ? 0.068 ns/op StringHashCode.Algorithm.scalarLatin1 7 avgt 3 6.530 ? 0.065 ns/op StringHashCode.Algorithm.scalarLatin1 8 avgt 3 7.472 ? 0.034 ns/op StringHashCode.Algorithm.scalarLatin1 15 avgt 3 12.750 ? 0.028 ns/op StringHashCode.Algorithm.scalarLatin1 100 avgt 3 99.190 ? 0.618 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 3 3.119 ? 0.015 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled16 7 avgt 3 11.556 ? 4.690 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled16 8 avgt 3 7.740 ? 0.005 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled16 15 avgt 3 13.030 ? 0.124 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 3 46.470 ? 0.496 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 3 3.123 ? 0.057 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled8 7 avgt 3 11.380 ? 0.085 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled8 8 avgt 3 5.849 ? 0.583 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled8 15 avgt 3 12.312 ? 0.025 ns/op StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 3 45.751 ? 0.146 ns/op StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 1 avgt 3 3.173 ? 0.015 ns/op StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 7 avgt 3 5.229 ? 0.455 ns/op StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 8 avgt 3 5.679 ? 0.012 ns/op StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 15 avgt 3 8.731 ? 0.103 ns/op StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 100 avgt 3 70.954 ? 3.386 ns/op I wonder if this might be a safer play while we investigate intrinsification and other possible enhancements? ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From brian.goetz at oracle.com Tue Mar 8 15:37:41 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 8 Mar 2022 15:37:41 +0000 Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: <733963846.13126867.1646751861690.JavaMail.zimbra@u-pem.fr> References: <733963846.13126867.1646751861690.JavaMail.zimbra@u-pem.fr> Message-ID: <9C1AC73E-C677-486E-967A-5EFEF15D21C8@oracle.com> You keep saying ?what we need?. But really, what I think you mean is ?what the scheme I have in mind needs.? Can we try and separate these out? I don?t think any of these are *needed*, but maybe you want to make the argument that you have a better scheme in mind, and we should choose that scheme, and therefore then we might need them. > On Mar 8, 2022, at 10:04 AM, Remi Forax wrote: > > Hi Jim, > I believe that there is a mismatch about what is needed for the pattern matching and the API you propose. > The Carrier API allows to map one tuple of types to one storage representation based on ints, longs and references. > > But what we need is to have several shapes for the same storage, mapping is not one to one but many to one, more like how unions are mapped in C. > For a switch, if we have several cases, each one need it's own shape to store the bindings but at the same time we also need one field to be the same for all shapes (the field of type int indicating which case match) so one storage but many shapes. > > R?mi > > ----- Original Message ----- >> From: "Jim Laskey" >> To: "core-libs-dev" >> Sent: Tuesday, March 8, 2022 3:11:39 PM >> Subject: RFR: JDK-8282798 java.lang.runtime.Carrier > >> We propose to provide a runtime anonymous carrier class object generator; >> java.lang.runtime.Carrier. This generator class is designed to share anonymous >> classes when shapes are similar. For example, if several clients require >> objects containing two integer fields, then Carrier will ensure that each >> client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. >> >> ------------- >> >> Commit messages: >> - Introduce java.lang.runtime.Carrier >> >> Changes: https://git.openjdk.java.net/jdk/pull/7744/files >> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8282798 >> Stats: 1085 lines in 2 files changed: 1085 ins; 0 del; 0 mod >> Patch: https://git.openjdk.java.net/jdk/pull/7744.diff >> Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 >> >> PR: https://git.openjdk.java.net/jdk/pull/7744 From duke at openjdk.java.net Tue Mar 8 15:39:10 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 8 Mar 2022 15:39:10 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks Can we change the optimizer so that the strength reduction happens only after all transformations have settled? Carelessly changing a multiplication to a shift as today may hurt a lot of potential optimisations. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From zgu at openjdk.java.net Tue Mar 8 15:38:06 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 8 Mar 2022 15:38:06 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 13:25:12 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 > > > The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code. > > That's to allow for general use by C or C++ source files. But you are only needing this in a C source file so you would only need the C variant of the calling syntax. > > The macros are used to hide the different syntax of c and c++ to avoid polluting code here, it seems to be a common pattern in client code. > > That's to allow for general use by C or C++ source files. But you are only needing this in a C source file so you would only need the C variant of the calling syntax. I don't like the macros. I can argument all `JNU_CHECK_EXCEPTION(_RETURN)` macros are particular bad, because these patterns can easily result premature returns without proper cleanup. This bug is an evidence. But they exist for a long time, and I just follow the convention :-( I would prefer to eliminate them all, as inline code is not big at all. I did a quick grep, there are a few suspicious spots, e.g. [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711](url), I have yet take a close look. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From zgu at openjdk.java.net Tue Mar 8 15:54:45 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 8 Mar 2022 15:54:45 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: > Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` > > Test: > > - [x] jdk_desktop on Linux x86_64 Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: mrserb and aivanov-jdk's comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7691/files - new: https://git.openjdk.java.net/jdk/pull/7691/files/0ff07ddd..c4a3ec87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7691&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7691&range=00-01 Stats: 23 lines in 2 files changed: 2 ins; 18 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7691.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7691/head:pull/7691 PR: https://git.openjdk.java.net/jdk/pull/7691 From aivanov at openjdk.java.net Tue Mar 8 16:02:03 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 8 Mar 2022 16:02:03 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu wrote: >> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` >> >> Test: >> >> - [x] jdk_desktop on Linux x86_64 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > mrserb and aivanov-jdk's comments > I did a quick grep, there are a few suspicious spots, e.g. [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711](url), I have yet take a close look. It doesn't leak the icon handle here, it's assigned to the member of the object (probably `NULL`). Yet it's inconsistent: if an exception is expected from `CreateIconFromRaster` on the line above, why isn't it checked after `CreateIconFromRaster` is called on the following line? ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From mcimadamore at openjdk.java.net Tue Mar 8 16:04:05 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 8 Mar 2022 16:04:05 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: <2nZrjxn2EiFVB-ffQ_zCA4-5UebHlZyaxB068Vy2NHs=.22965292-5657-41fc-a0b1-0d1fd3331698@github.com> On Tue, 8 Mar 2022 15:49:46 GMT, Maurizio Cimadamore wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 432: > >> 430: * Construct a new object carrier class based on shape. >> 431: * >> 432: * @param carrierShape shape of carrier > > Suggestion: > > * @param carrierShape shape of carrier I see all `@param` tags have double space. If that's deliberate that's ok. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From mcimadamore at openjdk.java.net Tue Mar 8 16:04:05 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 8 Mar 2022 16:04:05 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 14:02:39 GMT, Jim Laskey wrote: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Looks good. I've left some minor doc-related comments. When reading (as discussed online) I wondered if using Unsafe to access values inside a byte[] or Object[] would simplify the carrier implementation somehow. src/java.base/share/classes/java/lang/runtime/Carrier.java line 48: > 46: > 47: /** > 48: * This class is used to create objects that have number and types of The class javadoc seems a bit on the thin side. I would say something on the fact that the shape of the carrier is determined by a MethodType, etc, and add an example to illustrate basic usage. src/java.base/share/classes/java/lang/runtime/Carrier.java line 129: > 127: > 128: /** > 129: * Factory for array based carrier. Array wrapped in object to provide I found this comment hard to parse - or unhelpful to understand how the factory really worked. IIUC, this factory captures all parameters into an Object[] (using a collector MH) and returns that Object[] (which acts as the carrier object). I'm not sure I see anything here that would prevent the user from building a carrier and casting to Object[] ? src/java.base/share/classes/java/lang/runtime/Carrier.java line 432: > 430: * Construct a new object carrier class based on shape. > 431: * > 432: * @param carrierShape shape of carrier Suggestion: * @param carrierShape shape of carrier src/java.base/share/classes/java/lang/runtime/Carrier.java line 633: > 631: * getter. > 632: * > 633: * @param i index of component to get Suggestion: * @param i index of component to get src/java.base/share/classes/java/lang/runtime/Carrier.java line 656: > 654: > 655: /** > 656: * Find or create carrier class for a carrioer shape. Suggestion: * Find or create carrier class for a carrier shape. src/java.base/share/classes/java/lang/runtime/Carrier.java line 852: > 850: * @throws IllegalArgumentException if number of component slots exceeds maximum > 851: */ > 852: public static MethodHandle constructor(MethodType methodType) { What happens to the methodType return type? (both here and in the components method). Should javadoc say anything? ------------- Marked as reviewed by mcimadamore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7744 From igraves at openjdk.java.net Tue Mar 8 16:36:08 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 16:36:08 GMT Subject: Integrated: 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 19:54:00 GMT, Ian Graves wrote: > Fixing a bug in `NFCCharProperty` where code falling through an if-statement can prematurely set the matcher's `hitEnd` field to true. This pull request has now been integrated. Changeset: 3fc009be Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/3fc009be8a49f9edb8059d8612ef6ed7f048f242 Stats: 29 lines in 2 files changed: 27 ins; 2 del; 0 mod 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. Reviewed-by: rriggs, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7466 From psandoz at openjdk.java.net Tue Mar 8 16:47:02 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 8 Mar 2022 16:47:02 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:13:46 GMT, Claes Redestad wrote: >> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UTF-16 benchmarks > > An awkward effect of this implementation is that it perturbs results on small Strings a bit. Adding a branch in the trivial case, but also regressing on certain lengths (try size=7). The added complexity seem to be no issue for JITs in these microbenchmarks, but I worry that the increased code size might play tricks with inlining heuristics in real applications. > > After chatting a bit with @richardstartin regarding the observation that preventing a strength reduction on the constant 31 value being part of the improvement I devised an experiment which simply makes the 31 non-constant as to disable the strength reduction: > > private static int base = 31; > @Benchmark > public int scalarLatin1_NoStrengthReduction() { > int h = 0; > int i = 0, len = latin1.length; > for (; i < len; i++) { > h = base * h + (latin1[i] & 0xff); > } > return h; > } > > Interestingly results of that get planted in the middle of the baseline on large inputs, while avoiding most of the irregularities on small inputs compared to manually unrolled versions: > > Benchmark (size) Mode Cnt Score Error Units > StringHashCode.Algorithm.scalarLatin1 1 avgt 3 2.910 ? 0.068 ns/op > StringHashCode.Algorithm.scalarLatin1 7 avgt 3 6.530 ? 0.065 ns/op > StringHashCode.Algorithm.scalarLatin1 8 avgt 3 7.472 ? 0.034 ns/op > StringHashCode.Algorithm.scalarLatin1 15 avgt 3 12.750 ? 0.028 ns/op > StringHashCode.Algorithm.scalarLatin1 100 avgt 3 99.190 ? 0.618 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 3 3.119 ? 0.015 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 7 avgt 3 11.556 ? 4.690 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 8 avgt 3 7.740 ? 0.005 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 15 avgt 3 13.030 ? 0.124 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 3 46.470 ? 0.496 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 3 3.123 ? 0.057 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 7 avgt 3 11.380 ? 0.085 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 8 avgt 3 5.849 ? 0.583 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 15 avgt 3 12.312 ? 0.025 ns/op > StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 3 45.751 ? 0.146 ns/op > StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 1 avgt 3 3.173 ? 0.015 ns/op > StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 7 avgt 3 5.229 ? 0.455 ns/op > StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 8 avgt 3 5.679 ? 0.012 ns/op > StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 15 avgt 3 8.731 ? 0.103 ns/op > StringHashCode.Algorithm.scalarLatin1_NoStrengthReduction 100 avgt 3 70.954 ? 3.386 ns/op > > I wonder if this might be a safer play while we investigate intrinsification and other possible enhancements? @cl4es Yes, we would need to carefully measure the impact for small array sizes (similar to what we had to do when the array mismatch intrinsic was implemented and applied to array equals). My sense is to focus on the intrinsic and also look for potential opportunities like @merykitty points out, as that is where the larger impact is, although it is more work! ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From jrose at openjdk.java.net Tue Mar 8 16:55:00 2022 From: jrose at openjdk.java.net (John R Rose) Date: Tue, 8 Mar 2022 16:55:00 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:59:59 GMT, Maurizio Cimadamore wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 48: > >> 46: >> 47: /** >> 48: * This class is used to create objects that have number and types of > > The class javadoc seems a bit on the thin side. I would say something on the fact that the shape of the carrier is determined by a MethodType, etc, and add an example to illustrate basic usage. Agreed. Also, this class is unusual in that it is not instantiated; like `Arrays` or `Collections` it is a (small) bundle of static factories (or are they algorithms?). I think as such it should be called `Carriers`. I'm slightly surprised the MH factories are not factored through a metaobject of the form record CarrierBinding( MethodType methodType, MethodHandle constructor, List> componentTypes, List components) { ? } The presupposition here, I suppose, is that carriers will only be used by condy or similar quasi-statically configured clients, so having the multiple lookups through a hidden table is no burden, and the clients can always keep the associations correct (between constructors and various component accessors). **But** if I were to use carriers to manage intermediate structures in (say) a serialization package (for instance) I would need to make my own records like the above for my own bookkeeping, and I would be slightly miffed that the Carrier API insisted on doing a de-novo lookup twice on each MT key (to say nothing of me having to create the MT key first). **And** if I were to use carriers in that way (away from condy), **then** I would want to skip the step of building the MethodType, and wish for a factory method for CarrierBinding instances that took a plain List, as well as a factory method that took the MethodType (which is convenient for condy). BTW, it would be normal to give the name `Carrier` (which is a good name BTW) to the record type that embodies the group of method handles, so `record Carrier(?constructor?components?) {?factories?}`. I suppose stuff like this could be added later. But it's worth considering now, simply because there is an early decision point between a class named `Carrier` and a static-only class named `Carriers`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From igraves at openjdk.java.net Tue Mar 8 16:58:36 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 16:58:36 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v2] In-Reply-To: References: Message-ID: > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Bug id's to header and some other cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7539/files - new: https://git.openjdk.java.net/jdk/pull/7539/files/7177ac44..b0e98fab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7539/head:pull/7539 PR: https://git.openjdk.java.net/jdk/pull/7539 From redestad at openjdk.java.net Tue Mar 8 17:04:00 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Mar 2022 17:04:00 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:36:22 GMT, Quan Anh Mai wrote: > Can we change the optimizer so that the strength reduction happens only after all transformations have settled? Carelessly changing a multiplication to a shift as today may hurt a lot of potential optimisations. Thanks. Yes, it's troubling that making a constant non-foldable can lead the JIT down a path that ultimately pessimizes the end result (as observed here). If we could train the JIT to avoid this pitfall and get to the improvement observed in my experiment here without any changes to `String.java` then that'd be great. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From redestad at openjdk.java.net Tue Mar 8 17:11:00 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 8 Mar 2022 17:11:00 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: <09Y4yqHXagErs9xsjNeoajWf_BNFhQa4FYAcScfbj0U=.a1307e83-564a-4a76-a65c-d4e29234e90a@github.com> On Tue, 8 Mar 2022 17:01:09 GMT, Claes Redestad wrote: >> Can we change the optimizer so that the strength reduction happens only after all transformations have settled? Carelessly changing a multiplication to a shift as today may hurt a lot of potential optimisations. >> Thanks. > >> Can we change the optimizer so that the strength reduction happens only after all transformations have settled? Carelessly changing a multiplication to a shift as today may hurt a lot of potential optimisations. Thanks. > > Yes, it's troubling that making a constant non-foldable can lead the JIT down a path that ultimately pessimizes the end result (as observed here). If we could train the JIT to avoid this pitfall and get to the improvement observed in my experiment here without any changes to `String.java` then that'd be great. > @cl4es Yes, we would need to carefully measure the impact for small array sizes (similar to what we had to do when the array mismatch intrinsic was implemented and applied to array equals). My sense is to focus on the intrinsic and also look for potential opportunities like @merykitty points out, as that is where the larger impact is, although it is more work! Right, I'm not too thrilled about the prospect of moving ahead with the de-constantification as an alternative patch here. It's such a crutch, but it's also simple and has no obvious downsides as of right now. I think it was a useful experiment to see where some of the gain observed in the unroll might be coming from. The degradation on many smaller `Strings` in the unrolled versions is a concern that I think might be a blocker, though. Short Strings are excessively common as keys in hash maps et.c.. Feels like none of the alternatives seen here so far is really _it_. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From naoto at openjdk.java.net Tue Mar 8 17:11:10 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 8 Mar 2022 17:11:10 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v9] In-Reply-To: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com> References: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com> Message-ID: On Tue, 8 Mar 2022 13:19:39 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Correct indentation Looks good. Thanks for adding the tests. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7703 From igraves at openjdk.java.net Tue Mar 8 17:19:14 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 8 Mar 2022 17:19:14 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v3] In-Reply-To: References: Message-ID: > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' of https://github.com/openjdk/jdk into bug-8264160 - Bug id's to header and some other cleanup - Fixing bad javadoc - Merge remote-tracking branch 'upstream/master' into bug-8264160 - Updating spec - Proposed change for \b metacharacter ------------- Changes: https://git.openjdk.java.net/jdk/pull/7539/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=02 Stats: 79 lines in 2 files changed: 61 ins; 6 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7539/head:pull/7539 PR: https://git.openjdk.java.net/jdk/pull/7539 From rriggs at openjdk.java.net Tue Mar 8 17:22:10 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 8 Mar 2022 17:22:10 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v9] In-Reply-To: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com> References: <8M2xTtlccDjOlndrZ4WPe4hZrcNFVlKuDluLqz0x7Rw=.3700a098-624c-438f-95c6-8a44553813d9@github.com> Message-ID: On Tue, 8 Mar 2022 13:19:39 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Correct indentation Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From forax at univ-mlv.fr Tue Mar 8 17:28:13 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 8 Mar 2022 18:28:13 +0100 (CET) Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: <1543657756.13221183.1646760493504.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "John R Rose" > To: "core-libs-dev" > Sent: Tuesday, March 8, 2022 5:55:00 PM > Subject: Re: RFR: JDK-8282798 java.lang.runtime.Carrier > On Tue, 8 Mar 2022 15:59:59 GMT, Maurizio Cimadamore > wrote: > >>> We propose to provide a runtime anonymous carrier class object generator; >>> java.lang.runtime.Carrier. This generator class is designed to share anonymous >>> classes when shapes are similar. For example, if several clients require >>> objects containing two integer fields, then Carrier will ensure that each >>> client generates carrier objects using the same underlying anonymous class. >>> >>> See JBS for details. >> >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 48: >> >>> 46: >>> 47: /** >>> 48: * This class is used to create objects that have number and types of >> >> The class javadoc seems a bit on the thin side. I would say something on the >> fact that the shape of the carrier is determined by a MethodType, etc, and add >> an example to illustrate basic usage. > > Agreed. Also, this class is unusual in that it is not instantiated; like > `Arrays` or `Collections` it is a (small) bundle of static factories (or are > they algorithms?). I think as such it should be called `Carriers`. > > I'm slightly surprised the MH factories are not factored through a metaobject of > the form > > record CarrierBinding( > MethodType methodType, > MethodHandle constructor, > List> componentTypes, > List components) > { ? } Yes, i've done something very similar https://github.com/forax/switch-carrier/blob/master/src/main/java/com/github/forax/carrier/java/lang/runtime/Patterns.java#L172 Note that constructor.type() == methodType and constructor.parameterList() == componenetTypes, so the record can be reduced to a tuple (constructor / components). > > > The presupposition here, I suppose, is that carriers will only be used by condy > or similar quasi-statically configured clients, so having the multiple lookups > through a hidden table is no burden, and the clients can always keep the > associations correct (between constructors and various component accessors). > > **But** if I were to use carriers to manage intermediate structures in (say) a > serialization package (for instance) I would need to make my own records like > the above for my own bookkeeping, and I would be slightly miffed that the > Carrier API insisted on doing a de-novo lookup twice on each MT key (to say > nothing of me having to create the MT key first). It depends if you want to use the same carrier for several cases or not. > > **And** if I were to use carriers in that way (away from condy), **then** I > would want to skip the step of building the MethodType, and wish for a factory > method for CarrierBinding instances that took a plain List, as well as a > factory method that took the MethodType (which is convenient for condy). As i said above, constructor.type() == methodType so anyway the MethodType has to be created. > > BTW, it would be normal to give the name `Carrier` (which is a good name BTW) to > the record type that embodies the group of method handles, so `record > Carrier(?constructor?components?) {?factories?}`. > > I suppose stuff like this could be added later. But it's worth considering now, > simply because there is an early decision point between a class named `Carrier` > and a static-only class named `Carriers`. R?mi From forax at univ-mlv.fr Tue Mar 8 17:32:30 2022 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 8 Mar 2022 18:32:30 +0100 (CET) Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: <9C1AC73E-C677-486E-967A-5EFEF15D21C8@oracle.com> References: <733963846.13126867.1646751861690.JavaMail.zimbra@u-pem.fr> <9C1AC73E-C677-486E-967A-5EFEF15D21C8@oracle.com> Message-ID: <715666193.13225533.1646760750437.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Brian Goetz" > To: "Remi Forax" > Cc: "Jim Laskey" , "core-libs-dev" > Sent: Tuesday, March 8, 2022 4:37:41 PM > Subject: Re: RFR: JDK-8282798 java.lang.runtime.Carrier > You keep saying ?what we need?. But really, what I think you mean is ?what the > scheme I have in mind needs.? Can we try and separate these out? I don?t > think any of these are *needed*, but maybe you want to make the argument that > you have a better scheme in mind, and we should choose that scheme, and > therefore then we might need them. I'm open to any other schemes, it would be a kind of sad if the carrier API is added to java.lang.runtime to not use it for pattern matching. So what other scheme you have in mind ? R?mi > >> On Mar 8, 2022, at 10:04 AM, Remi Forax wrote: >> >> Hi Jim, >> I believe that there is a mismatch about what is needed for the pattern matching >> and the API you propose. >> The Carrier API allows to map one tuple of types to one storage representation >> based on ints, longs and references. >> >> But what we need is to have several shapes for the same storage, mapping is not >> one to one but many to one, more like how unions are mapped in C. >> For a switch, if we have several cases, each one need it's own shape to store >> the bindings but at the same time we also need one field to be the same for all >> shapes (the field of type int indicating which case match) so one storage but >> many shapes. >> >> R?mi >> >> ----- Original Message ----- >>> From: "Jim Laskey" >>> To: "core-libs-dev" >>> Sent: Tuesday, March 8, 2022 3:11:39 PM >>> Subject: RFR: JDK-8282798 java.lang.runtime.Carrier >> >>> We propose to provide a runtime anonymous carrier class object generator; >>> java.lang.runtime.Carrier. This generator class is designed to share anonymous >>> classes when shapes are similar. For example, if several clients require >>> objects containing two integer fields, then Carrier will ensure that each >>> client generates carrier objects using the same underlying anonymous class. >>> >>> See JBS for details. >>> >>> ------------- >>> >>> Commit messages: >>> - Introduce java.lang.runtime.Carrier >>> >>> Changes: https://git.openjdk.java.net/jdk/pull/7744/files >>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=00 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8282798 >>> Stats: 1085 lines in 2 files changed: 1085 ins; 0 del; 0 mod >>> Patch: https://git.openjdk.java.net/jdk/pull/7744.diff >>> Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 >>> > >> PR: https://git.openjdk.java.net/jdk/pull/7744 From djelinski at openjdk.java.net Tue Mar 8 17:37:12 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Tue, 8 Mar 2022 17:37:12 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 23:36:41 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > make sure String(StringBuffer) is still synchronized. I could find at least 2 other cases where `AbstractStringBuilder` is initialized with UTF16 coder, `growOnly` is `true`, and the string is compressible: - the constructor that takes a `CharSequence` may be used with `AbstractStringBuilder`; it then copies the coder, but does not copy `growOnly` - the same happens in `append(AbstractStringBuilder asb)`; coder may be upgraded to UTF16 even if asb has `growOnly` = `false` As for a better name for `growOnly`, something like `mayBeLatin` would better convey the variable's purpose. What do you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From zgu at openjdk.java.net Tue Mar 8 17:52:04 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 8 Mar 2022 17:52:04 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:58:57 GMT, Alexey Ivanov wrote: > > I did a quick grep, there are a few suspicious spots, e.g. [https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711](url), I have yet take a close look. > > It doesn't leak the icon handle here, it's assigned to the member of the object (probably `NULL`). Yet it's inconsistent: if an exception is expected from `CreateIconFromRaster` on the line above, why isn't it checked after `CreateIconFromRaster` is called on the following line? I am not familiar with this code. What I see is that, it assigns `m_hIcon` and `m_hIconSm` to local variables, then reset them to `NULL`, once exception returns, are references to icon and small icon handles lost? and it will destroy icons as L2727 - 2732 do. But I may miss something. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From duke at openjdk.java.net Tue Mar 8 18:55:08 2022 From: duke at openjdk.java.net (Jens Li) Date: Tue, 8 Mar 2022 18:55:08 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 14:02:39 GMT, Jim Laskey wrote: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. test/jdk/java/lang/runtime/CarrierTest.java line 45: > 43: } > 44: > 45: static void assertTrue(boolean test, String message) { This test does not use TestNG like the other tests in the package. Is that intentional? (Please tell me if its weird that I as a total rando pops in and makes comments here!) test/jdk/java/lang/runtime/CarrierTest.java line 143: > 141: MethodHandle constructor = Carrier.constructor(methodType); > 142: } catch (IllegalArgumentException ex) { > 143: passed = true; There is `Assert.assertThrows` for this kind of assertions if TestNG is used. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From lancea at openjdk.java.net Tue Mar 8 19:05:07 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 8 Mar 2022 19:05:07 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v3] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 17:19:14 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into bug-8264160 > - Bug id's to header and some other cleanup > - Fixing bad javadoc > - Merge remote-tracking branch 'upstream/master' into bug-8264160 > - Updating spec > - Proposed change for \b metacharacter The changes to Pattern seem OK pending the final CSR approval. Looks like your CSR is not quite ready for review as their is no info in the compatibility section. test/jdk/java/util/regex/RegExTest.java line 65: > 63: import java.util.stream.Stream; > 64: > 65: import org.testng.annotations.DataProvider; I don't see a DataProvider being used anywhere, perhaps you were and then decided against it? test/jdk/java/util/regex/RegExTest.java line 4556: > 4554: } > 4555: > 4556: //This test is for 8264160 Even if you are not going to do a pass through existing tests to provide a comment of the tests intent as part of this PR, please do so for your additional tests. Future maintainers will thank you :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From kasperni at gmail.com Tue Mar 8 19:14:44 2022 From: kasperni at gmail.com (Kasper Nielsen) Date: Tue, 8 Mar 2022 19:14:44 +0000 Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: > > > Agreed. Also, this class is unusual in that it is not instantiated; like > `Arrays` or `Collections` it is a (small) bundle of static factories (or > are they algorithms?). I think as such it should be called `Carriers`. > I don't know if it is still the plan. But there was talk about adding a java.util.concurrent.Carrier type? As well as various Carrier implementations. https://mail.openjdk.java.net/pipermail/loom-dev/2020-March/001122.html What about java.lang.runtime.ObjectShapes instead? Would fit in with ObjectMethods. /Kasper From brian.goetz at oracle.com Tue Mar 8 19:18:39 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 8 Mar 2022 19:18:39 +0000 Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: <52DBD830-FB2E-4FF8-A6D2-54F2E21109B1@oracle.com> It is a base assumption that the specific representation ? bits in an int[], a class per shape, a cache of common shapes, etc ? is a pure implementation detail that can be changed at will, based on various tradeoffs like footprint-vs-startup that can be made at any time. The only assumption is that when you pass a shape to the constructor() method, the same (hidden) representation will be used when you pass the same shape in the same JVM invocation to the component() methods. Having a List view fo the components may help because of the internal @Stable annotation. For pattern matching, we envision storing the accessor MHs in condy at the use site. String templates probably has a different expected user model. > On Mar 8, 2022, at 11:04 AM, Maurizio Cimadamore wrote: > > On Tue, 8 Mar 2022 14:02:39 GMT, Jim Laskey wrote: > >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Looks good. > I've left some minor doc-related comments. > When reading (as discussed online) I wondered if using Unsafe to access values inside a byte[] or Object[] would simplify the carrier implementation somehow. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 48: > >> 46: >> 47: /** >> 48: * This class is used to create objects that have number and types of > > The class javadoc seems a bit on the thin side. I would say something on the fact that the shape of the carrier is determined by a MethodType, etc, and add an example to illustrate basic usage. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 129: > >> 127: >> 128: /** >> 129: * Factory for array based carrier. Array wrapped in object to provide > > I found this comment hard to parse - or unhelpful to understand how the factory really worked. IIUC, this factory captures all parameters into an Object[] (using a collector MH) and returns that Object[] (which acts as the carrier object). I'm not sure I see anything here that would prevent the user from building a carrier and casting to Object[] ? > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 432: > >> 430: * Construct a new object carrier class based on shape. >> 431: * >> 432: * @param carrierShape shape of carrier > > Suggestion: > > * @param carrierShape shape of carrier > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 633: > >> 631: * getter. >> 632: * >> 633: * @param i index of component to get > > Suggestion: > > * @param i index of component to get > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 656: > >> 654: >> 655: /** >> 656: * Find or create carrier class for a carrioer shape. > > Suggestion: > > * Find or create carrier class for a carrier shape. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 852: > >> 850: * @throws IllegalArgumentException if number of component slots exceeds maximum >> 851: */ >> 852: public static MethodHandle constructor(MethodType methodType) { > > What happens to the methodType return type? (both here and in the components method). Should javadoc say anything? > > ------------- > > Marked as reviewed by mcimadamore (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/7744 From iklam at openjdk.java.net Tue Mar 8 19:29:33 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 8 Mar 2022 19:29:33 GMT Subject: RFR: 8253495: CDS generates non-deterministic output Message-ID: This patch makes the result of "java -Xshare:dump" deterministic: - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp - Fixed a problem in hashtable ordering in heapShared.cpp - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). Testing under way: - tier1~tier5 - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). ------------- Commit messages: - Merge branch 'master' into 8253495-cds-generateds-non-deterministic-output-2 - fixed test - more fixes - 8253495: CDS generates non-deterministic output Changes: https://git.openjdk.java.net/jdk/pull/7748/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253495 Stats: 73 lines in 12 files changed: 49 ins; 7 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From duke at openjdk.java.net Tue Mar 8 19:37:06 2022 From: duke at openjdk.java.net (Patrick Doyle) Date: Tue, 8 Mar 2022 19:37:06 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 21:41:05 GMT, Richard Startin wrote: >> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UTF-16 benchmarks > > Great to see this taken up. As it?s implemented here, it?s still scalar, but the unroll prevents a strength reduction of the multiplication in the loop from > > result = 31 * result + element; > > to: > > result = (result << 5) - result + element > > which creates a data dependency and slows the loop down. > > This was first reported by Peter Levart here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028898.html @richardstartin - does that strength reduction actually happen? The bit-shift transformation valid only if the original `result` is known to be non-negative. ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From jlaskey at openjdk.java.net Tue Mar 8 19:42:15 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 19:42:15 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:40:10 GMT, Maurizio Cimadamore wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 656: > >> 654: >> 655: /** >> 656: * Find or create carrier class for a carrioer shape. > > Suggestion: > > * Find or create carrier class for a carrier shape. Noted ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Tue Mar 8 19:53:13 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 19:53:13 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:48:56 GMT, Maurizio Cimadamore wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 129: > >> 127: >> 128: /** >> 129: * Factory for array based carrier. Array wrapped in object to provide > > I found this comment hard to parse - or unhelpful to understand how the factory really worked. IIUC, this factory captures all parameters into an Object[] (using a collector MH) and returns that Object[] (which acts as the carrier object). I'm not sure I see anything here that would prevent the user from building a carrier and casting to Object[] ? Clarified the comment. You are right. When I reworked the original code I dropped the intermediate object. For my purposes, it was about performance. If the object needs to be protected then it's up to the client to protect. The same would be true if I add byte[] for all binary carriers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Tue Mar 8 19:53:13 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 19:53:13 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: <2nZrjxn2EiFVB-ffQ_zCA4-5UebHlZyaxB068Vy2NHs=.22965292-5657-41fc-a0b1-0d1fd3331698@github.com> References: <2nZrjxn2EiFVB-ffQ_zCA4-5UebHlZyaxB068Vy2NHs=.22965292-5657-41fc-a0b1-0d1fd3331698@github.com> Message-ID: On Tue, 8 Mar 2022 15:50:22 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 432: >> >>> 430: * Construct a new object carrier class based on shape. >>> 431: * >>> 432: * @param carrierShape shape of carrier >> >> Suggestion: >> >> * @param carrierShape shape of carrier > > I see all `@param` tags have double space. If that's deliberate that's ok. Deliberate ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From erikj at openjdk.java.net Tue Mar 8 19:55:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Mar 2022 19:55:05 GMT Subject: RFR: 8253495: CDS generates non-deterministic output In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 19:11:02 GMT, Ioi Lam wrote: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). compare.sh looks good. Can't comment on the rest. Thank you for fixing this! ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7748 From jlaskey at openjdk.java.net Tue Mar 8 20:01:08 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 20:01:08 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: <5cJnBhkRjxOcEs5PjJmSp3ElaErdVSQUloaAD3RpXgo=.b859d270-140c-4659-a9e9-cca6c79566c8@github.com> On Tue, 8 Mar 2022 16:51:22 GMT, John R Rose wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 48: >> >>> 46: >>> 47: /** >>> 48: * This class is used to create objects that have number and types of >> >> The class javadoc seems a bit on the thin side. I would say something on the fact that the shape of the carrier is determined by a MethodType, etc, and add an example to illustrate basic usage. > > Agreed. Also, this class is unusual in that it is not instantiated; like `Arrays` or `Collections` it is a (small) bundle of static factories (or are they algorithms?). I think as such it should be called `Carriers`. > > I'm slightly surprised the MH factories are not factored through a metaobject of the form > > record CarrierBinding( > MethodType methodType, > MethodHandle constructor, > List> componentTypes, > List components) > { ? } > > > The presupposition here, I suppose, is that carriers will only be used by condy or similar quasi-statically configured clients, so having the multiple lookups through a hidden table is no burden, and the clients can always keep the associations correct (between constructors and various component accessors). > > **But** if I were to use carriers to manage intermediate structures in (say) a serialization package (for instance) I would need to make my own records like the above for my own bookkeeping, and I would be slightly miffed that the Carrier API insisted on doing a de-novo lookup twice on each MT key (to say nothing of me having to create the MT key first). > > **And** if I were to use carriers in that way (away from condy), **then** I would want to skip the step of building the MethodType, and wish for a factory method for CarrierBinding instances that took a plain List, as well as a factory method that took the MethodType (which is convenient for condy). > > BTW, it would be normal to give the name `Carrier` (which is a good name BTW) to the record type that embodies the group of method handles, so `record Carrier(?constructor?components?) {?factories?}`. > > I suppose stuff like this could be added later. But it's worth considering now, simply because there is an early decision point between a class named `Carrier` and a static-only class named `Carriers`. Will do. When I wrote this code, I wasn't expecting the external exposure. Hence... ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Tue Mar 8 20:10:06 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 8 Mar 2022 20:10:06 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 16:00:48 GMT, Maurizio Cimadamore wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 852: > >> 850: * @throws IllegalArgumentException if number of component slots exceeds maximum >> 851: */ >> 852: public static MethodHandle constructor(MethodType methodType) { > > What happens to the methodType return type? (both here and in the components method). Should javadoc say anything? The return type is ignored. Going back to John's notion of just passing in the parameterTypes would work okay. I think when Brian wrote the original code he may have been thinking about keying on the MethodType (interned). I'll add a note about the return type. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From lucy at openjdk.java.net Tue Mar 8 20:15:05 2022 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Tue, 8 Mar 2022 20:15:05 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v11] In-Reply-To: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com> References: <8p4ATe7aWCTiQ4umjuDmMO7mNozkF7S9aHvlYW0t7nI=.7f3ba36b-2f11-4a47-947e-f936d5929a0f@github.com> Message-ID: On Mon, 7 Mar 2022 23:13:36 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request incrementally with two additional commits since the last revision: > > - use 32-bit mask to calculate correct remainder value > - ary1 not required to have USE_KILL effect Changes look good. Due to lack of specific expertise, I can't fully approve aarch64 and x86 changes. ------------- Marked as reviewed by lucy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7231 From serb at openjdk.java.net Tue Mar 8 20:16:04 2022 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 8 Mar 2022 20:16:04 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 13:37:44 GMT, Alexey Ivanov wrote: >> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds. > > Can `SetObjectElementArray` raise an exception? > The index is within the array length and we store a string. I assume `cacheDirArray` is a string array. > ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds. If the SetObjectArrayElement will throw an exception we will call the NewStringUTF while the exception is raised which is a kind of "jni" issue. If such an exception is possible we should check and cleanup. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From brian.goetz at oracle.com Tue Mar 8 20:25:44 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 8 Mar 2022 20:25:44 +0000 Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: <111756CC-1515-4AAA-94C2-D95DB47F71EC@oracle.com> MethodType is a useful shape for describing a pattern, in reverse; the ?parameter? types are really the pattern bindings, and the ?return? type is really the (minimal) type of the target. With such a description, the MethodType for a pattern is the right input to get the carrier for the pattern. > On Mar 8, 2022, at 3:10 PM, Jim Laskey wrote: > > On Tue, 8 Mar 2022 16:00:48 GMT, Maurizio Cimadamore wrote: > >>> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >>> >>> See JBS for details. >> >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 852: >> >>> 850: * @throws IllegalArgumentException if number of component slots exceeds maximum >>> 851: */ >>> 852: public static MethodHandle constructor(MethodType methodType) { >> >> What happens to the methodType return type? (both here and in the components method). Should javadoc say anything? > > The return type is ignored. Going back to John's notion of just passing in the parameterTypes would work okay. I think when Brian wrote the original code he may have been thinking about keying on the MethodType (interned). I'll add a note about the return type. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7744 From xliu at openjdk.java.net Tue Mar 8 20:32:07 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 8 Mar 2022 20:32:07 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v2] In-Reply-To: References: Message-ID: <9_s7ria1CtL41qV9pD-hURvY1cQed-UnMfGf1cRBuuY=.09def3bb-6308-4bfa-a6f8-cbdb0cd3aa8a@github.com> On Tue, 8 Mar 2022 17:33:58 GMT, Daniel Jeli?ski wrote: > As for a better name for `growOnly`, something like `mayBeLatin` would better convey the variable's purpose. What do you think? There are tricky. I need to add test to cover them. The problem comes from that this patch fails to copy over the attribute 'growOnly/maybeLatin1' from the other AbstractStringBuilder. I think we can fix this loophole. Other types such as String are well-formed. they don't suffer from this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From duke at openjdk.java.net Tue Mar 8 20:43:06 2022 From: duke at openjdk.java.net (Richard Startin) Date: Tue, 8 Mar 2022 20:43:06 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 21:41:05 GMT, Richard Startin wrote: >> Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: >> >> Add UTF-16 benchmarks > > Great to see this taken up. As it?s implemented here, it?s still scalar, but the unroll prevents a strength reduction of the multiplication in the loop from > > result = 31 * result + element; > > to: > > result = (result << 5) - result + element > > which creates a data dependency and slows the loop down. > > This was first reported by Peter Levart here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028898.html > @richardstartin - does that strength reduction actually happen? The bit-shift transformation valid only if the original `result` is known to be non-negative. Yes. @State(Scope.Benchmark) public class StringHashCode { @Param({"sdjhfklashdfklashdflkashdflkasdhf", "????????????????????"}) String string; @CompilerControl(CompilerControl.Mode.DONT_INLINE) @Benchmark public int stringHashCode() { return new String(string).hashCode(); } } ....[Hottest Region 1].............................................................................. c2, level 4, StringHashCode::stringHashCode, version 507 (384 bytes) 0x00007f2df0142da4: shl $0x3,%r10 0x00007f2df0142da8: movabs $0x800000000,%r12 0x00007f2df0142db2: add %r12,%r10 0x00007f2df0142db5: xor %r12,%r12 0x00007f2df0142db8: cmp %r10,%rax 0x00007f2df0142dbb: jne 0x00007f2de8696080 ; {runtime_call ic_miss_stub} 0x00007f2df0142dc1: data16 xchg %ax,%ax 0x00007f2df0142dc4: nopl 0x0(%rax,%rax,1) 0x00007f2df0142dcc: data16 data16 xchg %ax,%ax [Verified Entry Point] 0.12% 0x00007f2df0142dd0: mov %eax,-0x14000(%rsp) 0.84% 0x00007f2df0142dd7: push %rbp 0.22% 0x00007f2df0142dd8: sub $0x30,%rsp ;*synchronization entry ; - StringHashCode::stringHashCode at -1 (line 14) 0x00007f2df0142ddc: mov 0xc(%rsi),%r8d ;*getfield string {reexecute=0 rethrow=0 return_oop=0} ; - StringHashCode::stringHashCode at 5 (line 14) 0.73% 0x00007f2df0142de0: mov 0x10(%r12,%r8,8),%eax ; implicit exception: dispatches to 0x00007f2df0142fc4 0.10% 0x00007f2df0142de5: test %eax,%eax ? 0x00007f2df0142de7: je 0x00007f2df0142df9 ;*synchronization entry ? ; - StringHashCode::stringHashCode at -1 (line 14) 0.16% ? 0x00007f2df0142de9: add $0x30,%rsp ? 0x00007f2df0142ded: pop %rbp ? 0x00007f2df0142dee: mov 0x108(%r15),%r10 0.88% ? 0x00007f2df0142df5: test %eax,(%r10) ; {poll_return} 0.18% ? 0x00007f2df0142df8: retq ? 0x00007f2df0142df9: mov 0xc(%r12,%r8,8),%ecx ;*getfield value {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::<init>@6 (line 236) ; - StringHashCode::stringHashCode at 8 (line 14) 0x00007f2df0142dfe: mov 0xc(%r12,%rcx,8),%r10d ;*arraylength {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::hashCode at 13 (line 1503) ; - StringHashCode::stringHashCode at 11 (line 14) ; implicit exception: dispatches to 0x00007f2df0142fd0 0.83% 0x00007f2df0142e03: test %r10d,%r10d 0x00007f2df0142e06: jbe 0x00007f2df0142f86 ;*ifle {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::hashCode at 14 (line 1503) ; - StringHashCode::stringHashCode at 11 (line 14) 0.14% 0x00007f2df0142e0c: movsbl 0x14(%r12,%r8,8),%r8d ;*getfield coder {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::<init>@14 (line 237) ; - StringHashCode::stringHashCode at 8 (line 14) 0.02% 0x00007f2df0142e12: test %r8d,%r8d 0x00007f2df0142e15: jne 0x00007f2df0142fac ;*ifne {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::isLatin1 at 10 (line 3266) ; - java.lang.String::hashCode at 19 (line 1504) ; - StringHashCode::stringHashCode at 11 (line 14) 0x00007f2df0142e1b: mov %r10d,%edi 1.14% 0x00007f2df0142e1e: dec %edi 0.10% 0x00007f2df0142e20: cmp %r10d,%edi 0x00007f2df0142e23: jae 0x00007f2df0142f8d 0x00007f2df0142e29: movzbl 0x10(%r12,%rcx,8),%r9d ;*iand {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.StringLatin1::hashCode at 31 (line 196) ; - java.lang.String::hashCode at 29 (line 1504) ; - StringHashCode::stringHashCode at 11 (line 14) 0x00007f2df0142e2f: lea (%r12,%rcx,8),%rbx ;*getfield value {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.String::<init>@6 (line 236) ; - StringHashCode::stringHashCode at 8 (line 14) 0.77% 0x00007f2df0142e33: mov %r10d,%edx 0.22% 0x00007f2df0142e36: add $0xfffffff9,%edx 0x00007f2df0142e39: mov $0x80000000,%r11d 0x00007f2df0142e3f: cmp %edx,%edi 0.84% 0x00007f2df0142e41: cmovl %r11d,%edx 0.10% 0x00007f2df0142e45: mov $0x1,%ebp 0x00007f2df0142e4a: cmp $0x1,%edx ? 0x00007f2df0142e4d: jle 0x00007f2df0142f55 ? 0x00007f2df0142e53: mov %r9d,%r11d 1.08% ? 0x00007f2df0142e56: shl $0x5,%r11d 0.08% ? 0x00007f2df0142e5a: sub %r9d,%r11d ;*putfield value {reexecute=0 rethrow=0 return_oop=0} ? ; - java.lang.String::<init>@9 (line 236) ? ; - StringHashCode::stringHashCode at 8 (line 14) 0.02% ?? 0x00007f2df0142e5d: jmp 0x00007f2df0142e6d ?? ? 0x00007f2df0142e5f: vmovd %xmm0,%ecx ?? ? 0x00007f2df0142e63: vmovd %xmm2,%r10d ?? ? 0x00007f2df0142e68: vmovd %xmm1,%r8d ?? ? 0x00007f2df0142e6d: mov %edx,%esi 0.92% ? ? 0x00007f2df0142e6f: sub %ebp,%esi 0.16% ? ? 0x00007f2df0142e71: mov $0x1f40,%r9d 0.02% ? ? 0x00007f2df0142e77: cmp %r9d,%esi ? ? 0x00007f2df0142e7a: mov $0x1f40,%edi 0.94% ? ? 0x00007f2df0142e7f: cmovg %edi,%esi 0.12% ? ? 0x00007f2df0142e82: add %ebp,%esi ? ? 0x00007f2df0142e84: vmovd %ecx,%xmm0 ? ? 0x00007f2df0142e88: vmovd %r10d,%xmm2 0.83% ? ? 0x00007f2df0142e8d: vmovd %r8d,%xmm1 0.10% ? ? 0x00007f2df0142e92: data16 nopw 0x0(%rax,%rax,1) ? ? 0x00007f2df0142e9c: data16 data16 xchg %ax,%ax ;*imul {reexecute=0 rethrow=0 return_oop=0} ? ? ; - java.lang.StringLatin1::hashCode at 25 (line 196) ? ? ; - java.lang.String::hashCode at 29 (line 1504) ? ? ; - StringHashCode::stringHashCode at 11 (line 14) 0.16% ? ?? 0x00007f2df0142ea0: movslq %ebp,%r13 ;*baload {reexecute=0 rethrow=0 return_oop=0} ? ?? ; - java.lang.StringLatin1::hashCode at 19 (line 195) ? ?? ; - java.lang.String::hashCode at 29 (line 1504) ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) 1.08% ? ?? 0x00007f2df0142ea3: movzbl 0x10(%rbx,%r13,1),%r9d 2.08% ? ?? 0x00007f2df0142ea9: movzbl 0x17(%rbx,%r13,1),%r10d 1.39% ? ?? 0x00007f2df0142eaf: movzbl 0x11(%rbx,%r13,1),%ecx 0.20% ? ?? 0x00007f2df0142eb5: add %r9d,%r11d 1.04% ? ?? 0x00007f2df0142eb8: movzbl 0x15(%rbx,%r13,1),%r8d 1.59% ? ?? 0x00007f2df0142ebe: mov %r11d,%edi 1.26% ? ?? 0x00007f2df0142ec1: shl $0x5,%edi 0.12% ? ?? 0x00007f2df0142ec4: sub %r11d,%edi 1.81% ? ?? 0x00007f2df0142ec7: add %ecx,%edi 2.77% ? ?? 0x00007f2df0142ec9: movzbl 0x14(%rbx,%r13,1),%r11d 0.84% ? ?? 0x00007f2df0142ecf: mov %edi,%ecx 0.16% ? ?? 0x00007f2df0142ed1: shl $0x5,%ecx 1.77% ? ?? 0x00007f2df0142ed4: sub %edi,%ecx 2.28% ? ?? 0x00007f2df0142ed6: movzbl 0x13(%rbx,%r13,1),%r9d 0.67% ? ?? 0x00007f2df0142edc: movzbl 0x12(%rbx,%r13,1),%edi 0.02% ? ?? 0x00007f2df0142ee2: add %edi,%ecx 2.51% ? ?? 0x00007f2df0142ee4: movzbl 0x16(%rbx,%r13,1),%edi 1.00% ? ?? 0x00007f2df0142eea: mov %ecx,%r14d 0.79% ? ?? 0x00007f2df0142eed: shl $0x5,%r14d 1.61% ? ?? 0x00007f2df0142ef1: sub %ecx,%r14d 6.01% ? ?? 0x00007f2df0142ef4: add %r9d,%r14d 1.73% ? ?? 0x00007f2df0142ef7: mov %r14d,%r9d 0.29% ? ?? 0x00007f2df0142efa: shl $0x5,%r9d 0.24% ? ?? 0x00007f2df0142efe: sub %r14d,%r9d 6.09% ? ?? 0x00007f2df0142f01: add %r11d,%r9d 2.28% ? ?? 0x00007f2df0142f04: mov %r9d,%r11d 0.29% ? ?? 0x00007f2df0142f07: shl $0x5,%r11d 0.28% ? ?? 0x00007f2df0142f0b: sub %r9d,%r11d 5.30% ? ?? 0x00007f2df0142f0e: add %r8d,%r11d 2.50% ? ?? 0x00007f2df0142f11: mov %r11d,%ecx 0.24% ? ?? 0x00007f2df0142f14: shl $0x5,%ecx 0.37% ? ?? 0x00007f2df0142f17: sub %r11d,%ecx 6.50% ? ?? 0x00007f2df0142f1a: add %edi,%ecx 2.71% ? ?? 0x00007f2df0142f1c: mov %ecx,%r9d 0.26% ? ?? 0x00007f2df0142f1f: shl $0x5,%r9d 0.18% ? ?? 0x00007f2df0142f23: sub %ecx,%r9d 5.93% ? ?? 0x00007f2df0142f26: add %r10d,%r9d ;*iadd {reexecute=0 rethrow=0 return_oop=0} ? ?? ; - java.lang.StringLatin1::hashCode at 32 (line 196) ? ?? ; - java.lang.String::hashCode at 29 (line 1504) ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) 2.85% ? ?? 0x00007f2df0142f29: mov %r9d,%r11d 0.10% ? ?? 0x00007f2df0142f2c: shl $0x5,%r11d 0.20% ? ?? 0x00007f2df0142f30: sub %r9d,%r11d ;*imul {reexecute=0 rethrow=0 return_oop=0} ? ?? ; - java.lang.StringLatin1::hashCode at 25 (line 196) ? ?? ; - java.lang.String::hashCode at 29 (line 1504) ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) 2.57% ? ?? 0x00007f2df0142f33: add $0x8,%ebp ;*iinc {reexecute=0 rethrow=0 return_oop=0} ? ?? ; - java.lang.StringLatin1::hashCode at 34 (line 195) ? ?? ; - java.lang.String::hashCode at 29 (line 1504) ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) 1.36% ? ?? 0x00007f2df0142f36: cmp %esi,%ebp ? ?? 0x00007f2df0142f38: jl 0x00007f2df0142ea0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ? ? ; - java.lang.StringLatin1::hashCode at 13 (line 195) ? ? ; - java.lang.String::hashCode at 29 (line 1504) ? ? ; - StringHashCode::stringHashCode at 11 (line 14) ? ? 0x00007f2df0142f3e: mov 0x108(%r15),%r10 ; ImmutableOopMap{rbx=Oop xmm0=NarrowOop } ? ? ;*goto {reexecute=1 rethrow=0 return_oop=0} ? ? ; - java.lang.StringLatin1::hashCode at 37 (line 195) ? ? ; - java.lang.String::hashCode at 29 (line 1504) ? ? ; - StringHashCode::stringHashCode at 11 (line 14) ? ? 0x00007f2df0142f45: test %eax,(%r10) ;*goto {reexecute=0 rethrow=0 return_oop=0} ? ? ; - java.lang.StringLatin1::hashCode at 37 (line 195) ? ? ; - java.lang.String::hashCode at 29 (line 1504) ? ? ; - StringHashCode::stringHashCode at 11 (line 14) ? ? ; {poll} 1.00% ? ? 0x00007f2df0142f48: cmp %edx,%ebp ? ? 0x00007f2df0142f4a: jl 0x00007f2df0142e5f 0.16% ? 0x00007f2df0142f50: vmovd %xmm2,%r10d ? 0x00007f2df0142f55: cmp %r10d,%ebp 0x00007f2df0142f58: jge 0x00007f2df0142f7e 0x00007f2df0142f5a: xchg %ax,%ax ;*aload_2 {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.StringLatin1::hashCode at 16 (line 195) ; - java.lang.String::hashCode at 29 (line 1504) ; - StringHashCode::stringHashCode at 11 (line 14) 0x00007f2df0142f5c: movzbl 0x10(%rbx,%rbp,1),%r8d 0x00007f2df0142f62: mov %r9d,%eax 0x00007f2df0142f65: shl $0x5,%eax 0x00007f2df0142f68: sub %r9d,%eax c2, level 4, StringHashCode::stringHashCode, version 505 (435 bytes) 0x00007fd05f2c0ba4: shl $0x3,%r10 0x00007fd05f2c0ba8: movabs $0x800000000,%r12 0x00007fd05f2c0bb2: add %r12,%r10 0x00007fd05f2c0bb5: xor %r12,%r12 0x00007fd05f2c0bb8: cmp %r10,%rax 0x00007fd05f2c0bbb: jne 0x00007fd057814080 ; {runtime_call ic_miss_stub} 0x00007fd05f2c0bc1: data16 xchg %ax,%ax 0x00007fd05f2c0bc4: nopl 0x0(%rax,%rax,1) 0x00007fd05f2c0bcc: data16 data16 xchg %ax,%ax [Verified Entry Point] 1.14% 0x00007fd05f2c0bd0: mov %eax,-0x14000(%rsp) 0.50% 0x00007fd05f2c0bd7: push %rbp 0.22% 0x00007fd05f2c0bd8: sub $0x30,%rsp ;*synchronization entry ; - StringHashCode::stringHashCode at -1 (line 14) 1.58% 0x00007fd05f2c0bdc: mov 0xc(%rsi),%r11d ;*getfield string {reexecute=0 rethrow=0 return_oop=0} ; - StringHashCode::stringHashCode at 5 (line 14) 0x00007fd05f2c0be0: mov 0x10(%r12,%r11,8),%ecx ;*synchronization entry ; - StringHashCode::stringHashCode at -1 (line 14) ; implicit exception: dispatches to 0x00007fd05f2c0efc 0.34% 0x00007fd05f2c0be5: test %ecx,%ecx ? 0x00007fd05f2c0be7: jne 0x00007fd05f2c0d84 ;*ifne {reexecute=0 rethrow=0 return_oop=0} ? ; - java.lang.String::hashCode at 6 (line 1503) ? ; - StringHashCode::stringHashCode at 11 (line 14) 1.04% ? 0x00007fd05f2c0bed: mov 0xc(%r12,%r11,8),%edx ;*getfield value {reexecute=0 rethrow=0 return_oop=0} ? ; - java.lang.String::<init>@6 (line 236) ? ; - StringHashCode::stringHashCode at 8 (line 14) 0.50% ? 0x00007fd05f2c0bf2: mov 0xc(%r12,%rdx,8),%r14d ;*arraylength {reexecute=0 rethrow=0 return_oop=0} ? ; - java.lang.String::hashCode at 13 (line 1503) ? ; - StringHashCode::stringHashCode at 11 (line 14) ? ; implicit exception: dispatches to 0x00007fd05f2c0f08 ? 0x00007fd05f2c0bf7: xor %eax,%eax 0.36% ? 0x00007fd05f2c0bf9: test %r14d,%r14d ?? 0x00007fd05f2c0bfc: jbe 0x00007fd05f2c0d74 ;*ifle {reexecute=0 rethrow=0 return_oop=0} ?? ; - java.lang.String::hashCode at 14 (line 1503) ?? ; - StringHashCode::stringHashCode at 11 (line 14) 1.08% ?? 0x00007fd05f2c0c02: movsbl 0x14(%r12,%r11,8),%ebp ;*getfield coder {reexecute=0 rethrow=0 return_oop=0} ?? ; - java.lang.String::<init>@14 (line 237) ?? ; - StringHashCode::stringHashCode at 8 (line 14) 0.50% ?? 0x00007fd05f2c0c08: lea (%r12,%rdx,8),%rdi ;*getfield value {reexecute=0 rethrow=0 return_oop=0} ?? ; - java.lang.String::<init>@6 (line 236) ?? ; - StringHashCode::stringHashCode at 8 (line 14) ?? 0x00007fd05f2c0c0c: mov $0x1,%r10d 0.18% ?? 0x00007fd05f2c0c12: mov $0x1f40,%esi 1.20% ?? 0x00007fd05f2c0c17: mov $0x80000000,%r11d ;*putfield value {reexecute=0 rethrow=0 return_oop=0} ?? ; - java.lang.String::<init>@9 (line 236) ?? ; - StringHashCode::stringHashCode at 8 (line 14) 0.50% ?? 0x00007fd05f2c0c1d: test %ebp,%ebp ??? 0x00007fd05f2c0c1f: je 0x00007fd05f2c0d88 ;*ifeq {reexecute=0 rethrow=0 return_oop=0} ??? ; - java.lang.String::hashCode at 22 (line 1504) ??? ; - StringHashCode::stringHashCode at 11 (line 14) ??? 0x00007fd05f2c0c25: sar %r14d ;*ishr {reexecute=0 rethrow=0 return_oop=0} ??? ; - java.lang.StringUTF16::hashCode at 5 (line 348) ??? ; - java.lang.String::hashCode at 39 (line 1505) ??? ; - StringHashCode::stringHashCode at 11 (line 14) 0.20% ??? 0x00007fd05f2c0c28: test %r14d,%r14d ???? 0x00007fd05f2c0c2b: jle 0x00007fd05f2c0d74 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ???? ; - java.lang.StringUTF16::hashCode at 11 (line 349) ???? ; - java.lang.String::hashCode at 39 (line 1505) ???? ; - StringHashCode::stringHashCode at 11 (line 14) 1.14% ???? 0x00007fd05f2c0c31: movzwl 0x10(%r12,%rdx,8),%r9d ;*invokestatic getChar {reexecute=0 rethrow=0 return_oop=0} ???? ; - java.lang.StringUTF16::hashCode at 20 (line 350) ???? ; - java.lang.String::hashCode at 39 (line 1505) ???? ; - StringHashCode::stringHashCode at 11 (line 14) 0.40% ???? 0x00007fd05f2c0c37: mov %r14d,%r13d ???? 0x00007fd05f2c0c3a: dec %r13d 0.16% ???? 0x00007fd05f2c0c3d: mov %r9d,%r8d 0.86% ???? 0x00007fd05f2c0c40: shl $0x5,%r8d 0.46% ???? 0x00007fd05f2c0c44: mov %r14d,%ebx ???? 0x00007fd05f2c0c47: add $0xfffffff9,%ebx 0.16% ???? 0x00007fd05f2c0c4a: cmp %ebx,%r13d 0.98% ???? 0x00007fd05f2c0c4d: cmovl %r11d,%ebx 0.46% ???? 0x00007fd05f2c0c51: cmp $0x1,%ebx ???? 0x00007fd05f2c0c54: jle 0x00007fd05f2c0edb ???? 0x00007fd05f2c0c5a: sub %r9d,%r8d ;*imul {reexecute=0 rethrow=0 return_oop=0} ???? ; - java.lang.StringUTF16::hashCode at 17 (line 350) ???? ; - java.lang.String::hashCode at 39 (line 1505) ???? ; - StringHashCode::stringHashCode at 11 (line 14) 0.28% ????? 0x00007fd05f2c0c5d: jmp 0x00007fd05f2c0c8e ;*bipush {reexecute=0 rethrow=0 return_oop=0} ????? ; - java.lang.StringUTF16::hashCode at 14 (line 350) ????? ; - java.lang.String::hashCode at 39 (line 1505) ????? ; - StringHashCode::stringHashCode at 11 (line 14) 1.22% ????? ? ? 0x00007fd05f2c0c5f: movzwl 0x10(%rdi,%r10,2),%r11d 1.54% ????? ? ? 0x00007fd05f2c0c65: sub %r9d,%eax 1.58% ????? ? ? 0x00007fd05f2c0c68: add %r11d,%eax ;*iadd {reexecute=0 rethrow=0 return_oop=0} ????? ? ? ; - java.lang.StringUTF16::hashCode at 23 (line 350) ????? ? ? ; - java.lang.String::hashCode at 39 (line 1505) ????? ? ? ; - StringHashCode::stringHashCode at 11 (line 14) 1.93% ????? ? ? 0x00007fd05f2c0c6b: inc %r10d ;*iinc {reexecute=0 rethrow=0 return_oop=0} ????? ? ? ; - java.lang.StringUTF16::hashCode at 25 (line 349) ????? ? ? ; - java.lang.String::hashCode at 39 (line 1505) ????? ? ? ; - StringHashCode::stringHashCode at 11 (line 14) 0.78% ????? ? ? 0x00007fd05f2c0c6e: cmp %r14d,%r10d ??????? ? 0x00007fd05f2c0c71: jge 0x00007fd05f2c0d74 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ??????? ? ; - java.lang.StringUTF16::hashCode at 11 (line 349) ??????? ? ; - java.lang.String::hashCode at 39 (line 1505) ??????? ? ; - StringHashCode::stringHashCode at 11 (line 14) 0.80% ??????? ? 0x00007fd05f2c0c77: mov %eax,%r8d 0.72% ??????? ? 0x00007fd05f2c0c7a: shl $0x5,%r8d 1.56% ??????? ? 0x00007fd05f2c0c7e: mov %eax,%r9d 0.68% ??????? ? 0x00007fd05f2c0c81: mov %r8d,%eax 0.62% ??????? ? 0x00007fd05f2c0c84: jmp 0x00007fd05f2c0c5f ?????? ?? 0x00007fd05f2c0c86: vmovd %xmm1,%ecx ?????? ?? 0x00007fd05f2c0c8a: vmovd %xmm2,%edx 1.12% ?????? ?? 0x00007fd05f2c0c8e: mov %ebx,%r13d 0.46% ???? ? ?? 0x00007fd05f2c0c91: sub %r10d,%r13d ???? ? ?? 0x00007fd05f2c0c94: cmp %esi,%r13d 0.18% ???? ? ?? 0x00007fd05f2c0c97: cmovg %esi,%r13d 1.14% ???? ? ?? 0x00007fd05f2c0c9b: add %r10d,%r13d 0.46% ???? ? ?? 0x00007fd05f2c0c9e: vmovd %ecx,%xmm1 ???? ? ?? 0x00007fd05f2c0ca2: vmovd %edx,%xmm2 0.30% ???? ? ?? 0x00007fd05f2c0ca6: data16 nopw 0x0(%rax,%rax,1) ;*imul {reexecute=0 rethrow=0 return_oop=0} ???? ? ?? ; - java.lang.StringUTF16::hashCode at 17 (line 350) ???? ? ?? ; - java.lang.String::hashCode at 39 (line 1505) ???? ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) 1.22% ???? ? ??? 0x00007fd05f2c0cb0: movzwl 0x1e(%rdi,%r10,2),%eax 1.91% ???? ? ??? 0x00007fd05f2c0cb6: movzwl 0x1c(%rdi,%r10,2),%ecx 0.42% ???? ? ??? 0x00007fd05f2c0cbc: movzwl 0x10(%rdi,%r10,2),%r9d 0.16% ???? ? ??? 0x00007fd05f2c0cc2: movzwl 0x12(%rdi,%r10,2),%r11d 1.16% ???? ? ??? 0x00007fd05f2c0cc8: add %r9d,%r8d 1.72% ???? ? ??? 0x00007fd05f2c0ccb: movzwl 0x14(%rdi,%r10,2),%r9d 0.50% ???? ? ??? 0x00007fd05f2c0cd1: mov %r8d,%edx 0.26% ???? ? ??? 0x00007fd05f2c0cd4: shl $0x5,%edx 1.54% ???? ? ??? 0x00007fd05f2c0cd7: sub %r8d,%edx 1.68% ???? ? ??? 0x00007fd05f2c0cda: add %r11d,%edx 0.44% ???? ? ??? 0x00007fd05f2c0cdd: movzwl 0x16(%rdi,%r10,2),%r8d 0.26% ???? ? ??? 0x00007fd05f2c0ce3: mov %edx,%r11d 1.10% ???? ? ??? 0x00007fd05f2c0ce6: shl $0x5,%r11d 1.38% ???? ? ??? 0x00007fd05f2c0cea: sub %edx,%r11d 0.46% ???? ? ??? 0x00007fd05f2c0ced: add %r9d,%r11d 0.38% ???? ? ??? 0x00007fd05f2c0cf0: movzwl 0x18(%rdi,%r10,2),%edx 1.10% ???? ? ??? 0x00007fd05f2c0cf6: mov %r11d,%r9d 1.44% ???? ? ??? 0x00007fd05f2c0cf9: shl $0x5,%r9d 0.54% ???? ? ??? 0x00007fd05f2c0cfd: sub %r11d,%r9d 0.38% ???? ? ??? 0x00007fd05f2c0d00: add %r8d,%r9d 1.64% ???? ? ??? 0x00007fd05f2c0d03: movzwl 0x1a(%rdi,%r10,2),%r8d 1.40% ???? ? ??? 0x00007fd05f2c0d09: mov %r9d,%r11d 0.44% ???? ? ??? 0x00007fd05f2c0d0c: shl $0x5,%r11d 0.56% ???? ? ??? 0x00007fd05f2c0d10: sub %r9d,%r11d 1.58% ???? ? ??? 0x00007fd05f2c0d13: add %edx,%r11d 1.97% ???? ? ??? 0x00007fd05f2c0d16: mov %r11d,%edx 0.22% ???? ? ??? 0x00007fd05f2c0d19: shl $0x5,%edx 1.02% ???? ? ??? 0x00007fd05f2c0d1c: sub %r11d,%edx 3.41% ???? ? ??? 0x00007fd05f2c0d1f: add %r8d,%edx 2.03% ???? ? ??? 0x00007fd05f2c0d22: mov %edx,%r11d 0.12% ???? ? ??? 0x00007fd05f2c0d25: shl $0x5,%r11d 1.24% ???? ? ??? 0x00007fd05f2c0d29: sub %edx,%r11d 2.97% ???? ? ??? 0x00007fd05f2c0d2c: add %ecx,%r11d 1.83% ???? ? ??? 0x00007fd05f2c0d2f: mov %r11d,%r9d 0.06% ???? ? ??? 0x00007fd05f2c0d32: shl $0x5,%r9d 1.16% ???? ? ??? 0x00007fd05f2c0d36: sub %r11d,%r9d 3.89% ???? ? ??? 0x00007fd05f2c0d39: add %eax,%r9d ;*iadd {reexecute=0 rethrow=0 return_oop=0} ???? ? ??? ; - java.lang.StringUTF16::hashCode at 23 (line 350) ???? ? ??? ; - java.lang.String::hashCode at 39 (line 1505) ???? ? ??? ; - StringHashCode::stringHashCode at 11 (line 14) 1.44% ???? ? ??? 0x00007fd05f2c0d3c: mov %r9d,%eax ???? ? ??? 0x00007fd05f2c0d3f: shl $0x5,%eax 1.16% ???? ? ??? 0x00007fd05f2c0d42: mov %eax,%r8d 1.83% ???? ? ??? 0x00007fd05f2c0d45: sub %r9d,%r8d ;*imul {reexecute=0 rethrow=0 return_oop=0} ???? ? ??? ; - java.lang.StringUTF16::hashCode at 17 (line 350) ???? ? ??? ; - java.lang.String::hashCode at 39 (line 1505) ???? ? ??? ; - StringHashCode::stringHashCode at 11 (line 14) 1.76% ???? ? ??? 0x00007fd05f2c0d48: add $0x8,%r10d ;*iinc {reexecute=0 rethrow=0 return_oop=0} ???? ? ??? ; - java.lang.StringUTF16::hashCode at 25 (line 349) ???? ? ??? ; - java.lang.String::hashCode at 39 (line 1505) ???? ? ??? ; - StringHashCode::stringHashCode at 11 (line 14) ???? ? ??? 0x00007fd05f2c0d4c: cmp %r13d,%r10d ???? ? ??? 0x00007fd05f2c0d4f: jl 0x00007fd05f2c0cb0 ;*if_icmpge {reexecute=0 rethrow=0 return_oop=0} ???? ? ?? ; - java.lang.StringUTF16::hashCode at 11 (line 349) ???? ? ?? ; - java.lang.String::hashCode at 39 (line 1505) ???? ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) ???? ? ?? 0x00007fd05f2c0d55: mov 0x108(%r15),%r11 ; ImmutableOopMap{rdi=Oop xmm2=NarrowOop } ???? ? ?? ;*goto {reexecute=1 rethrow=0 return_oop=0} ???? ? ?? ; - java.lang.StringUTF16::hashCode at 28 (line 349) ???? ? ?? ; - java.lang.String::hashCode at 39 (line 1505) ???? ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) 0.68% ???? ? ?? 0x00007fd05f2c0d5c: test %eax,(%r11) ;*goto {reexecute=0 rethrow=0 return_oop=0} ???? ? ?? ; - java.lang.StringUTF16::hashCode at 28 (line 349) ???? ? ?? ; - java.lang.String::hashCode at 39 (line 1505) ???? ? ?? ; - StringHashCode::stringHashCode at 11 (line 14) ???? ? ?? ; {poll} 0.84% ???? ? ?? 0x00007fd05f2c0d5f: cmp %ebx,%r10d ???? ? ?? 0x00007fd05f2c0d62: jl 0x00007fd05f2c0c86 ???? ? ? 0x00007fd05f2c0d68: cmp %r14d,%r10d ???? ? ? 0x00007fd05f2c0d6b: jl 0x00007fd05f2c0c5f ???? ? 0x00007fd05f2c0d71: mov %r9d,%eax ;*synchronization entry ???? ? ; - StringHashCode::stringHashCode at -1 (line 14) 0.38% ???? ? ? 0x00007fd05f2c0d74: add $0x30,%rsp 0.88% ? ? ? 0x00007fd05f2c0d78: pop %rbp 0.76% ? ? ? 0x00007fd05f2c0d79: mov 0x108(%r15),%r10 ? ? ? 0x00007fd05f2c0d80: test %eax,(%r10) ; {poll_return} 0.28% ? ? ? 0x00007fd05f2c0d83: retq ? ? ? 0x00007fd05f2c0d84: mov %ecx,%eax ? ? 0x00007fd05f2c0d86: jmp 0x00007fd05f2c0d74 ? 0x00007fd05f2c0d88: mov %r14d,%ebx 0x00007fd05f2c0d8b: dec %ebx 0x00007fd05f2c0d8d: cmp %r14d,%ebx 0x00007fd05f2c0d90: jae 0x00007fd05f2c0ee3 0x00007fd05f2c0d96: movzbl 0x10(%r12,%rdx,8),%r9d ;*iand {reexecute=0 rethrow=0 return_oop=0} ; - java.lang.StringLatin1::hashCode at 31 (line 196) ; - java.lang.String::hashCode at 29 (line 1504) ; - StringHashCode::stringHashCode at 11 (line 14) ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From john.r.rose at oracle.com Tue Mar 8 20:44:13 2022 From: john.r.rose at oracle.com (John Rose) Date: Tue, 08 Mar 2022 12:44:13 -0800 Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: <4E0A7D6B-AAFF-40FC-8FDA-E015ED673536@oracle.com> On 8 Mar 2022, at 11:53, Jim Laskey wrote: >> I'm not sure I see anything here that would prevent the user from building a carrier and casting to Object[] ? > Clarified the comment. You are right. When I reworked the original code I dropped the intermediate object. For my purposes, it was about performance. If the object needs to be protected then it's up to the client to protect. The same would be true if I add byte[] for all binary carriers. I would prefer protecting the Object[] inside a non-public-class envelope object. It?s a performance hit, but only on a path (no class spun b/c a high number of components) where there is no detailed optimization strategy anyway. For the less-optimized path, putting everything into an Object[] (boxing primitives as well?) suggests that performance (+ footprint) is not an issue anyway. In that case, the extra cost of adding the envelope object (indirection cost + footprint) not be a unique cost. The best reason to put an envelope around the Object[] array (or other user-crackable representation) is the same reason we randomize encounter order in Set.of and Map.of. It?s extra work, but it prevents users from building in out-of-contract dependencies in their code. If this API exposes Object[] values, even temporarily, is is possible (even likely) that users will notice and build in out-of-contract dependencies. The sad result of ?optimizing? the Object[] representation by omitting the envelope will be that further optimizations (real ones!) will be harder to get accepted. Summary: Put the envelope around the Object, on paths which use Object[]. Second suggestion, as a follow-on task for later, is add a long[] array into that same envelope and use the long[] array for all primitive values, instead of boxing them as Integer, Long, etc. (Or put the long[] array as the first item in the Object[] array.) It probably doesn?t matter, but 32-bit values could be stored in high or low halves of the long elements. (I think I?m not the only one to prototype it that way; I?ll bet Remi did something similar.) From aivanov at openjdk.java.net Tue Mar 8 20:51:07 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 8 Mar 2022 20:51:07 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu wrote: >> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` >> >> Test: >> >> - [x] jdk_desktop on Linux x86_64 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > mrserb and aivanov-jdk's comments > > > I did a quick grep, there are a few suspicious spots, e.g. https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp#L2711, I have yet take a close look. > > > > > > It doesn't leak the icon handle here, it's assigned to the member of the object (probably `NULL`). Yet it's inconsistent: if an exception is expected from `CreateIconFromRaster` on the line above, why isn't it checked after `CreateIconFromRaster` is called on the following line? > > I am not familiar with this code. What I see is that, it assigns `m_hIcon` and `m_hIconSm` to local variables, then reset them to `NULL`, once exception returns, are references to icon and small icon handles lost? and it will destroy icons as L2727 - 2732 do. But I may miss something. You're right. The old icon handles in `hOldIcon` and `hOldIconSm` will be leaked here if `CreateIconFromRaster` throws an exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From aivanov at openjdk.java.net Tue Mar 8 21:01:10 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 8 Mar 2022 21:01:10 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 20:12:29 GMT, Sergey Bylokhov wrote: >> Can `SetObjectElementArray` raise an exception? >> The index is within the array length and we store a string. I assume `cacheDirArray` is a string array. > >> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds. > > If the SetObjectArrayElement will throw an exception we will call the NewStringUTF while the exception is raised which is a kind of "jni" issue. If such an exception is possible we should check and cleanup. A quick search for `SetObjectArrayElement` in `java.desktop` module shows the call to `SetObjectArrayElement` is rarely followed by exception check. What kind of exception can `SetObjectArrayElement` raise if the index is within the range and the stored element is of correct type? ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From zgu at openjdk.java.net Tue Mar 8 21:05:09 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 8 Mar 2022 21:05:09 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 20:57:27 GMT, Alexey Ivanov wrote: >>> ??? You want to check and cleanup if NewStringUTF fails. You only want to call SetObjectElementArray if NewStringUTF succeeds. >> >> If the SetObjectArrayElement will throw an exception we will call the NewStringUTF while the exception is raised which is a kind of "jni" issue. If such an exception is possible we should check and cleanup. > > A quick search for `SetObjectArrayElement` in `java.desktop` module shows the call to `SetObjectArrayElement` is rarely followed by exception check. > > What kind of exception can `SetObjectArrayElement` raise if the index is within the range and the stored element is of correct type? I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From aivanov at openjdk.java.net Tue Mar 8 21:08:06 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 8 Mar 2022 21:08:06 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 21:02:04 GMT, Zhengyu Gu wrote: > I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick. Yes. But we're discussing whether a check for exception is necessary after `(*env)->SetObjectArrayElement`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From zgu at openjdk.java.net Tue Mar 8 21:18:07 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 8 Mar 2022 21:18:07 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 21:05:13 GMT, Alexey Ivanov wrote: >> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick. > >> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick. > > Yes. > > But we're discussing whether a check for exception is necessary after `(*env)->SetObjectArrayElement`. `SetObjectArrayElement()` may throw `ArrayIndexOutOfBoundsException` and `ArrayStoreException`, but I don't see it is possible here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From aivanov at openjdk.java.net Tue Mar 8 21:18:07 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 8 Mar 2022 21:18:07 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 21:12:33 GMT, Zhengyu Gu wrote: >>> I think `NewStringUTF()` can throw OOM and also return `NULL`, just which one you pick. >> >> Yes. >> >> But we're discussing whether a check for exception is necessary after `(*env)->SetObjectArrayElement`. > > `SetObjectArrayElement()` may throw `ArrayIndexOutOfBoundsException` and `ArrayStoreException`, but I don't see it is possible here. That's exactly my point. Therefore the check for exception after `SetObjectArrayElement` is unnecessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From xgong at openjdk.java.net Wed Mar 9 01:06:04 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 9 Mar 2022 01:06:04 GMT Subject: Integrated: 8282432: Optimize masked "test" Vector API with predicate feature In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 02:50:27 GMT, Xiaohong Gong wrote: > The vector `"test"` api is implemented with vector `"compare"`. And the masked `"test" `is implemented with `"test(op).and(m)"` which means `"compare().and(m)"` finally. Since the masked vector `"compare"` has been optimized with predicated instruction for archituctures that support the feature, the masked `"test"` can also be optimized by implementing it with the predicated compare. This could save the additional ` "and"` for architectures that support the predicate feature. > > This patch optimized the masked `"test"` by implementing it with masked `"compare"`. With this patch, the following codes for the` "IS_NEGATIVE"` op for a DoubleVector with SVE: > > mov z19.d, #0 > cmpgt p1.d, p7/z, z19.d, z17.d > and p0.b, p7/z, p1.b, p0.b > > are optimized to: > > mov z19.d, #0 > cmpgt p0.d, p0/z, z19.d, z17.d > > Also update the jtreg tests for masked` "test" ` to make sure they are hot enough to be compiled by c2. This pull request has now been integrated. Changeset: 12693a6c Author: Xiaohong Gong Committer: Ningsheng Jian URL: https://git.openjdk.java.net/jdk/commit/12693a6cf3e00c38a635d888419406f689657813 Stats: 1325 lines in 70 files changed: 574 ins; 11 del; 740 mod 8282432: Optimize masked "test" Vector API with predicate feature Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/7654 From igraves at openjdk.java.net Wed Mar 9 01:33:43 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 9 Mar 2022 01:33:43 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v4] In-Reply-To: References: Message-ID: > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Updating with additional descriptors. Removing DataProvider import ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7539/files - new: https://git.openjdk.java.net/jdk/pull/7539/files/75289c00..98fcaa9a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=02-03 Stats: 19 lines in 1 file changed: 18 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7539/head:pull/7539 PR: https://git.openjdk.java.net/jdk/pull/7539 From igraves at openjdk.java.net Wed Mar 9 01:33:48 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 9 Mar 2022 01:33:48 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v3] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 18:54:13 GMT, Lance Andersen wrote: >> Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' of https://github.com/openjdk/jdk into bug-8264160 >> - Bug id's to header and some other cleanup >> - Fixing bad javadoc >> - Merge remote-tracking branch 'upstream/master' into bug-8264160 >> - Updating spec >> - Proposed change for \b metacharacter > > test/jdk/java/util/regex/RegExTest.java line 65: > >> 63: import java.util.stream.Stream; >> 64: >> 65: import org.testng.annotations.DataProvider; > > I don't see a DataProvider being used anywhere, perhaps you were and then decided against it? Ah yes, thanks. I had originally written this test with a DataProvider, it proved to be a bit clunky and slower than it is now. > test/jdk/java/util/regex/RegExTest.java line 4556: > >> 4554: } >> 4555: >> 4556: //This test is for 8264160 > > Even if you are not going to do a pass through existing tests to provide a comment of the tests intent as part of this PR, please do so for your additional tests. Future maintainers will thank you :-) Fixed as far back as I can remember for now! ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From valeriep at openjdk.java.net Wed Mar 9 02:02:51 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 02:02:51 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to use SHA-384 as long as the keysize permits. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/27e27836..7f6fe4b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=00-01 Stats: 27 lines in 7 files changed: 6 ins; 4 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From duke at openjdk.java.net Wed Mar 9 02:05:44 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 9 Mar 2022 02:05:44 GMT Subject: RFR: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame [v5] In-Reply-To: References: Message-ID: <1A3_6fwGH0K81xA_SzoIijntQnnHHoC1BRb6s3lrRgs=.064e9d34-edc6-4da9-95b6-72a3f452dd3d@github.com> > The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. Tim Prinzing 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: - Merge branch 'master' into JDK-8280902 - remove unnecessary variable - more suggested changes - suggested changes - Update src/java.base/share/classes/java/util/ResourceBundle.java Co-authored-by: Mandy Chung - Use the unnamed module defined to the system class loader instead of the boot class loader. - JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7663/files - new: https://git.openjdk.java.net/jdk/pull/7663/files/45f9b37b..6600e1f5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7663&range=03-04 Stats: 17900 lines in 516 files changed: 12667 ins; 3251 del; 1982 mod Patch: https://git.openjdk.java.net/jdk/pull/7663.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7663/head:pull/7663 PR: https://git.openjdk.java.net/jdk/pull/7663 From duke at openjdk.java.net Wed Mar 9 04:07:11 2022 From: duke at openjdk.java.net (Tim Prinzing) Date: Wed, 9 Mar 2022 04:07:11 GMT Subject: Integrated: JDK-8280902 ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 18:56:40 GMT, Tim Prinzing wrote: > The caller class returned by Reflection::getCallerClass was used to gain access to it's module in most cases and class loader in one case. I added a method to translate the caller class to caller module so that the decision of what module represents the caller with no stack frame is made in a single place. Calls made to caller.getModule() were replaced with getCallerModule(caller) which returns the system class loader unnamed module if the caller is null. > > The one place a class loader was produced from the caller in getBundleImpl it was rewritten to route through the getCallerModule method: > > final ClassLoader loader = (caller != null) ? > caller.getClassLoader() : getLoader(getCallerModule(caller)); > > A JNI test was added which calls getBundle to fetch a test bundle from a location added to the classpath, fetches a string out of the bundle and verifies it, and calls clearCache. > > The javadoc was updated for the caller sensitive methods changed. This pull request has now been integrated. Changeset: 31ad80a2 Author: Tim Prinzing Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/31ad80a229e3f67823ff8f1fc914c5503f184b57 Stats: 218 lines in 4 files changed: 207 ins; 3 del; 8 mod 8280902: ResourceBundle::getBundle may throw NPE when invoked by JNI code with no caller frame Reviewed-by: naoto, mchung, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/7663 From iklam at openjdk.java.net Wed Mar 9 05:10:44 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Mar 2022 05:10:44 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed zero build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7748/files - new: https://git.openjdk.java.net/jdk/pull/7748/files/1fb3f830..44db40f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=00-01 Stats: 5 lines in 2 files changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From stuefe at openjdk.java.net Wed Mar 9 06:57:01 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Mar 2022 06:57:01 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: <-S80LKyRxiTf3Cpc22n2rjAz9wJFGlM795arBKTmlcw=.d22e7b11-6b30-4f35-8b6b-03bd190946df@github.com> On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu wrote: >> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` >> >> Test: >> >> - [x] jdk_desktop on Linux x86_64 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > mrserb and aivanov-jdk's comments Still looks good to me. ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7691 From dholmes at openjdk.java.net Wed Mar 9 07:07:58 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Mar 2022 07:07:58 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed zero build I have reservations about contorting things this way just to get "deterministic output". The VM needs to fully initialize and then become quiescent before the dump occurs, and as I say below if you don't start other threads then you potentially remove part of the archive because classes won't be loaded by those threads. I think if you care about the order of dumping classes then you should control that order, you don't try to force the order of loading. Can't you sort things before dumping? ie rehash/rebuild the hashtables etc so it has a canonical ordering? I see this was mentioned in the bug report and is considered a largish/complex fix, but it would be the proper fix IMO. Thanks, David src/hotspot/share/prims/jvm.cpp line 2873: > 2871: // execute in parallel, symbols and classes may be loaded in > 2872: // random orders which will make the resulting CDS archive > 2873: // non-deterministic. Yes but by not starting these threads you are potentially excluding a range of classes from the shared archive! ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Wed Mar 9 07:18:06 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Mar 2022 07:18:06 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 06:49:02 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > src/hotspot/share/prims/jvm.cpp line 2873: > >> 2871: // execute in parallel, symbols and classes may be loaded in >> 2872: // random orders which will make the resulting CDS archive >> 2873: // non-deterministic. > > Yes but by not starting these threads you are potentially excluding a range of classes from the shared archive! `java -Xshare:dump` loads all classes specified in a classlist, which is created without this thread-disabling hack. The number of classes in the CDS archive is the same before/after this PR. The size of the CDS archive is identical. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Wed Mar 9 07:36:02 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 9 Mar 2022 07:36:02 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 07:04:56 GMT, David Holmes wrote: > I have reservations about contorting things this way just to get "deterministic output". > > The VM needs to fully initialize and then become quiescent before the dump occurs, and as I say below if you don't start other threads then you potentially remove part of the archive because classes won't be loaded by those threads. > > I think if you care about the order of dumping classes then you should control that order, you don't try to force the order of loading. Can't you sort things before dumping? ie rehash/rebuild the hashtables etc so it has a canonical ordering? I see this was mentioned in the bug report and is considered a largish/complex fix, but it would be the proper fix IMO. > > Thanks, David I tried the "proper" approach but it's very complicated. I already have an implementation that sorts all the metadata. However, the CDS archive also contains a heap dump, which includes Java HashMaps. If I allow those 3 Java threads to start, some HashMaps in the module graph will have unstable ordering. I think the reason is concurrent thread execution causes unstable assignment of the identity_hash for objects in the heap dump. I cannot think of a clean way to fix this. The alternative, disabling Java thread starts, is much simpler and much more appealing to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From stuefe at openjdk.java.net Wed Mar 9 08:02:01 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 9 Mar 2022 08:02:01 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed zero build Hi Ioi, some questions, comments inline. Like David in the comments, I am also a bit vague on the usefulness, but I may not know the whole story. Is it to enable repackagers like Debian to check the "reproducable" tickbox on their OpenJDK package? Or is there a practical need for this? Thanks, Thomas src/hotspot/share/prims/jvm.cpp line 2887: > 2885: return; > 2886: } > 2887: #endif Should we do this for jni_AttachCurrentThread too? src/hotspot/share/utilities/hashtable.hpp line 42: > 40: > 41: LP64_ONLY(unsigned int _gap;) > 42: For 64-bit, you now lose packing potential in the theoretical case the following payload does not have to be aligned to 64 bit. E.g. for T=char, where the whole entry would fit into 8 bytes. Probably does not matter as long as entries are allocated individually from C-heap which is a lot more wasteful anyway. For 32-bit, I think you may have the same problem if the payload starts with a uint64_t. Would that not be aligned to a 64-bit boundary too? Whether or not you build on 64-bit? I think setting the memory, or at least the first 8..16 bytes, of the entry to zero in BasicHashtable::new_entry could be more robust: (16 bytes in case the payload starts with a long double but that may be overthinking it :) template BasicHashtableEntry* BasicHashtable::new_entry(unsigned int hashValue) { char* p = :new (NEW_C_HEAP_ARRAY(char, this->entry_size(), F); ::memset(p, 0, MIN2(this->entry_size(), 16)); // needs reproducable BasicHashtableEntry* entry = ::new (p) BasicHashtableEntry(hashValue); return entry; } If you are worried about performance, this may also be controlled by a template parameter, and then you do it just for the system dictionary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From xliu at openjdk.java.net Wed Mar 9 08:33:36 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 9 Mar 2022 08:33:36 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3] In-Reply-To: References: Message-ID: > If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. > toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). > > java.io.BufferedRead::readLine() is a case that StringBuilder grows only. > > In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. > > Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. > > Before: > > $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms > > > After > > $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Change growOnly to maybeLatin. This patch also copys over the attribute from the other AbstractStringBuilder. Add a unit test to cover methods which cause maybeLatin1 becomes true. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7671/files - new: https://git.openjdk.java.net/jdk/pull/7671/files/a5e3a162..415929af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=01-02 Stats: 62 lines in 3 files changed: 42 ins; 9 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671 From duke at openjdk.java.net Wed Mar 9 08:35:45 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Mar 2022 08:35:45 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8282662: Revert dubious changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7729/files - new: https://git.openjdk.java.net/jdk/pull/7729/files/b31edfcd..5bbe8c4e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=00-01 Stats: 6 lines in 2 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Wed Mar 9 09:02:00 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Mar 2022 09:02:00 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> References: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> Message-ID: On Tue, 8 Mar 2022 14:28:00 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes > > src/java.base/share/classes/sun/reflect/annotation/AnnotationSupport.java line 79: > >> 77: containerBeforeContainee(annotations, annoClass); >> 78: >> 79: result.addAll((indirectFirst ? 0 : 1), List.of(indirect)); > > This `indirect` is most likely to be of size > 2 I've reverted this along with the rest of dubious changes ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From aivanov at openjdk.java.net Wed Mar 9 09:14:08 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 9 Mar 2022 09:14:08 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 15:54:45 GMT, Zhengyu Gu wrote: >> Please review this small patch that fixes a potential memory leak that exception return fails to release allocated `cacheDirs` >> >> Test: >> >> - [x] jdk_desktop on Linux x86_64 > > Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision: > > mrserb and aivanov-jdk's comments Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From duke at openjdk.java.net Wed Mar 9 09:41:05 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Wed, 9 Mar 2022 09:41:05 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> References: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> Message-ID: <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com> On Tue, 8 Mar 2022 14:27:23 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes > > src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70: > >> 68: throws IOException >> 69: { >> 70: this.walker = new FileTreeWalker(List.of(options), maxDepth); > > Relates to https://bugs.openjdk.java.net/browse/JDK-8145048 Should I keep it as is or revert along with the rest of dubious changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From aivanov at openjdk.java.net Wed Mar 9 09:42:00 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 9 Mar 2022 09:42:00 GMT Subject: RFR: 8282628: Potential memory leak in sun.font.FontConfigManager.getFontConfig() [v2] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 20:47:45 GMT, Alexey Ivanov wrote: > You're right. The old icon handles in `hOldIcon` and `hOldIconSm` will be leaked here if `CreateIconFromRaster` throws an exception. I've submitted [JDK-8282862](https://bugs.openjdk.java.net/browse/JDK-8282862): AwtWindow::SetIconData leaks old icon handles if an exception is detected ------------- PR: https://git.openjdk.java.net/jdk/pull/7691 From djelinski at openjdk.java.net Wed Mar 9 11:06:07 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Wed, 9 Mar 2022 11:06:07 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3] In-Reply-To: References: Message-ID: <9TX9zYCOMkIcS-q5J4zwR7cEzB46xl_kGhrFYnXzC0E=.e7813f83-eef5-48b1-9545-98b9ea7aca22@github.com> On Wed, 9 Mar 2022 08:33:36 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Change growOnly to maybeLatin. > > This patch also copys over the attribute from the other AbstractStringBuilder. > Add a unit test to cover methods which cause maybeLatin1 becomes true. LGTM. I'm not a reviewer, so you'll need another opinion. ------------- Marked as reviewed by djelinski (Author). PR: https://git.openjdk.java.net/jdk/pull/7671 From lancea at openjdk.java.net Wed Mar 9 11:18:06 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 9 Mar 2022 11:18:06 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v4] In-Reply-To: References: Message-ID: <9dE6nBNfUJ2Uml9SAovwZEVeowd-nv0dvlQaeEKhHqY=.3ed5feff-e8e9-482a-8f90-d25ff7dc7628@github.com> On Wed, 9 Mar 2022 01:33:43 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Updating with additional descriptors. Removing DataProvider import Thank you for the cleanup. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7539 From jbhateja at openjdk.java.net Wed Mar 9 11:38:34 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 9 Mar 2022 11:38:34 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v12] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 - 8279508: Removing +LogCompilation flag. - 8279508: Review comments resolved.` - 8279508: Adding descriptive comments. - 8279508: Review comments resolved. - 8279508: Review comments resolved. - 8279508: Fixing for windows failure. - 8279508: Adding few descriptive comments. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d07f7c76...547f4e31 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7094/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=11 Stats: 752 lines in 24 files changed: 660 ins; 30 del; 62 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From dholmes at openjdk.java.net Wed Mar 9 11:49:05 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 9 Mar 2022 11:49:05 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed zero build The "heap dump" aspect of this is not something I'm familiar with, but if the threads don't affect the list of classes dumped, they surely must affect what is in the heap dump otherwise their execution would not be an issue. So you must be sacrificing something by not having these threads start. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From jlaskey at openjdk.java.net Wed Mar 9 13:15:59 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 9 Mar 2022 13:15:59 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 14:02:39 GMT, Jim Laskey wrote: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Note that the Object[] + int/long[] trick is pretty close to how we implemented objects in Nashorn and we got decent performance there. I'll run some jmh tests and compare against the anon class. As Brian states, it's not the implementation, it's the API. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From rkennke at openjdk.java.net Wed Mar 9 13:20:36 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 9 Mar 2022 13:20:36 GMT Subject: [jdk18] RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive Message-ID: <0-m3pV9rC1YH-PQPh02NTkWiL50-I0MwfIcnRIMnTvw=.b817aec7-a4a4-494b-99bf-b0e993f87c28@github.com> Hi all, This pull request contains a backport of commit [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository. The commit being backported was authored by Roman Kennke on 10 Dec 2021 and was reviewed by Roger Riggs and Peter Levart. It fixes a memory leak in ObjectStreamClass under certain conditions. See bug for details. Thanks! ------------- Commit messages: - Backport 8eb453baebe377697286f7eb32280ca9f1fd7775 Changes: https://git.openjdk.java.net/jdk18/pull/117/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=117&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277072 Stats: 496 lines in 4 files changed: 284 ins; 186 del; 26 mod Patch: https://git.openjdk.java.net/jdk18/pull/117.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/117/head:pull/117 PR: https://git.openjdk.java.net/jdk18/pull/117 From joe.darcy at oracle.com Wed Mar 9 13:44:45 2022 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 9 Mar 2022 05:44:45 -0800 Subject: Please help backport the fix with the XSLT compiler in JDK18 to JDK11 & JDK17 In-Reply-To: References: Message-ID: <9e7eca0f-7aac-fce2-517c-8ace8ef217aa@oracle.com> Note that management of the update releases are are discussed on different aliases and follow their own processes: ??? http://mail.openjdk.java.net/mailman/listinfo/jdk-updates-dev ??? http://openjdk.java.net/projects/jdk-updates/ -Joe On 3/7/2022 6:59 PM, Cheng Jin wrote: > Hi there, > > I notice the issue with the XSLT compiler (https://github.com/openjdk/jdk/blob/master/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/XSLTC.java) > I raised later last year at https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-November/083135.html has been fixed in JDK18 via https://bugs.openjdk.java.net/browse/JDK-8276657. > Could you help backport the fix to JDK11 and JDK17 give both of them share the same issue in code? Many thanks. > > Best Regards > Cheng Jin From rriggs at openjdk.java.net Wed Mar 9 14:31:17 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 9 Mar 2022 14:31:17 GMT Subject: [jdk18] RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive In-Reply-To: <0-m3pV9rC1YH-PQPh02NTkWiL50-I0MwfIcnRIMnTvw=.b817aec7-a4a4-494b-99bf-b0e993f87c28@github.com> References: <0-m3pV9rC1YH-PQPh02NTkWiL50-I0MwfIcnRIMnTvw=.b817aec7-a4a4-494b-99bf-b0e993f87c28@github.com> Message-ID: On Wed, 9 Mar 2022 13:11:27 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository. > > The commit being backported was authored by Roman Kennke on 10 Dec 2021 and was reviewed by Roger Riggs and Peter Levart. > > It fixes a memory leak in ObjectStreamClass under certain conditions. See bug for details. > > Thanks! Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk18/pull/117 From rkennke at openjdk.java.net Wed Mar 9 14:49:02 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 9 Mar 2022 14:49:02 GMT Subject: [jdk18] RFR: 8277072: ObjectStreamClass caches keep ClassLoaders alive In-Reply-To: <0-m3pV9rC1YH-PQPh02NTkWiL50-I0MwfIcnRIMnTvw=.b817aec7-a4a4-494b-99bf-b0e993f87c28@github.com> References: <0-m3pV9rC1YH-PQPh02NTkWiL50-I0MwfIcnRIMnTvw=.b817aec7-a4a4-494b-99bf-b0e993f87c28@github.com> Message-ID: <9eTZCvO2f9yfiXUUrOlzDxArNfm66r4Bqwb6RLaZ2mA=.217b732a-685d-4499-a490-516e1b579ad5@github.com> On Wed, 9 Mar 2022 13:11:27 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository. > > The commit being backported was authored by Roman Kennke on 10 Dec 2021 and was reviewed by Roger Riggs and Peter Levart. > > It fixes a memory leak in ObjectStreamClass under certain conditions. See bug for details. > > Thanks! Oops, I believe this should have been done vs jdk18u (not jdk18). Trying again. ------------- PR: https://git.openjdk.java.net/jdk18/pull/117 From rkennke at openjdk.java.net Wed Mar 9 14:49:02 2022 From: rkennke at openjdk.java.net (Roman Kennke) Date: Wed, 9 Mar 2022 14:49:02 GMT Subject: [jdk18] Withdrawn: 8277072: ObjectStreamClass caches keep ClassLoaders alive In-Reply-To: <0-m3pV9rC1YH-PQPh02NTkWiL50-I0MwfIcnRIMnTvw=.b817aec7-a4a4-494b-99bf-b0e993f87c28@github.com> References: <0-m3pV9rC1YH-PQPh02NTkWiL50-I0MwfIcnRIMnTvw=.b817aec7-a4a4-494b-99bf-b0e993f87c28@github.com> Message-ID: <9A22lrc5PAtjlcJf3WE5RJBb1XpAe-BRrAlwe9ltxzI=.4e0bd55c-efd4-4016-93c0-2022899d6fa0@github.com> On Wed, 9 Mar 2022 13:11:27 GMT, Roman Kennke wrote: > Hi all, > > This pull request contains a backport of commit [8eb453ba](https://github.com/openjdk/jdk/commit/8eb453baebe377697286f7eb32280ca9f1fd7775) from the [openjdk/jdk](https://git.openjdk.java.net/jdk) repository. > > The commit being backported was authored by Roman Kennke on 10 Dec 2021 and was reviewed by Roger Riggs and Peter Levart. > > It fixes a memory leak in ObjectStreamClass under certain conditions. See bug for details. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk18/pull/117 From duke at openjdk.java.net Wed Mar 9 15:50:03 2022 From: duke at openjdk.java.net (liach) Date: Wed, 9 Mar 2022 15:50:03 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com> References: <5Lm__pWStimPX-G9_s78bey9eqvpV2FNhzPcyL8sP3U=.f708f27f-e0f5-4d8d-952b-d8e2d2fb2534@github.com> <4pr44lTfbkJI8XL7aYPyxtbJFaZgQ3n2fXzJMyunO-E=.074d67c9-c57b-4b81-95bd-f984157b0811@github.com> Message-ID: On Wed, 9 Mar 2022 09:37:30 GMT, ?????? ??????? wrote: >> src/java.base/share/classes/java/nio/file/FileTreeIterator.java line 70: >> >>> 68: throws IOException >>> 69: { >>> 70: this.walker = new FileTreeWalker(List.of(options), maxDepth); >> >> Relates to https://bugs.openjdk.java.net/browse/JDK-8145048 > > Should I keep it as is or revert along with the rest of dubious changes? probably keep it. this can be updated in the patch for that bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Wed Mar 9 16:12:13 2022 From: duke at openjdk.java.net (liach) Date: Wed, 9 Mar 2022 16:12:13 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 08:35:45 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes src/java.base/share/classes/java/lang/invoke/MethodType.java line 910: > 908: if (skipPos > myLen || myLen - skipPos > fullLen) > 909: return false; > 910: List> myList = List.of(ptypes); imo should revert this one together with that proxy parameter one ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From bpb at openjdk.java.net Wed Mar 9 16:34:06 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 9 Mar 2022 16:34:06 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v4] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 01:33:43 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Updating with additional descriptors. Removing DataProvider import src/java.base/share/classes/java/util/regex/Pattern.java line 161: > 159: * Any character (may or may not match line terminators) > 160: * {@code \d} > 161: * A digit: {@code [0-9]} if if Looks like there is a superfluous `if` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From weijun at openjdk.java.net Wed Mar 9 16:44:03 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 16:44:03 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 02:02:51 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Updated to use SHA-384 as long as the keysize permits. The `JarSigner` API is not updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From redestad at openjdk.java.net Wed Mar 9 16:52:54 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Mar 2022 16:52:54 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v12] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Restructure encodeUTF8 to reduce code gen issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/934b5b8a..3d155c87 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=10-11 Stats: 21 lines in 1 file changed: 8 ins; 5 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From jlaskey at openjdk.java.net Wed Mar 9 17:42:34 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Wed, 9 Mar 2022 17:42:34 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v2] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - More comments. - Allocate long fields first (alignment) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/ac2b6eb2..246450ca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=00-01 Stats: 95 lines in 1 file changed: 26 ins; 4 del; 65 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From bpb at openjdk.java.net Wed Mar 9 17:55:51 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 9 Mar 2022 17:55:51 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v5] In-Reply-To: References: Message-ID: <6YU_dh0rk5tPyWu2vMm6J-b7JbiZ9bY6ndMmsa4K-ls=.d7739fd8-0314-449d-8115-27d0b92e8fa8@github.com> On Wed, 9 Mar 2022 17:49:11 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing superfluous 'if' Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From igraves at openjdk.java.net Wed Mar 9 17:55:59 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 9 Mar 2022 17:55:59 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v4] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 16:30:24 GMT, Brian Burkhalter wrote: >> Ian Graves has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating with additional descriptors. Removing DataProvider import > > src/java.base/share/classes/java/util/regex/Pattern.java line 161: > >> 159: * Any character (may or may not match line terminators) >> 160: * {@code \d} >> 161: * A digit: {@code [0-9]} if if > > Looks like there is a superfluous `if` here. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From igraves at openjdk.java.net Wed Mar 9 17:55:47 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Wed, 9 Mar 2022 17:55:47 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v5] In-Reply-To: References: Message-ID: > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Removing superfluous 'if' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7539/files - new: https://git.openjdk.java.net/jdk/pull/7539/files/98fcaa9a..57fef39c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7539/head:pull/7539 PR: https://git.openjdk.java.net/jdk/pull/7539 From naoto at openjdk.java.net Wed Mar 9 18:12:23 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 9 Mar 2022 18:12:23 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v5] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 17:55:47 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Removing superfluous 'if' LGTM. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7539 From bpb at openjdk.java.net Wed Mar 9 18:39:29 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 9 Mar 2022 18:39:29 GMT Subject: RFR: 8254574: PrintWriter handling of InterruptedIOException PrintWriter handling of InterruptedIOException should be removed [v2] In-Reply-To: References: Message-ID: <8nCesNmIZmHJOjhGhSZkqWdJUbKv7QHRFpurI3nvaf0=.cf852c3a-4aaa-4882-90bb-6168869989ef@github.com> > Remove reference to `java.io.InterruptedIOException` from `java.io.PrintStream`, and make the specifications of `checkError()`, `setError()`, and `clearError()` consistent between `java.io.PrintStream` and `java.io.PrintWriter`. Brian Burkhalter 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: 8254574: PrintWriter handling of InterruptedIOException should be removed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7507/files - new: https://git.openjdk.java.net/jdk/pull/7507/files/4015d9c0..95f15465 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7507&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7507&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7507.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7507/head:pull/7507 PR: https://git.openjdk.java.net/jdk/pull/7507 From valeriep at openjdk.java.net Wed Mar 9 19:15:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 19:15:36 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update JarSigner javadoc to make it consistent with previous update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/7f6fe4b5..099a6d92 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=01-02 Stats: 16 lines in 2 files changed: 0 ins; 3 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From simonis at openjdk.java.net Wed Mar 9 19:28:50 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Wed, 9 Mar 2022 19:28:50 GMT Subject: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence [v2] In-Reply-To: <1D4M66CbBg1O5uHteS_kY0pKEos7Olhwlj_1RLBvoCs=.1cf2a416-ba80-421c-95a8-edca93cc55a5@github.com> References: <1D4M66CbBg1O5uHteS_kY0pKEos7Olhwlj_1RLBvoCs=.1cf2a416-ba80-421c-95a8-edca93cc55a5@github.com> Message-ID: <-4WdVBJyFYtvPAaPX7ygL0CvZX-P0bCXOGWRsZGBZVU=.04b5f836-5f10-4da8-a95e-af4df7fb06f7@github.com> On Wed, 11 Nov 2020 11:58:08 GMT, Lance Andersen wrote: >> Hi, >> >> Please review the fix for JDK-8256018 which addresses the issue that the update(ByteBuffer) methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly. >> >> The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the jck:api/java_util/zip,jck:api/java_util/jar continue to run clean. >> >> Best >> Lance > > Lance Andersen has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra blank line I wonder why this change was necessary? Did you see any concrete problems or crashes? If yes, could you please share any details? The code you've fixed with a `reachabilityFence` looks as follows: if (buffer.isDirect()) { try { crc = updateByteBuffer(crc, ((DirectBuffer)buffer).address(), pos, rem); } finally { Reference.reachabilityFence(buffer); } } else if (buffer.hasArray()) { ... } else { ... } buffer.position(limit); // <-- 'buffer' is still alive here (at least in the bytecode) But as you can see, `buffer` is still alive at the end of the method. According to @iwanowww (see [this mail](http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051312.html) during the ["Reduce Chance Of Mistakenly Early Backing Memory Cleanup" discussion](http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/thread.html#51221)) this should suffice because HotSpot computes reachability based on bytecode analysis (rather than analysis of optimized IR). Shouldn't this be enough to keep `buffer` alive until `updateByteBuffer()` has finished working on the buffer? ------------- PR: https://git.openjdk.java.net/jdk/pull/1149 From volker.simonis at gmail.com Wed Mar 9 19:33:07 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 9 Mar 2022 20:33:07 +0100 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: Message-ID: @Alan, @Lance, Sorry for my obtrusiveness, but what's your opinion on this issue? Thank you and best regards, Volker On Fri, Mar 4, 2022 at 11:04 AM Volker Simonis wrote: > > `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater > functionality. `Inflater::inflate(byte[] output, int off, int len)` > currently calls zlib's native `inflate(..)` function and passes the > address of `output[off]` and `len` to it via JNI. > > The specification of zlib's `inflate(..)` function (i.e. the [API > documentation in the original zlib > implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) > doesn't give any guarantees with regard to usage of the output buffer. > It only states that upon completion the function will return the > number of bytes that have been written (i.e. "inflated") into the > output buffer. > > The original zlib implementation only wrote as many bytes into the > output buffer as it inflated. However, this is not a hard requirement > and newer, more performant implementations of the zlib library like > [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) > or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more > bytes of the output buffer than they actually inflate as a scratch > buffer. See https://github.com/simonis/zlib-chromium for a more > detailed description of their approach and its performance benefit. > > These new zlib versions can still be used transparently from Java > (e.g. by putting them into the `LD_LIBRARY_PATH` or by using > `LD_PRELOAD`), because they still fully comply to specification of > `Inflater::inflate(..)`. However, we might run into problems when > using the `Inflater` functionality from the `InflaterInputStream` > class. `InflaterInputStream` is derived from from `InputStream` and as > such, its `read(byte[] b, int off, int len)` method is quite > constrained. It specifically specifies that if *k* bytes have been > read, then "these bytes will be stored in elements `b[off]` through > `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through > `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] > b, int off, int len)` (which is constrained by > `InputStream::read(..)`'s specification) calls > `Inflater::inflate(byte[] b, int off, int len)` and directly passes > its output buffer down to the native zlib `inflate(..)` method which > is free to change the bytes beyond `b[off+`*k*`]` (where *k* is the > number of inflated bytes). > > From a practical point of view, I don't see this as a big problem, > because callers of `InflaterInputStream::read(byte[] b, int off, int > len)` can never know how many bytes will be written into the output > buffer `b` (and in fact its content can always be completely > overwritten). It therefore makes no sense to depend on any data there > being untouched after the call. Also, having used zlib-cloudflare > productively for about two years, we haven't seen real-world issues > because of this behavior yet. However, from a specification point of > view it is easy to artificially construct a program which violates > `InflaterInputStream::read(..)`'s postcondition if using one of the > alterantive zlib implementations. A recently integrated JTreg test > (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" > fails with zlib-chromium but could be easily fixed to run with > alternative implementations as well. > > What should/can be done to solve this problem? I think we have three options: > > 1. Relax the specification of `InflaterInputStream::read(..)` and > specifically note in the API documentation that a call to > `InflaterInputStream::read(byte[] b, int off, int len)` may write more > than *k* characters into `b` where *k* is the returned number of > inflated bytes. Notice that there's a precedence for this approach in > `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden > method of InputStream, returns -1 instead of zero if the end of the > stream has been reached and len==0*". > > 2. Tighten the specification of `Inflater::read(byte[] b, int off, int > len)` to explicitly forbid any writes into the output array `b` beyond > the inflated bytes. > > 3. Change the implementation of `InflaterInputStream::read(..)` to > call `Inflater::read(..)` with a temporary buffer and only copy the > nu,ber of inflated bytes into `InflaterInputStream::read(..)`'s output > buffer. I think we all agree that this is only a theoretic option > because of its unacceptable performance regression. > > I personally favor option 1 but I'm interested in your opinions? > > Thank you and best regards, > Volker From weijun at openjdk.java.net Wed Mar 9 19:49:45 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 9 Mar 2022 19:49:45 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 19:15:36 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update JarSigner javadoc to make it consistent with previous update Sorry if my previous comment confused you, the code and javadoc are not consistent now. src/java.base/share/classes/sun/security/util/SignatureUtil.java line 561: > 559: return (isDSA || bitLength >= 624 ? "SHA384" : "SHA256"); > 560: } > 561: } In this method, "SHA-384" for 7680-bit key (7680 > 7680 is false). src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > 437: * Specifically, if a DSA or RSA key with a key size no less than 7680 > 438: * bits, or an EC key with a key size no less than 512 bits, > 439: * SHA-512 will be used as the hash function for the signature. In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From redestad at openjdk.java.net Wed Mar 9 20:56:46 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Mar 2022 20:56:46 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v12] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 16:52:54 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Restructure encodeUTF8 to reduce code gen issues The regressions I observe on aarch64 in `encodeLatin1Short` and a few others are not in the intrinsic itself but due changes to the surrounding code. Reverting the changes to `String.encodeUTF8` removes the regressions (but also the improvements). Seems some loop optimization is not taking place like it should - or just differently. Going back to check I see that x64 is also affected, meaning this is something that has come in when syncing up with master. I've experimented with adjusting the code to try and workaround and improve code gen, but with only partial success. I'll back out the changes to `String.encodeUTF8`, see if we can deal with the loop opt regression (separately) and return to do the `encodeUTF8` optimization later on. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Wed Mar 9 21:01:13 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Mar 2022 21:01:13 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v13] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits: - Merge branch 'master' into count_positives - Restructure encodeUTF8 to reduce code gen issues - use 32-bit mask to calculate correct remainder value - ary1 not required to have USE_KILL effect - Better implementation for aarch64 returning roughly the count of positive bytes - Document that it's allowed for implementations to return values less than the exact count (iff there are negative bytes) - Clean out and remove vmIntrinsics::_hasNegatives and all related code - s390 impl provided by @RealLucy - PPC impl provided by @TheRealMDoerr - Narrow the bottom_type of CountPositivesNode (always results in a positive int value) - ... and 30 more: https://git.openjdk.java.net/jdk/compare/ff766204...30739e15 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7231/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=12 Stats: 638 lines in 36 files changed: 288 ins; 62 del; 288 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From achung at openjdk.java.net Wed Mar 9 21:16:48 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 9 Mar 2022 21:16:48 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 Message-ID: msg drop for jdk19, Mar 9, 2022 ------------- Commit messages: - open jdk19 l10n msg drop Changes: https://git.openjdk.java.net/jdk/pull/7765/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280400 Stats: 13775 lines in 142 files changed: 12170 ins; 1249 del; 356 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From valeriep at openjdk.java.net Wed Mar 9 22:13:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 9 Mar 2022 22:13:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v3] In-Reply-To: References: Message-ID: <1j7YQWGZ5x2PU7aUm7m2gUBkI_BThArGU6qrn5fYPng=.49a446eb-f48f-4276-b326-f1cea296c1cb@github.com> On Wed, 9 Mar 2022 19:44:39 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update JarSigner javadoc to make it consistent with previous update > > src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java line 439: > >> 437: * Specifically, if a DSA or RSA key with a key size no less than 7680 >> 438: * bits, or an EC key with a key size no less than 512 bits, >> 439: * SHA-512 will be used as the hash function for the signature. > > In this javadoc, SHA-512 for 7680-bit key (7680 is no less than 7680). Right, there are a few places which this is documented. Code and doc aren't closely coupled together plus changed course a few times... I will fix this and double check other files. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From naoto at openjdk.java.net Wed Mar 9 22:29:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 9 Mar 2022 22:29:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 `src/java.base/share/classes/sun/util/resources/CurrencyNames_de.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_ja.properties` `src/java.base/share/classes/sun/util/resources/CurrencyNames_zh_CN.properties` These are part of `jdk.localedata` module. Should be excluded from `java.base` module and apply the diffs to `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_xx.properties` manually. (Note that the first half of it is not necessary when merging). ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From bpb at openjdk.java.net Wed Mar 9 22:57:53 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 9 Mar 2022 22:57:53 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v6] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: <4IRjKJbPoBG6Eq4oDifN7NJIARyDVslSDiN35-ZYHe8=.4cf1eb08-949b-45ee-9ef4-7c3d3e2c4fe0@github.com> On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adapted hashes in ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Enhanced intervals in MathUtils. > Updated references to Schubfach v4. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > > Refactored test classes to better match OpenJDK conventions. > Added tests recommended by Guy Steele and Paul Zimmermann. > - Changed MAX_CHARS to static > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76 Keep PR open. ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From mchung at openjdk.java.net Wed Mar 9 22:59:02 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 9 Mar 2022 22:59:02 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver Message-ID: A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. ------------- Commit messages: - JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver Changes: https://git.openjdk.java.net/jdk/pull/7766/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282776 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7766.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7766/head:pull/7766 PR: https://git.openjdk.java.net/jdk/pull/7766 From redestad at openjdk.java.net Wed Mar 9 23:44:22 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Mar 2022 23:44:22 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v14] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Revert encodeUTF8 for this PR due issues with fragile optimization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/30739e15..58ee73bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=12-13 Stats: 18 lines in 1 file changed: 0 ins; 9 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Wed Mar 9 23:52:44 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Mar 2022 23:52:44 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v14] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 23:44:22 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Revert encodeUTF8 for this PR due issues with fragile optimization Reverting changes to `String.encodeUTF8` brought all `encode`-micros down to effectively no change: https://jmh.morethan.io/?gist=b957cb9457c31141ac71d47f2e10486a (which proves implementing `hasNegatives` using `countPositives != len` has no measurable cost) I consider this the final version for this PR (assuming tests pass). I need someone to review the aarch64 changes in particular, and perhaps someone from the core library team should sign off on the String changes (less of those now). ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Wed Mar 9 23:59:32 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 9 Mar 2022 23:59:32 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v15] In-Reply-To: References: Message-ID: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Fix copyright year in new test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/58ee73bb..bc5a8c80 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From valeriep at openjdk.java.net Thu Mar 10 00:20:36 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 10 Mar 2022 00:20:36 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v4] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Updated to match the latest SignatureUtil.ifcFfcStrength() impl ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/099a6d92..f728aa7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From joehw at openjdk.java.net Thu Mar 10 00:46:44 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 10 Mar 2022 00:46:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: <8oYKi_L4IgNDFUfJ9uXlSl47KULO4j1HudfJg3kVeCU=.90fa019e-8b6f-4a69-870b-cd53c8802490@github.com> On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For the bundles in java.xml: For files with Oracle copyright, update the year to 2022 and @LastModified Mar 2022. Take XPATHErrorResources_ja.java as an example, the copyright year was updated to 2021 and @LastModified: Nov 2021. That's probably the date it was last modified, but as we updating them now along with a number of other files, it would be good to be consistent and change all of them to the current date. For files with the reserved comment block such as SerializerMessages_de.java, do the same as did in XPATHErrorResources_de.java, add the copyright header and LastModified tag with the current date. For files with the Oracle GPL license such as message_zh_CN.properties, do not delete the license header. Instead, update the copyright year to 2022 if there are changes. I don't see any changes were made for many of these files, for example from msg/XMLSchemaMessages_ja.properties to regex/message_zh_CN.properties, the only change was the removal of the header. In the webrev view, some files have the word "undefined" right under the license header, hopefully once the license header is fixed, that would go away as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From smarks at openjdk.java.net Thu Mar 10 01:14:48 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 10 Mar 2022 01:14:48 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Sat, 5 Mar 2022 19:06:03 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refactor tests Sorry, the test changes look like they're heading in the wrong direction. I tried to provide some hints for what I was looking for in my previous comments. At this point, I felt it would have been too time-consuming to provide a bunch of review comments to try to get your proposed tests closer to what I was looking for, so instead I've extended/rewritten the existing `WhiteBoxResizeTest` file: https://github.com/stuart-marks/jdk/blob/JDK-8281631-smarks/test/jdk/java/util/HashMap/WhiteBoxResizeTest.java I hope you're ok with this. Here are some issues I have with the multiple-file approach: * The separate classes tends to obscure things, as the separate files are actually tightly coupled; infrastructure (reflection stuff) and test case setup (Util, TestSuite) are separated from the test, making it hard to see what's going on. * Each test method still does too much work. In general, test methods should do one thing in three phases: setup, perform action, assert results -- the [GivenWhenThen](https://martinfowler.com/bliki/GivenWhenThen.html) pattern. (Yes, I know a lot of tests currently in the regression suite violate this, but I think it's reasonable for new fine-grained combo tests like this one to be held to this standard.) Several of the test methods here do setup, perform an op, make assertions, perform another op, make assertions, perform another op, make more assertions, etc. The reason this is bad is that it's hard to separate out special cases. Consider `WhiteBoxHashMapInitialCapacityTest`. Since this test method tests both lazy allocation and initial capacity allocation, it can't handle the different behavior of `WeakHashMap`. * The need for separate classes is possibly driven by JUnit 4, where the test parameterization mechanism seems to only be available on the granularity of an entire class. (I'm not a JUnit expert, so I might have missed something.) This makes it difficult to structure parameterized tests on a per-method basis, as can be done in TestNG. The existing `WhiteBoxResizeTest` is TestNG, so it seems sensible to extend that, and add several parameterized test methods. I believe the new `WhiteBoxResizeTest` covers all the existing cases as well as the new ones in your tests, plus some additional ones that we've uncovered during this discussion. It covers a reasonable set of cases in the following areas: * combo of various constructors plus populating the map in different ways all get the same expected table size * lazy allocation of table * correct default allocation of table * verification of fix for `WeakHashMap` premature resizing * verification of fix using double instead of float calculation for certain large sizes Here are some notes about what I did. Unfortunately all that's here is the end result. I tried a bunch of experiments and different alternatives, which aren't present here, but I'll try to document some of the processes I went through to get to this result. * Rearranged the infrastructure to accommodate `WeakHashMap`. The `table()` and `capacity()` methods now work for all map classes under test. Really, there are only three classes, and two (`HashMap` and `LinkedHashMap`) have the table in the `HashMap` class, so a simple conditional will work. If additional classes are added, the conditional might turn into a case expression. * Simplified VarHandle setup. The old code had to load some private classes in order to get the exact types to provide to `findVarHandle()`. It's easier to find the field using reflection and then to "unreflect" it into a VarHandle. * Rearranged test methods into pairs of data provider and data-provider-consuming test methods, possibly with some helper methods, demarcated into different sections in the test class. Using TestNG data providers is a bit clunky with `Object[][]` or `Iterator` but it ends up working reasonably well. * The `tableSizeFor()` test is also now a data provider. It probably would have been ok to leave it as a single method with a bunch of asserts, but using a data provider enables using a tabular form for the test data, which I think makes it easier to manage the test cases. * Most test data is tabular. It's fairly straightforward but for some providers it's bit a repetitive to add more test cases. However, I didn't go the next step of compressing out the repetition, because doing so would have made it difficult to exclude special cases. For example, the `WeakHashMap` growth policy for `putAll` differs from the others. * Of note is that some of the larger sizes/capacities are tested using a "fake" map, which reports some size but whose `entrySet` iterator returns only one entry. This works for some of the implementations, so only cases for those are included. * I used helper methods called from the data provider in order to establish a target type for lambdas. This reduces the clutter in the table data. * It's much easier to parameterize constructors using `Supplier` lambdas as method arguments instead of as fields in a helper class. Using a `record` might be helpful here though. * If a parameterized test fails, TestNG will print out the arguments obtained from the data provider that caused the test method to fail. The string form of a lambda isn't useful. Providing a string label is a technique (hack) to identify the failing test case. It's a bit cryptic but it's quite effective. There is a certain amount of brittleness in these tests such that they're prone to failure if the internals of one of the implementations changes. These are whitebox tests after all. But the new organization should facilitate rearrangement of the test cases and test methods if one of the implementations diverges. In addition, if changing one of the implementations causes test failures here, it will point to other implementations that might also need to be changed. The new test is comprehensive enough that we might be able to remove the `Enum/ConstantDirectoryOptimalCapacity` test and the related test that uses those utilities to verify map table sizes. However, that evaluation should be done separately. I suggest you merge this file into this PR in place of the other test files. Once you get this done I can run everything through our internal test system and sponsor this PR for integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From bpb at openjdk.java.net Thu Mar 10 02:37:02 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Mar 2022 02:37:02 GMT Subject: RFR: 8058924: FileReader(String) documentation is insufficient Message-ID: Add a statement to the `java.io` package documentation clarifying how a `String` representing a _pathname string_ is interpreted in the package. ------------- Commit messages: - 8058924: FileReader(String) documentation is insufficient Changes: https://git.openjdk.java.net/jdk/pull/7767/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7767&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8058924 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7767.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7767/head:pull/7767 PR: https://git.openjdk.java.net/jdk/pull/7767 From smarks at openjdk.java.net Thu Mar 10 04:05:40 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 10 Mar 2022 04:05:40 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v14] In-Reply-To: <6RH4kWy7ti-hSyZnp9r14Iygat5p-dHCLDbuzueI_vI=.39fd470b-c893-4e90-906a-2ccc5557e6bc@github.com> References: <6RH4kWy7ti-hSyZnp9r14Iygat5p-dHCLDbuzueI_vI=.39fd470b-c893-4e90-906a-2ccc5557e6bc@github.com> Message-ID: On Sat, 5 Mar 2022 21:27:47 GMT, Marcono1234 wrote: > Would it make sense to override next(int) to always throw an exception? Even though it should not be possible for a user to call the method on the wrapper, it might be better to be on the safe side; for example in case a new Random method which depends on next(int) is added in the future (even though this is unlikely). Heh, interesting. On the one hand, it can only be called reflectively, and doing so would be an odd thing to do, so who cares. I initially thought it would NPE immediately on `seed`, but it turns out that `seed` is actually initialized by the wrapper's call to the superclass constructor. So calling `next(int)` will actually advance the random state in the superclass, quite independently of the wrapped `RandomGenerator`. So yeah maybe having `next(int)` throw UOE might be reasonable. It's good documentation for the wrapper as well. As an aside it might be reasonable to initialize `seed` to `null` in that constructor, since the seed should never be used. The NPE will fail-fast in the unlikely event that something ends up trying to use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From smarks at openjdk.java.net Thu Mar 10 04:22:42 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 10 Mar 2022 04:22:42 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v15] In-Reply-To: References: Message-ID: On Sun, 6 Mar 2022 01:39:02 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Update javadoc I've created a draft CSR for this change: https://bugs.openjdk.java.net/browse/JDK-8282928 Please review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From dholmes at openjdk.java.net Thu Mar 10 04:50:37 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Mar 2022 04:50:37 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 22:52:41 GMT, Mandy Chung wrote: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. Hi Mandy, This is an enhancement request not a bug and I don't think adding a performance penalty to all correct code just to produce a slightly clearer NPE message for broken code, is the right trade-off here. Cheers, David ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From duke at openjdk.java.net Thu Mar 10 06:40:49 2022 From: duke at openjdk.java.net (Suminda Sirinath Salpitikorala Dharmasena) Date: Thu, 10 Mar 2022 06:40:49 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v6] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adapted hashes in ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Enhanced intervals in MathUtils. > Updated references to Schubfach v4. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > > Refactored test classes to better match OpenJDK conventions. > Added tests recommended by Guy Steele and Paul Zimmermann. > - Changed MAX_CHARS to static > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76 Why is this still not merged? ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From plevart at openjdk.java.net Thu Mar 10 07:06:40 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 10 Mar 2022 07:06:40 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 00:19:58 GMT, Joe Darcy wrote: > > The mapping from Location to AccessFlag(s) could be implemented event without using a Map. You just have to be careful not to use EnumSet for that (i.e. before AccessFlag enum constants are fully initialized) - an ArrayList is better for this case anyway. Also, conversion from ModuleDescriptor modifier(s) to AccessFlag(s) could be done without first creating a bitmask and then re-constructing a set of AccessFlag(s) from it. Reflective object modifiers can only be translated via bitmask, but various ModuleDescriptor Modifier(s) may have a direct mapping to corresponding AccessFlag(s). For example: > > [plevart at 5a3cd8f](https://github.com/plevart/jdk/commit/5a3cd8f6851a0deae7e3e5028bba9a51d7863929) > > Yes, I made the same observation for the module-related modifiers when coding this up; I'll look to add some API support to avoid the need to detour through bitmasks. > > To get the public API worked out, I wanted to avoid complications in inter-dependent class initialization. Thanks for suggesting an alternative; I'll consider that when I resume work on this PR (need to start writing some tests...) Thanks. On a second thought, maybe the common bitmask representation is the way to go. One one hand it must be computed from the set of module-related Modifier set(s), but then again such bitmask is very easy to cache economically (a single int field, no synchronization). When you have a bitmask at hand and a list of all possible elements (the universe), a very efficient implementation of a Set is possible (similar to EnumSet). Such AccessFlagSet instances do not need to be cached since they are just thin views over existing "permanent" structures and will, as such, typically be optimized away by JIT. Note the particularly efficient .contains() implementation which just checks two bitmasks (the flag mask and the location mask). https://github.com/plevart/jdk/commit/de9f2614da56775be4ae07c6781cbec9fbd39930 ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From plevart at openjdk.java.net Thu Mar 10 07:45:45 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Thu, 10 Mar 2022 07:45:45 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy 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 26 additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8266670 > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/b7d02b1c...14980605 > Such AccessFlagSet ... > > [plevart at de9f261](https://github.com/plevart/jdk/commit/de9f2614da56775be4ae07c6781cbec9fbd39930) ...also needs proper hashCode/equals/toString implementations of course: https://github.com/plevart/jdk/commit/1ad5e1f925029908ecf8b21d793c25aec34a80cb ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From duke at openjdk.java.net Thu Mar 10 08:52:19 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 10 Mar 2022 08:52:19 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 16:09:01 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes > > src/java.base/share/classes/java/lang/invoke/MethodType.java line 910: > >> 908: if (skipPos > myLen || myLen - skipPos > fullLen) >> 909: return false; >> 910: List> myList = List.of(ptypes); > > imo should revert this one together with that proxy parameter one Reverted ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From duke at openjdk.java.net Thu Mar 10 08:52:17 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Thu, 10 Mar 2022 08:52:17 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3] In-Reply-To: References: Message-ID: > `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. > > In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): > - `MethodHandles.longestParameterList()` never returns null > - parameter types are never null > - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null > - exceptions types of method signature are never null ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: 8282662: Revert dubious changes in MethodType ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7729/files - new: https://git.openjdk.java.net/jdk/pull/7729/files/5bbe8c4e..e765c42a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7729.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7729/head:pull/7729 PR: https://git.openjdk.java.net/jdk/pull/7729 From dfuchs at openjdk.java.net Thu Mar 10 10:34:43 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 10 Mar 2022 10:34:43 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 For simple webserver resource files - should the copyright year be 2022? ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From ihse at openjdk.java.net Thu Mar 10 11:23:44 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 10 Mar 2022 11:23:44 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 07:58:51 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > Hi Ioi, > > some questions, comments inline. > > Like David in the comments, I am also a bit vague on the usefulness, but I may not know the whole story. Is it to enable repackagers like Debian to check the "reproducable" tickbox on their OpenJDK package? Or is there a practical need for this? > > Thanks, Thomas @tstuefe Without commenting on Ioi's actual implementation, let me explain a bit on the importance of this fix. Reproducible builds is not just a "checkbox", any more than "does not crash on startup" is a checkbox. It is an important security tool. See e.g. https://reproducible-builds.org/ for more information. The problem with CDS generating non-deterministic output is that during the build process we generate the file classes.jsa (and classes_nocoops.jsa). These files in turn are included in the java.base jmod, which in turn is included in the entire jlinked image. So if classes.jsa gets random bits, these random bits propagate to java.base.jmod and finally, to the entire jimage. This means that it is imposslbe to get bit-by-bit reproducibility verification of the entire JDK build. For several years, we have relentlessly (albeit with an unfortunately low priority) addressed and fixed indeterminism in the build of the JDK. We are now at the point were the only major issue is the randomness of classes.jsa and classes_nocoops.jsa. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From ihse at openjdk.java.net Thu Mar 10 12:14:44 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 10 Mar 2022 12:14:44 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 11:45:59 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > The "heap dump" aspect of this is not something I'm familiar with, but if the threads don't affect the list of classes dumped, they surely must affect what is in the heap dump otherwise their execution would not be an issue. So you must be sacrificing something by not having these threads start. @dholmes-ora That something is "sacrificed" does not follow from that something is "different". The list of classes to dump is specified in the lib/classlist file, which is generated during the build. The process of creating this involves running a suitable "exercise most important parts" java program, and logging the classes loaded. This class file is then post-processed (sorted) to make sure it is reproducible for the same JDK code base. As Ioi say, in this case threads are started freely, and may run in any non-deterministic order. At the next stage, we take this file (which is just done implicitly by -Xshare:dump), and generate the actual CDS archive, classes.jsa. Now it turns out this generation is non-deterministic. And Ioi's analysis is that this is due to thread non-determinism. So if we just disable threads during the dump process (where we are not really running the JVM "actually" -- it's a special mode, where we don't even have a Java program to run!), there's no harm in that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From dholmes at openjdk.java.net Thu Mar 10 12:56:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Mar 2022 12:56:43 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 12:11:06 GMT, Magnus Ihse Bursie wrote: >> The "heap dump" aspect of this is not something I'm familiar with, but if the threads don't affect the list of classes dumped, they surely must affect what is in the heap dump otherwise their execution would not be an issue. So you must be sacrificing something by not having these threads start. > > @dholmes-ora That something is "sacrificed" does not follow from that something is "different". The list of classes to dump is specified in the lib/classlist file, which is generated during the build. > > The process of creating this involves running a suitable "exercise most important parts" java program, and logging the classes loaded. This class file is then post-processed (sorted) to make sure it is reproducible for the same JDK code base. > > As Ioi say, in this case threads are started freely, and may run in any non-deterministic order. > > At the next stage, we take this file (which is just done implicitly by -Xshare:dump), and generate the actual CDS archive, classes.jsa. Now it turns out this generation is non-deterministic. And Ioi's analysis is that this is due to thread non-determinism. So if we just disable threads during the dump process (where we are not really running the JVM "actually" -- it's a special mode, where we don't even have a Java program to run!), there's no harm in that. @magicus the issue is not the list of classes dumped, or their format in the dump. As Ioi indicated that list is fixed. The issue is with the heap dump part of the archive. Running these other threads affects the heap so by not running them with end up with a different heap. So the question is whether there is anything about having a different heap dumped that we need to be concerned about. We dump the heap into the archive for a reason and this changes what we dump, ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From ihse at openjdk.java.net Thu Mar 10 12:56:44 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 10 Mar 2022 12:56:44 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: <_gEQbuQSg9m85mgGK8CTapGQ8lHNcaZk6swKv_h3b2c=.22aee41e-3faa-432f-aa9b-e1b21f40a63c@github.com> On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed zero build Well, previously we'd get different dumps on different runs. If that was an issue, surely it would have manifested itself by now? With this change, we'll just get the same dump each run. I fail to see how that could be a risk. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From stuefe at openjdk.java.net Thu Mar 10 12:56:44 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 10 Mar 2022 12:56:44 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: <3rBXZ8EImtvDdKrC0ORD6PLNvXA46aPXo4l8hKiRUkQ=.461eac24-d5e3-483a-a567-1ed22aa1dade@github.com> On Wed, 9 Mar 2022 07:58:51 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > Hi Ioi, > > some questions, comments inline. > > Like David in the comments, I am also a bit vague on the usefulness, but I may not know the whole story. Is it to enable repackagers like Debian to check the "reproducable" tickbox on their OpenJDK package? Or is there a practical need for this? > > Thanks, Thomas > @tstuefe Without commenting on Ioi's actual implementation, let me explain a bit on the importance of this fix. > > Reproducible builds is not just a "checkbox", any more than "does not crash on startup" is a checkbox. It is an important security tool. See e.g. https://reproducible-builds.org/ for more information. > Hi @magicus, thanks for explaining, and for the link. That one was a good explanation. I had no idea, but I'm convinced now. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From magnus.ihse.bursie at oracle.com Thu Mar 10 12:58:58 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 10 Mar 2022 13:58:58 +0100 Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: <_gEQbuQSg9m85mgGK8CTapGQ8lHNcaZk6swKv_h3b2c=.22aee41e-3faa-432f-aa9b-e1b21f40a63c@github.com> References: <_gEQbuQSg9m85mgGK8CTapGQ8lHNcaZk6swKv_h3b2c=.22aee41e-3faa-432f-aa9b-e1b21f40a63c@github.com> Message-ID: <30b40101-1af6-8d6f-cbfe-758001d588a8@oracle.com> The Skara bots messed up this one badly. It was a reply to David's comment, not Ioi's latest push. /Magnus On 2022-03-10 13:56, Magnus Ihse Bursie wrote: > On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: > >>> This patch makes the result of "java -Xshare:dump" deterministic: >>> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >>> - Fixed a problem in hashtable ordering in heapShared.cpp >>> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >>> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >>> >>> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >>> >>> Testing under way: >>> - tier1~tier5 >>> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > Well, previously we'd get different dumps on different runs. If that was an issue, surely it would have manifested itself by now? With this change, we'll just get the same dump each run. I fail to see how that could be a risk. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7748 From zgu at openjdk.java.net Thu Mar 10 13:39:04 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 10 Mar 2022 13:39:04 GMT Subject: RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c Message-ID: Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a `jboolean*`, instead of `jboolean` ------------- Commit messages: - 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c Changes: https://git.openjdk.java.net/jdk/pull/7775/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7775&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282897 Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7775.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7775/head:pull/7775 PR: https://git.openjdk.java.net/jdk/pull/7775 From dholmes at openjdk.java.net Thu Mar 10 13:42:40 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Mar 2022 13:42:40 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: <_gEQbuQSg9m85mgGK8CTapGQ8lHNcaZk6swKv_h3b2c=.22aee41e-3faa-432f-aa9b-e1b21f40a63c@github.com> References: <_gEQbuQSg9m85mgGK8CTapGQ8lHNcaZk6swKv_h3b2c=.22aee41e-3faa-432f-aa9b-e1b21f40a63c@github.com> Message-ID: <5aktAeTElag7Ggnr0HIfRVDSf6NQtaEpjQLjqeyBIeg=.62824610-1602-4853-91d2-beb28e18faa4@github.com> On Thu, 10 Mar 2022 12:50:58 GMT, Magnus Ihse Bursie wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > Well, previously we'd get different dumps on different runs. If that was an issue, surely it would have manifested itself by now? With this change, we'll just get the same dump each run. I fail to see how that could be a risk. @magicus I think we need @iklam to weigh in here and explain exactly what the "heap dump" consists of and how not running those threads affects its contents. Presently the heap dump is potentially different on each run, IIUC, only due to the order of its contents, not the contents themselves. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From ihse at openjdk.java.net Thu Mar 10 13:54:48 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 10 Mar 2022 13:54:48 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 05:10:44 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed zero build I think he already did. I'm quoting: > However, the CDS archive also contains a heap dump, which includes Java HashMaps. If I allow those 3 Java threads to start, some HashMaps in the module graph will have unstable ordering. I think the reason is concurrent thread execution causes unstable assignment of the identity_hash for objects in the heap dump. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From aph at openjdk.java.net Thu Mar 10 14:05:49 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 10 Mar 2022 14:05:49 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v12] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 11:38:34 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Removing +LogCompilation flag. > - 8279508: Review comments resolved.` > - 8279508: Adding descriptive comments. > - 8279508: Review comments resolved. > - 8279508: Review comments resolved. > - 8279508: Fixing for windows failure. > - 8279508: Adding few descriptive comments. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d07f7c76...547f4e31 test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java line 114: > 112: for (int i = 0; i < TESTSIZE; i++) { > 113: ResF[i] = Math.round(FargV1[i]); > 114: } I think that this is wrong: you should not be storing the result into a float array because it requires an extra integer->float conversion, which distorts the timings. You need `resI` and `resL` for the results of `Math.round`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From aph at openjdk.java.net Thu Mar 10 14:10:52 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 10 Mar 2022 14:10:52 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v12] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 11:38:34 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: > > - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Removing +LogCompilation flag. > - 8279508: Review comments resolved.` > - 8279508: Adding descriptive comments. > - 8279508: Review comments resolved. > - 8279508: Review comments resolved. > - 8279508: Fixing for windows failure. > - 8279508: Adding few descriptive comments. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d07f7c76...547f4e31 test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java line 70: > 68: } > 69: > 70: FargV1 = new float[TESTSIZE]; `FargV1` is not initialized. You need to set `i = 0;` here. test/micro/org/openjdk/bench/java/math/FpRoundingBenchmark.java line 78: > 76: > 77: for (; i < TESTSIZE; i++) { > 78: FargV1[i] = r.nextFloat()*TESTSIZE; This is an unrealistically narrow range of values. I'd use Suggestion: FargV1[i] = Float.intBitsToFloat(r.nextInt()); ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Thu Mar 10 14:11:42 2022 From: duke at openjdk.java.net (Maxim Kartashev) Date: Thu, 10 Mar 2022 14:11:42 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v4] In-Reply-To: References: Message-ID: <_7lJM4Ck_giPtQBYb_Yfsv0ytHQ_AX1fmLd4rfF3Tt0=.5436db52-2eec-42fa-8dd1-0377df1956c1@github.com> On Mon, 7 Mar 2022 16:46:28 GMT, Roger Riggs wrote: >> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverted addition of the test via echo > > As an alternative fix, please take a look at Draft PR: https://github.com/openjdk/jdk/pull/7709. > > In the default handling of arguments, the check for what is quoted is reverted to prior to 8255068. First and last quotes are sufficient to identify a "quoted" string. The check for a backslash ("\") is removed. > This original check is sufficient for `jdk.lang.Process.allowAmbiguousCommands = true`. > > For the case where the system property `jdk.lang.Process.allowAmbiguousCommands = false` > and the argument has first and last quotes, a backslash ("\") before the final quote must not allow the quote to interpreted as a literal quote and merge the following argument. The backslashes will doubled to prevent the interpretation of the quote as a literal. This is the correct encoding if the command uses the ".exe" encoding, when reparsing the arguments the doubled backslashes are reduced to the original contents. > When the command is using the simpler parsing that does not support literal quotes, the backslash before the quote is typically is a trailing backslash on a file path and in that case the additional backslash is redundant and has no effect on the interpretation of the argument as a directory path. > > The PR includes a test of the 12 combinations of invoking an "java"/.exe program, a .cmd script, and a Visual Basic script (which uses the .exe rules but different command line parser); with and without application quotes and compares the actual results with the expected arguments. @RogerRiggs I believe your patch fixes the use case(s) we are interested in. Would be good to see it merged into `master`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From darcy at openjdk.java.net Thu Mar 10 14:32:46 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Mar 2022 14:32:46 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com> References: <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com> Message-ID: <7lwsCvdSjkvDYJNwuA7fVPrWFUbzchuwx0Z3IID5VZw=.0c00c3d7-2106-40df-88bc-38bf7e2655f9@github.com> On Fri, 4 Mar 2022 19:04:40 GMT, Jatin Bhateja wrote: >> IMO RoundTests should have a explicit @run tag without any VM options as well. >> >> Do the added VM options run on all platforms in question? What is the approximate time to run the test run compared to before? > > Hi @jddarcy , > > Test has been modified on the same lines using generic options which manipulate compilation thresholds and agnostic to target platforms. > > * @run main/othervm -XX:Tier3CompileThreshold=100 -XX:CompileThresholdScaling=0.01 -XX:+TieredCompilation RoundTests > > Verified that RoundTests::test* methods gets compiled by c2. > Test execution time with and without change is almost same ~7.80sec over Skylake-server. > > Regards To be more explicit, the existing RoundTests.java test runs in a fraction of a second. The updated test runs many times slower, even if now under 10 second, at least on some platforms. Can something closer to the original performance be restored? As a tier 1 library test, these tests are run quite frequently. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From Alan.Bateman at oracle.com Thu Mar 10 14:41:31 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 10 Mar 2022 14:41:31 +0000 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: Message-ID: <653a3349-6780-0541-3d4b-cbf3b14f87d7@oracle.com> On 09/03/2022 19:33, Volker Simonis wrote: > @Alan, @Lance, > > Sorry for my obtrusiveness, but what's your opinion on this issue? > I saw your mail but I haven't had time to study it yet and see if the spec option you prefer is the best. I will try to get time next week. -Alan From darcy at openjdk.java.net Thu Mar 10 14:54:54 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 10 Mar 2022 14:54:54 GMT Subject: RFR: JDK-8266670: Better modeling of access flags in core reflection [v17] In-Reply-To: References: Message-ID: On Sat, 5 Mar 2022 19:54:44 GMT, Joe Darcy wrote: >> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level. >> >> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic). >> >> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation. >> >> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced. >> >> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions. >> >> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along. > > Joe Darcy 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 26 additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8266670 > - Make workding changes suggested in review feedback. > - Merge branch 'master' into JDK-8266670 > - Typo fix; add implSpec to Executable. > - Appease jcheck. > - Fix some bugs found by inspection, docs cleanup. > - Merge branch 'master' into JDK-8266670 > - Initial support for accessFlags methods > - Add mask to access flag functionality. > - ... and 16 more: https://git.openjdk.java.net/jdk/compare/f992eace...14980605 > > > The mapping from Location to AccessFlag(s) could be implemented event without using a Map. You just have to be careful not to use EnumSet for that (i.e. before AccessFlag enum constants are fully initialized) - an ArrayList is better for this case anyway. Also, conversion from ModuleDescriptor modifier(s) to AccessFlag(s) could be done without first creating a bitmask and then re-constructing a set of AccessFlag(s) from it. Reflective object modifiers can only be translated via bitmask, but various ModuleDescriptor Modifier(s) may have a direct mapping to corresponding AccessFlag(s). For example: > > > [plevart at 5a3cd8f](https://github.com/plevart/jdk/commit/5a3cd8f6851a0deae7e3e5028bba9a51d7863929) > > > > > > Yes, I made the same observation for the module-related modifiers when coding this up; I'll look to add some API support to avoid the need to detour through bitmasks. > > To get the public API worked out, I wanted to avoid complications in inter-dependent class initialization. Thanks for suggesting an alternative; I'll consider that when I resume work on this PR (need to start writing some tests...) Thanks. > > On a second thought, maybe the common bitmask representation is the way to go. One one hand it must be computed from the set of module-related Modifier set(s), but then again such bitmask is very easy to cache economically (a single int field, no synchronization). When you have a bitmask at hand and a list of all possible elements (the universe), a very efficient implementation of a Set is possible (similar to EnumSet). Such AccessFlagSet instances do not need to be cached since they are just thin views over existing "permanent" structures and will, as such, typically be optimized away by JIT. Note the particularly efficient .contains() implementation which just checks two bitmasks (the flag mask and the location mask). > > [plevart at de9f261](https://github.com/plevart/jdk/commit/de9f2614da56775be4ae07c6781cbec9fbd39930) FWIW, I did link this issue to the RFE [JDK-8145048](https://bugs.openjdk.java.net/browse/JDK-8145048) consider enhancements to EnumMap and EnumSet, which includes a request an immutable EnumSet. ------------- PR: https://git.openjdk.java.net/jdk/pull/7445 From shade at openjdk.java.net Thu Mar 10 15:31:44 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 10 Mar 2022 15:31:44 GMT Subject: RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu wrote: > Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a `jboolean*`, instead of `jboolean` Looks fine to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7775 From duke at openjdk.java.net Thu Mar 10 16:00:48 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 10 Mar 2022 16:00:48 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v27] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <5IoShMtVNPwAlNlDFYWzEhQ4VIf7J7up1hDHq2K8iKs=.c08f2d51-d8df-46b2-a341-765ace1054a6@github.com> On Thu, 10 Mar 2022 01:11:03 GMT, Stuart Marks wrote: > Sorry, the test changes look like they're heading in the wrong direction. I tried to provide some hints for what I was looking for in my previous comments. At this point, I felt it would have been too time-consuming to provide a bunch of review comments to try to get your proposed tests closer to what I was looking for, so instead I've extended/rewritten the existing `WhiteBoxResizeTest` file: > > https://github.com/stuart-marks/jdk/blob/JDK-8281631-smarks/test/jdk/java/util/HashMap/WhiteBoxResizeTest.java > > I hope you're ok with this. > > Here are some issues I have with the multiple-file approach: > > * The separate classes tends to obscure things, as the separate files are actually tightly coupled; infrastructure (reflection stuff) and test case setup (Util, TestSuite) are separated from the test, making it hard to see what's going on. > * Each test method still does too much work. In general, test methods should do one thing in three phases: setup, perform action, assert results -- the [GivenWhenThen](https://martinfowler.com/bliki/GivenWhenThen.html) pattern. (Yes, I know a lot of tests currently in the regression suite violate this, but I think it's reasonable for new fine-grained combo tests like this one to be held to this standard.) Several of the test methods here do setup, perform an op, make assertions, perform another op, make assertions, perform another op, make more assertions, etc. The reason this is bad is that it's hard to separate out special cases. Consider `WhiteBoxHashMapInitialCapacityTest`. Since this test method tests both lazy allocation and initial capacity allocation, it can't handle the different behavior of `WeakHashMap`. > * The need for separate classes is possibly driven by JUnit 4, where the test parameterization mechanism seems to only be available on the granularity of an entire class. (I'm not a JUnit expert, so I might have missed something.) This makes it difficult to structure parameterized tests on a per-method basis, as can be done in TestNG. > > The existing `WhiteBoxResizeTest` is TestNG, so it seems sensible to extend that, and add several parameterized test methods. I believe the new `WhiteBoxResizeTest` covers all the existing cases as well as the new ones in your tests, plus some additional ones that we've uncovered during this discussion. It covers a reasonable set of cases in the following areas: > > * combo of various constructors plus populating the map in different ways all get the same expected table size > * lazy allocation of table > * correct default allocation of table > * verification of fix for `WeakHashMap` premature resizing > * verification of fix using double instead of float calculation for certain large sizes > > Here are some notes about what I did. Unfortunately all that's here is the end result. I tried a bunch of experiments and different alternatives, which aren't present here, but I'll try to document some of the processes I went through to get to this result. > > * Rearranged the infrastructure to accommodate `WeakHashMap`. The `table()` and `capacity()` methods now work for all map classes under test. Really, there are only three classes, and two (`HashMap` and `LinkedHashMap`) have the table in the `HashMap` class, so a simple conditional will work. If additional classes are added, the conditional might turn into a case expression. > * Simplified VarHandle setup. The old code had to load some private classes in order to get the exact types to provide to `findVarHandle()`. It's easier to find the field using reflection and then to "unreflect" it into a VarHandle. > * Rearranged test methods into pairs of data provider and data-provider-consuming test methods, possibly with some helper methods, demarcated into different sections in the test class. Using TestNG data providers is a bit clunky with `Object[][]` or `Iterator` but it ends up working reasonably well. > * The `tableSizeFor()` test is also now a data provider. It probably would have been ok to leave it as a single method with a bunch of asserts, but using a data provider enables using a tabular form for the test data, which I think makes it easier to manage the test cases. > * Most test data is tabular. It's fairly straightforward but for some providers it's bit a repetitive to add more test cases. However, I didn't go the next step of compressing out the repetition, because doing so would have made it difficult to exclude special cases. For example, the `WeakHashMap` growth policy for `putAll` differs from the others. > * Of note is that some of the larger sizes/capacities are tested using a "fake" map, which reports some size but whose `entrySet` iterator returns only one entry. This works for some of the implementations, so only cases for those are included. > * I used helper methods called from the data provider in order to establish a target type for lambdas. This reduces the clutter in the table data. > * It's much easier to parameterize constructors using `Supplier` lambdas as method arguments instead of as fields in a helper class. Using a `record` might be helpful here though. > * If a parameterized test fails, TestNG will print out the arguments obtained from the data provider that caused the test method to fail. The string form of a lambda isn't useful. Providing a string label is a technique (hack) to identify the failing test case. It's a bit cryptic but it's quite effective. > > There is a certain amount of brittleness in these tests such that they're prone to failure if the internals of one of the implementations changes. These are whitebox tests after all. But the new organization should facilitate rearrangement of the test cases and test methods if one of the implementations diverges. In addition, if changing one of the implementations causes test failures here, it will point to other implementations that might also need to be changed. > > The new test is comprehensive enough that we might be able to remove the `Enum/ConstantDirectoryOptimalCapacity` test and the related test that uses those utilities to verify map table sizes. However, that evaluation should be done separately. > > I suggest you merge this file into this PR in place of the other test files. Once you get this done I can run everything through our internal test system and sponsor this PR for integration. Thanks for your help. A quick glance: that is really big differences between the designs, but I do accept that sometimes there be no absolute right and wrong in designs, and consistency to the group is important. So I will have a look at your version of this test and it functionally correct and can cover our newly found cases, I'm glad to change the tests to your version. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Mar 10 16:13:42 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 10 Mar 2022 16:13:42 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with five additional commits since the last revision: - clean out tests - Remove 'randomness' keyword. - Cleanup and commenting. - initial rewrite of WhiteBoxResizeTest - Restore WhiteBoxResizeTest.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/49aeef20..11a57a2d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=27 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=26-27 Stats: 845 lines in 6 files changed: 311 ins; 534 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From igraves at openjdk.java.net Thu Mar 10 16:17:16 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 10 Mar 2022 16:17:16 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v6] In-Reply-To: References: Message-ID: > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters Ian Graves has updated the pull request incrementally with one additional commit since the last revision: Adding description of word-boundary regex ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7539/files - new: https://git.openjdk.java.net/jdk/pull/7539/files/57fef39c..77f9a5b6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7539/head:pull/7539 PR: https://git.openjdk.java.net/jdk/pull/7539 From duke at openjdk.java.net Thu Mar 10 16:18:45 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 10 Mar 2022 16:18:45 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> Message-ID: <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> On Thu, 10 Mar 2022 16:13:42 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with five additional commits since the last revision: > > - clean out tests > - Remove 'randomness' keyword. > - Cleanup and commenting. > - initial rewrite of WhiteBoxResizeTest > - Restore WhiteBoxResizeTest.java test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 116: > 114: } > 115: > 116: void putN(Map map, int n) { @stuart-marks well we know this is correct for WeakHashMap when n < IntegerCache.high because we have Integer constant pool, but I think it be better to manlly make it sure it is referenced, as IntegerCache.high is configurable. test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 290: > 288: cases.addAll(genPopulatedCapacityCases(12, 16)); > 289: cases.addAll(genPopulatedCapacityCases(13, 32)); > 290: cases.addAll(genPopulatedCapacityCases(64, 128)); @stuart-marks should there better be a loop from 1 to 64? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From igraves at openjdk.java.net Thu Mar 10 16:23:13 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 10 Mar 2022 16:23:13 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v7] In-Reply-To: References: Message-ID: <36oj_s2k_5SjMNaeW5VaM1chgzDEHBRv43yjjrt1GHM=.22fb0c12-2cac-4679-977d-f78620994480@github.com> > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters Ian Graves has updated the pull request incrementally with 196 additional commits since the last revision: - Merge branch 'bug-8264160' of github.com:igraves/jdk into bug-8264160 - Adding description of word-boundary regex - Removing superfluous 'if' - Updating with additional descriptors. Removing DataProvider import - 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. Reviewed-by: rriggs, lancea - 8275640: (win) java.net.NetworkInterface issues with IPv6-only environments Reviewed-by: msheppar, dfuchs - 8282295: SymbolPropertyEntry::set_method_type fails with assert Reviewed-by: hseigel - 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle hidden classes correctly Reviewed-by: sgehwolf, dnsimon - 8282769: BSD date cannot handle all ISO 8601 formats Reviewed-by: erikj - 8282770: Set source date in jib profiles from buildId Reviewed-by: erikj - ... and 186 more: https://git.openjdk.java.net/jdk/compare/77f9a5b6...ef1e4d5b ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7539/files - new: https://git.openjdk.java.net/jdk/pull/7539/files/77f9a5b6..ef1e4d5b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7539&range=05-06 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7539.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7539/head:pull/7539 PR: https://git.openjdk.java.net/jdk/pull/7539 From duke at openjdk.java.net Thu Mar 10 16:26:45 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 10 Mar 2022 16:26:45 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v29] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: manually create reference for ensuring test for WeakHashMap when IntegerCache.high is configured/changed default value. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/11a57a2d..3f1e0e7c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=28 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=27-28 Stats: 18 lines in 1 file changed: 16 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Mar 10 16:26:46 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 10 Mar 2022 16:26:46 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> Message-ID: On Thu, 10 Mar 2022 16:15:03 GMT, XenoAmess wrote: >> XenoAmess has updated the pull request incrementally with five additional commits since the last revision: >> >> - clean out tests >> - Remove 'randomness' keyword. >> - Cleanup and commenting. >> - initial rewrite of WhiteBoxResizeTest >> - Restore WhiteBoxResizeTest.java > > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 116: > >> 114: } >> 115: >> 116: void putN(Map map, int n) { > > @stuart-marks well we know this is correct for WeakHashMap when n < IntegerCache.high because we have Integer constant pool, but I think it be better to manlly make it sure it is referenced, as IntegerCache.high is configurable. @stuart-marks please have a look in changes in the latest commit, I think we'd better to manually create references for keys like that. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From igraves at openjdk.java.net Thu Mar 10 16:27:46 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 10 Mar 2022 16:27:46 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v7] In-Reply-To: <36oj_s2k_5SjMNaeW5VaM1chgzDEHBRv43yjjrt1GHM=.22fb0c12-2cac-4679-977d-f78620994480@github.com> References: <36oj_s2k_5SjMNaeW5VaM1chgzDEHBRv43yjjrt1GHM=.22fb0c12-2cac-4679-977d-f78620994480@github.com> Message-ID: On Thu, 10 Mar 2022 16:23:13 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has updated the pull request incrementally with 196 additional commits since the last revision: > > - Merge branch 'bug-8264160' of github.com:igraves/jdk into bug-8264160 > - Adding description of word-boundary regex > - Removing superfluous 'if' > - Updating with additional descriptors. Removing DataProvider import > - 8281560: Matcher.hitEnd returns unexpected results in presence of CANON_EQ flag. > > Reviewed-by: rriggs, lancea > - 8275640: (win) java.net.NetworkInterface issues with IPv6-only environments > > Reviewed-by: msheppar, dfuchs > - 8282295: SymbolPropertyEntry::set_method_type fails with assert > > Reviewed-by: hseigel > - 8281266: [JVMCI] MetaUtil.toInternalName() doesn't handle hidden classes correctly > > Reviewed-by: sgehwolf, dnsimon > - 8282769: BSD date cannot handle all ISO 8601 formats > > Reviewed-by: erikj > - 8282770: Set source date in jib profiles from buildId > > Reviewed-by: erikj > - ... and 186 more: https://git.openjdk.java.net/jdk/compare/77f9a5b6...ef1e4d5b Something very odd is going on with this PR. I am looking into it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From zgu at openjdk.java.net Thu Mar 10 16:42:45 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 10 Mar 2022 16:42:45 GMT Subject: RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 15:28:15 GMT, Aleksey Shipilev wrote: > Looks fine to me. Thanks, @shipilev ------------- PR: https://git.openjdk.java.net/jdk/pull/7775 From naoto at openjdk.java.net Thu Mar 10 17:03:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 17:03:45 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From dfuchs at openjdk.java.net Thu Mar 10 17:09:44 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 10 Mar 2022 17:09:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:00:09 GMT, Naoto Sato wrote: > IIRC, localized resource files should have the same copyright year as the base English one. That's what I was told by the l10n engineer when I had the same comment. Thanks Naoto! I have no objection then. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From naoto at openjdk.java.net Thu Mar 10 17:14:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 17:14:44 GMT Subject: RFR: 8058924: FileReader(String) documentation is insufficient In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 02:30:35 GMT, Brian Burkhalter wrote: > Add a statement to the `java.io` package documentation clarifying how a `String` representing a _pathname string_ is interpreted in the package. Looks good, Brian. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7767 From naoto at openjdk.java.net Thu Mar 10 17:22:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 17:22:45 GMT Subject: RFR: 8058924: FileReader(String) documentation is insufficient In-Reply-To: References: Message-ID: <0JvU7ZjyfSq_KwQ4oFCobGconOFzFxdfs35DBNCzkyg=.594ee0d0-0844-4a03-bd07-2f1899e06a05@github.com> On Thu, 10 Mar 2022 02:30:35 GMT, Brian Burkhalter wrote: > Add a statement to the `java.io` package documentation clarifying how a `String` representing a _pathname string_ is interpreted in the package. I believe a CSR is needed for this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7767 From igraves at openjdk.java.net Thu Mar 10 17:23:45 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Thu, 10 Mar 2022 17:23:45 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v7] In-Reply-To: <36oj_s2k_5SjMNaeW5VaM1chgzDEHBRv43yjjrt1GHM=.22fb0c12-2cac-4679-977d-f78620994480@github.com> References: <36oj_s2k_5SjMNaeW5VaM1chgzDEHBRv43yjjrt1GHM=.22fb0c12-2cac-4679-977d-f78620994480@github.com> Message-ID: On Thu, 10 Mar 2022 16:23:13 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Apologies for the force push. I had a very odd rebase happen that I did not intend. This push rolled it all back out to it's prior state plus a minor change clarifying a regex in the spec. ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From naoto at openjdk.java.net Thu Mar 10 17:28:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 17:28:45 GMT Subject: RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c In-Reply-To: References: Message-ID: <6N80WM128ttYyb08HpsuHpvlU6ejKa3n7LzY8i6JyyQ=.f8341776-a00b-49a3-a343-8cc844185564@github.com> On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu wrote: > Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a `jboolean*`, instead of `jboolean` LGTM. Thanks for the fix! ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7775 From achung at openjdk.java.net Thu Mar 10 17:55:44 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Thu, 10 Mar 2022 17:55:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: > msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: moved CurrencyNames changes to jdk.localedata ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/fb51cf60..4735722d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=00-01 Stats: 2807 lines in 6 files changed: 693 ins; 1527 del; 587 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From lancea at openjdk.java.net Thu Mar 10 18:01:48 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 10 Mar 2022 18:01:48 GMT Subject: RFR: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS [v6] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 16:17:16 GMT, Ian Graves wrote: >> Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters > > Ian Graves has updated the pull request incrementally with one additional commit since the last revision: > > Adding description of word-boundary regex Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From jbhateja at openjdk.java.net Thu Mar 10 18:21:31 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 10 Mar 2022 18:21:31 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v13] In-Reply-To: References: Message-ID: <4_HYBZmpNv3PRkPgYlo51m_YAyKeLB6m1hlg_jX9fMY=.69c82d73-0cd4-419c-96d0-99be51e58e15@github.com> > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Review comments resolution. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/547f4e31..fcb73212 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=11-12 Stats: 13 lines in 3 files changed: 6 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From zgu at openjdk.java.net Thu Mar 10 18:27:41 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 10 Mar 2022 18:27:41 GMT Subject: RFR: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c In-Reply-To: <6N80WM128ttYyb08HpsuHpvlU6ejKa3n7LzY8i6JyyQ=.f8341776-a00b-49a3-a343-8cc844185564@github.com> References: <6N80WM128ttYyb08HpsuHpvlU6ejKa3n7LzY8i6JyyQ=.f8341776-a00b-49a3-a343-8cc844185564@github.com> Message-ID: On Thu, 10 Mar 2022 17:25:55 GMT, Naoto Sato wrote: > LGTM. Thanks for the fix! Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7775 From zgu at openjdk.java.net Thu Mar 10 18:27:42 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 10 Mar 2022 18:27:42 GMT Subject: Integrated: 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 13:33:05 GMT, Zhengyu Gu wrote: > Please review this trivial patch to correct last parameter of `GetStringChars()` call, which should be a `jboolean*`, instead of `jboolean` This pull request has now been integrated. Changeset: 879b6445 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/879b6445e33ad3a07461d01ea8f28a09979a4313 Stats: 19 lines in 1 file changed: 0 ins; 0 del; 19 mod 8282897: Fix call parameter to GetStringChars() in HostLocaleProviderAdapter_md.c Reviewed-by: shade, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7775 From bpb at openjdk.java.net Thu Mar 10 18:29:47 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Mar 2022 18:29:47 GMT Subject: Integrated: 8254574: PrintWriter handling of InterruptedIOException should be removed In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 22:32:21 GMT, Brian Burkhalter wrote: > Remove reference to `java.io.InterruptedIOException` from `java.io.PrintStream`, and make the specifications of `checkError()`, `setError()`, and `clearError()` consistent between `java.io.PrintStream` and `java.io.PrintWriter`. This pull request has now been integrated. Changeset: b13cacc5 Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/b13cacc575f58c206c928f2756698b027ee07b6f Stats: 21 lines in 2 files changed: 0 ins; 11 del; 10 mod 8254574: PrintWriter handling of InterruptedIOException should be removed Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7507 From jlaskey at openjdk.java.net Thu Mar 10 18:34:27 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 10 Mar 2022 18:34:27 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v10] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s 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 14 additional commits since the last revision: - Merge branch 'master' into 8282625 - Correct indentation - Add unit test for DecimalFormatSymbols.getLocale() - Add comment about DecimalFormatSymbols being mutable objects. - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. - Revert "Drop DecimalFormatSymbols.getLocale change" This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. - Revert "Correct caching test" This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. - Correct caching test - Drop DecimalFormatSymbols.getLocale change - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation. - ... and 4 more: https://git.openjdk.java.net/jdk/compare/f239354a...84fa1fe7 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/dfcc1ec2..84fa1fe7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=08-09 Stats: 7713 lines in 305 files changed: 5264 ins; 679 del; 1770 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Thu Mar 10 18:39:21 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 10 Mar 2022 18:39:21 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v3] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. 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 six additional commits since the last revision: - Reimplemented array based carrier - Merge branch 'master' into 8282798 - Add non-public comment - More comments. - Allocate long fields first (alignment) - Introduce java.lang.runtime.Carrier ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/246450ca..4c68ea0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=01-02 Stats: 4560 lines in 122 files changed: 2753 ins; 523 del; 1284 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From zgu at openjdk.java.net Thu Mar 10 18:47:04 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Thu, 10 Mar 2022 18:47:04 GMT Subject: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocalProviderAdapterImpl.getNumberPattern() on Windows Message-ID: Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`. ------------- Commit messages: - 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows Changes: https://git.openjdk.java.net/jdk/pull/7777/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7777&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282887 Stats: 9 lines in 1 file changed: 2 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7777.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7777/head:pull/7777 PR: https://git.openjdk.java.net/jdk/pull/7777 From cjplummer at openjdk.java.net Thu Mar 10 19:06:43 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 10 Mar 2022 19:06:43 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com> On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 305: > 303: {"Thread not suspended", "Thread nicht unterbrochen"}, > 304: {"thread group number description name", "{0,number,integer}. {1} {2}"}, > 305: {"Threadgroup name not specified.", "Name der Threadgruppe nicht angegeben."}, Same comment here as mentioned in TTYResources_ja.java. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_de.java line 342: > 340: {"watch modification of", "\u00C4nderung von {0}.{1} \u00FCberwachen"}, > 341: {"zz help text", > 342: "** Befehlsliste **\nconnectors -- Listet verf\u00FCgbare Connectors und Transporte in dieser VM auf\n\nrun [class [args]] -- Startet die Ausf\u00FChrung der Hauptklasse der Anwendung\n\nthreads [threadgroup] -- Listet Threads auf\nthread -- Legt den Standardthread fest\nsuspend [thread id(s)] -- Unterbricht Threads (Standard: all)\nresume [thread id(s)] -- Nimmt Threads wieder auf (Standard: all)\nwhere [ | all] -- Gibt den Stack eines Threads aus\nwherei [ | all] -- Gibt den Stack eines Threads mit PC-Informationen aus\nup [n frames] -- Verschiebt den Stack eines Threads nach oben\ndown [n frames] -- Verschiebt den Stack eines Threads nach unten\nkill -- Bricht einen Thread mit dem angegebenen Ausnahmeobjekt ab\ninterrupt -- Unterbricht einen Thread\n\nprint -- Gibt den Wert eines Ausdrucks aus\ndump -- Gibt alle Objektinformationen aus\neval -- Bewertet einen Ausdruck (wie \"print\")\nset = -- Weist einem Feld/einer Variablen/einem Arrayelement einen neuen Wert zu\nlocals -- Gibt alle lokalen Variablen im aktuellen Stackframe aus\n\nclasses -- Listet derzeit bekannte Klassen auf\nclass -- Zeigt Details einer benannten Klasse an\nmethods -- Listet die Methoden einer Klasse auf\nfields -- Listet die Felder einer Klasse auf\n\nthreadgroups -- Listet Threadgruppen auf\nthreadgroup -- Legt die aktuelle Threadgruppe fest\n\nstop [go|thread] [] \n -- Legt einen Breakpoint fest\n -- Wenn Sie keine Optionen angeben, wird die aktuelle Breakpoint-Liste ausgegeben\n -- Wenn Sie \"go\" angeben, wird der Vorgang nach dem Stoppen sofort wiederaufgenommen\n -- Wenn Sie \"thread\" angeben, wird nur der Thread unterbrochen, in dem gestoppt wurde\n -- Wenn Sie weder \"go\" noch \"thread\" angeben, werden alle Threads unterbrochen\n -- Wenn Sie eine ganzzahlige angeben, wird der Vorgang nur im angegebenen Thread gestoppt\n -- \"at\" und \"in\" haben die gleiche Bedeutung\n -- kann eine Zeilennummer oder eine Methode sein:\n -- :\n -- .[(argument_type,...)]\nclear .[(argument_type,...)]\n -- L\u00F6scht einen Breakpoint in einer Methode\nclear : -- L\u00F6scht einen Breakpoint bei einer Zeile\nclear -- Listet Breakpoints auf\ncatch [uncaught|caught|all] |\n -- Break bei der angegebenen Ausnahme\nignore [uncaught|caught|all] |\n -- Bricht \"catch\" f\u00FCr die angegebene Ausnahme ab\nwatch [access|all] .\n -- \u00DCberwacht Zugriffe/\u00C4nderungen eines Feldes\nunwatch [access|all] .\n -- Hebt die \u00DCberwachung der Zugriffe/\u00C4nderungen eines Feldes auf\ntrace [go] methods [thread]\n -- Verfolgt Methodenstarts und -beendigungen.\n -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\ntrace [go] method exit | exits [thread]\n -- Verfolgt die Beendigung der aktuellen Methode oder die Beendigungen aller Methoden\n -- Alle Threads werden unterbrochen, es sei denn, \"go\" ist angegeben\nuntrace [methods] -- Stoppt das Tracing von Methodenstarts und/oder -beendigungen\nstep -- F\u00FChrt die aktuelle Zeile aus\nstep up -- Ausf\u00FChren, bis die aktuelle Methode an den Aufrufer zur\u00FCckgegeben wird\nstepi -- F\u00FChrt die aktuelle Anweisung aus\nnext -- Eine Zeile weiter (Aufrufe auslassen)\ncont -- Setzt die Ausf\u00FChrung ab dem Breakpoint fort\n\nlist [line number|method] -- Gibt den Quellcode aus\nuse (or sourcepath) [source file path]\n -- Zeigt den Quellpfad an oder \u00E4ndert diesen\nexclude [, ... | \"none\"]\n -- Meldet keine Schritt- oder Methodenereignisse f\u00FCr angegebene Klassen\nclasspath -- Gibt Classpath-Informationen aus der Ziel-VM aus\n\nmonitor -- F\u00FChrt bei jedem Programmstopp einen Befehl aus\nmonitor -- Listet Monitore auf\nunmonitor -- L\u00F6scht einen Monitor\nread -- Liest eine Befehlsdatei und f\u00FChrt diese aus\n\nlock -- Gibt Sperrinformationen f\u00FCr ein Objekt aus\nthreadlocks [thread id] -- Gibt Sperrinformationen f\u00FCr einen Thread aus\n\npop -- Holt den Stack bis zum aktuellen Frame (einschlie\u00DFlich)\nreenter -- Wie \"pop\", aber der aktuelle Frame wird wieder eingegeben\nredefine \n -- Definiert den Code f\u00FCr eine Klasse neu\n\ndisablegc -- Verhindert die Garbage Collection eines Objekts\nenablegc -- L\u00E4sst die Garbage Collection eines Objekts zu\n\n!! -- Wiederholt den letzten Befehl\n -- Wiederholt einen Befehl n-mal\nrepeat -- Zeigt an, ob die Wiederholung durch leeren Befehl im GDB-Stil aktiviert ist\nrepeat -- Aktiviert/deaktiviert die Wiederholung im GDB-Stil\n# -- Verwerfen (kein Vorgang)\nhelp (oder ?) -- Listet Befehle auf\ndbgtrace [flag] -- Identisch mit der Befehlszeilenoption \"dbgtrace\"\nversion -- Gibt Versionsinformationen aus\nexit (oder quit) -- Beendet den Debugger\n\n: Ein vollst\u00E4ndiger Klassenname mit Package-Qualifiers\n: Ein Klassenname mit einem Platzhalter am Anfang oder Ende (\"*\")\n: Threadnummer aus dem Befehl \"threads\"\n: Ein Ausdruck der Java(TM)-Programmiersprache.\nDer Gro\u00DFteil der g\u00E4ngigen Syntax wird unterst\u00FCtzt.\n\nStartbefehle k\u00F6nnen in \"jdb.ini\" oder \".jdbrc\" abgelegt werden\nin user.home oder user.dir"}, Same comment here as mentioned in TTYResources_ja.java. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305: > 303: {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"}, > 304: {"thread group number description name", "{0,number,integer}. {1} {2}"}, > 305: {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"}, I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 342: > 340: {"watch modification of", "{0}.{1}\u306E\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1"}, > 341: {"zz help text", > 342: "** \u30B3\u30DE\u30F3\u30C9\u30FB\u30EA\u30B9\u30C8 **\nconnectors -- \u3053\u306EVM\u5185\u306E\u4F7F\u7528\u53EF\u80FD\u306A\u30B3\u30CD\u30AF\u30BF\u3068\u30C8\u30E9\u30F3\u30B9\u30DD\u30FC\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\n\nrun [class [args]] -- \u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u30E1\u30A4\u30F3\u30FB\u30AF\u30E9\u30B9\u306E\u5B9F\u884C\u3092\u958B\u59CB\u3057\u307E\u3059\n\nthreads [threadgroup] -- \u30B9\u30EC\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthread -- \u30C7\u30D5\u30A9\u30EB\u30C8\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u8A2D\u5B9A\u3057\u307E\u3059\nsuspend [thread id(s)] -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nresume [thread id(s)] -- \u30B9\u30EC\u30C3\u30C9\u3092\u518D\u958B\u3057\u307E\u3059(\u30C7\u30D5\u30A9\u30EB\u30C8: \u3059\u3079\u3066)\nwhere [ | all] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30C0\u30F3\u30D7\u3057\u307E\u3059\nwherei [ | all]-- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092pc\u60C5\u5831\u3068\u3068\u3082\u306B\u30C0\u30F3\u30D7\u3057\u307E\u3059\nup [n frames] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0A\u306B\u79FB\u52D5\u3057\u307E\u3059\ndown [n frames] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u4E0B\u306B\u79FB\u52D5\u3057\u307E\u3059\nkill -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u3067\u30B9\u30EC\u30C3\u30C9\u3092\u5F37\u5236\u7D42\u4E86\u3057\u307E\u3059\ninterrupt -- \u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n\nprint -- \u5F0F\u306E\u5024\u3092\u51FA\u529B\u3057\u307E\u3059\ndump -- \u3059\u3079\u3066\u306E\u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u60C5\u58 31\u3092\u51FA\u529B\u3057\u307E\u3059\neval -- \u5F0F\u3092\u8A55\u4FA1\u3057\u307E\u3059(print\u3068\u540C\u3058)\nset = -- \u65B0\u3057\u3044\u5024\u3092\u30D5\u30A3\u30FC\u30EB\u30C9/\u5909\u6570/\u914D\u5217\u8981\u7D20\u306B\u4EE3\u5165\u3057\u307E\u3059\nlocals -- \u73FE\u5728\u306E\u30B9\u30BF\u30C3\u30AF\u30FB\u30D5\u30EC\u30FC\u30E0\u5185\u306E\u3059\u3079\u3066\u306E\u30ED\u30FC\u30AB\u30EB\u5909\u6570\u3092\u51FA\u529B\u3057\u307E\u3059\n\nclasses -- \u73FE\u5728\u65E2\u77E5\u306E\u30AF\u30E9\u30B9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nclass -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u8A73\u7D30\u3092\u8868\u793A\u3057\u307E\u3059\nmethods -- \u30AF\u30E9\u30B9\u306E\u30E1\u30BD\u30C3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nfields -- \u30AF\u30E9\u30B9\u306E\u30D5\u30A3\u30FC\u30EB\u30C9\u3092\u30EA\u30B9\u30C8\u305 7\u307E\u3059\n\nthreadgroups -- \u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nthreadgroup -- \u73FE\u5728\u306E\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n\nstop [go|thread] [] \n -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u8A2D\u5B9A\u3057\u307E\u3059\n -- \u30AA\u30D7\u30B7\u30E7\u30F3\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u306E\u73FE\u5728\u306E\u30EA\u30B9\u30C8\u304C\u51FA\u529B\u3055\u308C\u307E\u3059\n -- \"go\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u505C\u6B62\u5F8C\u3059\u3050\u306B\u518D\u958B\u3057\u307E\u3059\n -- \"thread\"\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\ u505C\u6B62\u3057\u305F\u30B9\u30EC\u30C3\u30C9\u306E\u307F\u4E2D\u65AD\u3057\u307E\u3059\n -- \"go\"\u3082\"thread\"\u3082\u6307\u5B9A\u3055\u308C\u3066\u3044\u306A\u3044\u5834\u5408\u306F\u3001\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u3092\u4E2D\u65AD\u3057\u307E\u3059\n -- \u6574\u6570\u306E\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u308B\u5834\u5408\u306F\u3001\u6307\u5B9A\u3055\u308C\u305F\u30B9\u30EC\u30C3\u30C9\u3067\u306E\u307F\u505C\u6B62\u3057\u307E\u3059\n -- \"at\"\u3068\"in\"\u306F\u540C\u3058\u610F\u5473\u3092\u6301\u3061\u307E\u3059\n -- \u306F\u884C\u756A\u53F7\u307E\u305F\u306F\u30E1\u30BD\u30C3\u30C9\u306B\u3059\u308B\u3053\u3068\u304C\u3067\u304D\u307E\u3059:\n -- :\n -- .[(argument_type,...)]\nclear .[(argument_type,...)]\n -- \u30E1\u30BD\u30C3\u30C9\u5185\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear : -- \u884C\u306E\u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30AF\u30EA\u30A2\u3057\u307E\u3059\nclear -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\ncatch [uncaught|caught|all] |\n -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u304C\u767A\u751F\u3057\u305F\u3068\u304D\u306B\u30D6\u30EC\u30FC\u30AF\u3057\u307E\u3059\nignore [uncaught|caught|all] |\n -- \u6307\u5B9A\u3055\u308C\u305F\u4F8B\u5916\u306E'catch'\u3092\u53D6\u308A\u6D88\u3057\u307E\u3059\nwatch [access|all] .\n -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u3092\u30A6\u3 0A9\u30C3\u30C1\u3057\u307E\u3059\nunwatch [access|all] .\n -- \u30D5\u30A3\u30FC\u30EB\u30C9\u3078\u306E\u30A2\u30AF\u30BB\u30B9\u307E\u305F\u306F\u5909\u66F4\u306E\u30A6\u30A9\u30C3\u30C1\u3092\u4E2D\u6B62\u3057\u307E\u3059\ntrace [go] methods [thread]\n -- \u30E1\u30BD\u30C3\u30C9\u306E\u5165\u308A\u53E3\u3068\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\u3002\n -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\ntrace [go] method exit | exits [thread]\n -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u307E\u305F\u306F\u3059\u3079\u3066\u306E\u30E1\u30BD\u30C3\u30C9\u306E\u51FA\u53E3\u3092\u30C8\u30EC\u30FC\u30B9\u3057\u307E\u3059\n -- 'go'\u304C\u6307\u5B9A\u3055\u308C\u308B\u307E\u3067\u3059\u3079\u3066\u306E\u30B9\ u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u307E\u3059\nuntrace [methods] -- \u30E1\u30BD\u30C3\u30C9\u306E\u958B\u59CB\u307E\u305F\u306F\u7D42\u4E86\u306E\u30C8\u30EC\u30FC\u30B9\u3092\u505C\u6B62\u3057\u307E\u3059\nstep -- \u73FE\u5728\u306E\u884C\u3092\u5B9F\u884C\u3057\u307E\u3059\nstep up -- \u73FE\u5728\u306E\u30E1\u30BD\u30C3\u30C9\u304C\u30E1\u30BD\u30C3\u30C9\u306E\u547C\u51FA\u3057\u5143\u306B\u623B\u308B\u307E\u3067\u5B9F\u884C\u3057\u307E\u3059\nstepi -- \u73FE\u5728\u306E\u547D\u4EE4\u3092\u5B9F\u884C\u3057\u307E\u3059\nnext -- 1\u884C\u3092\u30B9\u30C6\u30C3\u30D7\u5B9F\u884C\u3057\u307E\u3059(\u547C\u51FA\u3057\u3092\u30B9\u30C6\u30C3\u30D7\u30AA\u30FC\u30D0\u30FC)\ncont -- \u30D6\u30EC\u30FC\u30AF\u30DD\u30A4\u30F3\u30C8\u304B\u3089\u5B9F\u884C\u3092\u7D9A\u884C\u3057\u307E\u3059\n\nlist [line number|method] -- \u30BD\u30FC\u30B9\u30FB\u30B3\u30FC\u30C9\u3092\u 51FA\u529B\u3057\u307E\u3059\nuse (or sourcepath) [source file path]\n -- \u30BD\u30FC\u30B9\u30FB\u30D1\u30B9\u3092\u8868\u793A\u307E\u305F\u306F\u5909\u66F4\u3057\u307E\u3059\nexclude [, ... | \"none\"]\n -- \u6307\u5B9A\u3057\u305F\u30AF\u30E9\u30B9\u306E\u30B9\u30C6\u30C3\u30D7\u3084\u30E1\u30BD\u30C3\u30C9\u30FB\u30A4\u30D9\u30F3\u30C8\u3092\u5831\u544A\u3057\u307E\u305B\u3093\nclasspath -- \u30BF\u30FC\u30B2\u30C3\u30C8VM\u304B\u3089\u30AF\u30E9\u30B9\u30D1\u30B9\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\nmonitor -- \u30D7\u30ED\u30B0\u30E9\u30E0\u304C\u505C\u6B62\u3059\u308B\u305F\u3073\u306B\u30B3\u30DE\u30F3\u30C9\u3092\u5B9F\u884C\u3057\u307E\u3059\nmonitor -- \u30E2\u30CB\u30BF\u30FC\u3092\u30EA\u30B9\u30C8\u3057\u307E\u3059\nunmonitor -- \u30E2\u30CB\u30BF\u30FC\u3092\u524A\u9664\u3057\u307E\u3059\nread -- \u30B 3\u30DE\u30F3\u30C9\u30FB\u30D5\u30A1\u30A4\u30EB\u3092\u8AAD\u307F\u53D6\u3063\u3066\u5B9F\u884C\u3057\u307E\u3059\n\nlock -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nthreadlocks [thread id] -- \u30B9\u30EC\u30C3\u30C9\u306E\u30ED\u30C3\u30AF\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\n\npop -- \u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u307E\u3067\u306E\u3059\u3079\u3066\u306E\u30B9\u30BF\u30C3\u30AF\u3092\u30DD\u30C3\u30D7\u3057\u307E\u3059\nreenter -- pop\u3068\u540C\u3058\u3067\u3059\u304C\u3001\u73FE\u5728\u306E\u30D5\u30EC\u30FC\u30E0\u304C\u518D\u5165\u529B\u3055\u308C\u307E\u3059\nredefine \n -- \u30AF\u30E9\u30B9\u306E\u30B3\u30FC\u30C9\u3092\u518D\u5B9A\u7FA9\u3057\u307E\u3059\n\ndisablegc -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3 \u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u6291\u5236\u3057\u307E\u3059\nenablegc -- \u30AA\u30D6\u30B8\u30A7\u30AF\u30C8\u306E\u30AC\u30D9\u30FC\u30B8\u30FB\u30B3\u30EC\u30AF\u30B7\u30E7\u30F3\u3092\u8A31\u53EF\u3057\u307E\u3059\n\n!! -- \u6700\u5F8C\u306E\u30B3\u30DE\u30F3\u30C9\u3092\u7E70\u308A\u8FD4\u3057\u307E\u3059\n -- \u30B3\u30DE\u30F3\u30C9\u3092n\u56DE\u7E70\u308A\u8FD4\u3057\u307E\u3059\nrepeat -- GDB\u5F62\u5F0F\u306E\u7A7A\u306E\u30B3\u30DE\u30F3\u30C9\u306E\u7E70\u8FD4\u3057\u304C\u6709\u52B9\u306B\u306A\u3063\u3066\u3044\u308B\u304B\u3069\u3046\u304B\u3092\u793A\u3057\u307E\u3059\nrepeat -- GDB\u5F62\u5F0F\u306E\u7E70\u8FD4\u3057\u3092\u6709\u52B9/\u7121\u52B9\u306B\u3057\u307E\u3059\n# -- \u7834\u68C4\u3057\u307E\u3059(\u64CD\u4F5C\u306A\u3057)\nhelp (\u307E\u305F\u306F?) -- \u30B3\u30DE\u30F3\u30C9\u3092\u30EA\u30B9\u30C8\u3057\u3 07E\u3059\ndbgtrace [flag] -- dbgtrace\u30B3\u30DE\u30F3\u30C9\u30FB\u30E9\u30A4\u30F3\u30FB\u30AA\u30D7\u30B7\u30E7\u30F3\u3068\u540C\u3058\u3067\u3059\nversion -- \u30D0\u30FC\u30B8\u30E7\u30F3\u60C5\u5831\u3092\u51FA\u529B\u3057\u307E\u3059\nexit (\u307E\u305F\u306Fquit) -- \u30C7\u30D0\u30C3\u30AC\u3092\u7D42\u4E86\u3057\u307E\u3059\n\n: \u30D1\u30C3\u30B1\u30FC\u30B8\u4FEE\u98FE\u5B50\u3092\u542B\u3080\u5B8C\u5168\u30AF\u30E9\u30B9\u540D\n: \u5148\u982D\u307E\u305F\u306F\u672B\u5C3E\u306E\u30EF\u30A4\u30EB\u30C9\u30AB\u30FC\u30C9('*')\u3092\u542B\u3080\u30AF\u30E9\u30B9\u540D\n: 'threads'\u30B3\u30DE\u30F3\u30C9\u3067\u5831\u544A\u3055\u308C\u308B\u30B9\u30EC\u30C3\u30C9\u756A\u53F7\n: Java(TM)\u30D7\u30ED\u30B0\u30E9\u30DF\u30F3\u30B0\u8A00\u8A9E\u306E\u5F0F\u3002\n\u307B\u3068\u3093\u3069\u306E\u4E00\u822C\u7684\u306A\u69CB\u6587\u304C\u30B5\u30DD\u30FC\u30C8\u3055\u308C\u3066\u3044\u307E\u3059\u 3002\n\n\u8D77\u52D5\u30B3\u30DE\u30F3\u30C9\u306F\u3001\"jdb.ini\"\u307E\u305F\u306F\".jdbrc\"\u306B\u914D\u7F6E\u3067\u304D\u307E\u3059\n(user.home\u307E\u305F\u306Fuser.dir\u5185)"}, Also as part of #7687 there is a new entry for the `threadgroup` command without any argument. This used to produce the "Threadgroup name not specified" error message which is I mentioned above was removed. It now has supported functionality, so there should be two `threadgroup` entries: "threadgroup -- set current threadgroup to \n" + "threadgroup -- set current threadgroup back to the top level threadgroup\n" + src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 305: > 303: {"Thread not suspended", "\u672A\u6302\u8D77\u7EBF\u7A0B"}, > 304: {"thread group number description name", "{0,number,integer}\u3002{1} {2}"}, > 305: {"Threadgroup name not specified.", "\u672A\u6307\u5B9A\u7EBF\u7A0B\u7EC4\u540D\u3002"}, Same comment here as mentioned in TTYResources_ja.java. src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java line 342: > 340: {"watch modification of", "\u76D1\u89C6{0}.{1}\u7684\u4FEE\u6539"}, > 341: {"zz help text", > 342: "** \u547D\u4EE4\u5217\u8868 **\nconnectors -- \u5217\u51FA\u6B64 VM \u4E2D\u53EF\u7528\u7684\u8FDE\u63A5\u5668\u548C\u4F20\u8F93\n\nrun [class [args]] -- \u5F00\u59CB\u6267\u884C\u5E94\u7528\u7A0B\u5E8F\u7684\u4E3B\u7C7B\n\nthreads [threadgroup] -- \u5217\u51FA\u7EBF\u7A0B\nthread -- \u8BBE\u7F6E\u9ED8\u8BA4\u7EBF\u7A0B\nsuspend [thread id(s)] -- \u6302\u8D77\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nresume [thread id(s)] -- \u6062\u590D\u7EBF\u7A0B (\u9ED8\u8BA4\u503C: all)\nwhere [ | all] -- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808\nwherei [ | all]-- \u8F6C\u50A8\u7EBF\u7A0B\u7684\u5806\u6808, \u4EE5\u53CA pc \u4FE1\u606F\nup [n frames] -- \u4E0A\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\ndown [n frames] -- \u4E0B\u79FB\u7EBF\u7A0B\u7684\u5806\u6808\nkill -- \u7EC8\u6B62\u5177\u6709\u7ED9\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u5BF9\u8C61\u7684\u7EBF\u7A0B \ninterrupt -- \u4E2D\u65AD\u7EBF\u7A0B\n\nprint -- \u8F93\u51FA\u8868\u8FBE\u5F0F\u7684\u503C\ndump -- \u8F93\u51FA\u6240\u6709\u5BF9\u8C61\u4FE1\u606F\neval -- \u5BF9\u8868\u8FBE\u5F0F\u6C42\u503C (\u4E0E print \u76F8\u540C)\nset = -- \u5411\u5B57\u6BB5/\u53D8\u91CF/\u6570\u7EC4\u5143\u7D20\u5206\u914D\u65B0\u503C\nlocals -- \u8F93\u51FA\u5F53\u524D\u5806\u6808\u5E27\u4E2D\u7684\u6240\u6709\u672C\u5730\u53D8\u91CF\n\nclasses -- \u5217\u51FA\u5F53\u524D\u5DF2\u77E5\u7684\u7C7B\nclass -- \u663E\u793A\u5DF2\u547D\u540D\u7C7B\u7684\u8BE6\u7EC6\u8D44\u6599\nmethods -- \u5217\u51FA\u7C7B\u7684\u65B9\u6CD5\nfields -- \u5217\u51FA\u7C7B\u7684\u5B57\u6BB5\n\nthreadgroups -- \u5217\u51FA\u7EBF\u7A0B\u7EC4\nthreadgroup -- \u8BBE\u7F6E\u5F53\u524D\u7EBF\u7A0B\u7EC4\n\nstop [go| thread] [] \n -- \u8BBE\u7F6E\u65AD\u70B9\n -- \u5982\u679C\u672A\u63D0\u4F9B\u4EFB\u4F55\u9009\u9879\uFF0C\u5219\u5C06\u6253\u5370\u5F53\u524D\u65AD\u70B9\u5217\u8868\n -- \u5982\u679C\u6307\u5B9A \"go\"\uFF0C\u5219\u5728\u505C\u6B62\u540E\u7ACB\u5373\u6062\u590D\n -- \u5982\u679C\u6307\u5B9A \"thread\"\uFF0C\u5219\u4EC5\u6302\u8D77\u5728\u5176\u4E2D\u505C\u6B62\u7684\u7EBF\u7A0B\n -- \u5982\u679C\u65E2\u672A\u6307\u5B9A \"go\" \u4E5F\u672A\u6307\u5B9A \"thread\"\uFF0C\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\n -- \u5982\u679C\u6307\u5B9A\u4EE5\u6574\u6570\u8868\u793A\u7684 \uFF0C\u5219\u4EC5\u5728\u6307\u5B9A\u7684\u7EBF\u7A0B\u4E2D\u505C\u6B62\n -- \"at\" \u548C \"in\" \u7684\u542B\u4E49\u76F8\u540C\n -- \u53EF\u4EE5\u662F\u884C\u53 F7\u6216\u65B9\u6CD5\uFF1A\n -- :\n -- .[(argument_type,...)]\nclear .[(argument_type,...)]\n -- \u6E05\u9664\u65B9\u6CD5\u4E2D\u7684\u65AD\u70B9\nclear : -- \u6E05\u9664\u884C\u4E2D\u7684\u65AD\u70B9\nclear -- \u5217\u51FA\u65AD\u70B9\ncatch [uncaught|caught|all] |\n -- \u51FA\u73B0\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF\u65F6\u4E2D\u65AD\nignore [uncaught|caught|all] |\n -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u5F02\u5E38\u9519\u8BEF, \u53D6\u6D88 'catch'\nwatch [access|all] .\n -- \u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u8BBF\u95EE/\u4FEE\u6539\nunwatch [access|all] .\n -- \u505C\u6B62\u76D1\u89C6\u5BF9\u5B57\u6BB5\u7684\u 8BBF\u95EE/\u4FEE\u6539\ntrace [go] methods [thread]\n -- \u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C\u9000\u51FA\u3002\n -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\ntrace [go] method exit | exits [thread]\n -- \u8DDF\u8E2A\u5F53\u524D\u65B9\u6CD5\u7684\u9000\u51FA, \u6216\u8005\u6240\u6709\u65B9\u6CD5\u7684\u9000\u51FA\n -- \u9664\u975E\u6307\u5B9A 'go', \u5426\u5219\u6302\u8D77\u6240\u6709\u7EBF\u7A0B\nuntrace [methods] -- \u505C\u6B62\u8DDF\u8E2A\u65B9\u6CD5\u8FDB\u5165\u548C/\u6216\u9000\u51FA\nstep -- \u6267\u884C\u5F53\u524D\u884C\nstep up -- \u4E00\u76F4\u6267\u884C, \u76F4\u5230\u5F53\u524D\u65B9\u6CD5\u8FD4\u56DE\u5230\u5176\u8C03\u7528\u65B9\nstepi -- \u6267\u884C\u5F53\u524D\u6307\u4EE4\n\u4E0B\u4E00\u6B65 -- \u6B65\u8FDB\u4E00\u884C (\u6B65\u8FC7\u 8C03\u7528)\ncont -- \u4ECE\u65AD\u70B9\u5904\u7EE7\u7EED\u6267\u884C\n\nlist [line number|method] -- \u8F93\u51FA\u6E90\u4EE3\u7801\nuse (\u6216 sourcepath) [source file path]\n -- \u663E\u793A\u6216\u66F4\u6539\u6E90\u8DEF\u5F84\nexclude [, ... | \"none\"]\n -- \u5BF9\u4E8E\u6307\u5B9A\u7684\u7C7B, \u4E0D\u62A5\u544A\u6B65\u9AA4\u6216\u65B9\u6CD5\u4E8B\u4EF6\nclasspath -- \u4ECE\u76EE\u6807 VM \u8F93\u51FA\u7C7B\u8DEF\u5F84\u4FE1\u606F\n\nmonitor -- \u6BCF\u6B21\u7A0B\u5E8F\u505C\u6B62\u65F6\u6267\u884C\u547D\u4EE4\nmonitor -- \u5217\u51FA\u76D1\u89C6\u5668\nunmonitor -- \u5220\u9664\u76D1\u89C6\u5668\nread -- \u8BFB\u53D6\u5E76\u6267\u884C\u547D\u4EE4\u6587\u4EF6\n\nlock -- \u8F93\u51FA\u5BF9\u8C61\u7684\u9501\u4FE1\u606F\nthreadlocks [thread id] -- \u8F93\u51FA\u7EBF\u7A0B\u7684\u9501 \u4FE1\u606F\n\npop -- \u901A\u8FC7\u5F53\u524D\u5E27\u51FA\u6808, \u4E14\u5305\u542B\u5F53\u524D\u5E27\nreenter -- \u4E0E pop \u76F8\u540C, \u4F46\u91CD\u65B0\u8FDB\u5165\u5F53\u524D\u5E27\nredefine \n -- \u91CD\u65B0\u5B9A\u4E49\u7C7B\u7684\u4EE3\u7801\n\ndisablegc -- \u7981\u6B62\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\nenablegc -- \u5141\u8BB8\u5BF9\u8C61\u7684\u5783\u573E\u6536\u96C6\n\n!! -- \u91CD\u590D\u6267\u884C\u6700\u540E\u4E00\u4E2A\u547D\u4EE4\n -- \u5C06\u547D\u4EE4\u91CD\u590D\u6267\u884C n \u6B21\nrepeat -- \u663E\u793A\u662F\u5426\u542F\u7528\u4E86 GDB \u6837\u5F0F\u7684\u7A7A\u547D\u4EE4\u91CD\u590D\nrepeat -- \u542F\u7528/\u7981\u7528 GDB \u6837\u5F0F\u7684\u91CD\u590D\n# -- \u653E\u5F03 (\u65E0\u64CD\u4F5C)\nhelp (\u6216 ?) -- \u5217\u51FA\u547D\u4EE4\ndbgtrace [flag] -- \u4E0E dbgtrace \u547D\u4EE4\u884C\u9009\u9879\u76F8\u540C\nversion -- \u8F93\u51FA\u7248\u672C\u4FE1\u606F\nexit (\u6216 quit) -- \u9000\u51FA\u8C03\u8BD5\u5668\n\n: \u5E26\u6709\u7A0B\u5E8F\u5305\u9650\u5B9A\u7B26\u7684\u5B8C\u6574\u7C7B\u540D\n: \u5E26\u6709\u524D\u5BFC\u6216\u5C3E\u968F\u901A\u914D\u7B26 ('*') \u7684\u7C7B\u540D\n: 'threads' \u547D\u4EE4\u4E2D\u62A5\u544A\u7684\u7EBF\u7A0B\u7F16\u53F7\n: Java(TM) \u7F16\u7A0B\u8BED\u8A00\u8868\u8FBE\u5F0F\u3002\n\u652F\u6301\u5927\u591A\u6570\u5E38\u89C1\u8BED\u6CD5\u3002\n\n\u53EF\u4EE5\u5C06\u542F\u52A8\u547D\u4EE4\u7F6E\u4E8E \"jdb.ini\" \u6216 \".jdbrc\" \u4E2D\n\u4F4D\u4E8E user.home \u6216 user.dir \u4E2D"}, Same comment here as mentioned in TTYResources_ja.java. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From mchung at openjdk.java.net Thu Mar 10 19:19:38 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 10 Mar 2022 19:19:38 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 22:52:41 GMT, Mandy Chung wrote: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. `Objects::requireNonNull` is force inlined. I expect the performance overhead should be insignificant in practice. I asked @cl4es to give the performance guidance and review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From lance.andersen at oracle.com Thu Mar 10 19:26:28 2022 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 10 Mar 2022 19:26:28 +0000 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: Message-ID: Hi Volker, Thank you for the reminder This is on my radar as well but have not had a chance spend any time on this as yet. On Mar 9, 2022, at 2:33 PM, Volker Simonis > wrote: @Alan, @Lance, Sorry for my obtrusiveness, but what's your opinion on this issue? Thank you and best regards, Volker On Fri, Mar 4, 2022 at 11:04 AM Volker Simonis > wrote: `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://urldefense.com/v3/__https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h*L400__;Iw!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0w3u0Q7HA$ )) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://urldefense.com/v3/__https://chromium.googlesource.com/chromium/src/third_party/zlib/__;!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0yNMBtuew$ ) or [zlib-cloudflare](https://urldefense.com/v3/__https://github.com/cloudflare/zlib__;!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0y7Uhi8nA$ ) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://urldefense.com/v3/__https://github.com/simonis/zlib-chromium__;!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0z1qVlYPg$ for a more detailed description of their approach and its performance benefit. These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*k*`]` (where *k* is the number of inflated bytes). >From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but could be easily fixed to run with alternative implementations as well. What should/can be done to solve this problem? I think we have three options: 1. Relax the specification of `InflaterInputStream::read(..)` and specifically note in the API documentation that a call to `InflaterInputStream::read(byte[] b, int off, int len)` may write more than *k* characters into `b` where *k* is the returned number of inflated bytes. Notice that there's a precedence for this approach in `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden method of InputStream, returns -1 instead of zero if the end of the stream has been reached and len==0*". 2. Tighten the specification of `Inflater::read(byte[] b, int off, int len)` to explicitly forbid any writes into the output array `b` beyond the inflated bytes. 3. Change the implementation of `InflaterInputStream::read(..)` to call `Inflater::read(..)` with a temporary buffer and only copy the nu,ber of inflated bytes into `InflaterInputStream::read(..)`'s output buffer. I think we all agree that this is only a theoretic option because of its unacceptable performance regression. I personally favor option 1 but I'm interested in your opinions? Thank you and best regards, Volker [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From iklam at openjdk.java.net Thu Mar 10 19:29:43 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Mar 2022 19:29:43 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 13:51:56 GMT, Magnus Ihse Bursie wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > I think he already did. I'm quoting: > >> However, the CDS archive also contains a heap dump, which includes Java HashMaps. If I allow those 3 Java threads to start, some HashMaps in the module graph will have unstable ordering. I think the reason is concurrent thread execution causes unstable assignment of the identity_hash for objects in the heap dump. > @magicus I think we need @iklam to weigh in here and explain exactly what the "heap dump" consists of and how not running those threads affects its contents. Presently the heap dump is potentially different on each run, IIUC, only due to the order of its contents, not the contents themselves. CDS doesn't dump the entire Java heap. Instead, it dumps only a selected portion of the Java heap. For example, the module graph. The contents of the dumped objects are always the same, except that the identity hashcode may be different if multiple threads are executed. The identity hashcode is computed here, and its value is "sticky" to the first thread that tries to get the hashcode for an object. static inline intptr_t get_next_hash(Thread* current, oop obj) { intptr_t value = 0; if (hashCode == 0) { ... } else if (hashCode == 4) { ... } else { // default hashCode is 5: // Marsaglia's xor-shift scheme with thread-specific state // This is probably the best overall implementation -- we'll // likely make this the default in future releases. unsigned t = current->_hashStateX; t ^= (t << 11); current->_hashStateX = current->_hashStateY; current->_hashStateY = current->_hashStateZ; current->_hashStateZ = current->_hashStateW; unsigned v = current->_hashStateW; v = (v ^ (v >> 19)) ^ (t ^ (t >> 8)); current->_hashStateW = v; value = v; } So, when the main Java thread tries to store an object `O` into a hashtable inside the module graph, if the hashcode of `O` has already been computed by a non-main thread, then the module graph will have unstable contents. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From jlaskey at openjdk.java.net Thu Mar 10 19:35:16 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 10 Mar 2022 19:35:16 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v4] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Leave public for the time being ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/4c68ea0d..0849c65d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From iklam at openjdk.java.net Thu Mar 10 19:37:40 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Mar 2022 19:37:40 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: <1E_zgqBQtByT4cXyk_dlbXGRVAQpCI6jlKXFIYovvVU=.3597bbf1-2ae7-4d41-9bef-79f77c90e8d3@github.com> On Wed, 9 Mar 2022 07:51:46 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > src/hotspot/share/prims/jvm.cpp line 2887: > >> 2885: return; >> 2886: } >> 2887: #endif > > Should we do this for jni_AttachCurrentThread too? This hasn't been necessary for me because jni_AttachCurrentThread is not called during "java -Xshare:dump", which executes under a very strict condition and doesn't normally allow arbitrary JNI libraries to be loaded. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Thu Mar 10 19:44:39 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Mar 2022 19:44:39 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 13:51:56 GMT, Magnus Ihse Bursie wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > I think he already did. I'm quoting: > >> However, the CDS archive also contains a heap dump, which includes Java HashMaps. If I allow those 3 Java threads to start, some HashMaps in the module graph will have unstable ordering. I think the reason is concurrent thread execution causes unstable assignment of the identity_hash for objects in the heap dump. > @magicus the issue is not the list of classes dumped, or their format in the dump. As Ioi indicated that list is fixed. The issue is with the heap dump part of the archive. Running these other threads affects the heap so by not running them with end up with a different heap. So the question is whether there is anything about having a different heap dumped that we need to be concerned about. We dump the heap into the archive for a reason and this changes what we dump, To be clear, if multiple threads are running, classes could be loaded in a different order and the symbols will have different orders. This would cause the vtables in Klass objects to be laid out differently. Trying to fix this is very difficult. I have a different patch that makes it work but it's just too complicated. So, disabling the threads is also necessary for (easily) sorting the metaspace objects. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From naoto at openjdk.java.net Thu Mar 10 19:49:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 19:49:44 GMT Subject: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocalProviderAdapterImpl.getNumberPattern() on Windows In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`. LGTM. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7777 From naoto at openjdk.java.net Thu Mar 10 19:54:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 10 Mar 2022 19:54:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_de.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP No need for these lines in each localized files, as English bundle contains them. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_ja.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP Same here with `de` bundle. src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties line 63: > 61: # written authorization of the copyright holder. > 62: > 63: ADP=ADP and here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From omikhaltcova at openjdk.java.net Thu Mar 10 20:43:43 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 10 Mar 2022 20:43:43 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v4] In-Reply-To: References: Message-ID: On Mon, 7 Mar 2022 16:46:28 GMT, Roger Riggs wrote: >> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: >> >> Reverted addition of the test via echo > > As an alternative fix, please take a look at Draft PR: https://github.com/openjdk/jdk/pull/7709. > > In the default handling of arguments, the check for what is quoted is reverted to prior to 8255068. First and last quotes are sufficient to identify a "quoted" string. The check for a backslash ("\") is removed. > This original check is sufficient for `jdk.lang.Process.allowAmbiguousCommands = true`. > > For the case where the system property `jdk.lang.Process.allowAmbiguousCommands = false` > and the argument has first and last quotes, a backslash ("\") before the final quote must not allow the quote to interpreted as a literal quote and merge the following argument. The backslashes will doubled to prevent the interpretation of the quote as a literal. This is the correct encoding if the command uses the ".exe" encoding, when reparsing the arguments the doubled backslashes are reduced to the original contents. > When the command is using the simpler parsing that does not support literal quotes, the backslash before the quote is typically is a trailing backslash on a file path and in that case the additional backslash is redundant and has no effect on the interpretation of the argument as a directory path. > > The PR includes a test of the 12 combinations of invoking an "java"/.exe program, a .cmd script, and a Visual Basic script (which uses the .exe rules but different command line parser); with and without application quotes and compares the actual results with the expected arguments. @RogerRiggs Sorry for the delay! I also checked, the test-case with VBS, that raised this issue, successfully workes with your patch. It would be great to have it asap. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From omikhaltcova at openjdk.java.net Thu Mar 10 20:46:41 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 10 Mar 2022 20:46:41 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v4] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 15:38:44 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Reverted addition of the test via echo Closed due to an alternative fix #7709. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From omikhaltcova at openjdk.java.net Thu Mar 10 20:46:41 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Thu, 10 Mar 2022 20:46:41 GMT Subject: Withdrawn: 8282008: Incorrect handling of quoted arguments in ProcessBuilder In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:19:04 GMT, Olga Mikhaltsova wrote: > This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. > > For example, it's needed to execute the following command on Windows: > `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` > it's equal to: > `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` > > While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. > > private static String unQuote(String str) { > .. > if (str.endsWith("\\"")) { > return str; // not properly quoted, treat as unquoted > } > .. > } > > > that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. > As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: > > pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test > (jdk.lang.Process.allowAmbiguousCommands = true) > pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test > (jdk.lang.Process.allowAmbiguousCommands = false) > > > Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From duke at openjdk.java.net Thu Mar 10 21:03:16 2022 From: duke at openjdk.java.net (Maxim Kartashev) Date: Thu, 10 Mar 2022 21:03:16 GMT Subject: RFR: JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 23:20:21 GMT, Roger Riggs wrote: > Quoting related changes in https://bugs.openjdk.java.net/browse/JDK-8250568 modified the way that > process builder recognized argument strings, causing some arguments to be doubly quoted and malformed. > > ProcessBuilder encodes command arguments in two ways, a looser legacy encoding > and stricter encoding that prevents quotes from being misinterpreted. > The system property jdk.lang.Process.allowAmbiguousCommands controls which is in effect. > > When the property is "true" or not set, arguments are inserted into the Windows command line > with minimal changes. Arguments containing space or tab are quoted to prevent them being split. > Arguments that start and end with double-quote are left alone. > Some executables interpret a backslash before the final quote as an escape; if the argument > contains first and last quotes, backslashes are ignored. > > When the allowAmbigousCommands property is `false`, care is taken to ensure that > the final quote of an argument is the closing quote for the argument and is not > interpreted as a literal quote by a preceding quote (or an odd number of quotes). > > The PR includes a test matrix of the cases where an argument with spaces and a final backslash > is passed with each combination of `allowAmbiguousCommands = true and false`, > launched executable, java, .cmd, and .vbs and when the argument is surrounded with double-quotes. > > The priority for allowAmbiguousCommands = false is that no argument is split or joined to another argument. > In some cases, backslashes are doubled to prevent a double-quote from being interpreted incorrectly. > The trailing backslash in an argument occurs rarely exception when the argument is a directory. > In that case, the addition of trailing backslashes is benign when the string is used as a filesystem path. > > See also PR#7504, for background and a proposal. src/java.base/windows/classes/java/lang/ProcessImpl.java line 302: > 300: */ > 301: private static String unQuote(String str) { > 302: if (!str.startsWith("\"") || !str.endsWith("\"") || str.length() < 2) This method has never been doing what it says in the comment above. Maybe drop the comment altogether as the code is fairly self-explanatory? ------------- PR: https://git.openjdk.java.net/jdk/pull/7709 From rriggs at openjdk.java.net Thu Mar 10 20:57:41 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 10 Mar 2022 20:57:41 GMT Subject: RFR: 8282008: Incorrect handling of quoted arguments in ProcessBuilder [v4] In-Reply-To: References: Message-ID: On Thu, 3 Mar 2022 15:38:44 GMT, Olga Mikhaltsova wrote: >> This fix made equal processing of strings such as ""C:\\Program Files\\Git\\"" before and after JDK-8250568. >> >> For example, it's needed to execute the following command on Windows: >> `C:\Windows\SysWOW64\WScript.exe "MyVB.vbs" "C:\Program Files\Git" "Test"` >> it's equal to: >> `new ProcessBuilder("C:\\Windows\\SysWOW64\\WScript.exe", "MyVB.vbs", ""C:\\Program Files\\Git\\"", "Test").start();` >> >> While processing, the 3rd argument ""C:\\Program Files\\Git\\"" treated as unquoted due to the condition added in JDK-8250568. >> >> private static String unQuote(String str) { >> .. >> if (str.endsWith("\\"")) { >> return str; // not properly quoted, treat as unquoted >> } >> .. >> } >> >> >> that leads to the additional surrounding by quotes in ProcessImpl::createCommandLine(..) because needsEscaping(..) returns true due to the space inside the string argument. >> As a result the native function CreateProcessW (src/java.base/windows/native/libjava/ProcessImpl_md.c) gets the incorrectly quoted argument: >> >> pcmd = C:\Windows\SysWOW64\WScript.exe MyVB.vbs ""C:\Program Files\Git"" Test >> (jdk.lang.Process.allowAmbiguousCommands = true) >> pcmd = "C:\Windows\SysWOW64\WScript.exe" MyVB.vbs ""C:\Program Files\Git\\"" Test >> (jdk.lang.Process.allowAmbiguousCommands = false) >> >> >> Obviously, a string ending with `"\\""` must not be started with `"""` to treat as unquoted overwise it?s should be treated as properly quoted. > > Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision: > > Reverted addition of the test via echo Thanks for the followup and confirmation. I'll move #7709 to review from draft. ------------- PR: https://git.openjdk.java.net/jdk/pull/7504 From rriggs at openjdk.java.net Thu Mar 10 21:03:15 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 10 Mar 2022 21:03:15 GMT Subject: RFR: JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder Message-ID: Quoting related changes in https://bugs.openjdk.java.net/browse/JDK-8250568 modified the way that process builder recognized argument strings, causing some arguments to be doubly quoted and malformed. ProcessBuilder encodes command arguments in two ways, a looser legacy encoding and stricter encoding that prevents quotes from being misinterpreted. The system property jdk.lang.Process.allowAmbiguousCommands controls which is in effect. When the property is "true" or not set, arguments are inserted into the Windows command line with minimal changes. Arguments containing space or tab are quoted to prevent them being split. Arguments that start and end with double-quote are left alone. Some executables interpret a backslash before the final quote as an escape; if the argument contains first and last quotes, backslashes are ignored. When the allowAmbigousCommands property is `false`, care is taken to ensure that the final quote of an argument is the closing quote for the argument and is not interpreted as a literal quote by a preceding quote (or an odd number of quotes). The PR includes a test matrix of the cases where an argument with spaces and a final backslash is passed with each combination of `allowAmbiguousCommands = true and false`, launched executable, java, .cmd, and .vbs and when the argument is surrounded with double-quotes. The priority for allowAmbiguousCommands = false is that no argument is split or joined to another argument. In some cases, backslashes are doubled to prevent a double-quote from being interpreted incorrectly. The trailing backslash in an argument occurs rarely exception when the argument is a directory. In that case, the addition of trailing backslashes is benign when the string is used as a filesystem path. See also PR#7504, for background and a proposal. ------------- Commit messages: - Cleanup comment and copyright - JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder Changes: https://git.openjdk.java.net/jdk/pull/7709/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7709&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282008 Stats: 341 lines in 2 files changed: 330 ins; 6 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7709/head:pull/7709 PR: https://git.openjdk.java.net/jdk/pull/7709 From dholmes at openjdk.java.net Thu Mar 10 21:28:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 10 Mar 2022 21:28:43 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 19:41:03 GMT, Ioi Lam wrote: >> I think he already did. I'm quoting: >> >>> However, the CDS archive also contains a heap dump, which includes Java HashMaps. If I allow those 3 Java threads to start, some HashMaps in the module graph will have unstable ordering. I think the reason is concurrent thread execution causes unstable assignment of the identity_hash for objects in the heap dump. > >> @magicus the issue is not the list of classes dumped, or their format in the dump. As Ioi indicated that list is fixed. The issue is with the heap dump part of the archive. Running these other threads affects the heap so by not running them with end up with a different heap. So the question is whether there is anything about having a different heap dumped that we need to be concerned about. We dump the heap into the archive for a reason and this changes what we dump, > > To be clear, if multiple threads are running, classes could be loaded in a different order and the symbols will have different orders. This would cause the vtables in Klass objects to be laid out differently. Trying to fix this is very difficult. I have a different patch that makes it work but it's just too complicated. > > So, disabling the threads is also necessary for (easily) sorting the metaspace objects. @iklam thanks for clarifying. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From bpb at openjdk.java.net Thu Mar 10 22:08:41 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Thu, 10 Mar 2022 22:08:41 GMT Subject: RFR: 8058924: FileReader(String) documentation is insufficient In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 02:30:35 GMT, Brian Burkhalter wrote: > Add a statement to the `java.io` package documentation clarifying how a `String` representing a _pathname string_ is interpreted in the package. CSR created: https://bugs.openjdk.java.net/browse/JDK-8282992 ------------- PR: https://git.openjdk.java.net/jdk/pull/7767 From smarks at openjdk.java.net Thu Mar 10 22:25:46 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 10 Mar 2022 22:25:46 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> Message-ID: On Thu, 10 Mar 2022 16:22:29 GMT, XenoAmess wrote: >> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 116: >> >>> 114: } >>> 115: >>> 116: void putN(Map map, int n) { >> >> @stuart-marks well we know this is correct for WeakHashMap when n < IntegerCache.high because we have Integer constant pool, but I think it be better to manlly make it sure it is referenced, as IntegerCache.high is configurable. > > @stuart-marks please have a look in changes in the latest commit, I think we'd better to manually create references for keys like that. Good point about WeakHashMap! I don't think we need a separate table. Since the value is held by a strong reference, using the same reference as the key will prevent the key's weak reference from being cleared. I'd suggest this: for (int i = 0; i < n; i++) { Integer obj = i; // prevent WeakHashMap from clearing keys map.put(obj, obj); } ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From smarks at openjdk.java.net Thu Mar 10 22:25:47 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 10 Mar 2022 22:25:47 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> Message-ID: <-2ndV5uB-h798UgDFjcPGrL9KVOdXLNnbMq81H-qrcE=.33748fb8-1b28-4f55-8b7c-86aa6fa25112@github.com> On Thu, 10 Mar 2022 16:10:31 GMT, XenoAmess wrote: >> XenoAmess has updated the pull request incrementally with five additional commits since the last revision: >> >> - clean out tests >> - Remove 'randomness' keyword. >> - Cleanup and commenting. >> - initial rewrite of WhiteBoxResizeTest >> - Restore WhiteBoxResizeTest.java > > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 290: > >> 288: cases.addAll(genPopulatedCapacityCases(12, 16)); >> 289: cases.addAll(genPopulatedCapacityCases(13, 32)); >> 290: cases.addAll(genPopulatedCapacityCases(64, 128)); > > @stuart-marks should there better be a loop from 1 to 64? The difficulty with having a loop instead of constants is that the expected value now needs to be computed. We could probably use `tableSizeFor` to do this. But this is starting to get uncomfortably close to a testing antipattern which is to use the code under test as part of the test. If a bug is introduced into `tableSizeFor`, it could introduce the error into both the actual value and the expected value, covering up the bug. (This is related to one of the flaws with the Enum/ConstantDirectoryOptimalCapacity test.) Now we _hope_ that `tableSizeFor` is correct and tested, but that verges on having tests depend on each other in a subtle and uncomfortable way. Recall that one of the original cases was that the table size computation (int) (numMappings / 0.75f) + 1 gives a value one too large: for 12 mappings it results in 17, giving a table size of 32. The (12, 16) case is sufficient to verify that this is fixed. Then the adjacent cases are there to make sure nothing weird is going on. (You could argue that (11, 16) isn't necessary.) I threw in the (64, 128) case because of the loop to 64, but it's not necessarily testing anything useful. If you think we need more cases we can add more at the boundaries, such as (24, 32) and (25, 64). ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From mcimadamore at openjdk.java.net Thu Mar 10 22:32:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 10 Mar 2022 22:32:47 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v4] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 19:35:16 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Leave public for the time being src/java.base/share/classes/java/lang/runtime/Carrier.java line 346: > 344: * Carrier for longs and integers. > 345: */ > 346: private final int[] integers; I believe (@rose00 correct me if I'm wrong) that an `int[]` doesn't guarantee proper 64-but alignment of the first element in the array in 32-bit platforms. We ran into similar issues with the MemorySegment API, I believe. I think using a `long[]` if you want explicit 64-bit alignment is the safest choice. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From rriggs at openjdk.java.net Thu Mar 10 22:41:43 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 10 Mar 2022 22:41:43 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> Message-ID: On Thu, 10 Mar 2022 22:01:49 GMT, Stuart Marks wrote: >> @stuart-marks please have a look in changes in the latest commit, I think we'd better to manually create references for keys like that. > > Good point about WeakHashMap! I don't think we need a separate table. Since the value is held by a strong reference, using the same reference as the key will prevent the key's weak reference from being cleared. I'd suggest this: > > for (int i = 0; i < n; i++) { > Integer obj = i; // prevent WeakHashMap from clearing keys > map.put(obj, obj); > } Heads up here! java.lang.Integer is specified as a value based class and should not be used where identity is needed. https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/doc-files/ValueBased.html I don't have a ready suggestion, but be forewarned that this use is not considered valid. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From rriggs at openjdk.java.net Thu Mar 10 22:47:46 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 10 Mar 2022 22:47:46 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v10] In-Reply-To: References: Message-ID: <2_PPLf9un51N9nJZ-lBi6NsSw8k1ZguLVQGEGm3Lsb0=.cdd3a8d6-9c4f-4393-8fa4-1411372593a5@github.com> On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > 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 14 additional commits since the last revision: > > - Merge branch 'master' into 8282625 > - Correct indentation > - Add unit test for DecimalFormatSymbols.getLocale() > - Add comment about DecimalFormatSymbols being mutable objects. > - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." > > This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. > - Revert "Drop DecimalFormatSymbols.getLocale change" > > This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. > - Revert "Correct caching test" > > This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. > - Correct caching test > - Drop DecimalFormatSymbols.getLocale change > - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation. > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/59f5719e...84fa1fe7 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Thu Mar 10 22:56:46 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Thu, 10 Mar 2022 22:56:46 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v4] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 22:29:48 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Leave public for the time being > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 346: > >> 344: * Carrier for longs and integers. >> 345: */ >> 346: private final int[] integers; > > I believe (@rose00 correct me if I'm wrong) that an `int[]` doesn't guarantee proper 64-but alignment of the first element in the array in 32-bit platforms. We ran into similar issues with the MemorySegment API, I believe. I think using a `long[]` if you want explicit 64-bit alignment is the safest choice. Makes sense. Easy change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From iklam at openjdk.java.net Thu Mar 10 23:20:26 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Mar 2022 23:20:26 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v3] In-Reply-To: References: Message-ID: <0N6pu8Jh3q0V0N7cxQtV7GWcszvjiQzX5W_4ZryJPQY=.4b615784-dd08-426a-8a3e-11bad1843ce8@github.com> > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: improvement zeroing of alignment gaps ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7748/files - new: https://git.openjdk.java.net/jdk/pull/7748/files/44db40f1..6974021f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=01-02 Stats: 8 lines in 2 files changed: 3 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Thu Mar 10 23:24:41 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 10 Mar 2022 23:24:41 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 07:47:19 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed zero build > > src/hotspot/share/utilities/hashtable.hpp line 42: > >> 40: >> 41: LP64_ONLY(unsigned int _gap;) >> 42: > > For 64-bit, you now lose packing potential in the theoretical case the following payload does not have to be aligned to 64 bit. E.g. for T=char, where the whole entry would fit into 8 bytes. Probably does not matter as long as entries are allocated individually from C-heap which is a lot more wasteful anyway. > > For 32-bit, I think you may have the same problem if the payload starts with a uint64_t. Would that not be aligned to a 64-bit boundary too? Whether or not you build on 64-bit? > > I think setting the memory, or at least the first 8..16 bytes, of the entry to zero in BasicHashtable::new_entry could be more robust: > > (16 bytes in case the payload starts with a long double but that may be overthinking it :) > > > template BasicHashtableEntry* BasicHashtable::new_entry(unsigned int hashValue) { > char* p = :new (NEW_C_HEAP_ARRAY(char, this->entry_size(), F); > ::memset(p, 0, MIN2(this->entry_size(), 16)); // needs reproducable > BasicHashtableEntry* entry = ::new (p) BasicHashtableEntry(hashValue); > return entry; > } > > If you are worried about performance, this may also be controlled by a template parameter, and then you do it just for the system dictionary. Thanks for pointing this out. I ran more tests and found that on certain platforms, there are other structures that have problems with uninitialized gaps. I ended up changing `os::malloc()` to zero the buffer when running with -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't matter too much for regular VM executions because `os::malloc()` already has a high overhead. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From duke at openjdk.java.net Fri Mar 11 01:11:25 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 01:11:25 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: <-2ndV5uB-h798UgDFjcPGrL9KVOdXLNnbMq81H-qrcE=.33748fb8-1b28-4f55-8b7c-86aa6fa25112@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> <-2ndV5uB-h798UgDFjcPGrL9KVOdXLNnbMq81H-qrcE=.33748fb8-1b28-4f55-8b7c-86aa6fa25112@github.com> Message-ID: On Thu, 10 Mar 2022 22:21:28 GMT, Stuart Marks wrote: > The difficulty with having a loop instead of constants is that the expected value now needs to be computed. We could probably use `tableSizeFor` to do this. But this is starting to get uncomfortably close to a testing antipattern which is to use the code under test as part of the test. If a bug is introduced into `tableSizeFor`, it could introduce the error into both the actual value and the expected value, covering up the bug. (This is related to one of the flaws with the Enum/ConstantDirectoryOptimalCapacity test.) Now we _hope_ that `tableSizeFor` is correct and tested, but that verges on having tests depend on each other in a subtle and uncomfortable way. you are correct about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 11 01:11:24 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 01:11:24 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v30] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refine test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/3f1e0e7c..866b4606 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=29 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=28-29 Stats: 383 lines in 1 file changed: 277 ins; 15 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 11 01:13:10 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 01:13:10 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v28] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <5SN4YdMHSdrUnjNv2neMmtNo0XpdLnbaWSab4eGzDLI=.83e29a60-1c0a-409f-9f6f-0cbc96d3f367@github.com> <1VGRD9YZ6_Q1HMphLJcrTNq7uuCch0qvi3rSkolrmVU=.6a050632-0dd5-47c1-86d1-61cf65818503@github.com> Message-ID: On Thu, 10 Mar 2022 22:37:58 GMT, Roger Riggs wrote: > Heads up here! java.lang.Integer is specified as a value based class and should not be used where identity is needed. https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/doc-files/ValueBased.html > > I don't have a ready suggestion, but be forewarned that this use is not considered valid. @RogerRiggs Sounds reasonable. Could you please have a look at the latest commit? I tried to make a class to use as a key, instead of using integer. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 11 01:25:28 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 11 Mar 2022 01:25:28 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v16] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'randomwrapper' of https://github.com/YShow/jdk.git into randomwrapper - Remove atomicLong allocation and override next(int) method to throw UOE ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/d6376b29..8155593e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=14-15 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Mar 11 01:25:29 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 11 Mar 2022 01:25:29 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v15] In-Reply-To: References: Message-ID: On Sun, 6 Mar 2022 01:39:02 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Update javadoc All changes are commited, tests passed ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Mar 11 01:26:24 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 01:26:24 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v31] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refine test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/866b4606..0d1fc155 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=30 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=29-30 Stats: 302 lines in 1 file changed: 75 ins; 5 del; 222 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 11 01:28:13 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 01:28:13 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v32] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <2X1gf_SEh4wEzxcy-x3NzxTc_ohZkcSYk_BFe410lqA=.3e37a092-0d24-4a84-9f55-b7ded1536dee@github.com> > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refine test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/0d1fc155..9b9156c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=31 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=30-31 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 11 01:45:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 01:45:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v32] In-Reply-To: <2X1gf_SEh4wEzxcy-x3NzxTc_ohZkcSYk_BFe410lqA=.3e37a092-0d24-4a84-9f55-b7ded1536dee@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <2X1gf_SEh4wEzxcy-x3NzxTc_ohZkcSYk_BFe410lqA=.3e37a092-0d24-4a84-9f55-b7ded1536dee@github.com> Message-ID: On Fri, 11 Mar 2022 01:28:13 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refine test oops seems I wronglly added a teat case 0/1 will delete it later ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From smarks at openjdk.java.net Fri Mar 11 03:10:47 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 11 Mar 2022 03:10:47 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v32] In-Reply-To: <2X1gf_SEh4wEzxcy-x3NzxTc_ohZkcSYk_BFe410lqA=.3e37a092-0d24-4a84-9f55-b7ded1536dee@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <2X1gf_SEh4wEzxcy-x3NzxTc_ohZkcSYk_BFe410lqA=.3e37a092-0d24-4a84-9f55-b7ded1536dee@github.com> Message-ID: On Fri, 11 Mar 2022 01:28:13 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refine test @RogerRiggs Good point about `Integer` being value-based. We should probably use `String` instead. @XenoAmess I don't think we need `KeyStructure`. It's probably sufficient to change the map types to `Map` and then use `String.valueOf(i)` to generate strings to use as keys and values. (If we did need something like `KeyStructure`, it would be a perfect use of record classes.) Also, I don't think `tableSizeFor` needs quite as many cases. It's sufficient to test the edge and boundary cases. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Fri Mar 11 04:17:47 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 04:17:47 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v32] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> <2X1gf_SEh4wEzxcy-x3NzxTc_ohZkcSYk_BFe410lqA=.3e37a092-0d24-4a84-9f55-b7ded1536dee@github.com> Message-ID: On Fri, 11 Mar 2022 01:42:19 GMT, XenoAmess wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> refine test > > oops seems I wronglly added a teat case 0/1 > will delete it later > @XenoAmess I don't think we need `KeyStructure`. It's probably sufficient to change the map types to `Map` and then use `String.valueOf(i)` to generate strings to use as keys and values. (If we did need something like `KeyStructure`, it would be a perfect use of record classes.) Seems good. Will do it at about 12 hours later, when I off work. > Also, I don't think `tableSizeFor` needs quite as many cases. It's sufficient to test the edge and boundary cases. Well I just don't think there be any cost in adding them... after all they runs fast. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From jpai at openjdk.java.net Fri Mar 11 04:31:13 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 11 Mar 2022 04:31:13 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v10] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > 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 14 additional commits since the last revision: > > - Merge branch 'master' into 8282625 > - Correct indentation > - Add unit test for DecimalFormatSymbols.getLocale() > - Add comment about DecimalFormatSymbols being mutable objects. > - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." > > This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. > - Revert "Drop DecimalFormatSymbols.getLocale change" > > This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. > - Revert "Correct caching test" > > This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. > - Correct caching test > - Drop DecimalFormatSymbols.getLocale change > - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation. > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/11e9685d...84fa1fe7 src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192: > 190: > 191: /** > 192: * {@return locale used to create this instance} Hello Jim, the opening and closing `{`, I think aren't needed for a `@return` ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From dholmes at openjdk.java.net Fri Mar 11 04:31:43 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 11 Mar 2022 04:31:43 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver In-Reply-To: References: Message-ID: <55ool8tK46SW6luyv6x9JI_F0WaRLSHcYV231oLZplA=.99020740-5f35-44ec-919c-d44182a10595@github.com> On Wed, 9 Mar 2022 22:52:41 GMT, Mandy Chung wrote: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. I'd like to know if the explicit null check will lead to removal of the existing implicit null checks? Otherwise this is just "death by a thousand cuts" whether requireNonNull is inlined or not. ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From iklam at openjdk.java.net Fri Mar 11 04:56:23 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Mar 2022 04:56:23 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v4] In-Reply-To: References: Message-ID: <10c63f_4lXQrZZumBkYQzjpKoaD_BICnzEIn27u9eyI=.9107ac65-6882-4b79-9f35-d6997a25fca1@github.com> > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: zero GC heap filler arrays ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7748/files - new: https://git.openjdk.java.net/jdk/pull/7748/files/6974021f..be7673af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=02-03 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From david.holmes at oracle.com Fri Mar 11 05:57:20 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Mar 2022 15:57:20 +1000 Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: Message-ID: <2b212659-d920-171c-867a-7dbea8a1a69b@oracle.com> I can't find this comment in the PR so replying via email ... On 11/03/2022 9:24 am, Ioi Lam wrote: > On Wed, 9 Mar 2022 07:47:19 GMT, Thomas Stuefe wrote: > >>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >>> >>> Fixed zero build >> >> src/hotspot/share/utilities/hashtable.hpp line 42: >> >>> 40: >>> 41: LP64_ONLY(unsigned int _gap;) >>> 42: >> >> For 64-bit, you now lose packing potential in the theoretical case the following payload does not have to be aligned to 64 bit. E.g. for T=char, where the whole entry would fit into 8 bytes. Probably does not matter as long as entries are allocated individually from C-heap which is a lot more wasteful anyway. >> >> For 32-bit, I think you may have the same problem if the payload starts with a uint64_t. Would that not be aligned to a 64-bit boundary too? Whether or not you build on 64-bit? >> >> I think setting the memory, or at least the first 8..16 bytes, of the entry to zero in BasicHashtable::new_entry could be more robust: >> >> (16 bytes in case the payload starts with a long double but that may be overthinking it :) >> >> >> template BasicHashtableEntry* BasicHashtable::new_entry(unsigned int hashValue) { >> char* p = :new (NEW_C_HEAP_ARRAY(char, this->entry_size(), F); >> ::memset(p, 0, MIN2(this->entry_size(), 16)); // needs reproducable >> BasicHashtableEntry* entry = ::new (p) BasicHashtableEntry(hashValue); >> return entry; >> } >> >> If you are worried about performance, this may also be controlled by a template parameter, and then you do it just for the system dictionary. > > Thanks for pointing this out. I ran more tests and found that on certain platforms, there are other structures that have problems with uninitialized gaps. I ended up changing `os::malloc()` to zero the buffer when running with -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't matter too much for regular VM executions because `os::malloc()` already has a high overhead. This is raising red flags for me sorry. Every user of the JDK is now paying a penalty because of something only needed when dumping the shared archive. It might not be much but it is the old "death by a thousand cuts". Is there any way to tell the OS to pre-zero all memory provided to the current process, such that we could set that when dumping and not have to check on each allocation? And I have to wonder how easy it would be to re-introduce non-deterministic values in these data structures that are being dumped. Does malloc itself even guarantee to return the same set of addresses for the same sequence of requests in different executions of a program? Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7748 From kbarrett at openjdk.java.net Fri Mar 11 05:58:42 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Mar 2022 05:58:42 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v4] In-Reply-To: <10c63f_4lXQrZZumBkYQzjpKoaD_BICnzEIn27u9eyI=.9107ac65-6882-4b79-9f35-d6997a25fca1@github.com> References: <10c63f_4lXQrZZumBkYQzjpKoaD_BICnzEIn27u9eyI=.9107ac65-6882-4b79-9f35-d6997a25fca1@github.com> Message-ID: On Fri, 11 Mar 2022 04:56:23 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > zero GC heap filler arrays Changes requested by kbarrett (Reviewer). src/hotspot/share/gc/shared/collectedHeap.cpp line 449: > 447: allocator.initialize(start); > 448: DEBUG_ONLY(zap_filler_array(start, words, zap);) > 449: if (DumpSharedSpaces) { Probably shouldn't both zap and clear for dumping, to avoid wasting time. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Fri Mar 11 06:07:27 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Mar 2022 06:07:27 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v5] In-Reply-To: References: Message-ID: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @kimbarrett comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7748/files - new: https://git.openjdk.java.net/jdk/pull/7748/files/be7673af..584c6572 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=03-04 Stats: 3 lines in 1 file changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Fri Mar 11 06:07:28 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Mar 2022 06:07:28 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v4] In-Reply-To: References: <10c63f_4lXQrZZumBkYQzjpKoaD_BICnzEIn27u9eyI=.9107ac65-6882-4b79-9f35-d6997a25fca1@github.com> Message-ID: On Fri, 11 Mar 2022 05:55:20 GMT, Kim Barrett wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> zero GC heap filler arrays > > src/hotspot/share/gc/shared/collectedHeap.cpp line 449: > >> 447: allocator.initialize(start); >> 448: DEBUG_ONLY(zap_filler_array(start, words, zap);) >> 449: if (DumpSharedSpaces) { > > Probably shouldn't both zap and clear for dumping, to avoid wasting time. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Fri Mar 11 06:40:47 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Mar 2022 06:40:47 GMT Subject: RFR: 8253495: CDS generates non-deterministic output In-Reply-To: <2b212659-d920-171c-867a-7dbea8a1a69b@oracle.com> References: <2b212659-d920-171c-867a-7dbea8a1a69b@oracle.com> Message-ID: On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote: > > I ended up changing `os::malloc()` to zero the buffer when running with -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't matter too much for regular VM executions because `os::malloc()` already has a high overhead. > > This is raising red flags for me sorry. Every user of the JDK is now paying a penalty because of something only needed when dumping the shared archive. It might not be much but it is the old "death by a thousand cuts". Is there any way to tell the OS to pre-zero all memory provided to the current process, such that we could set that when dumping and not have to check on each allocation? I don't know how to tell the OS (or C library) to zero out the buffer returned by malloc. However, in the current code path, we already have a test for an uncommon condition when `os::malloc()` calls `MemTracker::record_malloc()` which calls `MallocTracker::record_malloc()` void* MallocTracker::record_malloc(void* malloc_base, size_t size, MEMFLAGS flags, const NativeCallStack& stack) { if (MemTracker::tracking_level() == NMT_detail) { MallocSiteTable::allocation_at(stack, size, &mst_marker, flags); } I can combine the tests for `MemTracker::tracking_level()` and `DumpSharedSpaces` into a single test and do more work only when the uncommon path is taken. This would require some refactoring of the MemTracker/MallocTracker code. I'd rather do that in a separate RFE. In fact, `MemTracker::_tracking_level` is tested twice in the current implementation. We can change it to do a single test in the most common case (NMT_summary) if we really want to cut down the number of tests. But honestly I don't think this makes any difference. > And I have to wonder how easy it would be to re-introduce non-deterministic values in these data structures that are being dumped. Does malloc itself even guarantee to return the same set of addresses for the same sequence of requests in different executions of a program? The malloc'ed objects are copied into the CDS archive at deterministic addresses. Any pointers inside such objects will be relocated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From david.holmes at oracle.com Fri Mar 11 06:48:07 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Mar 2022 16:48:07 +1000 Subject: RFR: 8253495: CDS generates non-deterministic output In-Reply-To: References: <2b212659-d920-171c-867a-7dbea8a1a69b@oracle.com> Message-ID: <3948464a-0a50-0155-3b42-28998b97801c@oracle.com> On 11/03/2022 4:40 pm, Ioi Lam wrote: > On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote: > >>> I ended up changing `os::malloc()` to zero the buffer when running with -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't matter too much for regular VM executions because `os::malloc()` already has a high overhead. >> >> This is raising red flags for me sorry. Every user of the JDK is now paying a penalty because of something only needed when dumping the shared archive. It might not be much but it is the old "death by a thousand cuts". Is there any way to tell the OS to pre-zero all memory provided to the current process, such that we could set that when dumping and not have to check on each allocation? > > I don't know how to tell the OS (or C library) to zero out the buffer returned by malloc. However, in the current code path, we already have a test for an uncommon condition when `os::malloc()` calls `MemTracker::record_malloc()` which calls `MallocTracker::record_malloc()` > > > void* MallocTracker::record_malloc(void* malloc_base, size_t size, MEMFLAGS flags, > const NativeCallStack& stack) > { > if (MemTracker::tracking_level() == NMT_detail) { > MallocSiteTable::allocation_at(stack, size, &mst_marker, flags); > } > > > I can combine the tests for `MemTracker::tracking_level()` and `DumpSharedSpaces` into a single test and do more work only when the uncommon path is taken. This would require some refactoring of the MemTracker/MallocTracker code. I'd rather do that in a separate RFE. > > In fact, `MemTracker::_tracking_level` is tested twice in the current implementation. We can change it to do a single test in the most common case (NMT_summary) if we really want to cut down the number of tests. But honestly I don't think this makes any difference. > >> And I have to wonder how easy it would be to re-introduce non-deterministic values in these data structures that are being dumped. Does malloc itself even guarantee to return the same set of addresses for the same sequence of requests in different executions of a program? > > The malloc'ed objects are copied into the CDS archive at deterministic addresses. Any pointers inside such objects will be relocated. Okay. I won't object further but I really don't like it - c'est la vie! I'll let others review the actual code changes in detail. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7748 From stuefe at openjdk.java.net Fri Mar 11 06:50:43 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Mar 2022 06:50:43 GMT Subject: RFR: 8253495: CDS generates non-deterministic output In-Reply-To: <2b212659-d920-171c-867a-7dbea8a1a69b@oracle.com> References: <2b212659-d920-171c-867a-7dbea8a1a69b@oracle.com> Message-ID: <3joACrACnlZ1rQDb6XV2MUdfdtPCq5ZnhXzWT4fi_MA=.a02524ef-9488-4e71-bfa1-58acf25ff080@github.com> On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote: > > Thanks for pointing this out. I ran more tests and found that on certain platforms, there are other structures that have problems with uninitialized gaps. I ended up changing `os::malloc()` to zero the buffer when running with -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't matter too much for regular VM executions because `os::malloc()` already has a high overhead. > > This is raising red flags for me sorry. Every user of the JDK is now paying a penalty because of something only needed when dumping the shared archive. It might not be much but it is the old "death by a thousand cuts". Well, he does it for `DumpSharedSpaces` only. Are you really worried about that one load+conditional jump? @iklam: I dislike the fact that CDS terminology is now in os::malloc. I would give this another flag, "ZapMalloc" or similar, and maybe merge it with the `DEBUG_ONLY(memset(..uninitBlockPad))` above. > Is there any way to tell the OS to pre-zero all memory provided to the current process, such that we could set that when dumping and not have to check on each allocation? No. Malloced memory is not provided by the OS but by the glibc, and it may be polluted with whatever the allocator did with it (eg pointers to chain free blocks), or by prior user payload. Glibc has a specific tunable, `glibc.malloc.perturb`, that initializes malloc memory to a given value, but you cannot directly set the value. It is very handy to check for uninitialized memory. Always wanted to add some tests that used it, but never got around. But obviously its nothing you could do in production. > > And I have to wonder how easy it would be to re-introduce non-deterministic values in these data structures that are being dumped. Does malloc itself even guarantee to return the same set of addresses for the same sequence of requests in different executions of a program? No, of course not. Non-Java threads may still run concurrently, no? System libraries do malloc too. But are pointer *values* even the problem? ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Fri Mar 11 06:55:23 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Mar 2022 06:55:23 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v6] In-Reply-To: References: Message-ID: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added helper function CollectedHeap::zap_filler_array_with ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7748/files - new: https://git.openjdk.java.net/jdk/pull/7748/files/584c6572..47e0238a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=04-05 Stats: 10 lines in 2 files changed: 6 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From stuefe at openjdk.java.net Fri Mar 11 06:55:24 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Mar 2022 06:55:24 GMT Subject: RFR: 8253495: CDS generates non-deterministic output In-Reply-To: <3948464a-0a50-0155-3b42-28998b97801c@oracle.com> References: <3948464a-0a50-0155-3b42-28998b97801c@oracle.com> Message-ID: <6vk6z5DuSwcSGtsGueROK1tL108ymh60lIi0SXL_Eh4=.ea5accf2-836f-49a0-b90d-1dbc77b827e3@github.com> On Fri, 11 Mar 2022 06:50:00 GMT, David Holmes wrote: > I can combine the tests for `MemTracker::tracking_level()` and `DumpSharedSpaces` into a single test and do more work only when the uncommon path is taken. This would require some refactoring of the MemTracker/MallocTracker code. I'd rather do that in a separate RFE. > > In fact, `MemTracker::_tracking_level` is tested twice in the current implementation. We can change it to do a single test in the most common case (NMT_summary) if we really want to cut down the number of tests. But honestly I don't think this makes any difference. > Before going down that road, I would really like to see some measurements, whether this really matters. malloc is not blindingly fast. The malloc code in glibc does test a lot of conditions too. If you need fast allocation (or well packed, for that matter), you need another allocator. Thats why we have Arenas. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From david.holmes at oracle.com Fri Mar 11 07:01:06 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Mar 2022 17:01:06 +1000 Subject: RFR: 8253495: CDS generates non-deterministic output In-Reply-To: <3joACrACnlZ1rQDb6XV2MUdfdtPCq5ZnhXzWT4fi_MA=.a02524ef-9488-4e71-bfa1-58acf25ff080@github.com> References: <2b212659-d920-171c-867a-7dbea8a1a69b@oracle.com> <3joACrACnlZ1rQDb6XV2MUdfdtPCq5ZnhXzWT4fi_MA=.a02524ef-9488-4e71-bfa1-58acf25ff080@github.com> Message-ID: On 11/03/2022 4:50 pm, Thomas Stuefe wrote: > On Fri, 11 Mar 2022 05:59:00 GMT, David Holmes wrote: > >>> Thanks for pointing this out. I ran more tests and found that on certain platforms, there are other structures that have problems with uninitialized gaps. I ended up changing `os::malloc()` to zero the buffer when running with -Xshare:dump. Hopefully one extra check of `if (DumpSharedSpaces)` doesn't matter too much for regular VM executions because `os::malloc()` already has a high overhead. >> >> This is raising red flags for me sorry. Every user of the JDK is now paying a penalty because of something only needed when dumping the shared archive. It might not be much but it is the old "death by a thousand cuts". > > Well, he does it for `DumpSharedSpaces` only. Are you really worried about that one load+conditional jump? As I said (and I'm not the only one who says this :) ) "death by a thousand cuts". > @iklam: I dislike the fact that CDS terminology is now in os::malloc. I would give this another flag, "ZapMalloc" or similar, and maybe merge it with the `DEBUG_ONLY(memset(..uninitBlockPad))` above. > >> Is there any way to tell the OS to pre-zero all memory provided to the current process, such that we could set that when dumping and not have to check on each allocation? > > No. Malloced memory is not provided by the OS but by the glibc, and it may be polluted with whatever the allocator did with it (eg pointers to chain free blocks), or by prior user payload. > > Glibc has a specific tunable, `glibc.malloc.perturb`, that initializes malloc memory to a given value, but you cannot directly set the value. It is very handy to check for uninitialized memory. Always wanted to add some tests that used it, but never got around. But obviously its nothing you could do in production. > >> >> And I have to wonder how easy it would be to re-introduce non-deterministic values in these data structures that are being dumped. Does malloc itself even guarantee to return the same set of addresses for the same sequence of requests in different executions of a program? > > No, of course not. Non-Java threads may still run concurrently, no? System libraries do malloc too. But are pointer *values* even the problem? I assumed that pointer values could be the problem, even if not presently, but apparently all the pointers get rewritten to use offsets from the known base of the shared archive - so not an issue. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7748 From kbarrett at openjdk.java.net Fri Mar 11 07:06:40 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Fri, 11 Mar 2022 07:06:40 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v6] In-Reply-To: References: Message-ID: <5ODb6bJ8c7yanEh6JuuOTxH5Wh7L_CAzi6n17VtOINM=.db57ef37-6138-4c6a-84f4-f2371244248e@github.com> On Fri, 11 Mar 2022 06:55:23 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added helper function CollectedHeap::zap_filler_array_with GC changes look good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7748 From stuefe at openjdk.java.net Fri Mar 11 07:16:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Mar 2022 07:16:41 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: <1E_zgqBQtByT4cXyk_dlbXGRVAQpCI6jlKXFIYovvVU=.3597bbf1-2ae7-4d41-9bef-79f77c90e8d3@github.com> References: <1E_zgqBQtByT4cXyk_dlbXGRVAQpCI6jlKXFIYovvVU=.3597bbf1-2ae7-4d41-9bef-79f77c90e8d3@github.com> Message-ID: On Thu, 10 Mar 2022 19:34:29 GMT, Ioi Lam wrote: >> src/hotspot/share/prims/jvm.cpp line 2887: >> >>> 2885: return; >>> 2886: } >>> 2887: #endif >> >> Should we do this for jni_AttachCurrentThread too? > > This hasn't been necessary for me because jni_AttachCurrentThread is not called during "java -Xshare:dump", which executes under a very strict condition and doesn't normally allow arbitrary JNI libraries to be loaded. Is reproducibility also a topic for users calling -Xdump with custom JNI coding? Or maybe having the VM instrumented somehow? Since it seems such an easy fix, I would prevent attaching too. At least the user would get a clear error message. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From stuefe at openjdk.java.net Fri Mar 11 07:21:49 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Mar 2022 07:21:49 GMT Subject: RFR: 8253495: CDS generates non-deterministic output In-Reply-To: References: Message-ID: <_qq1q2olwT_11EF476cn5DsQHdl-b8P-L2nJkGn3Aqk=.dfb932f7-a43e-4730-b4a1-7356efd7defa@github.com> On Fri, 11 Mar 2022 07:03:00 GMT, David Holmes wrote: > > Well, he does it for `DumpSharedSpaces` only. Are you really worried about that one load+conditional jump? > > As I said (and I'm not the only one who says this :) ) "death by a thousand cuts". Thank you, that is a good expression. I just wanted to clarify what you meant. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Fri Mar 11 08:31:45 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 11 Mar 2022 08:31:45 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: <1E_zgqBQtByT4cXyk_dlbXGRVAQpCI6jlKXFIYovvVU=.3597bbf1-2ae7-4d41-9bef-79f77c90e8d3@github.com> Message-ID: On Fri, 11 Mar 2022 07:13:35 GMT, Thomas Stuefe wrote: > Is reproducibility also a topic for users calling -Xdump with custom JNI coding? Or maybe having the VM instrumented somehow? Since it seems such an easy fix, I would prevent attaching too. At least the user would get a clear error message. It's impossible to execute arbitrary Java code when running "java -Xshare:dump", so this means there's no way to load a JNI library when creating a *static* CDS archive. The loading of JVMTI agents is also not supported. So this is not a case we need to handle. During *dynamic* CDS dumps, arbitrary Java code can execute, but we don't have a requirement for the *dynamic* CDS archive to be deterministic (at least not for now). ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From jpai at openjdk.java.net Fri Mar 11 09:01:39 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 11 Mar 2022 09:01:39 GMT Subject: RFR: 8282572: EnumSet should be a sealed class In-Reply-To: References: Message-ID: <-1PVJ7KeVSTj58YVYuzJTFmO9KUsLVt_MdqgmIlzWbw=.25130faa-22d1-4f25-85bd-5b9152e0eabf@github.com> On Tue, 8 Mar 2022 10:50:35 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to implement the enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? > > The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any sub-classes of their own. > > In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` and `RegularEnumSet` are the two permitted sub classes. Both of these sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for these 2 sub-classes was an option too. But I decided to start with the more restrictive option since we don't have any other sub-classes and if and when we do have their sub-classes, it's possible to change them to `non-sealed`. > > The `EnumSet` class implements the `java.io.Serializable` interface. As part of this change, manual tests have been run to make sure that changing this class to `sealed` and marking the sub-classes as `final` don't break any serialization/deserialization semantics, across Java version and/or user application versions. > > `tier1` testing across various platforms is currently in progress. The linked CSR has now been approved. ------------- PR: https://git.openjdk.java.net/jdk/pull/7741 From sundar at openjdk.java.net Fri Mar 11 09:07:44 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Fri, 11 Mar 2022 09:07:44 GMT Subject: RFR: 8282572: EnumSet should be a sealed class In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 10:50:35 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to implement the enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? > > The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any sub-classes of their own. > > In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` and `RegularEnumSet` are the two permitted sub classes. Both of these sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for these 2 sub-classes was an option too. But I decided to start with the more restrictive option since we don't have any other sub-classes and if and when we do have their sub-classes, it's possible to change them to `non-sealed`. > > The `EnumSet` class implements the `java.io.Serializable` interface. As part of this change, manual tests have been run to make sure that changing this class to `sealed` and marking the sub-classes as `final` don't break any serialization/deserialization semantics, across Java version and/or user application versions. > > `tier1` testing across various platforms is currently in progress. LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7741 From sgehwolf at openjdk.java.net Fri Mar 11 10:01:38 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Fri, 11 Mar 2022 10:01:38 GMT Subject: RFR: 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked In-Reply-To: References: Message-ID: On Wed, 20 Oct 2021 13:35:22 GMT, Martin Balao wrote: > I'd like to propose a fix for JDK-8275535. This fix reverts the behavior to the state previous to JDK-8160768, where an authentication failure stops from trying other LDAP servers with the same credentials [1]. After JDK-8160768 we have 2 possible loops to stop: the one that iterates over different URLs and the one that iterates over different endpoints (after a DNS query that returns multiple values). > > No test regressions observed in jdk/com/sun/jndi/ldap. > > -- > [1] - https://hg.openjdk.java.net/jdk/jdk/rev/a609d549992a#l2.137 Please don't auto-close this bot :) ------------- PR: https://git.openjdk.java.net/jdk/pull/6043 From jlaskey at openjdk.java.net Fri Mar 11 10:19:50 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 10:19:50 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v10] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 04:28:00 GMT, Jaikiran Pai 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 14 additional commits since the last revision: >> >> - Merge branch 'master' into 8282625 >> - Correct indentation >> - Add unit test for DecimalFormatSymbols.getLocale() >> - Add comment about DecimalFormatSymbols being mutable objects. >> - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." >> >> This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. >> - Revert "Drop DecimalFormatSymbols.getLocale change" >> >> This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. >> - Revert "Correct caching test" >> >> This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. >> - Correct caching test >> - Drop DecimalFormatSymbols.getLocale change >> - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation. >> - ... and 4 more: https://git.openjdk.java.net/jdk/compare/9cda7890...84fa1fe7 > > src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192: > >> 190: >> 191: /** >> 192: * {@return locale used to create this instance} > > Hello Jim, the opening and closing `{`, I think aren't needed for a `@return` This is actually a feature of JavaDoc. Accessor methods that require little description (self evident) can use {@return ...} to define the description and return in one go. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jpai at openjdk.java.net Fri Mar 11 10:34:51 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 11 Mar 2022 10:34:51 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v10] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 10:16:33 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/text/DecimalFormatSymbols.java line 192: >> >>> 190: >>> 191: /** >>> 192: * {@return locale used to create this instance} >> >> Hello Jim, the opening and closing `{`, I think aren't needed for a `@return` > > This is actually a feature of JavaDoc. Accessor methods that require little description (self evident) can use {@return ...} to define the description and return in one go. Didn't know that, thank you for clarifying. The rest of the changes look good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From jpai at openjdk.java.net Fri Mar 11 10:34:50 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 11 Mar 2022 10:34:50 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v10] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 18:34:27 GMT, Jim Laskey wrote: >> Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. >> >> >> @Benchmark >> public void bigDecimalDefaultLocale() { >> result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalLocaleAlternate() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void bigDecimalThaiLocale() { >> result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); >> } >> >> @Benchmark >> public void integerDefaultLocale() { >> result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerLocaleAlternate() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> @Benchmark >> public void integerThaiLocale() { >> result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); >> } >> >> >> Before: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s >> >> After: >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s >> MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s >> MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s >> MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s >> MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s >> MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s > > 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 14 additional commits since the last revision: > > - Merge branch 'master' into 8282625 > - Correct indentation > - Add unit test for DecimalFormatSymbols.getLocale() > - Add comment about DecimalFormatSymbols being mutable objects. > - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." > > This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. > - Revert "Drop DecimalFormatSymbols.getLocale change" > > This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. > - Revert "Correct caching test" > > This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. > - Correct caching test > - Drop DecimalFormatSymbols.getLocale change > - Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation. > - ... and 4 more: https://git.openjdk.java.net/jdk/compare/76644795...84fa1fe7 Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From mcimadamore at openjdk.java.net Fri Mar 11 11:01:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 11 Mar 2022 11:01:47 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v4] In-Reply-To: References: Message-ID: <98MGR3fb-NF05zLbITa2WQWaC-0vF-DeIp9r0PP5JBE=.2161c1c0-e3fe-4fdf-8bf7-974b32ec686d@github.com> On Thu, 10 Mar 2022 19:35:16 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Leave public for the time being src/java.base/share/classes/java/lang/runtime/Carrier.java line 48: > 46: > 47: /** > 48: * This class is used to create anonymous objects that have number and types of This is a bit ambiguous: anonymous "objects that have number and types of objects determined at runtime" almost seems like the clients have no control. I think what you want to say is that the shape is given by the client (e.g. how many longs, int, objects) - but the underlying implementation can vary. Maybe something like: A carrier is an anonymous objects that can store component values. Valid component value types are [...]. Clients can create new carrier instances by describing a carrier shape, that is, a MethodType whose parameter types describe the types of the carrier component values. src/java.base/share/classes/java/lang/runtime/Carrier.java line 57: > 55: * @since 19 > 56: */ > 57: /*non-public*/ What does this non-public comment mean? src/java.base/share/classes/java/lang/runtime/Carrier.java line 146: > 144: * @return constructor with arguments recasted and reordered > 145: */ > 146: private static MethodHandle reshapeConstructor(CarrierShape carrierShape, I like how reshape constructors and components is now shared across both implementations ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From lancea at openjdk.java.net Fri Mar 11 11:12:44 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 11 Mar 2022 11:12:44 GMT Subject: RFR: 8058924: FileReader(String) documentation is insufficient In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 02:30:35 GMT, Brian Burkhalter wrote: > Add a statement to the `java.io` package documentation clarifying how a `String` representing a _pathname string_ is interpreted in the package. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7767 From stuefe at openjdk.java.net Fri Mar 11 11:38:38 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 11 Mar 2022 11:38:38 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v2] In-Reply-To: References: <1E_zgqBQtByT4cXyk_dlbXGRVAQpCI6jlKXFIYovvVU=.3597bbf1-2ae7-4d41-9bef-79f77c90e8d3@github.com> Message-ID: On Fri, 11 Mar 2022 08:28:32 GMT, Ioi Lam wrote: >> Is reproducibility also a topic for users calling -Xdump with custom JNI coding? Or maybe having the VM instrumented somehow? Since it seems such an easy fix, I would prevent attaching too. At least the user would get a clear error message. > >> Is reproducibility also a topic for users calling -Xdump with custom JNI coding? Or maybe having the VM instrumented somehow? Since it seems such an easy fix, I would prevent attaching too. At least the user would get a clear error message. > > It's impossible to execute arbitrary Java code when running "java -Xshare:dump", so this means there's no way to load a JNI library when creating a *static* CDS archive. The loading of JVMTI agents is also not supported. So this is not a case we need to handle. > > During *dynamic* CDS dumps, arbitrary Java code can execute, but we don't have a requirement for the *dynamic* CDS archive to be deterministic (at least not for now). Thanks for that clarification. Never mind then :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From jlaskey at openjdk.java.net Fri Mar 11 13:13:44 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 13:13:44 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v4] In-Reply-To: <98MGR3fb-NF05zLbITa2WQWaC-0vF-DeIp9r0PP5JBE=.2161c1c0-e3fe-4fdf-8bf7-974b32ec686d@github.com> References: <98MGR3fb-NF05zLbITa2WQWaC-0vF-DeIp9r0PP5JBE=.2161c1c0-e3fe-4fdf-8bf7-974b32ec686d@github.com> Message-ID: On Fri, 11 Mar 2022 10:42:02 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Leave public for the time being > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 57: > >> 55: * @since 19 >> 56: */ >> 57: /*non-public*/ > > What does this non-public comment mean? We might switch to package private for String Template preview. I forgot that the test can't locate the class if I make it package private, > src/java.base/share/classes/java/lang/runtime/Carrier.java line 146: > >> 144: * @return constructor with arguments recasted and reordered >> 145: */ >> 146: private static MethodHandle reshapeConstructor(CarrierShape carrierShape, > > I like how reshape constructors and components is now shared across both implementations Refactoring is just another tool for the lazy. ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Fri Mar 11 15:17:30 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 15:17:30 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: - Use long array for primitives - Use long arrays for primitives ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/0849c65d..890ad4fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=03-04 Stats: 85 lines in 1 file changed: 14 ins; 26 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Fri Mar 11 15:17:32 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 15:17:32 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v4] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 22:53:39 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 346: >> >>> 344: * Carrier for longs and integers. >>> 345: */ >>> 346: private final int[] integers; >> >> I believe (@rose00 correct me if I'm wrong) that an `int[]` doesn't guarantee proper 64-but alignment of the first element in the array in 32-bit platforms. We ran into similar issues with the MemorySegment API, I believe. I think using a `long[]` if you want explicit 64-bit alignment is the safest choice. > > Makes sense. Easy change. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Fri Mar 11 15:17:31 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 15:17:31 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v4] In-Reply-To: <98MGR3fb-NF05zLbITa2WQWaC-0vF-DeIp9r0PP5JBE=.2161c1c0-e3fe-4fdf-8bf7-974b32ec686d@github.com> References: <98MGR3fb-NF05zLbITa2WQWaC-0vF-DeIp9r0PP5JBE=.2161c1c0-e3fe-4fdf-8bf7-974b32ec686d@github.com> Message-ID: On Fri, 11 Mar 2022 10:58:23 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Leave public for the time being > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 48: > >> 46: >> 47: /** >> 48: * This class is used to create anonymous objects that have number and types of > > This is a bit ambiguous: anonymous "objects that have number and types of objects determined at runtime" almost seems like the clients have no control. I think what you want to say is that the shape is given by the client (e.g. how many longs, int, objects) - but the underlying implementation can vary. Maybe something like: > > > A carrier is an anonymous objects that can store component values. Valid component value types are [...]. Clients can create new carrier instances by describing a carrier shape, that is, a MethodType whose parameter types describe the types of the carrier component values. Changed ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From weijun at openjdk.java.net Fri Mar 11 15:32:52 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Fri, 11 Mar 2022 15:32:52 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata The security related changes look fine, except for the year 2021. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From ckozak at ckozak.net Fri Mar 11 15:42:48 2022 From: ckozak at ckozak.net (Carter Kozak) Date: Fri, 11 Mar 2022 10:42:48 -0500 Subject: Request for an issue for LoggerFinderLoader error-message typo Message-ID: <3ab8bf41-0e9d-4b73-a919-60839a342f44@www.fastmail.com> Hello, I'd be grateful if someone could help me create an issue for a typo in LoggerFinderLoader. When multiple LoggerFinder implementations are found, a ServiceConfigurationError is thrown with message "More than on LoggerFinder implementation" rather than "More than one LoggerFinder implementation" (s/on/one). I've created a PR with a proposed fix, but I lack the ability to create an issue to track it: https://github.com/openjdk/jdk/pull/7780 Thank you, Carter Kozak From duke at openjdk.java.net Fri Mar 11 15:56:26 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 15:56:26 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v33] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - change KeyStructure to String - fix test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/9b9156c1..51871859 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=32 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=31-32 Stats: 133 lines in 1 file changed: 0 ins; 51 del; 82 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From mcimadamore at openjdk.java.net Fri Mar 11 15:56:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 11 Mar 2022 15:56:47 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 15:17:30 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Use long array for primitives > - Use long arrays for primitives Marked as reviewed by mcimadamore (Reviewer). src/java.base/share/classes/java/lang/runtime/Carrier.java line 51: > 49: * while avoiding primitive boxing associated with collection objects. Component values > 50: * can be primitive or Object. Clients can create new carrier instances by describing a > 51: * carrier shape, that is, a MethodType whose parameter types describe the Suggestion: * carrier shape, that is, a {@linkplain MethodType method type} whose parameter types describe the src/java.base/share/classes/java/lang/runtime/Carrier.java line 380: > 378: } > 379: > 380: return Unsafe.ARRAY_LONG_BASE_OFFSET + Shouldn't you add the offset of the first `int` value in the array to the resulting expression? E.g. I'm assuming we're storing `long`s first and `int`s after? If so, `int` values will be located at an offset from the start of the array. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From mcimadamore at openjdk.java.net Fri Mar 11 15:56:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 11 Mar 2022 15:56:47 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 15:48:37 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use long array for primitives >> - Use long arrays for primitives > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 380: > >> 378: } >> 379: >> 380: return Unsafe.ARRAY_LONG_BASE_OFFSET + > > Shouldn't you add the offset of the first `int` value in the array to the resulting expression? E.g. I'm assuming we're storing `long`s first and `int`s after? If so, `int` values will be located at an offset from the start of the array. Ah ok - I see - the constructor method handle binds the correct offset, adding the required constant offset (for all the long values). So my comment it's mostly stylistic. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From duke at openjdk.java.net Fri Mar 11 16:13:47 2022 From: duke at openjdk.java.net (Glavo) Date: Fri, 11 Mar 2022 16:13:47 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 15:17:30 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Use long array for primitives > - Use long arrays for primitives This is very exciting, it sounds like we can implement unboxed variable arguments lists based on it in the future ([JDK-8182862](https://bugs.openjdk.java.net/browse/JDK-8182862)), is that so? ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From redestad at openjdk.java.net Fri Mar 11 16:13:44 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 11 Mar 2022 16:13:44 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 22:52:41 GMT, Mandy Chung wrote: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. Historically I've found that `Objects.requireNonNull` compile down to be roughly equivalent to an implicit null check as long as a NPE is actually never thrown, see https://bugs.openjdk.java.net/browse/JDK-8042127 With the recent change to force-inline `requireNonNull` the profile pollution part of this issue might no longer be relevant. I'll see if I can carve out time to do some experiments to revisit and perhaps even close out that old bug, but I don't think this is much to worry about for this change since provoking such NPEs should be rare in production settings. Always a risk adding explicit calls, of course: A few added cycles on startup, a few extra bytecode that _could_ interfere with inlining of the `checkReceiver` method.. I suggest a quick sanity run of our reflection (micro)benchmarks ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From jlaskey at openjdk.java.net Fri Mar 11 16:44:39 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 16:44:39 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 15:44:49 GMT, Maurizio Cimadamore wrote: >> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: >> >> - Use long array for primitives >> - Use long arrays for primitives > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 51: > >> 49: * while avoiding primitive boxing associated with collection objects. Component values >> 50: * can be primitive or Object. Clients can create new carrier instances by describing a >> 51: * carrier shape, that is, a MethodType whose parameter types describe the > > Suggestion: > > * carrier shape, that is, a {@linkplain MethodType method type} whose parameter types describe the Done ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Fri Mar 11 16:44:40 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 16:44:40 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: References: Message-ID: <5x9GUXaaXIH4veG8pn6gTYlmIVpjYm7Vfzk3HNJw-Ck=.e3ea6012-4366-4396-ac1a-a93ceda9932c@github.com> On Fri, 11 Mar 2022 15:53:08 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 380: >> >>> 378: } >>> 379: >>> 380: return Unsafe.ARRAY_LONG_BASE_OFFSET + >> >> Shouldn't you add the offset of the first `int` value in the array to the resulting expression? E.g. I'm assuming we're storing `long`s first and `int`s after? If so, `int` values will be located at an offset from the start of the array. > > Ah ok - I see - the constructor method handle binds the correct offset, adding the required constant offset (for all the long values). So my comment it's mostly stylistic. I'll add commentary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From duke at openjdk.java.net Fri Mar 11 16:45:51 2022 From: duke at openjdk.java.net (XenoAmess) Date: Fri, 11 Mar 2022 16:45:51 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v33] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Mar 2022 15:56:26 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - change KeyStructure to String > - fix test ![image](https://user-images.githubusercontent.com/17455337/157909872-8702460d-6945-435a-b866-02394b0fc220.png) seems ci fails for network failure. @stuart-marks I refine the tests using String to replace KeyStructure. Please have a look. thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From jlaskey at openjdk.java.net Fri Mar 11 16:56:45 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 16:56:45 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: References: Message-ID: <_QH-26ffS3FPYry9tmQGwunHc3FY62kzCW17mWPZSDY=.01248c75-fd67-4e65-974d-e3f9ffda1dd7@github.com> On Fri, 11 Mar 2022 15:17:30 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with two additional commits since the last revision: > > - Use long array for primitives > - Use long arrays for primitives That might be more in the realm of Valhalla. This is more for capturing arguments from vararg bootstrap methods. But, I can see your use case. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Fri Mar 11 17:03:28 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 17:03:28 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v6] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clarify primitive store in array carriers. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/890ad4fa..f6b07254 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=04-05 Stats: 10 lines in 1 file changed: 5 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Fri Mar 11 17:41:24 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 11 Mar 2022 17:41:24 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v7] In-Reply-To: References: Message-ID: <3TtxBdip6_ZuejCtdI5OWgHpYmClTdzlzUbsbuw95Tw=.d366de36-f163-4972-b245-472bd3269937@github.com> > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Revert to {@return} style comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/f6b07254..10d1cc93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=05-06 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From daniel.fuchs at oracle.com Fri Mar 11 18:30:19 2022 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 11 Mar 2022 18:30:19 +0000 Subject: Request for an issue for LoggerFinderLoader error-message typo In-Reply-To: <3ab8bf41-0e9d-4b73-a919-60839a342f44@www.fastmail.com> References: <3ab8bf41-0e9d-4b73-a919-60839a342f44@www.fastmail.com> Message-ID: <56b84d2f-0153-b8d6-c2b8-b2c72b69f79a@oracle.com> Hi Carter, I have created https://bugs.openjdk.java.net/browse/JDK-8283049 I will sponsor the changed after it's been reviewed and integrated. best regards, -- daniel On 11/03/2022 15:42, Carter Kozak wrote: > When multiple LoggerFinder implementations are found, a ServiceConfigurationError is thrown with message "More than on LoggerFinder implementation" rather than "More than one LoggerFinder implementation" (s/on/one). From duke at openjdk.java.net Fri Mar 11 18:45:03 2022 From: duke at openjdk.java.net (Carter Kozak) Date: Fri, 11 Mar 2022 18:45:03 GMT Subject: RFR: 8283049: Fix non-singleton LoggerFinder error message: s/on/one Message-ID: 8283049: Fix non-singleton LoggerFinder error message: s/on/one ------------- Commit messages: - 8283049: Fix non-singleton LoggerFinder error message: s/on/one Changes: https://git.openjdk.java.net/jdk/pull/7780/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7780&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283049 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7780/head:pull/7780 PR: https://git.openjdk.java.net/jdk/pull/7780 From duke at openjdk.java.net Fri Mar 11 18:45:04 2022 From: duke at openjdk.java.net (Carter Kozak) Date: Fri, 11 Mar 2022 18:45:04 GMT Subject: RFR: 8283049: Fix non-singleton LoggerFinder error message: s/on/one In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 22:28:14 GMT, Carter Kozak wrote: > 8283049: Fix non-singleton LoggerFinder error message: s/on/one Unfortunately I lack the permissions to create an issue for this. @dfuch is there any chance you could help me create the issue? ------------- PR: https://git.openjdk.java.net/jdk/pull/7780 From dfuchs at openjdk.java.net Fri Mar 11 19:10:06 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 11 Mar 2022 19:10:06 GMT Subject: RFR: 8283049: Fix non-singleton LoggerFinder error message: s/on/one In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 22:28:14 GMT, Carter Kozak wrote: > 8283049: Fix non-singleton LoggerFinder error message: s/on/one I changed the bug title to match the PR title. test/jdk/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java line 233: > 231: } > 232: } else if (singleton) { > 233: if (!warning.contains("java.util.ServiceConfigurationError: More than one LoggerFinder implementation")) { please add 8283049 to the `@bug` list above since the test actually verifies the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/7780 From jbhateja at openjdk.java.net Fri Mar 11 19:10:09 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 11 Mar 2022 19:10:09 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v14] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Reducing the invocation count and compile thresholds for RoundTests.java. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/fcb73212..2519a58c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=12-13 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Fri Mar 11 19:10:11 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 11 Mar 2022 19:10:11 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v9] In-Reply-To: <7lwsCvdSjkvDYJNwuA7fVPrWFUbzchuwx0Z3IID5VZw=.0c00c3d7-2106-40df-88bc-38bf7e2655f9@github.com> References: <2jFjnftd7VluGsxgp8BK0vgHA68VrgGREj0fk7F6Dhk=.e40ddcaa-5a31-4115-976d-5f43e94b8ccf@github.com> <7lwsCvdSjkvDYJNwuA7fVPrWFUbzchuwx0Z3IID5VZw=.0c00c3d7-2106-40df-88bc-38bf7e2655f9@github.com> Message-ID: On Thu, 10 Mar 2022 14:29:36 GMT, Joe Darcy wrote: >> Hi @jddarcy , >> >> Test has been modified on the same lines using generic options which manipulate compilation thresholds and agnostic to target platforms. >> >> * @run main/othervm -XX:Tier3CompileThreshold=100 -XX:CompileThresholdScaling=0.01 -XX:+TieredCompilation RoundTests >> >> Verified that RoundTests::test* methods gets compiled by c2. >> Test execution time with and without change is almost same ~7.80sec over Skylake-server. >> >> Regards > > To be more explicit, the existing RoundTests.java test runs in a fraction of a second. The updated test runs many times slower, even if now under 10 second, at least on some platforms. > > Can something closer to the original performance be restored? > > As a tier 1 library test, these tests are run quite frequently. Hi @jddarcy , Earlier none of the test methods in RoundTests.java were compiled on account of low invocation count, a loop with 2000 iterations under the influence controlled compilation threshold now triggers tier4 compilation of test points. I did several runs in Skylake machine with patch and without patch and could see no perceptible difference in runtime due to modification. I have further reduced the invocation count and compile threshold. Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Fri Mar 11 19:18:55 2022 From: duke at openjdk.java.net (Carter Kozak) Date: Fri, 11 Mar 2022 19:18:55 GMT Subject: RFR: 8283049: Fix non-singleton LoggerFinder error message: s/on/one [v2] In-Reply-To: References: Message-ID: > 8283049: Fix non-singleton LoggerFinder error message: s/on/one Carter Kozak has updated the pull request incrementally with one additional commit since the last revision: Add 8283049 to LoggerFinderLoaderTest @bug docs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7780/files - new: https://git.openjdk.java.net/jdk/pull/7780/files/a78180d5..8406b3e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7780&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7780&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7780.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7780/head:pull/7780 PR: https://git.openjdk.java.net/jdk/pull/7780 From duke at openjdk.java.net Fri Mar 11 19:18:55 2022 From: duke at openjdk.java.net (Carter Kozak) Date: Fri, 11 Mar 2022 19:18:55 GMT Subject: RFR: 8283049: Fix non-singleton LoggerFinder error message: s/on/one [v2] In-Reply-To: References: Message-ID: <_D21PHOBfpk38ZPOQ0-drZSNPuaKIWaEhDVK55_bb7s=.695c2d06-a636-4a44-b5da-198a181d3677@github.com> On Fri, 11 Mar 2022 19:07:59 GMT, Daniel Fuchs wrote: >> Carter Kozak has updated the pull request incrementally with one additional commit since the last revision: >> >> Add 8283049 to LoggerFinderLoaderTest @bug docs > > test/jdk/java/lang/System/LoggerFinder/internal/LoggerFinderLoaderTest/LoggerFinderLoaderTest.java line 233: > >> 231: } >> 232: } else if (singleton) { >> 233: if (!warning.contains("java.util.ServiceConfigurationError: More than one LoggerFinder implementation")) { > > please add 8283049 to the `@bug` list above since the test actually verifies the fix. Updated, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7780 From smarks at openjdk.java.net Fri Mar 11 19:46:50 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 11 Mar 2022 19:46:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v33] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Mar 2022 15:56:26 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - change KeyStructure to String > - fix test Regarding the number of test cases for `tableSizeForCases` and `populatedCapacityCases`... the issue is not necessarily with execution time (although if the test is slow it is a problem). The issues are more around: Is this testing anything useful, and does this make sense to the reader? I think we can rely on the monotonicity of these functions. If populating a map both with 49 and with 96 mappings results in a table length of 128, we don't need to test that all the intermediate inputs also result in a table length of 128. Including all the intermediate inputs makes the source code more bulky and requires future readers/maintainers to hunt around in the long list of tests to figure out which ones are significant. Really, the only ones that are significant are the boundary cases, so just keep those. Adding more tests that aren't relevant actually does hurt, even if they execute quickly. So: please cut out all the extra test cases that aren't near the boundary cases. I'm not sure what's going on with the build. The builds are in GitHub Actions and they aren't necessarily reliable, so I wouldn't worry about them too much. I'll run the final version through our internal build/test system before integration. (I've also done this previously, and the results were fine.) test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 61: > 59: String String = Integer.toString(i); > 60: map.put(String, String); > 61: } Small details here... the `String` variable should be lower case. But really this method should be inlined into `putN`, since that's the method that needs to generate mappings. Then, `makeMap` should call `putN`. test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 107: > 105: for (int i = 0; i < size; ++i) { > 106: putMap(map, i); > 107: } Replace this loop with a call to `putN`. test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 131: > 129: void putN(Map map, int n) { > 130: for (int i = 0; i < n; i++) { > 131: putMap(map, i); Inline `putMap` here. test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 317: > 315: public void defaultCapacity(Supplier> s) { > 316: Map map = s.get(); > 317: putMap(map, 0); `map.put("", "")` test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 343: > 341: public void requestedCapacity(String label, int cap, Supplier> s) { > 342: Map map = s.get(); > 343: putMap(map, 0); No need to generate a key/value pair here, just use string literals, e.g. `map.put("", "")`. test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 430: > 428: map.putAll(makeMap(size)); > 429: }) > 430: ); Wait, did this get reindented? Adding line breaks totally destroys the tabular nature of test data. Please restore. Yes, the lines end up being longer than the usual limit, but the benefit of having things in a nice table outweighs to cost of having the lines be somewhat over-limit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From smarks at openjdk.java.net Fri Mar 11 20:31:52 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 11 Mar 2022 20:31:52 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v16] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 01:25:28 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'randomwrapper' of https://github.com/YShow/jdk.git into randomwrapper > - Remove atomicLong allocation and override next(int) method to throw UOE A small spec change is necessary; please make it here, and I'll copy it into the CSR. src/java.base/share/classes/java/util/Random.java line 98: > 96: private RandomWrapper(RandomGenerator randomToWrap) { > 97: super(null); > 98: this.generator = Objects.requireNonNull(randomToWrap); Can remove `requireNonNull` here; see other comments. At your option, add a comment saying that `randomToWrap` must not be null. This is easy to verify since there's only one caller elsewhere in this file. src/java.base/share/classes/java/util/Random.java line 320: > 318: * @param generator the {@code RandomGenerator} calls are delegated to > 319: * @return the delegating {@code Random} instance > 320: */ Need to add @throws NullPointerException if generator is null src/java.base/share/classes/java/util/Random.java line 327: > 325: return new RandomWrapper(generator); > 326: } > 327: I'd suggest adding Objects.requireNonNull(generator) as the first line of this method. In fact if null is passed, NPE is thrown already, as the `instanceof` will be false and then the `RandomWrapper` constructor will throw NPE. However, verifying this requires a bit of hunting around and some flow analysis to determine this. Might as well make the null check explicit at the top of this method. The now-redundant check can be removed from `RandomWrapper`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From naoto at openjdk.java.net Fri Mar 11 20:48:17 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Mar 2022 20:48:17 GMT Subject: RFR: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value Message-ID: `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type. ------------- Commit messages: - 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value Changes: https://git.openjdk.java.net/jdk/pull/7790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7790&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282929 Stats: 70 lines in 2 files changed: 65 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7790/head:pull/7790 PR: https://git.openjdk.java.net/jdk/pull/7790 From sviswanathan at openjdk.java.net Fri Mar 11 21:49:56 2022 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 11 Mar 2022 21:49:56 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v2] In-Reply-To: <3JoM4khNMz85gwfyxZeBNxJCZ_B7826cc-iO4pHtTJM=.5b21a96e-b2f5-4093-a763-eec2b6d77a2e@github.com> References: <3JoM4khNMz85gwfyxZeBNxJCZ_B7826cc-iO4pHtTJM=.5b21a96e-b2f5-4093-a763-eec2b6d77a2e@github.com> Message-ID: On Thu, 3 Mar 2022 05:42:23 GMT, Jatin Bhateja wrote: >> The testing for this PR doesn't look adequate to me. I don't see any testing for the values where the behavior of round has been redefined at points in the last decade. See JDK-8010430 and JDK-6430675, both of which have regression tests in the core libs area. Thanks. > > Hi @jddarcy , can you kindly validate your feedback, it has been incorporated. @jatin-bhateja There is a failure reported in the Pre-submit tests on Windows x64 for compiler/vectorization/TestRoundVect.java. Could you please take a look? ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From naoto at openjdk.java.net Fri Mar 11 22:20:38 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 11 Mar 2022 22:20:38 GMT Subject: RFR: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value [v2] In-Reply-To: References: Message-ID: > `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Refined the test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7790/files - new: https://git.openjdk.java.net/jdk/pull/7790/files/a6cbf914..5064e354 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7790&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7790&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7790/head:pull/7790 PR: https://git.openjdk.java.net/jdk/pull/7790 From mchung at openjdk.java.net Fri Mar 11 22:49:25 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Mar 2022 22:49:25 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v2] In-Reply-To: References: Message-ID: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. Mandy Chung 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: - Move the null check after isInstance check - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8282776 - JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7766/files - new: https://git.openjdk.java.net/jdk/pull/7766/files/8af60582..c7224f2f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=00-01 Stats: 688 lines in 35 files changed: 522 ins; 56 del; 110 mod Patch: https://git.openjdk.java.net/jdk/pull/7766.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7766/head:pull/7766 PR: https://git.openjdk.java.net/jdk/pull/7766 From mchung at openjdk.java.net Fri Mar 11 22:52:42 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 11 Mar 2022 22:52:42 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v2] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 22:49:25 GMT, Mandy Chung wrote: >> A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. > > Mandy Chung 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: > > - Move the null check after isInstance check > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8282776 > - JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver I did a quick sanity run of the reflection microbenchmarks. I eyeball the numbers and don't spot any difference. OTOH, since the `isInstance` check covers the null check, moving the null check inside the exception case is a better fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From mikael at openjdk.java.net Fri Mar 11 23:47:04 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 11 Mar 2022 23:47:04 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 Message-ID: Background, from JBS: src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] 942 | check_and_push(context, lengths, VM_MALLOC_BLK); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) | ^~~~~~~~~~~~~~ Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. Details: Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. Testing: tier1 + builds-tier{2,3,4,5} ------------- Commit messages: - 8283059: Uninitialized warning in check_code.c with GCC 11.2 Changes: https://git.openjdk.java.net/jdk/pull/7794/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7794&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283059 Stats: 22 lines in 1 file changed: 5 ins; 0 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/7794.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7794/head:pull/7794 PR: https://git.openjdk.java.net/jdk/pull/7794 From asemenyuk at openjdk.java.net Fri Mar 11 23:58:00 2022 From: asemenyuk at openjdk.java.net (Alexey Semenyuk) Date: Fri, 11 Mar 2022 23:58:00 GMT Subject: RFR: JDK-8236128: Allow jpackage create installers for services Message-ID: Implementation of [JDK-8275062: "Allow jpackage create installers for services"](https://bugs.openjdk.java.net/browse/JDK-8275062) CSR ------------- Commit messages: - Whitespace cleanup - Whitespace cleanup - JDK-8236128: Allow jpackage create installers for services - Sync l10n files. Fix copyright year - Minor formatting fix - Merge fix - Merge fixed - Merge branch 'master' into JDK-8236128 - Merge branch 'JDK-8236128' of https://github.com/alexeysemenyukoracle/jdk into JDK-8236128 - Bugfix - ... and 110 more: https://git.openjdk.java.net/jdk/compare/cd234f5d...0ff8e9aa Changes: https://git.openjdk.java.net/jdk/pull/7793/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7793&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8236128 Stats: 2769 lines in 64 files changed: 2508 ins; 121 del; 140 mod Patch: https://git.openjdk.java.net/jdk/pull/7793.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7793/head:pull/7793 PR: https://git.openjdk.java.net/jdk/pull/7793 From joehw at openjdk.java.net Sat Mar 12 00:34:41 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Sat, 12 Mar 2022 00:34:41 GMT Subject: RFR: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value [v2] In-Reply-To: References: Message-ID: <6pHxbPIB0nklM6wUOhO68T1NXQX9gqxYHE9wCcsyaGE=.c40b0b1b-0adc-496a-982d-968fc25992f2@github.com> On Fri, 11 Mar 2022 22:20:38 GMT, Naoto Sato wrote: >> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7790 From duke at openjdk.java.net Sat Mar 12 01:26:24 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sat, 12 Mar 2022 01:26:24 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v17] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: make changes proposed ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/8155593e..53c651f1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=15-16 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sat Mar 12 01:26:25 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Sat, 12 Mar 2022 01:26:25 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v16] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 01:25:28 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'randomwrapper' of https://github.com/YShow/jdk.git into randomwrapper > - Remove atomicLong allocation and override next(int) method to throw UOE Alright all changes were made, tests passed ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Sat Mar 12 01:35:23 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 12 Mar 2022 01:35:23 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v34] In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: > 8281631: HashMap copy constructor and putAll can over-allocate table XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refine test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7431/files - new: https://git.openjdk.java.net/jdk/pull/7431/files/51871859..a980bda4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=33 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7431&range=32-33 Stats: 350 lines in 1 file changed: 2 ins; 291 del; 57 mod Patch: https://git.openjdk.java.net/jdk/pull/7431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7431/head:pull/7431 PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sat Mar 12 01:35:28 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 12 Mar 2022 01:35:28 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v33] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <7sbvT7yEM1aPIt3sDXHCJnMOfrFtOLAqESjgo-3PW8E=.8146d589-0159-4644-8859-88ff7b55c144@github.com> On Fri, 11 Mar 2022 19:09:25 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with two additional commits since the last revision: >> >> - change KeyStructure to String >> - fix test > > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 61: > >> 59: String String = Integer.toString(i); >> 60: map.put(String, String); >> 61: } > > Small details here... the `String` variable should be lower case. But really this method should be inlined into `putN`, since that's the method that needs to generate mappings. Then, `makeMap` should call `putN`. @stuart-marks done. > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 107: > >> 105: for (int i = 0; i < size; ++i) { >> 106: putMap(map, i); >> 107: } > > Replace this loop with a call to `putN`. @stuart-marks done. > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 131: > >> 129: void putN(Map map, int n) { >> 130: for (int i = 0; i < n; i++) { >> 131: putMap(map, i); > > Inline `putMap` here. @stuart-marks done. > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 317: > >> 315: public void defaultCapacity(Supplier> s) { >> 316: Map map = s.get(); >> 317: putMap(map, 0); > > `map.put("", "")` @stuart-marks done. > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 343: > >> 341: public void requestedCapacity(String label, int cap, Supplier> s) { >> 342: Map map = s.get(); >> 343: putMap(map, 0); > > No need to generate a key/value pair here, just use string literals, e.g. `map.put("", "")`. @stuart-marks done. > test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 430: > >> 428: map.putAll(makeMap(size)); >> 429: }) >> 430: ); > > Wait, did this get reindented? Adding line breaks totally destroys the tabular nature of test data. Please restore. Yes, the lines end up being longer than the usual limit, but the benefit of having things in a nice table outweighs to cost of having the lines be somewhat over-limit. @stuart-marks done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sat Mar 12 01:37:11 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 12 Mar 2022 01:37:11 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v33] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Mar 2022 19:40:39 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with two additional commits since the last revision: >> >> - change KeyStructure to String >> - fix test > > Regarding the number of test cases for `tableSizeForCases` and `populatedCapacityCases`... the issue is not necessarily with execution time (although if the test is slow it is a problem). The issues are more around: Is this testing anything useful, and does this make sense to the reader? > > I think we can rely on the monotonicity of these functions. If populating a map both with 49 and with 96 mappings results in a table length of 128, we don't need to test that all the intermediate inputs also result in a table length of 128. Including all the intermediate inputs makes the source code more bulky and requires future readers/maintainers to hunt around in the long list of tests to figure out which ones are significant. Really, the only ones that are significant are the boundary cases, so just keep those. Adding more tests that aren't relevant actually does hurt, even if they execute quickly. So: please cut out all the extra test cases that aren't near the boundary cases. > > I'm not sure what's going on with the build. The builds are in GitHub Actions and they aren't necessarily reliable, so I wouldn't worry about them too much. I'll run the final version through our internal build/test system before integration. (I've also done this previously, and the results were fine.) @stuart-marks all the changes to the test you requested at last review comments are done. please have a look, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Sat Mar 12 01:45:38 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 12 Mar 2022 01:45:38 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v33] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Mar 2022 19:40:39 GMT, Stuart Marks wrote: > I think we can rely on the monotonicity of these functions. If populating a map both with 49 and with 96 mappings results in a table length of 128, we don't need to test that all the intermediate inputs also result in a table length of 128. Including all the intermediate inputs makes the source code more bulky and requires future readers/maintainers to hunt around in the long list of tests to figure out which ones are significant. Really, the only ones that are significant are the boundary cases, so just keep those. Adding more tests that aren't relevant actually does hurt, even if they execute quickly. So: please cut out all the extra test cases that aren't near the boundary cases. what I worried is, the boundary this is based on the current table size calculating mechanic in HashMap. If people change the mechanic in HashMap, then the boundary would change. But well, this is a white box text for HashMap (and HashMap-like) classes after all, so maybe I'm just over overthinking too much. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From almatvee at openjdk.java.net Sat Mar 12 03:19:11 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Sat, 12 Mar 2022 03:19:11 GMT Subject: RFR: 8282407: Missing ')' in MacResources.properties Message-ID: - Fixed by adding missing ']'. - I changed '()' to '[]', since other error messages use '[]' and not '()'. ------------- Commit messages: - 8282407: Missing ')' in MacResources.properties Changes: https://git.openjdk.java.net/jdk/pull/7797/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7797&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282407 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7797.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7797/head:pull/7797 PR: https://git.openjdk.java.net/jdk/pull/7797 From duke at openjdk.java.net Sat Mar 12 09:57:08 2022 From: duke at openjdk.java.net (xpbob) Date: Sat, 12 Mar 2022 09:57:08 GMT Subject: RFR: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java Message-ID: * Constructs an empty list with an initial capacity of ten => * Constructs an empty list with default sized empty instances. private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; DEFAULTCAPACITY_EMPTY_ELEMENTDATA is empty and the length is 0 ------------- Commit messages: - 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java Changes: https://git.openjdk.java.net/jdk/pull/7799/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7799&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283067 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7799.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7799/head:pull/7799 PR: https://git.openjdk.java.net/jdk/pull/7799 From duke at openjdk.java.net Sat Mar 12 12:24:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 12 Mar 2022 12:24:40 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v2] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 22:49:25 GMT, Mandy Chung wrote: >> A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. > > Mandy Chung 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: > > - Move the null check after isInstance check > - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8282776 > - JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 424: > 422: throw new IncompatibleClassChangeError(msg); > 423: } else { > 424: throw new NullPointerException(); Since?we?know which?`member` this?is?trying to?invoke, the?**NPE** can?be?constructed with?a?[JEP?358](https://openjdk.java.net/jeps/358)?style?message. src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 456: > 454: throw new IncompatibleClassChangeError(msg); > 455: } else { > 456: throw new NullPointerException(); Since?we?know which?`member` this?is?trying to?invoke, the?**NPE** can?be?constructed with?a?[JEP?358](https://openjdk.java.net/jeps/358)?style?message. ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From duke at openjdk.java.net Sat Mar 12 15:01:37 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sat, 12 Mar 2022 15:01:37 GMT Subject: RFR: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 09:48:14 GMT, xpbob wrote: > * Constructs an empty list with an initial capacity of ten > > => > > * Constructs an empty list with default sized empty instances. > > > private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; > > DEFAULTCAPACITY_EMPTY_ELEMENTDATA is empty and the length is 0 The comment is correct, it is just that the backing array allocation is delayed until the first element is added to the list. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7799 From lancea at openjdk.java.net Sat Mar 12 16:33:38 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 12 Mar 2022 16:33:38 GMT Subject: RFR: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value [v2] In-Reply-To: References: Message-ID: <7FMcOb-d6KfQt7eJeto4taZEc9iGV1p0HwGKyNA7rJY=.5681f965-a15d-4b2b-8d35-4871b1074bc4@github.com> On Fri, 11 Mar 2022 22:20:38 GMT, Naoto Sato wrote: >> `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined the test Marked as reviewed by lancea (Reviewer). test/jdk/java/text/Format/DecimalFormat/ToLocalizedPatternTest.java line 29: > 27: * @summary Verifies that toLocalizedPattern() method correctly returns > 28: * monetary symbols in a currency formatter > 29: * @run testng ToLocalizedPatternTest Maybe run in othervm mode? ------------- PR: https://git.openjdk.java.net/jdk/pull/7790 From jbhateja at openjdk.java.net Sat Mar 12 19:58:37 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sat, 12 Mar 2022 19:58:37 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Creating separate test for round double under feature check. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/2519a58c..e4d4e29b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=13-14 Stats: 239 lines in 3 files changed: 143 ins; 96 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From naoto at openjdk.java.net Sat Mar 12 20:36:39 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Sat, 12 Mar 2022 20:36:39 GMT Subject: RFR: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value [v2] In-Reply-To: <7FMcOb-d6KfQt7eJeto4taZEc9iGV1p0HwGKyNA7rJY=.5681f965-a15d-4b2b-8d35-4871b1074bc4@github.com> References: <7FMcOb-d6KfQt7eJeto4taZEc9iGV1p0HwGKyNA7rJY=.5681f965-a15d-4b2b-8d35-4871b1074bc4@github.com> Message-ID: <8WUHE2zGWxkbOmNfRBfb9V1Ml-mUKs4OXUG-P0W5FmU=.0468a475-73fe-411a-bc88-a57b5fbc8ecc@github.com> On Sat, 12 Mar 2022 16:27:51 GMT, Lance Andersen wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Refined the test > > test/jdk/java/text/Format/DecimalFormat/ToLocalizedPatternTest.java line 29: > >> 27: * @summary Verifies that toLocalizedPattern() method correctly returns >> 28: * monetary symbols in a currency formatter >> 29: * @run testng ToLocalizedPatternTest > > Maybe run in othervm mode? Thanks, Lance. I believe it is OK to run it in samejvm mode, as it does not leave any side effects. ------------- PR: https://git.openjdk.java.net/jdk/pull/7790 From duke at openjdk.java.net Sun Mar 13 00:10:46 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 13 Mar 2022 00:10:46 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 19:58:37 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Creating separate test for round double under feature check. src/hotspot/cpu/x86/assembler_x86.hpp line 1159: > 1157: void cvttsd2siq(Register dst, Address src); > 1158: void cvttsd2siq(Register dst, XMMRegister src); > 1159: void cvtsd2siq(Register dst, XMMRegister src); Hi, some small suggestions only, the instructions are sorted alphabetically so the `cvtsd2si` should come before `scttsd2si`, the same for the below instructions. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024: > 4022: * the result is equal to the value of Integer.MAX_VALUE. > 4023: */ > 4024: void C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst, XMMRegister src, XMMRegister xtmp1, This special handling is really large, could we use a stub routine for it? src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4161: > 4159: movl(scratch, 1056964608); > 4160: movq(xtmp1, scratch); > 4161: vbroadcastss(xtmp1, xtmp1, vec_enc); An `evpbroadcastd` would reduce this by one instruction I guess? src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178: > 4176: movl(scratch, 1056964608); > 4177: movq(xtmp1, scratch); > 4178: vbroadcastss(xtmp1, xtmp1, vec_enc); You could put the constant in the constant table and use `vbroadcastss` here also. Thank you very much. src/hotspot/cpu/x86/x86.ad line 7297: > 7295: ins_encode %{ > 7296: int vlen_enc = vector_length_encoding(this); > 7297: InternalAddress new_mxcsr = $constantaddress(0x3F80L); `ldmxcsr` takes a `m32` argument so this constant can be an `int` instead. Also, I would suggest putting the `mxcst_std` in the constant table also. src/hotspot/cpu/x86/x86_64.ad line 10699: > 10697: match(Set dst (ConvD2L src)); > 10698: effect(KILL cr); > 10699: format %{ "round_or_convert_d2l $dst,$src"%} You could revert the changes for `ConvD2L` and `ConvF2I` here ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sun Mar 13 00:10:46 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 13 Mar 2022 00:10:46 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 23:22:16 GMT, Quan Anh Mai wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Creating separate test for round double under feature check. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4161: > >> 4159: movl(scratch, 1056964608); >> 4160: movq(xtmp1, scratch); >> 4161: vbroadcastss(xtmp1, xtmp1, vec_enc); > > An `evpbroadcastd` would reduce this by one instruction I guess? Anyway an `evpbroadcastd xmm, r` has around 5 latency on the gpr so I think you could just put the constant in the constant table and use `vbroadcastsd` ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sun Mar 13 01:51:46 2022 From: duke at openjdk.java.net (xpbob) Date: Sun, 13 Mar 2022 01:51:46 GMT Subject: RFR: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java In-Reply-To: References: Message-ID: <5-Huoa6MswRGpp_p-BPg6kC1bXFajiD0dIxnubZXFNc=.3ae79008-a649-4687-a94f-f2a463551fc5@github.com> On Sat, 12 Mar 2022 14:58:48 GMT, Quan Anh Mai wrote: > The comment is correct, it is just that the backing array allocation is delayed until the first element is added to the list. Thanks. @merykitty Thanks to review. After new ArrayList, don't know whether to add an element. The array allocation may not be performed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7799 From duke at openjdk.java.net Sun Mar 13 02:09:47 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Sun, 13 Mar 2022 02:09:47 GMT Subject: RFR: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 09:48:14 GMT, xpbob wrote: > * Constructs an empty list with an initial capacity of ten > > => > > * Constructs an empty list with default sized empty instances. > > > private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; > > DEFAULTCAPACITY_EMPTY_ELEMENTDATA is empty and the length is 0 Yes that is the point, the backing array does not need to be allocated if there will be no element. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7799 From duke at openjdk.java.net Sun Mar 13 03:14:42 2022 From: duke at openjdk.java.net (liach) Date: Sun, 13 Mar 2022 03:14:42 GMT Subject: RFR: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java In-Reply-To: References: Message-ID: <4QuIeBCWBgYhyAxVUdUvv4rZWn_ysZcqXjIYKvJ3v2k=.58e3cdad-ba09-4151-ad29-6c22c8378951@github.com> On Sat, 12 Mar 2022 09:48:14 GMT, xpbob wrote: > * Constructs an empty list with an initial capacity of ten > > => > > * Constructs an empty list with default sized empty instances. > > > private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; > > DEFAULTCAPACITY_EMPTY_ELEMENTDATA is empty and the length is 0 This observation should probably be put in an implementation note, that the allocation of the backing array only happens when any element is added. Also, this API documentation change requires a CSR review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7799 From jbhateja at openjdk.java.net Sun Mar 13 04:33:46 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Mar 2022 04:33:46 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 23:20:58 GMT, Quan Anh Mai wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Creating separate test for round double under feature check. > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024: > >> 4022: * the result is equal to the value of Integer.MAX_VALUE. >> 4023: */ >> 4024: void C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst, XMMRegister src, XMMRegister xtmp1, > > This special handling is really large, could we use a stub routine for it? Good suggestion, but as of now we are not using vector calling conventions for stubs. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178: > >> 4176: movl(scratch, 1056964608); >> 4177: movq(xtmp1, scratch); >> 4178: vbroadcastss(xtmp1, xtmp1, vec_enc); > > You could put the constant in the constant table and use `vbroadcastss` here also. > > Thank you very much. constant and register to register moves are never issued to execution ports, rematerializing value rather than reading from memory will give better performance. > src/hotspot/cpu/x86/x86.ad line 7297: > >> 7295: ins_encode %{ >> 7296: int vlen_enc = vector_length_encoding(this); >> 7297: InternalAddress new_mxcsr = $constantaddress(0x3F80L); > > `ldmxcsr` takes a `m32` argument so this constant can be an `int` instead. Also, I would suggest putting the `mxcst_std` in the constant table also. Correct, if we do so constant emitted will occupy 4 bytes. FTR we can also improve on the alignment padding for constants such that start address of next emitted constant aligned based on the constant size. This will be beneficial for large sized vector constants (32/64 byte) as we can save cache line split penalty during vector load. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Mar 13 04:33:47 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Mar 2022 04:33:47 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 00:06:07 GMT, Quan Anh Mai wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4161: >> >>> 4159: movl(scratch, 1056964608); >>> 4160: movq(xtmp1, scratch); >>> 4161: vbroadcastss(xtmp1, xtmp1, vec_enc); >> >> An `evpbroadcastd` would reduce this by one instruction I guess? > > Anyway an `evpbroadcastd xmm, r` has around 5 latency on the gpr so I think you could just put the constant in the constant table and use `vbroadcastsd` It was done to save redundant floating point to integer domain switch over penalties. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Mar 13 04:46:21 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Mar 2022 04:46:21 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v16] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Styling comments resolved. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/e4d4e29b..c881d11c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=14-15 Stats: 11 lines in 3 files changed: 3 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Sun Mar 13 06:36:15 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Sun, 13 Mar 2022 06:36:15 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v17] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: 8279508: Windows build failure fix. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7094/files - new: https://git.openjdk.java.net/jdk/pull/7094/files/c881d11c..b1323a82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=15-16 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Sun Mar 13 09:07:50 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 13 Mar 2022 09:07:50 GMT Subject: RFR: 8279283 - BufferedInputStream should override transferTo [v5] In-Reply-To: References: Message-ID: <1TIUS0_pSRce-SLR4i3Yd7M1MYPaArTRhmIJKkrl_iA=.0c9f2f87-8a76-4792-9ccb-d72cf90b29e6@github.com> On Mon, 27 Dec 2021 13:43:12 GMT, Markus KARG wrote: >> Implementation of JDK-8279283 > > Markus KARG has updated the pull request incrementally with one additional commit since the last revision: > > fixed missing BufferedInputStream Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/6935 From duke at openjdk.java.net Sun Mar 13 09:47:50 2022 From: duke at openjdk.java.net (Markus KARG) Date: Sun, 13 Mar 2022 09:47:50 GMT Subject: RFR: 8265891: (ch) InputStream returned by Channels.newInputStream should override transferTo [v13] In-Reply-To: References: Message-ID: <1UqhJ5m2labh0jwHTw6SRuda6mF_ku_ZC50cm5k_mIU=.2de4a743-caed-4d9b-b2f7-f79d0eba1e7f@github.com> On Sun, 1 Aug 2021 22:01:33 GMT, Markus KARG wrote: >> This PR-*draft* is **work in progress** and an invitation to discuss a possible solution for issue [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not yet* intended for a final review. >> >> As proposed in JDK-8265891, this PR provides an implementation for `Channels.newInputStream().transferTo()` which provide superior performance compared to the current implementation. The changes are: >> * Prevents transfers through the JVM heap as much as possibly by offloading to deeper levels via NIO, hence allowing the operating system to optimize the transfer. >> * Using more JRE heap in the fallback case when no NIO is possible (still only KiBs, hence mostl ynegligible even on SBCs) to better perform on modern hardware / fast I/O devides. >> >> Using JMH I have benchmarked both, the original implementation and this implementation, and (depending on the used hardware and use case) performance change was approx. doubled performance. So this PoC proofs that it makes sense to finalize this work and turn it into an actual OpenJDK contribution. >> >> I encourage everybody to discuss this draft: >> * Are there valid arguments for *not* doing this change? >> * Is there a *better* way to improve performance of `Channels.newInputStream().transferTo()`? >> * How to go on from here: What is missing to get this ready for an actual review? > > Markus KARG has updated the pull request incrementally with two additional commits since the last revision: > > - Draft: Eliminated duplicate code using lambda expressions > - Draft: Use blocking mode also for target channel Please keep this PR open; I will continune work on it soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/4263 From duke at openjdk.java.net Sun Mar 13 10:08:41 2022 From: duke at openjdk.java.net (Glavo) Date: Sun, 13 Mar 2022 10:08:41 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v5] In-Reply-To: <_QH-26ffS3FPYry9tmQGwunHc3FY62kzCW17mWPZSDY=.01248c75-fd67-4e65-974d-e3f9ffda1dd7@github.com> References: <_QH-26ffS3FPYry9tmQGwunHc3FY62kzCW17mWPZSDY=.01248c75-fd67-4e65-974d-e3f9ffda1dd7@github.com> Message-ID: On Fri, 11 Mar 2022 16:53:12 GMT, Jim Laskey wrote: > That might be more in the realm of Valhalla. This is more for capturing arguments from vararg bootstrap methods. But, I can see your use case. Speaking of Valhalla, this also seems likely to be the basis for specialized generics??All in all, thanks for your great work. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From rreddy at openjdk.java.net Sun Mar 13 14:16:01 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Sun, 13 Mar 2022 14:16:01 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() Message-ID: Hi All, This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java Thanks, Ravi ------------- Commit messages: - 8278794: Infinite loop in DeflaterOutputStream.finish() Changes: https://git.openjdk.java.net/jdk/pull/7804/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7804&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278794 Stats: 366 lines in 5 files changed: 212 ins; 147 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7804/head:pull/7804 PR: https://git.openjdk.java.net/jdk/pull/7804 From jpai at openjdk.java.net Mon Mar 14 03:21:47 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 14 Mar 2022 03:21:47 GMT Subject: RFR: 8282572: EnumSet should be a sealed class In-Reply-To: References: Message-ID: <0Xq8RH5sLiQHlzXvrXj5PvLCjbMGWPyE4vUnTW4jEAs=.06d1c8c1-e7d2-404c-8dd9-38975e048bff@github.com> On Fri, 11 Mar 2022 09:04:23 GMT, Athijegannathan Sundararajan wrote: >> Can I please get a review of this change which proposes to implement the enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? >> >> The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any sub-classes of their own. >> >> In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` and `RegularEnumSet` are the two permitted sub classes. Both of these sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for these 2 sub-classes was an option too. But I decided to start with the more restrictive option since we don't have any other sub-classes and if and when we do have their sub-classes, it's possible to change them to `non-sealed`. >> >> The `EnumSet` class implements the `java.io.Serializable` interface. As part of this change, manual tests have been run to make sure that changing this class to `sealed` and marking the sub-classes as `final` don't break any serialization/deserialization semantics, across Java version and/or user application versions. >> >> `tier1` testing across various platforms is currently in progress. > > LGTM Thank you @sundararajana for the review and thanks everyone for the help on the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7741 From jpai at openjdk.java.net Mon Mar 14 03:21:48 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 14 Mar 2022 03:21:48 GMT Subject: Integrated: 8282572: EnumSet should be a sealed class In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 10:50:35 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to implement the enhancement requested in https://bugs.openjdk.java.net/browse/JDK-8282572? > > The (public) `EnumSet` class has 2 package private (JDK) internal sub-classes - the `JumboEnumSet` and `RegularEnumSet`. These 2 classes don't have any sub-classes of their own. > > In this commit, the `EnumSet` is marked as `sealed` and the `JumboEnumSet` and `RegularEnumSet` are the two permitted sub classes. Both of these sub-classes are now marked as `final` too. Usage of `non-sealed` modifier for these 2 sub-classes was an option too. But I decided to start with the more restrictive option since we don't have any other sub-classes and if and when we do have their sub-classes, it's possible to change them to `non-sealed`. > > The `EnumSet` class implements the `java.io.Serializable` interface. As part of this change, manual tests have been run to make sure that changing this class to `sealed` and marking the sub-classes as `final` don't break any serialization/deserialization semantics, across Java version and/or user application versions. > > `tier1` testing across various platforms is currently in progress. This pull request has now been integrated. Changeset: 3cf83a67 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/3cf83a671eaedd78d87197dffa76dcc3fededb78 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod 8282572: EnumSet should be a sealed class Reviewed-by: sundar ------------- PR: https://git.openjdk.java.net/jdk/pull/7741 From poweruserm at live.com.au Mon Mar 14 06:49:04 2022 From: poweruserm at live.com.au (A Z) Date: Mon, 14 Mar 2022 06:49:04 +0000 Subject: Questions about enhancement and Correction to Java OpenJDK Floating Point? Message-ID: To whom it may concern, Having noticed https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 https://bugs.openjdk.java.net/browse/JDK-8190991 and similar, at https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point I have been referred on to the core-libs-dev area. The software development company I represent wishes to keep its name confidential, and no-mentioned, at this time. A number of us at our end have found that floating point and StrictMath arithmetic on both float and double does not result in range accuracy, but produces denormal and pronormal values. We are aware of the Java Language Specification, and IEEE 754 specifications, to these issues, but are still finding that they are not the most relevant or great issue. While we are aware of the BigDecimal and BigInteger workarounds, and furthermore, the calculator class including big-math https://github.com/eobermuhlner, we are finding in the development, debugging, and editing of our Java programs, that using other classes to operate and exchange for the lack of range accuracy from float, double and java.lang.StrictMath, that we are getting bogged down with what turns into more inferior software. The known and available workaround approaches are becoming stop-gap measures, perforcedly put in place, while introducing other problems into OpenJDK or Java software that don't have any particular, immediate, solutions. Substituting float and double data in and out of BigDecimal and BigInteger produces source code which is much messier, complicated, error prone, difficult to understand and to change, is definitely slower, and is an inferior substitute when float and double are more than enough in the overwhelming majority of corresponding cases. This is particularly showing up in 2D and 3D Graphics software, by the default OpenJDK Libraries, but also through JMonkeyEngine 3.5. Possessing the option to immediately deal with the precondition, postcondition and field types of float and double is far superior and more than ideal. All this is before the massive advantage of being able to use operators, but the change case becomes overwhelming when along a range accurate, double (or maybe float, also) supporting Scientific Calculator class. If I want to discuss (at least OpenJDK) change in this area, I have been pointed to the core-libs area, by one of the respondents of the article: https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point. Is there anyone here, at core-libs-dev, who can point me in a better Oracle or OpenJDK direction, to discuss further and see about Java float and double and StrictMath floating point arithmetic denormal and pronormal values being repaired away and being made range accurate for all evaluation operations with them? Certainly since other languages already have, that are open source and open resource file ones. It is a mathematical fact that, for consistent, necessary and even fast term, 10% of 10% must always precisely be 1%, and by no means anything else. Consider these three different language API evaluations, using their equivalents of float and double to perform the floating point equivalent of that precise evaluation: //---------------------------------------------------------- //The C Language. #include int main() { printf("Program has started..."); printf("\n"); printf("\n"); double a = 0.1D; double b = 0.1D; double c = a*b; printf("%lf",c); printf("\n"); printf("\n"); float d = 0.1F; float e = 0.1F; float f = d*e; printf("%lf",f); printf("\n"); printf("\n"); printf("Program has Finished."); return 0; } /* Program has started... 0.010000 0.010000 Program has Finished. */ //---------------------------------------------------------- //The C++ Language. #include using namespace std; int main() { cout << "Program has started..." << endl; double a = 0.1D; double b = 0.1D; double c = a*b; cout << endl << c << endl << endl; float d = 0.1F; float e = 0.1F; float f = d*e; cout << f << endl << endl; cout << "Program has Finished."; return 0; } /* Program has started... 0.01 0.01 Program has Finished. */ //---------------------------------------------------------- //The Java Language. import static java.lang.System.*; public class Start { public static void main(String ... args) { out.println("Program has started..."); double a = 0.1D; double b = 0.1D; double c = a*b; out.println(); out.println(c); float d = 0.1F; float e = 0.1F; float f = d*e; out.println(); out.println(f); out.println(); out.println("Program has Finished."); }} /* Program has started... 0.010000000000000002 0.010000001 Program has Finished.. */ //---------------------------------------------------------- In order for java to introduce either default alteration, or a compatibility mode alteration, where, how and who should I begin to speak with? Yours Sincerely, Terry Neale From forax at univ-mlv.fr Mon Mar 14 07:01:00 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 14 Mar 2022 08:01:00 +0100 (CET) Subject: Questions about enhancement and Correction to Java OpenJDK Floating Point? In-Reply-To: References: Message-ID: <545123003.15958095.1647241260319.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "A Z" > To: "core-libs-dev" > Sent: Monday, March 14, 2022 7:49:04 AM > Subject: Questions about enhancement and Correction to Java OpenJDK Floating Point? Hi Terry, if you want to have the same output as C, instead of println() use printf(). In your example, using out.printf("%f\n", c); prints 0.010000 0.010000 regards, R?mi > To whom it may concern, > > Having noticed > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 > https://bugs.openjdk.java.net/browse/JDK-8190991 > > and similar, at > https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point > > I have been referred on to the core-libs-dev area. > > The software development company I represent wishes to keep its name > confidential, > and no-mentioned, at this time. > > A number of us at our end have found that floating point and StrictMath > arithmetic > on both float and double does not result in range accuracy, but produces > denormal > and pronormal values. > > We are aware of the Java Language Specification, and IEEE 754 specifications, > to these issues, but are still finding that they are not the most relevant or > great issue. > > While we are aware of the BigDecimal and BigInteger workarounds, and > furthermore, the calculator class including big-math > https://github.com/eobermuhlner, > we are finding in the development, debugging, and editing of our Java programs, > that using other classes to operate and exchange for the lack of range accuracy > from float, > double and java.lang.StrictMath, that we are getting bogged down with what turns > into > more inferior software. The known and available workaround approaches are > becoming > stop-gap measures, perforcedly put in place, while introducing other problems > into OpenJDK or Java software that don't have any particular, immediate, > solutions. > > Substituting float and double data in and out of BigDecimal and BigInteger > produces > source code which is much messier, complicated, error prone, difficult to > understand > and to change, is definitely slower, and is an inferior substitute when float > and double are more than enough in the overwhelming majority of corresponding > cases. > This is particularly showing up in 2D and 3D Graphics software, by the default > OpenJDK Libraries, but also through JMonkeyEngine 3.5. > > Possessing the option to immediately deal with the precondition, postcondition > and field types of float and double is far superior and more than ideal. > All this is before the massive advantage of being able to use operators, > but the change case becomes overwhelming when along a range accurate, > double (or maybe float, also) supporting Scientific Calculator class. > > If I want to discuss (at least OpenJDK) change in this area, I have > been pointed to the core-libs area, by one of the respondents > of the article: > > https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point. > > Is there anyone here, at core-libs-dev, who can point > me in a better Oracle or OpenJDK direction, to discuss further > and see about Java float and double and StrictMath floating point > arithmetic denormal and pronormal values being repaired away > and being made range accurate for all evaluation operations > with them? > > Certainly since other languages already have, that are open source > and open resource file ones. It is a mathematical fact that, for > consistent, necessary and even fast term, 10% of 10% must > always precisely be 1%, and by no means anything else. > > Consider these three different language API evaluations, > using their equivalents of float and double to perform > the floating point equivalent of that precise evaluation: > > //---------------------------------------------------------- > //The C Language. > #include > > int main() > { > printf("Program has started..."); > printf("\n"); > printf("\n"); > double a = 0.1D; > double b = 0.1D; > double c = a*b; > printf("%lf",c); > printf("\n"); > printf("\n"); > float d = 0.1F; > float e = 0.1F; > float f = d*e; > printf("%lf",f); > printf("\n"); > printf("\n"); > printf("Program has Finished."); > return 0; > } > > /* > Program has started... > > 0.010000 > > 0.010000 > > Program has Finished. > */ > //---------------------------------------------------------- > //The C++ Language. > > #include > > using namespace std; > > int main() > { > cout << "Program has started..." << endl; > double a = 0.1D; > double b = 0.1D; > double c = a*b; > cout << endl << c << endl << endl; > float d = 0.1F; > float e = 0.1F; > float f = d*e; > cout << f << endl << endl; > cout << "Program has Finished."; > return 0; > } > > /* > Program has started... > > 0.01 > > 0.01 > > Program has Finished. > */ > > //---------------------------------------------------------- > //The Java Language. > > import static java.lang.System.*; > public class Start > { > public static void main(String ... args) > { > out.println("Program has started..."); > double a = 0.1D; > double b = 0.1D; > double c = a*b; > out.println(); > out.println(c); > float d = 0.1F; > float e = 0.1F; > float f = d*e; > out.println(); > out.println(f); out.println(); > out.println("Program has Finished."); > }} > > /* > Program has started... > > 0.010000000000000002 > > 0.010000001 > > Program has Finished.. > */ > //---------------------------------------------------------- > > In order for java to introduce either default alteration, > or a compatibility mode alteration, where, > how and who should I begin to speak with? > > Yours Sincerely, > > Terry Neale From martin.desruisseaux at geomatys.com Mon Mar 14 09:23:19 2022 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Mon, 14 Mar 2022 10:23:19 +0100 Subject: Questions about enhancement and Correction to Java OpenJDK Floating Point? In-Reply-To: References: Message-ID: Hello A.Z As far as I know, the difference in output that you observed between Java and C/C++ is not caused by a difference in floating-point computation, but in a difference in the way numbers are rounded by the "printf" command. Java has a policy of showing all significant digits, while C "printf" has a policy of rounding before printing. In my opinion, this is more dangerous because it hides what really happen in floating-point computation. The following statement is not entirely true when using finite floating point precision: > (?snip?) It is a mathematical fact that, for > consistent, necessary and even fast term, 10% of 10% must > always precisely be 1%, and by no means anything else. Above statement can be true only when using base 10 or some other bases. We could also said "It is a mathematical fact that 1/3 of 1/3 must always precisely be 1/9 and nothing else", but it can not be represented fully accurately with base 10. It can be represented fully accurately with base 3 however. There will always be examples that work in one base and not in another, and natural laws has no preference for base 10. I understand that base 10 is special for financial applications, but for many other applications (scientific, engineering, rendering?) base 2 is as good as any other base. I would even argue that base 10 can be dangerous because it gives a false sense of accuracy: it gives the illusion that rounding errors do not happen when testing with a few sample values in base 10 (like 10% of 10%), while in reality rounding errors continue to exist in the general case. ??? Martin From aph at openjdk.java.net Mon Mar 14 09:32:50 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Mon, 14 Mar 2022 09:32:50 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 04:27:25 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4024: >> >>> 4022: * the result is equal to the value of Integer.MAX_VALUE. >>> 4023: */ >>> 4024: void C2_MacroAssembler::vector_cast_float_special_cases_avx(XMMRegister dst, XMMRegister src, XMMRegister xtmp1, >> >> This special handling is really large, could we use a stub routine for it? > > Good suggestion, but as of now we are not using vector calling conventions for stubs. I don't understand this comment. If the stub is only to be used by you, then you can determine your own calling convention. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From raffaello.giulietti at gmail.com Mon Mar 14 10:28:45 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 14 Mar 2022 11:28:45 +0100 Subject: Questions about enhancement and Correction to Java OpenJDK Floating Point? In-Reply-To: References: Message-ID: Hi Terry, as pointed out by Martin, the real issue is using *binary* floating-point arithmetic, like float or double, to emulate *decimal* arithmetic. When you write 0.1D in Java, C or C++, what happens is that this decimal number is rounded to the double closest to the mathematical value 1/10. There's no double that is exactly 1/10, so you start with a value that is already rounded and inexact. Multiplication rounds as well, so you end up with a value that was subject to 3 roundings: twice for the conversion of the two openads from 0.1D to the closest doubles and once for the multiplication. The result is slightly different than the naively "expected" 0.01D, which is subject to one rounding only during conversion to the closest double. In other words, 0.1D*0.1D != 0.01D, even in C/C++ and most programming languages/environments. In Java, however, when you convert a double to a decimal string by means of System.out.print[ln](), the library outputs just as many digits as necessary, and no less, for an input routine to be able to recover the original double. C and C++ do *not* ensure this. In Java, 0.01D (1 rounding) is correctly converted to "0.01" while 0.1D*0.1D (3 roundings) is correctly converted to "0.010000000000000002". In C/C++, try to output both 0.1D*0.1D and 0.01D with 20 digits, say, instead of the default 6 and you'll see a difference. As observed by R?mi, Java offers formatting similar to C/C++ if that is what you want. To summarize, Java uses IEEE 754 binary arithmetic as by specification, as do most other languages, including C/C++. It is however fundamentally wrong to use binary floating-point arithmetic to emulate decimal behavior. Also, pay attention to the output routines that convert float and double values to a decimal representation. Usually, C and C++ will have information loss by default, as in your case. HTH Raffaello On 3/14/22 07:49, A Z wrote: > To whom it may concern, > > Having noticed > > https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 > https://bugs.openjdk.java.net/browse/JDK-8190991 > > and similar, at https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point > > I have been referred on to the core-libs-dev area. > > The software development company I represent wishes to keep its name confidential, > and no-mentioned, at this time. > > A number of us at our end have found that floating point and StrictMath arithmetic > on both float and double does not result in range accuracy, but produces denormal > and pronormal values. > > We are aware of the Java Language Specification, and IEEE 754 specifications, > to these issues, but are still finding that they are not the most relevant or great issue. > > While we are aware of the BigDecimal and BigInteger workarounds, and > furthermore, the calculator class including big-math https://github.com/eobermuhlner, > we are finding in the development, debugging, and editing of our Java programs, > that using other classes to operate and exchange for the lack of range accuracy from float, > double and java.lang.StrictMath, that we are getting bogged down with what turns into > more inferior software. The known and available workaround approaches are becoming > stop-gap measures, perforcedly put in place, while introducing other problems > into OpenJDK or Java software that don't have any particular, immediate, solutions. > > Substituting float and double data in and out of BigDecimal and BigInteger produces > source code which is much messier, complicated, error prone, difficult to understand > and to change, is definitely slower, and is an inferior substitute when float > and double are more than enough in the overwhelming majority of corresponding cases. > This is particularly showing up in 2D and 3D Graphics software, by the default > OpenJDK Libraries, but also through JMonkeyEngine 3.5. > > Possessing the option to immediately deal with the precondition, postcondition > and field types of float and double is far superior and more than ideal. > All this is before the massive advantage of being able to use operators, > but the change case becomes overwhelming when along a range accurate, > double (or maybe float, also) supporting Scientific Calculator class. > > If I want to discuss (at least OpenJDK) change in this area, I have > been pointed to the core-libs area, by one of the respondents > of the article: > > https://community.oracle.com/tech/developers/discussion/4126262/big-issue-with-float-double-java-floating-point. > > Is there anyone here, at core-libs-dev, who can point > me in a better Oracle or OpenJDK direction, to discuss further > and see about Java float and double and StrictMath floating point > arithmetic denormal and pronormal values being repaired away > and being made range accurate for all evaluation operations > with them? > > Certainly since other languages already have, that are open source > and open resource file ones. It is a mathematical fact that, for > consistent, necessary and even fast term, 10% of 10% must > always precisely be 1%, and by no means anything else. > > Consider these three different language API evaluations, > using their equivalents of float and double to perform > the floating point equivalent of that precise evaluation: > > //---------------------------------------------------------- > //The C Language. > #include > > int main() > { > printf("Program has started..."); > printf("\n"); > printf("\n"); > double a = 0.1D; > double b = 0.1D; > double c = a*b; > printf("%lf",c); > printf("\n"); > printf("\n"); > float d = 0.1F; > float e = 0.1F; > float f = d*e; > printf("%lf",f); > printf("\n"); > printf("\n"); > printf("Program has Finished."); > return 0; > } > > /* > Program has started... > > 0.010000 > > 0.010000 > > Program has Finished. > */ > //---------------------------------------------------------- > //The C++ Language. > > #include > > using namespace std; > > int main() > { > cout << "Program has started..." << endl; > double a = 0.1D; > double b = 0.1D; > double c = a*b; > cout << endl << c << endl << endl; > float d = 0.1F; > float e = 0.1F; > float f = d*e; > cout << f << endl << endl; > cout << "Program has Finished."; > return 0; > } > > /* > Program has started... > > 0.01 > > 0.01 > > Program has Finished. > */ > > //---------------------------------------------------------- > //The Java Language. > > import static java.lang.System.*; > public class Start > { > public static void main(String ... args) > { > out.println("Program has started..."); > double a = 0.1D; > double b = 0.1D; > double c = a*b; > out.println(); > out.println(c); > float d = 0.1F; > float e = 0.1F; > float f = d*e; > out.println(); > out.println(f); out.println(); > out.println("Program has Finished."); > }} > > /* > Program has started... > > 0.010000000000000002 > > 0.010000001 > > Program has Finished.. > */ > //---------------------------------------------------------- > > In order for java to introduce either default alteration, > or a compatibility mode alteration, where, > how and who should I begin to speak with? > > Yours Sincerely, > > Terry Neale From thartmann at openjdk.java.net Mon Mar 14 10:38:57 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 14 Mar 2022 10:38:57 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v17] In-Reply-To: References: Message-ID: <1J7RFTiEF7VfaEg4EF29Hwd9UUU0D1MM1xh6waG3ulY=.251d7fd9-0d1d-4288-9a55-6feca4b0ec6a@github.com> On Sun, 13 Mar 2022 06:36:15 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Windows build failure fix. `compiler/c2/cr6340864/TestFloatVect.java` and `TestDoubleVect.java` fail on Windows: # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000001971b940123, pid=56524, tid=57368 # # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # J 205 c2 compiler.c2.cr6340864.TestFloatVect.test_round([I[F)V (24 bytes) @ 0x000001971b940123 [0x000001971b93ffe0+0x0000000000000143] ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Mon Mar 14 12:11:49 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 14 Mar 2022 12:11:49 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: <8IP7JMUqOWwCVaV3-hf42ovowPNRAEDQRrkzLf-z2yg=.5f4f5350-711b-411d-bcb5-45911fd901d7@github.com> On Mon, 14 Mar 2022 09:29:28 GMT, Andrew Haley wrote: >> Good suggestion, but as of now we are not using vector calling conventions for stubs. > > I don't understand this comment. If the stub is only to be used by you, then you can determine your own calling convention. We are passing mixture of scalar, vector and opmask register to special handling function, only way we can pass them reliably to callee stub without having an elaborate mixed calling convention will be by bounding the machine operands. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Mon Mar 14 13:44:54 2022 From: duke at openjdk.java.net (Raffaello Giulietti) Date: Mon, 14 Mar 2022 13:44:54 GMT Subject: RFR: 4511638: Double.toString(double) sometimes produces incorrect results [v6] In-Reply-To: References: <4u2JXrpWNWRjJeJbtQmwyYrYcAun1jUNA3A2Q9SK4W8=.583a8daa-9cf4-476d-897c-f03820154de6@github.com> Message-ID: On Tue, 8 Feb 2022 22:11:34 GMT, Raffaello Giulietti wrote: >> Hello, >> >> here's a PR for a patch submitted on March 2020 [1](https://cr.openjdk.java.net/~bpb/4511638/webrev.04/) when Mercurial was a thing. >> >> The patch has been edited to adhere to OpenJDK code conventions about multi-line (block) comments. Nothing in the code proper has changed, except for the addition of redundant but clarifying parentheses in some expressions. >> >> >> Greetings >> Raffaello > > Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adapted hashes in ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Enhanced intervals in MathUtils. > Updated references to Schubfach v4. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > > Slight adjustments to Javadoc as suggested in the JDK-8202555 (CSR) comments. > - 4511638: Double.toString(double) sometimes produces incorrect results > > Adjusted hashes in test/langtools/tools/javac/sym/ElementStructureTest.java > - 4511638: Double.toString(double) sometimes produces incorrect results > > Merge branch 'master' into JDK-4511638 > - 4511638: Double.toString(double) sometimes produces incorrect results > - 4511638: Double.toString(double) sometimes produces incorrect results > > Refactored test classes to better match OpenJDK conventions. > Added tests recommended by Guy Steele and Paul Zimmermann. > - Changed MAX_CHARS to static > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/92f4f40d...c29dff76 Hi Suminda, before merging, an OpenJDK PR needs to be properly reviewed by officially nominated reviewers other than the author of a PR. In addition, this PR also needs a CSR approval because the proposed spec has changed. As you can see on the top of the PR, neither of these two prerequisites for merging are checked as of today. Greetings Raffaello On 3/10/22 07:37, Suminda Sirinath Salpitikorala Dharmasena wrote: > > Why is this still not merged? > > ? > Reply to this email directly, view it on GitHub > , or > unsubscribe > . > Triage notifications on the go with GitHub Mobile for iOS > > or Android > . > > You are receiving this because you were mentioned.Message ID: > ***@***.***> > ------------- PR: https://git.openjdk.java.net/jdk/pull/3402 From bpb at openjdk.java.net Mon Mar 14 16:14:04 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 14 Mar 2022 16:14:04 GMT Subject: Integrated: 8058924: FileReader(String) documentation is insufficient In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 02:30:35 GMT, Brian Burkhalter wrote: > Add a statement to the `java.io` package documentation clarifying how a `String` representing a _pathname string_ is interpreted in the package. This pull request has now been integrated. Changeset: 13cebffe Author: Brian Burkhalter URL: https://git.openjdk.java.net/jdk/commit/13cebffe618255ae29310c95fd1b91576e576751 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod 8058924: FileReader(String) documentation is insufficient Reviewed-by: naoto, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7767 From smarks at openjdk.java.net Mon Mar 14 16:18:50 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Mon, 14 Mar 2022 16:18:50 GMT Subject: RFR: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 09:48:14 GMT, xpbob wrote: > * Constructs an empty list with an initial capacity of ten > > => > > * Constructs an empty list with default sized empty instances. > > > private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; > > DEFAULTCAPACITY_EMPTY_ELEMENTDATA is empty and the length is 0 Closed as duplicate of [JDK-8143020](https://bugs.openjdk.java.net/browse/JDK-8143020). ------------- PR: https://git.openjdk.java.net/jdk/pull/7799 From psoujany at in.ibm.com Mon Mar 14 11:48:42 2022 From: psoujany at in.ibm.com (Pasam Soujanya1) Date: Mon, 14 Mar 2022 11:48:42 +0000 Subject: Behavior change in the jar tool JDK11 vs JDK8. Message-ID: There is a significant difference in the way the JAR tool (starting JDK11) seems to be responding to target files that are not present , when compared to JDK8. With JDK 8, the jar tool just reports about target files that are absent, and creates the jar file with whatever targets are available. With JDK8, If I try to create a jar file with one existing file and another invalid file name I can see achieve getting created with the file that exists. Only the warning seems to be printed for the target that doesn't exists: $ jar -cvf sample.jar exists.txt does_not_exist.txt does_not_exist.txt : no such file or directory added manifest adding: exists.txt(in = 0) (out= 0)(stored 0%) >From JDK11 onward upto the latest, though I can see the same verbose output the jar file(sample.jar) is not created. Looking at the code, the targets that do exist are written to a temporary JAR file, but the following "validation" code, which runs once the tool has finished writing the temporary JAR file, only moves/renames the temporary file to the specified JAR location if "ok" is true. If "ok" is false the temporary file is simply deleted: https://github.com/openjdk/jdk11u/blob/22186cb1fe22b4b30fc72c67ce9946cd4f03199d/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L451 Is this behavior change intentional? I couldn't find anything documented in release notes of JDK 9,10,11. If not intentional, can someone help me create bug report on OpenJDK jira? Thank you. Regards, Pasam Soujanya. From naoto at openjdk.java.net Mon Mar 14 16:31:53 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Mar 2022 16:31:53 GMT Subject: Integrated: 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 19:53:20 GMT, Naoto Sato wrote: > `DecimalFormat.toLocalizedPattern()` was not honoring the monetary decimal/grouping separator symbols. Fix is straightforward to use the correct symbols depending on the formatter type. This pull request has now been integrated. Changeset: c96085ea Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c96085eaab1f6b21e084b94fcc619d090f0afc97 Stats: 68 lines in 2 files changed: 63 ins; 0 del; 5 mod 8282929: Localized monetary symbols are not reflected in `toLocalizedPattern` return value Reviewed-by: joehw, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7790 From naoto at openjdk.java.net Mon Mar 14 16:32:38 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Mar 2022 16:32:38 GMT Subject: RFR: 8282407: Missing ')' in MacResources.properties In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 03:12:30 GMT, Alexander Matveev wrote: > - Fixed by adding missing ']'. > - I changed '()' to '[]', since other error messages use '[]' and not '()'. It is OK as it stands, but usually localized files are provided by the l10n process, so engineers only need to modify the base resource bundle. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7797 From achung at openjdk.java.net Mon Mar 14 16:41:48 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 14 Mar 2022 16:41:48 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com> References: <8cpPZ7PatfiigWBze5jL-LUXa6urMiCgdhpm1otQHhA=.1862cf26-296b-438e-acfe-2a83b64dc539@github.com> Message-ID: On Thu, 10 Mar 2022 18:56:41 GMT, Chris Plummer wrote: >> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> moved CurrencyNames changes to jdk.localedata > > src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java line 305: > >> 303: {"Thread not suspended", "\u30B9\u30EC\u30C3\u30C9\u306F\u4E2D\u65AD\u3057\u3066\u3044\u307E\u305B\u3093"}, >> 304: {"thread group number description name", "{0,number,integer}. {1} {2}"}, >> 305: {"Threadgroup name not specified.", "\u30B9\u30EC\u30C3\u30C9\u30B0\u30EB\u30FC\u30D7\u540D\u304C\u6307\u5B9A\u3055\u308C\u3066\u3044\u307E\u305B\u3093\u3002"}, > > I'm not sure what happened here. This resource was just removed yesterday as part of #7687. It had been around for a long time before that (probably from the beginning of this file), so I'm not sure what triggered getting it re-added. The translation was started before the updates to this file. This update can be done in the next msg drop. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From forax at univ-mlv.fr Mon Mar 14 16:45:32 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 14 Mar 2022 17:45:32 +0100 (CET) Subject: Behavior change in the jar tool JDK11 vs JDK8. In-Reply-To: References: Message-ID: <1756908502.16490329.1647276332120.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Pasam Soujanya1" > To: "core-libs-dev" > Sent: Monday, March 14, 2022 12:48:42 PM > Subject: Behavior change in the jar tool JDK11 vs JDK8. > There is a significant difference in the way the JAR tool (starting JDK11) seems > to be responding to target files that are not present , when compared to JDK8. > With JDK 8, the jar tool just reports about target files that are absent, and > creates the jar file with whatever targets are available. > > With JDK8, If I try to create a jar file with one existing file and another > invalid file name I can see achieve getting created with the file that exists. > Only the warning seems to be printed for the target that doesn't exists: > > $ jar -cvf sample.jar exists.txt does_not_exist.txt > does_not_exist.txt : no such file or directory > added manifest > adding: exists.txt(in = 0) (out= 0)(stored 0%) > > From JDK11 onward upto the latest, though I can see the same verbose output the > jar file(sample.jar) is not created. > > Looking at the code, the targets that do exist are written to a temporary JAR > file, but the following "validation" code, which runs once the tool has > finished writing the temporary JAR file, only moves/renames the temporary file > to the specified JAR location if "ok" is true. If "ok" is false the temporary > file is simply deleted: > https://github.com/openjdk/jdk11u/blob/22186cb1fe22b4b30fc72c67ce9946cd4f03199d/src/jdk.jartool/share/classes/sun/tools/jar/Main.java#L451 > > Is this behavior change intentional? I couldn't find anything documented in > release notes of JDK 9,10,11. If not intentional, can someone help me create > bug report on OpenJDK jira? Thank you. I believe it's a bugfix, since the creation of the command "jar", jar follows the semantics of "tar", so the behavior you are seeing now is the correct one. But i was not able to pinpoint the bug corresponding to that issue. > > Regards, > Pasam Soujanya. regards, R?mi From Alan.Bateman at oracle.com Mon Mar 14 17:21:41 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Mar 2022 17:21:41 +0000 Subject: Behavior change in the jar tool JDK11 vs JDK8. In-Reply-To: References: Message-ID: <42aca6b2-8282-469a-b897-00f4adde6a18@oracle.com> On 14/03/2022 11:48, Pasam Soujanya1 wrote: > There is a significant difference in the way the JAR tool (starting JDK11) seems to be responding to target files that are not present , when compared to JDK8. With JDK 8, the jar tool just reports about target files that are absent, and creates the jar file with whatever targets are available. > > With JDK8, If I try to create a jar file with one existing file and another invalid file name I can see achieve getting created with the file that exists. Only the warning seems to be printed for the target that doesn't exists: Can you check the exit code (echo $?)? There was a bug in JDK 8/older releases with it leaving the temporary file behind when exiting with an error, I suspect this is what you are seeing. This changed in JDK 9 to cleanup when exiting with an error. -Alan. From dfuchs at openjdk.java.net Mon Mar 14 17:21:51 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Mon, 14 Mar 2022 17:21:51 GMT Subject: RFR: 8283049: Fix non-singleton LoggerFinder error message: s/on/one [v2] In-Reply-To: References: Message-ID: <93Ri1dhbfxGuYGpnEUQHFL8vYkcqRVQkTvVaQScPjYg=.bb0ff692-aaf7-4cbd-a9f4-9ed65c01caab@github.com> On Fri, 11 Mar 2022 19:18:55 GMT, Carter Kozak wrote: >> 8283049: Fix non-singleton LoggerFinder error message: s/on/one > > Carter Kozak has updated the pull request incrementally with one additional commit since the last revision: > > Add 8283049 to LoggerFinderLoaderTest @bug docs Marked as reviewed by dfuchs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7780 From kizune at openjdk.java.net Mon Mar 14 17:41:55 2022 From: kizune at openjdk.java.net (Alexander Zuev) Date: Mon, 14 Mar 2022 17:41:55 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 17:55:44 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > moved CurrencyNames changes to jdk.localedata Marked as reviewed by kizune (Reviewer). Clientlibs related stuff looks correct. ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From duke at openjdk.java.net Mon Mar 14 17:57:45 2022 From: duke at openjdk.java.net (Carter Kozak) Date: Mon, 14 Mar 2022 17:57:45 GMT Subject: Integrated: 8283049: Fix non-singleton LoggerFinder error message: s/on/one In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 22:28:14 GMT, Carter Kozak wrote: > 8283049: Fix non-singleton LoggerFinder error message: s/on/one This pull request has now been integrated. Changeset: 70bd57ed Author: Carter Kozak Committer: Daniel Fuchs URL: https://git.openjdk.java.net/jdk/commit/70bd57ed3544cdb41029d425507ba4b9b35c8cdb Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8283049: Fix non-singleton LoggerFinder error message: s/on/one Reviewed-by: dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7780 From duke at openjdk.java.net Mon Mar 14 19:12:29 2022 From: duke at openjdk.java.net (iaroslavski) Date: Mon, 14 Mar 2022 19:12:29 GMT Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort) [v12] 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) * Improved mixed insertion sort * Optimized insertion sort * Improved merging sort * Optimized soring tests ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3938/files - new: https://git.openjdk.java.net/jdk/pull/3938/files/95f15386..8a373741 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3938&range=10-11 Stats: 2935 lines in 3 files changed: 1092 ins; 1401 del; 442 mod Patch: https://git.openjdk.java.net/jdk/pull/3938.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3938/head:pull/3938 PR: https://git.openjdk.java.net/jdk/pull/3938 From redestad at openjdk.java.net Mon Mar 14 19:44:47 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 14 Mar 2022 19:44:47 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v15] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 23:59:32 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year in new test Gentle reminder that I need a review of the aarch64 changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From darcy at openjdk.java.net Mon Mar 14 20:06:13 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Mar 2022 20:06:13 GMT Subject: RFR: JDK-8283075: Bad `IllegalArgumentException` message when calling `ClassDesc.arrayType(int)` which results in a rank > 255 Message-ID: Improving the exception messages for out-of-supported-range array types. I'll update copyrights before pushing. ------------- Commit messages: - Appease jcheck - Update @bug line of test - JDK-8283075: Bad `IllegalArgumentException` message when calling `ClassDesc.arrayType(int)` which results in a rank > 255 Changes: https://git.openjdk.java.net/jdk/pull/7812/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7812&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283075 Stats: 29 lines in 2 files changed: 24 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7812/head:pull/7812 PR: https://git.openjdk.java.net/jdk/pull/7812 From valeriep at openjdk.java.net Mon Mar 14 20:08:31 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Mon, 14 Mar 2022 20:08:31 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Update again and undo DSA changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/f728aa7d..48f562ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=03-04 Stats: 45 lines in 9 files changed: 8 ins; 2 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From vromero at openjdk.java.net Mon Mar 14 20:26:46 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 14 Mar 2022 20:26:46 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 19:56:17 GMT, Joe Darcy wrote: > Improving the exception messages for out-of-supported-range array types. > > I'll update copyrights before pushing. src/java.base/share/classes/java/lang/constant/ClassDesc.java line 186: > 184: if (rank <= 0 || netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS) > 185: throw new IllegalArgumentException("rank: " + netRank + > 186: " exceeds maximum supported dimension of " + if the `rank < 0` it won't be exceeding the maximum supported dimensions so this message only applies to the second condition ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From rriggs at openjdk.java.net Mon Mar 14 20:33:41 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 14 Mar 2022 20:33:41 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v15] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 23:59:32 GMT, Claes Redestad wrote: >> I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. >> >> Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 >> >> - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. >> >> - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. >> >> - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright year in new test core libs String.java changes look fine. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7231 From achung at openjdk.java.net Mon Mar 14 20:39:46 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 14 Mar 2022 20:39:46 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: > msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed repeated lines from ROOT bundle in CurrencyNames ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/4735722d..d5c9b884 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=01-02 Stats: 675 lines in 3 files changed: 0 ins; 675 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From darcy at openjdk.java.net Mon Mar 14 21:00:14 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Mar 2022 21:00:14 GMT Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath Message-ID: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 ------------- Commit messages: - JDK-8283124: Add constant for tau to Math and StrictMath Changes: https://git.openjdk.java.net/jdk/pull/7813/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7813&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283124 Stats: 29 lines in 2 files changed: 26 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7813.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7813/head:pull/7813 PR: https://git.openjdk.java.net/jdk/pull/7813 From bpb at openjdk.java.net Mon Mar 14 21:13:41 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 14 Mar 2022 21:13:41 GMT Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy wrote: > Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7813 From darcy at openjdk.java.net Mon Mar 14 21:27:29 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Mar 2022 21:27:29 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: References: Message-ID: > Improving the exception messages for out-of-supported-range array types. > > I'll update copyrights before pushing. 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.java.net/jdk/pull/7812/files - new: https://git.openjdk.java.net/jdk/pull/7812/files/51388988..1723d710 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7812&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7812&range=00-01 Stats: 14 lines in 1 file changed: 9 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7812/head:pull/7812 PR: https://git.openjdk.java.net/jdk/pull/7812 From weijun at openjdk.java.net Mon Mar 14 21:30:46 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Mon, 14 Mar 2022 21:30:46 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 20:08:31 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Update again and undo DSA changes Some small comments. Otherwise looks fine. src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 121: > 119: v = max; > 120: } > 121: } catch (NullPointerException | NoSuchAlgorithmException ne) { There is no need to mention NPE. src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 101: > 99: // set default key sizes and apply our own algorithm-specific limits > 100: // override lower limit to disallow unsecure keys being generated > 101: // override upper limit to deter DOS attack No a P11 expert, but I assume `algorithm` here is already guaranteed to be in uppercase? src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 122: > 120: default -> { > 121: throw new ProviderException > 122: ("Unrecognized algorithm for checking key size"); If it's an unknown key algorithm, is it possible we just ignore it and keep using `minKeyLen` and `maxKeyLen`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From raffaello.giulietti at gmail.com Mon Mar 14 21:32:18 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 14 Mar 2022 22:32:18 +0100 Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: <568253e8-0aec-7ff6-1bd0-03a0956e2b7d@gmail.com> Hello, I find it a bit disturbing that PI is specified with 21 digits whereas TAU has 16. I think that specifying PI as public static final double PI = 3.141592653589793; doesn't harm anybody and makes it visually more consistent with TAU- Greetings Raffaello On 3/14/22 22:13, Brian Burkhalter wrote: > On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy wrote: > >> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. >> >> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 > > Marked as reviewed by bpb (Reviewer). > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7813 From hboehm at google.com Mon Mar 14 21:51:49 2022 From: hboehm at google.com (Hans Boehm) Date: Mon, 14 Mar 2022 14:51:49 -0700 Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: <568253e8-0aec-7ff6-1bd0-03a0956e2b7d@gmail.com> References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> <568253e8-0aec-7ff6-1bd0-03a0956e2b7d@gmail.com> Message-ID: Couldn't the apiNote just say TAU == 2 * PI instead? I think the fact that this is actually a guaranteed floating point equality aids clarity. On Mon, Mar 14, 2022 at 2:33 PM Raffaello Giulietti < raffaello.giulietti at gmail.com> wrote: > Hello, > > I find it a bit disturbing that PI is specified with 21 digits whereas > TAU has 16. > I think that specifying PI as > public static final double PI = 3.141592653589793; > doesn't harm anybody and makes it visually more consistent with TAU- > > > Greetings > Raffaello > > > > On 3/14/22 22:13, Brian Burkhalter wrote: > > On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy wrote: > > > >> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a > very common value in mathematical formulas, it is helpful to give it a > distinct constant. > >> > >> Please also review the CSR > https://bugs.openjdk.java.net/browse/JDK-8283136 > > > > Marked as reviewed by bpb (Reviewer). > > > > ------------- > > > > PR: https://git.openjdk.java.net/jdk/pull/7813 > From naoto at openjdk.java.net Mon Mar 14 21:58:45 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 14 Mar 2022 21:58:45 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 20:39:46 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed repeated lines from ROOT bundle in CurrencyNames src/jdk.compiler/share/classes/com/sun/tools/javac/resources/ct_ja.properties line 1: > 1: # The change to this file (moving ct.properties to ct_ja.properties) does look suspicious. Looks like this is not a translation file, but some kind of a configuration for `javac`. If so, it should not be translated (and translation configuration in the closed repository should exclude this file) ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From vromero at openjdk.java.net Mon Mar 14 22:01:40 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 14 Mar 2022 22:01:40 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: References: Message-ID: <6B8x-NgCsh_W0ddBtLHQw81Mqi_H54RF8oMD9H_aNac=.299c3ce0-087c-4428-ade8-ec98f73df746@github.com> On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote: >> Improving the exception messages for out-of-supported-range array types. >> >> I'll update copyrights before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7812 From raffaello.giulietti at gmail.com Mon Mar 14 22:07:28 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 14 Mar 2022 23:07:28 +0100 Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> <568253e8-0aec-7ff6-1bd0-03a0956e2b7d@gmail.com> Message-ID: <463863d0-63dc-2255-731f-ac4c1e6f4fa4@gmail.com> Right, and PI with 16 digits (or 17). On 3/14/22 22:51, Hans Boehm wrote: > Couldn't the apiNote just say TAU == 2 * PI instead? I think the fact > that this is actually a guaranteed floating point equality aids clarity. > > > > On Mon, Mar 14, 2022 at 2:33 PM Raffaello Giulietti > > > wrote: > > Hello, > > I find it a bit disturbing that PI is specified with 21 digits whereas > TAU has 16. > I think that specifying PI as > ? ? ?public static final double PI = 3.141592653589793; > doesn't harm anybody and makes it visually more consistent with TAU- > > > Greetings > Raffaello > > > > On 3/14/22 22:13, Brian Burkhalter wrote: > > On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy > wrote: > > > >> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi > is a very common value in mathematical formulas, it is helpful to > give it a distinct constant. > >> > >> Please also review the CSR > https://bugs.openjdk.java.net/browse/JDK-8283136 > > > > > Marked as reviewed by bpb (Reviewer). > > > > ------------- > > > > PR: https://git.openjdk.java.net/jdk/pull/7813 > > From ccheung at openjdk.java.net Mon Mar 14 22:11:45 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Mon, 14 Mar 2022 22:11:45 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v6] In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 06:55:23 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added helper function CollectedHeap::zap_filler_array_with CDS changes look good. One minor comment on a test. test/hotspot/jtreg/runtime/cds/appcds/javaldr/LockDuringDumpAgent.java line 65: > 63: if (elapsed >= timeout) { > 64: System.out.println("This JVM may decide to not launch any Java threads during -Xshare:dump."); > 65: System.out.println("This is OK because no string objects be in a locked state during heap dump."); Should `no string objects be` be `no string objects could be`? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7748 From darcy at openjdk.java.net Mon Mar 14 23:15:46 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Mar 2022 23:15:46 GMT Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy wrote: > Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 > _Mailing list message from [Hans Boehm](mailto:hboehm at google.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > Couldn't the apiNote just say TAU == 2 * PI instead? I think the fact that this is actually a guaranteed floating point equality aids clarity. > > On Mon, Mar 14, 2022 at 2:33 PM Raffaello Giulietti < raffaello.giulietti at gmail.com> wrote: > > > Hello, > > I find it a bit disturbing that PI is specified with 21 digits whereas > > TAU has 16. > > I think that specifying PI as > > public static final double PI = 3.141592653589793; > > doesn't harm anybody and makes it visually more consistent with TAU- > > Greetings > > Raffaello > > On 3/14/22 22:13, Brian Burkhalter wrote: > > > On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy wrote: > > > > Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a > > > > very common value in mathematical formulas, it is helpful to give it a > > > > distinct constant. > > > > Please also review the CSR > > > > https://bugs.openjdk.java.net/browse/JDK-8283136 Yes; after further thought, I agree having tau = 2.0*pi is preferable. Just to go through the logic, 2.0 is exactly representable in binary floating-point and an in-range multiple by two is just an exponent adjustment. Floating-point exponent transitions occur at 2.0 = 0x1 * 2^1, 4.0 = 0x1 * 2^2, and 8.0 = 0x1 * 2^3. The value of pi is between 2.0 and 4.0 and has an exponent of 1 while the value of tau ~= 6.28 is between 4.0 and 8.0 and has an exponent of 2. So whatever the closest floating-point value to exact pi is, 2.0 * Math.pi will be the closest floating-point value to tau. ------------- PR: https://git.openjdk.java.net/jdk/pull/7813 From darcy at openjdk.java.net Mon Mar 14 23:21:26 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 14 Mar 2022 23:21:26 GMT Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath [v2] In-Reply-To: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: > Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Set value with 2.0 * PI. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7813/files - new: https://git.openjdk.java.net/jdk/pull/7813/files/c5931750..0fae656a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7813&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7813&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7813.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7813/head:pull/7813 PR: https://git.openjdk.java.net/jdk/pull/7813 From joe.darcy at oracle.com Mon Mar 14 23:22:56 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 14 Mar 2022 16:22:56 -0700 Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: <568253e8-0aec-7ff6-1bd0-03a0956e2b7d@gmail.com> References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> <568253e8-0aec-7ff6-1bd0-03a0956e2b7d@gmail.com> Message-ID: <6df8c6d6-0ea1-344f-267a-683197253153@oracle.com> Hi Raffaello, With changing TAU to be set to 2.0 * PI, I'll file a follow-up bug to use the least-precision decimal values that will get rounded to PI and E, respectively, in Math and StrictMath. (Per the general base conversion properties for the double format, there will be between 15 and 17 decimal digits rather than 21.) Thanks, -Joe On 3/14/2022 2:32 PM, Raffaello Giulietti wrote: > Hello, > > I find it a bit disturbing that PI is specified with 21 digits whereas > TAU has 16. > I think that specifying PI as > ??? public static final double PI = 3.141592653589793; > doesn't harm anybody and makes it visually more consistent with TAU- > > > Greetings > Raffaello > > > > On 3/14/22 22:13, Brian Burkhalter wrote: >> On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy wrote: >> >>> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is >>> a very common value in mathematical formulas, it is helpful to give >>> it a distinct constant. >>> >>> Please also review the CSR >>> https://bugs.openjdk.java.net/browse/JDK-8283136 >> >> Marked as reviewed by bpb (Reviewer). >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/7813 From almatvee at openjdk.java.net Tue Mar 15 01:05:51 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Tue, 15 Mar 2022 01:05:51 GMT Subject: RFR: JDK-8236128: Allow jpackage create installers for services In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk wrote: > Implementation of [JDK-8275062: "Allow jpackage create installers for services"](https://bugs.openjdk.java.net/browse/JDK-8275062) > CSR Marked as reviewed by almatvee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7793 From xgong at openjdk.java.net Tue Mar 15 01:18:46 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 15 Mar 2022 01:18:46 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong wrote: > The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. > And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. > > To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: > - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. > - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. > > So with this patch, the following transformations are applied: > > For non-masked negation with NEON: > > movi v16.4s, #0x0 > sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s > > and with SVE: > > mov z16.s, #0 > sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s > > For masked negation with NEON: > > movi v17.4s, #0x1 > mvn v19.16b, v18.16b > mov v20.16b, v16.16b ==> neg v18.4s, v17.4s > bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b > add v19.4s, v20.4s, v17.4s > mov v18.16b, v16.16b > bsl v18.16b, v19.16b, v20.16b > > and with SVE: > > mov z16.s, #-1 > mov z17.s, #1 ==> neg z16.s, p0/m, z16.s > eor z18.s, p0/m, z18.s, z16.s > add z18.s, p0/m, z18.s, z17.s > > Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): > > NEON: > Benchmark Gain > Byte128Vector.NEG 1.029 > Byte128Vector.NEGMasked 1.757 > Short128Vector.NEG 1.041 > Short128Vector.NEGMasked 1.659 > Int128Vector.NEG 1.005 > Int128Vector.NEGMasked 1.513 > Long128Vector.NEG 1.003 > Long128Vector.NEGMasked 1.878 > > SVE with 512-bits: > Benchmark Gain > ByteMaxVector.NEG 1.10 > ByteMaxVector.NEGMasked 1.165 > ShortMaxVector.NEG 1.056 > ShortMaxVector.NEGMasked 1.195 > IntMaxVector.NEG 1.002 > IntMaxVector.NEGMasked 1.239 > LongMaxVector.NEG 1.031 > LongMaxVector.NEGMasked 1.191 > > X86 (non AVX-512): > Benchmark Gain > ByteMaxVector.NEGMasked 1.254 > ShortMaxVector.NEGMasked 1.359 > IntMaxVector.NEGMasked 1.431 > LongMaxVector.NEGMasked 1.989 > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 Hi, could anyone please take a look at this PR? Thanks so much! ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From smarks at openjdk.java.net Tue Mar 15 01:23:44 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Mar 2022 01:23:44 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v17] In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 01:26:24 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > make changes proposed Thanks for the updates. I've updated the CSR and it should go through the review process now. I've also pulled the latest changes and will run them through our internal build/test system. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From kevinb at google.com Tue Mar 15 01:23:59 2022 From: kevinb at google.com (Kevin Bourrillion) Date: Mon, 14 Mar 2022 18:23:59 -0700 Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: On Mon, Mar 14, 2022 at 4:16 PM Joe Darcy wrote: Yes; after further thought, I agree having tau = 2.0*pi is preferable. > Kinda reads like it's taking a stand on which of the two is the *real* fundamental mathematical constant and which one is a hack. Therefore it should really be pi that's set to tau/2.0 :-) Can PI have a @see link to this so that people know about it? (I'll just mention that {from,to}Radians would also benefit from some advertisement, as a great many PI usages are dividing it by or into 180, but do what thou wilt with that FYI.) -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From darcy at openjdk.java.net Tue Mar 15 01:43:06 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 01:43:06 GMT Subject: RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants Message-ID: Depending on the range of the number line, a double value has between 15 and 17 digits of decimal precision. The literals used to initialize Math.PI and Math.E have several digits more precision than that maximum. That is potentially confusing to readers of the code and the minimum length strings to exactly represent the value in question should be used instead. ------------- Commit messages: - JDK-8283143: Use minimal-length literals to initialize PI and E constants Changes: https://git.openjdk.java.net/jdk/pull/7814/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7814&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283143 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7814.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7814/head:pull/7814 PR: https://git.openjdk.java.net/jdk/pull/7814 From valeriep at openjdk.java.net Tue Mar 15 01:47:51 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 01:47:51 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:08:30 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update again and undo DSA changes > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 121: > >> 119: v = max; >> 120: } >> 121: } catch (NullPointerException | NoSuchAlgorithmException ne) { > > There is no need to mention NPE. Sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From iris at openjdk.java.net Tue Mar 15 02:33:39 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 15 Mar 2022 02:33:39 GMT Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath [v2] In-Reply-To: References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: On Mon, 14 Mar 2022 23:21:26 GMT, Joe Darcy wrote: >> Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. >> >> Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Set value with 2.0 * PI. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7813 From smarks at openjdk.java.net Tue Mar 15 02:44:46 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Mar 2022 02:44:46 GMT Subject: RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 01:36:14 GMT, Joe Darcy wrote: > Depending on the range of the number line, a double value has between 15 and 17 digits of decimal precision. The literals used to initialize Math.PI and Math.E have several digits more precision than that maximum. > > That is potentially confusing to readers of the code and the minimum length strings to exactly represent the value in question should be used instead. I've verified that the shorter literals result in the same double bit pattern. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7814 From darcy at openjdk.java.net Tue Mar 15 02:42:40 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 02:42:40 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: Message-ID: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com> On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong wrote: > The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. > And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. > > To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: > - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. > - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. > > So with this patch, the following transformations are applied: > > For non-masked negation with NEON: > > movi v16.4s, #0x0 > sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s > > and with SVE: > > mov z16.s, #0 > sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s > > For masked negation with NEON: > > movi v17.4s, #0x1 > mvn v19.16b, v18.16b > mov v20.16b, v16.16b ==> neg v18.4s, v17.4s > bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b > add v19.4s, v20.4s, v17.4s > mov v18.16b, v16.16b > bsl v18.16b, v19.16b, v20.16b > > and with SVE: > > mov z16.s, #-1 > mov z17.s, #1 ==> neg z16.s, p0/m, z16.s > eor z18.s, p0/m, z18.s, z16.s > add z18.s, p0/m, z18.s, z17.s > > Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): > > NEON: > Benchmark Gain > Byte128Vector.NEG 1.029 > Byte128Vector.NEGMasked 1.757 > Short128Vector.NEG 1.041 > Short128Vector.NEGMasked 1.659 > Int128Vector.NEG 1.005 > Int128Vector.NEGMasked 1.513 > Long128Vector.NEG 1.003 > Long128Vector.NEGMasked 1.878 > > SVE with 512-bits: > Benchmark Gain > ByteMaxVector.NEG 1.10 > ByteMaxVector.NEGMasked 1.165 > ShortMaxVector.NEG 1.056 > ShortMaxVector.NEGMasked 1.195 > IntMaxVector.NEG 1.002 > IntMaxVector.NEGMasked 1.239 > LongMaxVector.NEG 1.031 > LongMaxVector.NEGMasked 1.191 > > X86 (non AVX-512): > Benchmark Gain > ByteMaxVector.NEGMasked 1.254 > ShortMaxVector.NEGMasked 1.359 > IntMaxVector.NEGMasked 1.431 > LongMaxVector.NEGMasked 1.989 > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: double negate(double arg) {return -0.0 - arg; } This is to handle signed zeros correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From xgong at openjdk.java.net Tue Mar 15 02:50:43 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 15 Mar 2022 02:50:43 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com> References: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com> Message-ID: On Tue, 15 Mar 2022 02:39:42 GMT, Joe Darcy wrote: > Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: > > double negate(double arg) {return -0.0 - arg; } > > This is to handle signed zeros correctly. Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From poweruserm at live.com.au Tue Mar 15 04:23:02 2022 From: poweruserm at live.com.au (A Z) Date: Tue, 15 Mar 2022 04:23:02 +0000 Subject: Discussion about Java Floating Point? Message-ID: To core-libs-dev at openjdk.java.net, In terms of floating point, it seems there are thus three (3) phenomena that are relevant. 1) Arithmetic on float and double, via operators. 2) Elementary function calls, namely those made from java.lang.StrictMath, as it is, on double values. 3) Comparison operators. ==, !=, >, <, >=,<=. Java floating point successfully has 3) the way required, even though other languages, particularly C++ , do not compare their floats and doubles through those comparison operators. The point at issue is Java although, so Java is satisfactory at point 3). My point of contention is that Java does not have 1) and 2) operating as they should, even though C++ and other languages do, in those two areas, namely C++: Martin has submitted the following: ?The following statement is not entirely true when using finite floating point precision: > (?snip?) It is a mathematical fact that, for > consistent, necessary and even fast term, 10% of 10% must > always precisely be 1%, and by no means anything else." /* #include using namespace std; int main() { cout << "Program has started..." << endl; double a = 0.1D; double b = 0.1D; double c = a*b; cout << endl << c << endl << endl; float d = 0.1F; float e = 0.1F; float f = d*e; cout << f << endl << endl; cout << "Program has Finished."; return 0; } */ /* Program has started... 0.01 0.01 Program has Finished. */ This is actually not fully or finally true, including SSE, SSE algorithm logic and further. The included C++ example of mine above here disproves this. Even though I do contextually admit these answers can only work within the range of the involved types, it is still actually the case that 10% of 10% can and always precisely be 1%, within the range of the type used, and by no means anything else. Because of the laws of decimal arithmetic. See https://en.wikipedia.org/wiki/Floating-point_arithmetic and the starting sentence: 'In computing, floating-point arithmetic (FP) is arithmetic using formulaic representation of real numbers as an approximation to support a trade-off betwee range and precision.' However, it simply isn't the case that reduced precision has to exist inside the range, certainly not any more. Rationally, one would have to think, with the present SSE support in ubiquity, and the preimplementation that is possible and already around elsewhere, that this kind of tradeoff in floating point isn't any kind of use or advantage any more. This is part of the issue with Java and the OpenJDK at this time, and I am trying to contend that this should be changed, either at default or in some mutual compatibility mode. The other part is java.lang.StrictMath, since it generates denormal and pronormal values on its own, also. Raffaello has stated: To summarize, Java uses IEEE 754 binary arithmetic as by specification, as do most other languages, including C/C++. It is however fundamentally wrong to use binary floating-point arithmetic to emulate decimal behavior. Also, pay attention to the output routines that convert float and double values to a decimal representation. Usually, C and C++ will have information loss by default, as in your case. What we and others are beginning to need to happen, in detailed Java 2D and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java floating point arithmetic and function behaviour, on float and double, within their ranges, do need to perfectly match decimal behaviour. C++ arithmetic, at least, has had no problem using floating point arithmetic, at least, to emulate decimal behaviour. I am trying to prove the opposite to Raffaello's statements, that floating point can and indeed must represent decimal behaviour. Output functions in any language that alter the appearance of the float or double value become irrelevant, because the only relevant factor is the operator behaviour and the innate, representation viewpoint of those float or double values. In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must be changed so that it upholds base ten (10) arithmetic, algebra,and elementary functions on real value arguments within the ranges of double and/or float. Alongside a calculator class that upholds the same. These are in keeping with the Wikipedia view on floating point arithmetic that I quoted earlier, but more than that, they are in keeping with the standards/specifications of Mathematics, and not just an idea that grew in computer science. I wish to still request that this matter be pursued, despite Java's stance on this matter, in terms of the JRE for a very long time now. While it is the case that JDK-8190991 does exist, and should continue, JDK-8190947 has been too blithely swept away. See: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 The explanation 'Closing this enhancement as will not fix' does nothing to explain why the advantages of floating point repair have been turned away, and in fact, not apprehended specifically in Java. Is there someone who can look deeper into this matter, and implement arithmetic and Calculator class changes for the next release version of SE and OpenJDK? From alanb at openjdk.java.net Tue Mar 15 07:28:47 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Mar 2022 07:28:47 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote: >> Improving the exception messages for out-of-supported-range array types. >> >> I'll update copyrights before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From plevart at openjdk.java.net Tue Mar 15 07:53:46 2022 From: plevart at openjdk.java.net (Peter Levart) Date: Tue, 15 Mar 2022 07:53:46 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: References: Message-ID: <4uQRE2eVYDoSGMKOavXQzlw2EE2-NvYs-GpnU--o2iw=.ee2229d2-6379-43ef-8239-db170a3d6973@github.com> On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote: >> Improving the exception messages for out-of-supported-range array types. >> >> I'll update copyrights before pushing. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Changes requested by plevart (Reviewer). src/java.base/share/classes/java/lang/constant/ClassDesc.java line 179: > 177: int netRank; > 178: if (rank <= 0) { > 179: throw new IllegalArgumentException("rank " + rank + "is not a positive value"); There's a space missing in the IAE message after the rank number. For example, if rank == 0, the message would be: "rank 0is not positive value" ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From iklam at openjdk.java.net Tue Mar 15 08:17:24 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Mar 2022 08:17:24 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v7] In-Reply-To: References: Message-ID: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). Ioi Lam 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 12 additional commits since the last revision: - fixed copyright - Merge branch 'master' into 8253495-cds-generateds-non-deterministic-output-2 - @calvinccheung review: fixed typo - Added helper function CollectedHeap::zap_filler_array_with - @kimbarrett comments - zero GC heap filler arrays - improvement zeroing of alignment gaps - Fixed zero build - Merge branch 'master' into 8253495-cds-generateds-non-deterministic-output-2 - fixed test - ... and 2 more: https://git.openjdk.java.net/jdk/compare/a6344ded...cd934f3c ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7748/files - new: https://git.openjdk.java.net/jdk/pull/7748/files/47e0238a..cd934f3c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=05-06 Stats: 6804 lines in 210 files changed: 3347 ins; 1802 del; 1655 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From iklam at openjdk.java.net Tue Mar 15 08:18:56 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Mar 2022 08:18:56 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v6] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 22:07:24 GMT, Calvin Cheung wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Added helper function CollectedHeap::zap_filler_array_with > > test/hotspot/jtreg/runtime/cds/appcds/javaldr/LockDuringDumpAgent.java line 65: > >> 63: if (elapsed >= timeout) { >> 64: System.out.println("This JVM may decide to not launch any Java threads during -Xshare:dump."); >> 65: System.out.println("This is OK because no string objects be in a locked state during heap dump."); > > Should `no string objects be` be `no string objects could be`? Thanks for the review. I've fixed the comment as you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From Alan.Bateman at oracle.com Tue Mar 15 08:57:27 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Mar 2022 08:57:27 +0000 Subject: Behavior change in the jar tool JDK11 vs JDK8. In-Reply-To: References: <42aca6b2-8282-469a-b897-00f4adde6a18@oracle.com> Message-ID: On 15/03/2022 08:18, Pasam Soujanya1 wrote: > I tried "tar" with a target that does not exist, and the tar file got > created successfully (with an error message about the missing file) > and with the exit code 0 (success). Same behavior is seen with JDK8 > jar too. From JDK11 onward, the output jar isn't created and the exit > code is 1(failure). > > So, to summarise: "jar" from Java 8 seems to be on the lines of "tar". > > Do we want to continue with this "jar" behaviour which is not the same > as "tar" ? > The behavior since JDK 9 is to delete the temporary file when there is an error. This looks to be the correct behavior. If it were changed back then people would complain that jar is leaving files behind when it fails. I'm curious how you run into this. Is this a script that runs with +e or doesn't check the exit status? -Alan From ihse at openjdk.java.net Tue Mar 15 10:00:45 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Mar 2022 10:00:45 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v7] In-Reply-To: References: Message-ID: <2V0vZlddOZ64jgcAUBOOYbOs4BR7IBpNdtRgiy-kCnE=.0a6072a2-1b7e-40a3-b3f8-4f1dc02dcc37@github.com> On Tue, 15 Mar 2022 08:17:24 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam 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 12 additional commits since the last revision: > > - fixed copyright > - Merge branch 'master' into 8253495-cds-generateds-non-deterministic-output-2 > - @calvinccheung review: fixed typo > - Added helper function CollectedHeap::zap_filler_array_with > - @kimbarrett comments > - zero GC heap filler arrays > - improvement zeroing of alignment gaps > - Fixed zero build > - Merge branch 'master' into 8253495-cds-generateds-non-deterministic-output-2 > - fixed test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1ab17a39...cd934f3c Build changes look good. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7748 From raffaello.giulietti at gmail.com Tue Mar 15 10:03:27 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 15 Mar 2022 11:03:27 +0100 Subject: Discussion about Java Floating Point? In-Reply-To: References: Message-ID: Hi, Java, as well as most implementations of most languages, including C and C++, have adopted the IEEE 754 floating-point standard, first issued in 1985. The standard specifies the formats, the outcome of operators and comparisons up to the last bit. Try out this C/C++ code (I'm on Linux with gcc) #include using namespace std; int main() { cout << "Program has started..." << endl; double a = 0.1D; double b = 0.1D; double c = a*b; double d = 0.01D; cout << endl << "0.1D*0.1D " << (c == d ? "==" : "!=") << " 0.01D" << endl << endl; cout.precision(30); cout << c << endl; cout << "0.01D : "; cout.precision(30); cout << d << endl << endl; cout << "Program has finished." << endl; return 0; } This is the output I see: Program has started... 0.1D*0.1D != 0.01D 0.1D*0.1D : 0.010000000000000001942890293094 0.01D : 0.0100000000000000002081668171172 Program has finished. So 0.1D*0.1D != 0.01D, as stated on my previous post. That is, expectations on decimal behavior are usually wrong. It is inherently, mathematically *impossible* to emulate decimal behavior with binary IEEE 754 arithmetic. That's why Java also offers java.math.BigDecimal, a decimal floating-point library implemented in software. Also, as suggested in that post, incrementing the precision of the output by means of precision(30) as done above, for example, also clearly shows where the two values start being different, with 0.1D*0.1D being slightly greater than 0.01D. Note that the precision only directs how many digits appear in the decimal output: it doesn't affect the underlying floating-point arithmetic at all. The latter follows the spec in full. In fact, all operators and comparisons are implemented directly in hardware, not in libraries. All CPUs designed in the last couple of decades implement IEEE 754. This shows that the default precision for decimal output in C/C++ is not sufficient to expose the difference between the values. You have to set a higher precision to see differences. This also shows the advantage of the default Java conversion routine, as opposed to the default precision in C/C++: different values are converted to different decimal outcome, without you having to set anything, because Java adapts the precision of the output automatically, depending on the value. Finally, while Wikipedia is an exceptional source of information, the ultimate authoritative reference are the IEEE 754 spec, the C/C++ specs and other languages specs, and their related standard libraries specs. Greetings Raffaello On 3/15/22 05:23, A Z wrote: > To core-libs-dev at openjdk.java.net, > > In terms of floating point, it seems there are thus > three (3) phenomena that are relevant. > > 1) Arithmetic on float and double, via operators. > 2) Elementary function calls, namely > those made from java.lang.StrictMath, as it is, > on double values. > 3) Comparison operators. ==, !=, >, <, >=,<=. > > Java floating point successfully has 3) the way required, > even though other languages, particularly C++ , do not > compare their floats and doubles through those comparison > operators. The point at issue is Java although, so Java is > satisfactory at point 3). > > My point of contention is that Java does not have 1) and 2) > operating as they should, even though C++ and other > languages do, in those two areas, namely C++: > > Martin has submitted the following: > ?The following statement is not entirely true when using finite floating > point precision: > >> (?snip?) It is a mathematical fact that, for >> consistent, necessary and even fast term, 10% of 10% must >> always precisely be 1%, and by no means anything else." > /* > #include > > using namespace std; > > int main() > { > cout << "Program has started..." << endl; > double a = 0.1D; > double b = 0.1D; > double c = a*b; > cout << endl << c << endl << endl; > float d = 0.1F; > float e = 0.1F; > float f = d*e; > cout << f << endl << endl; > cout << "Program has Finished."; > return 0; > } > */ > /* > Program has started... > > 0.01 > > 0.01 > > Program has Finished. > */ > > This is actually not fully or finally true, including SSE, SSE algorithm logic and further. > The included C++ example of mine above here disproves this. Even though I do > contextually admit these answers can only work within the range of the > involved types, it is still actually the case that 10% of 10% can and always > precisely be 1%, within the range of the type used, and by no means > anything else. Because of the laws of decimal arithmetic. > > See https://en.wikipedia.org/wiki/Floating-point_arithmetic > and the starting sentence: > > 'In computing, floating-point arithmetic (FP) is arithmetic using formulaic > representation of real numbers as an approximation to support a > trade-off betwee range and precision.' > > However, it simply isn't the case that reduced precision has to exist inside > the range, certainly not any more. Rationally, one would have to think, > with the present SSE support in ubiquity, and the preimplementation > that is possible and already around elsewhere, that this kind of tradeoff > in floating point isn't any kind of use or advantage any more. > > This is part of the issue with Java and the OpenJDK at this time, and I am trying > to contend that this should be changed, either at default or in > some mutual compatibility mode. The other part is java.lang.StrictMath, > since it generates denormal and pronormal values on its own, also. > > Raffaello has stated: > To summarize, Java uses IEEE 754 binary arithmetic as by specification, > as do most other languages, including C/C++. It is however fundamentally > wrong to use binary floating-point arithmetic to emulate decimal > behavior. Also, pay attention to the output routines that convert float > and double values to a decimal representation. Usually, C and C++ will > have information loss by default, as in your case. > What we and others are beginning to need to happen, in detailed Java 2D > and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java > floating point arithmetic and function behaviour, on float and double, > within their ranges, do need to perfectly match decimal behaviour. > > C++ arithmetic, at least, has had no problem using floating point arithmetic, > at least, to emulate decimal behaviour. I am trying to prove the opposite to > Raffaello's statements, that floating point can and indeed must represent decimal behaviour. > Output functions in any language that alter the appearance of the float or double > value become irrelevant, because the only relevant factor is the operator behaviour > and the innate, representation viewpoint of those float or double values. > > In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must be changed > so that it upholds base ten (10) arithmetic, algebra,and elementary functions on real value > arguments within the ranges of double and/or float. Alongside a calculator class that upholds > the same. These are in keeping with the Wikipedia view on floating point arithmetic that I > quoted earlier, but more than that, they are in keeping with the standards/specifications of > Mathematics, and not just an idea that grew in computer science. > > I wish to still request that this matter be pursued, despite Java's stance on this matter, > in terms of the JRE for a very long time now. > > While it is the case that JDK-8190991 does exist, and should continue, JDK-8190947 > has been too blithely swept away. See: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 > The explanation 'Closing this enhancement as will not fix' does nothing to explain why the advantages > of floating point repair have been turned away, and in fact, not apprehended specifically in Java. > > Is there someone who can look deeper into this matter, and implement arithmetic and Calculator class > changes for the next release version of SE and OpenJDK? > From raffaello.giulietti at gmail.com Tue Mar 15 10:19:37 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 15 Mar 2022 11:19:37 +0100 Subject: RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants In-Reply-To: References: Message-ID: The new decimal literals have indeed the minimal length required to recover the doubles closest to the true mathematical values. Raffaello On 3/15/22 02:43, Joe Darcy wrote: > Depending on the range of the number line, a double value has between 15 and 17 digits of decimal precision. The literals used to initialize Math.PI and Math.E have several digits more precision than that maximum. > > That is potentially confusing to readers of the code and the minimum length strings to exactly represent the value in question should be used instead. > > ------------- > > Commit messages: > - JDK-8283143: Use minimal-length literals to initialize PI and E constants > > Changes: https://git.openjdk.java.net/jdk/pull/7814/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7814&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8283143 > Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod > Patch: https://git.openjdk.java.net/jdk/pull/7814.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/7814/head:pull/7814 > > PR: https://git.openjdk.java.net/jdk/pull/7814 From raffaello.giulietti at gmail.com Tue Mar 15 10:23:19 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Tue, 15 Mar 2022 11:23:19 +0100 Subject: Discussion about Java Floating Point? In-Reply-To: References: Message-ID: <9164acfa-93a2-a215-5673-030926690699@gmail.com> Sorry, for some reason a line was missing in the C++ code #include using namespace std; int main() { cout << "Program has started..." << endl; double a = 0.1D; double b = 0.1D; double c = a*b; double d = 0.01D; cout << endl << "0.1D*0.1D " << (c == d ? "==" : "!=") << " 0.01D" << endl << endl; cout << "0.1D*0.1D : "; cout.precision(30); cout << c << endl; cout << "0.01D : "; cout.precision(30); cout << d << endl << endl; cout << "Program has finished." << endl; return 0; } On 3/15/22 11:03, Raffaello Giulietti wrote: > Hi, > > Java, as well as most implementations of most languages, including C and > C++, have adopted the IEEE 754 floating-point standard, first issued in > 1985. The standard specifies the formats, the outcome of operators and > comparisons up to the last bit. > > Try out this C/C++ code (I'm on Linux with gcc) > > > > #include > > using namespace std; > > int main() > { > ??? cout << "Program has started..." << endl; > ??? double a = 0.1D; > ??? double b = 0.1D; > ??? double c = a*b; > ??? double d = 0.01D; > ??? cout << endl << "0.1D*0.1D " << (c == d ? "==" : "!=") << " 0.01D" > << endl << endl; > ??? cout.precision(30); > ??? cout << c << endl; > ??? cout << "0.01D???? : "; > ??? cout.precision(30); > ??? cout << d << endl << endl; > ??? cout << "Program has finished." << endl; > ??? return 0; > } > > > > This is the output I see: > > > > Program has started... > > 0.1D*0.1D != 0.01D > > 0.1D*0.1D : 0.010000000000000001942890293094 > 0.01D???? : 0.0100000000000000002081668171172 > > Program has finished. > > > > So 0.1D*0.1D != 0.01D, as stated on my previous post. That is, > expectations on decimal behavior are usually wrong. It is inherently, > mathematically *impossible* to emulate decimal behavior with binary IEEE > 754 arithmetic. That's why Java also offers java.math.BigDecimal, a > decimal floating-point library implemented in software. > > Also, as suggested in that post, incrementing the precision of the > output by means of precision(30) as done above, for example, also > clearly shows where the two values start being different, with 0.1D*0.1D > being slightly greater than 0.01D. > > Note that the precision only directs how many digits appear in the > decimal output: it doesn't affect the underlying floating-point > arithmetic at all. The latter follows the spec in full. In fact, all > operators and comparisons are implemented directly in hardware, not in > libraries. All CPUs designed in the last couple of decades implement > IEEE 754. > > This shows that the default precision for decimal output in C/C++ is not > sufficient to expose the difference between the values. You have to set > a higher precision to see differences. > > This also shows the advantage of the default Java conversion routine, as > opposed to the default precision in C/C++: different values are > converted to different decimal outcome, without you having to set > anything, because Java adapts the precision of the output automatically, > depending on the value. > > Finally, while Wikipedia is an exceptional source of information, the > ultimate authoritative reference are the IEEE 754 spec, the C/C++ specs > and other languages specs, and their related standard libraries specs. > > > Greetings > Raffaello > > > On 3/15/22 05:23, A Z wrote: >> To core-libs-dev at openjdk.java.net, >> >> In terms of floating point, it seems there are thus >> three (3) phenomena that are relevant. >> >> 1) Arithmetic on float and double, via operators. >> 2) Elementary function calls, namely >> ??? those made from java.lang.StrictMath, as it is, >> ??? on double values. >> 3) Comparison operators.? ==, !=, >, <, >=,<=. >> >> Java floating point successfully has 3) the way required, >> even though other languages, particularly C++ , do not >> compare their floats and doubles through those comparison >> operators.? The point at issue is Java although, so Java is >> satisfactory at point 3). >> >> My point of contention is that Java does not have 1) and 2) >> operating as they should, even though C++ and other >> languages do, in those two areas, namely C++: >> >> Martin has submitted the following: >> ?The following statement is not entirely true when using finite floating >> point precision: >> >>> (?snip?) It is a mathematical fact that, for >>> consistent, necessary and even fast term, 10% of 10% must >>> always precisely be 1%, and by no means anything else." >> /* >> #include >> >> using namespace std; >> >> int main() >> { >> ???? cout << "Program has started..." << endl; >> ???? double a = 0.1D; >> ???? double b = 0.1D; >> ???? double c = a*b; >> ???? cout << endl << c << endl << endl; >> ???? float d = 0.1F; >> ???? float e = 0.1F; >> ???? float f = d*e; >> ???? cout << f << endl << endl; >> ???? cout << "Program has Finished."; >> ???? return 0; >> } >> */ >> /* >> Program has started... >> >> 0.01 >> >> 0.01 >> >> Program has Finished. >> */ >> >> This is actually not fully or finally true, including SSE, SSE >> algorithm logic and further. >> The included C++ example of mine above here disproves this.? Even >> though I do >> contextually admit these answers can only work within the range of the >> involved types, it is still actually the case that 10% of 10% can and >> always >> precisely be 1%, within the range of the type used, and by no means >> anything else.? Because of the laws of decimal arithmetic. >> >> See https://en.wikipedia.org/wiki/Floating-point_arithmetic >> and the starting sentence: >> >> 'In computing, floating-point arithmetic (FP) is arithmetic using >> formulaic >> representation of real numbers as an approximation to support a >> trade-off betwee range and precision.' >> >> However, it simply isn't the case that reduced precision has to exist >> inside >> the range, certainly not any more.? Rationally, one would have to think, >> with the present SSE support in ubiquity, and the preimplementation >> that is possible and already around elsewhere, that this kind of tradeoff >> in floating point isn't any kind of use or advantage any more. >> >> This is part of the issue with Java and the OpenJDK at this time, and >> I am trying >> to contend that this should be changed, either at default or in >> some mutual compatibility mode.? The other part is java.lang.StrictMath, >> since it generates denormal and pronormal values on its own, also. >> >> Raffaello has stated: >> To summarize, Java uses IEEE 754 binary arithmetic as by specification, >> as do most other languages, including C/C++. It is however fundamentally >> wrong to use binary floating-point arithmetic to emulate decimal >> behavior. Also, pay attention to the output routines that convert float >> and double values to a decimal representation. Usually, C and C++ will >> have information loss by default, as in your case. >> What we and others are beginning to need to happen, in detailed Java 2D >> and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java >> floating point arithmetic and function behaviour, on float and double, >> within their ranges, do need to perfectly match decimal behaviour. >> >> C++ arithmetic, at least, has had no problem using floating point >> arithmetic, >> at least, to emulate decimal behaviour.? I am trying to prove the >> opposite to >> Raffaello's statements, that floating point can and indeed must >> represent decimal behaviour. >> Output functions in any language that alter the appearance of the >> float or double >> value become irrelevant, because the only relevant factor is the >> operator behaviour >> and the innate, representation viewpoint of those float or double values. >> >> In contrast to Raffaelo, we assert that Java SE and OpenJDK floating >> point must be changed >> so that it upholds base ten (10) arithmetic, algebra,and elementary >> functions on real value >> arguments within the ranges of double and/or float.? Alongside a >> calculator class that upholds >> the same.? These are in keeping with the Wikipedia view on floating >> point arithmetic that I >> quoted earlier, but more than that, they are in keeping with the >> standards/specifications of >> Mathematics, and not just an idea that grew in computer science. >> >> I wish to still request that this matter be pursued, despite Java's >> stance on this matter, >> in terms of the JRE for a very long time now. >> >> While it is the case that JDK-8190991 does exist, and should continue, >> JDK-8190947 >> has been too blithely swept away. See: >> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 >> The explanation 'Closing this enhancement as will not fix' does >> nothing to explain why the advantages >> of floating point repair have been turned away, and in fact, not >> apprehended specifically in Java. >> >> Is there someone who can look deeper into this matter, and implement >> arithmetic and Calculator class >> changes for the next release version of SE and OpenJDK? >> From martin.desruisseaux at geomatys.com Tue Mar 15 10:38:08 2022 From: martin.desruisseaux at geomatys.com (Martin Desruisseaux) Date: Tue, 15 Mar 2022 11:38:08 +0100 Subject: Discussion about Java Floating Point? In-Reply-To: References: Message-ID: <518a75a6-9570-5184-2bf5-53fba3460acf@geomatys.com> Hello A.Z. As Raffaello said, Java arithmetic does not have any more problem than C/C++ when using IEEE 754. The "proof" of contrary is only an illusion due to the rounding behavior of C/C++ output routines, as demonstrated by Raffaello's code. Maybe some C/C++ code use Intel extended precision arithmetic (80 bits instead of 64 bits), but it only pushes the problem further, it still not an exact representation of decimal numbers. Exact representation of 0.1 using base 2 is mathematically impossible, no matter the language (it is a periodic number in base 2). ??? Regards, ??? ??? Martin From redestad at openjdk.java.net Tue Mar 15 11:02:47 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 15 Mar 2022 11:02:47 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v15] In-Reply-To: References: Message-ID: <-T5CXmH7O8EAO-UeX913WJJTZQBdVAms8RNLQx1NJOU=.2befca9f-3850-4f33-93f3-73b89e13b10d@github.com> On Mon, 14 Mar 2022 20:30:51 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright year in new test > > core libs String.java changes look fine. Thanks @RogerRiggs I intend to push this soon regardless, but would appreciate an explicit review of the aarch64 changes from an aarch64 maintainer. ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From psoujany at in.ibm.com Tue Mar 15 11:33:30 2022 From: psoujany at in.ibm.com (Pasam Soujanya1) Date: Tue, 15 Mar 2022 11:33:30 +0000 Subject: Behavior change in the jar tool JDK11 vs JDK8. In-Reply-To: References: <42aca6b2-8282-469a-b897-00f4adde6a18@oracle.com> Message-ID: Basically, we have a customer who use the jar command to zip up data files generated in a directory, most of the time the files don't exist. With JDK11, the jar archive is not created, and they see their tests failing. Their tests were probably written to suit the JDK8 behavior. However, if this behavior introduced in JDK9 was intentional, I am good with it. Thank you for the advice! Thanks, Pasam Soujanya. ________________________________ From: Alan Bateman Sent: Tuesday, March 15, 2022 2:27 PM To: Pasam Soujanya1 Cc: core-libs-dev at openjdk.java.net ; forax at univ-mlv.fr Subject: [EXTERNAL] Re: Behavior change in the jar tool JDK11 vs JDK8. On 15/03/2022 08:18, Pasam Soujanya1 wrote: I tried "tar" with a target that does not exist, and the tar file got created successfully (with an error message about the missing file) and with the exit code 0 (success). Same behavior ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd On 15/03/2022 08:18, Pasam Soujanya1 wrote: I tried "tar" with a target that does not exist, and the tar file got created successfully (with an error message about the missing file) and with the exit code 0 (success). Same behavior is seen with JDK8 jar too. From JDK11 onward, the output jar isn't created and the exit code is 1(failure). So, to summarise: "jar" from Java 8 seems to be on the lines of "tar". Do we want to continue with this "jar" behaviour which is not the same as "tar" ? The behavior since JDK 9 is to delete the temporary file when there is an error. This looks to be the correct behavior. If it were changed back then people would complain that jar is leaving files behind when it fails. I'm curious how you run into this. Is this a script that runs with +e or doesn't check the exit status? -Alan From Alan.Bateman at oracle.com Tue Mar 15 12:09:14 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Mar 2022 12:09:14 +0000 Subject: Behavior change in the jar tool JDK11 vs JDK8. In-Reply-To: References: <42aca6b2-8282-469a-b897-00f4adde6a18@oracle.com> Message-ID: <06ef84d3-9a53-7107-4496-13b9769aeb33@oracle.com> On 15/03/2022 11:33, Pasam Soujanya1 wrote: > Basically, we have a customer who use the jar command to zip up data > files generated in a directory, most of the time the files don't exist. Can you confirm that the jar command is failing, meaning the exit code is non-0? The change in JDK 9 to remove the temporay file when jar fails was deliberate. Yes, it probably should have had a release note at the time. -Alan From erikj at openjdk.java.net Tue Mar 15 12:37:43 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Mar 2022 12:37:43 GMT Subject: RFR: JDK-8236128: Allow jpackage create installers for services In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 23:37:06 GMT, Alexey Semenyuk wrote: > Implementation of [JDK-8275062: "Allow jpackage create installers for services"](https://bugs.openjdk.java.net/browse/JDK-8275062) > CSR Build change looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7793 From aph-open at littlepinkcloud.com Tue Mar 15 12:59:28 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 15 Mar 2022 12:59:28 +0000 Subject: Should System.exit be controlled by a Scope Local? In-Reply-To: <924583af-919c-56b6-d875-a534f277aaed@oracle.com> References: <6f98a4ae-8fcb-d796-c4ae-3141b62fd833@littlepinkcloud.com> <9accb6b2-335b-8c5f-bc7d-afed4f6e6727@oracle.com> <68ea5542-0866-8583-938f-51b2f5512088@littlepinkcloud.com> <4074cee5-7f6d-889e-9343-52d4894f5961@littlepinkcloud.com> <92191c36-718b-94b8-db42-2d0306d4906a@littlepinkcloud.com> <924583af-919c-56b6-d875-a534f277aaed@oracle.com> Message-ID: <1f386a60-05b8-424b-85d7-a00e5571d3e8@littlepinkcloud.com> On 3/1/22 18:17, Sean Mullan wrote: > Can you explain in a little more detail as to what the compatibility > issues are with preventing threads in thread pools from calling System.exit? It is possible, I suppose, that some rather odd programmer is using a task in a thread pool to exit their program. I know, unlikely, but we preserve compatibility. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From psoujany at in.ibm.com Tue Mar 15 13:23:18 2022 From: psoujany at in.ibm.com (Pasam Soujanya1) Date: Tue, 15 Mar 2022 13:23:18 +0000 Subject: Behavior change in the jar tool JDK11 vs JDK8. In-Reply-To: <06ef84d3-9a53-7107-4496-13b9769aeb33@oracle.com> References: <42aca6b2-8282-469a-b897-00f4adde6a18@oracle.com> <06ef84d3-9a53-7107-4496-13b9769aeb33@oracle.com> Message-ID: Yes, jar command fails(exit code is 1) from JDK11 onward when target files do not exist while archiving the data. Please find the below jar execution with JDK11 $ jar -cvf sample.jar nofile.txt nofile.txt : no such file or directory added manifest $ echo $? 1 Could you please share any documentation if exists, with this behavior change. We couldn't find it in the release notes of 9,10,11. Thanks, Pasam Soujanya. ________________________________ From: Alan Bateman Sent: Tuesday, March 15, 2022 5:39 PM To: Pasam Soujanya1 Cc: core-libs-dev at openjdk.java.net Subject: [EXTERNAL] Re: Behavior change in the jar tool JDK11 vs JDK8. On 15/03/2022 11:33, Pasam Soujanya1 wrote: Basically, we have a customer who use the jar command to zip up data files generated in a directory, most of the time the files don't exist. ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd On 15/03/2022 11:33, Pasam Soujanya1 wrote: Basically, we have a customer who use the jar command to zip up data files generated in a directory, most of the time the files don't exist. Can you confirm that the jar command is failing, meaning the exit code is non-0? The change in JDK 9 to remove the temporay file when jar fails was deliberate. Yes, it probably should have had a release note at the time. -Alan From duke at openjdk.java.net Tue Mar 15 13:55:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 15 Mar 2022 13:55:40 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:27:29 GMT, Joe Darcy wrote: >> Improving the exception messages for out-of-supported-range array types. >> >> I'll update copyrights before pushing. > > 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/constant/ClassDesc.java line 185: > 183: netRank = Math.addExact(currentDepth, rank); > 184: if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS) { > 185: throw new IllegalArgumentException("rank: " + netRank + This?doesn?t?need to?use [Math.addExact](currentDepth,?rank), as currentDepth will?always be?in?[0,?255], and?rank?here is?confined to?[1,?231-1], so?it?s?possible to?check for?netRank?<?0 and?use?[Integer.toUnsignedString](netRank) (or?[Integer.toUnsignedLong](netRank) and?let [StringConcatFactory] deal?with?it): Suggestion: netRank = currentDepth + rank; if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS || netRank < 0) { throw new IllegalArgumentException("rank: " + Integer.toUnsignedLong(netRank) + [Integer.toUnsignedLong]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedLong(int) [Integer.toUnsignedString]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedString(int) [Math.addExact]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Math.html#addExact(int,int) [StringConcatFactory]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From duke at openjdk.java.net Tue Mar 15 13:55:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 15 Mar 2022 13:55:40 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: <4uQRE2eVYDoSGMKOavXQzlw2EE2-NvYs-GpnU--o2iw=.ee2229d2-6379-43ef-8239-db170a3d6973@github.com> References: <4uQRE2eVYDoSGMKOavXQzlw2EE2-NvYs-GpnU--o2iw=.ee2229d2-6379-43ef-8239-db170a3d6973@github.com> Message-ID: On Tue, 15 Mar 2022 07:50:29 GMT, Peter Levart 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/constant/ClassDesc.java line 179: > >> 177: int netRank; >> 178: if (rank <= 0) { >> 179: throw new IllegalArgumentException("rank " + rank + "is not a positive value"); > > There's a space missing in the IAE message after the rank number. For example, if rank == 0, the message would be: "rank 0is not positive value" ... Suggestion: throw new IllegalArgumentException("rank " + rank + " is not a positive value"); ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From zgu at openjdk.java.net Tue Mar 15 14:01:45 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Mar 2022 14:01:45 GMT Subject: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows In-Reply-To: References: Message-ID: <8FQ5EWRNt4AntXLp7E2jD4bQho0c1T73LUCBJgDPa8Q=.8e9dabc6-b560-4cac-bdec-7b8117c975c3@github.com> On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`. Friendly ping. May I have a second review, please! ------------- PR: https://git.openjdk.java.net/jdk/pull/7777 From Alan.Bateman at oracle.com Tue Mar 15 14:11:31 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Mar 2022 14:11:31 +0000 Subject: Behavior change in the jar tool JDK11 vs JDK8. In-Reply-To: References: <42aca6b2-8282-469a-b897-00f4adde6a18@oracle.com> <06ef84d3-9a53-7107-4496-13b9769aeb33@oracle.com> Message-ID: <5073d604-a3ce-904f-9c36-e8e439503297@oracle.com> On 15/03/2022 13:23, Pasam Soujanya1 wrote: > Yes, jar command fails(exit code is 1) from JDK11 onward when target > files do not exist while archiving the data. Can you check JDK 8u? I would expect the exit code to be non-0 with that release too, it's just that it leaves behind the file. That's the bug that was fixed in JDK 9 via JDK-8174996. -Alan From kevinb at google.com Tue Mar 15 14:09:06 2022 From: kevinb at google.com (Kevin Bourrillion) Date: Tue, 15 Mar 2022 07:09:06 -0700 Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: I did a subjective eval of 30 random usages of Math.PI in our codebase. I would repeat this in more detail if it were seen as useful. These usages really wanted -- * Math.toRadians (6) * Math.TAU (10) [usually, they are explicitly doubling it] * Math.PI (1) [some high-pass filter formula uses a bare pi] * subject to taste (13) By the last one, I mean that the more a person has read, understood, and agreed with the Tau Manifesto the more they would prefer to use TAU in that situation. For example, for code that's talking about rotating an image a "quarter-turn", or the angle measure in a rectangle, TAU / 4 is very natural. But what about clamping a longitude expressed in radians -- is it cleaner to think that the absolute value is less than (a) one halfturn (PI) or (b) one-half of a turn (TAU/2)? Who can say. I suppose that introducing a new cause for subjective arguments between teammates is no a small thing. But still, the 10-to-1 part sells it for me. Again, I could flesh this out if necessary. (On a side note, the real-world value for "they should just use to/fromRadians" will be *much* higher than this. We actually have static analyzers that have been trying to nag people into using those methods for years, so these 6/30 are just the ones we didn't catch.) On Mon, Mar 14, 2022 at 6:23 PM Kevin Bourrillion wrote: > On Mon, Mar 14, 2022 at 4:16 PM Joe Darcy wrote: > > Yes; after further thought, I agree having tau = 2.0*pi is preferable. >> > > Kinda reads like it's taking a stand on which of the two is the *real* > fundamental mathematical constant and which one is a hack. Therefore it > should really be pi that's set to tau/2.0 :-) > > Can PI have a @see link to this so that people know about it? > > (I'll just mention that {from,to}Radians would also benefit from some > advertisement, as a great many PI usages are dividing it by or into 180, > but do what thou wilt with that FYI.) > > > -- > Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com > -- Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com From alanb at openjdk.java.net Tue Mar 15 14:20:46 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 15 Mar 2022 14:20:46 GMT Subject: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7777 From zgu at openjdk.java.net Tue Mar 15 14:20:47 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Mar 2022 14:20:47 GMT Subject: RFR: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows In-Reply-To: References: Message-ID: <_yHv28ooiVthtupJFkhLsUWAKJZE-1CUJF3UgcJjqd0=.6c5de42e-b376-4003-bd60-cfbbf1e7b0bf@github.com> On Thu, 10 Mar 2022 19:46:28 GMT, Naoto Sato wrote: >> Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`. > > LGTM. Thanks, @naotoj @AlanBateman ------------- PR: https://git.openjdk.java.net/jdk/pull/7777 From zgu at openjdk.java.net Tue Mar 15 14:20:47 2022 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Tue, 15 Mar 2022 14:20:47 GMT Subject: Integrated: 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 18:40:13 GMT, Zhengyu Gu wrote: > Please review this small patch that fixes early `CHECK_NULL_RETURN` results not releasing native `jchar` array returned by `GetStringChars()`. This pull request has now been integrated. Changeset: 2cddf3f5 Author: Zhengyu Gu URL: https://git.openjdk.java.net/jdk/commit/2cddf3f5391518ea40796e6c4759047d51b7b312 Stats: 8 lines in 1 file changed: 2 ins; 3 del; 3 mod 8282887: Potential memory leak in sun.util.locale.provider.HostLocaleProviderAdapterImpl.getNumberPattern() on Windows Reviewed-by: naoto, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7777 From ecki at zusammenkunft.net Tue Mar 15 15:24:03 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 15 Mar 2022 15:24:03 +0000 Subject: Discussion about Java Floating Point? In-Reply-To: References: Message-ID: Please stop sending mails marked as urgent to a mailing list, you just make a fool of yourself. The need to round floating point numbers for commercial math (and the risk involved in doing so) is nothing new, it predates the IEEE standard and should be subject for even basic comp sci curriculums all over the world. (Having said that, automatic precision/rounding for number formats in C++ looks neat) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von A Z Gesendet: Dienstag, M?rz 15, 2022 5:24 AM An: core-libs-dev at openjdk.java.net Betreff: Discussion about Java Floating Point? To core-libs-dev at openjdk.java.net, In terms of floating point, it seems there are thus three (3) phenomena that are relevant. 1) Arithmetic on float and double, via operators. 2) Elementary function calls, namely those made from java.lang.StrictMath, as it is, on double values. 3) Comparison operators. ==, !=, >, <, >=,<=. Java floating point successfully has 3) the way required, even though other languages, particularly C++ , do not compare their floats and doubles through those comparison operators. The point at issue is Java although, so Java is satisfactory at point 3). My point of contention is that Java does not have 1) and 2) operating as they should, even though C++ and other languages do, in those two areas, namely C++: Martin has submitted the following: ?The following statement is not entirely true when using finite floating point precision: > (?snip?) It is a mathematical fact that, for > consistent, necessary and even fast term, 10% of 10% must > always precisely be 1%, and by no means anything else." /* #include using namespace std; int main() { cout << "Program has started..." << endl; double a = 0.1D; double b = 0.1D; double c = a*b; cout << endl << c << endl << endl; float d = 0.1F; float e = 0.1F; float f = d*e; cout << f << endl << endl; cout << "Program has Finished."; return 0; } */ /* Program has started... 0.01 0.01 Program has Finished. */ This is actually not fully or finally true, including SSE, SSE algorithm logic and further. The included C++ example of mine above here disproves this. Even though I do contextually admit these answers can only work within the range of the involved types, it is still actually the case that 10% of 10% can and always precisely be 1%, within the range of the type used, and by no means anything else. Because of the laws of decimal arithmetic. See https://en.wikipedia.org/wiki/Floating-point_arithmetic and the starting sentence: 'In computing, floating-point arithmetic (FP) is arithmetic using formulaic representation of real numbers as an approximation to support a trade-off betwee range and precision.' However, it simply isn't the case that reduced precision has to exist inside the range, certainly not any more. Rationally, one would have to think, with the present SSE support in ubiquity, and the preimplementation that is possible and already around elsewhere, that this kind of tradeoff in floating point isn't any kind of use or advantage any more. This is part of the issue with Java and the OpenJDK at this time, and I am trying to contend that this should be changed, either at default or in some mutual compatibility mode. The other part is java.lang.StrictMath, since it generates denormal and pronormal values on its own, also. Raffaello has stated: To summarize, Java uses IEEE 754 binary arithmetic as by specification, as do most other languages, including C/C++. It is however fundamentally wrong to use binary floating-point arithmetic to emulate decimal behavior. Also, pay attention to the output routines that convert float and double values to a decimal representation. Usually, C and C++ will have information loss by default, as in your case. What we and others are beginning to need to happen, in detailed Java 2D and 3D (JMonkeyEngine 3.5) projects, and more widely again, is that Java floating point arithmetic and function behaviour, on float and double, within their ranges, do need to perfectly match decimal behaviour. C++ arithmetic, at least, has had no problem using floating point arithmetic, at least, to emulate decimal behaviour. I am trying to prove the opposite to Raffaello's statements, that floating point can and indeed must represent decimal behaviour. Output functions in any language that alter the appearance of the float or double value become irrelevant, because the only relevant factor is the operator behaviour and the innate, representation viewpoint of those float or double values. In contrast to Raffaelo, we assert that Java SE and OpenJDK floating point must be changed so that it upholds base ten (10) arithmetic, algebra,and elementary functions on real value arguments within the ranges of double and/or float. Alongside a calculator class that upholds the same. These are in keeping with the Wikipedia view on floating point arithmetic that I quoted earlier, but more than that, they are in keeping with the standards/specifications of Mathematics, and not just an idea that grew in computer science. I wish to still request that this matter be pursued, despite Java's stance on this matter, in terms of the JRE for a very long time now. While it is the case that JDK-8190991 does exist, and should continue, JDK-8190947 has been too blithely swept away. See: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190947 The explanation 'Closing this enhancement as will not fix' does nothing to explain why the advantages of floating point repair have been turned away, and in fact, not apprehended specifically in Java. Is there someone who can look deeper into this matter, and implement arithmetic and Calculator class changes for the next release version of SE and OpenJDK? From darcy at openjdk.java.net Tue Mar 15 16:09:29 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 16:09:29 GMT Subject: RFR: JDK-8283143: Use minimal-length literals to initialize PI and E constants [v2] In-Reply-To: References: Message-ID: > Depending on the range of the number line, a double value has between 15 and 17 digits of decimal precision. The literals used to initialize Math.PI and Math.E have several digits more precision than that maximum. > > That is potentially confusing to readers of the code and the minimum length strings to exactly represent the value in question should be used instead. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Update copyright. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7814/files - new: https://git.openjdk.java.net/jdk/pull/7814/files/3bf9de9f..f4c0e63e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7814&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7814&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7814.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7814/head:pull/7814 PR: https://git.openjdk.java.net/jdk/pull/7814 From darcy at openjdk.java.net Tue Mar 15 16:09:29 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 16:09:29 GMT Subject: Integrated: JDK-8283143: Use minimal-length literals to initialize PI and E constants In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 01:36:14 GMT, Joe Darcy wrote: > Depending on the range of the number line, a double value has between 15 and 17 digits of decimal precision. The literals used to initialize Math.PI and Math.E have several digits more precision than that maximum. > > That is potentially confusing to readers of the code and the minimum length strings to exactly represent the value in question should be used instead. This pull request has now been integrated. Changeset: 671b6efd Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/671b6efd6126384c0630d1cd84f53f52995e68d8 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod 8283143: Use minimal-length literals to initialize PI and E constants Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/7814 From smarks at openjdk.java.net Tue Mar 15 16:12:47 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 15 Mar 2022 16:12:47 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v17] In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 01:26:24 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > make changes proposed OK, I ran our test suite and found that SplittableRandomTest failed. Please merge in the fix from the latest commit on this branch: https://github.com/stuart-marks/jdk/commits/pull/7001 With this fix in place I get a clean test run. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From darcy at openjdk.java.net Tue Mar 15 16:18:27 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 16:18:27 GMT Subject: RFR: JDK-8283124: Add constant for tau to Math and StrictMath [v3] In-Reply-To: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: > Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 Joe Darcy 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-8283124 - Set value with 2.0 * PI. - JDK-8283124: Add constant for tau to Math and StrictMath ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7813/files - new: https://git.openjdk.java.net/jdk/pull/7813/files/0fae656a..0cd1f61e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7813&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7813&range=01-02 Stats: 1563 lines in 66 files changed: 1059 ins; 268 del; 236 mod Patch: https://git.openjdk.java.net/jdk/pull/7813.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7813/head:pull/7813 PR: https://git.openjdk.java.net/jdk/pull/7813 From darcy at openjdk.java.net Tue Mar 15 16:25:45 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 16:25:45 GMT Subject: Integrated: JDK-8283124: Add constant for tau to Math and StrictMath In-Reply-To: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> References: <-hKfGqZMKP7vf69ks3aOR1OvrdG6n07rJJA_m3uWE3M=.ed1dcf33-0721-4a46-9f0c-a9c5a7e743ed@github.com> Message-ID: On Mon, 14 Mar 2022 20:52:39 GMT, Joe Darcy wrote: > Add a constant for tau, 2*pi, to Math and StrictMath. Since 2*pi is a very common value in mathematical formulas, it is helpful to give it a distinct constant. > > Please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283136 This pull request has now been integrated. Changeset: 05a83e03 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/05a83e03ca35b4885b48bb0e7d188baf8f7d9d7f Stats: 29 lines in 2 files changed: 26 ins; 0 del; 3 mod 8283124: Add constant for tau to Math and StrictMath Reviewed-by: bpb, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7813 From iklam at openjdk.java.net Tue Mar 15 17:08:27 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 15 Mar 2022 17:08:27 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v8] In-Reply-To: References: Message-ID: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Avoid memset twice in os::malloc(); added comments about NMTPreInit::handle_malloc vs DumpSharedSpaces ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7748/files - new: https://git.openjdk.java.net/jdk/pull/7748/files/cd934f3c..f202bcbf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7748&range=06-07 Stats: 7 lines in 1 file changed: 5 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7748.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7748/head:pull/7748 PR: https://git.openjdk.java.net/jdk/pull/7748 From darcy at openjdk.java.net Tue Mar 15 17:13:27 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 17:13:27 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v3] In-Reply-To: References: Message-ID: > Improving the exception messages for out-of-supported-range array types. > > I'll update copyrights before pushing. Joe Darcy 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: - Update copyright and fix typo. - Merge branch 'master' into JDK-8283075 - Respond to review feedback. - Appease jcheck - Update @bug line of test - JDK-8283075: Bad `IllegalArgumentException` message when calling `ClassDesc.arrayType(int)` which results in a rank > 255 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7812/files - new: https://git.openjdk.java.net/jdk/pull/7812/files/1723d710..514a57a1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7812&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7812&range=01-02 Stats: 1594 lines in 67 files changed: 1085 ins; 268 del; 241 mod Patch: https://git.openjdk.java.net/jdk/pull/7812.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7812/head:pull/7812 PR: https://git.openjdk.java.net/jdk/pull/7812 From darcy at openjdk.java.net Tue Mar 15 17:13:29 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 17:13:29 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: References: <4uQRE2eVYDoSGMKOavXQzlw2EE2-NvYs-GpnU--o2iw=.ee2229d2-6379-43ef-8239-db170a3d6973@github.com> Message-ID: On Tue, 15 Mar 2022 13:50:03 GMT, ExE Boss wrote: >> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 179: >> >>> 177: int netRank; >>> 178: if (rank <= 0) { >>> 179: throw new IllegalArgumentException("rank " + rank + "is not a positive value"); >> >> There's a space missing in the IAE message after the rank number. For example, if rank == 0, the message would be: "rank 0is not positive value" ... > > Suggestion: > > throw new IllegalArgumentException("rank " + rank + " is not a positive value"); Good catch; will fix before pushing. ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From darcy at openjdk.java.net Tue Mar 15 17:13:30 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 17:13:30 GMT Subject: RFR: JDK-8283075: Bad IllegalArgumentException message when calling ClassDesc.arrayType(int) which results in a rank > 255 [v2] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 13:49:34 GMT, ExE Boss 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/constant/ClassDesc.java line 185: > >> 183: netRank = Math.addExact(currentDepth, rank); >> 184: if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS) { >> 185: throw new IllegalArgumentException("rank: " + netRank + > > This?doesn?t?need to?use [Math.addExact](currentDepth,?rank), as currentDepth will?always be?in?[0,?255], and?rank?here is?confined to?[1,?231-1], so?it?s?possible to?check for?netRank?<?0 and?use?[Integer.toUnsignedString](netRank) (or?[Integer.toUnsignedLong](netRank) and?let [StringConcatFactory] deal?with?it): > > Suggestion: > > netRank = currentDepth + rank; > if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS || netRank < 0) { > throw new IllegalArgumentException("rank: " + Integer.toUnsignedLong(netRank) + > > > [Integer.toUnsignedLong]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedLong(int) > [Integer.toUnsignedString]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedString(int) > [Math.addExact]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Math.html#addExact(int,int) > [StringConcatFactory]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html Hmm. In this context, I think using addExact is clearer regarding the intention of the check. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From duke at openjdk.java.net Tue Mar 15 17:30:47 2022 From: duke at openjdk.java.net (liach) Date: Tue, 15 Mar 2022 17:30:47 GMT Subject: RFR: 8283075: Bad IllegalArgumentException message for out of range rank from ClassDesc.arrayType(int) [v2] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 17:09:03 GMT, Joe Darcy wrote: >> src/java.base/share/classes/java/lang/constant/ClassDesc.java line 185: >> >>> 183: netRank = Math.addExact(currentDepth, rank); >>> 184: if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS) { >>> 185: throw new IllegalArgumentException("rank: " + netRank + >> >> This?doesn?t?need to?use [Math.addExact](currentDepth,?rank), as currentDepth will?always be?in?[0,?255], and?rank?here is?confined to?[1,?231-1], so?it?s?possible to?check for?netRank?<?0 and?use?[Integer.toUnsignedString](netRank) (or?[Integer.toUnsignedLong](netRank) and?let [StringConcatFactory] deal?with?it): >> >> Suggestion: >> >> netRank = currentDepth + rank; >> if (netRank > ConstantUtils.MAX_ARRAY_TYPE_DESC_DIMENSIONS || netRank < 0) { >> throw new IllegalArgumentException("rank: " + Integer.toUnsignedLong(netRank) + >> >> >> [Integer.toUnsignedLong]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedLong(int) >> [Integer.toUnsignedString]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Integer.html#toUnsignedString(int) >> [Math.addExact]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Math.html#addExact(int,int) >> [StringConcatFactory]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/StringConcatFactory.html > > Hmm. In this context, I think using addExact is clearer regarding the intention of the check. Thanks. Notice the overflow case is already handled by the `ArithmeticException` caught in the larger try block. ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From darcy at openjdk.java.net Tue Mar 15 17:37:53 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 15 Mar 2022 17:37:53 GMT Subject: Integrated: 8283075: Bad IllegalArgumentException message for out of range rank from ClassDesc.arrayType(int) In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 19:56:17 GMT, Joe Darcy wrote: > Improving the exception messages for out-of-supported-range array types. > > I'll update copyrights before pushing. This pull request has now been integrated. Changeset: 32f8437d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/32f8437d85a003914d5ca35bdddebdc732ab222d Stats: 35 lines in 2 files changed: 28 ins; 0 del; 7 mod 8283075: Bad IllegalArgumentException message for out of range rank from ClassDesc.arrayType(int) Reviewed-by: vromero, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7812 From xliu at openjdk.java.net Tue Mar 15 18:02:46 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 15 Mar 2022 18:02:46 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 08:33:36 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Change growOnly to maybeLatin. > > This patch also copys over the attribute from the other AbstractStringBuilder. > Add a unit test to cover methods which cause maybeLatin1 becomes true. @cl4es, Could you take a look at this PR? thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From valeriep at openjdk.java.net Tue Mar 15 20:40:45 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 20:40:45 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:18:56 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update again and undo DSA changes > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 101: > >> 99: // set default key sizes and apply our own algorithm-specific limits >> 100: // override lower limit to disallow unsecure keys being generated >> 101: // override upper limit to deter DOS attack > > Not a P11 expert, but I assume `algorithm` here is already guaranteed to be in uppercase? Yes, for P11KeyPairGenerator, its algorithm values are all in uppercase. I verified it with an existing regression test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Tue Mar 15 20:47:47 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 20:47:47 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: On Mon, 14 Mar 2022 21:24:15 GMT, Weijun Wang wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Update again and undo DSA changes > > src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 122: > >> 120: default -> { >> 121: throw new ProviderException >> 122: ("Unrecognized algorithm for checking key size"); > > If it's an unknown key algorithm, is it possible we just ignore it and keep using `minKeyLen` and `maxKeyLen`? Well, instead of ignore unknown key algorithm, perhaps safer to throw Exception so it can be caught and handled during develop time. P11KeyPairGenerator class is only used for known algorithms which it is registered for, so probably ok to go either way. I'd prefer to play it safe and force a review of this block of code when new algorithm is added. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Tue Mar 15 20:51:25 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 15 Mar 2022 20:51:25 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Removed NPE from the catch statement. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/48f562ab..c8ae1655 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From rriggs at openjdk.java.net Tue Mar 15 21:11:31 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 15 Mar 2022 21:11:31 GMT Subject: RFR: JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder [v2] In-Reply-To: References: Message-ID: > Quoting related changes in https://bugs.openjdk.java.net/browse/JDK-8250568 modified the way that > process builder recognized argument strings, causing some arguments to be doubly quoted and malformed. > > ProcessBuilder encodes command arguments in two ways, a looser legacy encoding > and stricter encoding that prevents quotes from being misinterpreted. > The system property jdk.lang.Process.allowAmbiguousCommands controls which is in effect. > > When the property is "true" or not set, arguments are inserted into the Windows command line > with minimal changes. Arguments containing space or tab are quoted to prevent them being split. > Arguments that start and end with double-quote are left alone. > Some executables interpret a backslash before the final quote as an escape; if the argument > contains first and last quotes, backslashes are ignored. > > When the allowAmbigousCommands property is `false`, care is taken to ensure that > the final quote of an argument is the closing quote for the argument and is not > interpreted as a literal quote by a preceding quote (or an odd number of quotes). > > The PR includes a test matrix of the cases where an argument with spaces and a final backslash > is passed with each combination of `allowAmbiguousCommands = true and false`, > launched executable, java, .cmd, and .vbs and when the argument is surrounded with double-quotes. > > The priority for allowAmbiguousCommands = false is that no argument is split or joined to another argument. > In some cases, backslashes are doubled to prevent a double-quote from being interpreted incorrectly. > The trailing backslash in an argument occurs rarely exception when the argument is a directory. > In that case, the addition of trailing backslashes is benign when the string is used as a filesystem path. > > See also PR#7504, for background and a proposal. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Refactored ArgCheck test to be more readable and easier to maintain and backport ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7709/files - new: https://git.openjdk.java.net/jdk/pull/7709/files/a194e439..7db92baf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7709&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7709&range=00-01 Stats: 164 lines in 1 file changed: 37 ins; 42 del; 85 mod Patch: https://git.openjdk.java.net/jdk/pull/7709.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7709/head:pull/7709 PR: https://git.openjdk.java.net/jdk/pull/7709 From mikael at openjdk.java.net Tue Mar 15 21:33:40 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Tue, 15 Mar 2022 21:33:40 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt wrote: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. > > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Adding hotspot-runtime to get some more eyes on this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From duke at openjdk.java.net Tue Mar 15 23:05:55 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Tue, 15 Mar 2022 23:05:55 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 Message-ID: As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL). In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. ### Alternatives It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. ### Testing This change has been tested on AIX and Linux/x86. ------------- Commit messages: - Extract memory error logic to helper procedure - Updates copyright year and adds bug-id to test - Addresses NullClassBytesTest Failure Changes: https://git.openjdk.java.net/jdk/pull/7829/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7829&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283225 Stats: 43 lines in 2 files changed: 20 ins; 0 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/7829.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7829/head:pull/7829 PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Tue Mar 15 23:18:24 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Tue, 15 Mar 2022 23:18:24 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v18] In-Reply-To: References: Message-ID: > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: Fix SplittableRandomTest. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/53c651f1..406e2bc8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=16-17 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Tue Mar 15 23:18:26 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Tue, 15 Mar 2022 23:18:26 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v17] In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 01:26:24 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > make changes proposed Merge done ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From ccheung at openjdk.java.net Tue Mar 15 23:43:52 2022 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 15 Mar 2022 23:43:52 GMT Subject: RFR: 8253495: CDS generates non-deterministic output [v8] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 17:08:27 GMT, Ioi Lam wrote: >> This patch makes the result of "java -Xshare:dump" deterministic: >> - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp >> - Fixed a problem in hashtable ordering in heapShared.cpp >> - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. >> - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh >> >> Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). >> >> Testing under way: >> - tier1~tier5 >> - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Avoid memset twice in os::malloc(); added comments about NMTPreInit::handle_malloc vs DumpSharedSpaces Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From redestad at openjdk.java.net Tue Mar 15 23:51:47 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 15 Mar 2022 23:51:47 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 08:33:36 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Change growOnly to maybeLatin. > > This patch also copys over the attribute from the other AbstractStringBuilder. > Add a unit test to cover methods which cause maybeLatin1 becomes true. Code changes look ok overall. We might inflate instance size of `StringBuilder`s a bit (could be examined via https://openjdk.java.net/projects/code-tools/jol/), but since SBs are typically short-lived entities I'm not too concerned about a few extra bytes here. The microbenchmark needs a small refactoring to avoid running micros that don't care about the newly added `MIXED_SIZE` `@Param` multiple times. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 540: > 538: } > 539: StringUTF16.putCharSB(value, index, ch); > 540: maybeLatin1 = true; Only possible if `StringLatin1.canEncode(ch) == true` (and strictly speaking if the char at `index` is not latin1-encodable). Considering the overheads of adding a test it might be preferable to be conservative and just always mark it as a "maybe" like you do, though. src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1008: > 1006: this.count = newCount; > 1007: putStringAt(start, str); > 1008: if (end - start > 0) { regardless of value of `end - start` you could also skip setting `maybeLatin1 = true` if: - `str.coder() == UTF16` - `this.coder == LATIN1` test/micro/org/openjdk/bench/java/lang/StringBuilders.java line 208: > 206: } > 207: > 208: @Param({"128", "256", "1024"}) I think adding this parameter at this level means all other benchmarks will now be redundantly run once per different value for MIXED_SIZE. You can avoid this by refactor this parameter and the associated Benchmark into subclass. ------------- Changes requested by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7671 From ihse at openjdk.java.net Tue Mar 15 23:50:20 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Mar 2022 23:50:20 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into shuffle-data-reborn - Fix merge - Merge tag 'jdk-19+13' into shuffle-data-reborn Added tag jdk-19+13 for changeset 5df2a057 - Move characterdata templates to share/classes/java/lang. - Update comment refering to "make" dir - Move new symbols to jdk.compiler - Merge branch 'master' into shuffle-data - Move macosxicons from share to macosx - Move to share/data, and move jdwp.spec to java.se - Update references in test - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f ------------- Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05 Stats: 85 lines in 1695 files changed: 4 ins; 1 del; 80 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Tue Mar 15 23:50:22 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Mar 2022 23:50:22 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v5] In-Reply-To: References: Message-ID: On Mon, 18 Jan 2021 13:47:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Move characterdata templates to share/classes/java/lang. This PR was almost ready to merge, but unfortunately got closed about a year ago when I disappeared on medical leave. :-( I've been putting off coming back to to this, worried that the merge conflicts would be bad. But no! Git handled the merge fantastically well; the default merge mode even realized that new files in a directory which had been moved elsewhere should probably also be moved to the same place. I was pleasantly surprised how easy this was. Nevertheless, I have carefully studied the automatic merge for any signs or mistakes. I only found one: a single renamed file (blacklist -> blocked) that it failed to match. So I believe this PR is back in the same integrateable state that it was when I left it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Tue Mar 15 23:59:55 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Mar 2022 23:59:55 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues. I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR. I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively). I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228. There were two open questions: * should jdwp.spec belong to specs directory instead of data * should bin/idea.sh be changed to exclude data but they sounded so exploratory that I decided not to open JBS issues for them. @wangweij @naotoj @prrace @erikj79 @jonathan-gibbons You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping) ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From weijun at openjdk.java.net Wed Mar 16 00:16:50 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 16 Mar 2022 00:16:50 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v5] In-Reply-To: References: Message-ID: <5LsStIDKZnRP4PyIE5dShT-XezKK-91XEglZ99DypvQ=.b9b15bd7-b7c0-4923-a26c-dc4ad331c757@github.com> On Tue, 15 Mar 2022 20:44:20 GMT, Valerie Peng wrote: >> src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyPairGenerator.java line 122: >> >>> 120: default -> { >>> 121: throw new ProviderException >>> 122: ("Unrecognized algorithm for checking key size"); >> >> If it's an unknown key algorithm, is it possible we just ignore it and keep using `minKeyLen` and `maxKeyLen`? > > Well, instead of ignore unknown key algorithm, perhaps safer to throw Exception so it can be caught and handled during develop time. P11KeyPairGenerator class is only used for known algorithms which it is registered for, so probably ok to go either way. I'd prefer to play it safe and force a review of this block of code when new algorithm is added. OK. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Wed Mar 16 00:33:43 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 16 Mar 2022 00:33:43 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v6] In-Reply-To: References: Message-ID: <6V_3NdKeibCcMiNw0PQEzKU-fhEytrR08Ckb_taEXkM=.c4af0ad3-697f-4515-bc66-42899ec68cb6@github.com> On Tue, 15 Mar 2022 20:51:25 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Removed NPE from the catch statement. Could you please please review CSR at: https://bugs.openjdk.java.net/browse/JDK-8282995 Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From darcy at openjdk.java.net Wed Mar 16 00:42:05 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Mar 2022 00:42:05 GMT Subject: RFR: JDK-8283230: Improve @jls usage in ElementType Message-ID: Improve some semantic links into JLS with actual links. ------------- Commit messages: - JDK-8283230: Improve @jls usage in ElementType Changes: https://git.openjdk.java.net/jdk/pull/7831/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7831&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283230 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7831.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7831/head:pull/7831 PR: https://git.openjdk.java.net/jdk/pull/7831 From jjg at openjdk.java.net Wed Mar 16 00:42:06 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Wed, 16 Mar 2022 00:42:06 GMT Subject: RFR: JDK-8283230: Improve @jls usage in ElementType In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 00:33:57 GMT, Joe Darcy wrote: > Improve some semantic links into JLS with actual links. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7831 From iris at openjdk.java.net Wed Mar 16 01:08:36 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 16 Mar 2022 01:08:36 GMT Subject: RFR: JDK-8283230: Improve @jls usage in ElementType In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 00:33:57 GMT, Joe Darcy wrote: > Improve some semantic links into JLS with actual links. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7831 From poweruserm at live.com.au Wed Mar 16 01:11:43 2022 From: poweruserm at live.com.au (A Z) Date: Wed, 16 Mar 2022 01:11:43 +0000 Subject: Java float, double, StrictMath correction? Message-ID: To core-libs-dev at openjdk.java.net, float and double should be mutually enhanced or defaultedly changed, to uphold the following three properties: 1) Base ten arithmetic on float and double, via operators. 2) Base Ten elementary function calls, like those made on java.lang.StrictMath, on double or float values. 3) Base ten Comparison operators. ==, !=, >, <, >=,<=. Martin has said: 'It is inherently, mathematically *impossible* to emulate decimal behaviour with binary IEEE 754 arithmetic. That's why Java also offers java.math.BigDecimal, a decimal floating-point library implemented in software.' Then don't use IEEE 754 alone! Or, have a dual mode, with an active alternative. There are binary alternatives, particularly that include the likes of SSE, that in fact can. The only standards necessary, and really, the 'authoritative standard', are those prevalent in mathematics itself. Base 10 arithmetic, algebra, elementary functions, range limited real values. BigDecimal, BigInteger, and https://github.com/eobermuhlner big-math, with its calculator class, take up more room in memory than necessary. They are slower, and they do not allow for the use of operators. Worse yet, they are not immediately reified in the rest of the language, ie all class and interface libraries. Raffaello has said: 'Exact representation of 0.1 using base 2 is mathematically impossible, no matter the language (it is a periodic number in base 2).' Consideration of the article: https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf Which is admittedly older, but still accurate, indicates otherwise. I contend that within an upper and lower range, that it is possible. While C++ can't use the immediate ==, !=, >,<,>=,<= operators immediately accurately, Java has. Using 32 or 64 bit buffers, and an SSE or similar buffer, and the right algorithms, unto limited range, you can have as much of a range representation as required for float or double, even though you ultimately don't have 'exact' representation. Bernd Eckenfels has said: 'The need to round floating point numbers for commercial math (and the risk involved in doing so) is nothing new, it predates the IEEE standard and should be subject for even basic comp sci curriculums all over the world.' That is true, but it is the case that range termination of decimal values, by means of truncation, is more accurate than this. By any processing of rounding, you start gaining inaccuracy, which can grow and grow and overpopulate the entire number. In Computer Programming, you can need range continuous range accuracy. Such as with 2D and 3D processing. The present Java approach is slower and a waste of memory. Given all this, and given that humans, and representations of the real world rely on base 10 first, shouldn't the 3 properties I outlined at the beginning of my post be at least mutually, compatibly, instituted in Java, if not defaultedly? From darcy at openjdk.java.net Wed Mar 16 02:05:43 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Mar 2022 02:05:43 GMT Subject: Integrated: JDK-8283230: Improve @jls usage in ElementType In-Reply-To: References: Message-ID: <-jrPKS3TF7ylJCkco-8MVxXwVAi4D8JJXT5Sk4wbgoY=.128b5ce3-0e14-44e9-84ff-93c20ba917a4@github.com> On Wed, 16 Mar 2022 00:33:57 GMT, Joe Darcy wrote: > Improve some semantic links into JLS with actual links. This pull request has now been integrated. Changeset: 4df24c5d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/4df24c5df38eeacc73097f71383916e9a0933839 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8283230: Improve @jls usage in ElementType Reviewed-by: jjg, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7831 From smarks at openjdk.java.net Wed Mar 16 02:28:45 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 16 Mar 2022 02:28:45 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v18] In-Reply-To: References: Message-ID: <5B673rFwqBB_x6v9jM9FxhCY12HX4dEIP3dhENKThmk=.f7f8c15e-84aa-4e9e-b23d-368e2f08d393@github.com> On Tue, 15 Mar 2022 23:18:24 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Fix SplittableRandomTest. Marked as reviewed by smarks (Reviewer). OK, thanks. I've moved the CSR to the "finalized" where it's awaiting approval. Shouldn't be more than a day or two. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From darcy at openjdk.java.net Wed Mar 16 03:08:57 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Mar 2022 03:08:57 GMT Subject: RFR: JDK-8283234: Improve @jls usage in java.base Message-ID: Checking the java.bases sources revealed a number of other instances where conceptual links into the JLS (or JVMS) could be upgraded to actual links. ------------- Commit messages: - JDK-8283234: Improve @jls usage in java.base Changes: https://git.openjdk.java.net/jdk/pull/7834/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7834&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283234 Stats: 21 lines in 5 files changed: 0 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/7834.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7834/head:pull/7834 PR: https://git.openjdk.java.net/jdk/pull/7834 From iklam at openjdk.java.net Wed Mar 16 03:17:42 2022 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 16 Mar 2022 03:17:42 GMT Subject: Integrated: 8253495: CDS generates non-deterministic output In-Reply-To: References: Message-ID: On Tue, 8 Mar 2022 19:11:02 GMT, Ioi Lam wrote: > This patch makes the result of "java -Xshare:dump" deterministic: > - Disabled new Java threads from launching. This is harmless. See comments in jvm.cpp > - Fixed a problem in hashtable ordering in heapShared.cpp > - BasicHashtableEntry has a gap on 64-bit platforms that may contain random bits. Added code to zero it. > - Enabled checking of $JAVA_HOME/lib/server/classes.jsa in make/scripts/compare.sh > > Note: $JAVA_HOME/lib/server/classes_ncoops.jsa is still non-deterministic. This will be fixed in [JDK-8282828](https://bugs.openjdk.java.net/browse/JDK-8282828). > > Testing under way: > - tier1~tier5 > - Run all *-cmp-baseline jobs 20 times each (linux-aarch64-cmp-baseline, windows-x86-cmp-baseline, .... etc). This pull request has now been integrated. Changeset: de4f04cb Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/de4f04cb71a26ce03b96460cb8d1c1e28cd1ed38 Stats: 100 lines in 15 files changed: 69 ins; 9 del; 22 mod 8253495: CDS generates non-deterministic output Reviewed-by: erikj, kbarrett, ccheung, ihse ------------- PR: https://git.openjdk.java.net/jdk/pull/7748 From iris at openjdk.java.net Wed Mar 16 05:23:51 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 16 Mar 2022 05:23:51 GMT Subject: RFR: JDK-8283234: Improve @jls usage in java.base In-Reply-To: References: Message-ID: <7PJmzA1MYf34d96HM00g6nA4Vz2u3Q6vYvuh7lXPM_4=.3216d529-ae9b-4f32-9893-2b1b2d906d8c@github.com> On Wed, 16 Mar 2022 03:03:23 GMT, Joe Darcy wrote: > Checking the java.bases sources revealed a number of other instances where conceptual links into the JLS (or JVMS) could be upgraded to actual links. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7834 From poweruserm at live.com.au Wed Mar 16 05:47:40 2022 From: poweruserm at live.com.au (A Z) Date: Wed, 16 Mar 2022 05:47:40 +0000 Subject: Java floating point and StrictMath improvement? Message-ID: To core-libs-dev at openjdk.java.net, float and double should be mutually enhanced or defaultedly changed, to uphold the following three properties: 1) Base ten arithmetic on float and double, via operators. 2) Base Ten elementary function calls, like those made on java.lang.StrictMath, on double or float values. 3) Base ten Comparison operators. ==, !=, >, <, >=,<=. Martin has said: 'It is inherently, mathematically *impossible* to emulate decimal behaviour with binary IEEE 754 arithmetic. That's why Java also offers java.math.BigDecimal, a decimal floating-point library implemented in software.' Then don't use IEEE 754 alone! Or, have a dual mode, with an active alternative. There are binary alternatives, particularly that include the likes of SSE, that in fact can. The only standards necessary, and really, the 'authoritative standard', are those prevalent in mathematics itself. Base 10 arithmetic, algebra, elementary functions, range limited real values. BigDecimal, BigInteger, and https://github.com/eobermuhlner big-math, with its calculator class, take up more room in memory than necessary. They are slower, and they do not allow for the use of operators. Worse yet, they are not immediately reified in the rest of the language, ie all class and interface libraries. Raffaello has said: 'Exact representation of 0.1 using base 2 is mathematically impossible, no matter the language (it is a periodic number in base 2).' Consideration of the article: https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf Which is admittedly older, but still accurate, indicates otherwise. I contend that within an upper and lower range, that it is possible. While C++ can't use the immediate ==, !=, >,<,>=,<= operators immediately accurately, Java has. Using 32 or 64 bit buffers, and an SSE or similar buffer, and the right algorithms, unto limited range, you can have as much of a range representation as required for float or double, even though you ultimately don't have 'exact' representation. Bernd Eckenfels has said: 'The need to round floating point numbers for commercial math (and the risk involved in doing so) is nothing new, it predates the IEEE standard and should be subject for even basic comp sci curriculums all over the world.' That is true, but it is the case that range termination of decimal values, by means of truncation, is more accurate than this. By any processing of rounding, you start gaining inaccuracy, which can grow and grow and overpopulate the entire number. In Computer Programming, you can need range continuous range accuracy. Such as with 2D and 3D processing. The present Java approach is slower and a waste of memory. Given all this, and given that humans, and representations of the real world rely on base 10 first, shouldn't the 3 properties I outlined at the beginning of my post be at least mutually, compatibly, instituted in Java, if not defaultedly? From Alan.Bateman at oracle.com Wed Mar 16 06:31:24 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Mar 2022 06:31:24 +0000 Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> Magnus, This proposal does not address the previous concerns. As before, you are proposing to put the data files used to generate the classes for jdk.localedata and jdk.charsets into src/java.base and I don't think we should do that. I really think this PR needs to be withdraw n or closed until there is at least some agreement on placement. I know you want to get the files moved out of the make tree but there are many issues to work through before that can happen. -Alan On 15/03/2022 23:59, Magnus Ihse Bursie wrote: > On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: > >>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >>> >>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >>> >>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >>> >>> ### Modules reviewed >>> >>> - [x] java.base >>> - [x] java.desktop >>> - [x] jdk.compiler >>> - [x] java.se >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into shuffle-data-reborn >> - Fix merge >> - Merge tag 'jdk-19+13' into shuffle-data-reborn >> >> Added tag jdk-19+13 for changeset 5df2a057 >> - Move characterdata templates to share/classes/java/lang. >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f > I have carefully reviewed all PR comments, and the changes I made in response to them. I believe I have resolved all requests from reviewers. What remained to do was to create an informational JEP about the new source structure, and file some follow-up issues. > > I have now created and submitted a new informational JEP ("JDK Source Structure"), available at https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this JEP, it felt increasingly silly to just copy and extend the part about src/$MODULE from JEP 201, so I extended it to cover a relevant overview of the entire JDK source base structure. I actually think this JEP has a good merit on its own, notwithstanding it being a reviewer requirement for this PR. > > I have also filed follow up issues for the non-standard jdk.hotspot.agent `doc` and `test` directories (https://bugs.openjdk.java.net/browse/JDK-8283197 and https://bugs.openjdk.java.net/browse/JDK-8283198, respectively). > > I have filed a follow up issue for continued efforts to clean up charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228. > > There were two open questions: > > * should jdwp.spec belong to specs directory instead of data > * should bin/idea.sh be changed to exclude data > > but they sounded so exploratory that I decided not to open JBS issues for them. > > @wangweij @naotoj @prrace @erikj79 @jonathan-gibbons You have all approved this PR at an older revision. Can you please reconfirm that your approval stands for the latest revision? (Sorry for the mass ping) > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/1611 From smarks at openjdk.java.net Wed Mar 16 06:51:49 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 16 Mar 2022 06:51:49 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v34] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Sat, 12 Mar 2022 01:35:23 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refine test > what I worried is, the boundary this is based on the current table size calculating mechanic in HashMap. > If people change the mechanic in HashMap, then the boundary would change. > But well, this is a white box text for HashMap (and HashMap-like) classes after all, so maybe I'm just over overthinking too much. Yes, the boundary conditions are sensitive to the exact calculation used for table sizing. If the calculation changes, the boundary results will most likely change, and the test will fail. But that's ok since this is a whitebox test. In any case, changes look good, and I've run this through our internal build/test system and the results are good. Ready to integrate! ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7431 From smarks at openjdk.java.net Wed Mar 16 06:54:55 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 16 Mar 2022 06:54:55 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v18] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:18:24 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > Fix SplittableRandomTest. src/java.base/share/classes/java/util/Random.java line 320: > 318: * @param generator the {@code RandomGenerator} calls are delegated to > 319: * @return the delegating {@code Random} instance > 320: * @throws NullPointerException if generator is null One more small thing. Add this line after the `@throws` line: * @since 19 Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Wed Mar 16 08:25:51 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Mar 2022 08:25:51 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v33] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Fri, 11 Mar 2022 19:40:39 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with two additional commits since the last revision: >> >> - change KeyStructure to String >> - fix test > > Regarding the number of test cases for `tableSizeForCases` and `populatedCapacityCases`... the issue is not necessarily with execution time (although if the test is slow it is a problem). The issues are more around: Is this testing anything useful, and does this make sense to the reader? > > I think we can rely on the monotonicity of these functions. If populating a map both with 49 and with 96 mappings results in a table length of 128, we don't need to test that all the intermediate inputs also result in a table length of 128. Including all the intermediate inputs makes the source code more bulky and requires future readers/maintainers to hunt around in the long list of tests to figure out which ones are significant. Really, the only ones that are significant are the boundary cases, so just keep those. Adding more tests that aren't relevant actually does hurt, even if they execute quickly. So: please cut out all the extra test cases that aren't near the boundary cases. > > I'm not sure what's going on with the build. The builds are in GitHub Actions and they aren't necessarily reliable, so I wouldn't worry about them too much. I'll run the final version through our internal build/test system before integration. (I've also done this previously, and the results were fine.) @stuart-marks should it mean I shall first rebase all commits? or it would be automatically sqruashed? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From magnus.ihse.bursie at oracle.com Wed Mar 16 08:44:51 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 09:44:51 +0100 Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> References: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> Message-ID: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com> On 2022-03-16 07:31, Alan Bateman wrote: > Magnus, > > This proposal does not address the previous concerns. As before, you > are proposing to put the data files used to generate the classes for > jdk.localedata and jdk.charsets into src/java.base and I don't think > we should do that. I really think this PR needs to be withdraw n or > closed until there is at least some agreement on placement. I know you > want to get the files moved out of the make tree but there are many > issues to work through before that can happen. I'm sorry that you feel I did not properly address your concerns. You wrote: "If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module." which I interpreted as a need to file a follow-up issue to sort that out, not a veto on the entire PR. If you have such strong opinions on the data files shared between java.base and jdk.charsets/jdk.localedata, I propose we leave them in make/data for the time being, clean up the associated mess, and then work out where they actually should be. Does that sound okay to you? /Magnus > > -Alan > > On 15/03/2022 23:59, Magnus Ihse Bursie wrote: >> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie >> wrote: >> >>>> A lot (but not all) of the data in make/data is tied to a specific >>>> module. For instance, the publicsuffixlist is used by java.base, >>>> and fontconfig by java.desktop. (A few directories, like >>>> mainmanifest, is *actually* used by make for the whole build.) >>>> >>>> These data files should move to the module they belong to. The are, >>>> after all, "source code" for that module that is "compiler" into >>>> resulting deliverables, for that module. (But the "source code" >>>> language is not Java or C, but typically a highly domain specific >>>> language or data format, and the "compilation" is, often, a >>>> specialized transformation.) >>>> >>>> This misplacement of the data directory is most visible at code >>>> review time. When such data is changed, most of the time build-dev >>>> (or the new build label) is involved, even though this has nothing >>>> to do with the build. While this is annoying, a worse problem is if >>>> the actual team that needs to review the patch (i.e., the team >>>> owning the module) is missed in the review. >>>> >>>> ### Modules reviewed >>>> >>>> - [x] java.base >>>> - [x] java.desktop >>>> - [x] jdk.compiler >>>> - [x] java.se >>> Magnus Ihse Bursie has updated the pull request with a new target >>> base due to a merge or a rebase. The pull request now contains 12 >>> commits: >>> >>> ? - Merge branch 'master' into shuffle-data-reborn >>> ? - Fix merge >>> ? - Merge tag 'jdk-19+13' into shuffle-data-reborn >>> ??? ??? Added tag jdk-19+13 for changeset 5df2a057 >>> ? - Move characterdata templates to share/classes/java/lang. >>> ? - Update comment refering to "make" dir >>> ? - Move new symbols to jdk.compiler >>> ? - Merge branch 'master' into shuffle-data >>> ? - Move macosxicons from share to macosx >>> ? - Move to share/data, and move jdwp.spec to java.se >>> ? - Update references in test >>> ? - ... and 2 more: >>> https://git.openjdk.java.net/jdk/compare/83d77186...598f740f >> I have carefully reviewed all PR comments, and the changes I made in >> response to them. I believe I have resolved all requests from >> reviewers. What remained to do was to create an informational JEP >> about the new source structure, and file some follow-up issues. >> >> I have now created and submitted a new informational JEP ("JDK Source >> Structure"), available at >> https://bugs.openjdk.java.net/browse/JDK-8283227. When creating this >> JEP, it felt increasingly silly to just copy and extend the part >> about src/$MODULE from JEP 201, so I extended it to cover a relevant >> overview of the entire JDK source base structure. I actually think >> this JEP has a good merit on its own, notwithstanding it being a >> reviewer requirement for this PR. >> >> I have also filed follow up issues for the non-standard >> jdk.hotspot.agent `doc` and `test` directories >> (https://bugs.openjdk.java.net/browse/JDK-8283197 and >> https://bugs.openjdk.java.net/browse/JDK-8283198, respectively). >> >> I have filed a follow up issue for continued efforts to clean up >> charsetmapping, https://bugs.openjdk.java.net/browse/JDK-8283228. >> >> There were two open questions: >> >> ? * should jdwp.spec belong to specs directory instead of data >> ? * should bin/idea.sh be changed to exclude data >> >> but they sounded so exploratory that I decided not to open JBS issues >> for them. >> >> @wangweij? @naotoj? @prrace? @erikj79 @jonathan-gibbons? You have all >> approved this PR at an older revision. Can you please reconfirm that >> your approval stands for the latest revision? (Sorry for the mass ping) >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/1611 > From raffaello.giulietti at gmail.com Wed Mar 16 09:56:22 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 16 Mar 2022 10:56:22 +0100 Subject: Java floating point and StrictMath improvement? In-Reply-To: References: Message-ID: "Computer scientists of the world, unite! Let's get rid of binary floating-point arithmetic in Java, after 27 years of honorable service! Let's adopt decimal floating-point arithmetic, where 1 / 3 + 1 / 3 is still different from 2 / 3, but who cares? At least we have 0.1 * 0.1 = 0.01, as Mathematics commands!" Just kidding... More seriously, let's stop this useless discussion. Raffaello On 2022-03-16 06:47, A Z wrote: > To core-libs-dev at openjdk.java.net, > > > float and double should be mutually enhanced or > > defaultedly changed, to uphold the following three > > properties: > > > 1) Base ten arithmetic on float and double, via operators. > > 2) Base Ten elementary function calls, like > > those made on java.lang.StrictMath, > > on double or float values. > > 3) Base ten Comparison operators. ==, !=, >, <, >=,<=. > > > > Martin has said: > > > 'It is inherently, mathematically *impossible* to emulate decimal > > behaviour with binary IEEE 754 arithmetic. That's why Java also > > offers java.math.BigDecimal, a decimal floating-point library > > implemented in software.' > > > Then don't use IEEE 754 alone! Or, have a dual mode, with an > > active alternative. There are binary alternatives, particularly > > that include the likes of SSE, that in fact can. > > > The only standards necessary, and really, the 'authoritative standard', > > are those prevalent in mathematics itself. Base 10 arithmetic, algebra, > > elementary functions, range limited real values. > > > BigDecimal, BigInteger, and https://github.com/eobermuhlner big-math, > > with its calculator class, take up more room in memory than necessary. > > They are slower, and they do not allow for the use of operators. > > Worse yet, they are not immediately reified in the rest of the language, > > ie all class and interface libraries. > > > Raffaello has said: > > 'Exact representation of 0.1 using base 2 is mathematically impossible, > > no matter the language (it is a periodic number in base 2).' > > > Consideration of the article: > > https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf > > > Which is admittedly older, but still accurate, indicates otherwise. > > > I contend that within an upper and lower range, that it is possible. > > While C++ can't use the immediate ==, !=, >,<,>=,<= operators > > immediately accurately, Java has. > > > Using 32 or 64 bit buffers, and an SSE or similar buffer, and the > > right algorithms, unto limited range, you can have as much of > > a range representation as required for float or double, even > > though you ultimately don't have 'exact' representation. > > > Bernd Eckenfels has said: > > 'The need to round floating point numbers for commercial math > > (and the risk involved in doing so) is nothing new, it predates > > the IEEE standard and should be subject for even basic comp > > sci curriculums all over the world.' > > > That is true, but it is the case that range termination > > of decimal values, by means of truncation, is more accurate > > than this. By any processing of rounding, you start gaining > > inaccuracy, which can grow and grow and overpopulate the > > entire number. In Computer Programming, you can need range > > continuous range accuracy. Such as with 2D and 3D processing. > > The present Java approach is slower and a waste of memory. > > > Given all this, and given that humans, and representations > > of the real world rely on base 10 first, shouldn't the 3 > > properties I outlined at the beginning of my post be > > at least mutually, compatibly, instituted in Java, > > if not defaultedly? > From adinn at redhat.com Wed Mar 16 11:17:37 2022 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 16 Mar 2022 11:17:37 +0000 Subject: Java floating point and StrictMath improvement? In-Reply-To: References: Message-ID: <775746eb-9ac1-f9b5-cb9c-016738968c48@redhat.com> On 16/03/2022 09:56, Raffaello Giulietti wrote: > "Computer scientists of the world, unite! > > Let's get rid of binary floating-point arithmetic in Java, after 27 > years of honorable service! > > Let's adopt decimal floating-point arithmetic, where 1 / 3 + 1 / 3 is > still different from 2 / 3, but who cares? At least we have 0.1 * 0.1 = > 0.01, as Mathematics commands!" > > > Just kidding... > More seriously, let's stop this useless discussion. Raffaello, the problem initially apparent here is that the person posting these rants is ignorant of some very straightforward knowledge about numbers and numeric representation, both mathematical and via fixed or floating point approximation. Surprising, perhaps in someone who claims to be a programmer, since it does not even require degree level study in mathematics to acquire such knowledge. A competent amateur or a degree student in a science or engineering field can easily learn what is at stake and note the misconceptions the rants are based on. However, on top of basic ignorance, it takes real wilfulness and stupidity -- not to mention a certain measure of narcissism -- for someone: to suggest that the various people, like yourself, who clearly do understand the relevant mathematical facts and have replied at length to explain those misconceptions, cannot know what they are talking about; and further to demand that some higher authority turn up as an act of duty, like a latter-day 8th cavalry, to sanction their incoherent proposals. Best not to feed someone like this; trolls are greedy beasts and grow to disproportionate size the more you feed them. regards, Andrew Dinn ----------- From coffeys at openjdk.java.net Wed Mar 16 12:03:46 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 16 Mar 2022 12:03:46 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 14:08:57 GMT, Ravi Reddy wrote: > Hi All, > > This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. > 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in > DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. > 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. > 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java > > Thanks, > Ravi Looks like a good approach to solve reported issue. test/jdk/java/util/zip/CloseInflaterDeflaterTest.java line 58: > 56: } > 57: @Override > 58: public void write(byte b[]) throws IOException {} Let's be consistant with style and use "byte[] b" Same with line 70 ------------- Marked as reviewed by coffeys (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7804 From duke at openjdk.java.net Wed Mar 16 13:26:08 2022 From: duke at openjdk.java.net (liach) Date: Wed, 16 Mar 2022 13:26:08 GMT Subject: RFR: 8283237: CallSite should be a sealed class Message-ID: Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. ------------- Commit messages: - 8283237: CallSite should be a sealed class Changes: https://git.openjdk.java.net/jdk/pull/7840/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7840&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283237 Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7840.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7840/head:pull/7840 PR: https://git.openjdk.java.net/jdk/pull/7840 From stuefe at openjdk.java.net Wed Mar 16 14:41:41 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 16 Mar 2022 14:41:41 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 22:58:48 GMT, Tyler Steele wrote: > As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. > > This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL). > > In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. > > ### Alternatives > > It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. > > ### Testing > > This change has been tested on AIX and Linux/x86. Hi Tyler, The way we solve this usually is by homogenizing malloc behavior across all platforms with `if (len == 0) len=1;`, see e.g. https://github.com/openjdk/jdk/blob/08cadb4754da0d5e68ee2df45f4098d203d14115/src/hotspot/share/runtime/os.cpp#L644-L647 I suggest you do that here too since it would be a far less intrusive change. If you don't want to fix up all three malloc call sites, just reroute them to a local malloc stub (`my_malloc()`) that corrects length and calls the real malloc. If you want, you can `#ifdef _AIX` that length correction too, e.g.: static void* my_malloc(size_t l) { #ifdef _AIX if (l == 0) l = 1; #endif return malloc(l); } That would be a far smaller change, and it would not introduce a new behavioral difference (because with your change, AIX now throws ClassFormatError where other platforms don't). Side note: nothing against changing 0 to NULL, but please in a separate cleanup patch. Cheers, Thomas Btw, which malloc call was the problematic exactly? Cannot be the one in getUTF, since that one already adds len + 1 and never gets called with a zero length anyway. ------------- Changes requested by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 14:54:41 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Wed, 16 Mar 2022 14:54:41 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: References: Message-ID: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> > Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. > > Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. > > Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: add since in javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7001/files - new: https://git.openjdk.java.net/jdk/pull/7001/files/406e2bc8..2208f848 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=18 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7001&range=17-18 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7001.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7001/head:pull/7001 PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Wed Mar 16 14:56:33 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Wed, 16 Mar 2022 14:56:33 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v18] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 06:51:37 GMT, Stuart Marks wrote: >> Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix SplittableRandomTest. > > src/java.base/share/classes/java/util/Random.java line 320: > >> 318: * @param generator the {@code RandomGenerator} calls are delegated to >> 319: * @return the delegating {@code Random} instance >> 320: * @throws NullPointerException if generator is null > > One more small thing. Add this line after the `@throws` line: > > * @since 19 > > Thanks. Added ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Wed Mar 16 15:08:47 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 15:08:47 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 14:38:55 GMT, Thomas Stuefe wrote: > Btw, which malloc call was the problematic exactly? Cannot be the one in getUTF, since that one already adds len + 1 and never gets called with a zero length anyway. Oh, good point. I guess it gets lost in the noise of my other changes. The lines causing the issue was these ones: https://github.com/openjdk/jdk/blob/08cadb4754da0d5e68ee2df45f4098d203d14115/src/java.base/share/native/libjava/ClassLoader.c#L102-L107 ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 15:11:36 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 15:11:36 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 In-Reply-To: References: Message-ID: <-2YzpgfxdAsT99AreEtBzrY-IaV5pdnans07Cmois5E=.472f3026-357b-4507-a2bc-eb1127115b12@github.com> On Wed, 16 Mar 2022 14:37:57 GMT, Thomas Stuefe wrote: > The way we solve this usually is by homogenizing malloc behavior across all platforms with `if (len == 0) len=1;` Interesting! That idea didn't occur to me until after I submitted the PR. I'm happy to test that out and see how it works. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From darcy at openjdk.java.net Wed Mar 16 16:21:47 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Mar 2022 16:21:47 GMT Subject: Integrated: JDK-8283234: Improve @jls usage in java.base In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 03:03:23 GMT, Joe Darcy wrote: > Checking the java.bases sources revealed a number of other instances where conceptual links into the JLS (or JVMS) could be upgraded to actual links. This pull request has now been integrated. Changeset: 0cf291bc Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/0cf291bc31acf69c767c5d39d21b1195e6d761b2 Stats: 21 lines in 5 files changed: 0 ins; 0 del; 21 mod 8283234: Improve @jls usage in java.base Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7834 From rreddy at openjdk.java.net Wed Mar 16 16:34:37 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Wed, 16 Mar 2022 16:34:37 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() [v2] In-Reply-To: References: Message-ID: > Hi All, > > This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. > 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in > DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. > 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. > 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java > > Thanks, > Ravi Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: Modified write(byte []b) to write(byte[] b) to maintain same signature across the test case ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7804/files - new: https://git.openjdk.java.net/jdk/pull/7804/files/5700e194..c50aa1bd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7804&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7804&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7804/head:pull/7804 PR: https://git.openjdk.java.net/jdk/pull/7804 From coffeys at openjdk.java.net Wed Mar 16 16:34:37 2022 From: coffeys at openjdk.java.net (Sean Coffey) Date: Wed, 16 Mar 2022 16:34:37 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 16:31:36 GMT, Ravi Reddy wrote: >> Hi All, >> >> This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. >> 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in >> DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. >> 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. >> 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > Modified write(byte []b) to write(byte[] b) to maintain same signature across the test case Marked as reviewed by coffeys (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7804 From rreddy at openjdk.java.net Wed Mar 16 16:34:38 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Wed, 16 Mar 2022 16:34:38 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 11:59:44 GMT, Sean Coffey wrote: >> Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: >> >> Modified write(byte []b) to write(byte[] b) to maintain same signature across the test case > > test/jdk/java/util/zip/CloseInflaterDeflaterTest.java line 58: > >> 56: } >> 57: @Override >> 58: public void write(byte b[]) throws IOException {} > > Let's be consistant with style and use "byte[] b" > > Same with line 70 Thanks , I am now using "byte[] b" in both write() and read() methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/7804 From lancea at openjdk.java.net Wed Mar 16 16:47:40 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 16 Mar 2022 16:47:40 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 16:34:37 GMT, Ravi Reddy wrote: >> Hi All, >> >> This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. >> 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in >> DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. >> 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. >> 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > Modified write(byte []b) to write(byte[] b) to maintain same signature across the test case Hi Ravi, Thank you for the additional work on this issue. Overall this looks good. If possible, could you please follow the format for comments as in open/test/jdk/java/util/zip/ZipFile/GetInputStreamNPETest.java for tests and DataProviders as it would be great to try and be consistent as we update and add new tests. ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7804 From smarks at openjdk.java.net Wed Mar 16 16:49:52 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 16 Mar 2022 16:49:52 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v34] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Sat, 12 Mar 2022 01:35:23 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refine test No, you don't need to do any rebasing; when the change is integrated, all these commits will automatically be squashed into a single commit. If that can't be done, the bot will detect it and give a warning, which will probably include instructions. But basically you'd merge from the master branch and commit the merge after resolving any conflicts. None of that needs to be done in this case, so I'll just go ahead and sponsor this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Wed Mar 16 16:52:47 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Mar 2022 16:52:47 GMT Subject: Integrated: 8281631: HashMap copy constructor and putAll can over-allocate table In-Reply-To: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: <-BS-zxF-S7qOnUk5H3uYtzE8BfgJvb_is3epV0-WvdY=.b24145f5-29ee-4178-9e22-3b0c2467e133@github.com> On Thu, 10 Feb 2022 17:46:36 GMT, XenoAmess wrote: > 8281631: HashMap copy constructor and putAll can over-allocate table This pull request has now been integrated. Changeset: 3e393047 Author: XenoAmess Committer: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/3e393047e12147a81e2899784b943923fc34da8e Stats: 267 lines in 4 files changed: 195 ins; 9 del; 63 mod 8281631: HashMap copy constructor and putAll can over-allocate table Reviewed-by: smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From smarks at openjdk.java.net Wed Mar 16 17:03:52 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 16 Mar 2022 17:03:52 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > add since in javadoc Thanks for the last-minute updates! ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7001 From darcy at openjdk.java.net Wed Mar 16 17:04:22 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 16 Mar 2022 17:04:22 GMT Subject: RFR: JDK-8283274: Improve @jvms usage in java.base Message-ID: As was done for JLS references under JDK-8283234, now the analogous update for JVMS references. ------------- Commit messages: - JDK-8283274: Improve @jvms usage in java.base Changes: https://git.openjdk.java.net/jdk/pull/7844/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7844&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283274 Stats: 12 lines in 6 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7844.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7844/head:pull/7844 PR: https://git.openjdk.java.net/jdk/pull/7844 From duke at openjdk.java.net Wed Mar 16 17:19:46 2022 From: duke at openjdk.java.net (liach) Date: Wed, 16 Mar 2022 17:19:46 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v4] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 23:36:19 GMT, liach wrote: >> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. > > liach has updated the pull request incrementally with two additional commits since the last revision: > > - merge branch 'identityhashmap-bench' of https://github.com/liachmodded/jdk into identityhashmap-default > - fix whitespace @stuart-marks Could you help me with this? In my JMH benchmark runs, I often find that ambient differences (from the jdk processes, the random test data generated, etc.) hide the actual performance difference caused by the patches. Hence, I need help in these two area: 1. I probably need to make a baseline benchmark that can discount the fundamental differences between jdk processes. What should it be? 2. How do I generate consistent data set for all test runs to avoid contributing to errors? ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From prr at openjdk.java.net Wed Mar 16 17:19:57 2022 From: prr at openjdk.java.net (Phil Race) Date: Wed, 16 Mar 2022 17:19:57 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: <_XwD8h3_L03wqvO0Na4_OoHwtdYInzjTKsOaFvqKfUY=.47ccb949-e5fe-49bb-b4b8-3bc36676910a@github.com> On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f How are folks reviewing this huge PR ? My browser paints a few files and that's it, and the drop down list to "jump to" is too big to display - it says ! ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From duke at openjdk.java.net Wed Mar 16 17:22:50 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 16 Mar 2022 17:22:50 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v34] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Wed, 16 Mar 2022 16:46:58 GMT, Stuart Marks wrote: > No, you don't need to do any rebasing; when the change is integrated, all these commits will automatically be squashed into a single commit. If that can't be done, the bot will detect it and give a warning, which will probably include instructions. But basically you'd merge from the master branch and commit the merge after resolving any conflicts. > > None of that needs to be done in this case, so I'll just go ahead and sponsor this. Thanks. So the next step would be clean the usage of ` x / 0.75F+1F` in codes. Should I create one another report at https://bugreport.java.com/bugreport/ ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From iris at openjdk.java.net Wed Mar 16 17:38:46 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 16 Mar 2022 17:38:46 GMT Subject: RFR: JDK-8283274: Improve @jvms usage in java.base In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 16:57:12 GMT, Joe Darcy wrote: > As was done for JLS references under JDK-8283234, now the analogous update for JVMS references. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7844 From duke at openjdk.java.net Wed Mar 16 17:45:16 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 17:45:16 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v2] In-Reply-To: References: Message-ID: > As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. > > This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL). > > In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. > > ### Alternatives > > It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. > > ### Testing > > This change has been tested on AIX and Linux/x86. Tyler Steele has updated the pull request incrementally with four additional commits since the last revision: - Fixes type warning. - Removes unneeded ClassFormatError from ClassLoader.c - Revert "Extract memory error logic to helper procedure" This reverts commit b631eb0ccd5f3748c2010c864f8ccef0c1da9c42. - Avoid calling malloc with size zero. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7829/files - new: https://git.openjdk.java.net/jdk/pull/7829/files/b631eb0c..de946b41 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7829&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7829&range=00-01 Stats: 41 lines in 2 files changed: 10 ins; 21 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7829.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7829/head:pull/7829 PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 18:13:45 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 18:13:45 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 In-Reply-To: References: Message-ID: <3Qwg1jljIpO5uZ-IlyQi8oR7qoEdP2QCrniOvbFu7rQ=.222af244-2890-4d50-bad5-4ed289b141fe@github.com> On Wed, 16 Mar 2022 14:38:55 GMT, Thomas Stuefe wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Btw, which malloc call was the problematic exactly? Cannot be the one in getUTF, since that one already adds len + 1 and never gets called with a zero length anyway. Thanks @tstuefe! Your suggestion lead to a better change, so I modified the PR. - ClassLoader.c no longer has any reason to throw a ClassFormatError, so that logic is removed. - The test no longer needs to recognize a new error message, so that is changed back as well. - I also alphabetized the header files, because that is the way I am :-) Note: I couldn't find an implementation of MAX2 in a C-friendly 'header.h' file, so I just used the ternary operator in the two places I needed it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 18:17:42 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 18:17:42 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 14:37:57 GMT, Thomas Stuefe wrote: > Side note: nothing against changing 0 to NULL, but please in a separate cleanup patch. I just saw this. I will separate the cleanup into a separate patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From achung at openjdk.java.net Wed Mar 16 18:31:55 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 16 Mar 2022 18:31:55 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: > msg drop for jdk19, Mar 9, 2022 Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: removed incorrect translation of compiler configuration file ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7765/files - new: https://git.openjdk.java.net/jdk/pull/7765/files/d5c9b884..715a6ad7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7765&range=02-03 Stats: 2310 lines in 3 files changed: 0 ins; 2310 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7765.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7765/head:pull/7765 PR: https://git.openjdk.java.net/jdk/pull/7765 From ihse at openjdk.java.net Wed Mar 16 19:10:03 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 19:10:03 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f It might be helpful to go to the webrev instead: https://openjdk.github.io/cr/?repo=jdk&pr=1611&range=05 Only the first dozen or so of files has actual changes; the rest are moved files. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From Alan.Bateman at oracle.com Wed Mar 16 19:53:11 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Mar 2022 19:53:11 +0000 Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com> References: <4dd8052d-b376-ef82-0dfd-ccaf0297a27c@oracle.com> <47cf38cc-2a72-0e2e-f626-707dd8cd4434@oracle.com> Message-ID: <1ffca295-1c99-300e-1ac5-f81c51d8ef9b@oracle.com> On 16/03/2022 08:44, Magnus Ihse Bursie wrote: > : > > If you have such strong opinions on the data files shared between > java.base and jdk.charsets/jdk.localedata, I propose we leave them in > make/data for the time being, clean up the associated mess, and then > work out where they actually should be. Does that sound okay to you? The concern, as before, is that it puts data files into src/java.base that are used by the build to generate classes/resources for the service provider modules.? We also have the complication that the charsets to include in java.base varies by platform so the module/package for each charset is decided at build time. It's always been low-priority to re-visit that and not clear if we could even get to an agreement easily because there are IBM platforms that want EBCDIC and other double byte charsets whereas other platforms don't want these in java.base. So yes, if you can drop the move of the charset data and CLDR data from the patch then it will make it easier to discuss. You asked about the JDWP spec. This is the protocol spec that is used to generate the spec in HTML, and source files for the debugger front-end and backend (jdk.jdi and jdk.jdwp.agent modules). The "specs" directory might be right. There is another source file (jdwp-spec.md) that isn't in the src tree right now and they probably go together. -Alan From rriggs at openjdk.java.net Wed Mar 16 20:22:38 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Mar 2022 20:22:38 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 17:45:16 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele has updated the pull request incrementally with four additional commits since the last revision: > > - Fixes type warning. > - Removes unneeded ClassFormatError from ClassLoader.c > - Revert "Extract memory error logic to helper procedure" > > This reverts commit b631eb0ccd5f3748c2010c864f8ccef0c1da9c42. > - Avoid calling malloc with size zero. Changes requested by rriggs (Reviewer). src/java.base/share/native/libjava/ClassLoader.c line 106: > 104: // NULL or a unique non-NULL pointer. To unify libc behavior across our platforms > 105: // we chose the latter. (see 8283225) > 106: body = (jbyte *)malloc(length < 1 ? 1 : length); This code conflates a length == in the comment with length < 1 in the code. If the issue is with length == 0, make that be the test. src/java.base/share/native/libjava/ClassLoader.c line 250: > 248: // NULL or a unique non-NULL pointer. To unify libc behavior across our platforms > 249: // we chose the latter. (see 8283225) > 250: body = (jbyte *)malloc(length < 1 ? 1 : length); The comment talks about a length of zero, but the code does something else with length < 1. I'd rather not see negative sizes conflated with zero. test/hotspot/jtreg/runtime/DefineClass/NullClassBytesTest.java line 26: > 24: /* > 25: * @test > 26: * @bug 8262913 8283225 All of the changes can be removed from NullClassBytesTest.java. (copyright and bug #) ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 20:40:47 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 20:40:47 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 20:17:50 GMT, Roger Riggs wrote: >> Tyler Steele has updated the pull request incrementally with four additional commits since the last revision: >> >> - Fixes type warning. >> - Removes unneeded ClassFormatError from ClassLoader.c >> - Revert "Extract memory error logic to helper procedure" >> >> This reverts commit b631eb0ccd5f3748c2010c864f8ccef0c1da9c42. >> - Avoid calling malloc with size zero. > > src/java.base/share/native/libjava/ClassLoader.c line 106: > >> 104: // NULL or a unique non-NULL pointer. To unify libc behavior across our platforms >> 105: // we chose the latter. (see 8283225) >> 106: body = (jbyte *)malloc(length < 1 ? 1 : length); > > This code conflates a length == in the comment with length < 1 in the code. > If the issue is with length == 0, make that be the test. Thanks for your comment. I agree, and will make this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 20:47:40 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 20:47:40 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 20:19:08 GMT, Roger Riggs wrote: >> Tyler Steele has updated the pull request incrementally with four additional commits since the last revision: >> >> - Fixes type warning. >> - Removes unneeded ClassFormatError from ClassLoader.c >> - Revert "Extract memory error logic to helper procedure" >> >> This reverts commit b631eb0ccd5f3748c2010c864f8ccef0c1da9c42. >> - Avoid calling malloc with size zero. > > test/hotspot/jtreg/runtime/DefineClass/NullClassBytesTest.java line 26: > >> 24: /* >> 25: * @test >> 26: * @bug 8262913 8283225 > > All of the changes can be removed from NullClassBytesTest.java. (copyright and bug #) Hmm, maybe I misunderstand the idea behind this bug tag. Don't we want to list the bug ids of any issues the test caught? ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From joe.darcy at oracle.com Wed Mar 16 21:01:07 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 16 Mar 2022 14:01:07 -0700 Subject: Java float, double, StrictMath correction? In-Reply-To: References: Message-ID: <525da6de-909a-0e6f-ae67-bf378ab5f3c0@oracle.com> On 3/15/2022 6:11 PM, A Z wrote: [snip] > > > Raffaello has said: > > 'Exact representation of 0.1 using base 2 is mathematically impossible, > > no matter the language (it is a periodic number in base 2).' > > > Consideration of the article: > > https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf > > > Which is admittedly older, but still accurate, indicates otherwise. As the co-author of the article in question, I am familiar with its contents and the article does not question 1/10 being a repeating fraction in binary. For comments on both the technical floating-point matters raised and style of discourse, I refer interested readers to a previous email on core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-March/051952.html -Joe From duke at openjdk.java.net Wed Mar 16 21:10:14 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 21:10:14 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v3] In-Reply-To: References: Message-ID: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> > As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. > > ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] > > In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. > > ### Alternatives > > It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. > > ### Testing > > This change has been tested on AIX and Linux/x86. Tyler Steele 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: Addresses failure in NullClassTest on AIX. - Changes malloc(0) call to malloc(1) on AIX. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7829/files - new: https://git.openjdk.java.net/jdk/pull/7829/files/de946b41..f05c8d85 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7829&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7829&range=01-02 Stats: 37 lines in 2 files changed: 12 ins; 6 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/7829.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7829/head:pull/7829 PR: https://git.openjdk.java.net/jdk/pull/7829 From rriggs at openjdk.java.net Wed Mar 16 21:10:17 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 16 Mar 2022 21:10:17 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 20:44:04 GMT, Tyler Steele wrote: >> test/hotspot/jtreg/runtime/DefineClass/NullClassBytesTest.java line 26: >> >>> 24: /* >>> 25: * @test >>> 26: * @bug 8262913 8283225 >> >> All of the changes can be removed from NullClassBytesTest.java. (copyright and bug #) > > Hmm, maybe I misunderstand the idea behind this bug tag. Don't we want to list the bug ids of any issues the test caught? Usually, the bug number implies the test was modified to cover the issue. Otherwise, we end up with very large bug lists and they lose their meaning. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 21:17:45 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 21:17:45 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v3] In-Reply-To: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: On Wed, 16 Mar 2022 21:10:14 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele 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: > > Addresses failure in NullClassTest on AIX. > > - Changes malloc(0) call to malloc(1) on AIX. The requested changes have been made, and a better, leaner PR results. In addition to the changes mentioned above, I also incorporated Thomas' suggestion to use `#ifdef _AIX` to ensure the change only happens on AIX where it's needed. I thought I'd skip the call to 'my_malloc' since the change is only required in two places. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 21:17:46 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 21:17:46 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v2] In-Reply-To: References: Message-ID: <4JzjW-oHKJFf7vYBWVKnxj8HqkEp2W4WwxVkkYKCUEg=.879a3edb-cd02-42d4-85cd-6f341f41efe6@github.com> On Wed, 16 Mar 2022 21:06:04 GMT, Roger Riggs wrote: >> Hmm, maybe I misunderstand the idea behind this bug tag. Don't we want to list the bug ids of any issues the test caught? > > Usually, the bug number implies the test was modified to cover the issue. Otherwise, we end up with very large bug lists and they lose their meaning. Thanks. That's good to know. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Wed Mar 16 21:33:02 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Wed, 16 Mar 2022 21:33:02 GMT Subject: RFR: 8283287: Spring Cleaning for ClassLoader.c Message-ID: As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c - Alphabetize includes. - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. - Replace 'return 0' with 'return NULL'. ------------- Commit messages: - Perform minor clean up ClassLoader.c Changes: https://git.openjdk.java.net/jdk/pull/7846/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283287 Stats: 26 lines in 1 file changed: 7 ins; 5 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7846/head:pull/7846 PR: https://git.openjdk.java.net/jdk/pull/7846 From naoto at openjdk.java.net Wed Mar 16 21:39:02 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Mar 2022 21:39:02 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:50:20 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - Merge tag 'jdk-19+13' into shuffle-data-reborn > > Added tag jdk-19+13 for changeset 5df2a057 > - Move characterdata templates to share/classes/java/lang. > - Update comment refering to "make" dir > - Move new symbols to jdk.compiler > - Merge branch 'master' into shuffle-data > - Move macosxicons from share to macosx > - Move to share/data, and move jdwp.spec to java.se > - Update references in test > - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f Looks good, with minor comments. Also I am assuming you will modify the copyright year for these files before the merge. make/modules/jdk.charsets/Gensrc.gmk line 32: > 30: # Generate files using the charsetmapping tool > 31: # > 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Wed Mar 16 21:40:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Mar 2022 21:40:44 GMT Subject: RFR: 8280400: JDK 19 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 18:31:55 GMT, Alisen Chung wrote: >> msg drop for jdk19, Mar 9, 2022 > > Alisen Chung has updated the pull request incrementally with one additional commit since the last revision: > > removed incorrect translation of compiler configuration file LGTM. Thanks for the change. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7765 From ihse at openjdk.java.net Wed Mar 16 22:00:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 22:00:02 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 21:31:08 GMT, Naoto Sato wrote: >> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Merge branch 'master' into shuffle-data-reborn >> - Fix merge >> - Merge tag 'jdk-19+13' into shuffle-data-reborn >> >> Added tag jdk-19+13 for changeset 5df2a057 >> - Move characterdata templates to share/classes/java/lang. >> - Update comment refering to "make" dir >> - Move new symbols to jdk.compiler >> - Merge branch 'master' into shuffle-data >> - Move macosxicons from share to macosx >> - Move to share/data, and move jdwp.spec to java.se >> - Update references in test >> - ... and 2 more: https://git.openjdk.java.net/jdk/compare/83d77186...598f740f > > make/modules/jdk.charsets/Gensrc.gmk line 32: > >> 30: # Generate files using the charsetmapping tool >> 31: # >> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping > > Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From naoto at openjdk.java.net Wed Mar 16 22:04:49 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 16 Mar 2022 22:04:49 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v6] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 21:56:53 GMT, Magnus Ihse Bursie wrote: >> make/modules/jdk.charsets/Gensrc.gmk line 32: >> >>> 30: # Generate files using the charsetmapping tool >>> 31: # >>> 32: CHARSET_DATA_DIR := $(TOPDIR)/src/java.base/share/data/charsetmapping >> >> Is it intentional to leave `java.base` literal here, or should it be replaced with `$(MODULE_SRC)`? I see this inconsistency in other tools' `gensrc.gmk` too > > This is part of the weirdness of charsetmapping that Alan talks about. The charsetmapping data is shared between java.base and jdk.charsets in a way that makes it non-trivial to disentangle. > > So this reference to java.base is quite intentional -- replacing it with $(MODULE_SRC) would have pointed to src/jdk.charsets instead of src/java.base, which would have been incorrect. Thanks for reminding me. Then yes, I'd agree with Alan. It'd be much simpler to exclude this from this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From cushon at openjdk.java.net Wed Mar 16 22:07:05 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Wed, 16 Mar 2022 22:07:05 GMT Subject: RFR: JDK-8283280: Improve exception messages with -Dsun.misc.URLClassPath.disableJarChecking=false Message-ID: This change improves an exception message to include a path, e.g. `Invalid Jar file: some.jar` instead of just `Invalid Jar file`. The exception is currently [always being caught and ignored](https://github.com/openjdk/jdk/blob/3e393047e12147a81e2899784b943923fc34da8e/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L459-L461) so this visible to users of the API, it's just helpful for debugging. ------------- Commit messages: - JDK-8283280: Improve exception messages with -Dsun.misc.URLClassPath.disableJarChecking=false Changes: https://git.openjdk.java.net/jdk/pull/7848/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7848&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283280 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7848.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7848/head:pull/7848 PR: https://git.openjdk.java.net/jdk/pull/7848 From ihse at openjdk.java.net Wed Mar 16 23:53:19 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 16 Mar 2022 23:53:19 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v7] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/598f740f..1c91b951 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=05-06 Stats: 35 lines in 35 files changed: 0 ins; 0 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Thu Mar 17 00:07:53 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Mar 2022 00:07:53 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v8] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Restore charsetmapping and cldr to make/data ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c91b951..34bb3c16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=06-07 Stats: 5 lines in 1079 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Thu Mar 17 00:12:38 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Mar 2022 00:12:38 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/34bb3c16..b1d1e4d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=07-08 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From weijun at openjdk.java.net Thu Mar 17 00:31:11 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Thu, 17 Mar 2022 00:31:11 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos The security-related change looks fine to me ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Thu Mar 17 00:31:13 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Mar 2022 00:31:13 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v2] In-Reply-To: References: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com> Message-ID: On Wed, 16 Dec 2020 18:34:37 GMT, Naoto Sato wrote: >>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place. >>> >>> I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html: >>> >>> > As to charsetmapping and cldrconverter, I believe they can reside in >>> > java.base, as jdk.charsets and jdk.localedata modules depend on it. >>> >>> Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart. >>> >>> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place. >> >> I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory. > >>I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is. > > Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this. @naotoj @AlanBateman I have now rolled back any changes to make/data/cldr and make/data/charsetmapping. I have also updated copyright years; thanks for reminding me Naoto! ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From poweruserm at live.com.au Thu Mar 17 02:18:24 2022 From: poweruserm at live.com.au (A Z) Date: Thu, 17 Mar 2022 02:18:24 +0000 Subject: Questions about Java Floating Point and StrictMath alteration in JRE. Message-ID: To core-libs-dev, Raffaello has said: 'Let's get rid of binary floating-point arithmetic in Java, after 27 years of honorable service! Let's adopt decimal floating-point arithmetic, where 1 / 3 + 1 / 3 is still different from 2 / 3, but who cares?' I am not suggesting that we get rid of floating point binary implementation behind decimal expression, for arithmetic, comparisons and functions. I am trying to suggest that we should use an imminent way to correct and remove all denormal and pronormal cases, so that float and double operations are base 10 digit accurate for all operation cases. All this is possible by means of SSE hardware and similar. Java floating point has been a problem, requiring too elaborate a working around, for as long as denormal and pronormal values have been generated by it. It has been formally enough stated elsewhere that floating point denormal and pronormal values were originally designed as a trade-off between range and accuracy. My point in all this is that even more of the time, people still will need range and accuracy to equate, whether or not accuracy degrades only outside the range. Things like language specifications and standards have done nothing to assist Java in these needs areas. There are cases, since there is diametric thought involved, where java programmers need continuous range accuracy with the use of float and double, yet these secondary possibilities have not be accorded to in efficient a manner as has become possible, and necessary. 2D Graphics and 3D world operations, where pixel accuracy must always be maintained, can and are a real example. The context yet is, however, that there could be dual mode floating point, with both the present mode and an enhanced mode made accessible. I am aware that recurring decimals, like 1/3 and 2/3 can't perfectly be expressed in a truncated range floating point number, however that is a situation and a property of rational numbers, and the necessary limited range, which is to do with decimal numbers, and not floating point. This is not any real kind of problem, since rational number truncation is rationally inevitable, anyway. C++, alongside many scientific pocket calculators, does have the phenomenon of final decimal place rounding, which is apparently a property of calculating for humans, and is not related to floating point 'errors'. Notwithstanding how C++ comparisons work too, which Java has for all purposes corrected, the following is a clear example, contradicting Raffaello: #include using namespace std; int main() { cout << "Program has started..." << endl; long double a = 1.0; long double b = 3.0; long double c = a/b; cout << endl << c << endl << endl; long double d = c + c; cout << d << endl << endl; long double e = 2.0D/3.0D; cout << e << endl << endl; cout << "Program has Finished."; return 0; } With this fragment running, Raffaello's example turns out to be inaccurate. As it will for the rest of C++ range arithmetic, arithmetic which Java can adopt. Since anything can prevent final decimal place rounding, take version 4 and later of of Qalculate!, for example, https://qalculate.github.io/, with that done, fairly well any coherent language can therefore uphold 1.0F/3.0F + 1.0F/3.0F == 2.0F/3.0F 1.0D/3.0D + 1.0D/3.0D == 2.0D/3.0D alongside any other such salient example. Raffaello's example doesn't make ultimate, possible sense for Java SE, Java OpenJDK, or any other, possible, Hardware Box Computer language. It is possible, and already present elsewhere, certainly overall, that computer languages, Java included, ultimately can uphold range accurate decimal mathematics, by means of floating point, which may inherently be kept, altered or even mutually augmented, in the Java language. That includes the presence and operation of binary storage, and binary algorithms for manipulation behind that, using 64 bit registers, and additional SSE-style carry registers too. To Andrew Dinn, I may reply with the following: I am aware of IEEE 754, the Java Language Specification and the Java Virtual Machine Specification. My understanding is that Java doesn't adhere to these standards enough. At any rate, the end standard of base 10 mathematics is, rationally, the greater issue. You can have range binary mathematics, or range decimal mathematics, and you can convert in between either way, but you can't really convolute both of them at the same time, the way that Java presently does. What you end up with is something which is only useful as a push-and-pull format, requiring yet another implementation on top of that, like BigDecimal, BigInteger, and a Calculator class in type for them, such as the 3rd party big-math library. This kind of arrangement is slow, wastes memory, is more difficult and messy than needed to produce, debug, and edit, and even loses other properties, such as operator syntax. Is there anyone on core-libs-dev who is prepared to see these things enter in to Java, or to make manifest Java floating point arithmetic and java.lang.StrictMath dual-mode operation? Runtime Switches and manifest file line entries are all viable, straight-forward options. ? Sergio Minervini. From smarks at openjdk.java.net Thu Mar 17 03:13:49 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Thu, 17 Mar 2022 03:13:49 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v34] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Sat, 12 Mar 2022 01:35:23 GMT, XenoAmess wrote: >> 8281631: HashMap copy constructor and putAll can over-allocate table > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > refine test There's already a bug for this: [JDK-8186958](https://bugs.openjdk.java.net/browse/JDK-8186958). This includes creating a new API as well as fixing up a bunch of call sites. There's a partial list of call sites in java.base there. Go ahead and open a PR if you like. I've added an initial suggestion at an API as a comment on that bug. There may be some bikeshedding about the API. If it gets too bad, a potential fallback position would be to create a JDK-internal utility method and call it instead, and sidestep the creation of a public API. (However, I do think we need a public API for this.) I'd avoid updating all the individual call sites with the actual computation `(int) (Math.ceil(expectedSize/0.75))` because we might want to change it in the future. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Mar 17 03:30:57 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 17 Mar 2022 03:30:57 GMT Subject: RFR: 8281631: HashMap copy constructor and putAll can over-allocate table [v34] In-Reply-To: References: <1g2Mx1tUWKrBAbpXFaHYLcCjN-DLa9tCotky9CMBpU4=.81424c1c-b957-4339-9f80-6ff50fdebd49@github.com> Message-ID: On Thu, 17 Mar 2022 03:09:53 GMT, Stuart Marks wrote: > There's already a bug for this: [JDK-8186958](https://bugs.openjdk.java.net/browse/JDK-8186958). This includes creating a new API as well as fixing up a bunch of call sites. There's a partial list of call sites in java.base there. Go ahead and open a PR if you like. got it. > I'd avoid updating all the individual call sites with the actual computation `(int) (Math.ceil(expectedSize/0.75))` because we might want to change it in the future. Yes, I still prefer my int calculation way... But I guess a jmh for several implementations is necessary. ------------- PR: https://git.openjdk.java.net/jdk/pull/7431 From duke at openjdk.java.net Thu Mar 17 05:21:50 2022 From: duke at openjdk.java.net (xpbob) Date: Thu, 17 Mar 2022 05:21:50 GMT Subject: Withdrawn: 8283067: Incorrect comment in java.base/share/classes/java/util/ArrayList.java In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 09:48:14 GMT, xpbob wrote: > * Constructs an empty list with an initial capacity of ten > > => > > * Constructs an empty list with default sized empty instances. > > > private static final Object[] DEFAULTCAPACITY_EMPTY_ELEMENTDATA = {}; > > DEFAULTCAPACITY_EMPTY_ELEMENTDATA is empty and the length is 0 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7799 From jkuhn at openjdk.java.net Thu Mar 17 05:43:33 2022 From: jkuhn at openjdk.java.net (Johannes Kuhn) Date: Thu, 17 Mar 2022 05:43:33 GMT Subject: RFR: 8283237: CallSite should be a sealed class In-Reply-To: References: Message-ID: <9PwRvhunHD6-nFWdCvwN3B2-X1xeBT7zn7Zb_ygvPsw=.4d11407b-bc7e-4cfa-ad53-acffed41559b@github.com> On Wed, 16 Mar 2022 13:09:30 GMT, liach wrote: > Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. Marked as reviewed by jkuhn (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From forax at openjdk.java.net Thu Mar 17 06:50:31 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 17 Mar 2022 06:50:31 GMT Subject: RFR: 8283237: CallSite should be a sealed class In-Reply-To: References: Message-ID: <17YwNNOFLz2FAefoowpY81Dbh308gRIvm7aN7uasHTc=.c3229520-3062-45aa-9841-f9addcf47465@github.com> On Wed, 16 Mar 2022 13:09:30 GMT, liach wrote: > Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: > 86: */ > 87: public > 88: abstract sealed class CallSite permits ConstantCallSite, VolatileCallSite, MutableCallSite { Nitpicking with my JSR 292 hat, given that the permits clause is reflected in the javadoc, the order should be ConstantCS, MutableCS and VolatileCS, it's both in the lexical order and in the "memory access" of setTarget() order , from stronger access to weaker access. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From dholmes at openjdk.java.net Thu Mar 17 07:02:39 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Mar 2022 07:02:39 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: <5bv0sOtKeAB5bJO0MHxbW0fiz3exeUpcMiWODdAIiBc=.3f59f6bf-0940-420b-b659-39410e6be713@github.com> On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt wrote: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. > > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} src/java.base/share/native/libverify/check_code.c line 4168: > 4166: } > 4167: > 4168: static void check_and_push_const(context_type *context, const void *ptr, int kind) { IIUC the only `const` cases all pass a `const char*` so perhaps we can make that explicit in the signature? I confess I can't figure out how the passed in memory eventually gets used and it seems bizarre that it could be a freshly malloc'd block or an existing string. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From stuefe at openjdk.java.net Thu Mar 17 07:24:34 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Mar 2022 07:24:34 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v3] In-Reply-To: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: On Wed, 16 Mar 2022 21:10:14 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele 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: > > Addresses failure in NullClassTest on AIX. > > - Changes malloc(0) call to malloc(1) on AIX. This is much better, thanks. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Thu Mar 17 07:35:35 2022 From: duke at openjdk.java.net (liach) Date: Thu, 17 Mar 2022 07:35:35 GMT Subject: RFR: 8283237: CallSite should be a sealed class In-Reply-To: <17YwNNOFLz2FAefoowpY81Dbh308gRIvm7aN7uasHTc=.c3229520-3062-45aa-9841-f9addcf47465@github.com> References: <17YwNNOFLz2FAefoowpY81Dbh308gRIvm7aN7uasHTc=.c3229520-3062-45aa-9841-f9addcf47465@github.com> Message-ID: <-R8o7djCc0mTodUXwCOiC65mtPfiMmUs4nFe1AjXdN4=.5d4a6a11-d93f-4b53-b481-01af7a17bfc2@github.com> On Thu, 17 Mar 2022 06:47:13 GMT, R?mi Forax wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: > >> 86: */ >> 87: public >> 88: abstract sealed class CallSite permits ConstantCallSite, VolatileCallSite, MutableCallSite { > > Nitpicking with my JSR 292 hat, > given that the permits clause is reflected in the javadoc, > the order should be ConstantCS, MutableCS and VolatileCS, > it's both in the lexical order and in the "memory access" of setTarget() order , from stronger access to weaker access. I agree that Constant, Mutable, Volatile order is better, ranked by the respective cost for `setTarget()` and (possibly) invocation, and earlier ones in the list are more preferable if conditions allow. However, in the current API documentation, the order is Constant, Mutable, and Volatile. Should I update that or leave it? /* *
    *
  • If a mutable target is not required, an {@code invokedynamic} instruction * may be permanently bound by means of a {@linkplain ConstantCallSite constant call site}. *
  • If a mutable target is required which has volatile variable semantics, * because updates to the target must be immediately and reliably witnessed by other threads, * a {@linkplain VolatileCallSite volatile call site} may be used. *
  • Otherwise, if a mutable target is required, * a {@linkplain MutableCallSite mutable call site} may be used. *
*/ ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From stuefe at openjdk.java.net Thu Mar 17 07:48:35 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Mar 2022 07:48:35 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v3] In-Reply-To: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: <3T4tgcbiZO8Fzbp7YKOrjHBKYu0p6n_LfUxAuQ8wyLo=.6a917fa0-491b-4a4f-a42d-eba07c75c4d7@github.com> On Wed, 16 Mar 2022 21:10:14 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele 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: > > Addresses failure in NullClassTest on AIX. > > - Changes malloc(0) call to malloc(1) on AIX. p.s. this issue puts the finger on a sore point. We have corrected mallocs in the JDK in a number of places, e.g. in libverify: (https://github.com/openjdk/jdk/blob/3da5204b3c3a3f95bddcdcfe2628c2e0ed8a12d9/src/java.base/share/native/libverify/check_code.c#L91-L102) (which is also strictly speaking incorrect since the spec says to return a *non-unique* pointer). More generally, we have with AIX the problem that APIs have different behavior than the more usual nixes or are missing, and we need a porting layer to provide missing or change different APIs. Beside AIX-ish malloc, one example is dladdr, which is missing. In hotspot, we have os/aix, so we are fine. See `os/aix/hotspot/os/aix/porting_aix.cpp`. In the JDK I never found a good place for a porting layer, since the different JDK binaries don't have a common layer. So we have multiple versions of aix malloc and dladdr sprinkled across the libraries, which I always found embarrassing. (outside hotspot we implement dladdr at least in java.desktop/aix/native/libawt/porting_aix.c and java.base/aix/native/libjli/java_md_aix.c). If you find a way to commonize that code across JDK libraries, that would be cool. I even thought about providing a porting library completely independent from the OpenJDK itself, more like a system library. We did this for our internal iSeries port but the logistics were annoying, so we did not do it for AIX. But you at IBM may have a better idea. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From dholmes at openjdk.java.net Thu Mar 17 07:48:36 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 17 Mar 2022 07:48:36 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v3] In-Reply-To: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: On Wed, 16 Mar 2022 21:10:14 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele 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: > > Addresses failure in NullClassTest on AIX. > > - Changes malloc(0) call to malloc(1) on AIX. src/java.base/share/native/libjava/ClassLoader.c line 102: > 100: } > 101: > 102: // On malloc(0), implementators of malloc(3) have the choice to return either It is confusing to mix `malloc(0)`, where you are passing an argument zero to malloc, with `malloc(3)` which actually means the definition of malloc as per the man page in section 3. Given this is only an issue on AIX the comment can simply say: `// On AIX malloc(0) returns NULL which looks like an out-of-memory condition; so adjust it to malloc(1)`. src/java.base/share/native/libjava/ClassLoader.c line 106: > 104: // we chose the latter. (see 8283225) > 105: #ifdef _AIX > 106: body = (jbyte *)malloc(length == 0 ? 1 : length); Using AIX_ONLY this can be simplified: `body = (jbyte *)malloc(length AIX_ONLY( == 0 ? 1 : length));` ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From stuefe at openjdk.java.net Thu Mar 17 07:48:36 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Mar 2022 07:48:36 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v3] In-Reply-To: References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: On Thu, 17 Mar 2022 07:44:39 GMT, David Holmes wrote: > Using AIX_ONLY this can be simplified: > > `body = (jbyte *)malloc(length AIX_ONLY( == 0 ? 1 : length));` This is jdk, not hotspot. Do we have AIX_ONLY in the JDK? ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From forax at openjdk.java.net Thu Mar 17 07:57:34 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Thu, 17 Mar 2022 07:57:34 GMT Subject: RFR: 8283237: CallSite should be a sealed class In-Reply-To: <-R8o7djCc0mTodUXwCOiC65mtPfiMmUs4nFe1AjXdN4=.5d4a6a11-d93f-4b53-b481-01af7a17bfc2@github.com> References: <17YwNNOFLz2FAefoowpY81Dbh308gRIvm7aN7uasHTc=.c3229520-3062-45aa-9841-f9addcf47465@github.com> <-R8o7djCc0mTodUXwCOiC65mtPfiMmUs4nFe1AjXdN4=.5d4a6a11-d93f-4b53-b481-01af7a17bfc2@github.com> Message-ID: On Thu, 17 Mar 2022 07:32:40 GMT, liach wrote: >> src/java.base/share/classes/java/lang/invoke/CallSite.java line 88: >> >>> 86: */ >>> 87: public >>> 88: abstract sealed class CallSite permits ConstantCallSite, VolatileCallSite, MutableCallSite { >> >> Nitpicking with my JSR 292 hat, >> given that the permits clause is reflected in the javadoc, >> the order should be ConstantCS, MutableCS and VolatileCS, >> it's both in the lexical order and in the "memory access" of setTarget() order , from stronger access to weaker access. > > I agree that Constant, Mutable, Volatile order is better, ranked by the respective cost for `setTarget()` and (possibly) invocation, and earlier ones in the list are more preferable if conditions allow. > > However, in the current API documentation, the order is Constant, Mutable, and Volatile. Should I update that or leave it? > > /* > *
    > *
  • If a mutable target is not required, an {@code invokedynamic} instruction > * may be permanently bound by means of a {@linkplain ConstantCallSite constant call site}. > *
  • If a mutable target is required which has volatile variable semantics, > * because updates to the target must be immediately and reliably witnessed by other threads, > * a {@linkplain VolatileCallSite volatile call site} may be used. > *
  • Otherwise, if a mutable target is required, > * a {@linkplain MutableCallSite mutable call site} may be used. > *
> */ For me, this is unrelated, for this paragraph it's easier to explain the semantics of MutableCallSite with an otherwise, i.e. it's mutable but you do not want the cost of a volatile acces. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Thu Mar 17 08:07:23 2022 From: duke at openjdk.java.net (liach) Date: Thu, 17 Mar 2022 08:07:23 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v2] In-Reply-To: References: Message-ID: > Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. liach has updated the pull request incrementally with one additional commit since the last revision: Swap mutable and volatile in the permits list ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7840/files - new: https://git.openjdk.java.net/jdk/pull/7840/files/ff8996e6..eef61c31 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7840&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7840&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7840.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7840/head:pull/7840 PR: https://git.openjdk.java.net/jdk/pull/7840 From kbarrett at openjdk.java.net Thu Mar 17 08:11:35 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 17 Mar 2022 08:11:35 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: <56RtTkzVwR0C4EbxGlgynq3BsX9CKND7X90zY1anshQ=.51ba1f35-a9c3-453c-90f8-e0542c9fe54e@github.com> On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt wrote: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. > > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Changes requested by kbarrett (Reviewer). src/java.base/share/native/libverify/check_code.c line 472: > 470: > 471: static void check_and_push(context_type *context, void *ptr, int kind); > 472: static void check_and_push_const(context_type *context, const void *ptr, int kind); This really needs a comment explaining why two functions are needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From kbarrett at openjdk.java.net Thu Mar 17 08:51:35 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 17 Mar 2022 08:51:35 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt wrote: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. > > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Changes requested by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From kbarrett at openjdk.java.net Thu Mar 17 08:51:36 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 17 Mar 2022 08:51:36 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: <56RtTkzVwR0C4EbxGlgynq3BsX9CKND7X90zY1anshQ=.51ba1f35-a9c3-453c-90f8-e0542c9fe54e@github.com> References: <56RtTkzVwR0C4EbxGlgynq3BsX9CKND7X90zY1anshQ=.51ba1f35-a9c3-453c-90f8-e0542c9fe54e@github.com> Message-ID: On Thu, 17 Mar 2022 08:08:07 GMT, Kim Barrett wrote: >> Background, from JBS: >> >> src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': >> src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] >> 942 | check_and_push(context, lengths, VM_MALLOC_BLK); >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here >> 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) >> | ^~~~~~~~~~~~~~ >> >> >> Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. >> >> The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. >> >> >> Details: >> >> Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. >> >> To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. >> >> Testing: >> >> tier1 + builds-tier{2,3,4,5} > > src/java.base/share/native/libverify/check_code.c line 472: > >> 470: >> 471: static void check_and_push(context_type *context, void *ptr, int kind); >> 472: static void check_and_push_const(context_type *context, const void *ptr, int kind); > > This really needs a comment explaining why two functions are needed. I think it would be clearer to drop the kind argument and have two functions check_and_push_vm_string(context_type*, const char*) check_and_push_malloc_block(context_type*, void*) with a shared helper that is given the appropriate kind. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From kbarrett at openjdk.java.net Thu Mar 17 08:51:36 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Thu, 17 Mar 2022 08:51:36 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: <5bv0sOtKeAB5bJO0MHxbW0fiz3exeUpcMiWODdAIiBc=.3f59f6bf-0940-420b-b659-39410e6be713@github.com> References: <5bv0sOtKeAB5bJO0MHxbW0fiz3exeUpcMiWODdAIiBc=.3f59f6bf-0940-420b-b659-39410e6be713@github.com> Message-ID: On Thu, 17 Mar 2022 06:59:01 GMT, David Holmes wrote: >> Background, from JBS: >> >> src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': >> src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] >> 942 | check_and_push(context, lengths, VM_MALLOC_BLK); >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here >> 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) >> | ^~~~~~~~~~~~~~ >> >> >> Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. >> >> The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. >> >> >> Details: >> >> Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. >> >> To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. >> >> Testing: >> >> tier1 + builds-tier{2,3,4,5} > > src/java.base/share/native/libverify/check_code.c line 4168: > >> 4166: } >> 4167: >> 4168: static void check_and_push_const(context_type *context, const void *ptr, int kind) { > > IIUC the only `const` cases all pass a `const char*` so perhaps we can make that explicit in the signature? I confess I can't figure out how the passed in memory eventually gets used and it seems bizarre that it could be a freshly malloc'd block or an existing string. David - The check_and_push idiom checks if ptr is null, doing the out of memory handling if so. Otherwise, add ptr to a collection for later release. The kind determines how the release is done, either JVM_ReleaseUTF or free. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From redestad at openjdk.java.net Thu Mar 17 09:13:23 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Mar 2022 09:13:23 GMT Subject: RFR: 8281146: Replace StringCoding.hasNegatives with countPositives [v16] In-Reply-To: References: Message-ID: <1pPTN2fxiRObl90zDb2ObrnuKswJ7Z42TUox2-XDhSY=.e2c705ca-f057-45a0-b687-fc473bd28305@github.com> > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Disallow negative values in TestCountPositives test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7231/files - new: https://git.openjdk.java.net/jdk/pull/7231/files/bc5a8c80..6f22e1aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7231&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7231.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7231/head:pull/7231 PR: https://git.openjdk.java.net/jdk/pull/7231 From redestad at openjdk.java.net Thu Mar 17 09:24:38 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Mar 2022 09:24:38 GMT Subject: Integrated: 8281146: Replace StringCoding.hasNegatives with countPositives In-Reply-To: References: Message-ID: On Wed, 26 Jan 2022 12:51:31 GMT, Claes Redestad wrote: > I'm requesting comments and, hopefully, some help with this patch to replace `StringCoding.hasNegatives` with `countPositives`. The new method does a very similar pass, but alters the intrinsic to return the number of leading bytes in the `byte[]` range which only has positive bytes. This allows for dealing much more efficiently with those `byte[]`s that has a ASCII prefix, with no measurable cost on ASCII-only or latin1/UTF16-mostly input. > > Microbenchmark results: https://jmh.morethan.io/?gists=428b487e92e3e47ccb7f169501600a88,3c585de7435506d3a3bdb32160fe8904 > > - Only implemented on x86 for now, but I want to verify that implementations of `countPositives` can be implemented with similar efficiency on all platforms that today implement a `hasNegatives` intrinsic (aarch64, ppc etc) before moving ahead. This pretty much means holding up this until it's implemented on all platforms, which can either contributed to this PR or as dependent follow-ups. > > - An alternative to holding up until all platforms are on board is to allow the implementation of `StringCoding.hasNegatives` and `countPositives` to be implemented so that the non-intrinsified method calls into the intrinsified. This requires structuring the implementations differently based on which intrinsic - if any - is actually implemented. One way to do this could be to mimic how `java.nio` handles unaligned accesses and expose which intrinsic is available via `Unsafe` into a `static final` field. > > - There are a few minor regressions (~5%) in the x86 implementation on `encode-/decodeLatin1Short`. Those regressions disappear when mixing inputs, for example `encode-/decodeShortMixed` even see a minor improvement, which makes me consider those corner case regressions with little real world implications (if you have latin1 Strings, you're likely to also have ASCII-only strings in your mix). This pull request has now been integrated. Changeset: beedae11 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/beedae1141b6b650dc4cedf1f038afc1c8b460dd Stats: 619 lines in 36 files changed: 278 ins; 61 del; 280 mod 8281146: Replace StringCoding.hasNegatives with countPositives Co-authored-by: Lutz Schmidt Co-authored-by: Martin Doerr Reviewed-by: kvn, lucy, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7231 From stuefe at openjdk.java.net Thu Mar 17 10:50:33 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Mar 2022 10:50:33 GMT Subject: RFR: 8283287: Spring Cleaning for ClassLoader.c In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 21:25:37 GMT, Tyler Steele wrote: > As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c > > - Alphabetize includes. > - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. > - Replace 'return 0' with 'return NULL'. Looks good in general. Question inline. src/java.base/share/native/libjava/ClassLoader.c line 27: > 25: > 26: #include > 27: #include Whats errno.h for? ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From dfranken.jdk at gmail.com Thu Mar 17 12:49:08 2022 From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com) Date: Thu, 17 Mar 2022 13:49:08 +0100 Subject: Making enum hashcodes consistent across JVM's Message-ID: <7c9d2204778dfe802aefc3c319410ee8538511a9.camel@gmail.com> Dear all, Currently enums do not have a well-defined hashCode() implementation so they defer to Object.hashCode() which just uses an internal mechanism to determine the hashcode, likely based on the object's place in the heap. This may confuse a lot of developers as other classes such as String do have a well-defined hashcode which is consistent across multiple JVM's. Could it be a good idea to make enums' hashCode() method more reliably and predictable? For instance by using the hashcode of the name of its value? For example: class MyEnum { A, B } -> A.hashCode() == A.name().hashCode() Kind regards, Dave Franken From forax at univ-mlv.fr Thu Mar 17 13:20:04 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Mar 2022 14:20:04 +0100 (CET) Subject: Making enum hashcodes consistent across JVM's In-Reply-To: <7c9d2204778dfe802aefc3c319410ee8538511a9.camel@gmail.com> References: <7c9d2204778dfe802aefc3c319410ee8538511a9.camel@gmail.com> Message-ID: <547304969.18594004.1647523204438.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "dfranken jdk" > To: "core-libs-dev" > Sent: Thursday, March 17, 2022 1:49:08 PM > Subject: Making enum hashcodes consistent across JVM's > Dear all, > > Currently enums do not have a well-defined hashCode() implementation so > they defer to Object.hashCode() which just uses an internal mechanism > to determine the hashcode, likely based on the object's place in the > heap. No, and no. Enum.hashCode() is well defined, it is equivalent to super.hashCode() and it can not be overridden by a specific enum (see the javadoc). > > This may confuse a lot of developers as other classes such as String do > have a well-defined hashcode which is consistent across multiple JVM's. One of the reasons why String.hashCode() is defined is because the compiler (javac) compiles a switch on String using String.hashCode() so the hashCode at compile time and at runtime has to be the same. Having a well defined hashCode was a mistake, first it means that we can not change the implementation later (the current hashCode of String has too many collisions) and it also make DDOS attacks easier because you can pre-compute a list of strings with the same hashCode. > > Could it be a good idea to make enums' hashCode() method more reliably > and predictable? For instance by using the hashcode of the name of its > value? Enum already have a kind of perfect hash, ordinal() which is reliable and predictable but it's not a great value as hashCode. > > For example: > > class MyEnum { A, B } > -> A.hashCode() == A.name().hashCode() This is not a good hashCode, enum Foo { Aa, BB } Foo.Aa.hashCode() == Foo.BB.hashCode() > > Kind regards, > > Dave Franken regards, R?mi From erikj at openjdk.java.net Thu Mar 17 13:35:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Mar 2022 13:35:35 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From sgehwolf at openjdk.java.net Thu Mar 17 13:46:52 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 17 Mar 2022 13:46:52 GMT Subject: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize Message-ID: Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap limits. In such a case a passing test tells us nothing. Certainly not if the fix from [JDK-8242480](https://bugs.openjdk.java.net/browse/JDK-8242480) is present or not. Testing: - [x] Manual with and without the code fix of JDK-8242480. Still passes with the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. ------------- Commit messages: - 8283279: [Testbug] Improve TestGetSwapSpaceSize Changes: https://git.openjdk.java.net/jdk/pull/7854/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7854&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283279 Stats: 29 lines in 2 files changed: 22 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7854.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7854/head:pull/7854 PR: https://git.openjdk.java.net/jdk/pull/7854 From aph at openjdk.java.net Thu Mar 17 13:52:39 2022 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 17 Mar 2022 13:52:39 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v17] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 06:36:15 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > 8279508: Windows build failure fix. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4143: > 4141: ldmxcsr(new_mxcsr); > 4142: // Move raw bits corresponding to double value 0.5 into scratch register. > 4143: mov64(scratch, 4602678819172646912L); Suggestion: mov64(scratch, julong_cast(0.5)); ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From rriggs at openjdk.java.net Thu Mar 17 14:51:34 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Mar 2022 14:51:34 GMT Subject: RFR: 8283225: [AIX] ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 [v3] In-Reply-To: References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: On Thu, 17 Mar 2022 07:44:35 GMT, David Holmes wrote: >> Tyler Steele 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: >> >> Addresses failure in NullClassTest on AIX. >> >> - Changes malloc(0) call to malloc(1) on AIX. > > src/java.base/share/native/libjava/ClassLoader.c line 102: > >> 100: } >> 101: >> 102: // On malloc(0), implementators of malloc(3) have the choice to return either > > It is confusing to mix `malloc(0)`, where you are passing an argument zero to malloc, with `malloc(3)` which actually means the definition of malloc as per the man page in section 3. > > Given this is only an issue on AIX the comment can simply say: > > `// On AIX malloc(0) returns NULL which looks like an out-of-memory condition; so adjust it to malloc(1)`. I would omit the bug number reference, they get stale and do not age well, cluttering up the source. Git blame can be used to find the origin of the comment if needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From raffaello.giulietti at gmail.com Thu Mar 17 14:59:09 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 17 Mar 2022 15:59:09 +0100 Subject: Making enum hashcodes consistent across JVM's In-Reply-To: <7c9d2204778dfe802aefc3c319410ee8538511a9.camel@gmail.com> References: <7c9d2204778dfe802aefc3c319410ee8538511a9.camel@gmail.com> Message-ID: Hi, specifying a fixed hashCode() algorithm has the important drawback that it prevents evolution. For example, as you note, String has a strictly specified algorithm [1] that was perhaps a good one in the early days of Java (around 1995) but has shown its deficiencies over the years. In particular, it's easy to construct collisions, which might impact the performance of popular and heavily used hash based data structures, like HashMap and HashSet, under some forms of cyberattack. Unfortunately, while better String hash algorithms have been proposed, they cannot be adopted, as too much code out there relies on the specific details of String::hashCode. (Even bytecode for switches over String relies on that particular spec.) It's far too late now to change the spec, even for the better. In retrospect and IMO, fixing String::hashCode in the spec was a (understandable) mistake. More generally, client code that relies on details of any popular library hashCode() implementation has a dangerous dependency on such details and impairs evolution of the library itself (as the example with String shows). To leave the door open for better implementations proposed in some future, it is best to avoid specifying the details of hashCode(), as done in Record::hashCode [2] ("Implementation Requirements"). After all, the general contract reads [3]: "This integer [the hash] need not remain consistent from one execution of an application to another execution of the same application." But what is the use case you have for which you would like a firmly specified Enum::hashCode? Greetings Raffaello ---- [1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html#hashCode() [2] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Record.html#hashCode() [3] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Object.html#hashCode() On 2022-03-17 13:49, dfranken.jdk at gmail.com wrote: > Dear all, > > Currently enums do not have a well-defined hashCode() implementation so > they defer to Object.hashCode() which just uses an internal mechanism > to determine the hashcode, likely based on the object's place in the > heap. > > This may confuse a lot of developers as other classes such as String do > have a well-defined hashcode which is consistent across multiple JVM's. > > Could it be a good idea to make enums' hashCode() method more reliably > and predictable? For instance by using the hashcode of the name of its > value? > > For example: > > class MyEnum { A, B } > -> A.hashCode() == A.name().hashCode() > > Kind regards, > > Dave Franken From duke at openjdk.java.net Thu Mar 17 15:47:39 2022 From: duke at openjdk.java.net (liach) Date: Thu, 17 Mar 2022 15:47:39 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > add since in javadoc FYI in the CSR review, Joe Darcy points out: > Okay; I've looked over this CSR in more detail and think some additional supporting changes in java.util.Random should be made to address some existing shortcoming in the spec there. > > In particular, I think Random.setSeed's spec should be changed to have a general contract that it is an optional operation, i.e. may throw UnsupportedOperationException as ThreadLocalRandom.setSeed already does. The particulars of Random.setSeed should be moved into an implSpec, which would only apply to that non-overridden method. > > (More generally, java.util.Random would likely benefit from a pass to use implNote, implSpec, etc., but I think only setSeed needs to be adjusted for the purposes of this CSR.) > > Moving back to Provisional. So need an update to `Random.setSeed`'s API documentation and update the CSR correspondingly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Thu Mar 17 15:59:32 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 17 Mar 2022 15:59:32 GMT Subject: RFR: 8283287: ClassLoader.c cleanups In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 10:46:35 GMT, Thomas Stuefe wrote: >> As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c >> >> - Alphabetize includes. >> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. >> - Replace 'return 0' with 'return NULL'. > > src/java.base/share/native/libjava/ClassLoader.c line 27: > >> 25: >> 26: #include >> 27: #include > > Whats errno.h for? Thanks for catching that. It was for [the other PR](https://github.com/openjdk/jdk/pull/7829). ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From duke at openjdk.java.net Thu Mar 17 16:02:45 2022 From: duke at openjdk.java.net (jmehrens) Date: Thu, 17 Mar 2022 16:02:45 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > add since in javadoc Should RandomWrapper implement toString to include toString representation of the RandomGenerator? I would think that implementations of equals and hashCode are not needed but toString might be useful. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Thu Mar 17 16:08:11 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 17 Mar 2022 16:08:11 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v2] In-Reply-To: References: Message-ID: > As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c > > - Alphabetize includes. > - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. > - Replace 'return 0' with 'return NULL'. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: removes unneeded errno.h ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7846/files - new: https://git.openjdk.java.net/jdk/pull/7846/files/57a92415..920e76fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7846/head:pull/7846 PR: https://git.openjdk.java.net/jdk/pull/7846 From naoto at openjdk.java.net Thu Mar 17 16:15:30 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Mar 2022 16:15:30 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos LGTM. Thanks for the change, Magnus! ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From redestad at openjdk.java.net Thu Mar 17 16:17:21 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Mar 2022 16:17:21 GMT Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive Message-ID: Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. ------------- Commit messages: - Exhaustively consume ASCII bytes in String.decodeASCII Changes: https://git.openjdk.java.net/jdk/pull/7855/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7855&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283325 Stats: 57 lines in 2 files changed: 57 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7855/head:pull/7855 PR: https://git.openjdk.java.net/jdk/pull/7855 From duke at openjdk.java.net Thu Mar 17 16:23:14 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 17 Mar 2022 16:23:14 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: > As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. > > ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] > > In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. > > ### Alternatives > > It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. > > ### Testing > > This change has been tested on AIX and Linux/x86. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Improve comment - Reword to avoid double use of malloc(X) - Remove bug id ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7829/files - new: https://git.openjdk.java.net/jdk/pull/7829/files/f05c8d85..f0e2800e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7829&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7829&range=02-03 Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7829.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7829/head:pull/7829 PR: https://git.openjdk.java.net/jdk/pull/7829 From darcy at openjdk.java.net Thu Mar 17 16:41:35 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 17 Mar 2022 16:41:35 GMT Subject: Integrated: JDK-8283274: Improve @jvms usage in java.base In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 16:57:12 GMT, Joe Darcy wrote: > As was done for JLS references under JDK-8283234, now the analogous update for JVMS references. This pull request has now been integrated. Changeset: 5ef1990d Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/5ef1990d6ce35a85c86689badba465b6c8f9f4a1 Stats: 12 lines in 6 files changed: 0 ins; 0 del; 12 mod 8283274: Improve @jvms usage in java.base Reviewed-by: iris ------------- PR: https://git.openjdk.java.net/jdk/pull/7844 From jincheng at ca.ibm.com Thu Mar 17 16:42:57 2022 From: jincheng at ca.ibm.com (Cheng Jin) Date: Thu, 17 Mar 2022 16:42:57 +0000 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? Message-ID: Hi there, The document of https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#findStatic(java.lang.Class,java.lang.String,java.lang.invoke.MethodType) in the Java API is ambiguous in terms of when to initialize the method's class as follows (the same description as in other OpenJDK versions) If the returned method handle is invoked, the method's class will be initialized, if it has not already been initialized. It occurs to me that the method's class should be initialized when invoking the method handle but OpenJDK actually chooses to do the initialization in lookup.findStatic() rather than in mh.invoke() e.g. import java.lang.invoke.*; public class Test_1 { static MethodHandle mh = MethodHandles.lookup().findStatic(Test_2.class, "testMethod", MethodType.methodType(int.class, int.class)); <----------- Test_2.class gets initialized and verified. public static void main(String[] args) throws Throwable { Test_1.mh.invoke(); } } public class Test_2 { static int testMethod(int value) { return (value + 1); } } So there should be more clear explanation what is the correct or expected behaviour at this point and why OpenJDK doesn't comply with the document to delay the initialization of the method's class to mh.invoke(). Best Regards Cheng Jin From rriggs at openjdk.java.net Thu Mar 17 16:50:35 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Mar 2022 16:50:35 GMT Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:08:42 GMT, Claes Redestad wrote: > Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. In the test, it might be worth a comment that the 100_000 repeats is enough to warm up the compiler and use the intrinsic. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7855 From rriggs at openjdk.java.net Thu Mar 17 16:53:38 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Mar 2022 16:53:38 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: <5W6sLtGMj1n1tf-edYfV6j6mj458cq3xo_PhLzH-gfk=.11cf5b10-dd20-4c5d-85df-cedd7d69fa91@github.com> On Thu, 17 Mar 2022 16:23:14 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment > > - Reword to avoid double use of malloc(X) > - Remove bug id Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Thu Mar 17 16:53:39 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 17 Mar 2022 16:53:39 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v3] In-Reply-To: References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: On Thu, 17 Mar 2022 14:48:09 GMT, Roger Riggs wrote: >> src/java.base/share/native/libjava/ClassLoader.c line 102: >> >>> 100: } >>> 101: >>> 102: // On malloc(0), implementators of malloc(3) have the choice to return either >> >> It is confusing to mix `malloc(0)`, where you are passing an argument zero to malloc, with `malloc(3)` which actually means the definition of malloc as per the man page in section 3. >> >> Given this is only an issue on AIX the comment can simply say: >> >> `// On AIX malloc(0) returns NULL which looks like an out-of-memory condition; so adjust it to malloc(1)`. > > I would omit the bug number reference, they get stale and do not age well, cluttering up the source. > Git blame can be used to find the origin of the comment if needed. I changed to the streamlined comment and removed the bug id. Thanks for your suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Thu Mar 17 16:53:40 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Thu, 17 Mar 2022 16:53:40 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v3] In-Reply-To: References: <0sIw6glE1yELHwxvdL9BIVLj_jOCG9mV5uNbNrQBqpA=.41ded084-620e-46e3-a737-e6986f50d528@github.com> Message-ID: On Thu, 17 Mar 2022 07:46:21 GMT, Thomas Stuefe wrote: >> src/java.base/share/native/libjava/ClassLoader.c line 106: >> >>> 104: // we chose the latter. (see 8283225) >>> 105: #ifdef _AIX >>> 106: body = (jbyte *)malloc(length == 0 ? 1 : length); >> >> Using AIX_ONLY this can be simplified: >> >> `body = (jbyte *)malloc(length AIX_ONLY( == 0 ? 1 : length));` > >> Using AIX_ONLY this can be simplified: >> >> `body = (jbyte *)malloc(length AIX_ONLY( == 0 ? 1 : length));` > > This is jdk, not hotspot. Do we have AIX_ONLY in the JDK? As Thomas mentioned, this does not seem to work here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From rreddy at openjdk.java.net Thu Mar 17 16:56:15 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Thu, 17 Mar 2022 16:56:15 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() [v3] In-Reply-To: References: Message-ID: > Hi All, > > This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. > 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in > DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. > 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. > 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java > > Thanks, > Ravi Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: Modified the format of comments across the test case and also done clean up of test case by using less data providers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7804/files - new: https://git.openjdk.java.net/jdk/pull/7804/files/c50aa1bd..ac867083 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7804&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7804&range=01-02 Stats: 94 lines in 1 file changed: 32 ins; 20 del; 42 mod Patch: https://git.openjdk.java.net/jdk/pull/7804.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7804/head:pull/7804 PR: https://git.openjdk.java.net/jdk/pull/7804 From rreddy at openjdk.java.net Thu Mar 17 16:56:16 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Thu, 17 Mar 2022 16:56:16 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() [v2] In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 16:34:37 GMT, Ravi Reddy wrote: >> Hi All, >> >> This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. >> 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in >> DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. >> 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. >> 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > Modified write(byte []b) to write(byte[] b) to maintain same signature across the test case > Thanks Lance for the review , In the latest commit , I have formatted the comments in the test case. ------------- PR: https://git.openjdk.java.net/jdk/pull/7804 From duke at openjdk.java.net Thu Mar 17 17:02:27 2022 From: duke at openjdk.java.net (liach) Date: Thu, 17 Mar 2022 17:02:27 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v2] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 08:07:23 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Swap mutable and volatile in the permits list @jddarcy Could you help me file a CSR for this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From stuefe at openjdk.java.net Thu Mar 17 17:03:36 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 17 Mar 2022 17:03:36 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v2] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:08:11 GMT, Tyler Steele wrote: >> As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c >> >> - Alphabetize includes. >> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. >> - Replace 'return 0' with 'return NULL'. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > removes unneeded errno.h All good. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7846 From forax at univ-mlv.fr Thu Mar 17 17:36:47 2022 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 17 Mar 2022 18:36:47 +0100 (CET) Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: References: Message-ID: <1800064429.18782838.1647538607658.JavaMail.zimbra@u-pem.fr> ----- Original Message ----- > From: "Cheng Jin" > To: "core-libs-dev" > Sent: Thursday, March 17, 2022 5:42:57 PM > Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? > Hi there, > > The document of > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#findStatic(java.lang.Class,java.lang.String,java.lang.invoke.MethodType) > in the Java API is ambiguous in terms of when to initialize the method's class > as follows (the same description as in other OpenJDK versions) > > If the returned method handle is invoked, the method's class will be > initialized, if it has not already been initialized. > > > It occurs to me that the method's class should be initialized when invoking the > method handle but OpenJDK actually chooses to do the initialization in > lookup.findStatic() rather than in mh.invoke() > e.g. > import java.lang.invoke.*; > > public class Test_1 { > static MethodHandle mh = MethodHandles.lookup().findStatic(Test_2.class, > "testMethod", MethodType.methodType(int.class, int.class)); <----------- > Test_2.class gets initialized and verified. > > public static void main(String[] args) throws Throwable { > Test_1.mh.invoke(); > } > } > > public class Test_2 { > static int testMethod(int value) { return (value + 1); } > } > > So there should be more clear explanation what is the correct or expected > behaviour at this point and why OpenJDK doesn't comply with the document to > delay the initialization of the method's class to mh.invoke(). Hi, if by initialization you mean running the static block, then it's a bug. As far as i remember, the JVMS spec cleanly separate the Linking exceptions from the Runtime exceptions. https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html#jvms-6.5.invokestatic The linking exceptions occurs when calling findStatic() while the runtime exceptions will appear at runtime when calling invokeExact()/invoke(). > > Best Regards > Cheng Jin regards, R?mi From dfranken.jdk at gmail.com Thu Mar 17 17:55:04 2022 From: dfranken.jdk at gmail.com (dfranken.jdk at gmail.com) Date: Thu, 17 Mar 2022 18:55:04 +0100 Subject: Making enum hashcodes consistent across JVM's In-Reply-To: References: <7c9d2204778dfe802aefc3c319410ee8538511a9.camel@gmail.com> Message-ID: <33a41e4d804d267aa23fced319a2ce44505cc5ec.camel@gmail.com> Hi, Our use case is that we have different instances of an application running in a cloud environment and a precomputed hash code is used downstream to see if object instances generated in different application instances are the same or not. An enum was later added to our model which caused the weird behavior that instances generated by the same application instance had the same hash, but instances generated by another application instance did not. So it was weird to me that all of the other fields which either consisted of Strings, primitives, collections or elements ending in Strings and primitives generated the same hash code each time between applications and executions and enums did not. I understand now that relying on a specific hashcode implementation is foolish, but because String worked this way I thought it would be nice if enum worked this way too. But I realize now that the way String does it, is in fact wrong (but part of unchangeable history) instead of the other way around. Kind regards, Dave On Thu, 2022-03-17 at 15:59 +0100, Raffaello Giulietti wrote: > Hi, > > specifying a fixed hashCode() algorithm has the important drawback > that > it prevents evolution. > > For example, as you note, String has a strictly specified algorithm > [1] > that was perhaps a good one in the early days of Java (around 1995) > but > has shown its deficiencies over the years. In particular, it's easy > to > construct collisions, which might impact the performance of popular > and > heavily used hash based data structures, like HashMap and HashSet, > under > some forms of cyberattack. > > Unfortunately, while better String hash algorithms have been > proposed, > they cannot be adopted, as too much code out there relies on the > specific details of String::hashCode. (Even bytecode for switches > over > String relies on that particular spec.) It's far too late now to > change > the spec, even for the better. > > In retrospect and IMO, fixing String::hashCode in the spec was a > (understandable) mistake. > > > More generally, client code that relies on details of any popular > library hashCode() implementation has a dangerous dependency on such > details and impairs evolution of the library itself (as the example > with > String shows). > > To leave the door open for better implementations proposed in some > future, it is best to avoid specifying the details of hashCode(), as > done in Record::hashCode [2] ("Implementation Requirements"). After > all, > the general contract reads [3]: "This integer [the hash] need not > remain > consistent from one execution of an application to another execution > of > the same application." > > > But what is the use case you have for which you would like a firmly > specified Enum::hashCode? > > > Greetings > Raffaello > > ---- > > [1] > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/String.html#hashCode() > [2] > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Record.html#hashCode() > [3] > https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Object.html#hashCode() > > > > On 2022-03-17 13:49, dfranken.jdk at gmail.com?wrote: > > Dear all, > > > > Currently enums do not have a well-defined hashCode() > > implementation so > > they defer to Object.hashCode() which just uses an internal > > mechanism > > to determine the hashcode, likely based on the object's place in > > the > > heap. > > > > This may confuse a lot of developers as other classes such as > > String do > > have a well-defined hashcode which is consistent across multiple > > JVM's. > > > > Could it be a good idea to make enums' hashCode() method more > > reliably > > and predictable? For instance by using the hashcode of the name of > > its > > value? > > > > For example: > > > > class MyEnum { A, B } > > -> A.hashCode() == A.name().hashCode() > > > > Kind regards, > > > > Dave Franken From lancea at openjdk.java.net Thu Mar 17 18:01:31 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 17 Mar 2022 18:01:31 GMT Subject: RFR: 8278794: Infinite loop in DeflaterOutputStream.finish() [v3] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:56:15 GMT, Ravi Reddy wrote: >> Hi All, >> >> This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. >> 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in >> DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. >> 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. >> 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java >> >> Thanks, >> Ravi > > Ravi Reddy has updated the pull request incrementally with one additional commit since the last revision: > > Modified the format of comments across the test case and also done clean up of test case by using less data providers Hi Ravi, Thank you for cleaning up the comments. Much appreciated! ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7804 From dcubed at openjdk.java.net Thu Mar 17 18:29:41 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 17 Mar 2022 18:29:41 GMT Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:08:42 GMT, Claes Redestad wrote: > Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. @cl4es - are you planning to integrate your fix today? ------------- PR: https://git.openjdk.java.net/jdk/pull/7855 From naoto at openjdk.java.net Thu Mar 17 18:36:56 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 17 Mar 2022 18:36:56 GMT Subject: RFR: 8283277: ISO 4217 Amendment 171 Update Message-ID: This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1. ------------- Commit messages: - 8283277: ISO 4217 Amendment 171 Update Changes: https://git.openjdk.java.net/jdk/pull/7857/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7857&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283277 Stats: 17 lines in 6 files changed: 3 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7857.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7857/head:pull/7857 PR: https://git.openjdk.java.net/jdk/pull/7857 From raffaello.giulietti at gmail.com Thu Mar 17 19:38:08 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 17 Mar 2022 20:38:08 +0100 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: References: Message-ID: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> Hi, as far as I can see, the code should not even compile, as there's a static field in Test_1 which is initialized with an expression that throws checked exceptions (findStatic(..)). In addition, it seems to me that there's nothing in your code that reveals whether Test_2 has been initialized during the lookup. How can you tell? Finally, the method handle invocation in Test_1 will throw, as you don't pass any argument to a handle that expects one. Can you perhaps add more details? Greetings Raffaello On 2022-03-17 17:42, Cheng Jin wrote: > Hi there, > > The document of https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#findStatic(java.lang.Class,java.lang.String,java.lang.invoke.MethodType) in the Java API is ambiguous in terms of when to initialize the method's class as follows (the same description as in other OpenJDK versions) > > If the returned method handle is invoked, the method's class will be initialized, if it has not already been initialized. > > > It occurs to me that the method's class should be initialized when invoking the method handle but OpenJDK actually chooses to do the initialization in lookup.findStatic() rather than in mh.invoke() > e.g. > import java.lang.invoke.*; > > public class Test_1 { > static MethodHandle mh = MethodHandles.lookup().findStatic(Test_2.class, "testMethod", MethodType.methodType(int.class, int.class)); <----------- Test_2.class gets initialized and verified. > > public static void main(String[] args) throws Throwable { > Test_1.mh.invoke(); > } > } > > public class Test_2 { > static int testMethod(int value) { return (value + 1); } > } > > So there should be more clear explanation what is the correct or expected behaviour at this point and why OpenJDK doesn't comply with the document to delay the initialization of the method's class to mh.invoke(). > > Best Regards > Cheng Jin From redestad at openjdk.java.net Thu Mar 17 19:47:14 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Mar 2022 19:47:14 GMT Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive [v2] In-Reply-To: References: Message-ID: > Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add comment, remove redundant Arrays.fill ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7855/files - new: https://git.openjdk.java.net/jdk/pull/7855/files/aa0470cf..ef9fbaa7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7855&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7855&range=00-01 Stats: 6 lines in 1 file changed: 5 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7855.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7855/head:pull/7855 PR: https://git.openjdk.java.net/jdk/pull/7855 From raffaello.giulietti at gmail.com Thu Mar 17 19:53:57 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 17 Mar 2022 20:53:57 +0100 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> Message-ID: <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> Hi again, here's code that shows that initialization doesn't happen during lookup but only upon invoking the method handle. (I'm on Java 17.) As long as the 2nd line in main() is commented, you don't see the message "Test_2 initialized", which shows that the lookup doesn't initialize Test_2. When you uncomment the line in main(), the message will appear. So, as advertised, it's the invocation of the method handle that can trigger initialization, not the lookup. HTH Raffaello ---- import java.lang.invoke.*; public class Test_1 { static MethodHandle mh; static { try { mh = MethodHandles.lookup().findStatic(Test_2.class, "testMethod", MethodType.methodType(int.class, int.class)); } catch (NoSuchMethodException | IllegalAccessException e) { e.printStackTrace(); } } public static void main(String[] args) throws Throwable { System.out.println(mh); // System.out.println(Test_1.mh.invoke(0)); } } public class Test_2 { static { System.out.println("Test_2 initialized"); } static int testMethod(int value) { return (value + 1); } } On 2022-03-17 20:38, Raffaello Giulietti wrote: > Hi, > > as far as I can see, the code should not even compile, as there's a > static field in Test_1 which is initialized with an expression that > throws checked exceptions (findStatic(..)). > > In addition, it seems to me that there's nothing in your code that > reveals whether Test_2 has been initialized during the lookup. How can > you tell? > > Finally, the method handle invocation in Test_1 will throw, as you don't > pass any argument to a handle that expects one. > > Can you perhaps add more details? > > > Greetings > Raffaello > > > > On 2022-03-17 17:42, Cheng Jin wrote: >> Hi there, >> >> The document of >> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#findStatic(java.lang.Class,java.lang.String,java.lang.invoke.MethodType) >> in the Java API is ambiguous in terms of when to initialize the >> method's class as follows (the same description as in other OpenJDK >> versions) >> >> If the returned method handle is invoked, the method's class will be >> initialized, if it has not already been initialized. >> >> >> It occurs to me that the method's class should be initialized when >> invoking the method handle but OpenJDK actually chooses to do the >> initialization in lookup.findStatic() rather than in mh.invoke() >> e.g. >> import java.lang.invoke.*; >> >> public class Test_1 { >> ???? static MethodHandle mh = >> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >> MethodType.methodType(int.class, int.class)); <----------- >> Test_2.class gets initialized and verified. >> >> ???? public static void main(String[] args) throws Throwable { >> ???????? Test_1.mh.invoke(); >> ???? } >> } >> >> public class Test_2 { >> ???? static int testMethod(int value) { return (value + 1); } >> } >> >> So there should be more clear explanation what is the correct or >> expected behaviour at this point and why OpenJDK doesn't comply with >> the document to delay the initialization of the method's class to >> mh.invoke(). >> >> Best Regards >> Cheng Jin From dcubed at openjdk.java.net Thu Mar 17 20:19:30 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 17 Mar 2022 20:19:30 GMT Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive [v2] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 19:47:14 GMT, Claes Redestad wrote: >> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add comment, remove redundant Arrays.fill Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7855 From mikael at openjdk.java.net Thu Mar 17 20:23:27 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 17 Mar 2022 20:23:27 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: <56RtTkzVwR0C4EbxGlgynq3BsX9CKND7X90zY1anshQ=.51ba1f35-a9c3-453c-90f8-e0542c9fe54e@github.com> Message-ID: <7KWeORt9lZLD4vGRyIx1bs4TMpjo7jfl9afvDJ818pA=.fe9ac853-940b-427b-814c-1cbebcf559c5@github.com> On Thu, 17 Mar 2022 08:44:57 GMT, Kim Barrett wrote: >> src/java.base/share/native/libverify/check_code.c line 472: >> >>> 470: >>> 471: static void check_and_push(context_type *context, void *ptr, int kind); >>> 472: static void check_and_push_const(context_type *context, const void *ptr, int kind); >> >> This really needs a comment explaining why two functions are needed. > > I think it would be clearer to drop the kind argument and have two functions > check_and_push_vm_string(context_type*, const char*) > check_and_push_malloc_block(context_type*, void*) > with a shared helper that is given the appropriate kind. I had that at some point and then dropped it. I don't know why and it does seem like the better option so I'll try it again. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From mikael at openjdk.java.net Thu Mar 17 20:36:31 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 17 Mar 2022 20:36:31 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2] In-Reply-To: References: Message-ID: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. > > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Mikael Vidstedt has updated the pull request incrementally with 50 additional commits since the last revision: - Spell out check_and_push_malloc_block - Fix code - 8282773: Refactor parsing of integer VM options Reviewed-by: dholmes, kbarrett - 8283274: Improve @jvms usage in java.base Reviewed-by: iris - 8283188: Build time regression caused by JDK-8278917 Reviewed-by: kbarrett, tschatzl - 8283320: Error message for Windows libraries always points to --with-msvcr-dll no matter the actual file name Reviewed-by: erikj, ihse - 8283056: show abstract machine code in hs-err for all VM crashes Reviewed-by: thartmann, dholmes - 8282727: Parallel: Remove PSPromotionManager::_totally_drain Reviewed-by: tschatzl, kbarrett - 8281146: Replace StringCoding.hasNegatives with countPositives Co-authored-by: Lutz Schmidt Co-authored-by: Martin Doerr Reviewed-by: kvn, lucy, rriggs - 8282602: Refactor awt classes javadoc to use @throws instead of @exception Reviewed-by: aivanov, prr - ... and 40 more: https://git.openjdk.java.net/jdk/compare/baf72097...eb04d78a ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7794/files - new: https://git.openjdk.java.net/jdk/pull/7794/files/baf72097..eb04d78a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7794&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7794&range=00-01 Stats: 5146 lines in 353 files changed: 2567 ins; 553 del; 2026 mod Patch: https://git.openjdk.java.net/jdk/pull/7794.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7794/head:pull/7794 PR: https://git.openjdk.java.net/jdk/pull/7794 From mikael at openjdk.java.net Thu Mar 17 20:41:37 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 17 Mar 2022 20:41:37 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2] In-Reply-To: References: Message-ID: <3sOTl5HO9veV85GRl652rqU98ifypA7J6r4aTezpogY=.38fdf5f9-ee8f-4202-99df-e5b88e2c29f6@github.com> On Thu, 17 Mar 2022 20:36:31 GMT, Mikael Vidstedt wrote: >> Background, from JBS: >> >> src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': >> src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] >> 942 | check_and_push(context, lengths, VM_MALLOC_BLK); >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here >> 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) >> | ^~~~~~~~~~~~~~ >> >> >> Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. >> >> The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. >> >> >> Details: >> >> Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. >> >> To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. >> >> Testing: >> >> tier1 + builds-tier{2,3,4,5} > > Mikael Vidstedt has updated the pull request incrementally with 50 additional commits since the last revision: > > - Spell out check_and_push_malloc_block > - Fix code > - 8282773: Refactor parsing of integer VM options > > Reviewed-by: dholmes, kbarrett > - 8283274: Improve @jvms usage in java.base > > Reviewed-by: iris > - 8283188: Build time regression caused by JDK-8278917 > > Reviewed-by: kbarrett, tschatzl > - 8283320: Error message for Windows libraries always points to --with-msvcr-dll no matter the actual file name > > Reviewed-by: erikj, ihse > - 8283056: show abstract machine code in hs-err for all VM crashes > > Reviewed-by: thartmann, dholmes > - 8282727: Parallel: Remove PSPromotionManager::_totally_drain > > Reviewed-by: tschatzl, kbarrett > - 8281146: Replace StringCoding.hasNegatives with countPositives > > Co-authored-by: Lutz Schmidt > Co-authored-by: Martin Doerr > Reviewed-by: kvn, lucy, rriggs > - 8282602: Refactor awt classes javadoc to use @throws instead of @exception > > Reviewed-by: aivanov, prr > - ... and 40 more: https://git.openjdk.java.net/jdk/compare/baf72097...eb04d78a Um.. I think I managed to mess up this PR when I brought in latest master *and* tried it both with the current and new version of gcc. Sorry about that. I'll withdraw this one and open a new PR ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From mikael at openjdk.java.net Thu Mar 17 20:41:37 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 17 Mar 2022 20:41:37 GMT Subject: Withdrawn: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: <9DTGwoM365cLnKvhNa1qILH0CPYrpeHJ0FHJdpjoXLg=.52991b52-60e1-4313-be75-36407d60c2e4@github.com> On Fri, 11 Mar 2022 23:38:10 GMT, Mikael Vidstedt wrote: > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1. > > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794 From rriggs at openjdk.java.net Thu Mar 17 20:53:35 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Mar 2022 20:53:35 GMT Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive [v2] In-Reply-To: References: Message-ID: <83sEBnnK_z8hNvRykey_s_asBttxq0i0KpGBfMI0kMQ=.00e19da5-8e92-48ec-b5e4-8d03fc2682e5@github.com> On Thu, 17 Mar 2022 19:47:14 GMT, Claes Redestad wrote: >> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add comment, remove redundant Arrays.fill Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7855 From rriggs at openjdk.java.net Thu Mar 17 20:58:34 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 17 Mar 2022 20:58:34 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 15:57:58 GMT, Roger Riggs wrote: > The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. > The result is retention of the class loader. > > The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. > The test verifies that the process reaper threads have a null context classloader. Please Review. ------------- PR: https://git.openjdk.java.net/jdk/pull/7131 From mikael at openjdk.java.net Thu Mar 17 21:05:54 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 17 Mar 2022 21:05:54 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 Message-ID: Note: this PR replaces the one I messed up earlier. Background, from JBS: src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] 942 | check_and_push(context, lengths, VM_MALLOC_BLK); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) | ^~~~~~~~~~~~~~ Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. The same general issue was addressed in JDK-8266168, presumably for GCC 11.1. Details: Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function check_and_push_const which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. Testing: tier1 + builds-tier{2,3,4,5} ------------- Commit messages: - 8283059: Uninitialized warning in check_code.c with GCC 11.2 Changes: https://git.openjdk.java.net/jdk/pull/7859/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7859&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283059 Stats: 30 lines in 1 file changed: 9 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/7859.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7859/head:pull/7859 PR: https://git.openjdk.java.net/jdk/pull/7859 From redestad at openjdk.java.net Thu Mar 17 21:20:32 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Mar 2022 21:20:32 GMT Subject: RFR: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive [v2] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 19:47:14 GMT, Claes Redestad wrote: >> Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add comment, remove redundant Arrays.fill Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7855 From redestad at openjdk.java.net Thu Mar 17 21:20:33 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 17 Mar 2022 21:20:33 GMT Subject: Integrated: 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:08:42 GMT, Claes Redestad wrote: > Adjust `String.decodeASCII` to deal with the possibility that `StringCoding.countPositives` can return a value less than the exact number of leading positive bytes. This is the likely cause of a number of intermittent but somewhat common errors on aarch64 tests in our CI. This pull request has now been integrated. Changeset: 002e3667 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/002e3667443d94e2303c875daf72cf1ccbbb0099 Stats: 61 lines in 2 files changed: 61 ins; 0 del; 0 mod 8283325: US_ASCII decoder relies on String.decodeASCII being exhaustive Reviewed-by: rriggs, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/7855 From iris at openjdk.java.net Thu Mar 17 21:26:32 2022 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 17 Mar 2022 21:26:32 GMT Subject: RFR: 8283277: ISO 4217 Amendment 171 Update In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7857 From joehw at openjdk.java.net Thu Mar 17 22:27:34 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 17 Mar 2022 22:27:34 GMT Subject: RFR: 8283277: ISO 4217 Amendment 171 Update In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1. Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7857 From mikael at openjdk.java.net Thu Mar 17 22:28:31 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 17 Mar 2022 22:28:31 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 20:56:34 GMT, Mikael Vidstedt wrote: > Note: this PR replaces the one I messed up earlier. > > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in JDK-8266168, presumably for GCC 11.1. > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function check_and_push_const which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Added hotspot-runtime to the new version of the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7859 From jincheng at ca.ibm.com Thu Mar 17 23:02:11 2022 From: jincheng at ca.ibm.com (Cheng Jin) Date: Thu, 17 Mar 2022 23:02:11 +0000 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: <1800064429.18782838.1647538607658.JavaMail.zimbra@u-pem.fr> References: <1800064429.18782838.1647538607658.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Raffaello, The code snippet I posted previously was not the original test I verified on Java 17 (which was generated via asmtools to trigger verification) Here's the pretty much the test I used: Test_1.java import java.lang.invoke.*; public class Test_1 { static MethodHandle mh; static { try { mh = MethodHandles.lookup().findStatic(Test_2.class, "testMethod", MethodType.methodType(int[].class)); } catch (NoSuchMethodException | IllegalAccessException e) { e.printStackTrace(); } } public static void main(String[] args) throws Throwable { //Test_1.mh.invoke(); } } Test_2.jasm super public class Test_2 version 52:0 { static Method "":"()V" stack 5 locals 12 { bipush -2; istore 7; iload 7; sipush 997; if_icmplt L127; iconst_0; istore 8; L127: stack_frame_type full; locals_map int, class "[B", class "[B", class "[Ljava/lang/Class;", class "[I", class "[I", class "[I", int, bogus, bogus, float, float; iload 8; istore 8; return; } public Method "":"()V" stack 1 locals 1 { aload_0; invokespecial Method java/lang/Object."":"()V"; return; } static Method testMethod:"()[I" stack 6 locals 1 { getstatic Field testArray:"[I"; areturn; } } // end Class Test_2 Jdk17/bin/java -jar asmtools.jar jasm Test_2.jasm // create the .class file of Test_2 Jdk17/bin/java Test_1 java.lang.IllegalAccessException: no such method: Test_2.testMethod()int[]/invokeStatic at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:972) at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1117) at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3649) at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2588) at Test_1.(Test_1.java:9) Caused by: java.lang.VerifyError: Inconsistent stackmap frames at branch target 15 Exception Details: Location: Test_2.()V @15: iload Reason: Type top (current frame, locals[0]) is not assignable to integer (stack map, locals[0]) Current Frame: bci: @9 flags: { } locals: { top, top, top, top, top, top, top, integer } stack: { integer, integer } Stackmap Frame: bci: @15 flags: { } locals: { integer, '[B', '[B', '[Ljava/lang/Class;', '[I', '[I', '[I', integer, top, top, float, float } stack: { } Bytecode: 0000000: 10fe 3607 1507 1103 e5a1 0006 0336 0815 0000010: 0836 08b1 Stackmap Table: full_frame(@15,{Integer,Object[#11],Object[#11],Object[#20],Object[#5],Object[#5],Object[#5],Integer,Top,Top,Float,Float},{}) at java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method) at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1085) at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1114) ... 3 more -------- Test_2 was intentionally modified to throw VerifyError if initialized. As you see above, mh.inovke() was commented out in Test_1.main() but the Test_2 was still verified in the test. So it is impossible to verify Test_2 if it is not initialized, which only means Test_2 is initialized during the lookup.findstatic rather than mh.invoke(). Best Regards Cheng ----- Original Message ----- > From: "Cheng Jin" > To: "core-libs-dev" > Sent: Thursday, March 17, 2022 5:42:57 PM > Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? > Hi there, > > The document of > INVALID URI REMOVED > n_java_javase_17_docs_api_java.base_java_lang_invoke_MethodHandles.Loo > kup.html-23findStatic-28java.lang.Class-2Cjava.lang.String-2Cjava.lang > .invoke.MethodType-29&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=X90f3XIRXAH8 > hbNam6bIUlWfF_qUAezL9ue7M7bFuPQ&m=Xt-10pHYoPWnY6dByKowR4yeLtEs7kZkKUgt > bxKUGvM&s=dPAMGMxphLLXT9N4ZdukiNvWyvRPAGkcGCBLTy_sm0c&e= > in the Java API is ambiguous in terms of when to initialize the > method's class as follows (the same description as in other OpenJDK > versions) > > If the returned method handle is invoked, the method's class will be > initialized, if it has not already been initialized. > > > It occurs to me that the method's class should be initialized when > invoking the method handle but OpenJDK actually chooses to do the > initialization in > lookup.findStatic() rather than in mh.invoke() e.g. > import java.lang.invoke.*; > > public class Test_1 { > static MethodHandle mh = MethodHandles.lookup().findStatic(Test_2.class, > "testMethod", MethodType.methodType(int.class, int.class)); <----------- > Test_2.class gets initialized and verified. > > public static void main(String[] args) throws Throwable { > Test_1.mh.invoke(); > } > } > > public class Test_2 { > static int testMethod(int value) { return (value + 1); } } > > So there should be more clear explanation what is the correct or > expected behaviour at this point and why OpenJDK doesn't comply with > the document to delay the initialization of the method's class to mh.invoke(). Hi, if by initialization you mean running the static block, then it's a bug. As far as i remember, the JVMS spec cleanly separate the Linking exceptions from the Runtime exceptions. https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html#jvms-6.5.invokestatic The linking exceptions occurs when calling findStatic() while the runtime exceptions will appear at runtime when calling invokeExact()/invoke(). > > Best Regards > Cheng Jin regards, R?mi From david.holmes at oracle.com Thu Mar 17 23:46:20 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2022 09:46:20 +1000 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> Message-ID: <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> Run with -Xlog:class+init=info to see the classes that get initialized and in what order. David On 18/03/2022 5:53 am, Raffaello Giulietti wrote: > Hi again, > > here's code that shows that initialization doesn't happen during lookup > but only upon invoking the method handle. (I'm on Java 17.) > > As long as the 2nd line in main() is commented, you don't see the > message "Test_2 initialized", which shows that the lookup doesn't > initialize Test_2. > When you uncomment the line in main(), the message will appear. > > So, as advertised, it's the invocation of the method handle that can > trigger initialization, not the lookup. > > > HTH > Raffaello > > ---- > > import java.lang.invoke.*; > > public class Test_1 { > > ??? static MethodHandle mh; > > ??? static { > ??????? try { > ??????????? mh = MethodHandles.lookup().findStatic(Test_2.class, > "testMethod", MethodType.methodType(int.class, int.class)); > ??????? } catch (NoSuchMethodException | IllegalAccessException e) { > ??????????? e.printStackTrace(); > ??????? } > ??? } > > ??? public static void main(String[] args) throws Throwable { > ??????? System.out.println(mh); > ??????? // System.out.println(Test_1.mh.invoke(0)); > ??? } > > } > > > > > public class Test_2 { > > ??? static { > ??????? System.out.println("Test_2 initialized"); > ??? } > > ??? static int testMethod(int value) { return (value + 1); } > > } > > > > > On 2022-03-17 20:38, Raffaello Giulietti wrote: >> Hi, >> >> as far as I can see, the code should not even compile, as there's a >> static field in Test_1 which is initialized with an expression that >> throws checked exceptions (findStatic(..)). >> >> In addition, it seems to me that there's nothing in your code that >> reveals whether Test_2 has been initialized during the lookup. How can >> you tell? >> >> Finally, the method handle invocation in Test_1 will throw, as you >> don't pass any argument to a handle that expects one. >> >> Can you perhaps add more details? >> >> >> Greetings >> Raffaello >> >> >> >> On 2022-03-17 17:42, Cheng Jin wrote: >>> Hi there, >>> >>> The document of >>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#findStatic(java.lang.Class,java.lang.String,java.lang.invoke.MethodType) >>> in the Java API is ambiguous in terms of when to initialize the >>> method's class as follows (the same description as in other OpenJDK >>> versions) >>> >>> If the returned method handle is invoked, the method's class will be >>> initialized, if it has not already been initialized. >>> >>> >>> It occurs to me that the method's class should be initialized when >>> invoking the method handle but OpenJDK actually chooses to do the >>> initialization in lookup.findStatic() rather than in mh.invoke() >>> e.g. >>> import java.lang.invoke.*; >>> >>> public class Test_1 { >>> ???? static MethodHandle mh = >>> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >>> MethodType.methodType(int.class, int.class)); <----------- >>> Test_2.class gets initialized and verified. >>> >>> ???? public static void main(String[] args) throws Throwable { >>> ???????? Test_1.mh.invoke(); >>> ???? } >>> } >>> >>> public class Test_2 { >>> ???? static int testMethod(int value) { return (value + 1); } >>> } >>> >>> So there should be more clear explanation what is the correct or >>> expected behaviour at this point and why OpenJDK doesn't comply with >>> the document to delay the initialization of the method's class to >>> mh.invoke(). >>> >>> Best Regards >>> Cheng Jin From cushon at openjdk.java.net Thu Mar 17 23:52:44 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Thu, 17 Mar 2022 23:52:44 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking Message-ID: This change removes support for `-Dsun.misc.URLClassPath.disableJarChecking`. As discussed in the bug the feature doesn't current work, and only ever supported scenarios where a security manager is installed, so it seems safe to remove. ------------- Commit messages: - 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking Changes: https://git.openjdk.java.net/jdk/pull/7861/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7861&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283340 Stats: 25 lines in 1 file changed: 0 ins; 20 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7861.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7861/head:pull/7861 PR: https://git.openjdk.java.net/jdk/pull/7861 From raffaello.giulietti at gmail.com Fri Mar 18 00:11:39 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 18 Mar 2022 01:11:39 +0100 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> Message-ID: <8ae0c0df-5292-8527-4096-ad967fad14a8@gmail.com> Sure, which again shows that Test_2 is not initialized by the lookup of the mh but only upon its invocation. Raffaello On 2022-03-18 00:46, David Holmes wrote: > Run with -Xlog:class+init=info to see the classes that get initialized > and in what order. > > David > > On 18/03/2022 5:53 am, Raffaello Giulietti wrote: >> Hi again, >> >> here's code that shows that initialization doesn't happen during >> lookup but only upon invoking the method handle. (I'm on Java 17.) >> >> As long as the 2nd line in main() is commented, you don't see the >> message "Test_2 initialized", which shows that the lookup doesn't >> initialize Test_2. >> When you uncomment the line in main(), the message will appear. >> >> So, as advertised, it's the invocation of the method handle that can >> trigger initialization, not the lookup. >> >> >> HTH >> Raffaello >> >> ---- >> >> import java.lang.invoke.*; >> >> public class Test_1 { >> >> ???? static MethodHandle mh; >> >> ???? static { >> ???????? try { >> ???????????? mh = MethodHandles.lookup().findStatic(Test_2.class, >> "testMethod", MethodType.methodType(int.class, int.class)); >> ???????? } catch (NoSuchMethodException | IllegalAccessException e) { >> ???????????? e.printStackTrace(); >> ???????? } >> ???? } >> >> ???? public static void main(String[] args) throws Throwable { >> ???????? System.out.println(mh); >> ???????? // System.out.println(Test_1.mh.invoke(0)); >> ???? } >> >> } >> >> >> >> >> public class Test_2 { >> >> ???? static { >> ???????? System.out.println("Test_2 initialized"); >> ???? } >> >> ???? static int testMethod(int value) { return (value + 1); } >> >> } >> >> >> >> >> On 2022-03-17 20:38, Raffaello Giulietti wrote: >>> Hi, >>> >>> as far as I can see, the code should not even compile, as there's a >>> static field in Test_1 which is initialized with an expression that >>> throws checked exceptions (findStatic(..)). >>> >>> In addition, it seems to me that there's nothing in your code that >>> reveals whether Test_2 has been initialized during the lookup. How >>> can you tell? >>> >>> Finally, the method handle invocation in Test_1 will throw, as you >>> don't pass any argument to a handle that expects one. >>> >>> Can you perhaps add more details? >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> On 2022-03-17 17:42, Cheng Jin wrote: >>>> Hi there, >>>> >>>> The document of >>>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#findStatic(java.lang.Class,java.lang.String,java.lang.invoke.MethodType) >>>> in the Java API is ambiguous in terms of when to initialize the >>>> method's class as follows (the same description as in other OpenJDK >>>> versions) >>>> >>>> If the returned method handle is invoked, the method's class will be >>>> initialized, if it has not already been initialized. >>>> >>>> >>>> It occurs to me that the method's class should be initialized when >>>> invoking the method handle but OpenJDK actually chooses to do the >>>> initialization in lookup.findStatic() rather than in mh.invoke() >>>> e.g. >>>> import java.lang.invoke.*; >>>> >>>> public class Test_1 { >>>> ???? static MethodHandle mh = >>>> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >>>> MethodType.methodType(int.class, int.class)); <----------- >>>> Test_2.class gets initialized and verified. >>>> >>>> ???? public static void main(String[] args) throws Throwable { >>>> ???????? Test_1.mh.invoke(); >>>> ???? } >>>> } >>>> >>>> public class Test_2 { >>>> ???? static int testMethod(int value) { return (value + 1); } >>>> } >>>> >>>> So there should be more clear explanation what is the correct or >>>> expected behaviour at this point and why OpenJDK doesn't comply with >>>> the document to delay the initialization of the method's class to >>>> mh.invoke(). >>>> >>>> Best Regards >>>> Cheng Jin From raffaello.giulietti at gmail.com Fri Mar 18 00:20:43 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 18 Mar 2022 01:20:43 +0100 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: References: <1800064429.18782838.1647538607658.JavaMail.zimbra@u-pem.fr> Message-ID: <0c56d072-cf53-b6d9-c609-ee195008e791@gmail.com> Hi Cheng, I'm not sure I understand your point. By class initialization I mean what's specified in the JVMS [1]. Are you concerned with initialization or with verification (which precedes initialization)? Raffaello ---- [1] https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-5.html#jvms-5.5 On 2022-03-18 00:02, Cheng Jin wrote: > Hi Raffaello, > > The code snippet I posted previously was not the original test I verified on Java 17 (which was generated via asmtools to trigger verification) > > Here's the pretty much the test I used: > > Test_1.java > import java.lang.invoke.*; > > public class Test_1 { > > static MethodHandle mh; > > static { > try { > mh = MethodHandles.lookup().findStatic(Test_2.class, > "testMethod", MethodType.methodType(int[].class)); > } catch (NoSuchMethodException | IllegalAccessException e) { > e.printStackTrace(); > } > } > > public static void main(String[] args) throws Throwable { > //Test_1.mh.invoke(); > } > > } > > Test_2.jasm > super public class Test_2 > version 52:0 > { > static Method "":"()V" > stack 5 locals 12 > { > bipush -2; > istore 7; > iload 7; > sipush 997; > if_icmplt L127; > iconst_0; > istore 8; > L127: stack_frame_type full; > locals_map int, class "[B", class "[B", class "[Ljava/lang/Class;", class "[I", class "[I", class "[I", int, bogus, bogus, float, float; > iload 8; > istore 8; > return; > } > public Method "":"()V" > stack 1 locals 1 > { > aload_0; > invokespecial Method java/lang/Object."":"()V"; > return; > } > > static Method testMethod:"()[I" > stack 6 locals 1 > { > getstatic Field testArray:"[I"; > areturn; > } > > } // end Class Test_2 > > Jdk17/bin/java -jar asmtools.jar jasm Test_2.jasm // create the .class file of Test_2 > Jdk17/bin/java Test_1 > java.lang.IllegalAccessException: no such method: Test_2.testMethod()int[]/invokeStatic > at java.base/java.lang.invoke.MemberName.makeAccessException(MemberName.java:972) > at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1117) > at java.base/java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:3649) > at java.base/java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:2588) > at Test_1.(Test_1.java:9) > Caused by: java.lang.VerifyError: Inconsistent stackmap frames at branch target 15 > Exception Details: > Location: > Test_2.()V @15: iload > Reason: > Type top (current frame, locals[0]) is not assignable to integer (stack map, locals[0]) > Current Frame: > bci: @9 > flags: { } > locals: { top, top, top, top, top, top, top, integer } > stack: { integer, integer } > Stackmap Frame: > bci: @15 > flags: { } > locals: { integer, '[B', '[B', '[Ljava/lang/Class;', '[I', '[I', '[I', integer, top, top, float, float } > stack: { } > Bytecode: > 0000000: 10fe 3607 1507 1103 e5a1 0006 0336 0815 > 0000010: 0836 08b1 > Stackmap Table: > full_frame(@15,{Integer,Object[#11],Object[#11],Object[#20],Object[#5],Object[#5],Object[#5],Integer,Top,Top,Float,Float},{}) > > at java.base/java.lang.invoke.MethodHandleNatives.resolve(Native Method) > at java.base/java.lang.invoke.MemberName$Factory.resolve(MemberName.java:1085) > at java.base/java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1114) > ... 3 more > -------- > Test_2 was intentionally modified to throw VerifyError if initialized. > As you see above, mh.inovke() was commented out in Test_1.main() but the Test_2 was still verified in the test. > So it is impossible to verify Test_2 if it is not initialized, which only means Test_2 is initialized during the lookup.findstatic rather than mh.invoke(). > > Best Regards > Cheng > > ----- Original Message ----- >> From: "Cheng Jin" >> To: "core-libs-dev" >> Sent: Thursday, March 17, 2022 5:42:57 PM >> Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? > >> Hi there, >> >> The document of >> INVALID URI REMOVED >> n_java_javase_17_docs_api_java.base_java_lang_invoke_MethodHandles.Loo >> kup.html-23findStatic-28java.lang.Class-2Cjava.lang.String-2Cjava.lang >> .invoke.MethodType-29&d=DwIFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=X90f3XIRXAH8 >> hbNam6bIUlWfF_qUAezL9ue7M7bFuPQ&m=Xt-10pHYoPWnY6dByKowR4yeLtEs7kZkKUgt >> bxKUGvM&s=dPAMGMxphLLXT9N4ZdukiNvWyvRPAGkcGCBLTy_sm0c&e= >> in the Java API is ambiguous in terms of when to initialize the >> method's class as follows (the same description as in other OpenJDK >> versions) >> >> If the returned method handle is invoked, the method's class will be >> initialized, if it has not already been initialized. >> >> >> It occurs to me that the method's class should be initialized when >> invoking the method handle but OpenJDK actually chooses to do the >> initialization in >> lookup.findStatic() rather than in mh.invoke() e.g. >> import java.lang.invoke.*; >> >> public class Test_1 { >> static MethodHandle mh = MethodHandles.lookup().findStatic(Test_2.class, >> "testMethod", MethodType.methodType(int.class, int.class)); <----------- >> Test_2.class gets initialized and verified. >> >> public static void main(String[] args) throws Throwable { >> Test_1.mh.invoke(); >> } >> } >> >> public class Test_2 { >> static int testMethod(int value) { return (value + 1); } } >> >> So there should be more clear explanation what is the correct or >> expected behaviour at this point and why OpenJDK doesn't comply with >> the document to delay the initialization of the method's class to mh.invoke(). > > Hi, > if by initialization you mean running the static block, then it's a bug. > > As far as i remember, the JVMS spec cleanly separate the Linking exceptions from the Runtime exceptions. > https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-6.html#jvms-6.5.invokestatic > > The linking exceptions occurs when calling findStatic() while the runtime exceptions will appear at runtime when calling invokeExact()/invoke(). > >> >> Best Regards >> Cheng Jin > > regards, > R?mi From jincheng at ca.ibm.com Fri Mar 18 00:21:35 2022 From: jincheng at ca.ibm.com (Cheng Jin) Date: Fri, 18 Mar 2022 00:21:35 +0000 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> Message-ID: Hi David, 1) for the test with mh.invoke() in main(), the log shows: [0.262s][info][class,init] Start class verification for: Test_1 [0.262s][info][class,init] End class verification for: Test_1 [0.263s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) [0.263s][info][class,init] Start class verification for: Test_2 [0.263s][info][class,init] End class verification for: Test_2 [0.272s][info][class,init] 366 Initializing 'Test_2' (0x0000000800c00a08) <------ 2) for the test without mh.invoke() in main(), the log shows: [0.296s][info][class,init] Start class verification for: Test_1 [0.296s][info][class,init] End class verification for: Test_1 [0.297s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) [0.297s][info][class,init] Start class verification for: Test_2 [0.297s][info][class,init] End class verification for: Test_2 (Test_2 was verified but didn't get initialized) The comparison above literally surprised me that the bytecode verification happened prior to the class initialization, which means the class got verified at first even without initialization coz I previously thought the initialization should trigger the verification rather than in the reversed order. Could you explain a little more about why it goes in this way? Best Regards Cheng -----Original Message----- From: core-libs-dev On Behalf Of David Holmes Sent: March 17, 2022 7:46 PM To: Raffaello Giulietti ; core-libs-dev at openjdk.java.net Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? Run with -Xlog:class+init=info to see the classes that get initialized and in what order. David On 18/03/2022 5:53 am, Raffaello Giulietti wrote: > Hi again, > > here's code that shows that initialization doesn't happen during > lookup but only upon invoking the method handle. (I'm on Java 17.) > > As long as the 2nd line in main() is commented, you don't see the > message "Test_2 initialized", which shows that the lookup doesn't > initialize Test_2. > When you uncomment the line in main(), the message will appear. > > So, as advertised, it's the invocation of the method handle that can > trigger initialization, not the lookup. > > > HTH > Raffaello > > ---- > > import java.lang.invoke.*; > > public class Test_1 { > > ??? static MethodHandle mh; > > ??? static { > ??????? try { > ??????????? mh = MethodHandles.lookup().findStatic(Test_2.class, > "testMethod", MethodType.methodType(int.class, int.class)); > ??????? } catch (NoSuchMethodException | IllegalAccessException e) { > ??????????? e.printStackTrace(); > ??????? } > ??? } > > ??? public static void main(String[] args) throws Throwable { > ??????? System.out.println(mh); > ??????? // System.out.println(Test_1.mh.invoke(0)); > ??? } > > } > > > > > public class Test_2 { > > ??? static { > ??????? System.out.println("Test_2 initialized"); > ??? } > > ??? static int testMethod(int value) { return (value + 1); } > > } > > > > > On 2022-03-17 20:38, Raffaello Giulietti wrote: >> Hi, >> >> as far as I can see, the code should not even compile, as there's a >> static field in Test_1 which is initialized with an expression that >> throws checked exceptions (findStatic(..)). >> >> In addition, it seems to me that there's nothing in your code that >> reveals whether Test_2 has been initialized during the lookup. How >> can you tell? >> >> Finally, the method handle invocation in Test_1 will throw, as you >> don't pass any argument to a handle that expects one. >> >> Can you perhaps add more details? >> >> >> Greetings >> Raffaello >> >> >> >> On 2022-03-17 17:42, Cheng Jin wrote: >>> Hi there, >>> >>> The document of >>> INVALID URI REMOVED >>> _en_java_javase_17_docs_api_java.base_java_lang_invoke_MethodHandles >>> .Lookup.html-23findStatic-28java.lang.Class-2Cjava.lang.String-2Cjav >>> a.lang.invoke.MethodType-29&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=X90f >>> 3XIRXAH8hbNam6bIUlWfF_qUAezL9ue7M7bFuPQ&m=RvhguidNJ90V-HK-3Ctl-kUZE5 >>> cIfo_nt3_r8VZ0Fcc&s=tw_ph6oUkS0eCvzITWi9zEkarss5yNeHDrAIfvd3s3g&e= >>> in the Java API is ambiguous in terms of when to initialize the >>> method's class as follows (the same description as in other OpenJDK >>> versions) >>> >>> If the returned method handle is invoked, the method's class will be >>> initialized, if it has not already been initialized. >>> >>> >>> It occurs to me that the method's class should be initialized when >>> invoking the method handle but OpenJDK actually chooses to do the >>> initialization in lookup.findStatic() rather than in mh.invoke() >>> e.g. >>> import java.lang.invoke.*; >>> >>> public class Test_1 { >>> ???? static MethodHandle mh = >>> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >>> MethodType.methodType(int.class, int.class)); <----------- >>> Test_2.class gets initialized and verified. >>> >>> ???? public static void main(String[] args) throws Throwable { >>> ???????? Test_1.mh.invoke(); >>> ???? } >>> } >>> >>> public class Test_2 { >>> ???? static int testMethod(int value) { return (value + 1); } } >>> >>> So there should be more clear explanation what is the correct or >>> expected behaviour at this point and why OpenJDK doesn't comply with >>> the document to delay the initialization of the method's class to >>> mh.invoke(). >>> >>> Best Regards >>> Cheng Jin From duke at openjdk.java.net Fri Mar 18 00:28:36 2022 From: duke at openjdk.java.net (Yasser Bazzi) Date: Fri, 18 Mar 2022 00:28:36 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > add since in javadoc The toString method of both classes do not implement anything so i dont think we should override it, also as per request of Joe Darcy how should we proceed with the annotation of implSpec? ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From raffaello.giulietti at gmail.com Fri Mar 18 00:34:35 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 18 Mar 2022 01:34:35 +0100 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> Message-ID: Cheng, initialization is the last thing that happens because it's where user provided code gets executed. This has always been this way, as long as I can remember. See the JVMS for the gory details. Greetings Raffaello On 2022-03-18 01:21, Cheng Jin wrote: > Hi David, > > 1) for the test with mh.invoke() in main(), the log shows: > [0.262s][info][class,init] Start class verification for: Test_1 > [0.262s][info][class,init] End class verification for: Test_1 > [0.263s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) > [0.263s][info][class,init] Start class verification for: Test_2 > [0.263s][info][class,init] End class verification for: Test_2 > [0.272s][info][class,init] 366 Initializing 'Test_2' (0x0000000800c00a08) <------ > > 2) for the test without mh.invoke() in main(), the log shows: > [0.296s][info][class,init] Start class verification for: Test_1 > [0.296s][info][class,init] End class verification for: Test_1 > [0.297s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) > [0.297s][info][class,init] Start class verification for: Test_2 > [0.297s][info][class,init] End class verification for: Test_2 > (Test_2 was verified but didn't get initialized) > > The comparison above literally surprised me that the bytecode verification happened prior to the class initialization, which means > the class got verified at first even without initialization coz I previously thought the initialization should trigger the verification rather than in the reversed order. > > Could you explain a little more about why it goes in this way? > > Best Regards > Cheng > > > -----Original Message----- > From: core-libs-dev On Behalf Of David Holmes > Sent: March 17, 2022 7:46 PM > To: Raffaello Giulietti ; core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? > > Run with -Xlog:class+init=info to see the classes that get initialized and in what order. > > David > > On 18/03/2022 5:53 am, Raffaello Giulietti wrote: >> Hi again, >> >> here's code that shows that initialization doesn't happen during >> lookup but only upon invoking the method handle. (I'm on Java 17.) >> >> As long as the 2nd line in main() is commented, you don't see the >> message "Test_2 initialized", which shows that the lookup doesn't >> initialize Test_2. >> When you uncomment the line in main(), the message will appear. >> >> So, as advertised, it's the invocation of the method handle that can >> trigger initialization, not the lookup. >> >> >> HTH >> Raffaello >> >> ---- >> >> import java.lang.invoke.*; >> >> public class Test_1 { >> >> ??? static MethodHandle mh; >> >> ??? static { >> ??????? try { >> ??????????? mh = MethodHandles.lookup().findStatic(Test_2.class, >> "testMethod", MethodType.methodType(int.class, int.class)); >> ??????? } catch (NoSuchMethodException | IllegalAccessException e) { >> ??????????? e.printStackTrace(); >> ??????? } >> ??? } >> >> ??? public static void main(String[] args) throws Throwable { >> ??????? System.out.println(mh); >> ??????? // System.out.println(Test_1.mh.invoke(0)); >> ??? } >> >> } >> >> >> >> >> public class Test_2 { >> >> ??? static { >> ??????? System.out.println("Test_2 initialized"); >> ??? } >> >> ??? static int testMethod(int value) { return (value + 1); } >> >> } >> >> >> >> >> On 2022-03-17 20:38, Raffaello Giulietti wrote: >>> Hi, >>> >>> as far as I can see, the code should not even compile, as there's a >>> static field in Test_1 which is initialized with an expression that >>> throws checked exceptions (findStatic(..)). >>> >>> In addition, it seems to me that there's nothing in your code that >>> reveals whether Test_2 has been initialized during the lookup. How >>> can you tell? >>> >>> Finally, the method handle invocation in Test_1 will throw, as you >>> don't pass any argument to a handle that expects one. >>> >>> Can you perhaps add more details? >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> On 2022-03-17 17:42, Cheng Jin wrote: >>>> Hi there, >>>> >>>> The document of >>>> INVALID URI REMOVED >>>> _en_java_javase_17_docs_api_java.base_java_lang_invoke_MethodHandles >>>> .Lookup.html-23findStatic-28java.lang.Class-2Cjava.lang.String-2Cjav >>>> a.lang.invoke.MethodType-29&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=X90f >>>> 3XIRXAH8hbNam6bIUlWfF_qUAezL9ue7M7bFuPQ&m=RvhguidNJ90V-HK-3Ctl-kUZE5 >>>> cIfo_nt3_r8VZ0Fcc&s=tw_ph6oUkS0eCvzITWi9zEkarss5yNeHDrAIfvd3s3g&e= >>>> in the Java API is ambiguous in terms of when to initialize the >>>> method's class as follows (the same description as in other OpenJDK >>>> versions) >>>> >>>> If the returned method handle is invoked, the method's class will be >>>> initialized, if it has not already been initialized. >>>> >>>> >>>> It occurs to me that the method's class should be initialized when >>>> invoking the method handle but OpenJDK actually chooses to do the >>>> initialization in lookup.findStatic() rather than in mh.invoke() >>>> e.g. >>>> import java.lang.invoke.*; >>>> >>>> public class Test_1 { >>>> ???? static MethodHandle mh = >>>> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >>>> MethodType.methodType(int.class, int.class)); <----------- >>>> Test_2.class gets initialized and verified. >>>> >>>> ???? public static void main(String[] args) throws Throwable { >>>> ???????? Test_1.mh.invoke(); >>>> ???? } >>>> } >>>> >>>> public class Test_2 { >>>> ???? static int testMethod(int value) { return (value + 1); } } >>>> >>>> So there should be more clear explanation what is the correct or >>>> expected behaviour at this point and why OpenJDK doesn't comply with >>>> the document to delay the initialization of the method's class to >>>> mh.invoke(). >>>> >>>> Best Regards >>>> Cheng Jin From jincheng at ca.ibm.com Fri Mar 18 00:51:33 2022 From: jincheng at ca.ibm.com (Cheng Jin) Date: Fri, 18 Mar 2022 00:51:33 +0000 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> Message-ID: Hi Raffaello, My concern is why the verification happens even without initialization in the test without mh.invoke() in the main(), which I don't think is covered or explained in the JVM Spec. Put it in another way, my understanding is, when the class gets loaded, it is verified which doesn't necessarily lead to initialization, am I correct? Best Regards Cheng -----Original Message----- From: core-libs-dev On Behalf Of Raffaello Giulietti Sent: March 17, 2022 8:35 PM To: core-libs-dev at openjdk.java.net Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? Cheng, initialization is the last thing that happens because it's where user provided code gets executed. This has always been this way, as long as I can remember. See the JVMS for the gory details. Greetings Raffaello On 2022-03-18 01:21, Cheng Jin wrote: > Hi David, > > 1) for the test with mh.invoke() in main(), the log shows: > [0.262s][info][class,init] Start class verification for: Test_1 > [0.262s][info][class,init] End class verification for: Test_1 > [0.263s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) > [0.263s][info][class,init] Start class verification for: Test_2 > [0.263s][info][class,init] End class verification for: Test_2 > [0.272s][info][class,init] 366 Initializing 'Test_2' (0x0000000800c00a08) <------ > > 2) for the test without mh.invoke() in main(), the log shows: > [0.296s][info][class,init] Start class verification for: Test_1 > [0.296s][info][class,init] End class verification for: Test_1 > [0.297s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) > [0.297s][info][class,init] Start class verification for: Test_2 > [0.297s][info][class,init] End class verification for: Test_2 > (Test_2 was verified but didn't get initialized) > > The comparison above literally surprised me that the bytecode verification happened prior to the class initialization, which means > the class got verified at first even without initialization coz I previously thought the initialization should trigger the verification rather than in the reversed order. > > Could you explain a little more about why it goes in this way? > > Best Regards > Cheng > > > -----Original Message----- > From: core-libs-dev On Behalf Of David Holmes > Sent: March 17, 2022 7:46 PM > To: Raffaello Giulietti ; core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? > > Run with -Xlog:class+init=info to see the classes that get initialized and in what order. > > David > > On 18/03/2022 5:53 am, Raffaello Giulietti wrote: >> Hi again, >> >> here's code that shows that initialization doesn't happen during >> lookup but only upon invoking the method handle. (I'm on Java 17.) >> >> As long as the 2nd line in main() is commented, you don't see the >> message "Test_2 initialized", which shows that the lookup doesn't >> initialize Test_2. >> When you uncomment the line in main(), the message will appear. >> >> So, as advertised, it's the invocation of the method handle that can >> trigger initialization, not the lookup. >> >> >> HTH >> Raffaello >> >> ---- >> >> import java.lang.invoke.*; >> >> public class Test_1 { >> >> ??? static MethodHandle mh; >> >> ??? static { >> ??????? try { >> ??????????? mh = MethodHandles.lookup().findStatic(Test_2.class, >> "testMethod", MethodType.methodType(int.class, int.class)); >> ??????? } catch (NoSuchMethodException | IllegalAccessException e) { >> ??????????? e.printStackTrace(); >> ??????? } >> ??? } >> >> ??? public static void main(String[] args) throws Throwable { >> ??????? System.out.println(mh); >> ??????? // System.out.println(Test_1.mh.invoke(0)); >> ??? } >> >> } >> >> >> >> >> public class Test_2 { >> >> ??? static { >> ??????? System.out.println("Test_2 initialized"); >> ??? } >> >> ??? static int testMethod(int value) { return (value + 1); } >> >> } >> >> >> >> >> On 2022-03-17 20:38, Raffaello Giulietti wrote: >>> Hi, >>> >>> as far as I can see, the code should not even compile, as there's a >>> static field in Test_1 which is initialized with an expression that >>> throws checked exceptions (findStatic(..)). >>> >>> In addition, it seems to me that there's nothing in your code that >>> reveals whether Test_2 has been initialized during the lookup. How >>> can you tell? >>> >>> Finally, the method handle invocation in Test_1 will throw, as you >>> don't pass any argument to a handle that expects one. >>> >>> Can you perhaps add more details? >>> >>> >>> Greetings >>> Raffaello >>> >>> >>> >>> On 2022-03-17 17:42, Cheng Jin wrote: >>>> Hi there, >>>> >>>> The document of >>>> INVALID URI REMOVED >>>> _en_java_javase_17_docs_api_java.base_java_lang_invoke_MethodHandles >>>> .Lookup.html-23findStatic-28java.lang.Class-2Cjava.lang.String-2Cjav >>>> a.lang.invoke.MethodType-29&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=X90f >>>> 3XIRXAH8hbNam6bIUlWfF_qUAezL9ue7M7bFuPQ&m=RvhguidNJ90V-HK-3Ctl-kUZE5 >>>> cIfo_nt3_r8VZ0Fcc&s=tw_ph6oUkS0eCvzITWi9zEkarss5yNeHDrAIfvd3s3g&e= >>>> in the Java API is ambiguous in terms of when to initialize the >>>> method's class as follows (the same description as in other OpenJDK >>>> versions) >>>> >>>> If the returned method handle is invoked, the method's class will be >>>> initialized, if it has not already been initialized. >>>> >>>> >>>> It occurs to me that the method's class should be initialized when >>>> invoking the method handle but OpenJDK actually chooses to do the >>>> initialization in lookup.findStatic() rather than in mh.invoke() >>>> e.g. >>>> import java.lang.invoke.*; >>>> >>>> public class Test_1 { >>>> ???? static MethodHandle mh = >>>> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >>>> MethodType.methodType(int.class, int.class)); <----------- >>>> Test_2.class gets initialized and verified. >>>> >>>> ???? public static void main(String[] args) throws Throwable { >>>> ???????? Test_1.mh.invoke(); >>>> ???? } >>>> } >>>> >>>> public class Test_2 { >>>> ???? static int testMethod(int value) { return (value + 1); } } >>>> >>>> So there should be more clear explanation what is the correct or >>>> expected behaviour at this point and why OpenJDK doesn't comply with >>>> the document to delay the initialization of the method's class to >>>> mh.invoke(). >>>> >>>> Best Regards >>>> Cheng Jin From raffaello.giulietti at gmail.com Fri Mar 18 01:07:02 2022 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Fri, 18 Mar 2022 02:07:02 +0100 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> Message-ID: OK, from what I read so far from you is that you were surprised about the order, not about why verification happens even without initialization. Verification is part of linking, which surely must happen before user code (e.g., initialization) is executed, which explains the order. But once linked (thus, verified), there's no pressure to have initialization code (user code) executed. This can wait until the very last moment, when some other code of the class is invoked, or some field is accessed, or an instance is created, etc. It's a lazy execution strategy, which the JVM spec allows and which HotSpot implements this way. HTH Raffaello On 2022-03-18 01:51, Cheng Jin wrote: > Hi Raffaello, > > My concern is why the verification happens even without initialization in the test without mh.invoke() in the main(), which I don't think is covered or explained in the JVM Spec. > Put it in another way, my understanding is, when the class gets loaded, it is verified which doesn't necessarily lead to initialization, am I correct? > > Best Regards > Cheng > > -----Original Message----- > From: core-libs-dev On Behalf Of Raffaello Giulietti > Sent: March 17, 2022 8:35 PM > To: core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? > > Cheng, > > initialization is the last thing that happens because it's where user provided code gets executed. > > This has always been this way, as long as I can remember. See the JVMS for the gory details. > > > Greetings > Raffaello > > > On 2022-03-18 01:21, Cheng Jin wrote: >> Hi David, >> >> 1) for the test with mh.invoke() in main(), the log shows: >> [0.262s][info][class,init] Start class verification for: Test_1 >> [0.262s][info][class,init] End class verification for: Test_1 >> [0.263s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) >> [0.263s][info][class,init] Start class verification for: Test_2 >> [0.263s][info][class,init] End class verification for: Test_2 >> [0.272s][info][class,init] 366 Initializing 'Test_2' (0x0000000800c00a08) <------ >> >> 2) for the test without mh.invoke() in main(), the log shows: >> [0.296s][info][class,init] Start class verification for: Test_1 >> [0.296s][info][class,init] End class verification for: Test_1 >> [0.297s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) >> [0.297s][info][class,init] Start class verification for: Test_2 >> [0.297s][info][class,init] End class verification for: Test_2 >> (Test_2 was verified but didn't get initialized) >> >> The comparison above literally surprised me that the bytecode verification happened prior to the class initialization, which means >> the class got verified at first even without initialization coz I previously thought the initialization should trigger the verification rather than in the reversed order. >> >> Could you explain a little more about why it goes in this way? >> >> Best Regards >> Cheng >> >> >> -----Original Message----- >> From: core-libs-dev On Behalf Of David Holmes >> Sent: March 17, 2022 7:46 PM >> To: Raffaello Giulietti ; core-libs-dev at openjdk.java.net >> Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? >> >> Run with -Xlog:class+init=info to see the classes that get initialized and in what order. >> >> David >> >> On 18/03/2022 5:53 am, Raffaello Giulietti wrote: >>> Hi again, >>> >>> here's code that shows that initialization doesn't happen during >>> lookup but only upon invoking the method handle. (I'm on Java 17.) >>> >>> As long as the 2nd line in main() is commented, you don't see the >>> message "Test_2 initialized", which shows that the lookup doesn't >>> initialize Test_2. >>> When you uncomment the line in main(), the message will appear. >>> >>> So, as advertised, it's the invocation of the method handle that can >>> trigger initialization, not the lookup. >>> >>> >>> HTH >>> Raffaello >>> >>> ---- >>> >>> import java.lang.invoke.*; >>> >>> public class Test_1 { >>> >>> ??? static MethodHandle mh; >>> >>> ??? static { >>> ??????? try { >>> ??????????? mh = MethodHandles.lookup().findStatic(Test_2.class, >>> "testMethod", MethodType.methodType(int.class, int.class)); >>> ??????? } catch (NoSuchMethodException | IllegalAccessException e) { >>> ??????????? e.printStackTrace(); >>> ??????? } >>> ??? } >>> >>> ??? public static void main(String[] args) throws Throwable { >>> ??????? System.out.println(mh); >>> ??????? // System.out.println(Test_1.mh.invoke(0)); >>> ??? } >>> >>> } >>> >>> >>> >>> >>> public class Test_2 { >>> >>> ??? static { >>> ??????? System.out.println("Test_2 initialized"); >>> ??? } >>> >>> ??? static int testMethod(int value) { return (value + 1); } >>> >>> } >>> >>> >>> >>> >>> On 2022-03-17 20:38, Raffaello Giulietti wrote: >>>> Hi, >>>> >>>> as far as I can see, the code should not even compile, as there's a >>>> static field in Test_1 which is initialized with an expression that >>>> throws checked exceptions (findStatic(..)). >>>> >>>> In addition, it seems to me that there's nothing in your code that >>>> reveals whether Test_2 has been initialized during the lookup. How >>>> can you tell? >>>> >>>> Finally, the method handle invocation in Test_1 will throw, as you >>>> don't pass any argument to a handle that expects one. >>>> >>>> Can you perhaps add more details? >>>> >>>> >>>> Greetings >>>> Raffaello >>>> >>>> >>>> >>>> On 2022-03-17 17:42, Cheng Jin wrote: >>>>> Hi there, >>>>> >>>>> The document of >>>>> INVALID URI REMOVED >>>>> _en_java_javase_17_docs_api_java.base_java_lang_invoke_MethodHandles >>>>> .Lookup.html-23findStatic-28java.lang.Class-2Cjava.lang.String-2Cjav >>>>> a.lang.invoke.MethodType-29&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=X90f >>>>> 3XIRXAH8hbNam6bIUlWfF_qUAezL9ue7M7bFuPQ&m=RvhguidNJ90V-HK-3Ctl-kUZE5 >>>>> cIfo_nt3_r8VZ0Fcc&s=tw_ph6oUkS0eCvzITWi9zEkarss5yNeHDrAIfvd3s3g&e= >>>>> in the Java API is ambiguous in terms of when to initialize the >>>>> method's class as follows (the same description as in other OpenJDK >>>>> versions) >>>>> >>>>> If the returned method handle is invoked, the method's class will be >>>>> initialized, if it has not already been initialized. >>>>> >>>>> >>>>> It occurs to me that the method's class should be initialized when >>>>> invoking the method handle but OpenJDK actually chooses to do the >>>>> initialization in lookup.findStatic() rather than in mh.invoke() >>>>> e.g. >>>>> import java.lang.invoke.*; >>>>> >>>>> public class Test_1 { >>>>> ???? static MethodHandle mh = >>>>> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >>>>> MethodType.methodType(int.class, int.class)); <----------- >>>>> Test_2.class gets initialized and verified. >>>>> >>>>> ???? public static void main(String[] args) throws Throwable { >>>>> ???????? Test_1.mh.invoke(); >>>>> ???? } >>>>> } >>>>> >>>>> public class Test_2 { >>>>> ???? static int testMethod(int value) { return (value + 1); } } >>>>> >>>>> So there should be more clear explanation what is the correct or >>>>> expected behaviour at this point and why OpenJDK doesn't comply with >>>>> the document to delay the initialization of the method's class to >>>>> mh.invoke(). >>>>> >>>>> Best Regards >>>>> Cheng Jin From duke at openjdk.java.net Fri Mar 18 01:20:31 2022 From: duke at openjdk.java.net (liach) Date: Fri, 18 Mar 2022 01:20:31 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > add since in javadoc The current API docs on `Random.setSeed` look like: /** * Sets the seed of this random number generator using a single * {@code long} seed. The general contract of {@code setSeed} is * that it alters the state of this random number generator object * so as to be in exactly the same state as if it had just been * created with the argument {@code seed} as a seed. The method * {@code setSeed} is implemented by class {@code Random} by * atomically updating the seed to *
{@code (seed ^ 0x5DEECE66DL) & ((1L << 48) - 1)}
* and clearing the {@code haveNextNextGaussian} flag used by {@link * #nextGaussian}. * *

The implementation of {@code setSeed} by class {@code Random} * happens to use only 48 bits of the given seed. In general, however, * an overriding method may use all 64 bits of the {@code long} * argument as a seed value. * * @param seed the initial seed */ An updated version would possibly look like: /** * Sets the seed of this random number generator using a single * {@code long} seed (optional operation). * * @implSpec The general contract of {@code setSeed} is * that it alters the state of this random number generator object * so as to be in exactly the same state as if it had just been * created with the argument {@code seed} as a seed. * *

The method {@code setSeed} is implemented by class * {@code Random} by atomically updating the seed to *

{@code (seed ^ 0x5DEECE66DL) & ((1L << 48) - 1)}
* and clearing the {@code haveNextNextGaussian} flag used by {@link * #nextGaussian}. * *

The implementation of {@code setSeed} by class {@code Random} * happens to use only 48 bits of the given seed. In general, however, * an overriding method may use all 64 bits of the {@code long} * argument as a seed value. * * @param seed the initial seed * @throws UnsupportedOperationException if the {@code setSeed} * operation is not supported by this random number generator */ This moves pretty much everything besides the first sentence to `@implSpec`, as they are only applicable to the `Random` class, but not its subclasses. The rest is an emulation of `List.add` javadoc on optional operations. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From darcy at openjdk.java.net Fri Mar 18 02:04:30 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 18 Mar 2022 02:04:30 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > add since in javadoc > The current API docs on `Random.setSeed` look like: > > ```java > /** > * Sets the seed of this random number generator using a single > * {@code long} seed. The general contract of {@code setSeed} is > * that it alters the state of this random number generator object > * so as to be in exactly the same state as if it had just been > * created with the argument {@code seed} as a seed. The method > * {@code setSeed} is implemented by class {@code Random} by > * atomically updating the seed to > *

{@code (seed ^ 0x5DEECE66DL) & ((1L << 48) - 1)}
> * and clearing the {@code haveNextNextGaussian} flag used by {@link > * #nextGaussian}. > * > *

The implementation of {@code setSeed} by class {@code Random} > * happens to use only 48 bits of the given seed. In general, however, > * an overriding method may use all 64 bits of the {@code long} > * argument as a seed value. > * > * @param seed the initial seed > */ > ``` > > An updated version would possibly look like: > > ```java > /** > * Sets the seed of this random number generator using a single > * {@code long} seed (optional operation). > * > * @implSpec The general contract of {@code setSeed} is > * that it alters the state of this random number generator object > * so as to be in exactly the same state as if it had just been > * created with the argument {@code seed} as a seed. > * > *

The method {@code setSeed} is implemented by class > * {@code Random} by atomically updating the seed to > *

{@code (seed ^ 0x5DEECE66DL) & ((1L << 48) - 1)}
> * and clearing the {@code haveNextNextGaussian} flag used by {@link > * #nextGaussian}. > * > *

The implementation of {@code setSeed} by class {@code Random} > * happens to use only 48 bits of the given seed. In general, however, > * an overriding method may use all 64 bits of the {@code long} > * argument as a seed value. > * > * @param seed the initial seed > * @throws UnsupportedOperationException if the {@code setSeed} > * operation is not supported by this random number generator > */ > ``` > > This moves pretty much everything besides the first sentence to `@implSpec`, as they are only applicable to the `Random` class, but not its subclasses. The rest is an emulation of `List.add` javadoc on optional operations. Please also update the Random.setSeed spec to accommodate the behavior of SecureRandom.setSeed: "Reseeds this random object, using the eight bytes contained in the given long seed. The given seed supplements, rather than replaces, the existing seed. Thus, repeated calls are guaranteed never to reduce randomness. This method is defined for compatibility with java.util.Random." https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/SecureRandom.html#setSeed(long) Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From dholmes at openjdk.java.net Fri Mar 18 02:15:25 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 18 Mar 2022 02:15:25 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 20:56:34 GMT, Mikael Vidstedt wrote: > Note: this PR replaces the one I messed up earlier. > > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in JDK-8266168, presumably for GCC 11.1. > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function check_and_push_const which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Changes requested by dholmes (Reviewer). src/java.base/share/native/libverify/check_code.c line 472: > 470: > 471: static void check_and_push_malloc_block(context_type *context, void *ptr); > 472: static void check_and_push_string_utf(context_type *context, const void *ptr); Can't this be: `static void check_and_push_string_utf(context_type *context, const char* str);` ------------- PR: https://git.openjdk.java.net/jdk/pull/7859 From dholmes at openjdk.java.net Fri Mar 18 02:18:33 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 18 Mar 2022 02:18:33 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:23:14 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment > > - Reword to avoid double use of malloc(X) > - Remove bug id Update looks good. Sorry for the AIX_ONLY misdirect. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7829 From mikael at openjdk.java.net Fri Mar 18 02:39:23 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 18 Mar 2022 02:39:23 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2] In-Reply-To: References: Message-ID: > Note: this PR replaces the one I messed up earlier. > > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in JDK-8266168, presumably for GCC 11.1. > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function check_and_push_const which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: Use const char for check_and_push_string_utf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7859/files - new: https://git.openjdk.java.net/jdk/pull/7859/files/c5c60cb2..9f412d0b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7859&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7859&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7859.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7859/head:pull/7859 PR: https://git.openjdk.java.net/jdk/pull/7859 From david.holmes at oracle.com Fri Mar 18 02:38:13 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Mar 2022 12:38:13 +1000 Subject: When to initialize the method's class for MethodHandles.Lookup.findStatic()? In-Reply-To: References: <701de8f0-2edd-20ba-dfdc-16d9070c3b8b@gmail.com> <773c0a55-bd6f-d49d-9607-59a4df7c4d98@gmail.com> <296e7a57-c5ae-3676-af45-4e626657bbfd@oracle.com> Message-ID: <58db91f2-a99b-39da-e8e9-679f46208b22@oracle.com> On 18/03/2022 10:51 am, Cheng Jin wrote: > Hi Raffaello, > > My concern is why the verification happens even without initialization in the test without mh.invoke() in the main(), which I don't think is covered or explained in the JVM Spec. > Put it in another way, my understanding is, when the class gets loaded, it is verified which doesn't necessarily lead to initialization, am I correct? From Section 5.4 of the JVMS: This specification allows an implementation flexibility as to when linking activities (and, because of recursion, loading) take place, provided that all of the following properties are maintained: ? A class or interface is completely loaded before it is linked. ? A class or interface is completely verified and prepared before it is initialized. --- Hotspot does loading, verification and preparing upfront/eagerly. HTH. David ----- > Best Regards > Cheng > > -----Original Message----- > From: core-libs-dev On Behalf Of Raffaello Giulietti > Sent: March 17, 2022 8:35 PM > To: core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? > > Cheng, > > initialization is the last thing that happens because it's where user provided code gets executed. > > This has always been this way, as long as I can remember. See the JVMS for the gory details. > > > Greetings > Raffaello > > > On 2022-03-18 01:21, Cheng Jin wrote: >> Hi David, >> >> 1) for the test with mh.invoke() in main(), the log shows: >> [0.262s][info][class,init] Start class verification for: Test_1 >> [0.262s][info][class,init] End class verification for: Test_1 >> [0.263s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) >> [0.263s][info][class,init] Start class verification for: Test_2 >> [0.263s][info][class,init] End class verification for: Test_2 >> [0.272s][info][class,init] 366 Initializing 'Test_2' (0x0000000800c00a08) <------ >> >> 2) for the test without mh.invoke() in main(), the log shows: >> [0.296s][info][class,init] Start class verification for: Test_1 >> [0.296s][info][class,init] End class verification for: Test_1 >> [0.297s][info][class,init] 282 Initializing 'Test_1' (0x0000000800c00800) >> [0.297s][info][class,init] Start class verification for: Test_2 >> [0.297s][info][class,init] End class verification for: Test_2 >> (Test_2 was verified but didn't get initialized) >> >> The comparison above literally surprised me that the bytecode verification happened prior to the class initialization, which means >> the class got verified at first even without initialization coz I previously thought the initialization should trigger the verification rather than in the reversed order. >> >> Could you explain a little more about why it goes in this way? >> >> Best Regards >> Cheng >> >> >> -----Original Message----- >> From: core-libs-dev On Behalf Of David Holmes >> Sent: March 17, 2022 7:46 PM >> To: Raffaello Giulietti ; core-libs-dev at openjdk.java.net >> Subject: [EXTERNAL] Re: When to initialize the method's class for MethodHandles.Lookup.findStatic()? >> >> Run with -Xlog:class+init=info to see the classes that get initialized and in what order. >> >> David >> >> On 18/03/2022 5:53 am, Raffaello Giulietti wrote: >>> Hi again, >>> >>> here's code that shows that initialization doesn't happen during >>> lookup but only upon invoking the method handle. (I'm on Java 17.) >>> >>> As long as the 2nd line in main() is commented, you don't see the >>> message "Test_2 initialized", which shows that the lookup doesn't >>> initialize Test_2. >>> When you uncomment the line in main(), the message will appear. >>> >>> So, as advertised, it's the invocation of the method handle that can >>> trigger initialization, not the lookup. >>> >>> >>> HTH >>> Raffaello >>> >>> ---- >>> >>> import java.lang.invoke.*; >>> >>> public class Test_1 { >>> >>> ??? static MethodHandle mh; >>> >>> ??? static { >>> ??????? try { >>> ??????????? mh = MethodHandles.lookup().findStatic(Test_2.class, >>> "testMethod", MethodType.methodType(int.class, int.class)); >>> ??????? } catch (NoSuchMethodException | IllegalAccessException e) { >>> ??????????? e.printStackTrace(); >>> ??????? } >>> ??? } >>> >>> ??? public static void main(String[] args) throws Throwable { >>> ??????? System.out.println(mh); >>> ??????? // System.out.println(Test_1.mh.invoke(0)); >>> ??? } >>> >>> } >>> >>> >>> >>> >>> public class Test_2 { >>> >>> ??? static { >>> ??????? System.out.println("Test_2 initialized"); >>> ??? } >>> >>> ??? static int testMethod(int value) { return (value + 1); } >>> >>> } >>> >>> >>> >>> >>> On 2022-03-17 20:38, Raffaello Giulietti wrote: >>>> Hi, >>>> >>>> as far as I can see, the code should not even compile, as there's a >>>> static field in Test_1 which is initialized with an expression that >>>> throws checked exceptions (findStatic(..)). >>>> >>>> In addition, it seems to me that there's nothing in your code that >>>> reveals whether Test_2 has been initialized during the lookup. How >>>> can you tell? >>>> >>>> Finally, the method handle invocation in Test_1 will throw, as you >>>> don't pass any argument to a handle that expects one. >>>> >>>> Can you perhaps add more details? >>>> >>>> >>>> Greetings >>>> Raffaello >>>> >>>> >>>> >>>> On 2022-03-17 17:42, Cheng Jin wrote: >>>>> Hi there, >>>>> >>>>> The document of >>>>> INVALID URI REMOVED >>>>> _en_java_javase_17_docs_api_java.base_java_lang_invoke_MethodHandles >>>>> .Lookup.html-23findStatic-28java.lang.Class-2Cjava.lang.String-2Cjav >>>>> a.lang.invoke.MethodType-29&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=X90f >>>>> 3XIRXAH8hbNam6bIUlWfF_qUAezL9ue7M7bFuPQ&m=RvhguidNJ90V-HK-3Ctl-kUZE5 >>>>> cIfo_nt3_r8VZ0Fcc&s=tw_ph6oUkS0eCvzITWi9zEkarss5yNeHDrAIfvd3s3g&e= >>>>> in the Java API is ambiguous in terms of when to initialize the >>>>> method's class as follows (the same description as in other OpenJDK >>>>> versions) >>>>> >>>>> If the returned method handle is invoked, the method's class will be >>>>> initialized, if it has not already been initialized. >>>>> >>>>> >>>>> It occurs to me that the method's class should be initialized when >>>>> invoking the method handle but OpenJDK actually chooses to do the >>>>> initialization in lookup.findStatic() rather than in mh.invoke() >>>>> e.g. >>>>> import java.lang.invoke.*; >>>>> >>>>> public class Test_1 { >>>>> ???? static MethodHandle mh = >>>>> MethodHandles.lookup().findStatic(Test_2.class, "testMethod", >>>>> MethodType.methodType(int.class, int.class)); <----------- >>>>> Test_2.class gets initialized and verified. >>>>> >>>>> ???? public static void main(String[] args) throws Throwable { >>>>> ???????? Test_1.mh.invoke(); >>>>> ???? } >>>>> } >>>>> >>>>> public class Test_2 { >>>>> ???? static int testMethod(int value) { return (value + 1); } } >>>>> >>>>> So there should be more clear explanation what is the correct or >>>>> expected behaviour at this point and why OpenJDK doesn't comply with >>>>> the document to delay the initialization of the method's class to >>>>> mh.invoke(). >>>>> >>>>> Best Regards >>>>> Cheng Jin From mikael at openjdk.java.net Fri Mar 18 02:39:23 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 18 Mar 2022 02:39:23 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2] In-Reply-To: References: Message-ID: <-noF5UWi1nKg_n-hUB6UraPSs2acwCUTqd92ynyVu-g=.5e606f10-f91a-446f-80a2-93f7b0b842fa@github.com> On Fri, 18 Mar 2022 02:10:32 GMT, David Holmes wrote: >> Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: >> >> Use const char for check_and_push_string_utf > > src/java.base/share/native/libverify/check_code.c line 472: > >> 470: >> 471: static void check_and_push_malloc_block(context_type *context, void *ptr); >> 472: static void check_and_push_string_utf(context_type *context, const void *ptr); > > Can't this be: > > `static void check_and_push_string_utf(context_type *context, const char* str);` Indeed it can. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7859 From dholmes at openjdk.java.net Fri Mar 18 02:44:28 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 18 Mar 2022 02:44:28 GMT Subject: RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 02:39:23 GMT, Mikael Vidstedt wrote: >> Note: this PR replaces the one I messed up earlier. >> >> Background, from JBS: >> >> src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': >> src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] >> 942 | check_and_push(context, lengths, VM_MALLOC_BLK); >> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here >> 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) >> | ^~~~~~~~~~~~~~ >> >> Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. >> >> The same general issue was addressed in JDK-8266168, presumably for GCC 11.1. >> >> Details: >> >> Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function check_and_push_const which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. >> >> To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. >> >> Testing: >> >> tier1 + builds-tier{2,3,4,5} > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Use const char for check_and_push_string_utf Looks good! ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7859 From almatvee at openjdk.java.net Fri Mar 18 03:18:32 2022 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Fri, 18 Mar 2022 03:18:32 GMT Subject: Integrated: 8282407: Missing ')' in MacResources.properties In-Reply-To: References: Message-ID: On Sat, 12 Mar 2022 03:12:30 GMT, Alexander Matveev wrote: > - Fixed by adding missing ']'. > - I changed '()' to '[]', since other error messages use '[]' and not '()'. This pull request has now been integrated. Changeset: d83cee98 Author: Alexander Matveev URL: https://git.openjdk.java.net/jdk/commit/d83cee98b5e6628f19f1b5dea11038079dd0c758 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod 8282407: Missing ')' in MacResources.properties Reviewed-by: naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7797 From jiangli at openjdk.java.net Fri Mar 18 04:04:27 2022 From: jiangli at openjdk.java.net (Jiangli Zhou) Date: Fri, 18 Mar 2022 04:04:27 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 23:44:32 GMT, Liam Miller-Cushon wrote: > This change removes support for `-Dsun.misc.URLClassPath.disableJarChecking`. As discussed in the bug the feature doesn't current work, and only ever supported scenarios where a security manager is installed, so it seems safe to remove. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 806: > 804: > 805: /* Throws if the given jar file is does not start with the correct LOC */ > 806: @SuppressWarnings("removal") I noticed the @SuppressWarnings("removal") when looking at the PR. It is added by https://github.com/openjdk/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1 for [JDK-8266459](https://bugs.openjdk.java.net/browse/JDK-8266459). So looks like the method has been targeted for deprcating/removal. ------------- PR: https://git.openjdk.java.net/jdk/pull/7861 From stuefe at openjdk.java.net Fri Mar 18 07:05:31 2022 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 18 Mar 2022 07:05:31 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 02:15:36 GMT, David Holmes wrote: > Update looks good. Sorry for the AIX_ONLY misdirect. > > Thanks, David It would be real nice to have the same set of macros in JDK too, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Fri Mar 18 07:05:32 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 07:05:32 GMT Subject: Integrated: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 22:58:48 GMT, Tyler Steele wrote: > As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. > > ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] > > In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. > > ### Alternatives > > It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. > > ### Testing > > This change has been tested on AIX and Linux/x86. This pull request has now been integrated. Changeset: cab4ff64 Author: Tyler Steele Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/cab4ff64541393a974ea91e35167668ef0036804 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) Reviewed-by: stuefe, rriggs, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From alanb at openjdk.java.net Fri Mar 18 07:45:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 07:45:32 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:23:14 GMT, Tyler Steele wrote: >> As described in the linked issue, NullClassBytesTest fails due an OutOfMemoryError produced on AIX when the test calls defineClass with a byte array of size of 0. The native implementation of defineClass then calls malloc with a size of 0. On AIX malloc(0) returns NULL, while on other platforms it return a valid address. When NULL is produced by malloc for this reason, ClassLoader.c incorrectly interprets this as a failure due to a lack of memory. >> >> ~~This PR modifies ClassLoader.c to produce an OutOfMemoryError only when `errno == ENOMEM` and to produce a ClassFormatError with the message "ClassLoader internal allocation failure" in all other cases (in which malloc returns NULL).~~ [edit: The above no longer describes the PR's proposed fix. See discussion below] >> >> In addition, I performed some minor tidy-up work in ClassLoader.c by changing instances of `return 0` to `return NULL`, and `if (some_ptr == 0)` to `if (some_ptr == NULL)`. This was done to improve the clarity of the code in ClassLoader.c, but didn't feel worthy of opening a separate issue. >> >> ### Alternatives >> >> It would be possible to address this failure by modifying the test to accept the OutOfMemoryError on AIX. I thought it was a better solution to modify ClassLoader.c to produce an OutOfMemoryError only when the system is actually out of memory. >> >> ### Testing >> >> This change has been tested on AIX and Linux/x86. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Improve comment > > - Reword to avoid double use of malloc(X) > - Remove bug id src/java.base/share/native/libjava/ClassLoader.c line 104: > 102: // On AIX malloc(0) returns NULL which looks like an out-of-memory condition; so adjust it to malloc(1) > 103: #ifdef _AIX > 104: body = (jbyte *)malloc(length == 0 ? 1 : length); Can we use identification in the ifdef/else/endif block to make it a bit more readable. Also can you trim down the comment or split it over two lines to avoid the really long line (it makes it a bit easier for future side-by-side reviews). ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From alanb at openjdk.java.net Fri Mar 18 07:47:36 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 07:47:36 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v2] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 16:08:11 GMT, Tyler Steele wrote: >> As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c >> >> - Alphabetize includes. >> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. >> - Replace 'return 0' with 'return NULL'. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > removes unneeded errno.h Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From alanb at openjdk.java.net Fri Mar 18 08:42:27 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 08:42:27 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 23:44:32 GMT, Liam Miller-Cushon wrote: > This change removes support for `-Dsun.misc.URLClassPath.disableJarChecking`. As discussed in the bug the feature doesn't current work, and only ever supported scenarios where a security manager is installed, so it seems safe to remove. I don't know what the motivation for this change is but there is more to this story and I think will require agreement from the security area before removing it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7861 From alanb at openjdk.java.net Fri Mar 18 08:59:35 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 08:59:35 GMT Subject: RFR: 8283280: Improve exception messages with -Dsun.misc.URLClassPath.disableJarChecking=false In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 22:00:15 GMT, Liam Miller-Cushon wrote: > This change improves an exception message to include a path, e.g. `Invalid Jar file: some.jar` instead of just `Invalid Jar file`. > > The exception is currently [always being caught and ignored](https://github.com/openjdk/jdk/blob/3e393047e12147a81e2899784b943923fc34da8e/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L459-L461) so this visible to users of the API, it's just helpful for debugging. As with PR7861, I think this will require security input (it might be that jdk.includeInExceptions=jar will be required here, needs analysis). ------------- PR: https://git.openjdk.java.net/jdk/pull/7848 From alanb at openjdk.java.net Fri Mar 18 10:03:39 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 10:03:39 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Thanks for dropping the charset and locale data from the proposal. The updated proposal (b1d1e4d8) looks okay but I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed? I suspect that JEP will need to includes a "specs" directory. It's okay to jdwp.spec into the java.se "data" directory for now I think "specs" would be a bette place for it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From alanb at openjdk.java.net Fri Mar 18 11:54:33 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 11:54:33 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 15:57:58 GMT, Roger Riggs wrote: > The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. > The result is retention of the class loader. > > The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. > The test verifies that the process reaper threads have a null context classloader. src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 138: > 136: Thread t = new InnocuousThread(INNOCUOUSTHREADGROUP, > 137: target, name, stackSize, loader); > 138: if (priority >= 0) { Adding an addition newSystemThread method should be okay but can you fix the formatting/line lengths so it's a bit more inconsistent with the existing code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7131 From duke at openjdk.java.net Fri Mar 18 13:09:53 2022 From: duke at openjdk.java.net (jmehrens) Date: Fri, 18 Mar 2022 13:09:53 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Fri, 18 Mar 2022 00:24:56 GMT, Yasser Bazzi wrote: > The toString method of both classes do not implement anything so i dont think we should override it, .... The inherited implementation is descriptive enough because the the class names are the implementation: https://github.com/openjdk/jdk/tree/master/src/jdk.random/share/classes/jdk/random The wrapper would hide this detail without an implementation of toString if I'm understanding it correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From duke at openjdk.java.net Fri Mar 18 13:13:50 2022 From: duke at openjdk.java.net (liach) Date: Fri, 18 Mar 2022 13:13:50 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Fri, 18 Mar 2022 13:06:12 GMT, jmehrens wrote: > > The toString method of both classes do not implement anything so i dont think we should override it, .... > > The inherited implementation is descriptive enough because the the class names are the implementation: https://github.com/openjdk/jdk/tree/master/src/jdk.random/share/classes/jdk/random > > The wrapper would hide this detail without an implementation of toString if I'm understanding it correctly. you are not expected to inspect a random object by its string. if you want to debug, in the debugger you usually gets hold of the object itself. it's not like a user-oriented exception thrown. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From magnus.ihse.bursie at oracle.com Fri Mar 18 14:13:58 2022 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 18 Mar 2022 14:13:58 +0000 Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: <62193BC0-B3FC-43E9-A65D-387708D85B3D@oracle.com> > 18 mars 2022 kl. 11:04 skrev Alan Bateman : > > I can't tell if you are planning to integrate this or wait until there is discussion on the locations proposed in the Informational JEP that you've just submitted. Maybe you plan to just integrate and then adjust/move again if needed? I am *not* planning to wait for the JEP. (My perhaps cynical prediction is that it will be treated as a low-priority, bike-shedding playground which is unlikely to progress to its final stage for a year or so?) The point of the informational JEP is that it is a living document. If the code changes, we can update the JEP. The JEP as it stands right now describes the code base as it will look when this PR is integrated. And yes, I?m open for more updates/changes in the future if we find the need. Things like code structure is something which we impose on the source code to be helpful. If it works against our best interests, we need to change it. And sometimes it?s hard to get things right the first time around. /Magnus From jlaskey at openjdk.java.net Fri Mar 18 14:24:21 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 18 Mar 2022 14:24:21 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v8] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Remove redundant MethodHandle component(MethodType methodType, int i) API ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/10d1cc93..d754d806 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=06-07 Stats: 114 lines in 1 file changed: 2 ins; 112 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Fri Mar 18 14:32:10 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 18 Mar 2022 14:32:10 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v9] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clean up API ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/d754d806..1d706d32 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=07-08 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From duke at openjdk.java.net Fri Mar 18 15:05:55 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 15:05:55 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v3] In-Reply-To: References: Message-ID: > As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c > > - Alphabetize includes. > - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. > - Replace 'return 0' with 'return NULL'. Tyler Steele has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into ClassLoaderCleanup - removes unneeded errno.h - Perform minor clean up ClassLoader.c - Alphabatizes includes. - Replaces 'if (ptr == 0)' with 'if (ptr == NULL)'. - Replaces 'return 0' with 'return NULL'. ------------- Changes: https://git.openjdk.java.net/jdk/pull/7846/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=02 Stats: 26 lines in 1 file changed: 6 ins; 5 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7846/head:pull/7846 PR: https://git.openjdk.java.net/jdk/pull/7846 From duke at openjdk.java.net Fri Mar 18 15:13:17 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 15:13:17 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v4] In-Reply-To: References: Message-ID: <1SRylKrSJ006iCA5mMD63PiEsHd1znuJOPEDVuxDvic=.6f3c4bf8-2d60-406a-95ff-cce2e3737d32@github.com> > As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c > > - Alphabetize includes. > - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. > - Replace 'return 0' with 'return NULL'. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Removes offending whitespace ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7846/files - new: https://git.openjdk.java.net/jdk/pull/7846/files/d7e67d4c..2fd5b368 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7846/head:pull/7846 PR: https://git.openjdk.java.net/jdk/pull/7846 From rriggs at openjdk.java.net Fri Mar 18 15:23:27 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Mar 2022 15:23:27 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread [v2] In-Reply-To: References: Message-ID: > The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. > The result is retention of the class loader. > > The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. > The test verifies that the process reaper threads have a null context classloader. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Folded lines to reduce max line length ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7131/files - new: https://git.openjdk.java.net/jdk/pull/7131/files/3e64a424..fd3faa9d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7131&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7131&range=00-01 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7131.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7131/head:pull/7131 PR: https://git.openjdk.java.net/jdk/pull/7131 From rriggs at openjdk.java.net Fri Mar 18 15:25:35 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 18 Mar 2022 15:25:35 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v4] In-Reply-To: <1SRylKrSJ006iCA5mMD63PiEsHd1znuJOPEDVuxDvic=.6f3c4bf8-2d60-406a-95ff-cce2e3737d32@github.com> References: <1SRylKrSJ006iCA5mMD63PiEsHd1znuJOPEDVuxDvic=.6f3c4bf8-2d60-406a-95ff-cce2e3737d32@github.com> Message-ID: On Fri, 18 Mar 2022 15:13:17 GMT, Tyler Steele wrote: >> As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c >> >> - Alphabetize includes. >> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. >> - Replace 'return 0' with 'return NULL'. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Removes offending whitespace Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From duke at openjdk.java.net Fri Mar 18 15:28:32 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 15:28:32 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 07:43:21 GMT, Alan Bateman wrote: >> Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve comment >> >> - Reword to avoid double use of malloc(X) >> - Remove bug id > > src/java.base/share/native/libjava/ClassLoader.c line 104: > >> 102: // On AIX malloc(0) returns NULL which looks like an out-of-memory condition; so adjust it to malloc(1) >> 103: #ifdef _AIX >> 104: body = (jbyte *)malloc(length == 0 ? 1 : length); > > Can we use identification in the ifdef/else/endif block to make it a bit more readable. Also can you trim down the comment or split it over two lines to avoid the really long line (it makes it a bit easier for future side-by-side reviews). I can split down the comment if you prefer. It might be appropriate to do in the as-yet-unmerged cleanup PR I have open for the same file. I am not sure what you mean by 'use identification'. Can you clarify? ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Fri Mar 18 15:28:32 2022 From: duke at openjdk.java.net (ExE Boss) Date: Fri, 18 Mar 2022 15:28:32 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 15:22:48 GMT, Tyler Steele wrote: >> src/java.base/share/native/libjava/ClassLoader.c line 104: >> >>> 102: // On AIX malloc(0) returns NULL which looks like an out-of-memory condition; so adjust it to malloc(1) >>> 103: #ifdef _AIX >>> 104: body = (jbyte *)malloc(length == 0 ? 1 : length); >> >> Can we use identification in the ifdef/else/endif block to make it a bit more readable. Also can you trim down the comment or split it over two lines to avoid the really long line (it makes it a bit easier for future side-by-side reviews). > > I can split down the comment if you prefer. It might be appropriate to do in the as-yet-unmerged cleanup PR I have open for the same file. > > I am not sure what you mean by 'use identification'. Can you clarify? I?think it?s?a?typo of??indentation?, e.g.: Suggestion: body = (jbyte *)malloc(length == 0 ? 1 : length); ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Fri Mar 18 15:32:32 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 15:32:32 GMT Subject: RFR: 8283225: ClassLoader.c produces incorrect OutOfMemory Exception when length is 0 (aix) [v4] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 15:25:20 GMT, ExE Boss wrote: >> I can split down the comment if you prefer. It might be appropriate to do in the as-yet-unmerged cleanup PR I have open for the same file. >> >> I am not sure what you mean by 'use identification'. Can you clarify? > > I?think it?s?a?typo of??indentation?, e.g.: > Suggestion: > > body = (jbyte *)malloc(length == 0 ? 1 : length); Ah, that does make sense. Please request these changes [here](https://github.com/openjdk/jdk/pull/7846) and I am happy to make them. ------------- PR: https://git.openjdk.java.net/jdk/pull/7829 From duke at openjdk.java.net Fri Mar 18 15:33:41 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 15:33:41 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v4] In-Reply-To: <1SRylKrSJ006iCA5mMD63PiEsHd1znuJOPEDVuxDvic=.6f3c4bf8-2d60-406a-95ff-cce2e3737d32@github.com> References: <1SRylKrSJ006iCA5mMD63PiEsHd1znuJOPEDVuxDvic=.6f3c4bf8-2d60-406a-95ff-cce2e3737d32@github.com> Message-ID: On Fri, 18 Mar 2022 15:13:17 GMT, Tyler Steele wrote: >> As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c >> >> - Alphabetize includes. >> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. >> - Replace 'return 0' with 'return NULL'. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Removes offending whitespace Please do not sponsor yet. ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From rreddy at openjdk.java.net Fri Mar 18 15:34:42 2022 From: rreddy at openjdk.java.net (Ravi Reddy) Date: Fri, 18 Mar 2022 15:34:42 GMT Subject: Integrated: 8278794: Infinite loop in DeflaterOutputStream.finish() In-Reply-To: References: Message-ID: <1RxlPgISkpF8b_BaRsd6A9Nrb7Vuj5AtbztnSac7EIA=.c564a179-6c01-4bc7-8ea5-71efd7bf7d8e@github.com> On Sun, 13 Mar 2022 14:08:57 GMT, Ravi Reddy wrote: > Hi All, > > This review request contains fix for infinite loop issue in DeflaterOutputStream.finish() in an exception scenario. > 1. The issue is with 'finished' flag not getting set to correct value when there is an IOException in > DeflaterOutputStream.finish() which will result in Infinite loops for next write operations on the same deflater. > 2. Tighten the condition(to close deflater) in ZipOutputStream using an already existing 'finish' flag in Deflater class. > 3. Added Inflater exception scenarios also to the test case, renaming test case to CloseInflaterDeflaterTest.java from CloseDeflaterTest.java > > Thanks, > Ravi This pull request has now been integrated. Changeset: ff0b0927 Author: Ravi Reddy Committer: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/ff0b0927a2df8b36f8fd6ed41bd4e20e71a5b653 Stats: 378 lines in 5 files changed: 224 ins; 147 del; 7 mod 8278794: Infinite loop in DeflaterOutputStream.finish() Reviewed-by: coffeys, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7804 From duke at openjdk.java.net Fri Mar 18 15:40:09 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 15:40:09 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v5] In-Reply-To: References: Message-ID: > As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c > > - Alphabetize includes. > - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. > - Replace 'return 0' with 'return NULL'. Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: Makes requested readability changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7846/files - new: https://git.openjdk.java.net/jdk/pull/7846/files/2fd5b368..9a8e6b6f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7846&range=03-04 Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7846.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7846/head:pull/7846 PR: https://git.openjdk.java.net/jdk/pull/7846 From duke at openjdk.java.net Fri Mar 18 15:44:40 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 15:44:40 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v5] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 15:40:09 GMT, Tyler Steele wrote: >> As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c >> >> - Alphabetize includes. >> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. >> - Replace 'return 0' with 'return NULL'. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Makes requested readability changes Made some additional readability changes that were requested after #7829 closed. They felt appropriate here since it's already a cleanup PR. All changes complete. Please sponsor when ready. ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From jlaskey at openjdk.java.net Fri Mar 18 16:16:31 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Fri, 18 Mar 2022 16:16:31 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v10] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with three additional commits since the last revision: - Typos - Update Carrier.java - Redo API to use list, bring Carrier.component back ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/1d706d32..a82bfd64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=08-09 Stats: 129 lines in 2 files changed: 111 ins; 5 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From cushon at openjdk.java.net Fri Mar 18 17:47:33 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 18 Mar 2022 17:47:33 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 04:01:05 GMT, Jiangli Zhou wrote: >> This change removes support for `-Dsun.misc.URLClassPath.disableJarChecking`. As discussed in the bug the feature doesn't current work, and only ever supported scenarios where a security manager is installed, so it seems safe to remove. > > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 806: > >> 804: >> 805: /* Throws if the given jar file is does not start with the correct LOC */ >> 806: @SuppressWarnings("removal") > > I noticed the @SuppressWarnings("removal") when looking at the PR. It is added by https://github.com/openjdk/jdk/commit/6765f902505fbdd02f25b599f942437cd805cad1 for [JDK-8266459](https://bugs.openjdk.java.net/browse/JDK-8266459). So looks like the method has been targeted for deprcating/removal. Right, the suppression is for the use of `getSecurityManager` here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7861 From cushon at openjdk.java.net Fri Mar 18 17:51:31 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 18 Mar 2022 17:51:31 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking In-Reply-To: References: Message-ID: <421euDsqvdOajGBHkUWKHaQS10xZkks4akGNTd0QQqk=.23aea358-053b-4ba9-88ed-9675e2e19c00@github.com> On Fri, 18 Mar 2022 08:39:46 GMT, Alan Bateman wrote: > I don't know what the motivation for this change is but there is more to this story and I think will require agreement from the security area before removing it. Thanks @AlanBateman. The motivation is that I was investigating an unrelated change to this code (a potential performance optimization), and it accidentally removed the logic that's catching and ignoring the `IOException`, and when I investigated this logic it looked unused and seemed like a cleanup opportunity. There don't seem to be any public tests for this feature. If it's security related I understand there may be other internal tests, and this PR may be a non-starter. I'd be interested in anything you can share about the story here, but if this code needs to stay for security reasons feel free to close the PR. Do you expect this will still be turned down once the `SecurityManager` remove is complete? Or does it make sense to think about generalize this logic so it works even if there isn't a `SecurityManager` enabled? ------------- PR: https://git.openjdk.java.net/jdk/pull/7861 From cushon at openjdk.java.net Fri Mar 18 17:51:31 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Fri, 18 Mar 2022 17:51:31 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 23:44:32 GMT, Liam Miller-Cushon wrote: > This change removes support for `-Dsun.misc.URLClassPath.disableJarChecking`. As discussed in the bug the feature doesn't current work, and only ever supported scenarios where a security manager is installed, so it seems safe to remove. Also, I belatedly realized that I don't think this is actually a no-op: the exception is never shown to the user, but it will cause the jar to be skipped. It should be possible to write a test to exercise that, so I may look in to contributing that if there's interest. ------------- PR: https://git.openjdk.java.net/jdk/pull/7861 From mullan at openjdk.java.net Fri Mar 18 19:02:34 2022 From: mullan at openjdk.java.net (Sean Mullan) Date: Fri, 18 Mar 2022 19:02:34 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 08:39:46 GMT, Alan Bateman wrote: >> This change removes support for `-Dsun.misc.URLClassPath.disableJarChecking`. As discussed in the bug the feature doesn't current work, and only ever supported scenarios where a security manager is installed, so it seems safe to remove. > > I don't know what the motivation for this change is but there is more to this story and I think will require agreement from the security area before removing it. I agree with @AlanBateman. Please don't proceed with this fix until further notice. ------------- PR: https://git.openjdk.java.net/jdk/pull/7861 From duke at openjdk.java.net Fri Mar 18 19:14:31 2022 From: duke at openjdk.java.net (jmehrens) Date: Fri, 18 Mar 2022 19:14:31 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: On Fri, 18 Mar 2022 13:10:10 GMT, liach wrote: >you are not expected to inspect a random object by its string. ToString representations tend to show up in exception messages and logging. Seems like this adapter just won't adapt that call. Not a deal breaker. > Also the reverse order comparator in Collections doesn't have a toString override as well. ToString wasn't added to that for compatibility reasons. Since this hasn't been released yet that doesn't apply here. https://bugs.openjdk.java.net/browse/JDK-6483125 ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From alanb at openjdk.java.net Fri Mar 18 19:37:34 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 18 Mar 2022 19:37:34 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From duke at openjdk.java.net Fri Mar 18 20:02:27 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Fri, 18 Mar 2022 20:02:27 GMT Subject: RFR: 8283287: ClassLoader.c cleanups [v5] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 15:40:09 GMT, Tyler Steele wrote: >> As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c >> >> - Alphabetize includes. >> - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. >> - Replace 'return 0' with 'return NULL'. > > Tyler Steele has updated the pull request incrementally with one additional commit since the last revision: > > Makes requested readability changes Thanks :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From jbhateja at openjdk.java.net Fri Mar 18 20:19:08 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 18 Mar 2022 20:19:08 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v18] In-Reply-To: References: Message-ID: > Summary of changes: > - Intrinsify Math.round(float) and Math.round(double) APIs. > - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. > - Test creation using new IR testing framework. > > Following are the performance number of a JMH micro included with the patch > > Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) > > > Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio > -- | -- | -- | -- | -- | -- | -- | -- > FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 > FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 > FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 > FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 > > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 - 8279508: Windows build failure fix. - 8279508: Styling comments resolved. - 8279508: Creating separate test for round double under feature check. - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java. - 8279508: Review comments resolution. - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating. - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 - 8279508: Removing +LogCompilation flag. - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf ------------- Changes: https://git.openjdk.java.net/jdk/pull/7094/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7094&range=17 Stats: 800 lines in 25 files changed: 707 ins; 30 del; 63 mod Patch: https://git.openjdk.java.net/jdk/pull/7094.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7094/head:pull/7094 PR: https://git.openjdk.java.net/jdk/pull/7094 From jbhateja at openjdk.java.net Fri Mar 18 20:19:10 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Fri, 18 Mar 2022 20:19:10 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v17] In-Reply-To: <1J7RFTiEF7VfaEg4EF29Hwd9UUU0D1MM1xh6waG3ulY=.251d7fd9-0d1d-4288-9a55-6feca4b0ec6a@github.com> References: <1J7RFTiEF7VfaEg4EF29Hwd9UUU0D1MM1xh6waG3ulY=.251d7fd9-0d1d-4288-9a55-6feca4b0ec6a@github.com> Message-ID: <9OJ2oXsQoXjxikba14rEmZMby_rRgq5yzeiwMkk0AMk=.07f34037-6510-453a-bb63-1f5ab162a530@github.com> On Mon, 14 Mar 2022 10:35:58 GMT, Tobias Hartmann wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> 8279508: Windows build failure fix. > > `compiler/c2/cr6340864/TestFloatVect.java` and `TestDoubleVect.java` fail on Windows: > > > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000001971b940123, pid=56524, tid=57368 > # > # JRE version: Java(TM) SE Runtime Environment (19.0) (fastdebug build 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 19-internal-2022-03-14-0834080.tobias.hartmann.jdk2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > # Problematic frame: > # J 205 c2 compiler.c2.cr6340864.TestFloatVect.test_round([I[F)V (24 bytes) @ 0x000001971b940123 [0x000001971b93ffe0+0x0000000000000143] Hi @TobiHartmann , Can you kindly regress latest changes through your test infrastructure Hi @theRealAph , Your suggestions incorporated. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From mikael at openjdk.java.net Fri Mar 18 20:32:29 2022 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 18 Mar 2022 20:32:29 GMT Subject: Integrated: 8283059: Uninitialized warning in check_code.c with GCC 11.2 In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 20:56:34 GMT, Mikael Vidstedt wrote: > Note: this PR replaces the one I messed up earlier. > > Background, from JBS: > > src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': > src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] > 942 | check_and_push(context, lengths, VM_MALLOC_BLK); > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here > 4145 | static void check_and_push(context_type *context, const void *ptr, int kind) > | ^~~~~~~~~~~~~~ > > Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. > > The same general issue was addressed in JDK-8266168, presumably for GCC 11.1. > > Details: > > Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function check_and_push_const which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion. > > To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call. > > Testing: > > tier1 + builds-tier{2,3,4,5} This pull request has now been integrated. Changeset: d8893fad Author: Mikael Vidstedt URL: https://git.openjdk.java.net/jdk/commit/d8893fad23d1ee6841336b96c34599643edb81ce Stats: 30 lines in 1 file changed: 9 ins; 0 del; 21 mod 8283059: Uninitialized warning in check_code.c with GCC 11.2 Reviewed-by: dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/7859 From duke at openjdk.java.net Fri Mar 18 21:08:33 2022 From: duke at openjdk.java.net (altrisi) Date: Fri, 18 Mar 2022 21:08:33 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v2] In-Reply-To: References: Message-ID: <2R7VNKY-j91jbM3uZX_L0832hRCvo7geX45jbkTEcrk=.f0550e5d-9a90-4dd3-9c05-8d06b5293aee@github.com> On Thu, 17 Mar 2022 08:07:23 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Swap mutable and volatile in the permits list Note that there's a class in tests (or something similar) that extends CallSite directly: https://github.com/openjdk/jdk/blob/d8893fad23d1ee6841336b96c34599643edb81ce/test/hotspot/jtreg/vmTestbase/vm/mlvm/patches/java.base/java/lang/invoke/NewInvokeSpecialCallSite.java ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From prr at openjdk.java.net Fri Mar 18 21:21:30 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 18 Mar 2022 21:21:30 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos Changes requested by prr (Reviewer). make/modules/java.desktop/gensrc/GensrcX11Wrappers.gmk line 27: > 25: > 26: # Generate java sources using the X11 offsets that are precalculated in files > 27: # src/java.desktop/share/data/x11wrappergen/sizes-

.txt. This doesn't seem right to me. This is X11 specific. It should not be in share. Same for related files. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From prr at openjdk.java.net Fri Mar 18 21:27:36 2022 From: prr at openjdk.java.net (Phil Race) Date: Fri, 18 Mar 2022 21:27:36 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 00:12:38 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix typos This doesn't seem right to me to put x11wrappergen into share. This is X11 specific. It should not be in share. Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From duke at openjdk.java.net Fri Mar 18 21:46:27 2022 From: duke at openjdk.java.net (liach) Date: Fri, 18 Mar 2022 21:46:27 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v2] In-Reply-To: <2R7VNKY-j91jbM3uZX_L0832hRCvo7geX45jbkTEcrk=.f0550e5d-9a90-4dd3-9c05-8d06b5293aee@github.com> References: <2R7VNKY-j91jbM3uZX_L0832hRCvo7geX45jbkTEcrk=.f0550e5d-9a90-4dd3-9c05-8d06b5293aee@github.com> Message-ID: On Fri, 18 Mar 2022 21:05:01 GMT, altrisi wrote: > Note that there's a class in tests (or something similar) that extends CallSite directly: https://github.com/openjdk/jdk/blob/d8893fad23d1ee6841336b96c34599643edb81ce/test/hotspot/jtreg/vmTestbase/vm/mlvm/patches/java.base/java/lang/invoke/NewInvokeSpecialCallSite.java Appears it's exclusively used by `GenManyIndyCorrectBootstrap`. Looking at that code, it's just used to create random indy instructions to stuff the constant pool: if (Env.getRNG().nextBoolean()) { bsm = new Handle(Opcodes.H_NEWINVOKESPECIAL, NEW_INVOKE_SPECIAL_CLASS_NAME, INIT_METHOD_NAME, NEW_INVOKE_SPECIAL_BOOTSTRAP_METHOD_SIGNATURE); } else { bsm = new Handle(Opcodes.H_INVOKESTATIC, this.fullClassName, BOOTSTRAP_METHOD_NAME, BOOTSTRAP_METHOD_SIGNATURE); } Appears we can just remove the randomization and always use a standard reference to the generated class' bootstrap method, and extending `CallSite` directly for such tiny functionality is overkill. If my approach is not desired, please speak out and suggest changes. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Fri Mar 18 22:12:10 2022 From: duke at openjdk.java.net (liach) Date: Fri, 18 Mar 2022 22:12:10 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: > Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. liach has updated the pull request incrementally with one additional commit since the last revision: Remove homemade callsite from test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7840/files - new: https://git.openjdk.java.net/jdk/pull/7840/files/eef61c31..1bcd779f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7840&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7840&range=01-02 Stats: 119 lines in 3 files changed: 2 ins; 113 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7840.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7840/head:pull/7840 PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Fri Mar 18 22:16:30 2022 From: duke at openjdk.java.net (liach) Date: Fri, 18 Mar 2022 22:16:30 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: <84jg2OY_T6CFoDhU0-4T26NPIqD6cTxj9nfgiew5UhA=.68bd1f89-722c-4e52-981f-382d7de267df@github.com> On Fri, 18 Mar 2022 19:11:45 GMT, jmehrens wrote: > > you are not expected to inspect a random object by its string. > > ToString representations tend to show up in exception messages and logging. Seems like this adapter just won't adapt that call. Not a deal breaker. > > > Also the reverse order comparator in Collections doesn't have a toString override as well. > > ToString wasn't added to that for compatibility reasons. Since this hasn't been released yet that doesn't apply here. > > https://bugs.openjdk.java.net/browse/JDK-6483125 How is this issue related at all? `equals` is [explicitly specified](https://github.com/openjdk/jdk/blob/8384ac4ed3eaaa18998ab88e1ca36358c212e699/src/java.base/share/classes/java/util/Comparator.java#L178) in comparator, while `toString` is not specified in `Random` at all. Also, my `Comparator` example talks about the `toString` method than the `equals` method. Please read the topics more carefully. ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From smarks at openjdk.java.net Fri Mar 18 23:51:37 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 18 Mar 2022 23:51:37 GMT Subject: RFR: 8279598: Provide adapter from RandomGenerator to Random [v19] In-Reply-To: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> References: <4CScKgCK77AQUoapbpjfA5fr4iogBOop8uxZZRIBTcA=.1dbaa9f1-da6d-45d3-b9a5-e96b737b22ca@github.com> Message-ID: <-4KquKI72AawNrJ3lWYXc1mj1nP7eyKrp4CCmdoUY_c=.29d0d2ec-bca6-4a34-8c6e-670089a08708@github.com> On Wed, 16 Mar 2022 14:54:41 GMT, Yasser Bazzi wrote: >> Hi, could i get a review on this implementation proposed by Stuart Marks, i decided to use the https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/random/RandomGenerator.html interface to create the default method `asRandom()` that wraps around the newer algorithms to be used on classes that do not accept the new interface. >> >> Some things to note as proposed by the bug report, the protected method next(int bits) is not overrided and setSeed() method if left blank up to discussion on what to do with it. >> >> Small test done on https://gist.github.com/YShow/da678561419cda8e32fccf3a27a649d4 > > Yasser Bazzi has updated the pull request incrementally with one additional commit since the last revision: > > add since in javadoc On the `toString` issue: there's no specification requirement for this nor is there need to change any specification, but it might be nice to provide a friendly implementation. I note that `SecureRandom` does override `toString` and delegates to the SPI. It seems reasonable for `RandomWrapper` to say that it's a wrapper around some `RandomGenerator` instance. It doesn't look like any of the generators currently override `toString`, but the default implementation would show the classname which is somewhat useful. If in the future a generator were to provide useful information in its string, that would be passed through the wrapper's string. The implementation could be as simple as return "RandomWrapper[" + generator + "]"; ------------- PR: https://git.openjdk.java.net/jdk/pull/7001 From smarks at openjdk.java.net Sat Mar 19 00:48:23 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 19 Mar 2022 00:48:23 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v4] In-Reply-To: References: Message-ID: <4G1xsefnA_jRtsxJYpnQC2n9Jal49p4DWiu5TS-w4vg=.1831dff3-deda-4955-b4cf-aca4728b009b@github.com> On Wed, 16 Mar 2022 17:16:06 GMT, liach wrote: >> liach has updated the pull request incrementally with two additional commits since the last revision: >> >> - merge branch 'identityhashmap-bench' of https://github.com/liachmodded/jdk into identityhashmap-default >> - fix whitespace > > @stuart-marks Could you help me with this? > > In my JMH benchmark runs, I often find that ambient differences (from the jdk processes, the random test data generated, etc.) hide the actual performance difference caused by the patches. > > Hence, I need help in these two area: > 1. I probably need to make a baseline benchmark that can discount the fundamental differences between jdk processes. What should it be? > 2. How do I generate consistent data set for all test runs to avoid contributing to errors? @liach I don't have much time to spend on this. Several comments. JMH benchmarking is more than a bit of an art. There's a lot of information in the JMH samples, so I'd recommend going through them in detail if you haven't already. There are a couple of obvious things to look at, such as to make sure to return values produced by the computation (or use black holes); to fork multiple JVMs during the benchmark run; to reduce or eliminate garbage generation during the test, or account for it if it can't be eliminated; and so forth. In this particular case it's not clear to me how much performance there is to be gained from overriding the default methods. Suppose an entry exists and `compute(k, bifunc)` is called. The default method calls `get` to obtain the value, calls the bifunction, then calls `put(k, newVal)`. An optimized implementation would remember the location of the mapping so that the new value could be stored without probing again. But probing in an IdentityHashMap is likely pretty inexpensive: the identity hashcode is cached, finding the table index is integer arithmetic, and searching for the right mapping is reference comparisons on table entries that are probably already cached. It doesn't seem likely to me that there is much to be gained here in the first place. Then again, one's intuition about performance, including mine, is easily wrong! But: if you're having trouble writing a benchmark that demonstrates a performance improvement, maybe that means there isn't much performance to be gained. As a general comment I'd suggest pursuing performance improvements only when there's a demonstrated performance issue. This kind of looks to me like a case of starting with "I bet I can speed this up by changing this code" and then trying to justify that with benchmarks. If so, that's kind of backwards, and it can easily lead to a lot of time being wasted. ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From jiefu at openjdk.java.net Sat Mar 19 02:49:28 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 19 Mar 2022 02:49:28 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: Message-ID: On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong wrote: > The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. > And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. > > To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: > - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. > - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. > > So with this patch, the following transformations are applied: > > For non-masked negation with NEON: > > movi v16.4s, #0x0 > sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s > > and with SVE: > > mov z16.s, #0 > sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s > > For masked negation with NEON: > > movi v17.4s, #0x1 > mvn v19.16b, v18.16b > mov v20.16b, v16.16b ==> neg v18.4s, v17.4s > bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b > add v19.4s, v20.4s, v17.4s > mov v18.16b, v16.16b > bsl v18.16b, v19.16b, v20.16b > > and with SVE: > > mov z16.s, #-1 > mov z17.s, #1 ==> neg z16.s, p0/m, z16.s > eor z18.s, p0/m, z18.s, z16.s > add z18.s, p0/m, z18.s, z17.s > > Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): > > NEON: > Benchmark Gain > Byte128Vector.NEG 1.029 > Byte128Vector.NEGMasked 1.757 > Short128Vector.NEG 1.041 > Short128Vector.NEGMasked 1.659 > Int128Vector.NEG 1.005 > Int128Vector.NEGMasked 1.513 > Long128Vector.NEG 1.003 > Long128Vector.NEGMasked 1.878 > > SVE with 512-bits: > Benchmark Gain > ByteMaxVector.NEG 1.10 > ByteMaxVector.NEGMasked 1.165 > ShortMaxVector.NEG 1.056 > ShortMaxVector.NEGMasked 1.195 > IntMaxVector.NEG 1.002 > IntMaxVector.NEGMasked 1.239 > LongMaxVector.NEG 1.031 > LongMaxVector.NEGMasked 1.191 > > X86 (non AVX-512): > Benchmark Gain > ByteMaxVector.NEGMasked 1.254 > ShortMaxVector.NEGMasked 1.359 > IntMaxVector.NEGMasked 1.431 > LongMaxVector.NEGMasked 1.989 > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 src/hotspot/share/opto/vectorIntrinsics.cpp line 209: > 207: #ifndef PRODUCT > 208: if (C->print_intrinsics()) { > 209: tty->print_cr(" ** Rejected vector op (%s,%s,%d) because architecture does not support variable vector negate", "variable vector negate" seems a bit strange to me. How about removing "variable"? src/hotspot/share/opto/vectorIntrinsics.cpp line 291: > 289: if ((mask_use_type & VecMaskUsePred) != 0) { > 290: if (!Matcher::has_predicated_vectors()) { > 291: return false; If we return here, we would miss the intrinsic failing msg "Rejected vector mask predicate using ...", right? src/hotspot/share/opto/vectornode.cpp line 141: > 139: case T_BYTE: > 140: case T_SHORT: > 141: case T_INT: return Op_NegVI; Why not add `Op_NegVB` for `BYTE` and `Op_NegVS` for `SHORT`? Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector? src/hotspot/share/opto/vectornode.cpp line 1635: > 1633: } > 1634: > 1635: Node* NegVINode::Ideal(PhaseGVN* phase, bool can_reshape) { Much duplication in `NegVINode::Ideal` and `NegVLNode::Ideal`. Is it possible to refactor the implementation? ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From jiefu at openjdk.java.net Sat Mar 19 03:14:26 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 19 Mar 2022 03:14:26 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com> Message-ID: On Tue, 15 Mar 2022 02:47:20 GMT, Xiaohong Gong wrote: > Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: > > double negate(double arg) {return -0.0 - arg; } > > This is to handle signed zeros correctly. This seems easy to be broken by an opt enhancement. Just wondering do we have a jtreg test for this point? @jddarcy Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From duke at openjdk.java.net Sat Mar 19 07:10:29 2022 From: duke at openjdk.java.net (Tyler Steele) Date: Sat, 19 Mar 2022 07:10:29 GMT Subject: Integrated: 8283287: ClassLoader.c cleanups In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 21:25:37 GMT, Tyler Steele wrote: > As mentioned in the issue, I'd like to perform the following tidying on ClassLoader.c > > - Alphabetize includes. > - Replace 'if (ptr == 0)' with 'if (ptr == NULL)'. > - Replace 'return 0' with 'return NULL'. This pull request has now been integrated. Changeset: 3e58a438 Author: Tyler Steele Committer: Thomas Stuefe URL: https://git.openjdk.java.net/jdk/commit/3e58a438e9051d4c976273eea35e36d37d5428c3 Stats: 33 lines in 1 file changed: 8 ins; 5 del; 20 mod 8283287: ClassLoader.c cleanups Reviewed-by: stuefe, alanb, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7846 From turbanoff at gmail.com Sat Mar 19 18:20:59 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sat, 19 Mar 2022 21:20:59 +0300 Subject: Unused paramter 'boolean newln' in java.lang.VersionProps#print(boolean err, boolean newln) Message-ID: Hello. I found a suspicious method java.lang.VersionProps#print with unused parameter 'boolean newln'. This class is generated from template - https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/VersionProps.java.template#L203 It's unused since integration of 'JDK-8169069 Module system implementation refresh (11/2016)' - https://github.com/openjdk/jdk/commit/fbe85300bfcc69cb4dd56e4df33ceea632366283 Andrey Turbanov From turbanoff at gmail.com Sat Mar 19 18:39:14 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Sat, 19 Mar 2022 21:39:14 +0300 Subject: Visual Studio 2005/2008 code in 'src/java.base/share/native/launcher/main.c' Message-ID: Hello. During my review of the JDK codebase, I found that launcher's 'main.c' still has code, which included only with Visual Studio 2005 and 2008. https://github.com/openjdk/jdk/blob/3f923b82c31325504430b50dee262fd460004e7b/src/java.base/share/native/launcher/main.c#L38 #if _MSC_VER > 1400 && _MSC_VER < 1600 /* * When building for Microsoft Windows, main has a dependency on msvcr??.dll. * * When using Visual Studio 2005 or 2008, that must be recorded in #ifdef _MSC_VER I wonder, shouldn't such code be removed, when JDK drops support of old compiler/toolchains? As I know, JDK now supports only recent versions of Visual Studio. (2017+). Or this file should be compilable with older versions as well? Andrey Turbanov From duke at openjdk.java.net Sat Mar 19 19:28:22 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 19 Mar 2022 19:28:22 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v4] In-Reply-To: <4G1xsefnA_jRtsxJYpnQC2n9Jal49p4DWiu5TS-w4vg=.1831dff3-deda-4955-b4cf-aca4728b009b@github.com> References: <4G1xsefnA_jRtsxJYpnQC2n9Jal49p4DWiu5TS-w4vg=.1831dff3-deda-4955-b4cf-aca4728b009b@github.com> Message-ID: On Sat, 19 Mar 2022 00:45:14 GMT, Stuart Marks wrote: >> @stuart-marks Could you help me with this? >> >> In my JMH benchmark runs, I often find that ambient differences (from the jdk processes, the random test data generated, etc.) hide the actual performance difference caused by the patches. >> >> Hence, I need help in these two area: >> 1. I probably need to make a baseline benchmark that can discount the fundamental differences between jdk processes. What should it be? >> 2. How do I generate consistent data set for all test runs to avoid contributing to errors? > > @liach I don't have much time to spend on this. Several comments. > > JMH benchmarking is more than a bit of an art. There's a lot of information in the JMH samples, so I'd recommend going through them in detail if you haven't already. There are a couple of obvious things to look at, such as to make sure to return values produced by the computation (or use black holes); to fork multiple JVMs during the benchmark run; to reduce or eliminate garbage generation during the test, or account for it if it can't be eliminated; and so forth. > > In this particular case it's not clear to me how much performance there is to be gained from overriding the default methods. Suppose an entry exists and `compute(k, bifunc)` is called. The default method calls `get` to obtain the value, calls the bifunction, then calls `put(k, newVal)`. An optimized implementation would remember the location of the mapping so that the new value could be stored without probing again. But probing in an IdentityHashMap is likely pretty inexpensive: the identity hashcode is cached, finding the table index is integer arithmetic, and searching for the right mapping is reference comparisons on table entries that are probably already cached. It doesn't seem likely to me that there is much to be gained here in the first place. > > Then again, one's intuition about performance, including mine, is easily wrong! But: if you're having trouble writing a benchmark that demonstrates a performance improvement, maybe that means there isn't much performance to be gained. > > As a general comment I'd suggest pursuing performance improvements only when there's a demonstrated performance issue. This kind of looks to me like a case of starting with "I bet I can speed this up by changing this code" and then trying to justify that with benchmarks. If so, that's kind of backwards, and it can easily lead to a lot of time being wasted. @stuart-marks Note?that the?default implementation of?those?methods assume?that the?map uses?`Object.equals(?)` and?`Object.hashCode()`, which?doesn?t?apply to?`IdentityHashMap`. This?means?that the?performance argument is?secondary to?implementation?correctness. ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From duke at openjdk.java.net Sat Mar 19 20:00:27 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 19 Mar 2022 20:00:27 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 22:12:10 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Remove homemade callsite from test The?purpose of?`GenManyIndyCorrectBootstrap`?s `NewInvokeSpecialCallSite` is?to?check that?bootstrap?methods work?correctly with?a?`REF_newInvokeSpecial` method?handle. Instead, it?should?probably be?implemented by?subclassing `MutableCallSite`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Sat Mar 19 20:02:23 2022 From: duke at openjdk.java.net (liach) Date: Sat, 19 Mar 2022 20:02:23 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v4] In-Reply-To: <4G1xsefnA_jRtsxJYpnQC2n9Jal49p4DWiu5TS-w4vg=.1831dff3-deda-4955-b4cf-aca4728b009b@github.com> References: <4G1xsefnA_jRtsxJYpnQC2n9Jal49p4DWiu5TS-w4vg=.1831dff3-deda-4955-b4cf-aca4728b009b@github.com> Message-ID: On Sat, 19 Mar 2022 00:45:14 GMT, Stuart Marks wrote: >> @stuart-marks Could you help me with this? >> >> In my JMH benchmark runs, I often find that ambient differences (from the jdk processes, the random test data generated, etc.) hide the actual performance difference caused by the patches. >> >> Hence, I need help in these two area: >> 1. I probably need to make a baseline benchmark that can discount the fundamental differences between jdk processes. What should it be? >> 2. How do I generate consistent data set for all test runs to avoid contributing to errors? > > @liach I don't have much time to spend on this. Several comments. > > JMH benchmarking is more than a bit of an art. There's a lot of information in the JMH samples, so I'd recommend going through them in detail if you haven't already. There are a couple of obvious things to look at, such as to make sure to return values produced by the computation (or use black holes); to fork multiple JVMs during the benchmark run; to reduce or eliminate garbage generation during the test, or account for it if it can't be eliminated; and so forth. > > In this particular case it's not clear to me how much performance there is to be gained from overriding the default methods. Suppose an entry exists and `compute(k, bifunc)` is called. The default method calls `get` to obtain the value, calls the bifunction, then calls `put(k, newVal)`. An optimized implementation would remember the location of the mapping so that the new value could be stored without probing again. But probing in an IdentityHashMap is likely pretty inexpensive: the identity hashcode is cached, finding the table index is integer arithmetic, and searching for the right mapping is reference comparisons on table entries that are probably already cached. It doesn't seem likely to me that there is much to be gained here in the first place. > > Then again, one's intuition about performance, including mine, is easily wrong! But: if you're having trouble writing a benchmark that demonstrates a performance improvement, maybe that means there isn't much performance to be gained. > > As a general comment I'd suggest pursuing performance improvements only when there's a demonstrated performance issue. This kind of looks to me like a case of starting with "I bet I can speed this up by changing this code" and then trying to justify that with benchmarks. If so, that's kind of backwards, and it can easily lead to a lot of time being wasted. > @stuart-marks Note?that the?default implementation of?those?methods assume?that the?map uses?`Object.equals(?)` and?`Object.hashCode()`, which?doesn?t?apply to?`IdentityHashMap`. > > This?means?that the?performance argument is?secondary to?implementation?correctness. That was tracked in a separate ticket [JDK-8178355](https://bugs.openjdk.java.net/browse/JDK-8178355). My current implementations utilize the newly added `findInterestingIndex`, which I plan to use in a fix for that bug in addition, as opposed to writing a while loop in virtually every method in the class. ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From duke at openjdk.java.net Sat Mar 19 19:50:25 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sat, 19 Mar 2022 19:50:25 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v4] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 23:36:19 GMT, liach wrote: >> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. > > liach has updated the pull request incrementally with two additional commits since the last revision: > > - merge branch 'identityhashmap-bench' of https://github.com/liachmodded/jdk into identityhashmap-default > - fix whitespace src/java.base/share/classes/java/util/IdentityHashMap.java line 523: > 521: * mapping was in the map > 522: */ > 523: private boolean removeMapping(Object key, Object value) { Note?that `IdentityHashMap.remove(Object,?Object)` needs?to?call this?method, as?the?default implementation calls `Objects.equals(?)`: ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From duke at openjdk.java.net Sat Mar 19 20:19:26 2022 From: duke at openjdk.java.net (liach) Date: Sat, 19 Mar 2022 20:19:26 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 22:12:10 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Remove homemade callsite from test Hmm, I think the purpose of this test is just to fill up the class constant pool with random garbage and to ensure it runs, and using either type of indy doesn't seem to make big differences. Moreover, these tests [need to be reworked](https://github.com/openjdk/jdk/blob/d8893fad23d1ee6841336b96c34599643edb81ce/test/hotspot/jtreg/vmTestbase/README.md), but I don't think I am suited for such a rework for this test. -------------------------- If we do tweak the test, a subclass of `ConstantCallSite` would work too: public class CustomCallSite extends ConstantCallSite { public CustomCallSite(MethodHandles.Lookup lookup, String callName, MethodType mtype, MethodHandle handle) { super(handle); } } And we write bytecode that makes an indy using this ctor as bootstrap method and additionally pass a `Handle` with `fullClassName`, `TARGET_METHOD_NAME`, `TARGET_METHOD_SIGNATURE`. https://github.com/openjdk/jdk/blob/d8893fad23d1ee6841336b96c34599643edb81ce/test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/share/GenManyIndyCorrectBootstrap.java#L107-L109 Becomes mw.visitInvokeDynamicInsn(TARGET_METHOD_NAME, TARGET_METHOD_SIGNATURE, bsm, customCallSite ? new Object[] {TARGET_HANDLE} : new Object[0]); The problem with this approach is: 1. Where should I put this `CustomCallSite` class? The bootstrap is only a class generator as opposed to a runtime, and this class probably shouldn't be put into the patches for `java.lang`. (In fact, the patches on asm should be replaced by patches on a shaded standalone asm library to reduce compile time for tests, too) - Should I generate it in the `generateBytecodes` method instead? 2. The approach of using a indy + a MethodHandle constant would use an extra constant, wonder if it hurts the goal of filling up the constant pool without exceeding the limit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Sat Mar 19 20:26:24 2022 From: duke at openjdk.java.net (liach) Date: Sat, 19 Mar 2022 20:26:24 GMT Subject: RFR: JDK-8277520: Implement JDK-8 default methods for IdentityHashMap [v4] In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 23:36:19 GMT, liach wrote: >> Might need a CSR as now `computeIfAbsent` `computeIfPresent` `compute` `merge` would throw CME if the functions modified the map itself, and there are corresponding specification changes. > > liach has updated the pull request incrementally with two additional commits since the last revision: > > - merge branch 'identityhashmap-bench' of https://github.com/liachmodded/jdk into identityhashmap-default > - fix whitespace Also re stuart: The relative performance of `putIfAbsent` versus `put` has always improved with this patch, now being 1.01 times of `put` call time while previously it was 1.2 times of it, regardless of jvm instance noise. My main concern is the performance hit brought by my move of the while loops in every method into a consolidated `findInterestingIndex`. This part is somehow harder to get consistent results, or should I make a clean copy of `IdentityHashMap` on new implementation and test (works only if there is no existing hotspot optimizations on `IdentityHashMap`) ------------- PR: https://git.openjdk.java.net/jdk/pull/6532 From darcy at openjdk.java.net Sat Mar 19 22:36:38 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 19 Mar 2022 22:36:38 GMT Subject: RFR: JDK-8283415: Update java.lang.ref to use sealed classes Message-ID: Another refactoring to use sealed classes where possible, this time in the java.lang.ref package. Copyright dates will be updated, if needed, before a push. ------------- Commit messages: - JDK-8283415: Update java.lang.ref to use sealed classes Changes: https://git.openjdk.java.net/jdk/pull/7874/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7874&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283415 Stats: 6 lines in 5 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7874/head:pull/7874 PR: https://git.openjdk.java.net/jdk/pull/7874 From joe.darcy at oracle.com Sat Mar 19 22:38:20 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Sat, 19 Mar 2022 15:38:20 -0700 Subject: FYI, candidate list of classes to be updated to sealed in JDK-8283414: Update java.base to use sealed classes (umbrella) Message-ID: <63f66025-f2ff-6311-f5e7-31f3f70c2697@oracle.com> Hello, With a number of efforts to update various class hierarchies in the JDK to sealed classes, I wrote an annotation processor to find candidates to be changed to sealed. The candidates for this analysis are non-final public classes with at least one package access constructor and no public constructors. That is, the candidate class cannot be generally subclassable. Several dozen candidates were identified and listed in JDK-8283414, including two cases where changing the classes in question to sealed was already out for review (JDK-8282536 and JDK-8283237). I've created subtasks for a number of other cases in core-libs; the cases in security libs could also be reviewed. -Joe From jpai at openjdk.java.net Sun Mar 20 04:29:39 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 20 Mar 2022 04:29:39 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes Message-ID: Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. tier1, tier2, tier3 tests have been run successfully with this change. ------------- Commit messages: - 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes Changes: https://git.openjdk.java.net/jdk/pull/7875/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7875&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283411 Stats: 3 lines in 1 file changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7875/head:pull/7875 PR: https://git.openjdk.java.net/jdk/pull/7875 From kbarrett at openjdk.java.net Sun Mar 20 05:17:29 2022 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 20 Mar 2022 05:17:29 GMT Subject: RFR: JDK-8283415: Update java.lang.ref to use sealed classes In-Reply-To: References: Message-ID: <4Ackk7fcVWDWTa2eXmIkOeXEOw2eLjcBALQZJBidUGU=.5ba86b57-86ed-4098-a9c2-1383af5293c1@github.com> On Sat, 19 Mar 2022 22:30:13 GMT, Joe Darcy wrote: > Another refactoring to use sealed classes where possible, this time in the java.lang.ref package. > > Copyright dates will be updated, if needed, before a push. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7874 From lancea at openjdk.java.net Sun Mar 20 10:51:23 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sun, 20 Mar 2022 10:51:23 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 04:24:07 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? > > The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. > > tier1, tier2, tier3 tests have been run successfully with this change. Hi Jaikiran, This looks fine. Please add the label noreg-trivial to the bug otherwise you will get a ping as there is no test associated with the PR ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7875 From ecki at zusammenkunft.net Sun Mar 20 11:30:20 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sun, 20 Mar 2022 11:30:20 +0000 Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes In-Reply-To: References: Message-ID: Hello, Not sure how often skip is actually used so it might not matter, but this change would increase allocations if skip is called regularly. Not sure if EA can prevent that if it is only medium hot and therefore the callsite is not compiled or inlined? An alternative would be to make this static and/or allocate lazy (or even share it with more places which need a write-only array?) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Lance Andersen Gesendet: Sunday, March 20, 2022 11:51:23 AM An: core-libs-dev at openjdk.java.net Betreff: Re: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes On Sun, 20 Mar 2022 04:24:07 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? > > The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. > > tier1, tier2, tier3 tests have been run successfully with this change. Hi Jaikiran, This looks fine. Please add the label noreg-trivial to the bug otherwise you will get a ping as there is no test associated with the PR ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7875 From jai.forums2013 at gmail.com Sun Mar 20 12:18:37 2022 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sun, 20 Mar 2022 17:48:37 +0530 Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes In-Reply-To: References: Message-ID: Hello Bernd, On 20/03/22 5:00 pm, Bernd Eckenfels wrote: > Hello, > > Not sure how often skip is actually used so it might not matter, but this change would increase allocations if skip is called regularly. I had given this a thought before changing it. The skip doesn't get called in a regular jar/zip entry content retrieval use case (which from what I can see is the most used one). So instead of allocating an additional 512 bytes, holding onto it till the stream is closed and never using it, for each entry of a zip whose content is fetched, I think it's better to allocate it only when needed in skip(). -Jaikiran From aturbanov at openjdk.java.net Sun Mar 20 13:50:42 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Sun, 20 Mar 2022 13:50:42 GMT Subject: RFR: 8283426: Fix 'exeption' typo Message-ID: Fix repeated type `exeption` ------------- Commit messages: - [PATCH] Typo 'Exeption' instead of 'Exception' Changes: https://git.openjdk.java.net/jdk/pull/7879/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283426 Stats: 24 lines in 10 files changed: 0 ins; 2 del; 22 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From alanb at openjdk.java.net Sun Mar 20 13:56:26 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 20 Mar 2022 13:56:26 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 04:24:07 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? > > The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. > > tier1, tier2, tier3 tests have been run successfully with this change. src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 206: > 204: int max = (int)Math.min(n, Integer.MAX_VALUE); > 205: int total = 0; > 206: byte[] b = new byte[512]; n may be less than 512 so maybe the temporary array can be of length Math.min(max, 512). ------------- PR: https://git.openjdk.java.net/jdk/pull/7875 From tvaleev at openjdk.java.net Sun Mar 20 14:02:25 2022 From: tvaleev at openjdk.java.net (Tagir F.Valeev) Date: Sun, 20 Mar 2022 14:02:25 GMT Subject: RFR: 8280915: Better parallelization for AbstractSpliterator and IteratorSpliterator when size is unknown [v5] In-Reply-To: References: Message-ID: On Thu, 10 Feb 2022 04:30:34 GMT, Tagir F. Valeev wrote: >> See the bug description for details. >> >> I propose a simple solution. Let's allow ArraySpliterator to be non-SIZED and report artificial estimatedSize(), much bigger than the real one. This will allow AbstractSpliterator and IteratorSpliterator to produce prefix whose size is comparable to Long.MAX_VALUE (say, starting with Long.MAX_VALUE/2), and this will enable further splitting of the prefix. This change will drastically improve parallel streaming for affected streams of size <= 1024 and significantly improve for streams of size 1025..20000. The cost is higher-grained splitting for huge streams of unknown size. This might add a minor overhead for such scenarios which, I believe, is completely tolerable. >> >> No public API changes are necessary, sequential processing should not be affected, except an extra field in ArraySpliterator which increases a footprint by 8 bytes. >> >> I added a simple test using an artificial collector to ensure that at least two non-empty parts are created when parallelizing Stream.iterate source. More testing ideas are welcome. > > Tagir F. Valeev has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Cosmetic fixes A gentle ping :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/7279 From jpai at openjdk.java.net Sun Mar 20 14:05:58 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 20 Mar 2022 14:05:58 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? > > The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. > > tier1, tier2, tier3 tests have been run successfully with this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Use Alan's suggestion and allocate less than 512 bytes if possible. Plus copyright year fix. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7875/files - new: https://git.openjdk.java.net/jdk/pull/7875/files/6bc997fb..f4250e7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7875&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7875&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7875/head:pull/7875 PR: https://git.openjdk.java.net/jdk/pull/7875 From jpai at openjdk.java.net Sun Mar 20 14:05:59 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Sun, 20 Mar 2022 14:05:59 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2] In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:53:34 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Use Alan's suggestion and allocate less than 512 bytes if possible. Plus copyright year fix. > > src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 206: > >> 204: int max = (int)Math.min(n, Integer.MAX_VALUE); >> 205: int total = 0; >> 206: byte[] b = new byte[512]; > > n may be less than 512 so maybe the temporary array can be of length Math.min(max, 512). That's a good idea. I just pushed a update to this PR with this suggested change. Plus updated the copyright year too. ------------- PR: https://git.openjdk.java.net/jdk/pull/7875 From xuelei at openjdk.java.net Sun Mar 20 14:41:37 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Sun, 20 Mar 2022 14:41:37 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: <_PAkHa5ReaDzrQiBnAEskX-GEe8viZdHkXfcUgMUBro=.f8aa01f8-13cf-4847-8f51-00e3b3e10516@github.com> On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated type `exeption` Looks good to me. Thanks! ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7879 From iris at openjdk.java.net Sun Mar 20 14:57:22 2022 From: iris at openjdk.java.net (Iris Clark) Date: Sun, 20 Mar 2022 14:57:22 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated type `exeption` Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From alanb at openjdk.java.net Sun Mar 20 16:31:26 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sun, 20 Mar 2022 16:31:26 GMT Subject: RFR: JDK-8283415: Update java.lang.ref to use sealed classes In-Reply-To: References: Message-ID: On Sat, 19 Mar 2022 22:30:13 GMT, Joe Darcy wrote: > Another refactoring to use sealed classes where possible, this time in the java.lang.ref package. > > Copyright dates will be updated, if needed, before a push. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7874 From darcy at openjdk.java.net Sun Mar 20 17:48:26 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 20 Mar 2022 17:48:26 GMT Subject: RFR: JDK-8283415: Update java.lang.ref to use sealed classes In-Reply-To: References: Message-ID: <2Sp3peC8P7Bxd1NMc4vHRiXcEcHlRGH7Lf-jBvxANmo=.f9149414-7481-430b-8e2c-d5778374165c@github.com> On Sun, 20 Mar 2022 16:28:36 GMT, Alan Bateman wrote: >> Another refactoring to use sealed classes where possible, this time in the java.lang.ref package. >> >> Copyright dates will be updated, if needed, before a push. > > Marked as reviewed by alanb (Reviewer). PS @AlanBateman and @kimbarrett , please also review the CSR https://bugs.openjdk.java.net/browse/JDK-8283428 Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7874 From liangchenblue at gmail.com Sun Mar 20 19:03:56 2022 From: liangchenblue at gmail.com (-) Date: Sun, 20 Mar 2022 14:03:56 -0500 Subject: CSR creation request for JDK-8283237 Message-ID: Hello, I hereby request the creation of a CSR request for bug 8283237 by a jdk project author or committer, with the following contents: CSR of: JDK-8283237 Component: core-libs Subcomponent: java.lang.invoke Compatibility Kind: source Compatibility risk: minimal Compatibility Risk Description: Given all constructors of java.lang.invoke.CallSite were package-private, no application or non-JDK code is expected to break, as they could not create direct subclasses to CallSite before. Interface Kind: Java API Scope: SE Description: ## Summary `java.lang.invoke.CallSite` will be marked as a sealed class; its direct subclasses, `ConstantCallSite`, `VolatileCallSite`, and `MutableCallSite`, will be marked as non-sealed classes. The documentation of `CallSite` is updated to mention sealed and non-sealed status of these classes. ## Problem `CallSite` is not intended to be directly subclassed, but it may not be straightforward, especially when only the bytecode of the JDK API is available. Moreover, it may be a bit hard to navigate to the three immediate subclasses. ## Solution Marking `CallSite` as `sealed` and listing the permitted subclasses (in the order they appear in the documentation) makes the API design more obvious, and the documentation of `CallSite` is updated to reflect the seal change. `ConstantCallSite`, `VolatileCallSite`, and `MutableCallSite` will be marked as `non-sealed`, as they are extendable by design. ## Specification ```patch diff --git a/src/java.base/share/classes/java/lang/invoke/CallSite.java b/src/java.base/share/classes/java/lang/invoke/CallSite.java index e159e235f30..172d33f65b6 100644 --- a/src/java.base/share/classes/java/lang/invoke/CallSite.java +++ b/src/java.base/share/classes/java/lang/invoke/CallSite.java @@ -40,9 +40,9 @@ import jdk.internal.vm.annotation.Stable; * In any case, it may be invoked through an associated method handle * called its {@linkplain #dynamicInvoker dynamic invoker}. *

- * {@code CallSite} is an abstract class which does not allow + * {@code CallSite} is an abstract sealed class which does not allow * direct subclassing by users. It has three immediate, - * concrete subclasses that may be either instantiated or subclassed. + * concrete non-sealed subclasses that may be either instantiated or subclassed. *

    *
  • If a mutable target is not required, an {@code invokedynamic} instruction * may be permanently bound by means of a {@linkplain ConstantCallSite constant call site}. @@ -85,7 +85,7 @@ private static CallSite bootstrapDynamic(MethodHandles.Lookup caller, String nam * @since 1.7 */ public -abstract class CallSite { +abstract sealed class CallSite permits ConstantCallSite, MutableCallSite, VolatileCallSite { // The actual payload of this call site. // Can be modified using {@link MethodHandleNatives#setCallSiteTargetNormal} or {@link MethodHandleNatives#setCallSiteTargetVolatile}. diff --git a/src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java b/src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java index e2e3f478a3c..833cd5b117a 100644 --- a/src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java +++ b/src/java.base/share/classes/java/lang/invoke/ConstantCallSite.java @@ -35,7 +35,7 @@ import jdk.internal.vm.annotation.Stable; * @author John Rose, JSR 292 EG * @since 1.7 */ -public class ConstantCallSite extends CallSite { +public non-sealed class ConstantCallSite extends CallSite { private static final Unsafe UNSAFE = Unsafe.getUnsafe(); @Stable // should NOT be constant folded during instance initialization (isFrozen == false) diff --git a/src/java.base/share/classes/java/lang/invoke/MutableCallSite.java b/src/java.base/share/classes/java/lang/invoke/MutableCallSite.java index c16483d02ae..c100657df6b 100644 --- a/src/java.base/share/classes/java/lang/invoke/MutableCallSite.java +++ b/src/java.base/share/classes/java/lang/invoke/MutableCallSite.java @@ -83,7 +83,7 @@ assertEquals("Wilma, dear?", (String) worker2.invokeExact()); * @author John Rose, JSR 292 EG * @since 1.7 */ -public class MutableCallSite extends CallSite { +public non-sealed class MutableCallSite extends CallSite { /** * Creates a blank call site object with the given method type. * The initial target is set to a method handle of the given type diff --git a/src/java.base/share/classes/java/lang/invoke/VolatileCallSite.java b/src/java.base/share/classes/java/lang/invoke/VolatileCallSite.java index 742fa23737d..ea068ff07e6 100644 --- a/src/java.base/share/classes/java/lang/invoke/VolatileCallSite.java +++ b/src/java.base/share/classes/java/lang/invoke/VolatileCallSite.java @@ -42,7 +42,7 @@ package java.lang.invoke; * @author John Rose, JSR 292 EG * @since 1.7 */ -public class VolatileCallSite extends CallSite { +public non-sealed class VolatileCallSite extends CallSite { /** * Creates a call site with a volatile binding to its target. * The initial target is set to a method handle ``` From darcy at openjdk.java.net Sun Mar 20 21:38:51 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sun, 20 Mar 2022 21:38:51 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes Message-ID: Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 ------------- Commit messages: - JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes Changes: https://git.openjdk.java.net/jdk/pull/7881/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7881&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283416 Stats: 16 lines in 5 files changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7881.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7881/head:pull/7881 PR: https://git.openjdk.java.net/jdk/pull/7881 From dholmes at openjdk.java.net Mon Mar 21 00:56:30 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 21 Mar 2022 00:56:30 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` Looks good. Thanks for cleaning this up. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7879 From xgong at openjdk.java.net Mon Mar 21 01:24:40 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 21 Mar 2022 01:24:40 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: Message-ID: On Sat, 19 Mar 2022 02:34:55 GMT, Jie Fu wrote: >> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. >> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. >> >> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: >> - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. >> - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. >> >> So with this patch, the following transformations are applied: >> >> For non-masked negation with NEON: >> >> movi v16.4s, #0x0 >> sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s >> >> and with SVE: >> >> mov z16.s, #0 >> sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s >> >> For masked negation with NEON: >> >> movi v17.4s, #0x1 >> mvn v19.16b, v18.16b >> mov v20.16b, v16.16b ==> neg v18.4s, v17.4s >> bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b >> add v19.4s, v20.4s, v17.4s >> mov v18.16b, v16.16b >> bsl v18.16b, v19.16b, v20.16b >> >> and with SVE: >> >> mov z16.s, #-1 >> mov z17.s, #1 ==> neg z16.s, p0/m, z16.s >> eor z18.s, p0/m, z18.s, z16.s >> add z18.s, p0/m, z18.s, z17.s >> >> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): >> >> NEON: >> Benchmark Gain >> Byte128Vector.NEG 1.029 >> Byte128Vector.NEGMasked 1.757 >> Short128Vector.NEG 1.041 >> Short128Vector.NEGMasked 1.659 >> Int128Vector.NEG 1.005 >> Int128Vector.NEGMasked 1.513 >> Long128Vector.NEG 1.003 >> Long128Vector.NEGMasked 1.878 >> >> SVE with 512-bits: >> Benchmark Gain >> ByteMaxVector.NEG 1.10 >> ByteMaxVector.NEGMasked 1.165 >> ShortMaxVector.NEG 1.056 >> ShortMaxVector.NEGMasked 1.195 >> IntMaxVector.NEG 1.002 >> IntMaxVector.NEGMasked 1.239 >> LongMaxVector.NEG 1.031 >> LongMaxVector.NEGMasked 1.191 >> >> X86 (non AVX-512): >> Benchmark Gain >> ByteMaxVector.NEGMasked 1.254 >> ShortMaxVector.NEGMasked 1.359 >> IntMaxVector.NEGMasked 1.431 >> LongMaxVector.NEGMasked 1.989 >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 > > src/hotspot/share/opto/vectornode.cpp line 141: > >> 139: case T_BYTE: >> 140: case T_SHORT: >> 141: case T_INT: return Op_NegVI; > > Why not add `Op_NegVB` for `BYTE` and `Op_NegVS` for `SHORT`? > Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector? The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files. > Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector? >From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short. Thanks! > src/hotspot/share/opto/vectornode.cpp line 1635: > >> 1633: } >> 1634: >> 1635: Node* NegVINode::Ideal(PhaseGVN* phase, bool can_reshape) { > > Much duplication in `NegVINode::Ideal` and `NegVLNode::Ideal`. > Is it possible to refactor the implementation? Yeah, maybe we need a superclass for `NegVINode` and `NegVLNode`. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From sundar at openjdk.java.net Mon Mar 21 04:07:33 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 21 Mar 2022 04:07:33 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. > > Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 "DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses." We can have a permits clause that lists fully qualified class name for the nested class and simple name for that separate type in the same package, right? Also $ cd $jdk_src/src/java.base/share/classes/java/lang/invoke $ grep "extends DelegatingMethodHandle" * MethodHandleImpl.java: private static final class AsVarargsCollector extends DelegatingMethodHandle { MethodHandleImpl.java: static class CountingWrapper extends DelegatingMethodHandle { MethodHandleImpl.java: private static final class WrappedMember extends DelegatingMethodHandle { MethodHandleImpl.java: static final class IntrinsicMethodHandle extends DelegatingMethodHandle All 4 are nested classes. Two of those subclasses are nested "private" in another class and hence cannot be referred from DelegatingMethodHandle's permits clause, right? ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From wetmore at openjdk.java.net Mon Mar 21 04:49:33 2022 From: wetmore at openjdk.java.net (Bradford Wetmore) Date: Mon, 21 Mar 2022 04:49:33 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` Good grief! I wouldn't have expected it to be so widespread. Thanks for noticing and fixing. ------------- Marked as reviewed by wetmore (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7879 From duke at openjdk.java.net Mon Mar 21 05:21:34 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 21 Mar 2022 05:21:34 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v10] In-Reply-To: References: Message-ID: <94AA8YHplB54wErPGAn65vhQCX-Hqcc6VxrfXGEbDDo=.a39c4bbf-08a5-40ed-8966-841e7a347bdc@github.com> On Fri, 18 Mar 2022 16:16:31 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with three additional commits since the last revision: > > - Typos > - Update Carrier.java > - Redo API to use list, bring Carrier.component back src/java.base/share/classes/java/lang/runtime/Carrier.java line 309: > 307: static { > 308: LOOKUP = MethodHandles.lookup(); > 309: UNSAFE = Unsafe.getUnsafe(); It?might be?better to?use `java.lang.invoke.MethodHandleStatics.UNSAFE`, and?probably?also `java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From darcy at openjdk.java.net Mon Mar 21 05:29:39 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 21 Mar 2022 05:29:39 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: <3kqdG9Zo06e0joMCd2qZ5inAs5UYQNTfz9-D-K8Jy-s=.78f01349-3dd2-49d8-ba5b-0b80ebd13b8e@github.com> On Mon, 21 Mar 2022 04:04:45 GMT, Athijegannathan Sundararajan wrote: > "DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses." > > We can have a permits clause that lists fully qualified class name for the nested class and simple name for that separate type in the same package, right? > > Also > > $ cd $jdk_src/src/java.base/share/classes/java/lang/invoke $ grep "extends DelegatingMethodHandle" * MethodHandleImpl.java: private static final class AsVarargsCollector extends DelegatingMethodHandle { MethodHandleImpl.java: static class CountingWrapper extends DelegatingMethodHandle { MethodHandleImpl.java: private static final class WrappedMember extends DelegatingMethodHandle { MethodHandleImpl.java: static final class IntrinsicMethodHandle extends DelegatingMethodHandle > > All 4 are nested classes. Two of those subclasses are nested "private" in another class and hence cannot be referred from DelegatingMethodHandle's permits clause, right? I did try to name the nested type in the permits clause, and it was not accepted by javac. (If all the subclasses are in the same compilation unit, either as auxiliary classes or nested classes, an explicit permits clause can be skipped as the compiler will infer it.) Per your other point about the nested classes in MethodHandleImpl, JLS 8.1.6 states: "Every TypeName [in the permits clause] must name an accessible class ([?6.6]), or a compile-time error occurs." so the private classes of another class would not be accessible either. ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From sundar at openjdk.java.net Mon Mar 21 06:11:27 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 21 Mar 2022 06:11:27 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: <6QxgD_j4URvME87pOMWMjtrcs8OWSCWlsHpmw2Bl1cg=.a4543478-ce6d-4755-9061-ffbcfa3f5c49@github.com> On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. > > Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 Hmm.. I tried the following example: $ cat com/acme/X.java package com.acme; // We can omit permits clause if all the subclasses are in the same compilation unit. // But that's applicable here as two subclasses "Z", "P.Q" are outside the compilation unit. // So we use explicit permits clause that lists all the subclasses. public sealed class X permits X.Y, W, Z, P.Q { final class Y extends X {} } final class W extends X {} $ cat com/acme/Z.java package com.acme; final class Z extends X { } $ cat com/acme/P.java package com.acme; class P { final class Q extends X {} } $ javac com/acme/*.java is fine. Am I missing something? ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From sundar at openjdk.java.net Mon Mar 21 06:17:33 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Mon, 21 Mar 2022 06:17:33 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. > > Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7881 From vtewari at openjdk.java.net Mon Mar 21 06:23:30 2022 From: vtewari at openjdk.java.net (Vyom Tewari) Date: Mon, 21 Mar 2022 06:23:30 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2] In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 14:05:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? >> >> The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. >> >> tier1, tier2, tier3 tests have been run successfully with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Use Alan's suggestion and allocate less than 512 bytes if possible. Plus copyright year fix. Looks ok. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.java.net/jdk/pull/7875 From forax at openjdk.java.net Mon Mar 21 06:33:38 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 21 Mar 2022 06:33:38 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v10] In-Reply-To: <94AA8YHplB54wErPGAn65vhQCX-Hqcc6VxrfXGEbDDo=.a39c4bbf-08a5-40ed-8966-841e7a347bdc@github.com> References: <94AA8YHplB54wErPGAn65vhQCX-Hqcc6VxrfXGEbDDo=.a39c4bbf-08a5-40ed-8966-841e7a347bdc@github.com> Message-ID: On Mon, 21 Mar 2022 05:17:31 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request incrementally with three additional commits since the last revision: >> >> - Typos >> - Update Carrier.java >> - Redo API to use list, bring Carrier.component back > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 309: > >> 307: static { >> 308: LOOKUP = MethodHandles.lookup(); >> 309: UNSAFE = Unsafe.getUnsafe(); > > It?might be?better to?use `java.lang.invoke.MethodHandleStatics.UNSAFE`, and?probably?also `java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP`. The package is java.lang.runtime not java.lang.invoke so both fields are not accessible. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From aivanov at openjdk.java.net Mon Mar 21 07:26:47 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 21 Mar 2022 07:26:47 GMT Subject: RFR: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` Marked as reviewed by aivanov (Reviewer). src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformEmbeddedFrame.java line 201: > 199: /* > 200: * The method could not be implemented due to CALayer restrictions. > 201: * The exception enforce clients not to use it. Suggestion: * The exception enforces clients not to use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From duke at openjdk.java.net Mon Mar 21 07:32:35 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 21 Mar 2022 07:32:35 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v10] In-Reply-To: References: <94AA8YHplB54wErPGAn65vhQCX-Hqcc6VxrfXGEbDDo=.a39c4bbf-08a5-40ed-8966-841e7a347bdc@github.com> Message-ID: On Mon, 21 Mar 2022 06:29:53 GMT, R?mi Forax wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 309: >> >>> 307: static { >>> 308: LOOKUP = MethodHandles.lookup(); >>> 309: UNSAFE = Unsafe.getUnsafe(); >> >> It?might be?better to?use `java.lang.invoke.MethodHandleStatics.UNSAFE`, and?probably?also `java.lang.invoke.MethodHandles.Lookup.IMPL_LOOKUP`. > > The package is java.lang.runtime not java.lang.invoke so both fields are not accessible. Well, you?could?use `SharedSecrets.getJavaLangInvokeAccess().findStatic(?)` and?`SharedSecrets.getJavaLangInvokeAccess().findVirtual(?)` in?place of?`LOOKUP.findStatic(?)` and?`LOOKUP.findVirtual(?)`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From fyang at openjdk.java.net Mon Mar 21 08:08:10 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Mon, 21 Mar 2022 08:08:10 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port Message-ID: This PR implements JEP 422: Linux/RISC-V Port [1]. The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. [1] https://openjdk.java.net/jeps/422 ------------- Commit messages: - 8276799: Implementation of JEP 422: Linux/RISC-V Port Changes: https://git.openjdk.java.net/jdk/pull/6294/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276799 Stats: 59153 lines in 188 files changed: 59002 ins; 54 del; 97 mod Patch: https://git.openjdk.java.net/jdk/pull/6294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294 PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Mon Mar 21 08:08:11 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Mon, 21 Mar 2022 08:08:11 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. > > [1] https://openjdk.java.net/jeps/422 Rebased to master keep alive ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From aturbanov at openjdk.java.net Mon Mar 21 09:02:17 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 21 Mar 2022 09:02:17 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v2] In-Reply-To: References: Message-ID: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com> > Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo Apply suggestion Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7879/files - new: https://git.openjdk.java.net/jdk/pull/7879/files/d93dde25..4c1e68ed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From volker.simonis at gmail.com Mon Mar 21 11:45:38 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 21 Mar 2022 12:45:38 +0100 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: Message-ID: Ping... On Thu, Mar 10, 2022 at 8:26 PM Lance Andersen wrote: > Hi Volker, > > Thank you for the reminder > > This is on my radar as well but have not had a chance spend any time on > this as yet. > > > > On Mar 9, 2022, at 2:33 PM, Volker Simonis > wrote: > > @Alan, @Lance, > > Sorry for my obtrusiveness, but what's your opinion on this issue? > > Thank you and best regards, > Volker > > On Fri, Mar 4, 2022 at 11:04 AM Volker Simonis > wrote: > > > `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater > functionality. `Inflater::inflate(byte[] output, int off, int len)` > currently calls zlib's native `inflate(..)` function and passes the > address of `output[off]` and `len` to it via JNI. > > The specification of zlib's `inflate(..)` function (i.e. the [API > documentation in the original zlib > implementation]( > https://urldefense.com/v3/__https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h*L400__;Iw!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0w3u0Q7HA$ > )) > doesn't give any guarantees with regard to usage of the output buffer. > It only states that upon completion the function will return the > number of bytes that have been written (i.e. "inflated") into the > output buffer. > > The original zlib implementation only wrote as many bytes into the > output buffer as it inflated. However, this is not a hard requirement > and newer, more performant implementations of the zlib library like > [zlib-chromium]( > https://urldefense.com/v3/__https://chromium.googlesource.com/chromium/src/third_party/zlib/__;!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0yNMBtuew$ > ) > or [zlib-cloudflare]( > https://urldefense.com/v3/__https://github.com/cloudflare/zlib__;!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0y7Uhi8nA$ > ) can use more > bytes of the output buffer than they actually inflate as a scratch > buffer. See > https://urldefense.com/v3/__https://github.com/simonis/zlib-chromium__;!!ACWV5N9M2RV99hQ!fpVcYO7aobaYs-KfF-KOOiQtV17pdX5BNzn8ZkU0UX9B2Lj2Pcs1uh4mh0z1qVlYPg$ > for a more > detailed description of their approach and its performance benefit. > > These new zlib versions can still be used transparently from Java > (e.g. by putting them into the `LD_LIBRARY_PATH` or by using > `LD_PRELOAD`), because they still fully comply to specification of > `Inflater::inflate(..)`. However, we might run into problems when > using the `Inflater` functionality from the `InflaterInputStream` > class. `InflaterInputStream` is derived from from `InputStream` and as > such, its `read(byte[] b, int off, int len)` method is quite > constrained. It specifically specifies that if *k* bytes have been > read, then "these bytes will be stored in elements `b[off]` through > `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through > `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] > b, int off, int len)` (which is constrained by > `InputStream::read(..)`'s specification) calls > `Inflater::inflate(byte[] b, int off, int len)` and directly passes > its output buffer down to the native zlib `inflate(..)` method which > is free to change the bytes beyond `b[off+`*k*`]` (where *k* is the > number of inflated bytes). > > From a practical point of view, I don't see this as a big problem, > because callers of `InflaterInputStream::read(byte[] b, int off, int > len)` can never know how many bytes will be written into the output > buffer `b` (and in fact its content can always be completely > overwritten). It therefore makes no sense to depend on any data there > being untouched after the call. Also, having used zlib-cloudflare > productively for about two years, we haven't seen real-world issues > because of this behavior yet. However, from a specification point of > view it is easy to artificially construct a program which violates > `InflaterInputStream::read(..)`'s postcondition if using one of the > alterantive zlib implementations. A recently integrated JTreg test > (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" > fails with zlib-chromium but could be easily fixed to run with > alternative implementations as well. > > What should/can be done to solve this problem? I think we have three > options: > > 1. Relax the specification of `InflaterInputStream::read(..)` and > specifically note in the API documentation that a call to > `InflaterInputStream::read(byte[] b, int off, int len)` may write more > than *k* characters into `b` where *k* is the returned number of > inflated bytes. Notice that there's a precedence for this approach in > `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden > method of InputStream, returns -1 instead of zero if the end of the > stream has been reached and len==0*". > > 2. Tighten the specification of `Inflater::read(byte[] b, int off, int > len)` to explicitly forbid any writes into the output array `b` beyond > the inflated bytes. > > 3. Change the implementation of `InflaterInputStream::read(..)` to > call `Inflater::read(..)` with a temporary buffer and only copy the > nu,ber of inflated bytes into `InflaterInputStream::read(..)`'s output > buffer. I think we all agree that this is only a theoretic option > because of its unacceptable performance regression. > > I personally favor option 1 but I'm interested in your opinions? > > Thank you and best regards, > Volker > > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From jlaskey at openjdk.java.net Mon Mar 21 12:36:32 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 21 Mar 2022 12:36:32 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v10] In-Reply-To: References: <94AA8YHplB54wErPGAn65vhQCX-Hqcc6VxrfXGEbDDo=.a39c4bbf-08a5-40ed-8966-841e7a347bdc@github.com> Message-ID: <6ruqdnjluSgBGyOJ2sgMANCLK87DzoGzzmAi_Cknse0=.bcc3e854-6999-403e-88b6-5a1833a2e02a@github.com> On Mon, 21 Mar 2022 07:29:21 GMT, ExE Boss wrote: >> The package is java.lang.runtime not java.lang.invoke so both fields are not accessible. > > Well, you?could?use `SharedSecrets.getJavaLangInvokeAccess().findStatic(?)` and?`SharedSecrets.getJavaLangInvokeAccess().findVirtual(?)` in?place of?`LOOKUP.findStatic(?)` and?`LOOKUP.findVirtual(?)`. Trusted access is not needed, but I can get rid of the LOOKUP static final. The UNSAFE static final is trickier since it might impact the performance of the array getInt. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From aivanov at openjdk.java.net Mon Mar 21 13:23:30 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 21 Mar 2022 13:23:30 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v2] In-Reply-To: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com> References: <1aOenacSYTb23hOLJFJBdM_k6vXL8gl5qxTn0RrocoA=.a0d88289-1e12-45f9-88ec-27981f9a0f74@github.com> Message-ID: On Mon, 21 Mar 2022 09:02:17 GMT, Andrey Turbanov wrote: >> Fix repeated typo `exeption` > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8283426: Fix 'exeption' typo > > Apply suggestion > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From ihse at openjdk.java.net Mon Mar 21 13:41:40 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 13:41:40 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v10] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix fontconfig according to review request ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/b1d1e4d8..5a75e7d1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=08-09 Stats: 26 lines in 5 files changed: 10 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Mar 21 13:46:27 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 13:46:27 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v11] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge tag 'jdk-19+14' into shuffle-data Added tag jdk-19+14 for changeset 08cadb47 - Move x11wrappergen from share/data to unix/data - Fix fontconfig according to review request - Fix typos - Restore charsetmapping and cldr to make/data - Update copyright year - Merge branch 'master' into shuffle-data-reborn - Fix merge - Merge tag 'jdk-19+13' into shuffle-data-reborn Added tag jdk-19+13 for changeset 5df2a057 - Move characterdata templates to share/classes/java/lang. - ... and 8 more: https://git.openjdk.java.net/jdk/compare/08cadb47...ea17b206 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10 Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From sgehwolf at openjdk.java.net Mon Mar 21 14:00:36 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Mon, 21 Mar 2022 14:00:36 GMT Subject: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 13:40:53 GMT, Severin Gehwolf wrote: > Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap limits. In such a case a passing test tells us nothing. Certainly not if the > fix from [JDK-8242480](https://bugs.openjdk.java.net/browse/JDK-8242480) is present or not. > > Testing: > - [x] Manual with and without the code fix of JDK-8242480. Still passes with the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. @DamonFool Do you think you can have a look at this? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7854 From ihse at openjdk.java.net Mon Mar 21 14:15:36 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 14:15:36 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos > > This doesn't seem right to me to put x11wrappergen into share. > > This is X11 specific. It should not be in share. > > Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories. @prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`. (Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.) ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From jlaskey at openjdk.java.net Mon Mar 21 14:24:30 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 21 Mar 2022 14:24:30 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. 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 18 additional commits since the last revision: - Remove LOOKUP static final - Merge branch 'master' into 8282798 - Typos - Update Carrier.java - Redo API to use list, bring Carrier.component back - Clean up API - Remove redundant MethodHandle component(MethodType methodType, int i) API - Revert to {@return} style comments. - Clarify primitive store in array carriers. - Use long array for primitives - ... and 8 more: https://git.openjdk.java.net/jdk/compare/ffc8a484...a8657bbe ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/a82bfd64..a8657bbe Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=09-10 Stats: 9833 lines in 495 files changed: 4777 ins; 2492 del; 2564 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From ihse at openjdk.java.net Mon Mar 21 14:43:33 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 14:43:33 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port In-Reply-To: References: Message-ID: On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. > > [1] https://openjdk.java.net/jeps/422 Build changes look good. I can't say anything about the rest of the code. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6294 From naoto at openjdk.java.net Mon Mar 21 15:36:41 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 21 Mar 2022 15:36:41 GMT Subject: Integrated: 8283277: ISO 4217 Amendment 171 Update In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 18:10:17 GMT, Naoto Sato wrote: > This is to incorporate the ISO 4217 amendment 171 for Sierra Leonean LEONE redenomination (removing 3 zeros). Its effective date is 4/1, but I went ahead as JDK19 won't be released by 4/1. This pull request has now been integrated. Changeset: c4dc58e1 Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c4dc58e12e197562dce90c0027aa74c29047cea6 Stats: 17 lines in 6 files changed: 3 ins; 0 del; 14 mod 8283277: ISO 4217 Amendment 171 Update Reviewed-by: iris, joehw ------------- PR: https://git.openjdk.java.net/jdk/pull/7857 From ihse at openjdk.java.net Mon Mar 21 16:06:35 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 16:06:35 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v12] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Correct name for bfc files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/ea17b206..f66afd1a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From darcy at openjdk.java.net Mon Mar 21 16:24:17 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 21 Mar 2022 16:24:17 GMT Subject: RFR: JDK-8283415: Update java.lang.ref to use sealed classes [v2] In-Reply-To: References: Message-ID: > Another refactoring to use sealed classes where possible, this time in the java.lang.ref package. > > Copyright dates will be updated, if needed, before a push. Joe Darcy 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: - Update copyrights. - Merge branch 'master' into JDK-8283415 - JDK-8283415: Update java.lang.ref to use sealed classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7874/files - new: https://git.openjdk.java.net/jdk/pull/7874/files/8dc83e5f..6382c607 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7874&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7874&range=00-01 Stats: 1302 lines in 71 files changed: 785 ins; 314 del; 203 mod Patch: https://git.openjdk.java.net/jdk/pull/7874.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7874/head:pull/7874 PR: https://git.openjdk.java.net/jdk/pull/7874 From ihse at openjdk.java.net Mon Mar 21 16:29:25 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 16:29:25 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' into shuffle-data - Correct name for bfc files - Merge tag 'jdk-19+14' into shuffle-data Added tag jdk-19+14 for changeset 08cadb47 - Move x11wrappergen from share/data to unix/data - Fix fontconfig according to review request - Fix typos - Restore charsetmapping and cldr to make/data - Update copyright year - Merge branch 'master' into shuffle-data-reborn - Fix merge - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d ------------- Changes: https://git.openjdk.java.net/jdk/pull/1611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12 Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From mcimadamore at openjdk.java.net Mon Mar 21 16:36:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 16:36:42 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) Message-ID: This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. [1] - https://openjdk.java.net/jeps/424 ------------- Commit messages: - Fix TestLayouts on 32-bits - Update copyright - Drop unused imports in Reflection.java - Fix writeOversized for booleans - Revert changes to scopedMemoryAccess.cpp - Add TestUpcallStack to problem list - Revert changes to problem list - Revert to previous handshake logic - Initial push Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282191 Stats: 66428 lines in 364 files changed: 44012 ins; 19911 del; 2505 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From jboes at openjdk.java.net Mon Mar 21 16:36:45 2022 From: jboes at openjdk.java.net (Julia Boes) Date: Mon, 21 Mar 2022 16:36:45 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: <1c6iI0BzRJEWKr5IDBEaZfw6CyXoJw1N5G54lDjpGYc=.52e24356-0cf0-4939-8a7f-776800511b51@github.com> On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600: > 598: * @param elementLayout the source element layout. If the byte order associated with the layout is > 599: * different from the native order, a byte swap operation will be performed on each array element. > 600: * @return a fresh short array copy of this memory segment. Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods? src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 600: > 598: * @param elementLayout the source element layout. If the byte order associated with the layout is > 599: * different from the native order, a byte swap operation will be performed on each array element. > 600: * @return a fresh short array copy of this memory segment. Maybe use "new" instead of "fresh" here and in the other MemorySegment::toArray methods? src/java.base/share/classes/java/lang/foreign/package-info.java line 149: > 147: * provided: > 148: * > 149: * {@snippet lang=java : missing leading space in comment on line 150 and 162 src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986: > 7984: *

    > 7985: * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values > 7986: * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type ... are the return *types* ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7986: > 7984: *

    > 7985: * When calling e.g. {@link VarHandle#get(Object...)} on the resulting var handle, the incoming coordinate values > 7986: * starting at position {@code pos} (of type {@code C1, C2 ... Cn}, where {@code C1, C2 ... Cn} are the return type ... are the return *types* ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035: > 8033: * @param pos the position of the first coordinate to be inserted > 8034: * @param values the series of bound coordinates to insert > 8035: * @return an adapter var handle which inserts an additional coordinates, ... which inserts additional coordinates, ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8035: > 8033: * @param pos the position of the first coordinate to be inserted > 8034: * @param values the series of bound coordinates to insert > 8035: * @return an adapter var handle which inserts an additional coordinates, ... which inserts additional coordinates, ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151: > 8149: * > 8150: * @param target the var handle to invoke after the dummy coordinates are dropped > 8151: * @param pos position of first coordinate to drop (zero for the leftmost) ... of *the* first coordinate to drop ... src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 8151: > 8149: * > 8150: * @param target the var handle to invoke after the dummy coordinates are dropped > 8151: * @param pos position of first coordinate to drop (zero for the leftmost) ... of *the* first coordinate to drop ... ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon Mar 21 16:36:42 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 16:36:42 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Here is a list of the main changes in this iteration. #### java.lang.foreign The API is now a **preview** API in `java.lang.foreign`. As such to be able to use the API, users must pass the `--enable-preview` flag accordingly, to `javac` and `java`. Since the API now lives in `java.base`, we dropped the `MemoryHandles` class and moved all its var handle combinator methods under `MethodHandles`. We have also dropped the `MemorySegment::map` factory and replaced it with a new overload in `FileChannel`, which plays much better with custom file systems. #### ResourceScope The `ResourceScope` abstraction has been renamed to `MemorySession`. Aside from the naming difference (which also is reflected in some of the factories associated with `MemorySession`, another difference are that `MemorySession` now implements `SegmentAllocator` and can be used straight away to allocate segments. Finally, the fact that some sessions are not closeable is now reflected in the API (see `MemorySession::isCloseable`), and a method has been added to create a non-closeable *view* of the memory session. #### Restricted methods Addressing the feedback we have received during incubation, the mechanism to control access to restricted methods is now more permissive. Users can still use the `--enable-native-access` flag, to get a strict, opt-in behavior, in case they want to control which modules can access restricted methods in the foreign API. But if no flag is specified, access is allowed, with a runtime warning. Supporting this required some changes in `ModuleBootstrap` so that we could record the fact that we have seen an `--enable-native-access` flag (so that all checks in `Reflection.java` becomes constant). #### Deterministic library loading/unloading We have enhanced the `SymbolLookup` abstraction to provide a new symbol lookup, called *library lookup*. A library lookup is a symbol lookup built around a specific native library which is loaded/unloaded using dlopen/LoadLibrary. Library lookups are associated with memory sessions, so the library can be unloaded deterministically when the session is closed. #### Memory layouts All memory layout constants feature the expected alignment constraints. For instance, `JAVA_CHAR` is 2 byte aligned, `JAVA_INT` is 4 byte aligned, and so on. #### Removed functionalities As we moved the API in `java.base` we have dropped a number of API points which did not seem to add much value, based on the feedback received: * `SequenceLayout`s now always have a bounded size. As a result, `MemoryLayout::byteSize` no longer returns an optional. A zero-length sequence can be used instead; * `NativeSymbol` has been dropped. At the end of the day, its role is undistinguishable from that of a memory segment with zero-length, so API (and users) should use zero-length segments instead; * `MemorySession::keepAlive` - has been removed; in its place we have a simple, high-order method which executes an action (a `Runnable`) while keeping the session alive (`MemorySession::whileAlive`); * `MemoryLayout::map` only provides limited capabilities when rewriting layouts (e.g. it can only replace one layout at a time); as such we removed this API, and we might add something better at a later point. #### Hotspot changes While the Panama foreign repo contains several Hotspot changes which simplify and regularize the foreign function support, these changes are not included here, as we have discovered some intermittent instability in macosx-aarch64. We might attempt to integrate the hotspot changes at a later date. Javadoc: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/javadoc/java.base/module-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/8282191/v1/specdiff_out/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From darcy at openjdk.java.net Mon Mar 21 17:00:35 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Mon, 21 Mar 2022 17:00:35 GMT Subject: Integrated: JDK-8283415: Update java.lang.ref to use sealed classes In-Reply-To: References: Message-ID: On Sat, 19 Mar 2022 22:30:13 GMT, Joe Darcy wrote: > Another refactoring to use sealed classes where possible, this time in the java.lang.ref package. > > Copyright dates will be updated, if needed, before a push. This pull request has now been integrated. Changeset: 14b9e80b Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/14b9e80b8adcc0ab0634357f5a7c25f24fd6808c Stats: 11 lines in 5 files changed: 1 ins; 0 del; 10 mod 8283415: Update java.lang.ref to use sealed classes Reviewed-by: kbarrett, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7874 From erikj at openjdk.java.net Mon Mar 21 17:07:40 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Mar 2022 17:07:40 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into shuffle-data > - Correct name for bfc files > - Merge tag 'jdk-19+14' into shuffle-data > > Added tag jdk-19+14 for changeset 08cadb47 > - Move x11wrappergen from share/data to unix/data > - Fix fontconfig according to review request > - Fix typos > - Restore charsetmapping and cldr to make/data > - Update copyright year > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d OS specific X11 and fontconfig looks good. make/modules/java.desktop/gendata/GendataFontConfig.gmk line 57: > 55: TARGETS += $(FONTCONFIG_OUT_BIN_FILE) > 56: > 57: endif It says no newline at end of file, maybe add that if it's true. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From erikj at openjdk.java.net Mon Mar 21 17:24:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 21 Mar 2022 17:24:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Build changes look ok. make/modules/java.base/Lib.gmk line 217: > 215: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ > 216: LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \ > 217: LIBS := $(LIBCXX) -lc -lm -ldl, \ Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this: LDFLAGS := $(LDFLAGS_JDKLIB), \ LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build. I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Mon Mar 21 17:40:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 17:40:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 17:16:49 GMT, Erik Joelsson wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > make/modules/java.base/Lib.gmk line 217: > >> 215: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ >> 216: LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \ >> 217: LIBS := $(LIBCXX) -lc -lm -ldl, \ > > Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this: > > > LDFLAGS := $(LDFLAGS_JDKLIB), \ > LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ > > > For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build. > > I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time. Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From prr at openjdk.java.net Mon Mar 21 17:57:38 2022 From: prr at openjdk.java.net (Phil Race) Date: Mon, 21 Mar 2022 17:57:38 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v9] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 21:24:43 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix typos > > This doesn't seem right to me to put x11wrappergen into share. > > This is X11 specific. It should not be in share. > > Same for all of the fontconfig files. In make/data it did not seem too weird but it is very weird to put them all in share. If you were to go back and look how it used to be before someone moved them to make I am sure you'd find them in platform specific source directories. > @prrace I have now moved the fontconfig files to `$OS/data`. (I also took the opportunity to clean up the GenData file, which had a quite hairy logic for a trivial task.) I have moved the x11wrappergen files to `unix/data`. > > (Strictly speaking, "unix" and "x11" do not have the same "sense" (in the Fregean meaning), even if it has the same "referent". But we've used that convention before so I'm sticking to it.) Indeed they do not but it is a better approximation than "shared". ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From duke at openjdk.java.net Mon Mar 21 17:59:44 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Mon, 21 Mar 2022 17:59:44 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Sun, 13 Mar 2022 04:27:44 GMT, Jatin Bhateja wrote: >> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 4178: >> >>> 4176: movl(scratch, 1056964608); >>> 4177: movq(xtmp1, scratch); >>> 4178: vbroadcastss(xtmp1, xtmp1, vec_enc); >> >> You could put the constant in the constant table and use `vbroadcastss` here also. >> >> Thank you very much. > > constant and register to register moves are never issued to execution ports, rematerializing value rather than reading from memory will give better performance. I have come across this a little bit. While `movl r, i` may not consume execution ports, `movq x, r` and `vbroadcastss x, x` surely do. This leads to 3 retired and 2 executed uops. Furthermore, both `movq x, r` and `vbroadcastss x, x` can only run on port 5, limit the throughput of the operation. On the contrary, a `vbroadcastss x, m` only results in 1 retired and 1 executed uop, reducing pressure on the decoder and the backend. A `vbroadcastss x, m` can run on both port 2 and port 3, offering a much better throughput. Latency is not much of a concern in this circumstance since the operation does not have any input dependency. > register to register moves are never issued to execution ports I believe you misremembered this part, a register to register move is only elided when the registers are of the same kind, `vmovq x, r` would result in 1 uop being executed on port 5. What do you think? Thank you very much. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Mon Mar 21 18:05:41 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 21 Mar 2022 18:05:41 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: References: Message-ID: <0LSF1Nd2NHRSj9FU6500BRx-mGXLB0N6PNYknvwaIeQ=.410f4f4f-58f3-4677-8815-19921fa01388@github.com> On Mon, 21 Mar 2022 14:24:30 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > 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 18 additional commits since the last revision: > > - Remove LOOKUP static final > - Merge branch 'master' into 8282798 > - Typos > - Update Carrier.java > - Redo API to use list, bring Carrier.component back > - Clean up API > - Remove redundant MethodHandle component(MethodType methodType, int i) API > - Revert to {@return} style comments. > - Clarify primitive store in array carriers. > - Use long array for primitives > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/7feac45e...a8657bbe src/java.base/share/classes/java/lang/runtime/Carrier.java line 574: > 572: try { > 573: Lookup lookup = MethodHandles.lookup(); > 574: return lookup.defineHiddenClass(bytes, false, ClassOption.STRONG); Actually, this?lookup?object should?probably be?kept?cached. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From mchung at openjdk.java.net Mon Mar 21 18:20:27 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Mar 2022 18:20:27 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: <6QxgD_j4URvME87pOMWMjtrcs8OWSCWlsHpmw2Bl1cg=.a4543478-ce6d-4755-9061-ffbcfa3f5c49@github.com> References: <6QxgD_j4URvME87pOMWMjtrcs8OWSCWlsHpmw2Bl1cg=.a4543478-ce6d-4755-9061-ffbcfa3f5c49@github.com> Message-ID: <-CRT3ySEJaBn5aRjBw_52qCMhbwXg7PPV3FzPXXDF2o=.47b6ce89-2ff1-4274-9eb0-a5967ea5ae9a@github.com> On Mon, 21 Mar 2022 06:08:32 GMT, Athijegannathan Sundararajan wrote: > $ javac com/acme/*.java > > is fine. Am I missing something? If you make P.Q private, it will fail the compilation. To make `DelegatingMethodHandle` a sealed class, we could make `AsVarargsCollector` and `WrappedMember` package-private classes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From jbhateja at openjdk.java.net Mon Mar 21 18:28:34 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Mon, 21 Mar 2022 18:28:34 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 17:56:22 GMT, Quan Anh Mai wrote: >> constant and register to register moves are never issued to execution ports, rematerializing value rather than reading from memory will give better performance. > > I have come across this a little bit. While `movl r, i` may not consume execution ports, `movq x, r` and `vbroadcastss x, x` surely do. This leads to 3 retired and 2 executed uops. Furthermore, both `movq x, r` and `vbroadcastss x, x` can only run on port 5, limit the throughput of the operation. On the contrary, a `vbroadcastss x, m` only results in 1 retired and 1 executed uop, reducing pressure on the decoder and the backend. A `vbroadcastss x, m` can run on both port 2 and port 3, offering a much better throughput. Latency is not much of a concern in this circumstance since the operation does not have any input dependency. > >> register to register moves are never issued to execution ports > > I believe you misremembered this part, a register to register move is only elided when the registers are of the same kind, `vmovq x, r` would result in 1 uop being executed on port 5. > > What do you think? Thank you very much. A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache. Change was done for replace vpbroadcastd with vbroadcastss because of two reasons. 1) vbroadcastss works at AVX=1 level where as vpbroadcastd need AVX2 feature. 2) We can avoid extra cycle penalty due to two domain switchovers (FP -> INT and then from INT-> FP). ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From jjg at openjdk.java.net Mon Mar 21 19:00:36 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Mon, 21 Mar 2022 19:00:36 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into shuffle-data > - Correct name for bfc files > - Merge tag 'jdk-19+14' into shuffle-data > > Added tag jdk-19+14 for changeset 08cadb47 > - Move x11wrappergen from share/data to unix/data > - Fix fontconfig according to review request > - Fix typos > - Restore charsetmapping and cldr to make/data > - Update copyright year > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d As before, the changes for `jdk.compiler` and `idk.javadoc` look OK, and if there is general consensus on the overall proposed move, then I think that overall it is a good idea. I did not review the `jdk.compiler` in low-level detail, but scanning the webrev index file, the changes seemed OK, and a pure move (no lines changed.) It might have been better to have handled this on a per-module basis, rather than all-at-once, but whatever ... ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From Alan.Bateman at oracle.com Mon Mar 21 19:19:30 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Mar 2022 19:19:30 +0000 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: Message-ID: <3e79090c-906e-6e89-31fa-9258cfdf830b@oracle.com> On 04/03/2022 10:04, Volker Simonis wrote: > : > > 1. Relax the specification of `InflaterInputStream::read(..)` and > specifically note in the API documentation that a call to > `InflaterInputStream::read(byte[] b, int off, int len)` may write more > than *k* characters into `b` where *k* is the returned number of > inflated bytes. Notice that there's a precedence for this approach in > `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden > method of InputStream, returns -1 instead of zero if the end of the > stream has been reached and len==0*". > On the surface this is probably okay. It wouldn't really be relaxing the specification, rather than it would say for a return value n, the bytes in b[n] to b[len-1] are undefined as the read operate may have clobbered their original values. The risk is that it becomes a performance "trick" to provide a larger buffer. That said, I think the main thing we need to satisfy ourselves on is security. One part of that is whether anything can be gleaned by reading from the byte array during or after an inflate. The other part is how the implementation behaves when there is a tampering of the array contents during an inflate. -Alan From lance.andersen at oracle.com Mon Mar 21 19:23:51 2022 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 21 Mar 2022 19:23:51 +0000 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: Message-ID: <6AFC33D6-63CA-4C2E-8422-1E70EDB0CAA8@oracle.com> Hi Volker, I have read through what you have provided/pointed to, thank you, and on the surface what you are suggesting sounds reasonable. That being said given that this API dates back to 1997ish, I think we have to be careful not introduce any regressions with existing applications with the proposal you suggest(even though it is just relaxes the spec), as you mentioned their is a jtreg test that seems to fail. Have you run the JCK with your ZLIB implementation? I only skimmed the tests but looks like there might be a couple of tests which validate the array?s contents. We don?t have a lot of test coverage so if we were to consider moving forward with your proposal, I believe additional test coverage would be warranted. Best Lance On Mar 4, 2022, at 5:04 AM, Volker Simonis > wrote: `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*k*`]` (where *k* is the number of inflated bytes). From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but could be easily fixed to run with alternative implementations as well. What should/can be done to solve this problem? I think we have three options: 1. Relax the specification of `InflaterInputStream::read(..)` and specifically note in the API documentation that a call to `InflaterInputStream::read(byte[] b, int off, int len)` may write more than *k* characters into `b` where *k* is the returned number of inflated bytes. Notice that there's a precedence for this approach in `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden method of InputStream, returns -1 instead of zero if the end of the stream has been reached and len==0*". 2. Tighten the specification of `Inflater::read(byte[] b, int off, int len)` to explicitly forbid any writes into the output array `b` beyond the inflated bytes. 3. Change the implementation of `InflaterInputStream::read(..)` to call `Inflater::read(..)` with a temporary buffer and only copy the nu,ber of inflated bytes into `InflaterInputStream::read(..)`'s output buffer. I think we all agree that this is only a theoretic option because of its unacceptable performance regression. I personally favor option 1 but I'm interested in your opinions? Thank you and best regards, Volker [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jvernee at openjdk.java.net Mon Mar 21 19:29:31 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Mon, 21 Mar 2022 19:29:31 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 10:45:27 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 src/java.base/share/classes/java/lang/foreign/CLinker.java line 176: > 174: * @param symbol the address of the target function. > 175: * @param function the function descriptor of the target function. > 176: * @return a new downcall method handle. The method handle type is inferred Maybe drop the "new" from this. Since we want to do caching in the future. Suggestion: * @return a downcall method handle. The method handle type is inferred src/java.base/share/classes/java/lang/foreign/CLinker.java line 199: > 197: * > 198: * @param function the function descriptor of the target function. > 199: * @return a new downcall method handle. The method handle type is inferred Suggestion: * @return a downcall method handle. The method handle type is inferred src/java.base/share/classes/java/lang/foreign/MemoryAddress.java line 159: > 157: * Creates a memory address from the given long value. > 158: * @param value the long value representing a raw address. > 159: * @return a new memory address instance. Similar here. A new address is not always returned. Suggestion: * @return a memory address instance. src/java.base/share/classes/java/lang/foreign/package-info.java line 230: > 228: * where {@code M1}, {@code M2}, {@code ... Mn} are module names (for the unnamed module, the special value {@code ALL-UNNAMED} > 229: * can be used). If this option is specified, access to restricted methods is only granted to the modules listed by that > 230: * option. If this option is not specified, access to restricted method is enabled for all modules, but Suggestion: * option. If this option is not specified, access to restricted methods is enabled for all modules, but src/java.base/share/classes/jdk/internal/foreign/abi/aarch64/CallArranger.java line 53: > (failed to retrieve contents of file, check the PR for context) Keeping this static import would seem more readable here, instead of prefixing everything with `AArch64Architecture.`. (especially in the ABI definition below) src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53: > (failed to retrieve contents of file, check the PR for context) Same here, I think keeping the static import for this would make things more readable. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Mon Mar 21 19:42:33 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Mon, 21 Mar 2022 19:42:33 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v13] In-Reply-To: References: Message-ID: <80sBZo5_9EhVEBljhwN7YRFwROLhSnYgNPH1Qg2tMOk=.061730ba-b085-4109-b5c9-ddbf0397301f@github.com> On Mon, 21 Mar 2022 16:29:25 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) >> >> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [x] java.base >> - [x] java.desktop >> - [x] jdk.compiler >> - [x] java.se > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' into shuffle-data > - Correct name for bfc files > - Merge tag 'jdk-19+14' into shuffle-data > > Added tag jdk-19+14 for changeset 08cadb47 > - Move x11wrappergen from share/data to unix/data > - Fix fontconfig according to review request > - Fix typos > - Restore charsetmapping and cldr to make/data > - Update copyright year > - Merge branch 'master' into shuffle-data-reborn > - Fix merge > - ... and 10 more: https://git.openjdk.java.net/jdk/compare/19d34bdf...1c47d82d I reviewed java.base and java.se. I agree that java.se is a better home for jdwp.spec. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611 From mcimadamore at openjdk.java.net Mon Mar 21 21:25:31 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Mon, 21 Mar 2022 21:25:31 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 14:17:21 GMT, Jorn Vernee wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > src/java.base/share/classes/jdk/internal/foreign/abi/x64/sysv/CallArranger.java line 53: > >> (failed to retrieve contents of file, check the PR for context) > Same here, I think keeping the static import for this would make things more readable. Good catch. I think the IDE did that when I moved files across; I've fixed few of these, but there's more it seems. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From ihse at openjdk.java.net Mon Mar 21 21:30:29 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 21:30:29 GMT Subject: RFR: 8257733: Move module-specific data from make to respective module [v14] In-Reply-To: References: Message-ID: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add missing newline at EOF ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1611/files - new: https://git.openjdk.java.net/jdk/pull/1611/files/1c47d82d..8faeff36 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1611&range=12-13 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611 PR: https://git.openjdk.java.net/jdk/pull/1611 From ihse at openjdk.java.net Mon Mar 21 21:39:38 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Mar 2022 21:39:38 GMT Subject: Integrated: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie wrote: > A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) > > These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) > > This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review. > > ### Modules reviewed > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se This pull request has now been integrated. Changeset: f8878cb0 Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/jdk/commit/f8878cb0cc436993ef1222bc13b00b923d91aad1 Stats: 140 lines in 619 files changed: 14 ins; 6 del; 120 mod 8257733: Move module-specific data from make to respective module Reviewed-by: jjg, weijun, naoto, erikj, prr, alanb, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From john.r.rose at oracle.com Mon Mar 21 21:42:45 2022 From: john.r.rose at oracle.com (John Rose) Date: Mon, 21 Mar 2022 14:42:45 -0700 Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: <0LSF1Nd2NHRSj9FU6500BRx-mGXLB0N6PNYknvwaIeQ=.410f4f4f-58f3-4677-8815-19921fa01388@github.com> References: <0LSF1Nd2NHRSj9FU6500BRx-mGXLB0N6PNYknvwaIeQ=.410f4f4f-58f3-4677-8815-19921fa01388@github.com> Message-ID: On 21 Mar 2022, at 11:05, ExE Boss wrote: > Actually, this?lookup?object should?probably be?kept?cached. +1. Good ?cache?. From mandy.chung at oracle.com Mon Mar 21 22:37:15 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 21 Mar 2022 15:37:15 -0700 Subject: Unused paramter 'boolean newln' in java.lang.VersionProps#print(boolean err, boolean newln) In-Reply-To: References: Message-ID: VersionProps::print(boolean err, boolean newln) is called by VersionProps::println(boolean) and VersionProps::print(boolean) which is called from the launcher java -version and -showversion option [1]. Mandy [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1804 On 3/19/22 11:20 AM, Andrey Turbanov wrote: > Hello. > I found a suspicious method java.lang.VersionProps#print with unused > parameter 'boolean newln'. > This class is generated from template - > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/VersionProps.java.template#L203 > It's unused since integration of 'JDK-8169069 Module system > implementation refresh (11/2016)' - > https://github.com/openjdk/jdk/commit/fbe85300bfcc69cb4dd56e4df33ceea632366283 > > > > Andrey Turbanov From darcy at openjdk.java.net Tue Mar 22 00:16:38 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 22 Mar 2022 00:16:38 GMT Subject: RFR: JDK-8283480: Make AbstractStringBuilder sealed Message-ID: As part of updating the core libraries to be sealed, the package-access AbstractStringBuilder, implementation superclass of StringBuilder and StringBuffer, can be marked as sealed with those two subclasses on its permits list. ------------- Commit messages: - Merge branch 'master' into JDK-8283480 - Fix whitespace. - JDK-8283480: Make AbstractStringBuilder sealed Changes: https://git.openjdk.java.net/jdk/pull/7898/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7898&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283480 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7898.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7898/head:pull/7898 PR: https://git.openjdk.java.net/jdk/pull/7898 From jjg at openjdk.java.net Tue Mar 22 00:16:38 2022 From: jjg at openjdk.java.net (Jonathan Gibbons) Date: Tue, 22 Mar 2022 00:16:38 GMT Subject: RFR: JDK-8283480: Make AbstractStringBuilder sealed In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access AbstractStringBuilder, implementation superclass of StringBuilder and StringBuffer, can be marked as sealed with those two subclasses on its permits list. Marked as reviewed by jjg (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7898 From rriggs at openjdk.java.net Tue Mar 22 00:16:38 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Mar 2022 00:16:38 GMT Subject: RFR: JDK-8283480: Make AbstractStringBuilder sealed In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access AbstractStringBuilder, implementation superclass of StringBuilder and StringBuffer, can be marked as sealed with those two subclasses on its permits list. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7898 From jlaskey at openjdk.java.net Tue Mar 22 00:23:26 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 00:23:26 GMT Subject: RFR: JDK-8283480: Make AbstractStringBuilder sealed In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access AbstractStringBuilder, implementation superclass of StringBuilder and StringBuffer, can be marked as sealed with those two subclasses on its permits list. LGTM ------------- Marked as reviewed by jlaskey (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7898 From duke at openjdk.java.net Tue Mar 22 01:58:40 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 22 Mar 2022 01:58:40 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 18:25:36 GMT, Jatin Bhateja wrote: > A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache But your approach comes at a cost of frontend bandwidth and port contention, which imo are more important than latency in this case since a constant load does not prolong dependency chains. A load has very good throughput so it is often performant unless the load depends on its input (the memory location or the registers used for address calculation). Thanks ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From xliu at openjdk.java.net Tue Mar 22 02:47:36 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 22 Mar 2022 02:47:36 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3] In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 08:33:36 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Change growOnly to maybeLatin. > > This patch also copys over the attribute from the other AbstractStringBuilder. > Add a unit test to cover methods which cause maybeLatin1 becomes true. I use **jol** to inspect the layout of StringBulder object. It won't increase object size because the extra boolean is in the alignment gap between coder and value. $java -jar ~/Devel/jol-cli-latest.jar internals java.lang.StringBuilder Instantiated the sample instance via default constructor. java.lang.StringBuilder object internals: OFF SZ TYPE DESCRIPTION VALUE 0 8 (object header: mark) 0x0000000000000001 (non-biasable; age: 0) 8 4 (object header: class) 0x000540e0 12 4 int AbstractStringBuilder.count 0 16 1 byte AbstractStringBuilder.coder 0 17 1 boolean AbstractStringBuilder.maybeLatin1 false 18 2 (alignment/padding gap) 20 4 byte[] AbstractStringBuilder.value [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] Instance size: 24 bytes Space losses: 2 bytes internal + 0 bytes external = 2 bytes total > java -jar ~/Devel/jol-cli-latest.jar estimates java.lang.StringBuilder will iterate different setups of HotSpot. It's still same comparing to the baseline. I don't know a lot about Java Object layout. It looks like Java guarantees reference is 4-bytes alignment. ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From jbhateja at openjdk.java.net Tue Mar 22 02:55:32 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 22 Mar 2022 02:55:32 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 01:55:38 GMT, Quan Anh Mai wrote: >> A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache. Change was done for replace vpbroadcastd with vbroadcastss because of two reasons. >> 1) vbroadcastss works at AVX=1 level where as vpbroadcastd need AVX2 feature. >> 2) We can avoid extra cycle penalty due to two domain switchovers (FP -> INT and then from INT-> FP). > >> A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache > > But your approach comes at a cost of frontend bandwidth and port contention, which imo are more important than latency in this case since a constant load does not prolong dependency chains. A load has very good throughput so it is often performant unless the load depends on its input (the memory location or the registers used for address calculation). Thanks Thanks for going into details, multicycle memory load will also defer dispatch of dependent instructions to execution port, port congestion becomes bottleneck when multiple ready instructions cannot be issued due to lack of execution resource or throughput constraints imposed by instruction, but a single cycle dependency chain may still win over latency due to pending memory operations. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From duke at openjdk.java.net Tue Mar 22 03:17:32 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 22 Mar 2022 03:17:32 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v15] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 02:52:07 GMT, Jatin Bhateja wrote: >>> A read from constant table will incur minimum of L1I access penalty to access code blob or at worst even more if data is not present in first level cache >> >> But your approach comes at a cost of frontend bandwidth and port contention, which imo are more important than latency in this case since a constant load does not prolong dependency chains. A load has very good throughput so it is often performant unless the load depends on its input (the memory location or the registers used for address calculation). Thanks > > Thanks for going into details, multicycle memory load will also defer dispatch of dependent instructions to execution port, port congestion becomes bottleneck when multiple ready instructions cannot be issued due to lack of execution resource or throughput constraints imposed by instruction, but a single cycle dependency chain may still win over latency due to pending memory operations. I think I get it now, thanks a lot for your detailed explanation. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From fyang at openjdk.java.net Tue Mar 22 03:31:16 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Tue, 22 Mar 2022 03:31:16 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2] In-Reply-To: References: Message-ID: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. > > [1] https://openjdk.java.net/jeps/422 Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8276799 - 8276799: Implementation of JEP 422: Linux/RISC-V Port ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6294/files - new: https://git.openjdk.java.net/jdk/pull/6294/files/33402035..a144cd20 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=00-01 Stats: 2517 lines in 698 files changed: 1371 ins; 865 del; 281 mod Patch: https://git.openjdk.java.net/jdk/pull/6294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294 PR: https://git.openjdk.java.net/jdk/pull/6294 From sundar at openjdk.java.net Tue Mar 22 04:03:31 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Tue, 22 Mar 2022 04:03:31 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: <-CRT3ySEJaBn5aRjBw_52qCMhbwXg7PPV3FzPXXDF2o=.47b6ce89-2ff1-4274-9eb0-a5967ea5ae9a@github.com> References: <6QxgD_j4URvME87pOMWMjtrcs8OWSCWlsHpmw2Bl1cg=.a4543478-ce6d-4755-9061-ffbcfa3f5c49@github.com> <-CRT3ySEJaBn5aRjBw_52qCMhbwXg7PPV3FzPXXDF2o=.47b6ce89-2ff1-4274-9eb0-a5967ea5ae9a@github.com> Message-ID: On Mon, 21 Mar 2022 18:17:06 GMT, Mandy Chung wrote: > > $ javac com/acme/*.java > > is fine. Am I missing something? > > If you make P.Q private, it will fail the compilation. > Yes, I got that part. I did make a comment earlier ("Two of those subclasses are nested "private" in another class and hence cannot be referred from DelegatingMethodHandle's permits clause, right?"). My example was in response to "I did try to name the nested type in the permits clause, and it was not accepted by javac." comment by @jddarcy. I wondered if there is any other issue with permits beyond private access of those 2 nested classes. > To make `DelegatingMethodHandle` a sealed class, we could make `AsVarargsCollector` and `WrappedMember` package-private classes. right. ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From jpai at openjdk.java.net Tue Mar 22 04:04:25 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 22 Mar 2022 04:04:25 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2] In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 14:01:50 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 206: >> >>> 204: int max = (int)Math.min(n, Integer.MAX_VALUE); >>> 205: int total = 0; >>> 206: byte[] b = new byte[512]; >> >> n may be less than 512 so maybe the temporary array can be of length Math.min(max, 512). > > That's a good idea. I just pushed a update to this PR with this suggested change. Plus updated the copyright year too. I ran tier1, tier2 and tier3 tests with this change and they completed successfully. Alan, does the current state of the PR look fine to you? Should I go ahead with the merge? ------------- PR: https://git.openjdk.java.net/jdk/pull/7875 From duke at openjdk.java.net Tue Mar 22 04:41:24 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 22 Mar 2022 04:41:24 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. > > Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 **javac** should?be?changed to?allow fully?qualified?access to?private inner?classes in?the?`permits`?clause of?an?enclosing?class. ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From dholmes at openjdk.java.net Tue Mar 22 05:15:35 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Mar 2022 05:15:35 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 03:31:16 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8276799 > - 8276799: Implementation of JEP 422: Linux/RISC-V Port Hi, I've looked at everything that is not a RISC-V specific file, except for the C1 changes as the compiler folk will need to approve those. Some copyrights will need updating to 2022 on the Oracle copyright line please. I have flagged one issue in regard to C++ atomics - see below. Thanks, David make/autoconf/libraries.m4 line 152: > 150: fi > 151: > 152: # Programs which use C11 or C++11 atomics, like #include , Use of C++ atomics is not allowed in hotspot code base. See the style guide: https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md That said, I don't see any actual use of C++ atomics. ?? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6294 From duke at openjdk.java.net Tue Mar 22 05:31:32 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 22 Mar 2022 05:31:32 GMT Subject: RFR: 8280035: Use Class.isInstance instead of Class.isAssignableFrom where applicable In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 12:16:53 GMT, Andrey Turbanov wrote: > Method `isAssignableFrom` is opposite: it brings unnecessary complexity in the code. And it's easy to confuse orders of parameters. Even JBS confirms that: Maybe we?should?add `Class::isSubclassOf(Class?that)` that?performs `that.isAssignableFrom(this)`: ------------- PR: https://git.openjdk.java.net/jdk/pull/7061 From forax at openjdk.java.net Tue Mar 22 06:56:36 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Tue, 22 Mar 2022 06:56:36 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: <7DExBxfS4H8GcTPt6scalCOnk9LZ0iJdop1Bf9Dg7tQ=.a1993e58-b5a7-43fa-a2ee-a211713fdefd@github.com> On Tue, 22 Mar 2022 04:38:15 GMT, ExE Boss wrote: > javac should be changed to allow fully qualified access to private inner classes in the permits clause of an enclosing class. This is not how private works, private means accessible between the '{' and the '}' of the class. The permits clause is declared outside of the '{' and the '}' of the class, thus a private member class is not visible from the permits clause. ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From xliu at openjdk.java.net Tue Mar 22 06:57:29 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 22 Mar 2022 06:57:29 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3] In-Reply-To: References: Message-ID: On Tue, 15 Mar 2022 23:25:17 GMT, Claes Redestad wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Change growOnly to maybeLatin. >> >> This patch also copys over the attribute from the other AbstractStringBuilder. >> Add a unit test to cover methods which cause maybeLatin1 becomes true. > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1008: > >> 1006: this.count = newCount; >> 1007: putStringAt(start, str); >> 1008: if (end - start > 0) { > > regardless of value of `end - start` you could also skip setting `maybeLatin1 = true` if: > - `str.coder() == UTF16` > - `this.coder == LATIN1` hi, @cl4es, you are correct for this and the comment at setCharAt(), but I don't think it's necessary to check all cases. this attribute is just like a hint. if this.coder == LATIN1, that it doesn't matter if maybeLatin1 is true. if our attitude is checking all cases, it will become too complex and error-prone. deleteCharAt() and setLength() also need to check. if so, it will pollute code more. I incline to set this attribute conservatively in all deleting methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From turbanoff at gmail.com Tue Mar 22 07:13:18 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Tue, 22 Mar 2022 10:13:18 +0300 Subject: Unused paramter 'boolean newln' in java.lang.VersionProps#print(boolean err, boolean newln) In-Reply-To: References: Message-ID: I mean _inside method body_ itself.It's only declared, but no code in the method refers to this parameter. Andrey Turbanov ??, 22 ???. 2022 ?. ? 01:37, Mandy Chung : > > VersionProps::print(boolean err, boolean newln) is called by VersionProps::println(boolean) and VersionProps::print(boolean) which is called from the launcher java -version and -showversion option [1]. > > Mandy > [1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1804 > > On 3/19/22 11:20 AM, Andrey Turbanov wrote: > > Hello. > I found a suspicious method java.lang.VersionProps#print with unused > parameter 'boolean newln'. > This class is generated from template - > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/VersionProps.java.template#L203 > It's unused since integration of 'JDK-8169069 Module system > implementation refresh (11/2016)' - > https://github.com/openjdk/jdk/commit/fbe85300bfcc69cb4dd56e4df33ceea632366283 > > > > Andrey Turbanov > > From thartmann at openjdk.java.net Tue Mar 22 07:41:37 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Tue, 22 Mar 2022 07:41:37 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v18] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 20:19:08 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Windows build failure fix. > - 8279508: Styling comments resolved. > - 8279508: Creating separate test for round double under feature check. > - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java. > - 8279508: Review comments resolution. > - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Removing +LogCompilation flag. > - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf Sure, I'll re-run testing and report back. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From xliu at openjdk.java.net Tue Mar 22 08:05:35 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 22 Mar 2022 08:05:35 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v4] In-Reply-To: References: Message-ID: <8JNfO89cFIugnFy-fs_651PCanH8tBkuEV-K6cHKdPk=.df544db7-0595-491e-accc-975188df9c24@github.com> > If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. > toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). > > java.io.BufferedRead::readLine() is a case that StringBuilder grows only. > > In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. > > Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. > > Before: > > $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms > > > After > > $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms Xin Liu 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: - Merge branch 'master' into JDK-8282429 - split StringBuilder.toString() performance test out of StringBuilders.java - Change growOnly to maybeLatin. This patch also copys over the attribute from the other AbstractStringBuilder. Add a unit test to cover methods which cause maybeLatin1 becomes true. - make sure String(StringBuffer) is still synchronized. - Add a microbenchmark. - 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7671/files - new: https://git.openjdk.java.net/jdk/pull/7671/files/415929af..d8acc1f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=02-03 Stats: 25201 lines in 1530 files changed: 15001 ins; 5266 del; 4934 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671 From xgong at openjdk.java.net Tue Mar 22 09:58:23 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 22 Mar 2022 09:58:23 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API [v2] In-Reply-To: References: Message-ID: > The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. > And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. > > To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: > - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. > - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. > > So with this patch, the following transformations are applied: > > For non-masked negation with NEON: > > movi v16.4s, #0x0 > sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s > > and with SVE: > > mov z16.s, #0 > sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s > > For masked negation with NEON: > > movi v17.4s, #0x1 > mvn v19.16b, v18.16b > mov v20.16b, v16.16b ==> neg v18.4s, v17.4s > bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b > add v19.4s, v20.4s, v17.4s > mov v18.16b, v16.16b > bsl v18.16b, v19.16b, v20.16b > > and with SVE: > > mov z16.s, #-1 > mov z17.s, #1 ==> neg z16.s, p0/m, z16.s > eor z18.s, p0/m, z18.s, z16.s > add z18.s, p0/m, z18.s, z17.s > > Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): > > NEON: > Benchmark Gain > Byte128Vector.NEG 1.029 > Byte128Vector.NEGMasked 1.757 > Short128Vector.NEG 1.041 > Short128Vector.NEGMasked 1.659 > Int128Vector.NEG 1.005 > Int128Vector.NEGMasked 1.513 > Long128Vector.NEG 1.003 > Long128Vector.NEGMasked 1.878 > > SVE with 512-bits: > Benchmark Gain > ByteMaxVector.NEG 1.10 > ByteMaxVector.NEGMasked 1.165 > ShortMaxVector.NEG 1.056 > ShortMaxVector.NEGMasked 1.195 > IntMaxVector.NEG 1.002 > IntMaxVector.NEGMasked 1.239 > LongMaxVector.NEG 1.031 > LongMaxVector.NEGMasked 1.191 > > X86 (non AVX-512): > Benchmark Gain > ByteMaxVector.NEGMasked 1.254 > ShortMaxVector.NEGMasked 1.359 > IntMaxVector.NEGMasked 1.431 > LongMaxVector.NEGMasked 1.989 > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Add a superclass for vector negation ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7782/files - new: https://git.openjdk.java.net/jdk/pull/7782/files/828866f8..97c8119a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=00-01 Stats: 64 lines in 4 files changed: 16 ins; 13 del; 35 mod Patch: https://git.openjdk.java.net/jdk/pull/7782.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7782/head:pull/7782 PR: https://git.openjdk.java.net/jdk/pull/7782 From xgong at openjdk.java.net Tue Mar 22 09:58:23 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 22 Mar 2022 09:58:23 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com> Message-ID: On Sat, 19 Mar 2022 03:11:12 GMT, Jie Fu wrote: >>> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: >>> >>> double negate(double arg) {return -0.0 - arg; } >>> >>> This is to handle signed zeros correctly. >> >> Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks! > >> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: >> >> double negate(double arg) {return -0.0 - arg; } >> >> This is to handle signed zeros correctly. > > This seems easy to be broken by an opt enhancement. > Just wondering do we have a jtreg test for this point? @jddarcy > Thanks. Hi @DamonFool , thanks for your review! All the comments have been addressed. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From duke at openjdk.java.net Tue Mar 22 09:59:31 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 22 Mar 2022 09:59:31 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: <2oawkZi1UTfIahjdMwxtpBsYf_6cx9TyHmhyE1rPj6Y=.702729b8-79f0-488d-a8e9-1310c9d635df@github.com> On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. > > Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 But?the?private inner?classes are?visible to?the?compiled `PermittedSubclasses` class?attribute (otherwise it?wouldn?t be?possible for?private inner?classes to?extend a?sealed outer?class with?an?implicit `permits`?clause). --- Technically, `private`?means accessible only?within the?current?nest. ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From mcimadamore at openjdk.java.net Tue Mar 22 10:11:47 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 10:11:47 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v2] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments * Use `new` instead of `fresh` * Drop use of `new` where caching might be used * Remove unused imports * Add static imports to make code more succint * Fix other typos ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/8e6017dc..6bb1b5c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=00-01 Stats: 83 lines in 10 files changed: 2 ins; 7 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From redestad at openjdk.java.net Tue Mar 22 10:12:39 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 22 Mar 2022 10:12:39 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v4] In-Reply-To: <8JNfO89cFIugnFy-fs_651PCanH8tBkuEV-K6cHKdPk=.df544db7-0595-491e-accc-975188df9c24@github.com> References: <8JNfO89cFIugnFy-fs_651PCanH8tBkuEV-K6cHKdPk=.df544db7-0595-491e-accc-975188df9c24@github.com> Message-ID: On Tue, 22 Mar 2022 08:05:35 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > Xin Liu 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: > > - Merge branch 'master' into JDK-8282429 > - split StringBuilder.toString() performance test out of StringBuilders.java > - Change growOnly to maybeLatin. > > This patch also copys over the attribute from the other AbstractStringBuilder. > Add a unit test to cover methods which cause maybeLatin1 becomes true. > - make sure String(StringBuffer) is still synchronized. > - Add a microbenchmark. > - 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings Thanks for refactoring the micro to avoid the redundant run overheads, and checking that the we're size neutral on all configurations. I have added a few minor comments inline that you can choose to address or ignore. Good work! src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 71: > 69: > 70: /** > 71: * The attribute indicates {@code value} is in UTF16 but may be compressible. Since we conservatively set this `true` when deleting anything there are state transitions possible where `maybeLatin1` is set to `true` even though the `coder` is still `LATIN1`. Perhaps clarify that such false positives must be handled gracefully? Since a true doesn't imply UTF16 I also suggest a minor rewording like so: `"Indicates that {@code value} might be compressible to LATIN1 if it's UTF16-encoded."` src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 75: > 73: * Therefore, set this attribute in all methods that delete chars. > 74: */ > 75: boolean maybeLatin1 = false; Could remove `= false` (default value). ------------- Marked as reviewed by redestad (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7671 From redestad at openjdk.java.net Tue Mar 22 10:12:40 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 22 Mar 2022 10:12:40 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v3] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 06:54:35 GMT, Xin Liu wrote: >> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1008: >> >>> 1006: this.count = newCount; >>> 1007: putStringAt(start, str); >>> 1008: if (end - start > 0) { >> >> regardless of value of `end - start` you could also skip setting `maybeLatin1 = true` if: >> - `str.coder() == UTF16` >> - `this.coder == LATIN1` > > hi, @cl4es, > you are correct for this and the comment at setCharAt(), but I don't think it's necessary to check all cases. this attribute is just like a hint. if this.coder == LATIN1, that it doesn't matter if maybeLatin1 is true. > > if our attitude is checking all cases, it will become too complex and error-prone. deleteCharAt() and setLength() also need to check. if so, it will pollute code more. I incline to set this attribute conservatively in all deleting methods. Right, we don't need to check every case and I agree with favoring simplicity at the expense of some false positives. Perhaps the `if (end - start > 0) {` test here isn't pulling its weight either and we should just unconditionally set `maybeLatin1 = true` even if we're not actually replacing anything (which is very much a corner-case). ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From dfuchs at openjdk.java.net Tue Mar 22 10:23:40 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Mar 2022 10:23:40 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: References: Message-ID: <63gmm3PDZZYZjqrRj26oZuy9MbIhomZlkcyzbVcbwNo=.ecf58609-29e9-4461-b5d5-ffe93c05f8f2@github.com> On Mon, 21 Mar 2022 14:24:30 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > 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 18 additional commits since the last revision: > > - Remove LOOKUP static final > - Merge branch 'master' into 8282798 > - Typos > - Update Carrier.java > - Redo API to use list, bring Carrier.component back > - Clean up API > - Remove redundant MethodHandle component(MethodType methodType, int i) API > - Revert to {@return} style comments. > - Clarify primitive store in array carriers. > - Use long array for primitives > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/eace55cb...a8657bbe src/java.base/share/classes/java/lang/runtime/Carrier.java line 166: > 164: from = longIndex++; > 165: filter = DOUBLE_TO_LONG; > 166: } else if(ptype == float.class) { Trivial: space missing after `if` ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From fyang at openjdk.java.net Tue Mar 22 11:50:13 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Tue, 22 Mar 2022 11:50:13 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: References: Message-ID: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. > > [1] https://openjdk.java.net/jeps/422 Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6294/files - new: https://git.openjdk.java.net/jdk/pull/6294/files/a144cd20..b7a31729 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=01-02 Stats: 44 lines in 41 files changed: 0 ins; 1 del; 43 mod Patch: https://git.openjdk.java.net/jdk/pull/6294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294 PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Tue Mar 22 11:50:17 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Tue, 22 Mar 2022 11:50:17 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 03:31:16 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8276799 > - 8276799: Implementation of JEP 422: Linux/RISC-V Port > Build changes look good. I can't say anything about the rest of the code. > > /reviewers 3 Thanks again for looking at the build changes :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Tue Mar 22 11:53:34 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Tue, 22 Mar 2022 11:53:34 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 05:12:46 GMT, David Holmes wrote: > Hi, > > I've looked at everything that is not a RISC-V specific file, except for the C1 changes as the compiler folk will need to approve those. > > Some copyrights will need updating to 2022 on the Oracle copyright line please. Hi David, I have pushed one more commit updating the Oralce copyright line for existing files touched. Thanks for looking at this. ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Tue Mar 22 12:11:36 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Tue, 22 Mar 2022 12:11:36 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 04:13:17 GMT, David Holmes wrote: >> Fei Yang 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 remote-tracking branch 'upstream/master' into JDK-8276799 >> - 8276799: Implementation of JEP 422: Linux/RISC-V Port > > make/autoconf/libraries.m4 line 152: > >> 150: fi >> 151: >> 152: # Programs which use C11 or C++11 atomics, like #include , > > Use of C++ atomics is not allowed in hotspot code base. See the style guide: > https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md > > That said, I don't see any actual use of C++ atomics. ?? I think the old code comment here is a bit too general. It does not mean we introduce any use of C++ atomics here. The fact is that RISC-V only has word-sized atomics, it requries libatomic where other common architectures do not [1]. So atomic support would require explicit linking against -latomic on RISC-V. Otherwise we got build errors like: ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From volker.simonis at gmail.com Tue Mar 22 12:28:27 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Mar 2022 13:28:27 +0100 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: <3e79090c-906e-6e89-31fa-9258cfdf830b@oracle.com> References: <3e79090c-906e-6e89-31fa-9258cfdf830b@oracle.com> Message-ID: On Mon, Mar 21, 2022 at 8:19 PM Alan Bateman wrote: > Hi Alan, Thanks for looking at this issue. Please find my answers to your questions inline: > On 04/03/2022 10:04, Volker Simonis wrote: > > : > > > > 1. Relax the specification of `InflaterInputStream::read(..)` and > > specifically note in the API documentation that a call to > > `InflaterInputStream::read(byte[] b, int off, int len)` may write more > > than *k* characters into `b` where *k* is the returned number of > > inflated bytes. Notice that there's a precedence for this approach in > > `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden > > method of InputStream, returns -1 instead of zero if the end of the > > stream has been reached and len==0*". > > > On the surface this is probably okay. It wouldn't really be relaxing the > specification, rather than it would say for a return value n, the bytes > in b[n] to b[len-1] are undefined as the read operate may have clobbered > their original values. Yes, that's exactly what I'd like to propose. > The risk is that it becomes a performance "trick" > to provide a larger buffer. A larger buffer is always beneficial because it saves us from multiple native down-calls to zlib's inflate function. That's already true today, with the current implementation, where ideally the whole inflated content fits into the output buffer such that it can be inflated by a single call to inflate(). The issue I'd like to solve here is really a corner case for the case where the size of the inflated content is `m` but the buffer size is `n` with `n < m`. In that case we need `(m + (n-1)) / n)` calls to inflate and if `(m % n) > 0` the last call will write fewer than ?n` content bytes (i.e. `m % n` bytes) to the output buffer. Only during the last call to inflate() some of the remaining bytes in the buffer after the `m % n` content bytes can be clobbered. Calling that out in the specification won't change the performance benefits of a larger output buffer except for the writing of the 16 (i.e. the size of a vector store) very last inflated bytes. This last write could be potentially optimized with a 16-byte vector store instruction if the output buffer was larger than the deflated content `m`. But that's really a corner case because in reality the output buffer is usually smaller than `m` and the size of the inflated content `m` is usually much, much larger than 16 (so optimizing the output of the last 16 bytes won't have any measurable effects). > That said, I think the main thing we need to > satisfy ourselves on is security. One part of that is whether anything > can be gleaned by reading from the byte array during or after an > inflate. I can't see any security risks here. The optimized vector store instructions are only used to copy repeated content from the history buffer (aka "sliding window") to the output (i.e. inflate LZ77 compressed data). So the "clobber" bytes will always only contain bytes which have already been written before. See [1, 2] for details. [1] https://www.zlib.net/manual.html [2] https://www.euccas.me/zlib/#deflate_sliding_window > The other part is how the implementation behaves when there is > a tampering of the array contents during an inflate. I don't really understand this concern? Do you mean what happens if another thread is changing the content of the output buffer during an inflate? I think such a use case has never been well-defined and amending the specification won't change anything for such a situation. As I've explained before, the extra clobber bytes won't contain any data which is required by the inflate algorithm for its correct operation. It just contains some additional data from the LZ77 history buffer which can be safely overwritten. The optimized inflate implementations are actually constantly doing this until they reach the end of the output buffer or the end of the deflated data (see [3] for a simple example). [3] https://github.com/simonis/zlib-chromium#inflater-improvements-in-zlib-chromium > > -Alan If you don't mind I'll send out a pull request with a draft of the amended API-doc and open a CSR for this issue. Thank you and best regards, Volker From dholmes at openjdk.java.net Tue Mar 22 12:58:32 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Mar 2022 12:58:32 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 12:08:01 GMT, Fei Yang wrote: >> make/autoconf/libraries.m4 line 152: >> >>> 150: fi >>> 151: >>> 152: # Programs which use C11 or C++11 atomics, like #include , >> >> Use of C++ atomics is not allowed in hotspot code base. See the style guide: >> https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md >> >> That said, I don't see any actual use of C++ atomics. ?? > > I think the old code comment here is a bit too general. It does not mean we introduce any use of C++ atomics here. > The fact is that RISC-V only has word-sized atomics, it requries libatomic where other common architectures do not [1]. > So atomic support would require explicit linking against -latomic on RISC-V. Otherwise we got build errors like: New comment looks good - thanks for clarifying. ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From dholmes at openjdk.java.net Tue Mar 22 12:58:32 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 22 Mar 2022 12:58:32 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> References: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> Message-ID: On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From jlaskey at openjdk.java.net Tue Mar 22 13:00:14 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 13:00:14 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v12] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Fix spacing on if( ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/a8657bbe..7f8de3b5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Tue Mar 22 13:00:20 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 13:00:20 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 14:24:30 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > 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 18 additional commits since the last revision: > > - Remove LOOKUP static final > - Merge branch 'master' into 8282798 > - Typos > - Update Carrier.java > - Redo API to use list, bring Carrier.component back > - Clean up API > - Remove redundant MethodHandle component(MethodType methodType, int i) API > - Revert to {@return} style comments. > - Clarify primitive store in array carriers. > - Use long array for primitives > - ... and 8 more: https://git.openjdk.java.net/jdk/compare/b726367e...a8657bbe Can I get some CSR reviews - thank you? ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Tue Mar 22 13:00:21 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 13:00:21 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: <63gmm3PDZZYZjqrRj26oZuy9MbIhomZlkcyzbVcbwNo=.ecf58609-29e9-4461-b5d5-ffe93c05f8f2@github.com> References: <63gmm3PDZZYZjqrRj26oZuy9MbIhomZlkcyzbVcbwNo=.ecf58609-29e9-4461-b5d5-ffe93c05f8f2@github.com> Message-ID: On Tue, 22 Mar 2022 10:20:15 GMT, Daniel Fuchs 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 18 additional commits since the last revision: >> >> - Remove LOOKUP static final >> - Merge branch 'master' into 8282798 >> - Typos >> - Update Carrier.java >> - Redo API to use list, bring Carrier.component back >> - Clean up API >> - Remove redundant MethodHandle component(MethodType methodType, int i) API >> - Revert to {@return} style comments. >> - Clarify primitive store in array carriers. >> - Use long array for primitives >> - ... and 8 more: https://git.openjdk.java.net/jdk/compare/b726367e...a8657bbe > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 166: > >> 164: from = longIndex++; >> 165: filter = DOUBLE_TO_LONG; >> 166: } else if(ptype == float.class) { > > Trivial: space missing after `if` Updated ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Tue Mar 22 13:00:22 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 13:00:22 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: <0LSF1Nd2NHRSj9FU6500BRx-mGXLB0N6PNYknvwaIeQ=.410f4f4f-58f3-4677-8815-19921fa01388@github.com> References: <0LSF1Nd2NHRSj9FU6500BRx-mGXLB0N6PNYknvwaIeQ=.410f4f4f-58f3-4677-8815-19921fa01388@github.com> Message-ID: On Mon, 21 Mar 2022 18:02:07 GMT, ExE Boss 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 18 additional commits since the last revision: >> >> - Remove LOOKUP static final >> - Merge branch 'master' into 8282798 >> - Typos >> - Update Carrier.java >> - Redo API to use list, bring Carrier.component back >> - Clean up API >> - Remove redundant MethodHandle component(MethodType methodType, int i) API >> - Revert to {@return} style comments. >> - Clarify primitive store in array carriers. >> - Use long array for primitives >> - ... and 8 more: https://git.openjdk.java.net/jdk/compare/b726367e...a8657bbe > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 574: > >> 572: try { >> 573: Lookup lookup = MethodHandles.lookup(); >> 574: return lookup.defineHiddenClass(bytes, false, ClassOption.STRONG); > > Actually, this?lookup?object should?probably be?kept?cached. Which one, the context lookup or the hidden class lookup? ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From david.holmes at oracle.com Tue Mar 22 13:02:37 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Mar 2022 23:02:37 +1000 Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: <7DExBxfS4H8GcTPt6scalCOnk9LZ0iJdop1Bf9Dg7tQ=.a1993e58-b5a7-43fa-a2ee-a211713fdefd@github.com> References: <7DExBxfS4H8GcTPt6scalCOnk9LZ0iJdop1Bf9Dg7tQ=.a1993e58-b5a7-43fa-a2ee-a211713fdefd@github.com> Message-ID: On 22/03/2022 4:56 pm, R?mi Forax wrote: > On Tue, 22 Mar 2022 04:38:15 GMT, ExE Boss wrote: > >> javac should be changed to allow fully qualified access to private inner classes in the permits clause of an enclosing class. > > This is not how private works, private means accessible between the '{' and the '}' of the class. > The permits clause is declared outside of the '{' and the '}' of the class, thus a private member class is not visible from the permits clause. This seems like an oversight in the Sealed classes specification. It makes perfect sense to have a sealed class that can only be extended by its own nested classes, so you should be able to clearly state that. David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/7881 From dfuchs at openjdk.java.net Tue Mar 22 13:15:34 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 22 Mar 2022 13:15:34 GMT Subject: RFR: JDK-8283480: Make AbstractStringBuilder sealed In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access AbstractStringBuilder, implementation superclass of StringBuilder and StringBuffer, can be marked as sealed with those two subclasses on its permits list. LGTM. The two subclasses are final. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7898 From duke at openjdk.java.net Tue Mar 22 13:35:31 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Mar 2022 13:35:31 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v12] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 13:00:14 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Fix spacing on if( Just curious, when valhalla is out, does the specification of Carrier allow the implementation to move to value classes? ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From duke at openjdk.java.net Tue Mar 22 13:35:31 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Mar 2022 13:35:31 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v11] In-Reply-To: References: <0LSF1Nd2NHRSj9FU6500BRx-mGXLB0N6PNYknvwaIeQ=.410f4f4f-58f3-4677-8815-19921fa01388@github.com> Message-ID: <1A3pHZiPdgjVBA_Nd6SZ24QZRRcvquHc7t1vMoCxnIg=.3337eab4-d7e8-400e-a270-cd30b54e98df@github.com> On Tue, 22 Mar 2022 12:56:02 GMT, Jim Laskey wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 574: >> >>> 572: try { >>> 573: Lookup lookup = MethodHandles.lookup(); >>> 574: return lookup.defineHiddenClass(bytes, false, ClassOption.STRONG); >> >> Actually, this?lookup?object should?probably be?kept?cached. > > Which one, the context lookup or the hidden class lookup? The context lookup used to define the hidden class, not the one returned. Don't know how costly calling the caller sensitive `lookup()` is, if the calls are too expensive then we'd rather cache it in a static final field ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Tue Mar 22 13:37:35 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 13:37:35 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v11] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s 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 15 additional commits since the last revision: - Merge branch 'master' into 8282625 - Merge branch 'master' into 8282625 - Correct indentation - Add unit test for DecimalFormatSymbols.getLocale() - Add comment about DecimalFormatSymbols being mutable objects. - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. - Revert "Drop DecimalFormatSymbols.getLocale change" This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. - Revert "Correct caching test" This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. - Correct caching test - Drop DecimalFormatSymbols.getLocale change - ... and 5 more: https://git.openjdk.java.net/jdk/compare/b8892a70...ffb39f97 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/84fa1fe7..ffb39f97 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=09-10 Stats: 9802 lines in 494 files changed: 4773 ins; 2477 del; 2552 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From jlaskey at openjdk.java.net Tue Mar 22 13:45:20 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 13:45:20 GMT Subject: RFR: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly [v12] In-Reply-To: References: Message-ID: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s 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 16 additional commits since the last revision: - Merge branch 'master' into 8282625 - Merge branch 'master' into 8282625 - Merge branch 'master' into 8282625 - Correct indentation - Add unit test for DecimalFormatSymbols.getLocale() - Add comment about DecimalFormatSymbols being mutable objects. - Revert "Cache DecimalFormatSymbols in DecimalFormatSymbols instead of Formatter. No significant performance degradation." This reverts commit fcbf66a2fe9641d3c3349f12cc7b32d8b84c6f72. - Revert "Drop DecimalFormatSymbols.getLocale change" This reverts commit b93cdb03ec68f24f4b8851c0966bb144c30b5110. - Revert "Correct caching test" This reverts commit bf7975396aaad4ed58d053bde8f54984215eeba5. - Correct caching test - ... and 6 more: https://git.openjdk.java.net/jdk/compare/cfdf1030...38251f9e ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7703/files - new: https://git.openjdk.java.net/jdk/pull/7703/files/ffb39f97..38251f9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7703&range=10-11 Stats: 1783 lines in 672 files changed: 858 ins; 698 del; 227 mod Patch: https://git.openjdk.java.net/jdk/pull/7703.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7703/head:pull/7703 PR: https://git.openjdk.java.net/jdk/pull/7703 From mcimadamore at openjdk.java.net Tue Mar 22 14:04:07 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 14:04:07 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - rename syslookup lib on Windows - Add missing LIBS flag - Simplify syslookup build changes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/6bb1b5c9..4b2760d3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=01-02 Stats: 28 lines in 3 files changed: 1 ins; 23 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue Mar 22 14:04:10 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 14:04:10 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 17:36:53 GMT, Maurizio Cimadamore wrote: >> make/modules/java.base/Lib.gmk line 217: >> >>> 215: CXXFLAGS := $(CXXFLAGS_JDKLIB), \ >>> 216: LDFLAGS := $(LDFLAGS_JDKLIB) -Wl$(COMMA)--no-as-needed, \ >>> 217: LIBS := $(LIBCXX) -lc -lm -ldl, \ >> >> Instead of repeating this whole macro call for both Linux and non Linux, you can use parameters of the form LDFLAGS_linux and LIBS_linux to add the Linux specific flags. Something like this: >> >> >> LDFLAGS := $(LDFLAGS_JDKLIB), \ >> LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ >> >> >> For the NAME field, there is no such support, so the way we usually do that is through a variable and conditionals before the macro call. What's the reason to have a different lib name on Windows? If they were the same, and the source file in windows/native/... had the same name, it would just automatically override in the build. >> >> I realize now that this is just moved code from jdk.incubator.foreign, and this patch is probably big enough as it is so no need to refactor the build logic at the same time. > > Good points - there is really no need AFAIK for the lib name to be different. I'll do few experiments. I've fixed the makefile as you suggested - I agree the result is much simpler. I've tested the changes on mac/linux/win and everything looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From rriggs at openjdk.java.net Tue Mar 22 14:04:34 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 22 Mar 2022 14:04:34 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> References: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> Message-ID: On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments The test/jdk files look ok. (I didn't look at the rest) ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6294 From jlaskey at openjdk.java.net Tue Mar 22 15:35:40 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 22 Mar 2022 15:35:40 GMT Subject: Integrated: JDK-8282625 Formatter caches Locale/DecimalFormatSymbols poorly In-Reply-To: References: Message-ID: <8BfY8fb-MQiDbbVPFHDxmUfCNHiLepzUz1seKxOkIIk=.98715874-1490-44c5-9adf-bb280cf01ac7@github.com> On Fri, 4 Mar 2022 17:54:20 GMT, Jim Laskey wrote: > Several attempts have been made to improve Formatter's numeric performance by caching the current Locale zero. Such fixes, however, ignore the real issue, which is the slowness of fetching DecimalFormatSymbols. By directly caching DecimalFormatSymbols in the Formatter, this enhancement streamlines the process of accessing Locale DecimalFormatSymbols and specifically getZeroDigit(). The result is a general improvement in the performance of numeric formatting. > > > @Benchmark > public void bigDecimalDefaultLocale() { > result = String.format("%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalLocaleAlternate() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > other = String.format(DEFAULT, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void bigDecimalThaiLocale() { > result = String.format(THAI, "%1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f %1$f", X); > } > > @Benchmark > public void integerDefaultLocale() { > result = String.format("%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerLocaleAlternate() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > other = String.format(DEFAULT, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > @Benchmark > public void integerThaiLocale() { > result = String.format(THAI, "%1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d %1$d", x); > } > > > Before: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 75498.923 ? 3686.966 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 39068.721 ? 162.983 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 77256.530 ? 294.743 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 344093.071 ? 6189.002 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165685.488 ? 440.857 ops/s > MyBenchmark.integerThaiLocale thrpt 25 327461.302 ? 1168.243 ops/s > > After: > Benchmark Mode Cnt Score Error Units > MyBenchmark.bigDecimalDefaultLocale thrpt 25 94735.293 ? 674.587 ops/s > MyBenchmark.bigDecimalLocaleAlternate thrpt 25 44215.547 ? 291.664 ops/s > MyBenchmark.bigDecimalThaiLocale thrpt 25 91390.997 ? 658.677 ops/s > MyBenchmark.integerDefaultLocale thrpt 25 363722.977 ? 2864.554 ops/s > MyBenchmark.integerLocaleAlternate thrpt 25 165789.514 ? 779.656 ops/s > MyBenchmark.integerThaiLocale thrpt 25 351400.818 ? 1030.246 ops/s This pull request has now been integrated. Changeset: 557ff4b3 Author: Jim Laskey URL: https://git.openjdk.java.net/jdk/commit/557ff4b3558f95723ebaff680b8524b0cb979559 Stats: 93 lines in 3 files changed: 51 ins; 35 del; 7 mod 8282625: Formatter caches Locale/DecimalFormatSymbols poorly Reviewed-by: naoto, rriggs, jpai ------------- PR: https://git.openjdk.java.net/jdk/pull/7703 From volker.simonis at gmail.com Tue Mar 22 16:28:20 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 22 Mar 2022 17:28:20 +0100 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: <6AFC33D6-63CA-4C2E-8422-1E70EDB0CAA8@oracle.com> References: <6AFC33D6-63CA-4C2E-8422-1E70EDB0CAA8@oracle.com> Message-ID: On Mon, Mar 21, 2022 at 8:24 PM Lance Andersen wrote: Hi Lance, Thanks for looking into this issue. Please find my answers inline: > Hi Volker, > > I have read through what you have provided/pointed to, thank you, and on the surface what you are suggesting sounds reasonable. > > That being said given that this API dates back to 1997ish, I think we have to be careful not introduce any regressions with existing applications with the proposal you suggest(even though it is just relaxes the spec), as you mentioned their is a jtreg test that seems to fail. > > Have you run the JCK with your ZLIB implementation? I only skimmed the tests but looks like there might be a couple of tests which validate the array?s contents. Yes, I did run the JCK tests with the optimized zlib implementations and couldn't find any problems related to this issue. We've also using the optimized version of zlib in production for quite a while without any problems. However, I did found a problem related to a test which was copied from "test/jdk/java/util/zip/DeflateIn_InflateOut.java". That jtreg test was fixed with "8240226: DeflateIn_InflateOut.java test incorrectly assumes size of compressed" [2] in JDK 15 but apparently that fix didn't made it into the JCK version. The test has now been excluded from JCK 17/18. Finally, the currently failing "nio/zipfs/ZipFSOutputStreamTest.java" [3] jtreg test is not failing because it specifically checks that the bytes in the output buffer beyond the last inflated byte remains untouched. It's just because they use a poor, "lazy" method of comparing inflated content to the original content and can easily be fixed. Instead of: ``` while ((numRead = is.read(buf)) != -1) { totalRead += numRead; // verify the content Assert.assertEquals(Arrays.mismatch(buf, chunk), -1, "Unexpected content"); } ``` just use: ``` while ((numRead = is.read(buf)) != -1) { totalRead += numRead; // verify the content Assert.assertEquals(Arrays.mismatch(buf, 0, numRead, chunk, 0, numRead), -1, "Unexpected content"); } ``` [1] https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/DeflateIn_InflateOut.java [2] https://bugs.openjdk.java.net/browse/JDK-8240226 [3] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java > > We don?t have a lot of test coverage so if we were to consider moving forward with your proposal, I believe additional test coverage would be warranted. Sure, I'll be happy to add some more testing. Do you have specific ideas? In fact my suggestion relaxes the specification of read(..) which would be hard to check :) Thank you and best regards, Volker > Best > Lance > > > On Mar 4, 2022, at 5:04 AM, Volker Simonis wrote: > > `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater > functionality. `Inflater::inflate(byte[] output, int off, int len)` > currently calls zlib's native `inflate(..)` function and passes the > address of `output[off]` and `len` to it via JNI. > > The specification of zlib's `inflate(..)` function (i.e. the [API > documentation in the original zlib > implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) > doesn't give any guarantees with regard to usage of the output buffer. > It only states that upon completion the function will return the > number of bytes that have been written (i.e. "inflated") into the > output buffer. > > The original zlib implementation only wrote as many bytes into the > output buffer as it inflated. However, this is not a hard requirement > and newer, more performant implementations of the zlib library like > [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) > or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more > bytes of the output buffer than they actually inflate as a scratch > buffer. See https://github.com/simonis/zlib-chromium for a more > detailed description of their approach and its performance benefit. > > These new zlib versions can still be used transparently from Java > (e.g. by putting them into the `LD_LIBRARY_PATH` or by using > `LD_PRELOAD`), because they still fully comply to specification of > `Inflater::inflate(..)`. However, we might run into problems when > using the `Inflater` functionality from the `InflaterInputStream` > class. `InflaterInputStream` is derived from from `InputStream` and as > such, its `read(byte[] b, int off, int len)` method is quite > constrained. It specifically specifies that if *k* bytes have been > read, then "these bytes will be stored in elements `b[off]` through > `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through > `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] > b, int off, int len)` (which is constrained by > `InputStream::read(..)`'s specification) calls > `Inflater::inflate(byte[] b, int off, int len)` and directly passes > its output buffer down to the native zlib `inflate(..)` method which > is free to change the bytes beyond `b[off+`*k*`]` (where *k* is the > number of inflated bytes). > > From a practical point of view, I don't see this as a big problem, > because callers of `InflaterInputStream::read(byte[] b, int off, int > len)` can never know how many bytes will be written into the output > buffer `b` (and in fact its content can always be completely > overwritten). It therefore makes no sense to depend on any data there > being untouched after the call. Also, having used zlib-cloudflare > productively for about two years, we haven't seen real-world issues > because of this behavior yet. However, from a specification point of > view it is easy to artificially construct a program which violates > `InflaterInputStream::read(..)`'s postcondition if using one of the > alterantive zlib implementations. A recently integrated JTreg test > (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" > fails with zlib-chromium but could be easily fixed to run with > alternative implementations as well. > > What should/can be done to solve this problem? I think we have three options: > > 1. Relax the specification of `InflaterInputStream::read(..)` and > specifically note in the API documentation that a call to > `InflaterInputStream::read(byte[] b, int off, int len)` may write more > than *k* characters into `b` where *k* is the returned number of > inflated bytes. Notice that there's a precedence for this approach in > `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden > method of InputStream, returns -1 instead of zero if the end of the > stream has been reached and len==0*". > > 2. Tighten the specification of `Inflater::read(byte[] b, int off, int > len)` to explicitly forbid any writes into the output array `b` beyond > the inflated bytes. > > 3. Change the implementation of `InflaterInputStream::read(..)` to > call `Inflater::read(..)` with a temporary buffer and only copy the > nu,ber of inflated bytes into `InflaterInputStream::read(..)`'s output > buffer. I think we all agree that this is only a theoretic option > because of its unacceptable performance regression. > > I personally favor option 1 but I'm interested in your opinions? > > Thank you and best regards, > Volker > > > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From darcy at openjdk.java.net Tue Mar 22 16:29:44 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 22 Mar 2022 16:29:44 GMT Subject: Integrated: JDK-8283480: Make AbstractStringBuilder sealed In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 00:01:59 GMT, Joe Darcy wrote: > As part of updating the core libraries to be sealed, the package-access AbstractStringBuilder, implementation superclass of StringBuilder and StringBuffer, can be marked as sealed with those two subclasses on its permits list. This pull request has now been integrated. Changeset: f7d21c35 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/f7d21c3523d87584b62a1143bfe52d067cf77519 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8283480: Make AbstractStringBuilder sealed Reviewed-by: jjg, rriggs, jlaskey, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/7898 From erikj at openjdk.java.net Tue Mar 22 16:58:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Mar 2022 16:58:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v3] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 14:04:07 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: > > - rename syslookup lib on Windows > - Add missing LIBS flag > - Simplify syslookup build changes make/modules/java.base/Lib.gmk line 217: > 215: LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ > 216: LIBS := $(LIBCXX), \ > 217: LIBS_linux := -lc -lm -ldl, \ This looks much better, thanks! Now if you could just fix the indentation of the parameters to 4 spaces, it would be perfect. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From kvn at openjdk.java.net Tue Mar 22 17:07:38 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 22 Mar 2022 17:07:38 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> References: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> Message-ID: On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments I looked on C1/C2 changes and compiler tests. Seems reasonable. But before approval I would need to run changes through our testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From kvn at openjdk.java.net Tue Mar 22 17:37:36 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 22 Mar 2022 17:37:36 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> References: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> Message-ID: On Tue, 22 Mar 2022 11:50:13 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/hotspot/cpu/riscv/disassembler_riscv.hpp line 18: > 16: * > 17: * You should have received a copy of the GNU General Public License version > 18: * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. These 2 lines merged into 1 accidentally causing failure in copyright headers verification. ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From mchung at openjdk.java.net Tue Mar 22 17:55:13 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Mar 2022 17:55:13 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v3] In-Reply-To: References: Message-ID: <6z1ybGQkS4NCQkYwDuZzyPgZM5iCrXEiabwSZfYwfls=.18f4c860-ee3c-41f1-a82d-c41e417ba6b8@github.com> > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: Add exception message ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7766/files - new: https://git.openjdk.java.net/jdk/pull/7766/files/c7224f2f..62f74c70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7766.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7766/head:pull/7766 PR: https://git.openjdk.java.net/jdk/pull/7766 From bchristi at openjdk.java.net Tue Mar 22 18:06:10 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Tue, 22 Mar 2022 18:06:10 GMT Subject: RFR: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar Message-ID: Please review this change to the java/util/prefs/AddNodeChangeListener.jar test. Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh Preferences on each test run, MacOS does not seem to honor this, and still stores prefs in Library/. This test has long suffered intermittent failures. 8255031 added some debugging code; as of that change, the test fails fast as soon as an expected change event is not received. In particular, if the expected event is not received for adding the node, the test exits without removing the node. In this way, on Mac, the node can get "stuck" in the preferences of the machine. Future runs on the machine will already have the node, no node added change event will be generated (because the node was already there), the test will continue to fail without removing the node, etc. This matches observations on some CI machines. This change ensures that: * the test node is not present before the test * the test runs to completion, including removing the test node * the test node is not left behind after the test Thanks. ------------- Commit messages: - Ensure test node does not already exist, and is always removed Changes: https://git.openjdk.java.net/jdk/pull/7908/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7908&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283349 Stats: 70 lines in 1 file changed: 30 ins; 17 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/7908.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7908/head:pull/7908 PR: https://git.openjdk.java.net/jdk/pull/7908 From naoto at openjdk.java.net Tue Mar 22 18:50:13 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 22 Mar 2022 18:50:13 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date Message-ID: Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. ------------- Commit messages: - 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date Changes: https://git.openjdk.java.net/jdk/pull/7909/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7909&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283465 Stats: 125 lines in 3 files changed: 50 ins; 73 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7909.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7909/head:pull/7909 PR: https://git.openjdk.java.net/jdk/pull/7909 From bpb at openjdk.java.net Tue Mar 22 18:56:33 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 22 Mar 2022 18:56:33 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato wrote: > Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7909 From iris at openjdk.java.net Tue Mar 22 19:04:32 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 22 Mar 2022 19:04:32 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato wrote: > Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7909 From mcimadamore at openjdk.java.net Tue Mar 22 19:07:12 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 22 Mar 2022 19:07:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix indentation in Lib.gmk ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/4b2760d3..7ec71f73 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=02-03 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From erikj at openjdk.java.net Tue Mar 22 20:46:31 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Mar 2022 20:46:31 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v4] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 19:07:12 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix indentation in Lib.gmk Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From valeriep at openjdk.java.net Tue Mar 22 21:25:28 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Tue, 22 Mar 2022 21:25:28 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Minor code refactoring ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/c8ae1655..1eb63292 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=05-06 Stats: 20 lines in 1 file changed: 1 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From mchung at openjdk.java.net Tue Mar 22 21:29:34 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Mar 2022 21:29:34 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 22:12:10 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Remove homemade callsite from test This `GenManyIndyCorrectBootstrap.java` test is currently ignored (JDK-8194951). Since this test is not executed and will need to be reworked anyway, I would suggest to leave this test as is and let JDK-8194951 to handle it properly. We should add a comment in JDK-8194951 to describe this change. P.S. Sorry for the late comment as I was on vacation last week. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From lance.andersen at oracle.com Tue Mar 22 21:35:29 2022 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 22 Mar 2022 21:35:29 +0000 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: <6AFC33D6-63CA-4C2E-8422-1E70EDB0CAA8@oracle.com> Message-ID: <0FAB53C7-9C4A-4D81-867E-05C24FFF37BC@oracle.com> On Mar 22, 2022, at 12:28 PM, Volker Simonis > wrote: On Mon, Mar 21, 2022 at 8:24 PM Lance Andersen > wrote: Hi Lance, Thanks for looking into this issue. Please find my answers inline: Hi Volker, I have read through what you have provided/pointed to, thank you, and on the surface what you are suggesting sounds reasonable. That being said given that this API dates back to 1997ish, I think we have to be careful not introduce any regressions with existing applications with the proposal you suggest(even though it is just relaxes the spec), as you mentioned their is a jtreg test that seems to fail. Have you run the JCK with your ZLIB implementation? I only skimmed the tests but looks like there might be a couple of tests which validate the array?s contents. Yes, I did run the JCK tests with the optimized zlib implementations and couldn't find any problems related to this issue. We've also using the optimized version of zlib in production for quite a while without any problems. However, I did found a problem related to a test which was copied from "test/jdk/java/util/zip/DeflateIn_InflateOut.java". That was the test on a quick scan I wondered about actually... That jtreg test was fixed with "8240226: DeflateIn_InflateOut.java test incorrectly assumes size of compressed" [2] in JDK 15 but apparently that fix didn't made it into the JCK version. The test has now been excluded from JCK 17/18. Finally, the currently failing "nio/zipfs/ZipFSOutputStreamTest.java" [3] jtreg test is not failing because it specifically checks that the bytes in the output buffer beyond the last inflated byte remains untouched. It's just because they use a poor, "lazy" method of comparing inflated content to the original content and can easily be fixed. Instead of: ``` while ((numRead = is.read(buf)) != -1) { totalRead += numRead; // verify the content Assert.assertEquals(Arrays.mismatch(buf, chunk), -1, "Unexpected content"); } ``` just use: ``` while ((numRead = is.read(buf)) != -1) { totalRead += numRead; // verify the content Assert.assertEquals(Arrays.mismatch(buf, 0, numRead, chunk, 0, numRead), -1, "Unexpected content"); } ``` Why don?t you generate a PR to fix this separate from the change in spec proposal? [1] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/zip/DeflateIn_InflateOut.java__;!!ACWV5N9M2RV99hQ!d0HFq-TCYrPXsCP8R_ja46jCDmVAXQCpz58ddo4rzXdRdDikJ27vpsKzBuKmMKov2g$ [2] https://bugs.openjdk.java.net/browse/JDK-8240226 [3] https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java__;!!ACWV5N9M2RV99hQ!d0HFq-TCYrPXsCP8R_ja46jCDmVAXQCpz58ddo4rzXdRdDikJ27vpsKzBuJSeRPJgw$ We don?t have a lot of test coverage so if we were to consider moving forward with your proposal, I believe additional test coverage would be warranted. Sure, I'll be happy to add some more testing. Do you have specific ideas? In fact my suggestion relaxes the specification of read(..) which would be hard to check :) Just some general coverage of the API would be great not expecting tests for the relaxed specification I think you are probably at a point where you can craft a draft CSR and PR and we can continue to review and discuss from there Best Lance Thank you and best regards, Volker Best Lance On Mar 4, 2022, at 5:04 AM, Volker Simonis > wrote: `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://urldefense.com/v3/__https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h*L400__;Iw!!ACWV5N9M2RV99hQ!d0HFq-TCYrPXsCP8R_ja46jCDmVAXQCpz58ddo4rzXdRdDikJ27vpsKzBuKV0E1HqA$ )) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://urldefense.com/v3/__https://chromium.googlesource.com/chromium/src/third_party/zlib/__;!!ACWV5N9M2RV99hQ!d0HFq-TCYrPXsCP8R_ja46jCDmVAXQCpz58ddo4rzXdRdDikJ27vpsKzBuJVkxWFew$ ) or [zlib-cloudflare](https://urldefense.com/v3/__https://github.com/cloudflare/zlib__;!!ACWV5N9M2RV99hQ!d0HFq-TCYrPXsCP8R_ja46jCDmVAXQCpz58ddo4rzXdRdDikJ27vpsKzBuIpQS_D6w$ ) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://urldefense.com/v3/__https://github.com/simonis/zlib-chromium__;!!ACWV5N9M2RV99hQ!d0HFq-TCYrPXsCP8R_ja46jCDmVAXQCpz58ddo4rzXdRdDikJ27vpsKzBuKrlfpHiw$ for a more detailed description of their approach and its performance benefit. These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*k*`]` (where *k* is the number of inflated bytes). From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but could be easily fixed to run with alternative implementations as well. What should/can be done to solve this problem? I think we have three options: 1. Relax the specification of `InflaterInputStream::read(..)` and specifically note in the API documentation that a call to `InflaterInputStream::read(byte[] b, int off, int len)` may write more than *k* characters into `b` where *k* is the returned number of inflated bytes. Notice that there's a precedence for this approach in `java.io.ByteArrayInputStream::read(..)` which "*unlike the overridden method of InputStream, returns -1 instead of zero if the end of the stream has been reached and len==0*". 2. Tighten the specification of `Inflater::read(byte[] b, int off, int len)` to explicitly forbid any writes into the output array `b` beyond the inflated bytes. 3. Change the implementation of `InflaterInputStream::read(..)` to call `Inflater::read(..)` with a temporary buffer and only copy the nu,ber of inflated bytes into `InflaterInputStream::read(..)`'s output buffer. I think we all agree that this is only a theoretic option because of its unacceptable performance regression. I personally favor option 1 but I'm interested in your opinions? Thank you and best regards, Volker Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com [cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home] Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From smarks at openjdk.java.net Tue Mar 22 21:46:40 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 22 Mar 2022 21:46:40 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato wrote: > Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. Thanks for doing this! I was going to offer to do this myself but you beat me to it. Rewritten test looks great. src/java.base/share/classes/java/lang/Character.java line 740: > 738: public static final class UnicodeBlock extends Subset { > 739: /** > 740: * 737 - the expected number of entities Just a quibble about this comment... it's probably not worth repeating the actual value. But it probably is worth mentioning that the actual value should (or must) match the number of entries added to the map by constructors called from the static initializers in this class. Whenever aliases or new blocks are added, this number must be adjusted. ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7909 From naoto at openjdk.java.net Tue Mar 22 22:02:23 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 22 Mar 2022 22:02:23 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 21:42:04 GMT, Stuart Marks wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment adjusted per review suggestion > > src/java.base/share/classes/java/lang/Character.java line 740: > >> 738: public static final class UnicodeBlock extends Subset { >> 739: /** >> 740: * 737 - the expected number of entities > > Just a quibble about this comment... it's probably not worth repeating the actual value. But it probably is worth mentioning that the actual value should (or must) match the number of entries added to the map by constructors called from the static initializers in this class. Whenever aliases or new blocks are added, this number must be adjusted. Not a "quibble" at all. In fact, I thought the same just after I submitted the PR that the number in the comment would be easily overlooked and got stale, which would defy this cleanup. Removed the actual number and put some explanation there. ------------- PR: https://git.openjdk.java.net/jdk/pull/7909 From mchung at openjdk.java.net Tue Mar 22 22:01:34 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Mar 2022 22:01:34 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 22:12:10 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Remove homemade callsite from test I created CSR (https://bugs.openjdk.java.net/browse/JDK-8283530). I took the liberty to adjust the CSR to include only the needed information. Since I'm the RE for this CSR (you don't have JBS account), you will need another reviewer for this CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From naoto at openjdk.java.net Tue Mar 22 22:02:22 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 22 Mar 2022 22:02:22 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date [v2] In-Reply-To: References: Message-ID: > Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Comment adjusted per review suggestion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7909/files - new: https://git.openjdk.java.net/jdk/pull/7909/files/7328e1e7..ec77e17d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7909&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7909&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7909.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7909/head:pull/7909 PR: https://git.openjdk.java.net/jdk/pull/7909 From bpb at openjdk.java.net Tue Mar 22 22:22:29 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 22 Mar 2022 22:22:29 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date [v2] In-Reply-To: References: Message-ID: <_amdaFT3AdjVDaWdk2kCwJpIC7kU7iiy_hlF5HetF40=.080394fc-f51e-4808-afe6-c34bc0b40fb0@github.com> On Tue, 22 Mar 2022 22:02:22 GMT, Naoto Sato wrote: >> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment adjusted per review suggestion Added comments look good. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7909 From iris at openjdk.java.net Tue Mar 22 22:22:29 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 22 Mar 2022 22:22:29 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 22:02:22 GMT, Naoto Sato wrote: >> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment adjusted per review suggestion Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7909 From duke at openjdk.java.net Tue Mar 22 22:26:32 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Mar 2022 22:26:32 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 22:12:10 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Remove homemade callsite from test I see a few other constant pool stress tests compile the `java.base` patches, which includes this broken `CallSite` implementation. Should we remove that implementation, or does it not cause compilation failure as is? ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From darcy at openjdk.java.net Tue Mar 22 22:33:27 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 22 Mar 2022 22:33:27 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 21:55:34 GMT, Mandy Chung wrote: > I created CSR (https://bugs.openjdk.java.net/browse/JDK-8283530). I took the liberty to adjust the CSR to include only the needed information. Since I'm the RE for this CSR (you don't have JBS account), you will need another reviewer for this CSR. I've added myself as a reviewer on the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From mchung at openjdk.java.net Tue Mar 22 22:33:28 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 22 Mar 2022 22:33:28 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 22:12:10 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Remove homemade callsite from test Which tests do you see? The following tests are all `@ignored`: test/hotspot/jtreg/vmTestbase/vm/mlvm/meth/stress/gc/createLotsOfMHConsts/Test.java test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/mt/TestDescription.java test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/mh/TestDescription.java test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/incorrectBootstrap/TestDescription.java test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/correctBootstrap/TestDescription.java ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Tue Mar 22 23:18:21 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Mar 2022 23:18:21 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v4] In-Reply-To: References: Message-ID: > Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. liach has updated the pull request incrementally with one additional commit since the last revision: Revert "Remove homemade callsite from test" This reverts commit 1bcd779f677420326bf365c3580ceab5a6b5e3fa. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7840/files - new: https://git.openjdk.java.net/jdk/pull/7840/files/1bcd779f..c0a10f6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7840&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7840&range=02-03 Stats: 119 lines in 3 files changed: 113 ins; 2 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7840.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7840/head:pull/7840 PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Tue Mar 22 23:18:22 2022 From: duke at openjdk.java.net (liach) Date: Tue, 22 Mar 2022 23:18:22 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v3] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 22:12:10 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Remove homemade callsite from test Ah, that's great. Seems all tests that have `@library`... `/vmTestbase/vm/mlvm/patches` are ignored (you missed `test/hotspot/jtreg/vmTestbase/vm/mlvm/cp/stress/classfmt/manyIndyOneCPX`) Safe to revert all the test changes. Now waiting for build again. ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From xliu at openjdk.java.net Wed Mar 23 00:35:14 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 23 Mar 2022 00:35:14 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v5] In-Reply-To: References: Message-ID: > If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. > toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). > > java.io.BufferedRead::readLine() is a case that StringBuilder grows only. > > In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. > > Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. > > Before: > > $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms > > > After > > $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" > > Benchmark (MIXED_SIZE) Mode Cnt Score Error Units > StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op > StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms > StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op > StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms > StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op > StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec > StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec > StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op > StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts > StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms Xin Liu has updated the pull request incrementally with one additional commit since the last revision: rewording the comment of 'maybeLatin1'. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7671/files - new: https://git.openjdk.java.net/jdk/pull/7671/files/d8acc1f0..83c74768 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7671&range=03-04 Stats: 9 lines in 1 file changed: 1 ins; 2 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7671.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7671/head:pull/7671 PR: https://git.openjdk.java.net/jdk/pull/7671 From weijun at openjdk.java.net Wed Mar 23 01:23:33 2022 From: weijun at openjdk.java.net (Weijun Wang) Date: Wed, 23 Mar 2022 01:23:33 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Minor code refactoring Everything looks fine to me. ------------- Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7652 From fyang at openjdk.java.net Wed Mar 23 02:03:26 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Wed, 23 Mar 2022 02:03:26 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4] In-Reply-To: References: Message-ID: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. > > [1] https://openjdk.java.net/jeps/422 Fei Yang has updated the pull request incrementally with one additional commit since the last revision: Fix copyright header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6294/files - new: https://git.openjdk.java.net/jdk/pull/6294/files/b7a31729..d8bef7fa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=02-03 Stats: 28 lines in 13 files changed: 14 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/6294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294 PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Wed Mar 23 02:03:27 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Wed, 23 Mar 2022 02:03:27 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: References: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> Message-ID: On Tue, 22 Mar 2022 14:01:28 GMT, Roger Riggs wrote: > The test/jdk files look ok. (I didn't look at the rest) Thank you for looking at that part. ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Wed Mar 23 02:03:27 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Wed, 23 Mar 2022 02:03:27 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: References: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> Message-ID: On Tue, 22 Mar 2022 17:34:18 GMT, Vladimir Kozlov wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/hotspot/cpu/riscv/disassembler_riscv.hpp line 18: > >> 16: * >> 17: * You should have received a copy of the GNU General Public License version >> 18: * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > > These 2 lines merged into 1 accidentally causing failure in copyright headers verification. > I looked on C1/C2 changes and compiler tests. Seems reasonable. But before approval I would need to run changes through our testing. That's great to hear :-) Thanks for the efforts. ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Wed Mar 23 02:03:28 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Wed, 23 Mar 2022 02:03:28 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v3] In-Reply-To: References: <-oQETK4V8ppli_-iya4r39Y3KnIlgZLQblw4kn5rPBQ=.7a89b832-8b1a-4135-bd4a-a2474d52966e@github.com> Message-ID: <3ImDU5mN1i84E9dzISTXAcGY6JrlzjHUjP7iTaaDgoo=.e1500563-8449-42ac-aa38-964f2995bc3d@github.com> On Wed, 23 Mar 2022 01:57:25 GMT, Fei Yang wrote: >> src/hotspot/cpu/riscv/disassembler_riscv.hpp line 18: >> >>> 16: * >>> 17: * You should have received a copy of the GNU General Public License version >>> 18: * 2 along with this work; if not, write to the Free Software Foundation, * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. >> >> These 2 lines merged into 1 accidentally causing failure in copyright headers verification. > >> I looked on C1/C2 changes and compiler tests. Seems reasonable. But before approval I would need to run changes through our testing. > > That's great to hear :-) Thanks for the efforts. I have fixed the copyright headers verification problem. Please take another look. ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From duke at openjdk.java.net Wed Mar 23 02:10:31 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 23 Mar 2022 02:10:31 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v3] In-Reply-To: <6z1ybGQkS4NCQkYwDuZzyPgZM5iCrXEiabwSZfYwfls=.18f4c860-ee3c-41f1-a82d-c41e417ba6b8@github.com> References: <6z1ybGQkS4NCQkYwDuZzyPgZM5iCrXEiabwSZfYwfls=.18f4c860-ee3c-41f1-a82d-c41e417ba6b8@github.com> Message-ID: <9oTEL6k_kNYvHWMSVoCYi8dMzPm-_MzB58C1AdeRhCI=.e91d4569-c4a3-47fa-9f53-c6963d5068c3@github.com> On Tue, 22 Mar 2022 17:55:13 GMT, Mandy Chung wrote: >> A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > Add exception message This?needs to?use `String.format(?)` in?order to?avoid circular?dependencies in?bootstraps on?`java.lang.invoke.StringConcatFactory`. src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 424: > 422: throw new IncompatibleClassChangeError(msg); > 423: } else { > 424: throw new NullPointerException("Cannot invoke " + member + " with null receiver"); Suggestion: String msg = String.format("Cannot invoke %s with null receiver", member); throw new NullPointerException(msg); src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 456: > 454: throw new IncompatibleClassChangeError(msg); > 455: } else { > 456: throw new NullPointerException("Cannot invoke " + member + " with null receiver"); Suggestion: String msg = String.format("Cannot invoke %s with null receiver", member); throw new NullPointerException(msg); ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From kvn at openjdk.java.net Wed Mar 23 02:20:28 2022 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 23 Mar 2022 02:20:28 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 02:03:26 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright header Update looks good. Testing results are also good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6294 From smarks at openjdk.java.net Wed Mar 23 02:49:35 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 23 Mar 2022 02:49:35 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 22:02:22 GMT, Naoto Sato wrote: >> Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Comment adjusted per review suggestion Marked as reviewed by smarks (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7909 From smarks at openjdk.java.net Wed Mar 23 02:49:36 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 23 Mar 2022 02:49:36 GMT Subject: RFR: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date [v2] In-Reply-To: References: Message-ID: <0ltI4ZnuHK9ktozuhdEOZ2fGOdRQ_ORZ18V3MOeudpE=.b5ee7e6a-38e1-4104-9e4b-15155b77b1db@github.com> On Tue, 22 Mar 2022 21:58:27 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/lang/Character.java line 740: >> >>> 738: public static final class UnicodeBlock extends Subset { >>> 739: /** >>> 740: * 737 - the expected number of entities >> >> Just a quibble about this comment... it's probably not worth repeating the actual value. But it probably is worth mentioning that the actual value should (or must) match the number of entries added to the map by constructors called from the static initializers in this class. Whenever aliases or new blocks are added, this number must be adjusted. > > Not a "quibble" at all. In fact, I thought the same just after I submitted the PR that the number in the comment would be easily overlooked and got stale, which would defy this cleanup. Removed the actual number and put some explanation there. Thanks, looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7909 From jiefu at openjdk.java.net Wed Mar 23 03:09:29 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 23 Mar 2022 03:09:29 GMT Subject: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 13:40:53 GMT, Severin Gehwolf wrote: > Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap limits. In such a case a passing test tells us nothing. Certainly not if the > fix from [JDK-8242480](https://bugs.openjdk.java.net/browse/JDK-8242480) is present or not. > > Testing: > - [x] Manual with and without the code fix of JDK-8242480. Still passes with the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. Please also update the copyright year. Thanks. test/jdk/jdk/internal/platform/docker/GetFreeSwapSpaceSize.java line 28: > 26: > 27: // Usage: > 28: // GetFreeSwapSpaceSize I would suggest // GetFreeSwapSpaceSize test/jdk/jdk/internal/platform/docker/GetFreeSwapSpaceSize.java line 32: > 30: public static void main(String[] args) { > 31: if (args.length != 4) { > 32: throw new RuntimeException("Unexpected arguments. Expected 2, got " + args.length); Shouldn't be `Expected 4` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7854 From mchung at openjdk.java.net Wed Mar 23 03:40:27 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 23 Mar 2022 03:40:27 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v3] In-Reply-To: <9oTEL6k_kNYvHWMSVoCYi8dMzPm-_MzB58C1AdeRhCI=.e91d4569-c4a3-47fa-9f53-c6963d5068c3@github.com> References: <6z1ybGQkS4NCQkYwDuZzyPgZM5iCrXEiabwSZfYwfls=.18f4c860-ee3c-41f1-a82d-c41e417ba6b8@github.com> <9oTEL6k_kNYvHWMSVoCYi8dMzPm-_MzB58C1AdeRhCI=.e91d4569-c4a3-47fa-9f53-c6963d5068c3@github.com> Message-ID: On Wed, 23 Mar 2022 02:01:08 GMT, ExE Boss wrote: >> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: >> >> Add exception message > > src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 424: > >> 422: throw new IncompatibleClassChangeError(msg); >> 423: } else { >> 424: throw new NullPointerException("Cannot invoke " + member + " with null receiver"); > > Suggestion: > > String msg = String.format("Cannot invoke %s with null receiver", > member); > throw new NullPointerException(msg); Good catch. Will update it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From xuelei at openjdk.java.net Wed Mar 23 04:54:26 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 23 Mar 2022 04:54:26 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: Message-ID: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> On Tue, 22 Mar 2022 21:25:28 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Minor code refactoring src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 129: > 127: return currVal; > 128: } > 129: I'm not very sure of this method. Is it performance friendly if making the default key size calculation in the static block (from line 142 to the end of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. Or did I miss something? src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > 135: public static final int DEF_ED_KEY_SIZE; > 136: public static final int DEF_XEC_KEY_SIZE; > 137: private static final AtomicInteger DEF_AES_KEY_SIZE; See the previous comment, maybe it could be `public static final int DEF_AES_KEY_SIZE.` ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From duke at openjdk.java.net Wed Mar 23 06:34:27 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 23 Mar 2022 06:34:27 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v12] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 13:32:18 GMT, liach wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix spacing on if( > > Just curious, when valhalla is out, does the specification of Carrier allow the implementation to move to value classes? @liach > Just curious, when valhalla is out, does the specification of Carrier allow the implementation to move to value classes? If?I?understand correctly, the?answer is?yes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From thartmann at openjdk.java.net Wed Mar 23 06:59:36 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 23 Mar 2022 06:59:36 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v18] In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 20:19:08 GMT, Jatin Bhateja wrote: >> Summary of changes: >> - Intrinsify Math.round(float) and Math.round(double) APIs. >> - Extend auto-vectorizer to infer vector operations on encountering scalar IR nodes for above intrinsics. >> - Test creation using new IR testing framework. >> >> Following are the performance number of a JMH micro included with the patch >> >> Test System: Intel(R) Xeon(R) Platinum 8380 CPU @ 2.30GHz (Icelake Server) >> >> >> Benchmark | TESTSIZE | Baseline AVX3 (ops/ms) | Withopt AVX3 (ops/ms) | Gain ratio | Baseline AVX2 (ops/ms) | Withopt AVX2 (ops/ms) | Gain ratio >> -- | -- | -- | -- | -- | -- | -- | -- >> FpRoundingBenchmark.test_round_double | 1024.00 | 504.15 | 2209.54 | 4.38 | 510.36 | 548.39 | 1.07 >> FpRoundingBenchmark.test_round_double | 2048.00 | 293.64 | 1271.98 | 4.33 | 293.48 | 274.01 | 0.93 >> FpRoundingBenchmark.test_round_float | 1024.00 | 825.99 | 4754.66 | 5.76 | 751.83 | 2274.13 | 3.02 >> FpRoundingBenchmark.test_round_float | 2048.00 | 412.22 | 2490.09 | 6.04 | 388.52 | 1334.18 | 3.43 >> >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Windows build failure fix. > - 8279508: Styling comments resolved. > - 8279508: Creating separate test for round double under feature check. > - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java. > - 8279508: Review comments resolution. > - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating. > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 > - 8279508: Removing +LogCompilation flag. > - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf All tests passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From shade at openjdk.java.net Wed Mar 23 07:27:33 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 23 Mar 2022 07:27:33 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4] In-Reply-To: References: Message-ID: <15WaiDnekvPCVSDawjOcu92JSwMFrdpn-bOEycOwIYc=.a69bf14a-082a-46c5-8a72-56d15c2d4142@github.com> On Wed, 23 Mar 2022 02:03:26 GMT, Fei Yang wrote: >> This PR implements JEP 422: Linux/RISC-V Port [1]. >> The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. >> >> This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. >> >> [1] https://openjdk.java.net/jeps/422 > > Fei Yang has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright header Looks okay to me. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/6294 From aturbanov at openjdk.java.net Wed Mar 23 07:31:23 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 23 Mar 2022 07:31:23 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v3] In-Reply-To: References: Message-ID: > Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo fix more typos, found by Sean Coffey ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7879/files - new: https://git.openjdk.java.net/jdk/pull/7879/files/4c1e68ed..1baca5ea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=01-02 Stats: 14 lines in 7 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From alanb at openjdk.java.net Wed Mar 23 07:32:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 23 Mar 2022 07:32:42 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2] In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 14:05:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? >> >> The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. >> >> tier1, tier2, tier3 tests have been run successfully with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Use Alan's suggestion and allocate less than 512 bytes if possible. Plus copyright year fix. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7875 From sgehwolf at openjdk.java.net Wed Mar 23 09:27:07 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 23 Mar 2022 09:27:07 GMT Subject: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize [v2] In-Reply-To: References: Message-ID: > Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap limits. In such a case a passing test tells us nothing. Certainly not if the > fix from [JDK-8242480](https://bugs.openjdk.java.net/browse/JDK-8242480) is present or not. > > Testing: > - [x] Manual with and without the code fix of JDK-8242480. Still passes with the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. Severin Gehwolf 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: - Incorporate review feedback - Merge branch 'master' into test_getswapspace_improvement_8283279 - 8283279: [Testbug] Improve TestGetSwapSpaceSize ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7854/files - new: https://git.openjdk.java.net/jdk/pull/7854/files/1bbb550a..891c2366 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7854&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7854&range=00-01 Stats: 2978 lines in 116 files changed: 1986 ins; 629 del; 363 mod Patch: https://git.openjdk.java.net/jdk/pull/7854.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7854/head:pull/7854 PR: https://git.openjdk.java.net/jdk/pull/7854 From sgehwolf at openjdk.java.net Wed Mar 23 09:27:09 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 23 Mar 2022 09:27:09 GMT Subject: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize [v2] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 03:06:00 GMT, Jie Fu wrote: >> Severin Gehwolf 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: >> >> - Incorporate review feedback >> - Merge branch 'master' into test_getswapspace_improvement_8283279 >> - 8283279: [Testbug] Improve TestGetSwapSpaceSize > > Please also update the copyright year. > Thanks. Thanks for the review, @DamonFool! Updated the patch. > test/jdk/jdk/internal/platform/docker/GetFreeSwapSpaceSize.java line 28: > >> 26: >> 27: // Usage: >> 28: // GetFreeSwapSpaceSize > > I would suggest > > // GetFreeSwapSpaceSize Thanks, fixed. > test/jdk/jdk/internal/platform/docker/GetFreeSwapSpaceSize.java line 32: > >> 30: public static void main(String[] args) { >> 31: if (args.length != 4) { >> 32: throw new RuntimeException("Unexpected arguments. Expected 2, got " + args.length); > > Shouldn't be `Expected 4` ? Yes. Fixed now. ------------- PR: https://git.openjdk.java.net/jdk/pull/7854 From jpai at openjdk.java.net Wed Mar 23 09:51:31 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Mar 2022 09:51:31 GMT Subject: RFR: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes [v2] In-Reply-To: References: Message-ID: <90ixA_OTWECOGIKj0tpgIuaO9-NbJ7zS-912jpi3qZM=.044f83a6-aef8-48ce-8498-5a5b08583723@github.com> On Sun, 20 Mar 2022 14:05:58 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? >> >> The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. >> >> tier1, tier2, tier3 tests have been run successfully with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Use Alan's suggestion and allocate less than 512 bytes if possible. Plus copyright year fix. Thank you everyone for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/7875 From jpai at openjdk.java.net Wed Mar 23 09:51:32 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 23 Mar 2022 09:51:32 GMT Subject: Integrated: 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes In-Reply-To: References: Message-ID: <6PbhIGW0scEAsKIwKCmF3LuOcIVmKeCjcqR8pKLDnQM=.ef221272-2f0c-44cb-8cb0-8bac3300af56@github.com> On Sun, 20 Mar 2022 04:24:07 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which handles https://bugs.openjdk.java.net/browse/JDK-8283411? > > The commit here moves the temporary byte array from being a member of the class to a local variable within the `skip` method which is the only place where it is used as a temporary buffer. > > tier1, tier2, tier3 tests have been run successfully with this change. This pull request has now been integrated. Changeset: 91fab6ad Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/91fab6ad59d2a4baf58802fc6e6039af3dd8d578 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod 8283411: InflaterInputStream holds on to a temporary byte array of 512 bytes Reviewed-by: lancea, vtewari, alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7875 From aivanov at openjdk.java.net Wed Mar 23 10:15:36 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 23 Mar 2022 10:15:36 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v3] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 07:31:23 GMT, Andrey Turbanov wrote: >> Fix repeated typo `exeption` > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8283426: Fix 'exeption' typo > fix more typos, found by Sean Coffey Marked as reviewed by aivanov (Reviewer). test/jdk/javax/sql/testng/test/rowset/serial/SerialJavaObjectTests.java line 46: > 44: > 45: /* > 46: * Validate that an SerialException is thrown when the object specified Suggestion: * Validate that a SerialException is thrown when the object specified ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From jiefu at openjdk.java.net Wed Mar 23 10:52:35 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 23 Mar 2022 10:52:35 GMT Subject: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize [v2] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 09:27:07 GMT, Severin Gehwolf wrote: >> Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap limits. In such a case a passing test tells us nothing. Certainly not if the >> fix from [JDK-8242480](https://bugs.openjdk.java.net/browse/JDK-8242480) is present or not. >> >> Testing: >> - [x] Manual with and without the code fix of JDK-8242480. Still passes with the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. > > Severin Gehwolf 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: > > - Incorporate review feedback > - Merge branch 'master' into test_getswapspace_improvement_8283279 > - 8283279: [Testbug] Improve TestGetSwapSpaceSize LGTM Thanks for the update. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7854 From dfuchs at openjdk.java.net Wed Mar 23 11:28:34 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 23 Mar 2022 11:28:34 GMT Subject: RFR: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 17:59:15 GMT, Brent Christian wrote: > Please review this change to the java/util/prefs/AddNodeChangeListener.jar test. > > Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh Preferences on each test run, MacOS does not seem to honor this, and still stores prefs in Library/. > > This test has long suffered intermittent failures. 8255031 added some debugging code; as of that change, the test fails fast as soon as an expected change event is not received. In particular, if the expected event is not received for adding the node, the test exits without removing the node. In this way, on Mac, the node can get "stuck" in the preferences of the machine. Future runs on the machine will already have the node, no node added change event will be generated (because the node was already there), the test will continue to fail without removing the node, etc. This matches observations on some CI machines. > > This change ensures that: > * the test node is not present before the test > * the test runs to completion, including removing the test node > * the test node is not left behind after the test > > Thanks. I'm not a regular contributor in this area, so maybe wait to see if a second opinion is forthcoming, but otherwise the proposed changes look reasonable to me. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7908 From sverre.moe at gmail.com Wed Mar 23 14:01:45 2022 From: sverre.moe at gmail.com (Sverre Moe) Date: Wed, 23 Mar 2022 15:01:45 +0100 Subject: jpackage Windows support for 4 digits version Message-ID: Could jpackage instruct WiX when building a native application on Windows, to support 4 digits in the version? 14:41:18 Detected [light.exe] version [3.11.2.4516]. 14:41:18 Detected [candle.exe] version [3.11.2.4516]. 14:41:18 WiX 3.11.2.4516 detected. Enabling advanced cleanup action. 14:41:18 Version sting may have up to 3 components - major.minor.build . 14:41:18 jdk.incubator.jpackage.internal.ConfigException: Version string is not compatible with MSI rules [1.10.3.1] 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) 14:41:18 jdk.incubator.jpackage.internal.PackagerException: Bundler EXE Installer Package skipped because of a configuration problem: Version string is not compatible with MSI rules [1.10.3.1] 14:41:18 Advice to fix: Set the bundler argument "win.msi.productVersion" according to these rules: https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx . 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) 14:41:18 Caused by: jdk.incubator.jpackage.internal.ConfigException: Version string is not compatible with MSI rules [1.10.3.1] 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) 14:41:18 at jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) 14:41:18 ... 3 more Perhaps something like this solution could be incorporated with the JPackage tool. https://github.com/hvandrie/msiCAFindRelatedProductsEx jpackage --windows-version-components=4 From turbanoff at gmail.com Wed Mar 23 14:03:16 2022 From: turbanoff at gmail.com (Andrey Turbanov) Date: Wed, 23 Mar 2022 17:03:16 +0300 Subject: Unused class jdk.internal.reflect.SignatureIterator Message-ID: Hello. As I can see, the class 'jdk.internal.reflect.SignatureIterator' is unused in JDK java code. Is it somehow used by VM, or is it just leftovers from some refactorings? I wonder if we can drop it. Andrey Turbanov From mcimadamore at openjdk.java.net Wed Mar 23 14:06:56 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 23 Mar 2022 14:06:56 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Drop redundant javadoc statements re. handling of nulls (handling of nulls is specified once and for all in the package javadoc) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/7ec71f73..c9bc9a70 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=03-04 Stats: 12 lines in 2 files changed: 3 ins; 8 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From sgehwolf at openjdk.java.net Wed Mar 23 15:03:37 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 23 Mar 2022 15:03:37 GMT Subject: RFR: 8283279: [Testbug] Improve TestGetSwapSpaceSize [v2] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 09:27:07 GMT, Severin Gehwolf wrote: >> Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap limits. In such a case a passing test tells us nothing. Certainly not if the >> fix from [JDK-8242480](https://bugs.openjdk.java.net/browse/JDK-8242480) is present or not. >> >> Testing: >> - [x] Manual with and without the code fix of JDK-8242480. Still passes with the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. > > Severin Gehwolf 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: > > - Incorporate review feedback > - Merge branch 'master' into test_getswapspace_improvement_8283279 > - 8283279: [Testbug] Improve TestGetSwapSpaceSize Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/7854 From sgehwolf at openjdk.java.net Wed Mar 23 15:03:38 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 23 Mar 2022 15:03:38 GMT Subject: Integrated: 8283279: [Testbug] Improve TestGetSwapSpaceSize In-Reply-To: References: Message-ID: On Thu, 17 Mar 2022 13:40:53 GMT, Severin Gehwolf wrote: > Please review this container test improvement. The test in question only makes sense iff the total swap space size as reported by the container aware OperatingSystemMXBean is `0`. If that's not the case, then something else might be amiss, e.g. OperatingSystemMXBean reporting the host swap limits. In such a case a passing test tells us nothing. Certainly not if the > fix from [JDK-8242480](https://bugs.openjdk.java.net/browse/JDK-8242480) is present or not. > > Testing: > - [x] Manual with and without the code fix of JDK-8242480. Still passes with the fix, and fails without. Tested the test on cgroups v1 and cgroups v2. This pull request has now been integrated. Changeset: a7716006 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/a77160065bb6f62314711514f7694fe50f0dc35b Stats: 31 lines in 2 files changed: 22 ins; 1 del; 8 mod 8283279: [Testbug] Improve TestGetSwapSpaceSize Reviewed-by: jiefu ------------- PR: https://git.openjdk.java.net/jdk/pull/7854 From mchung at openjdk.java.net Wed Mar 23 16:35:47 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 23 Mar 2022 16:35:47 GMT Subject: RFR: 8283470: Update java.lang.invoke.VarHandle to use sealed classes Message-ID: This patch changes VarHandle and its implementation hierarchy to use sealed classes. All VarHandle permitted classes are package-private and either final or sealed abstract classes. Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8283540 ------------- Commit messages: - 8283470: Update java.lang.invoke.VarHandle to use sealed classes Changes: https://git.openjdk.java.net/jdk/pull/7926/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7926&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283470 Stats: 58 lines in 5 files changed: 42 ins; 5 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/7926.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7926/head:pull/7926 PR: https://git.openjdk.java.net/jdk/pull/7926 From mchung at openjdk.java.net Wed Mar 23 16:37:28 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 23 Mar 2022 16:37:28 GMT Subject: RFR: 8283237: CallSite should be a sealed class [v4] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 23:18:21 GMT, liach wrote: >> Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. > > liach has updated the pull request incrementally with one additional commit since the last revision: > > Revert "Remove homemade callsite from test" > > This reverts commit 1bcd779f677420326bf365c3580ceab5a6b5e3fa. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From duke at openjdk.java.net Wed Mar 23 16:46:34 2022 From: duke at openjdk.java.net (liach) Date: Wed, 23 Mar 2022 16:46:34 GMT Subject: Integrated: 8283237: CallSite should be a sealed class In-Reply-To: References: Message-ID: On Wed, 16 Mar 2022 13:09:30 GMT, liach wrote: > Change `CallSite` to a sealed class, as `CallSite` is an abstract class which does not allow direct subclassing by users per its documentation. Since I don't have a JBS account, I posted the content for the CSR in a GitHub Gist at https://gist.github.com/150d5aa7f8b13a4deddf95969ad39d73 and wish someone can submit a CSR for me. This pull request has now been integrated. Changeset: 3e73a0b7 Author: liach Committer: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/3e73a0b726a97df0a4e92f9cf917429346090f45 Stats: 10 lines in 4 files changed: 0 ins; 0 del; 10 mod 8283237: CallSite should be a sealed class Reviewed-by: jkuhn, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7840 From darcy at openjdk.java.net Wed Mar 23 16:58:34 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Wed, 23 Mar 2022 16:58:34 GMT Subject: RFR: 8283470: Update java.lang.invoke.VarHandle to use sealed classes In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 16:27:29 GMT, Mandy Chung wrote: > This patch changes VarHandle and its implementation hierarchy to use sealed classes. All VarHandle permitted classes are package-private and either final or sealed abstract classes. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8283540 Looks fine. ------------- Marked as reviewed by darcy (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7926 From naoto at openjdk.java.net Wed Mar 23 17:33:25 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 23 Mar 2022 17:33:25 GMT Subject: RFR: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 17:59:15 GMT, Brent Christian wrote: > Please review this change to the java/util/prefs/AddNodeChangeListener.jar test. > > Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh Preferences on each test run, MacOS does not seem to honor this, and still stores prefs in Library/. > > This test has long suffered intermittent failures. 8255031 added some debugging code; as of that change, the test fails fast as soon as an expected change event is not received. In particular, if the expected event is not received for adding the node, the test exits without removing the node. In this way, on Mac, the node can get "stuck" in the preferences of the machine. Future runs on the machine will already have the node, no node added change event will be generated (because the node was already there), the test will continue to fail without removing the node, etc. This matches observations on some CI machines. > > This change ensures that: > * the test node is not present before the test > * the test runs to completion, including removing the test node > * the test node is not left behind after the test > > Thanks. Looks good to me. test/jdk/java/util/prefs/AddNodeChangeListener.java line 63: > 61: } finally { > 62: // Make sure test node is not present after the test > 63: clearPrefs(); If this call throws a `RuntimeException("Unable to clear...")`, it will override the possible `RuntimeException("Failed")` in the `try` block, but I think it is OK. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7908 From duke at openjdk.java.net Wed Mar 23 18:51:46 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 23 Mar 2022 18:51:46 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap Message-ID: 8186958: Need method to create pre-sized HashMap ------------- Commit messages: - 8186958: Need method to create pre-sized HashMap Changes: https://git.openjdk.java.net/jdk/pull/7928/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8186958 Stats: 169 lines in 2 files changed: 169 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Wed Mar 23 18:51:46 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 23 Mar 2022 18:51:46 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote: > 8186958: Need method to create pre-sized HashMap @stuart-marks I think making these functions at Collections is slightly better than place them to their own classes. The first step is to make such functions. The second step is to change some usage to these functions. I ran the jmh locally, and find it far better performance to use int calculations, than double. Benchmark Mode Cnt Score Error Units CalculateHashMapCapacityTestJMH.testCalculateHashMapCapacity1 thrpt 50 0.429 ?? 0.006 ops/s CalculateHashMapCapacityTestJMH.testCalculateHashMapCapacity2 thrpt 50 4703157194.777 ?? 25674718.597 ops/s CalculateHashMapCapacityTestJMH.testCalculateHashMapCapacity3 thrpt 50 4729596276.529 ?? 16516214.791 ops/s ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Wed Mar 23 18:57:25 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 23 Mar 2022 18:57:25 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote: > 8186958: Need method to create pre-sized HashMap I do have a local test to make sure the 3 functions I provided can produce equal capacity HashMap, but I think it does not need to be added into jdk. import java.lang.reflect.Array; import java.lang.reflect.Field; import java.util.HashMap; import java.util.Map; public class CalculateHashMapCapacityFunctionTest { /** * Calculate initial capacity for HashMap based classes, from expected size. * * @param expectedSize expected size * @return initial capacity for HashMap based classes. * @since 19 */ private static int calculateHashMapCapacity1(int expectedSize) { return (int) Math.ceil(expectedSize / 0.75); } /** * Calculate initial capacity for HashMap based classes, from expected size. * * @param expectedSize expected size * @return initial capacity for HashMap based classes. * @since 19 */ private static int calculateHashMapCapacity2(int expectedSize) { if (expectedSize >= 1610612736) { return Integer.MAX_VALUE; } return (expectedSize + (expectedSize + 2) / 3); } /** * Calculate initial capacity for HashMap based classes, from expected size. * * @param expectedSize expected size * @return initial capacity for HashMap based classes. * @since 19 */ private static int calculateHashMapCapacity3(int expectedSize) { if (expectedSize >= 805306368) { return (1 << 30); } return (expectedSize + (expectedSize + 2) / 3); } public static void main(String[] args) throws Exception { for (int i = Integer.MAX_VALUE; i >= 0; --i) { Map map1 = new HashMap<>(calculateHashMapCapacity1(i)); map1.put("1", "1"); int length1 = getArrayLength(map1); Map map2 = new HashMap<>(calculateHashMapCapacity2(i)); map2.put("1", "1"); int length2 = getArrayLength(map2); Map map3 = new HashMap<>(calculateHashMapCapacity3(i)); map3.put("1", "1"); if (i % 1000000 == 0) { System.out.println("running : " + i); } int length3 = getArrayLength(map3); if (length1 != length2 || length1 != length3) { throw new RuntimeException("wrong: " + i); } } } static Field FIELD; static { try { FIELD = HashMap.class.getDeclaredField("table"); FIELD.setAccessible(true); } catch (Exception e) { e.printStackTrace(); } } public static int getArrayLength(Map map) throws Exception { Object table = FIELD.get(map); return Array.getLength(table); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From aturbanov at openjdk.java.net Wed Mar 23 19:41:58 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 23 Mar 2022 19:41:58 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v4] In-Reply-To: References: Message-ID: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com> > Fix repeated typo `exeption` Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8283426: Fix 'exeption' typo Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7879/files - new: https://git.openjdk.java.net/jdk/pull/7879/files/1baca5ea..2ee3c98a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7879&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7879.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7879/head:pull/7879 PR: https://git.openjdk.java.net/jdk/pull/7879 From naoto at openjdk.java.net Wed Mar 23 19:47:32 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 23 Mar 2022 19:47:32 GMT Subject: Integrated: 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 18:44:09 GMT, Naoto Sato wrote: > Fixing the out-of-date number of entries in `Character.UnicodeBlock.NUM_ENTITIES` field. The regression test has been renamed and now repurposed just to examine whether the `NUM_ENTITIES` correctly has the `map.size()` value. This pull request has now been integrated. Changeset: 0ee65e1f Author: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/0ee65e1ff3eaed4a8a2542562f0ba2a61d0f5894 Stats: 128 lines in 3 files changed: 53 ins; 73 del; 2 mod 8283465: Character.UnicodeBlock.NUM_ENTITIES is out of date Reviewed-by: bpb, iris, smarks ------------- PR: https://git.openjdk.java.net/jdk/pull/7909 From mandy.chung at oracle.com Wed Mar 23 20:09:05 2022 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 23 Mar 2022 13:09:05 -0700 Subject: Unused class jdk.internal.reflect.SignatureIterator In-Reply-To: References: Message-ID: <0046e3c4-1fa2-6d83-44b0-614fb117c976@oracle.com> It's not used by the VM.? I believe it was no longer used due to JDK-4479184 long ago. Mandy On 3/23/22 7:03 AM, Andrey Turbanov wrote: > Hello. > As I can see, the class 'jdk.internal.reflect.SignatureIterator' is > unused in JDK java code. > Is it somehow used by VM, or is it just leftovers from some refactorings? > I wonder if we can drop it. > > Andrey Turbanov From valeriep at openjdk.java.net Wed Mar 23 20:49:53 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Mar 2022 20:49:53 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> Message-ID: <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> On Wed, 23 Mar 2022 04:46:48 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Minor code refactoring > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 129: > >> 127: return currVal; >> 128: } >> 129: > > I'm not very sure of this method. Is it performance friendly if making the default key size calculation in the static block (from line 142 to the end of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. > > Or did I miss something? My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From duke at openjdk.java.net Wed Mar 23 21:08:56 2022 From: duke at openjdk.java.net (liach) Date: Wed, 23 Mar 2022 21:08:56 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote: > 8186958: Need method to create pre-sized HashMap test/jdk/java/util/Collections/CalculateHashMapCapacityTestJMH.java line 42: > 40: public class CalculateHashMapCapacityTestJMH { > 41: > 42: private void consume(int tmp) { You should pass a jmh Blackhole object in the parameter of test methods and call its consume method. jmh will automatically pass the blackhole. This one will be eliminated as dead code. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Wed Mar 23 21:30:42 2022 From: duke at openjdk.java.net (liach) Date: Wed, 23 Mar 2022 21:30:42 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote: > 8186958: Need method to create pre-sized HashMap src/java.base/share/classes/java/util/Collections.java line 5826: > 5824: * @since 19 > 5825: */ > 5826: public static HashMap newHashMap(int expectedSize) { Stuart [in a JBS comment](https://bugs.openjdk.java.net/browse/JDK-8186958?focusedCommentId=14483078&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14483078) recommends keeping these factories to the respective classes instead of `Collections`. In existing code, such factories stay in the respective classes, including `ConcurrentHashMap.newKeySet(int)`. Since this is an API change, I suggest you determine where the methods will stay before filing a CSR request. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xuelei at openjdk.java.net Wed Mar 23 21:54:46 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Wed, 23 Mar 2022 21:54:46 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> Message-ID: On Wed, 23 Mar 2022 20:45:22 GMT, Valerie Peng wrote: >> src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 129: >> >>> 127: return currVal; >>> 128: } >>> 129: >> >> I'm not very sure of this method. Is it performance friendly if making the default key size calculation in the static block (from line 142 to the end of the file)? Then, the DEF_AES_KEY_SIZE could be a public primitive int. >> >> Or did I miss something? > > My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). I see. Would you mind add a comment about the provider loading impact, just in case someone else have similar questions in the future? ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Wed Mar 23 22:02:49 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Mar 2022 22:02:49 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> Message-ID: On Wed, 23 Mar 2022 21:51:51 GMT, Xue-Lei Andrew Fan wrote: >> My very first prototype is to implement the AES keysize calculation as you commented, i.e. in the static block and use an int for DEF_AES_KEY_SIZE. However, it is later discovered through testing that this leads to deadlocks as this interferes with provider loading. Given that AES key size is just a small piece of the whole puzzle, it seems safer to defer this to a later point when it's actually needed rather than touching the whole provider loading logic just to make this a static int. Performance-wise, this is a very small piece, generally should just be the AtomicInteger.get(). > > I see. > > Would you mind add a comment about the provider loading impact, just in case someone else have similar questions in the future? Sure, I can do that. Will add a comment about this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Wed Mar 23 22:48:41 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Wed, 23 Mar 2022 22:48:41 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8] In-Reply-To: References: Message-ID: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Added comment regarding possible deadlocks. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/1eb63292..a48ccef5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=06-07 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From mchung at openjdk.java.net Wed Mar 23 23:22:31 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 23 Mar 2022 23:22:31 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v4] In-Reply-To: References: Message-ID: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: per feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7766/files - new: https://git.openjdk.java.net/jdk/pull/7766/files/62f74c70..55c38cf8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=02-03 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7766.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7766/head:pull/7766 PR: https://git.openjdk.java.net/jdk/pull/7766 From mchung at openjdk.java.net Wed Mar 23 23:22:31 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 23 Mar 2022 23:22:31 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v3] In-Reply-To: References: <6z1ybGQkS4NCQkYwDuZzyPgZM5iCrXEiabwSZfYwfls=.18f4c860-ee3c-41f1-a82d-c41e417ba6b8@github.com> <9oTEL6k_kNYvHWMSVoCYi8dMzPm-_MzB58C1AdeRhCI=.e91d4569-c4a3-47fa-9f53-c6963d5068c3@github.com> Message-ID: On Wed, 23 Mar 2022 03:37:01 GMT, Mandy Chung wrote: >> src/java.base/share/classes/java/lang/invoke/DirectMethodHandle.java line 424: >> >>> 422: throw new IncompatibleClassChangeError(msg); >>> 423: } else { >>> 424: throw new NullPointerException("Cannot invoke " + member + " with null receiver"); >> >> Suggestion: >> >> String msg = String.format("Cannot invoke %s with null receiver", >> member); >> throw new NullPointerException(msg); > > Good catch. Will update it. I now reminded myself that java.base is built with -XDstringConcat=inline to avoid the bootstrap issue. So the original patch should have no issue. In any case, I updated the patch to use `String.format` to be consistent with the ICCE message formatting. ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From duke at openjdk.java.net Thu Mar 24 00:43:56 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 00:43:56 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 21:26:02 GMT, liach wrote: >> 8186958: Need method to create pre-sized HashMap > > src/java.base/share/classes/java/util/Collections.java line 5826: > >> 5824: * @since 19 >> 5825: */ >> 5826: public static HashMap newHashMap(int expectedSize) { > > Stuart [in a JBS comment](https://bugs.openjdk.java.net/browse/JDK-8186958?focusedCommentId=14483078&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14483078) recommends keeping these factories to the respective classes instead of `Collections`. In existing code, such factories stay in the respective classes, including `ConcurrentHashMap.newKeySet(int)`. > > Since this is an API change, I suggest you determine where the methods will stay before filing a CSR request. good but I have no account to comment on your jira system. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 00:43:57 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 00:43:57 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 00:39:27 GMT, XenoAmess wrote: >> src/java.base/share/classes/java/util/Collections.java line 5826: >> >>> 5824: * @since 19 >>> 5825: */ >>> 5826: public static HashMap newHashMap(int expectedSize) { >> >> Stuart [in a JBS comment](https://bugs.openjdk.java.net/browse/JDK-8186958?focusedCommentId=14483078&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14483078) recommends keeping these factories to the respective classes instead of `Collections`. In existing code, such factories stay in the respective classes, including `ConcurrentHashMap.newKeySet(int)`. >> >> Since this is an API change, I suggest you determine where the methods will stay before filing a CSR request. > > good but I have no account to comment on your jira system. still I think it better to put these functions to Collections as they can share a same calculation function. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 00:47:45 2022 From: duke at openjdk.java.net (liach) Date: Thu, 24 Mar 2022 00:47:45 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 00:40:19 GMT, XenoAmess wrote: > still I think it better to put these functions to Collections as they can share a same calculation function. You can just keep these methods in `Collections` but make them package-private, so the moved factories can call. (Note that the methods may have to go to somewhere else in `java.util` if `Collections` cannot be loaded too early during startup) > good but I have no account to comment on your jira system. I think when the patch looks good, stuart will file one CSR for you, or you can write a CSR draft for him to file. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xgong at openjdk.java.net Thu Mar 24 01:53:49 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Thu, 24 Mar 2022 01:53:49 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 09:58:23 GMT, Xiaohong Gong wrote: >> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. >> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. >> >> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: >> - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. >> - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. >> >> So with this patch, the following transformations are applied: >> >> For non-masked negation with NEON: >> >> movi v16.4s, #0x0 >> sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s >> >> and with SVE: >> >> mov z16.s, #0 >> sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s >> >> For masked negation with NEON: >> >> movi v17.4s, #0x1 >> mvn v19.16b, v18.16b >> mov v20.16b, v16.16b ==> neg v18.4s, v17.4s >> bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b >> add v19.4s, v20.4s, v17.4s >> mov v18.16b, v16.16b >> bsl v18.16b, v19.16b, v20.16b >> >> and with SVE: >> >> mov z16.s, #-1 >> mov z17.s, #1 ==> neg z16.s, p0/m, z16.s >> eor z18.s, p0/m, z18.s, z16.s >> add z18.s, p0/m, z18.s, z17.s >> >> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): >> >> NEON: >> Benchmark Gain >> Byte128Vector.NEG 1.029 >> Byte128Vector.NEGMasked 1.757 >> Short128Vector.NEG 1.041 >> Short128Vector.NEGMasked 1.659 >> Int128Vector.NEG 1.005 >> Int128Vector.NEGMasked 1.513 >> Long128Vector.NEG 1.003 >> Long128Vector.NEGMasked 1.878 >> >> SVE with 512-bits: >> Benchmark Gain >> ByteMaxVector.NEG 1.10 >> ByteMaxVector.NEGMasked 1.165 >> ShortMaxVector.NEG 1.056 >> ShortMaxVector.NEGMasked 1.195 >> IntMaxVector.NEG 1.002 >> IntMaxVector.NEGMasked 1.239 >> LongMaxVector.NEG 1.031 >> LongMaxVector.NEGMasked 1.191 >> >> X86 (non AVX-512): >> Benchmark Gain >> ByteMaxVector.NEGMasked 1.254 >> ShortMaxVector.NEGMasked 1.359 >> IntMaxVector.NEGMasked 1.431 >> LongMaxVector.NEGMasked 1.989 >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Add a superclass for vector negation Hi @PaulSandoz @jatin-bhateja, could you please help to take a look at this PR? Thanks so much! ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From dholmes at openjdk.java.net Thu Mar 24 04:55:49 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Mar 2022 04:55:49 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: <11BHH4po0p4PWloYcDR33aHTAk6weVdgyl-xh9xKXuc=.8f8fed3a-4b49-4e56-8b50-b330912358f7@github.com> On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote: > 8186958: Need method to create pre-sized HashMap src/java.base/share/classes/java/util/Collections.java line 5822: > 5820: * @param the type of keys maintained by this map > 5821: * @param the type of mapped values > 5822: * @return initial capacity for HashMap based classes. That isn't what is returned. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xuelei at openjdk.java.net Thu Mar 24 06:45:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 24 Mar 2022 06:45:42 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 22:48:41 GMT, Valerie Peng wrote: >> It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: >> >> - SHA-384 for secure hashing >> - AES-256 for symmetric encryption >> - RSA with 3072 bit keys for digital signatures and for key exchange >> - Diffie Hellman (DH) with 3072 bit keys for key exchange >> - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) >> >> So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? >> >> Thanks! > > Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: > > Added comment regarding possible deadlocks. Looks good to me. Thanks! src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > 135: public static final int DEF_ED_KEY_SIZE; > 136: public static final int DEF_XEC_KEY_SIZE; > 137: // the logic for finding the max allowable value in getDefAESKeySize() Capital the 1st letter? ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7652 From xuelei at openjdk.java.net Thu Mar 24 06:45:43 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Thu, 24 Mar 2022 06:45:43 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v7] In-Reply-To: References: <41swzBwhbUCz5d81mbzjbM3Q60GmHHqUPevIQs6LgSk=.f0b459bb-a368-40f2-a34c-8fd4b223ee78@github.com> <45EZZqaQNT4ljiATn65VwC03I9eXipUC_EMUd7jK4Bc=.14b3cf3e-73a8-48cf-a5be-fd7b73e0c331@github.com> Message-ID: On Wed, 23 Mar 2022 21:59:02 GMT, Valerie Peng wrote: >> I see. >> >> Would you mind add a comment about the provider loading impact, just in case someone else have similar questions in the future? > > Sure, I can do that. Will add a comment about this. Thank you. I have no more comment except a minor nit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From fyang at openjdk.java.net Thu Mar 24 07:01:43 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 24 Mar 2022 07:01:43 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v5] In-Reply-To: References: Message-ID: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. > > [1] https://openjdk.java.net/jeps/422 Fei Yang 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: - Merge remote-tracking branch 'upstream/master' into JDK-8276799 - Fix copyright header - Address review comments - Merge remote-tracking branch 'upstream/master' into JDK-8276799 - 8276799: Implementation of JEP 422: Linux/RISC-V Port ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/6294/files - new: https://git.openjdk.java.net/jdk/pull/6294/files/d8bef7fa..90db70eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=6294&range=03-04 Stats: 3082 lines in 147 files changed: 1635 ins; 374 del; 1073 mod Patch: https://git.openjdk.java.net/jdk/pull/6294.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6294/head:pull/6294 PR: https://git.openjdk.java.net/jdk/pull/6294 From fyang at openjdk.java.net Thu Mar 24 07:01:44 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 24 Mar 2022 07:01:44 GMT Subject: RFR: 8276799: Implementation of JEP 422: Linux/RISC-V Port [v4] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 02:17:22 GMT, Vladimir Kozlov wrote: >> Fei Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix copyright header > > Update looks good. > Testing results are also good. @vnkozlov @shipilev : Thanks for reviewing this :-) ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From duke at openjdk.java.net Thu Mar 24 07:05:44 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 07:05:44 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: <11BHH4po0p4PWloYcDR33aHTAk6weVdgyl-xh9xKXuc=.8f8fed3a-4b49-4e56-8b50-b330912358f7@github.com> References: <11BHH4po0p4PWloYcDR33aHTAk6weVdgyl-xh9xKXuc=.8f8fed3a-4b49-4e56-8b50-b330912358f7@github.com> Message-ID: On Thu, 24 Mar 2022 04:52:16 GMT, David Holmes wrote: > That isn't what is returned. @dholmes-ora Yes it isn't actually. but I cannot find a better description string for it. "the pre-processed raw initial capacity for HashMap based classes." is more exact but sounds weird. Have you any suggestions to replace this? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From fyang at openjdk.java.net Thu Mar 24 09:26:53 2022 From: fyang at openjdk.java.net (Fei Yang) Date: Thu, 24 Mar 2022 09:26:53 GMT Subject: Integrated: 8276799: Implementation of JEP 422: Linux/RISC-V Port In-Reply-To: References: Message-ID: <_xdzQDldAoyV0WBzaIMiT4tJWdNzOsP5JO-QuRhm2Z4=.da6e619a-2948-4886-878a-6feaa09e48c4@github.com> On Mon, 8 Nov 2021 11:17:47 GMT, Fei Yang wrote: > This PR implements JEP 422: Linux/RISC-V Port [1]. > The PR starts as a squashed merge of the https://openjdk.java.net/projects/riscv-port branch. > > This has been tested with jtreg tier{1,2,3,4} and jcstress on HiFive Unmatched board. Dacapo, SPECjbb2015 and SPECjvm2008 benchmark tests are also carried out regularly. So it should be good enough to run most Java programs. > > [1] https://openjdk.java.net/jeps/422 This pull request has now been integrated. Changeset: 5905b02c Author: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/5905b02c0e2643ae8d097562f181953f6c88fc89 Stats: 59141 lines in 188 files changed: 58964 ins; 54 del; 123 mod 8276799: Implementation of JEP 422: Linux/RISC-V Port Co-authored-by: Yadong Wang Co-authored-by: Yanhong Zhu Co-authored-by: Feilong Jiang Co-authored-by: Kun Wang Co-authored-by: Zhuxuan Ni Co-authored-by: Taiping Guo Co-authored-by: Kang He Co-authored-by: Aleksey Shipilev Co-authored-by: Xiaolin Zheng Co-authored-by: Kuai Wei Co-authored-by: Magnus Ihse Bursie Reviewed-by: ihse, dholmes, rriggs, kvn, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/6294 From dholmes at openjdk.java.net Thu Mar 24 11:18:41 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Mar 2022 11:18:41 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: <11BHH4po0p4PWloYcDR33aHTAk6weVdgyl-xh9xKXuc=.8f8fed3a-4b49-4e56-8b50-b330912358f7@github.com> Message-ID: On Thu, 24 Mar 2022 07:01:43 GMT, XenoAmess wrote: >> src/java.base/share/classes/java/util/Collections.java line 5822: >> >>> 5820: * @param the type of keys maintained by this map >>> 5821: * @param the type of mapped values >>> 5822: * @return initial capacity for HashMap based classes. >> >> That isn't what is returned. > >> That isn't what is returned. > > @dholmes-ora Yes it isn't actually. but I cannot find a better description string for it. > > "the pre-processed raw initial capacity for HashMap based classes." is more exact but sounds weird. > > Have you any suggestions to replace this? Thanks! This method doesn't return the capacity it returns the Map! ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From dholmes at openjdk.java.net Thu Mar 24 11:18:41 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 24 Mar 2022 11:18:41 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 18:41:59 GMT, XenoAmess wrote: > 8186958: Need method to create pre-sized HashMap src/java.base/share/classes/java/util/Collections.java line 5836: > 5834: * @param the type of keys maintained by this map > 5835: * @param the type of mapped values > 5836: * @return initial capacity for HashMap based classes. Again this method returns a Map ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:24:49 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:24:49 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap In-Reply-To: References: <11BHH4po0p4PWloYcDR33aHTAk6weVdgyl-xh9xKXuc=.8f8fed3a-4b49-4e56-8b50-b330912358f7@github.com> Message-ID: <3E7c-w8qY2YTSLbtL8SR8q_IMfggcYrzWb9q9R9d1fE=.bb533c89-83c8-41e0-9d20-9768bb553390@github.com> On Thu, 24 Mar 2022 11:14:54 GMT, David Holmes wrote: >>> That isn't what is returned. >> >> @dholmes-ora Yes it isn't actually. but I cannot find a better description string for it. >> >> "the pre-processed raw initial capacity for HashMap based classes." is more exact but sounds weird. >> >> Have you any suggestions to replace this? Thanks! > > This method doesn't return the capacity it returns the Map! my mistake. will fix it in hours. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:47:29 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:47:29 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v2] In-Reply-To: References: Message-ID: <8nxgkHyfP3ErizmtTDpwv5SjlkYnyvTCbROgfHkQItY=.fe88ee0a-6e44-4b33-b344-53065d4fcaf2@github.com> > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: fix javadoc's @return ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/2c02ea8f..78419b28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=00-01 Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:47:30 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:47:30 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v2] In-Reply-To: References: <11BHH4po0p4PWloYcDR33aHTAk6weVdgyl-xh9xKXuc=.8f8fed3a-4b49-4e56-8b50-b330912358f7@github.com> Message-ID: On Thu, 24 Mar 2022 11:14:54 GMT, David Holmes wrote: >>> That isn't what is returned. >> >> @dholmes-ora Yes it isn't actually. but I cannot find a better description string for it. >> >> "the pre-processed raw initial capacity for HashMap based classes." is more exact but sounds weird. >> >> Have you any suggestions to replace this? Thanks! > > This method doesn't return the capacity it returns the Map! @dholmes-ora done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:47:31 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:47:31 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v2] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 11:15:12 GMT, David Holmes wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> fix javadoc's @return > > src/java.base/share/classes/java/util/Collections.java line 5836: > >> 5834: * @param the type of keys maintained by this map >> 5835: * @param the type of mapped values >> 5836: * @return initial capacity for HashMap based classes. > > Again this method returns a Map @dholmes-ora done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:55:37 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:55:37 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v3] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: move the static functions to map classes themselves. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/78419b28..45f4aae9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=01-02 Stats: 125 lines in 4 files changed: 61 ins; 64 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:55:37 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:55:37 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v3] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 00:44:02 GMT, liach wrote: > Note that the methods may have to go to somewhere else in `java.util` if `Collections` cannot be loaded too early during startup, as HashMap is loaded very early I'm afraid you are correct... moved the calculation function into HashMap seems better. @liach done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:58:41 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:58:41 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v4] In-Reply-To: References: Message-ID: <2ldMYh3ZlNM-nVgKhqfxd6jfO01ywGsGGbZTcFw_O2c=.36f1e5b2-5b47-4b2f-b003-6d0aa47cbb64@github.com> > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: use jmh Blackhole ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/45f4aae9..435793c9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=02-03 Stats: 13 lines in 1 file changed: 1 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 11:58:41 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 11:58:41 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v4] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 21:04:52 GMT, liach wrote: >> XenoAmess has updated the pull request incrementally with one additional commit since the last revision: >> >> use jmh Blackhole > > test/jdk/java/util/Collections/CalculateHashMapCapacityTestJMH.java line 42: > >> 40: public class CalculateHashMapCapacityTestJMH { >> 41: >> 42: private void consume(int tmp) { > > You should pass a jmh Blackhole object in the parameter of test methods and call its consume method. jmh will automatically pass the blackhole. This one will be eliminated as dead code. @liach done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 12:10:28 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 12:10:28 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v5] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: delete a space. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/435793c9..8f4ecf63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 12:25:44 2022 From: duke at openjdk.java.net (liach) Date: Thu, 24 Mar 2022 12:25:44 GMT Subject: RFR: 8282178: Replace simple iterations of Map.entrySet with Map.forEach calls In-Reply-To: References: Message-ID: On Wed, 23 Feb 2022 22:33:42 GMT, liach wrote: > Replaces simple `for (Map.Entry entry : map.entrySet())` with `map.forEach((k, v) ->)` calls. This change is better for thread-safety and reduces allocation for some map implementations. > > A more in-depth description of benefits is available at https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086201.html and at the JBS issue itself. > > A [jmh comparison](https://jmh.morethan.io/?sources=https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/base-results.json,https://gist.githubusercontent.com/liach/0c0f79f0c0b9b78f474d65cda2c5f7b5/raw/4f2a160c51164aefdfac6ab5a19bdbc8c65f5fcf/head-results.json) on the performance of the existing `HashMapBench` shows that the performance of `putAll` for `HashMap` has not significantly changed. In a short summary, on mailing list, stuart says this doesn't benefit concurrent maps; Remi proposed to deprecate the synchronized collections for the peculiarities of iteration; kevin said that this change improves code clarity. Hence, I still believe changing to foreach calls in putAll can potentially benefit adding from maps that have expensive iterators and entry wrappers. ------------- PR: https://git.openjdk.java.net/jdk/pull/7601 From jvernee at openjdk.java.net Thu Mar 24 13:16:53 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 13:16:53 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 14:06:56 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Drop redundant javadoc statements re. handling of nulls > (handling of nulls is specified once and for all in the package javadoc) Some more nits. One potential issue with adding --enable-preview when building benchmarks (last comment of the bunch). Other than that, I think this looks good. make/test/BuildMicrobenchmark.gmk line 97: > 95: SRC := $(MICROBENCHMARK_SRC), \ > 96: BIN := $(MICROBENCHMARK_CLASSES), \ > 97: JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \ It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version. src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 61: > 59: *

  • {@linkplain MemorySegment#allocateNative(long, long, MemorySession) native memory segments}, backed by off-heap memory;
  • > 60: *
  • {@linkplain FileChannel#map(FileChannel.MapMode, long, long, MemorySession) mapped memory segments}, obtained by mapping > 61: * a file into main memory ({@code mmap}); tha contents of a mapped memory segments can be {@linkplain #force() persisted} and Suggestion: * a file into main memory ({@code mmap}); the contents of a mapped memory segments can be {@linkplain #force() persisted} and src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 298: > 296: > 297: /** > 298: * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address Saw a similar change in other places, so I'll suggest this here as well. Suggestion: * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 311: > 309: > 310: /** > 311: * Returns a slice of this memory segment, at given offset. The returned segment's base address is the base address Suggestion: * Returns a slice of this memory segment, at the given offset. The returned segment's base address is the base address src/java.base/share/classes/java/lang/foreign/MemorySession.java line 143: > 141: > 142: /** > 143: * {@return the owner thread associated with this memory session (if any)} Maybe the "if any" here could be more specific. e.g. saying that `null` is returned if the session doesn't have an owner thread. src/java.base/share/classes/java/lang/foreign/MemorySession.java line 165: > 163: > 164: /** > 165: * Closes this memory session. As a side effect, if this operation completes without exceptions, this session I'd suggest change this to "As a result of this", since the effects listed are the main reason for closing a session. (it strikes me as strange. If the things listed are side-effects, then what is the main effect of closing a segment?) Suggestion: * Closes this memory session. As a result of this, if this operation completes without exceptions, this session src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 51: > 49: *

    > 50: * Clients can obtain a {@linkplain #loaderLookup() loader lookup}, > 51: * which can be used to search symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)}, "search symbols" sounds a bit unnatural to me... I like the wording in the libraryLookup doc more Suggestion: * which can be used to find symbols in libraries loaded by the current classloader (e.g. using {@link System#load(String)}, src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 59: > 57: *

    > 58: * Finally, clients can load a library and obtain a {@linkplain #libraryLookup(Path, MemorySession) library lookup} which can be used > 59: * to search symbols in that library. A library lookup is associated with a {@linkplain MemorySession memory session}, Suggestion: * to find symbols in that library. A library lookup is associated with a {@linkplain MemorySession memory session}, src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 7895: > 7893: * VarHandle handle = MethodHandles.memorySegmentViewVarHandle(ValueLayout.JAVA_INT.withOrder(ByteOrder.BIG_ENDIAN)); //(MemorySegment, long) -> int > 7894: * handle = MethodHandles.insertCoordinates(handle, 1, 4); //(MemorySegment) -> int > 7895: * } These could be snippets. Also, I think it would be nice to add a link to MemoryLayout.varHandle here. src/java.base/share/classes/java/nio/channels/FileChannel.java line 975: > 973: /** > 974: * Maps a region of this channel's file into a new mapped memory segment, > 975: * with a given offset, size and memory session. Suggestion: * with the given offset, size and memory session. src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 51: > 49: > 50: /* A fallback lookup, used when creation of system lookup fails. */ > 51: private static final Function> fallbackLookup = name -> Optional.empty(); Now that we have SymbolLookup again, these Function types could potentially be changed to SymbolLookup again. (and also avoid some churn here) src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 135: > 133: } > 134: > 135: public Optional lookup(String name) { `@Override` here? src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1071: > 1069: sessionImpl.checkValidStateSlow(); > 1070: if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0."); > 1071: if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0."); The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing? ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From rriggs at openjdk.java.net Thu Mar 24 15:00:46 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 24 Mar 2022 15:00:46 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 12:10:28 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with one additional commit since the last revision: > > delete a space. src/java.base/share/classes/java/util/HashMap.java line 2549: > 2547: > 2548: /** > 2549: * Calculate initial capacity for HashMap based classes, from expected size. This method should say it is using a default load factor (0.75). I'm not sure how often anyone creates a map with a non-default load factor but that might suggest a more general API pattern either in the supporting calculation or the public factories. src/java.base/share/classes/java/util/HashMap.java line 2556: > 2554: */ > 2555: static int calculateHashMapCapacity(int expectedSize) { > 2556: if (expectedSize >= 1610612736) { It would be clearer with a comment on the constant or use the expression (the compiler will evaluate it). `Integer.MAX_VALUE / 4 * 3`. There also might be a valid point to make about a fail-fast exception if the requested capacity cannot be achieved. If defaulted to MAX_VALUE, the application would start populating the map and then at some later point get an exception when it cannot be resized to accommodate the n+1'th item. src/java.base/share/classes/java/util/HashMap.java line 2565: > 2563: * Creates a new, empty HashMap with an initial table size > 2564: * accommodating the specified number of elements without the need > 2565: * to dynamically resize. The default load factor should be mentioned. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From jbhateja at openjdk.java.net Thu Mar 24 15:47:45 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 24 Mar 2022 15:47:45 GMT Subject: RFR: 8279508: Auto-vectorize Math.round API [v18] In-Reply-To: References: Message-ID: <6Zb5Gbl88cEL8Ev2KqnwTpIwiUHTyijr1lOcc1sHrso=.ba487d91-0064-452a-b140-9c6b3022a221@github.com> On Wed, 23 Mar 2022 06:55:50 GMT, Tobias Hartmann wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: >> >> - 8279508: Using an explicit scratch register since rscratch1 is bound to r10 and its usage is transparent to compiler. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 >> - 8279508: Windows build failure fix. >> - 8279508: Styling comments resolved. >> - 8279508: Creating separate test for round double under feature check. >> - 8279508: Reducing the invocation count and compile thresholds for RoundTests.java. >> - 8279508: Review comments resolution. >> - 8279508: Preventing domain switch-over penalty for Math.round(float) and constraining unrolling to prevent code bloating. >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8279508 >> - 8279508: Removing +LogCompilation flag. >> - ... and 12 more: https://git.openjdk.java.net/jdk/compare/ff0b0927...c17440cf > > All tests passed. Hi @TobiHartmann , thanks for confirming. Hi @jddarcy , @theRealAph , kindly let me know if its good to integrate this. ------------- PR: https://git.openjdk.java.net/jdk/pull/7094 From alexey.semenyuk at oracle.com Thu Mar 24 16:39:00 2022 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 24 Mar 2022 12:39:00 -0400 Subject: jpackage Windows support for 4 digits version In-Reply-To: References: Message-ID: Hi Sverre, The output comes from quite old jpackage (jdk15, I guess). Please try jpackage from the newer jdk (the latest one would be the best option). They don't have this issue. - Alexey On 3/23/2022 10:01 AM, Sverre Moe wrote: > Could jpackage instruct WiX when building a native application on Windows, > to support 4 digits in the version? > > 14:41:18 Detected [light.exe] version [3.11.2.4516]. > 14:41:18 Detected [candle.exe] version [3.11.2.4516]. > 14:41:18 WiX 3.11.2.4516 detected. Enabling advanced cleanup action. > 14:41:18 Version sting may have up to 3 components - major.minor.build . > 14:41:18 jdk.incubator.jpackage.internal.ConfigException: Version string > is not compatible with MSI rules [1.10.3.1] > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > 14:41:18 jdk.incubator.jpackage.internal.PackagerException: Bundler EXE > Installer Package skipped because of a configuration problem: Version > string is not compatible with MSI rules [1.10.3.1] > 14:41:18 Advice to fix: Set the bundler argument "win.msi.productVersion" > according to these rules: > https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx . > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > 14:41:18 Caused by: jdk.incubator.jpackage.internal.ConfigException: > Version string is not compatible with MSI rules [1.10.3.1] > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > 14:41:18 at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > 14:41:18 ... 3 more > > Perhaps something like this solution could be incorporated with the > JPackage tool. > https://github.com/hvandrie/msiCAFindRelatedProductsEx > jpackage --windows-version-components=4 From duke at openjdk.java.net Thu Mar 24 16:41:35 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 16:41:35 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v6] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: refine javadoc about default load factor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/8f4ecf63..5b7eec6c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=04-05 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 16:41:36 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 16:41:36 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 14:36:36 GMT, Roger Riggs wrote: > This method should say it is using a default load factor (0.75). @RogerRiggs done. > The default load factor should be mentioned. @RogerRiggs done. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 16:50:49 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 16:50:49 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 14:54:39 GMT, Roger Riggs wrote: > It would be clearer with a comment on the constant or use the expression (the compiler will evaluate it). `Integer.MAX_VALUE / 4 * 3`. @RogerRiggs No, as `Integer.MAX_VALUE / 4 * 3` is actually 1610612733, and `(int)Math.ceil(1610612733/0.75)` is actually 2147483644, while `Integer.MAX_VALUE` is 2147483647 Although in this situation 2147483644 and 2147483647 is same (both would be trimed down to 1073741824 when enter the HashMap constructor), but I think it be better to be more precise. However if you want me to change it to `expectedSize >= Integer.MAX_VALUE / 4 * 3 + 3`, then I think it acceptable, but looks a little weird. So should we change it to `expectedSize >= Integer.MAX_VALUE / 4 * 3 + 3`? ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 16:50:49 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 16:50:49 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 16:44:50 GMT, XenoAmess wrote: >> src/java.base/share/classes/java/util/HashMap.java line 2556: >> >>> 2554: */ >>> 2555: static int calculateHashMapCapacity(int expectedSize) { >>> 2556: if (expectedSize >= 1610612736) { >> >> It would be clearer with a comment on the constant or use the expression (the compiler will evaluate it). >> `Integer.MAX_VALUE / 4 * 3`. >> >> There also might be a valid point to make about a fail-fast exception if the requested capacity cannot be achieved. If defaulted to MAX_VALUE, the application would start populating the map and then at some later point get an exception when it cannot be resized to accommodate the n+1'th item. > >> It would be clearer with a comment on the constant or use the expression (the compiler will evaluate it). `Integer.MAX_VALUE / 4 * 3`. > > @RogerRiggs > > No, as `Integer.MAX_VALUE / 4 * 3` is actually 1610612733, > > and `(int)Math.ceil(1610612733/0.75)` is actually 2147483644, > > while `Integer.MAX_VALUE` is 2147483647 > > Although in this situation 2147483644 and 2147483647 is same (both would be trimed down to 1073741824 when enter the HashMap constructor), but I think it be better to be more precise. > > However if you want me to change it to `expectedSize >= Integer.MAX_VALUE / 4 * 3 + 3`, then I think it acceptable, but looks a little weird. > > So should we change it to `expectedSize >= Integer.MAX_VALUE / 4 * 3 + 3`? > There also might be a valid point to make about a fail-fast exception if the requested capacity cannot be achieved. If defaulted to MAX_VALUE, the application would start populating the map and then at some later point get an exception when it cannot be resized to accommodate the n+1'th item. @RogerRiggs No, as I want 100% same reaction to use these functions like using new HashMap(int) So as the HashMap constructor itself doesn't throw exception when oversize, this function shall neither. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From rriggs at openjdk.java.net Thu Mar 24 17:12:48 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Thu, 24 Mar 2022 17:12:48 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v5] In-Reply-To: References: Message-ID: <70xDGoNvTaWEWJOUryQE8h4eHMpAri7NVupM5SBbSSQ=.ba45368b-8fe5-4a0e-ae68-c681de94072d@github.com> On Thu, 24 Mar 2022 16:46:11 GMT, XenoAmess wrote: >>> It would be clearer with a comment on the constant or use the expression (the compiler will evaluate it). `Integer.MAX_VALUE / 4 * 3`. >> >> @RogerRiggs >> >> No, as `Integer.MAX_VALUE / 4 * 3` is actually 1610612733, >> >> and `(int)Math.ceil(1610612733/0.75)` is actually 2147483644, >> >> while `Integer.MAX_VALUE` is 2147483647 >> >> Although in this situation 2147483644 and 2147483647 is same (both would be trimed down to 1073741824 when enter the HashMap constructor), but I think it be better to be more precise. >> >> However if you want me to change it to `expectedSize >= Integer.MAX_VALUE / 4 * 3 + 3`, then I think it acceptable, but looks a little weird. >> >> So should we change it to `expectedSize >= Integer.MAX_VALUE / 4 * 3 + 3`? > >> There also might be a valid point to make about a fail-fast exception if the requested capacity cannot be achieved. If defaulted to MAX_VALUE, the application would start populating the map and then at some later point get an exception when it cannot be resized to accommodate the n+1'th item. > > @RogerRiggs > > No, as I want 100% same reaction to use these functions like using new HashMap(int) > > So as the HashMap constructor itself doesn't throw exception when oversize, this function shall neither. I'm not too picky about how it is documented, as long as it is clear how the number 1610612733 is computed and why its the correct number. And I think that's working backward from Integer.MAX_VALUE. As for its precision, its almost irrelevant since the actual size must be a power of two; and precision is only important near the boundary of a power of two. A simple and obvious explanation is better than one that is overly precise (when it matters). ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 17:43:31 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 17:43:31 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with two additional commits since the last revision: - update jmh - refine javadoc; refine implement when expectedSize < 0 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/5b7eec6c..293b949c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=05-06 Stats: 32 lines in 2 files changed: 27 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Thu Mar 24 17:43:32 2022 From: duke at openjdk.java.net (XenoAmess) Date: Thu, 24 Mar 2022 17:43:32 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v5] In-Reply-To: <70xDGoNvTaWEWJOUryQE8h4eHMpAri7NVupM5SBbSSQ=.ba45368b-8fe5-4a0e-ae68-c681de94072d@github.com> References: <70xDGoNvTaWEWJOUryQE8h4eHMpAri7NVupM5SBbSSQ=.ba45368b-8fe5-4a0e-ae68-c681de94072d@github.com> Message-ID: On Thu, 24 Mar 2022 17:09:21 GMT, Roger Riggs wrote: > I'm not too picky about how it is documented, as long as it is clear how the number 1610612733 is computed and why its the correct number. And I think that's working backward from Integer.MAX_VALUE. As for its precision, its almost irrelevant since the actual size must be a power of two; and precision is only important near the boundary of a power of two. A simple and obvious explanation is better than one that is overly precise (when it matters). @RogerRiggs Got it. I''ve changed it and added some docs about the calculation, please have a look again. thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From xliu at openjdk.java.net Thu Mar 24 17:54:46 2022 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 24 Mar 2022 17:54:46 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v4] In-Reply-To: References: <8JNfO89cFIugnFy-fs_651PCanH8tBkuEV-K6cHKdPk=.df544db7-0595-491e-accc-975188df9c24@github.com> Message-ID: On Tue, 22 Mar 2022 10:09:40 GMT, Claes Redestad wrote: >> Xin Liu 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: >> >> - Merge branch 'master' into JDK-8282429 >> - split StringBuilder.toString() performance test out of StringBuilders.java >> - Change growOnly to maybeLatin. >> >> This patch also copys over the attribute from the other AbstractStringBuilder. >> Add a unit test to cover methods which cause maybeLatin1 becomes true. >> - make sure String(StringBuffer) is still synchronized. >> - Add a microbenchmark. >> - 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings > > Thanks for refactoring the micro to avoid the redundant run overheads, and checking that the we're size neutral on all configurations. > > I have added a few minor comments inline that you can choose to address or ignore. > > Good work! hi, @cl4es @djelinski , Could you take another look at the latest revision? thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk/pull/7671 From mcimadamore at openjdk.java.net Thu Mar 24 17:57:16 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 17:57:16 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v6] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision: - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/c9bc9a70..95f65eea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 17:57:19 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 17:57:19 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 13:10:20 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop redundant javadoc statements re. handling of nulls >> (handling of nulls is specified once and for all in the package javadoc) > > make/test/BuildMicrobenchmark.gmk line 97: > >> 95: SRC := $(MICROBENCHMARK_SRC), \ >> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >> 97: JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \ > > It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version. Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From sverre.moe at gmail.com Thu Mar 24 18:04:48 2022 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 24 Mar 2022 19:04:48 +0100 Subject: jpackage Windows support for 4 digits version In-Reply-To: References: Message-ID: Hi, This has been attempted on Java 15, Java 16 and the latest Java 17. This is the output from Java 17 14:46:49 C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat --no-daemon --version 14:46:51 14:46:51 ------------------------------------------------------------ 14:46:51 Gradle 7.3.3 14:46:51 ------------------------------------------------------------ 14:46:51 14:46:51 Build time: 2021-12-22 12:37:54 UTC 14:46:51 Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71 14:46:51 14:46:51 Kotlin: 1.5.31 14:46:51 Groovy: 3.0.9 14:46:51 Ant: Apache Ant(TM) version 1.10.11 compiled on July 10 2021 14:46:51 JVM: 17.0.2 (Eclipse Adoptium 17.0.2+8) 14:46:51 OS: Windows 10 10.0 amd64 14:46:53 C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat --no-daemon --stacktrace --refresh-dependencies -Pheadless createPackage 14:48:51 > Task :jpackage 14:48:51 [14:49:12.348] Running candle.exe 14:48:51 [14:49:12.386] Running C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe 14:48:51 [14:49:12.762] Running light.exe 14:48:51 [14:49:12.773] Running C:\Program Files (x86)\WiX Toolset v3.11\bin\light.exe 14:48:51 [14:49:13.207] Detected [candle.exe] version [3.11.2.4516]. 14:48:51 [14:49:13.208] Detected [light.exe] version [3.11.2.4516]. 14:48:51 [14:49:13.210] WiX 3.11.2.4516 detected. Enabling advanced cleanup action. 14:48:51 [14:49:13.211] jdk.jpackage.internal.ConfigException: Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. 14:48:51 at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) 14:48:51 Caused by: java.lang.IllegalArgumentException: Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. 14:48:51 at jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) 14:48:51 ... 5 more 14:48:51 [14:49:13.218] jdk.jpackage.internal.PackagerException: Bundler EXE Installer Package skipped because of a configuration problem: Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. 14:48:51 Advice to fix: Set value of --app-version parameter according to these rules: https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx 14:48:51 at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:688) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) 14:48:51 Caused by: jdk.jpackage.internal.ConfigException: Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. 14:48:51 at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) 14:48:51 ... 3 more 14:48:51 Caused by: java.lang.IllegalArgumentException: Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. 14:48:51 at jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) 14:48:51 at jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) 14:48:51 ... 5 more 14:48:51 14:48:51 14:48:51 > Task :jpackage FAILED 14:48:51 14:48:51 FAILURE: Build failed with an exception. 14:48:51 14:48:51 * What went wrong: 14:48:51 Execution failed for task ':jpackage'. 14:48:51 > Process 'command 'C:\Program Files\Eclipse Adoptium\jdk-17.0.2.8-hotspot/bin/jpackage.exe'' finished with non-zero exit tor. 24. mar. 2022 kl. 17:39 skrev Alexey Semenyuk < alexey.semenyuk at oracle.com>: > Hi Sverre, > > The output comes from quite old jpackage (jdk15, I guess). Please try > jpackage from the newer jdk (the latest one would be the best option). > They don't have this issue. > > - Alexey > > On 3/23/2022 10:01 AM, Sverre Moe wrote: > > Could jpackage instruct WiX when building a native application on > Windows, > > to support 4 digits in the version? > > > > 14:41:18 Detected [light.exe] version [3.11.2.4516]. > > 14:41:18 Detected [candle.exe] version [3.11.2.4516]. > > 14:41:18 WiX 3.11.2.4516 detected. Enabling advanced cleanup action. > > 14:41:18 Version sting may have up to 3 components - major.minor.build . > > 14:41:18 jdk.incubator.jpackage.internal.ConfigException: Version string > > is not compatible with MSI rules [1.10.3.1] > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > > 14:41:18 jdk.incubator.jpackage.internal.PackagerException: Bundler EXE > > Installer Package skipped because of a configuration problem: Version > > string is not compatible with MSI rules [1.10.3.1] > > 14:41:18 Advice to fix: Set the bundler argument > "win.msi.productVersion" > > according to these rules: > > https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx . > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > > 14:41:18 Caused by: jdk.incubator.jpackage.internal.ConfigException: > > Version string is not compatible with MSI rules [1.10.3.1] > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > 14:41:18 at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > 14:41:18 ... 3 more > > > > Perhaps something like this solution could be incorporated with the > > JPackage tool. > > https://github.com/hvandrie/msiCAFindRelatedProductsEx > > jpackage --windows-version-components=4 > > From valeriep at openjdk.java.net Thu Mar 24 18:11:50 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 18:11:50 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v8] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 06:41:11 GMT, Xue-Lei Andrew Fan wrote: >> Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: >> >> Added comment regarding possible deadlocks. > > src/java.base/share/classes/sun/security/util/SecurityProviderConstants.java line 137: > >> 135: public static final int DEF_ED_KEY_SIZE; >> 136: public static final int DEF_XEC_KEY_SIZE; >> 137: // the logic for finding the max allowable value in getDefAESKeySize() > > Capital the 1st letter? Ok~ ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From valeriep at openjdk.java.net Thu Mar 24 18:16:23 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 18:16:23 GMT Subject: RFR: 8267319: Use larger default key sizes and algorithms based on CNSA [v9] In-Reply-To: References: Message-ID: <92zDCOTW4v6y8rwrO9990oQ-XSc6C14VLJPPyezzOpU=.d3efec00-dd3d-4fea-b29f-f24d3019f474@github.com> > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! Valerie Peng has updated the pull request incrementally with one additional commit since the last revision: Use uppercase for 1st letter in some comments. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7652/files - new: https://git.openjdk.java.net/jdk/pull/7652/files/a48ccef5..8b7bc16a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7652&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7652.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7652/head:pull/7652 PR: https://git.openjdk.java.net/jdk/pull/7652 From mcimadamore at openjdk.java.net Thu Mar 24 18:19:09 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 18:19:09 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v7] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/95f65eea..3e8cfd74 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=05-06 Stats: 16 lines in 3 files changed: 2 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 18:19:12 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 18:19:12 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 13:00:12 GMT, Jorn Vernee wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Drop redundant javadoc statements re. handling of nulls >> (handling of nulls is specified once and for all in the package javadoc) > > src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 1071: > >> 1069: sessionImpl.checkValidStateSlow(); >> 1070: if (offset < 0) throw new IllegalArgumentException("Requested bytes offset must be >= 0."); >> 1071: if (size < 0) throw new IllegalArgumentException("Requested bytes size must be >= 0."); > > The javadoc also says that IAE will be thrown if `offset + size < 0` I think to guard against overflow, but I don't see that checked here. Is it missing? `mapInternal` in FileChannelImpl takes care of that for both flavors of `map` ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Thu Mar 24 18:38:44 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 18:38:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 17:48:23 GMT, Maurizio Cimadamore wrote: >> make/test/BuildMicrobenchmark.gmk line 97: >> >>> 95: SRC := $(MICROBENCHMARK_SRC), \ >>> 96: BIN := $(MICROBENCHMARK_CLASSES), \ >>> 97: JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED --enable-preview, \ >> >> It still seems like this would lead to potential issues. i.e. requiring all benchmarks to be run with `--enable-preview`? We ended up adding `--enable-preview` to our benchmarks, but do other benchmarks still work without it? AFAIK the entire benchmarks.jar will have the altered class file version. > > Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well. I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick: diff --git a/make/RunTests.gmk b/make/RunTests.gmk index 81540266ec0..9ed45fb02a8 100644 --- a/make/RunTests.gmk +++ b/make/RunTests.gmk @@ -583,7 +583,7 @@ define SetupRunMicroTestBody $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS)) # Current tests needs to open java.io - $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED + $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview # Save output as JSON or CSV file ifneq ($$(MICRO_RESULTS_FORMAT), ) People manually running the benchmarks.jar will have to pass `--enable-preview` still though. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From joehw at openjdk.java.net Thu Mar 24 18:44:27 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 24 Mar 2022 18:44:27 GMT Subject: RFR: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char Message-ID: The issue was caused by the difference on handling control characters between the parser and serializer. The parser rejected control characters while the serializer converted them to NCRs. The fix is for the later to be aligned with the parser, reporting error upon encountering control characters. Mach5 tier2 passed. ------------- Commit messages: - 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char Changes: https://git.openjdk.java.net/jdk/pull/7945/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7945&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273370 Stats: 197 lines in 4 files changed: 182 ins; 3 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/7945.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7945/head:pull/7945 PR: https://git.openjdk.java.net/jdk/pull/7945 From darcy at openjdk.java.net Thu Mar 24 18:58:43 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 24 Mar 2022 18:58:43 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes [v2] In-Reply-To: References: Message-ID: > Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. > > Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 Joe Darcy 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: - Respond to review feedback. - Merge branch 'master' into JDK-8283416 - JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7881/files - new: https://git.openjdk.java.net/jdk/pull/7881/files/f4f79411..e7c6495f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7881&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7881&range=00-01 Stats: 65233 lines in 1034 files changed: 62326 ins; 1345 del; 1562 mod Patch: https://git.openjdk.java.net/jdk/pull/7881.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7881/head:pull/7881 PR: https://git.openjdk.java.net/jdk/pull/7881 From mcimadamore at openjdk.java.net Thu Mar 24 18:59:11 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 18:59:11 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v8] In-Reply-To: References: Message-ID: <6yP7vgmmPmX36zl3Lp0Dxw48sxlimGcfvOI0YrM4Bt0=.86078fb2-182d-44a1-b861-a7a234073f40@github.com> > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/3e8cfd74..6881b6dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mchung at openjdk.java.net Thu Mar 24 19:03:48 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 24 Mar 2022 19:03:48 GMT Subject: RFR: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes [v2] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:58:43 GMT, Joe Darcy wrote: >> Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. >> >> DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. >> >> Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 > > Joe Darcy 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: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8283416 > - JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes Looks good. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7881 From mcimadamore at openjdk.java.net Thu Mar 24 19:05:35 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:05:35 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v9] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address more review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/6881b6dc..d95c6d0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=07-08 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From lancea at openjdk.java.net Thu Mar 24 19:07:49 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Thu, 24 Mar 2022 19:07:49 GMT Subject: RFR: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between the parser and serializer. The parser rejected control characters while the serializer converted them to NCRs. The fix is for the later to be aligned with the parser, reporting error upon encountering control characters. > > Mach5 tier2 passed. Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7945 From mcimadamore at openjdk.java.net Thu Mar 24 19:12:01 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:12:01 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v10] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Add --enable-preview to micro benchmark java options ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/d95c6d0f..6e7189b4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From darcy at openjdk.java.net Thu Mar 24 19:12:53 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Thu, 24 Mar 2022 19:12:53 GMT Subject: Integrated: JDK-8283416: Update java.lang.invoke.MethodHandle to use sealed classes In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 21:31:15 GMT, Joe Darcy wrote: > Small refactoring to use sealed classes in the MethodHandle implementation hierarchy. > > DelegatingMethodHandle is non-sealed rather than sealed since it has two subclasses, one defined as a nested class and only a separate type in the same package. The permits clause does not allow listed those two kinds of subclasses. > > Please also review the corresponding CSR https://bugs.openjdk.java.net/browse/JDK-8283434 This pull request has now been integrated. Changeset: f1624450 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/f16244509df7659572bfd23e55a62bb9a891000a Stats: 23 lines in 6 files changed: 6 ins; 0 del; 17 mod 8283416: Update java.lang.invoke.MethodHandle to use sealed classes Reviewed-by: sundar, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/7881 From alexey.semenyuk at oracle.com Thu Mar 24 19:14:37 2022 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 24 Mar 2022 15:14:37 -0400 Subject: [External] : Re: jpackage Windows support for 4 digits version In-Reply-To: References: Message-ID: <19828289-330b-ceaf-8c34-f34ec8fd7b1a@oracle.com> Hi Sverre, Oh, I misunderstood the problem. I though the issue was with parsing WiX version string, but the problem is that jpackage doesn't like the value of --version cli parameter. On windows this value should satisfy constrains of MSI ProductVersion property [1]: The format of the string is as follows: major.minor.build The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535. If not doing validation early, wix candle will fail later. This is platform limitation, not the limitation of jpackage. [1] https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx - Alexey On 3/24/2022 2:04 PM, Sverre Moe wrote: > Hi, > > This has been attempted on Java 15, Java 16 and the latest Java 17. > > This is the output from Java 17 > > 14:46:49 > ?C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat > ? ?--no-daemon --version > 14:46:51 > 14:46:51 ?------------------------------------------------------------ > 14:46:51 ?Gradle 7.3.3 > 14:46:51 ?------------------------------------------------------------ > 14:46:51 > 14:46:51 ?Build time: ? 2021-12-22 12:37:54 UTC > 14:46:51 ?Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71 > 14:46:51 > 14:46:51 ?Kotlin: ? ? ? 1.5.31 > 14:46:51 ?Groovy: ? ? ? 3.0.9 > 14:46:51 ?Ant: ? ? ? ? ?Apache Ant(TM) version 1.10.11 compiled on > July 10 2021 > 14:46:51 ?JVM: ? ? ? ? ?17.0.2 (Eclipse Adoptium 17.0.2+8) > 14:46:51 ?OS: ? ? ? ? ? Windows 10 10.0 amd64 > > > 14:46:53 > ?C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat > ? ?--no-daemon --stacktrace --refresh-dependencies -Pheadless > createPackage > 14:48:51 ?> Task :jpackage > 14:48:51 ?[14:49:12.348] Running candle.exe > 14:48:51 ?[14:49:12.386] Running C:\Program Files (x86)\WiX Toolset > v3.11\bin\candle.exe > 14:48:51 ?[14:49:12.762] Running light.exe > 14:48:51 ?[14:49:12.773] Running C:\Program Files (x86)\WiX Toolset > v3.11\bin\light.exe > 14:48:51 ?[14:49:13.207] Detected [candle.exe] version [3.11.2.4516]. > 14:48:51 ?[14:49:13.208] Detected [light.exe] version [3.11.2.4516]. > 14:48:51 ?[14:49:13.210] WiX 3.11.2.4516 detected. Enabling advanced > cleanup action. > 14:48:51 ?[14:49:13.211] jdk.jpackage.internal.ConfigException: > Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) > 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > 14:48:51 ?Caused by: java.lang.IllegalArgumentException: Version sting > may have between 1 and 3 components: 1, 1.2, 1.2.3. > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) > 14:48:51 ? ... 5 more > 14:48:51 ?[14:49:13.218] jdk.jpackage.internal.PackagerException: > Bundler EXE Installer Package skipped because of a configuration > problem: Version sting may have between 1 and 3 components: 1, 1.2, > 1.2.3. > 14:48:51 ?Advice to fix: Set value of --app-version parameter > according to these rules: > https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:688) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) > 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > 14:48:51 ?Caused by: jdk.jpackage.internal.ConfigException: Version > sting may have between 1 and 3 components: 1, 1.2, 1.2.3. > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) > 14:48:51 ? ... 3 more > 14:48:51 ?Caused by: java.lang.IllegalArgumentException: Version sting > may have between 1 and 3 components: 1, 1.2, 1.2.3. > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) > 14:48:51 ? at > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) > 14:48:51 ? ... 5 more > 14:48:51 > 14:48:51 > 14:48:51 ?> Task :jpackage FAILED > 14:48:51 > 14:48:51 ?FAILURE: Build failed with an exception. > 14:48:51 > 14:48:51 ?* What went wrong: > 14:48:51 ?Execution failed for task ':jpackage'. > 14:48:51 ?> Process 'command 'C:\Program Files\Eclipse > Adoptium\jdk-17.0.2.8-hotspot/bin/jpackage.exe'' finished with > non-zero exit > > > > tor. 24. mar. 2022 kl. 17:39 skrev Alexey Semenyuk > : > > Hi Sverre, > > The output comes from quite old jpackage (jdk15, I guess). Please try > jpackage from the newer jdk (the latest one would be the best > option). > They don't have this issue. > > - Alexey > > On 3/23/2022 10:01 AM, Sverre Moe wrote: > > Could jpackage instruct WiX when building a native application > on Windows, > > to support 4 digits in the version? > > > > 14:41:18? Detected [light.exe] version [3.11.2.4516]. > > 14:41:18? Detected [candle.exe] version [3.11.2.4516]. > > 14:41:18? WiX 3.11.2.4516 detected. Enabling advanced cleanup > action. > > 14:41:18? Version sting may have up to 3 components - > major.minor.build . > > 14:41:18 jdk.incubator.jpackage.internal.ConfigException: > Version string > > is not compatible with MSI rules [1.10.3.1] > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > > 14:41:18 jdk.incubator.jpackage.internal.PackagerException: > Bundler EXE > > Installer Package skipped because of a configuration problem: > Version > > string is not compatible with MSI rules [1.10.3.1] > > 14:41:18? Advice to fix: Set the bundler argument > "win.msi.productVersion" > > according to these rules: > > > https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > > . > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > > 14:41:18? Caused by: > jdk.incubator.jpackage.internal.ConfigException: > > Version string is not compatible with MSI rules [1.10.3.1] > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > 14:41:18? ?at > > > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > 14:41:18? ?... 3 more > > > > Perhaps something like this solution could be incorporated with the > > JPackage tool. > > https://github.com/hvandrie/msiCAFindRelatedProductsEx > > > jpackage --windows-version-components=4 > From aivanov at openjdk.java.net Thu Mar 24 19:25:53 2022 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 24 Mar 2022 19:25:53 GMT Subject: RFR: 8283426: Fix 'exeption' typo [v4] In-Reply-To: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com> References: <48NxGvP43iL5AnO2fxDF1vmpTZ6RxcQp4x6oaHxkEOQ=.ccd35bda-80d8-40da-8a89-bb004adc2ed2@github.com> Message-ID: On Wed, 23 Mar 2022 19:41:58 GMT, Andrey Turbanov wrote: >> Fix repeated typo `exeption` > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8283426: Fix 'exeption' typo > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From mcimadamore at openjdk.java.net Thu Mar 24 19:27:21 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:27:21 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Revert changes to RunTests.gmk ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/6e7189b4..504b564a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Thu Mar 24 19:27:22 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 19:27:22 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v11] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 19:19:34 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Revert changes to RunTests.gmk Looks Good! ------------- Marked as reviewed by jvernee (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From jvernee at openjdk.java.net Thu Mar 24 19:27:23 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Thu, 24 Mar 2022 19:27:23 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:35:12 GMT, Jorn Vernee wrote: >> Sure, this is problematic - but at the same time I don't think there's a better way to deal with this? I'd prefer to defer this to a separate issue (and I think the build team is in a much better position to suggest a better fix). IIRC we had this problem in the past as well. > > I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick: > > > diff --git a/make/RunTests.gmk b/make/RunTests.gmk > index 81540266ec0..9ed45fb02a8 100644 > --- a/make/RunTests.gmk > +++ b/make/RunTests.gmk > @@ -583,7 +583,7 @@ define SetupRunMicroTestBody > $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS)) > > # Current tests needs to open java.io > - $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED > + $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview > > # Save output as JSON or CSV file > ifneq ($$(MICRO_RESULTS_FORMAT), ) > > > People manually running the benchmarks.jar will have to pass `--enable-preview` still though. After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted. ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Thu Mar 24 19:27:24 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 24 Mar 2022 19:27:24 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v5] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 19:17:40 GMT, Jorn Vernee wrote: >> I'd suggest at least adding `--enable-preview` as an argument when running benchmarks through the build system in that case. I think this should do the trick: >> >> >> diff --git a/make/RunTests.gmk b/make/RunTests.gmk >> index 81540266ec0..9ed45fb02a8 100644 >> --- a/make/RunTests.gmk >> +++ b/make/RunTests.gmk >> @@ -583,7 +583,7 @@ define SetupRunMicroTestBody >> $$(eval $$(call SetMicroValue,$1,MICRO_JAVA_OPTIONS)) >> >> # Current tests needs to open java.io >> - $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED >> + $1_MICRO_JAVA_OPTIONS += --add-opens=java.base/java.io=ALL-UNNAMED --enable-preview >> >> # Save output as JSON or CSV file >> ifneq ($$(MICRO_RESULTS_FORMAT), ) >> >> >> People manually running the benchmarks.jar will have to pass `--enable-preview` still though. > > After discussing this offline, it seems that javac no longer poisons the minor class file version of every class file, but only of those that use preview features. So, my concern is not warranted. Turns out this is no longer necessary. As part of the support for preview API, javac now only pollutes the classfile if a source file is using preview features, as described in this PR: https://github.com/openjdk/jdk/pull/703 ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From aturbanov at openjdk.java.net Thu Mar 24 19:54:48 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 24 Mar 2022 19:54:48 GMT Subject: Integrated: 8283426: Fix 'exeption' typo In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 13:30:01 GMT, Andrey Turbanov wrote: > Fix repeated typo `exeption` This pull request has now been integrated. Changeset: dc5a65ab Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/dc5a65ab378f0780f7760965f2b52cbbd7c62aad Stats: 38 lines in 17 files changed: 0 ins; 2 del; 36 mod 8283426: Fix 'exeption' typo Reviewed-by: xuelei, iris, dholmes, wetmore, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/7879 From naoto at openjdk.java.net Thu Mar 24 20:44:42 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 24 Mar 2022 20:44:42 GMT Subject: RFR: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between the parser and serializer. The parser rejected control characters while the serializer converted them to NCRs. The fix is for the later to be aligned with the parser, reporting error upon encountering control characters. > > Mach5 tier2 passed. So the fix is now to throw an exception on serialization. Would there be any need to let the users know as it becomes a stricter behavior? ------------- PR: https://git.openjdk.java.net/jdk/pull/7945 From bchristi at openjdk.java.net Thu Mar 24 20:59:20 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 24 Mar 2022 20:59:20 GMT Subject: RFR: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar [v2] In-Reply-To: References: Message-ID: > Please review this change to the java/util/prefs/AddNodeChangeListener.jar test. > > Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh Preferences on each test run, MacOS does not seem to honor this, and still stores prefs in Library/. > > This test has long suffered intermittent failures. 8255031 added some debugging code; as of that change, the test fails fast as soon as an expected change event is not received. In particular, if the expected event is not received for adding the node, the test exits without removing the node. In this way, on Mac, the node can get "stuck" in the preferences of the machine. Future runs on the machine will already have the node, no node added change event will be generated (because the node was already there), the test will continue to fail without removing the node, etc. This matches observations on some CI machines. > > This change ensures that: > * the test node is not present before the test > * the test runs to completion, including removing the test node > * the test node is not left behind after the test > > Thanks. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Add test failure message to 'couldn't remove' RuntimeException ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7908/files - new: https://git.openjdk.java.net/jdk/pull/7908/files/71ab1f17..139b6a94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7908&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7908&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7908.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7908/head:pull/7908 PR: https://git.openjdk.java.net/jdk/pull/7908 From bchristi at openjdk.java.net Thu Mar 24 20:59:22 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Thu, 24 Mar 2022 20:59:22 GMT Subject: RFR: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar [v2] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 17:29:04 GMT, Naoto Sato wrote: >> Brent Christian has updated the pull request incrementally with one additional commit since the last revision: >> >> Add test failure message to 'couldn't remove' RuntimeException > > test/jdk/java/util/prefs/AddNodeChangeListener.java line 63: > >> 61: } finally { >> 62: // Make sure test node is not present after the test >> 63: clearPrefs(); > > If this call throws a `RuntimeException("Unable to clear...")`, it will override the possible `RuntimeException("Failed")` in the `try` block, but I think it is OK. That's true - I hadn't considered that. I think it's OK, too. Even so, I've added a message to the exception thrown from clearPrefs() to indicate if the test failed. ------------- PR: https://git.openjdk.java.net/jdk/pull/7908 From naoto at openjdk.java.net Thu Mar 24 22:11:30 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 24 Mar 2022 22:11:30 GMT Subject: RFR: 8282819: Deprecate Locale class constructors Message-ID: Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. ------------- Commit messages: - 8282819: Deprecate Locale class constructors Changes: https://git.openjdk.java.net/jdk/pull/7947/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282819 Stats: 904 lines in 196 files changed: 74 ins; 22 del; 808 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From joehw at openjdk.java.net Thu Mar 24 22:17:53 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Thu, 24 Mar 2022 22:17:53 GMT Subject: RFR: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char In-Reply-To: References: Message-ID: <-DbJTbcJLQuj3Wb4GRQBZnstmNFWkCKsRHjRS6-VHDo=.6a667a27-1ba9-44e5-9533-7833d9c35144@github.com> On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between the parser and serializer. The parser rejected control characters while the serializer converted them to NCRs. The fix is for the later to be aligned with the parser, reporting error upon encountering control characters. > > Mach5 tier2 passed. For XML 1.0, it's known that they were invalid. For prefs, it would be nice to add InvalidPreferencesFormatException to exportSubtree to match with that of importPreferences. But it's such an edge case, for this patch, I opted for no signature change. ------------- PR: https://git.openjdk.java.net/jdk/pull/7945 From naoto at openjdk.java.net Thu Mar 24 22:23:47 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Thu, 24 Mar 2022 22:23:47 GMT Subject: RFR: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between the parser and serializer. The parser rejected control characters while the serializer converted them to NCRs. The fix is for the later to be aligned with the parser, reporting error upon encountering control characters. > > Mach5 tier2 passed. Looks good. Thanks for the explanation, Joe. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7945 From valeriep at openjdk.java.net Thu Mar 24 22:53:56 2022 From: valeriep at openjdk.java.net (Valerie Peng) Date: Thu, 24 Mar 2022 22:53:56 GMT Subject: Integrated: 8267319: Use larger default key sizes and algorithms based on CNSA In-Reply-To: References: Message-ID: On Wed, 2 Mar 2022 00:13:41 GMT, Valerie Peng wrote: > It's been several years since we increased the default key sizes. Before shifting to PQC, NSA replaced its Suite B cryptography recommendations with the Commercial National Security Algorithm Suite which suggests: > > - SHA-384 for secure hashing > - AES-256 for symmetric encryption > - RSA with 3072 bit keys for digital signatures and for key exchange > - Diffie Hellman (DH) with 3072 bit keys for key exchange > - Elliptic curve [P-384] for key exchange (ECDH) and for digital signatures (ECDSA) > > So, this proposed changes made the suggested key size and algorithm changes. The changes are mostly in keytool, jarsigner and their regression tests, so @wangweij Could you please take a look? > > Thanks! This pull request has now been integrated. Changeset: 313bc7f6 Author: Valerie Peng URL: https://git.openjdk.java.net/jdk/commit/313bc7f64f69d8f352d495d2c35bea62aca910e4 Stats: 504 lines in 29 files changed: 326 ins; 8 del; 170 mod 8267319: Use larger default key sizes and algorithms based on CNSA Reviewed-by: weijun, xuelei ------------- PR: https://git.openjdk.java.net/jdk/pull/7652 From smarks at openjdk.java.net Fri Mar 25 00:25:47 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Fri, 25 Mar 2022 00:25:47 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Specs looks good, with minor modifications. I'm not so sure about replacement of the constructors with string concatenation with ternary operators; see my other comment. src/java.base/share/classes/java/util/Locale.java line 252: > 250: *

    The {@code Locale} class provides a number of convenient constants > 251: * that you can use to obtain {@code Locale} objects for commonly used > 252: * locales. For example, the following obtains a {@code Locale} object I'd replace this part (and the example below) with something like, For example, {@code Locale.US} is the {@code Locale} object for the United States. src/java.base/share/classes/java/util/Locale.java line 2511: > 2509: * constructors, the {@code Builder} checks if a value configured by a > 2510: * setter satisfies the syntax requirements defined by the {@code Locale} > 2511: * class. A {@code Locale} object obtained by a {@code Builder} is ...obtained from a Builder... src/java.base/share/classes/java/util/Locale.java line 2526: > 2524: * > 2525: *

    The following example shows how to obtain a {@code Locale} object > 2526: * with the {@code Builder}. ...shows how to obtain a Locale object using a Builder. src/java.base/share/classes/java/util/Locale.java line 2660: > 2658: * > 2659: *

    The country value in the {@code Locale} obtained by the > 2660: * {@code Builder} is always normalized to upper case. ...obtained from a Builder... src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375: > 373: (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) + > 374: (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) + > 375: (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant())); It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide? ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From dongbohe at openjdk.java.net Fri Mar 25 01:57:18 2022 From: dongbohe at openjdk.java.net (Dongbo He) Date: Fri, 25 Mar 2022 01:57:18 GMT Subject: RFR: 8240903: Add a regression test for JDK-8240734 Message-ID: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> This creates a regression test for JDK-8240734. This was once blocked by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766) We found the issue can always be produced with at least 64 modules. Note that we need to add the --date jmod option to avoid the timestamp issue. Testing: Added test case fails before JDK-8240734, and passes after JDK-8240734. Tested with tier2 on linux x86. ------------- Commit messages: - 8240903: Add a regression test for JDK-8240734 Changes: https://git.openjdk.java.net/jdk/pull/7948/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240903 Stats: 78 lines in 3 files changed: 75 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7948/head:pull/7948 PR: https://git.openjdk.java.net/jdk/pull/7948 From naoto at openjdk.java.net Fri Mar 25 01:59:51 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 01:59:51 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 00:18:54 GMT, Stuart Marks wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375: > >> 373: (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) + >> 374: (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) + >> 375: (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant())); > > It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide? True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From dongbohe at openjdk.java.net Fri Mar 25 02:26:36 2022 From: dongbohe at openjdk.java.net (Dongbo He) Date: Fri, 25 Mar 2022 02:26:36 GMT Subject: RFR: 8240903: Add a regression test for JDK-8240734 [v2] In-Reply-To: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> Message-ID: > This creates a regression test for JDK-8240734. This was once blocked > by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766) > > We found the issue can always be produced with at least 64 modules. > Note that we need to add the --date jmod option to avoid the timestamp issue. > > Testing: > Added test case fails before JDK-8240734, and passes after JDK-8240734. > Tested with tier2 on linux x86. Dongbo He has updated the pull request incrementally with one additional commit since the last revision: Update Copyright ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7948/files - new: https://git.openjdk.java.net/jdk/pull/7948/files/12c35178..b2a1c843 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7948/head:pull/7948 PR: https://git.openjdk.java.net/jdk/pull/7948 From darcy at openjdk.java.net Fri Mar 25 04:26:05 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 25 Mar 2022 04:26:05 GMT Subject: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes Message-ID: Working down the list of candidates to be sealed, this time IllegalFormatException. Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8283669 ------------- Commit messages: - JDK-8283668: Update IllegalFormatException to use sealed classes Changes: https://git.openjdk.java.net/jdk/pull/7950/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7950&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283668 Stats: 38 lines in 13 files changed: 12 ins; 0 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/7950.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7950/head:pull/7950 PR: https://git.openjdk.java.net/jdk/pull/7950 From iris at openjdk.java.net Fri Mar 25 05:01:42 2022 From: iris at openjdk.java.net (Iris Clark) Date: Fri, 25 Mar 2022 05:01:42 GMT Subject: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time IllegalFormatException. > > Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8283669 Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7950 From dongbohe at openjdk.java.net Fri Mar 25 05:16:28 2022 From: dongbohe at openjdk.java.net (Dongbo He) Date: Fri, 25 Mar 2022 05:16:28 GMT Subject: RFR: 8240903: Add a regression test for JDK-8240734 [v3] In-Reply-To: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> Message-ID: <55kL-Nlz4WxBPchyPK-3ADg1ISK4VVwRRXFxSOvFjD8=.3b29dc38-18e2-4358-8f7a-077930f6db78@github.com> > This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked > by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766) > > We found the issue can be produced stably with at least 64 modules. > Note that we need to add the --date jmod option to avoid the timestamp issue. > > Testing: > Added test case fails without fix for JDK-8240734, and passes otherwise. > Tested with tier2 on linux x86. Dongbo He has updated the pull request incrementally with one additional commit since the last revision: Get date by 'date +%Y-%m-%dT%H:%M:%S%:z' ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7948/files - new: https://git.openjdk.java.net/jdk/pull/7948/files/b2a1c843..aea79a40 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7948/head:pull/7948 PR: https://git.openjdk.java.net/jdk/pull/7948 From david.holmes at oracle.com Fri Mar 25 07:00:02 2022 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Mar 2022 17:00:02 +1000 Subject: [External] : Re: jpackage Windows support for 4 digits version In-Reply-To: <19828289-330b-ceaf-8c34-f34ec8fd7b1a@oracle.com> References: <19828289-330b-ceaf-8c34-f34ec8fd7b1a@oracle.com> Message-ID: <36c02309-debc-033a-84c2-8db8bde14842@oracle.com> On 25/03/2022 5:14 am, Alexey Semenyuk wrote: > Hi Sverre, > > Oh, I misunderstood the problem. I though the issue was with parsing WiX > version string, but the problem is that jpackage doesn't like the value > of --version cli parameter. > On windows this value should satisfy constrains of MSI ProductVersion > property [1]: > The format of the string is as follows: > major.minor.build > The first field is the major version and has a maximum value of 255. The > second field is the minor version and has a maximum value of 255. The > third field is called the build version or the update version and has a > maximum value of 65,535. It also states: "Note that Windows Installer uses only the first three fields of the product version. If you include a fourth field in your product version, the installer ignores the fourth field." So I think ignoring that fourth field is what is being requested. Cheers, David > If not doing validation early, wix candle will fail later. This is > platform limitation, not the limitation of jpackage. > > [1] https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > > - Alexey > > On 3/24/2022 2:04 PM, Sverre Moe wrote: >> Hi, >> >> This has been attempted on Java 15, Java 16 and the latest Java 17. >> >> This is the output from Java 17 >> >> 14:46:49 >> ?C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat >> ? ?--no-daemon --version >> 14:46:51 >> 14:46:51 ?------------------------------------------------------------ >> 14:46:51 ?Gradle 7.3.3 >> 14:46:51 ?------------------------------------------------------------ >> 14:46:51 >> 14:46:51 ?Build time: ? 2021-12-22 12:37:54 UTC >> 14:46:51 ?Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71 >> 14:46:51 >> 14:46:51 ?Kotlin: ? ? ? 1.5.31 >> 14:46:51 ?Groovy: ? ? ? 3.0.9 >> 14:46:51 ?Ant: ? ? ? ? ?Apache Ant(TM) version 1.10.11 compiled on >> July 10 2021 >> 14:46:51 ?JVM: ? ? ? ? ?17.0.2 (Eclipse Adoptium 17.0.2+8) >> 14:46:51 ?OS: ? ? ? ? ? Windows 10 10.0 amd64 >> >> >> 14:46:53 >> ?C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat >> ? ?--no-daemon --stacktrace --refresh-dependencies -Pheadless >> createPackage >> 14:48:51 ?> Task :jpackage >> 14:48:51 ?[14:49:12.348] Running candle.exe >> 14:48:51 ?[14:49:12.386] Running C:\Program Files (x86)\WiX Toolset >> v3.11\bin\candle.exe >> 14:48:51 ?[14:49:12.762] Running light.exe >> 14:48:51 ?[14:49:12.773] Running C:\Program Files (x86)\WiX Toolset >> v3.11\bin\light.exe >> 14:48:51 ?[14:49:13.207] Detected [candle.exe] version [3.11.2.4516]. >> 14:48:51 ?[14:49:13.208] Detected [light.exe] version [3.11.2.4516]. >> 14:48:51 ?[14:49:13.210] WiX 3.11.2.4516 detected. Enabling advanced >> cleanup action. >> 14:48:51 ?[14:49:13.211] jdk.jpackage.internal.ConfigException: >> Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) >> >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) >> >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) >> >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) >> >> 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) >> 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) >> 14:48:51 ?Caused by: java.lang.IllegalArgumentException: Version sting >> may have between 1 and 3 components: 1, 1.2, 1.2.3. >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) >> >> 14:48:51 ? ... 5 more >> 14:48:51 ?[14:49:13.218] jdk.jpackage.internal.PackagerException: >> Bundler EXE Installer Package skipped because of a configuration >> problem: Version sting may have between 1 and 3 components: 1, 1.2, >> 1.2.3. >> 14:48:51 ?Advice to fix: Set value of --app-version parameter >> according to these rules: >> https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx >> >> >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:688) >> >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) >> >> 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) >> 14:48:51 ? at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) >> 14:48:51 ?Caused by: jdk.jpackage.internal.ConfigException: Version >> sting may have between 1 and 3 components: 1, 1.2, 1.2.3. >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) >> >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) >> >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) >> >> 14:48:51 ? ... 3 more >> 14:48:51 ?Caused by: java.lang.IllegalArgumentException: Version sting >> may have between 1 and 3 components: 1, 1.2, 1.2.3. >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) >> 14:48:51 ? at >> jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) >> >> 14:48:51 ? ... 5 more >> 14:48:51 >> 14:48:51 >> 14:48:51 ?> Task :jpackage FAILED >> 14:48:51 >> 14:48:51 ?FAILURE: Build failed with an exception. >> 14:48:51 >> 14:48:51 ?* What went wrong: >> 14:48:51 ?Execution failed for task ':jpackage'. >> 14:48:51 ?> Process 'command 'C:\Program Files\Eclipse >> Adoptium\jdk-17.0.2.8-hotspot/bin/jpackage.exe'' finished with >> non-zero exit >> >> >> >> tor. 24. mar. 2022 kl. 17:39 skrev Alexey Semenyuk >> : >> >> ??? Hi Sverre, >> >> ??? The output comes from quite old jpackage (jdk15, I guess). Please try >> ??? jpackage from the newer jdk (the latest one would be the best >> ??? option). >> ??? They don't have this issue. >> >> ??? - Alexey >> >> ??? On 3/23/2022 10:01 AM, Sverre Moe wrote: >> ??? > Could jpackage instruct WiX when building a native application >> ??? on Windows, >> ??? > to support 4 digits in the version? >> ??? > >> ??? > 14:41:18? Detected [light.exe] version [3.11.2.4516]. >> ??? > 14:41:18? Detected [candle.exe] version [3.11.2.4516]. >> ??? > 14:41:18? WiX 3.11.2.4516 detected. Enabling advanced cleanup >> ??? action. >> ??? > 14:41:18? Version sting may have up to 3 components - >> ??? major.minor.build . >> ??? > 14:41:18 jdk.incubator.jpackage.internal.ConfigException: >> ??? Version string >> ??? > is not compatible with MSI rules [1.10.3.1] >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) >> >> ??? > 14:41:18 jdk.incubator.jpackage.internal.PackagerException: >> ??? Bundler EXE >> ??? > Installer Package skipped because of a configuration problem: >> ??? Version >> ??? > string is not compatible with MSI rules [1.10.3.1] >> ??? > 14:41:18? Advice to fix: Set the bundler argument >> ??? "win.msi.productVersion" >> ??? > according to these rules: >> ??? > >> ??? https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx >> >> >> >> ??? . >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) >> >> ??? > 14:41:18? Caused by: >> ??? jdk.incubator.jpackage.internal.ConfigException: >> ??? > Version string is not compatible with MSI rules [1.10.3.1] >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) >> >> ??? > 14:41:18? ?at >> ??? > >> >> jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) >> >> ??? > 14:41:18? ?... 3 more >> ??? > >> ??? > Perhaps something like this solution could be incorporated with the >> ??? > JPackage tool. >> ??? > https://github.com/hvandrie/msiCAFindRelatedProductsEx >> >> >> >> ??? > jpackage --windows-version-components=4 >> From sverre.moe at gmail.com Fri Mar 25 07:21:58 2022 From: sverre.moe at gmail.com (Sverre Moe) Date: Fri, 25 Mar 2022 08:21:58 +0100 Subject: [External] : Re: jpackage Windows support for 4 digits version In-Reply-To: <36c02309-debc-033a-84c2-8db8bde14842@oracle.com> References: <19828289-330b-ceaf-8c34-f34ec8fd7b1a@oracle.com> <36c02309-debc-033a-84c2-8db8bde14842@oracle.com> Message-ID: Hi, I was hoping something could be done to allow 4 fields in the version on Windows when using jpackage. Even though Windows will ignore the fourth component when installing, that is ok, but if we could build just build an EXE with 4 fields version. If by some configuration with jpackage, or the WiX Toolset it uses to build an EXE. I wanted to avoid having to configure an exception for Windows in Gradle like this jpackage { if (isWindows) { appVersion = applicationVersion.substring(0, applicationVersion.lastIndexOf(".")) } else { appVersion = applicationVersion } } I found someone who made a solution to allow a version with 4 fields on Windows. https://github.com/hvandrie/msiCAFindRelatedProductsEx However that would be a much more complex workaround than the one above. /Sverre fre. 25. mar. 2022 kl. 08:00 skrev David Holmes : > On 25/03/2022 5:14 am, Alexey Semenyuk wrote: > > Hi Sverre, > > > > Oh, I misunderstood the problem. I though the issue was with parsing WiX > > version string, but the problem is that jpackage doesn't like the value > > of --version cli parameter. > > On windows this value should satisfy constrains of MSI ProductVersion > > property [1]: > > The format of the string is as follows: > > major.minor.build > > The first field is the major version and has a maximum value of 255. The > > second field is the minor version and has a maximum value of 255. The > > third field is called the build version or the update version and has a > > maximum value of 65,535. > > It also states: > > "Note that Windows Installer uses only the first three fields of the > product version. If you include a fourth field in your product version, > the installer ignores the fourth field." > > So I think ignoring that fourth field is what is being requested. > > Cheers, > David > > > If not doing validation early, wix candle will fail later. This is > > platform limitation, not the limitation of jpackage. > > > > [1] https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > > > > - Alexey > > > > On 3/24/2022 2:04 PM, Sverre Moe wrote: > >> Hi, > >> > >> This has been attempted on Java 15, Java 16 and the latest Java 17. > >> > >> This is the output from Java 17 > >> > >> 14:46:49 > >> > C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat > > >> --no-daemon --version > >> 14:46:51 > >> 14:46:51 ------------------------------------------------------------ > >> 14:46:51 Gradle 7.3.3 > >> 14:46:51 ------------------------------------------------------------ > >> 14:46:51 > >> 14:46:51 Build time: 2021-12-22 12:37:54 UTC > >> 14:46:51 Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71 > >> 14:46:51 > >> 14:46:51 Kotlin: 1.5.31 > >> 14:46:51 Groovy: 3.0.9 > >> 14:46:51 Ant: Apache Ant(TM) version 1.10.11 compiled on > >> July 10 2021 > >> 14:46:51 JVM: 17.0.2 (Eclipse Adoptium 17.0.2+8) > >> 14:46:51 OS: Windows 10 10.0 amd64 > >> > >> > >> 14:46:53 > >> > C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat > > >> --no-daemon --stacktrace --refresh-dependencies -Pheadless > >> createPackage > >> 14:48:51 > Task :jpackage > >> 14:48:51 [14:49:12.348] Running candle.exe > >> 14:48:51 [14:49:12.386] Running C:\Program Files (x86)\WiX Toolset > >> v3.11\bin\candle.exe > >> 14:48:51 [14:49:12.762] Running light.exe > >> 14:48:51 [14:49:12.773] Running C:\Program Files (x86)\WiX Toolset > >> v3.11\bin\light.exe > >> 14:48:51 [14:49:13.207] Detected [candle.exe] version [3.11.2.4516]. > >> 14:48:51 [14:49:13.208] Detected [light.exe] version [3.11.2.4516]. > >> 14:48:51 [14:49:13.210] WiX 3.11.2.4516 detected. Enabling advanced > >> cleanup action. > >> 14:48:51 [14:49:13.211] jdk.jpackage.internal.ConfigException: > >> Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) > > >> > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) > > >> > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) > > >> > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) > > >> > >> 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > >> 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > >> 14:48:51 Caused by: java.lang.IllegalArgumentException: Version sting > >> may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 at > >> jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) > > >> > >> 14:48:51 ... 5 more > >> 14:48:51 [14:49:13.218] jdk.jpackage.internal.PackagerException: > >> Bundler EXE Installer Package skipped because of a configuration > >> problem: Version sting may have between 1 and 3 components: 1, 1.2, > >> 1.2.3. > >> 14:48:51 Advice to fix: Set value of --app-version parameter > >> according to these rules: > >> https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > >> < > https://urldefense.com/v3/__https://msdn.microsoft.com/en-us/library/aa370859*28v=VS.85*29.aspx__;JSU!!ACWV5N9M2RV99hQ!YstqoaSBaYrCTH11faRgBaN3Ty0NnlGP-1Q-IPI8DaDXTXeHNu1-VkCoS5UeOYqO3iFS$> > > >> > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:688) > > >> > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) > > >> > >> 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > >> 14:48:51 at jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > >> 14:48:51 Caused by: jdk.jpackage.internal.ConfigException: Version > >> sting may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) > > >> > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) > > >> > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) > > >> > >> 14:48:51 ... 3 more > >> 14:48:51 Caused by: java.lang.IllegalArgumentException: Version sting > >> may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 at > >> jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) > >> 14:48:51 at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) > > >> > >> 14:48:51 ... 5 more > >> 14:48:51 > >> 14:48:51 > >> 14:48:51 > Task :jpackage FAILED > >> 14:48:51 > >> 14:48:51 FAILURE: Build failed with an exception. > >> 14:48:51 > >> 14:48:51 * What went wrong: > >> 14:48:51 Execution failed for task ':jpackage'. > >> 14:48:51 > Process 'command 'C:\Program Files\Eclipse > >> Adoptium\jdk-17.0.2.8-hotspot/bin/jpackage.exe'' finished with > >> non-zero exit > >> > >> > >> > >> tor. 24. mar. 2022 kl. 17:39 skrev Alexey Semenyuk > >> : > >> > >> Hi Sverre, > >> > >> The output comes from quite old jpackage (jdk15, I guess). Please > try > >> jpackage from the newer jdk (the latest one would be the best > >> option). > >> They don't have this issue. > >> > >> - Alexey > >> > >> On 3/23/2022 10:01 AM, Sverre Moe wrote: > >> > Could jpackage instruct WiX when building a native application > >> on Windows, > >> > to support 4 digits in the version? > >> > > >> > 14:41:18 Detected [light.exe] version [3.11.2.4516]. > >> > 14:41:18 Detected [candle.exe] version [3.11.2.4516]. > >> > 14:41:18 WiX 3.11.2.4516 detected. Enabling advanced cleanup > >> action. > >> > 14:41:18 Version sting may have up to 3 components - > >> major.minor.build . > >> > 14:41:18 jdk.incubator.jpackage.internal.ConfigException: > >> Version string > >> > is not compatible with MSI rules [1.10.3.1] > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > >> > >> > 14:41:18 jdk.incubator.jpackage.internal.PackagerException: > >> Bundler EXE > >> > Installer Package skipped because of a configuration problem: > >> Version > >> > string is not compatible with MSI rules [1.10.3.1] > >> > 14:41:18 Advice to fix: Set the bundler argument > >> "win.msi.productVersion" > >> > according to these rules: > >> > > >> https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > >> > >> < > https://urldefense.com/v3/__https://msdn.microsoft.com/en-us/library/aa370859*28v=VS.85*29.aspx__;JSU!!ACWV5N9M2RV99hQ!YstqoaSBaYrCTH11faRgBaN3Ty0NnlGP-1Q-IPI8DaDXTXeHNu1-VkCoS5UeOYqO3iFS$> > > >> > >> . > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > >> > >> > 14:41:18 Caused by: > >> jdk.incubator.jpackage.internal.ConfigException: > >> > Version string is not compatible with MSI rules [1.10.3.1] > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > >> > >> > 14:41:18 at > >> > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > >> > >> > 14:41:18 ... 3 more > >> > > >> > Perhaps something like this solution could be incorporated with > the > >> > JPackage tool. > >> > https://github.com/hvandrie/msiCAFindRelatedProductsEx > >> > >> < > https://urldefense.com/v3/__https://github.com/hvandrie/msiCAFindRelatedProductsEx__;!!ACWV5N9M2RV99hQ!YstqoaSBaYrCTH11faRgBaN3Ty0NnlGP-1Q-IPI8DaDXTXeHNu1-VkCoS5UeOR0PTqUZ$> > > >> > >> > jpackage --windows-version-components=4 > >> > From rafael.wth at gmail.com Fri Mar 25 08:18:09 2022 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 25 Mar 2022 09:18:09 +0100 Subject: Thread::getId final method Message-ID: Hello, I was recently debugging an issue where threads' ids were used to identify an origin thread. The issue turned out to be that the getId method was overridden to return 0 for a row of threads in unrelated code, what broke that processing. I do now wonder if it would be a good idea to offer a new method on java.lang.Thread that returns the thread id but that is final. Possibly, getId should be deprecated in favour of that new method. Or is there a valid reason to override getId that I am missing? Thanks, Rafael From jiefu at openjdk.java.net Fri Mar 25 09:07:45 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Fri, 25 Mar 2022 09:07:45 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com> Message-ID: On Sat, 19 Mar 2022 03:11:12 GMT, Jie Fu wrote: >>> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: >>> >>> double negate(double arg) {return -0.0 - arg; } >>> >>> This is to handle signed zeros correctly. >> >> Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks! > >> Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: >> >> double negate(double arg) {return -0.0 - arg; } >> >> This is to handle signed zeros correctly. > > This seems easy to be broken by an opt enhancement. > Just wondering do we have a jtreg test for this point? @jddarcy > Thanks. > Hi @DamonFool , thanks for your review! All the comments have been addressed. Thanks! Thanks @XiaohongGong for the update. And sorry for the late (just a little busy this week). I'll do some testing and feedback here. ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From Alan.Bateman at oracle.com Fri Mar 25 09:09:54 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Mar 2022 09:09:54 +0000 Subject: Thread::getId final method In-Reply-To: References: Message-ID: <6ad92195-e9fc-d9fa-b817-4c912c8d4c9d@oracle.com> On 25/03/2022 08:18, Rafael Winterhalter wrote: > Hello, > > I was recently debugging an issue where threads' ids were used to identify > an origin thread. The issue turned out to be that the getId method was > overridden to return 0 for a row of threads in unrelated code, what broke > that processing. > > I do now wonder if it would be a good idea to offer a new method on > java.lang.Thread that returns the thread id but that is final. Possibly, > getId should be deprecated in favour of that new method. Loom lends on thread identifiers and adds a final Thread::threadId method, deprecating the existing getId method. It's potentially something that could be done at any time. As background,? when JSR-174 added Thread::getId it was concerned that adding a final method would be source and binary incompatible. At the time, the thread identifier was only used for monitoring purposes and wasn't a major issue if it were overridden to have different semantics. Since then, some libraries and tools have been making use of it. We did look at the impact of doing the breaking change and making it final. A static analysis of 100k artifacts found only one override, something in Apache ZooKeeper. There may be others in the wild but this is the only case found at the time. So on the surface it didn't seem to have a significant impact but a breaking change none the less and we chickened out of that approach. -Alan From jpai at openjdk.java.net Fri Mar 25 09:27:40 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 25 Mar 2022 09:27:40 GMT Subject: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time IllegalFormatException. > > Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8283669 Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7950 From ecki at zusammenkunft.net Fri Mar 25 09:37:34 2022 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Fri, 25 Mar 2022 09:37:34 +0000 Subject: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes In-Reply-To: References: Message-ID: I wonder should the CSR not describe what?s the advantage of this change is and what the compatibility problems are and why they don?t apply here? Especially given the fact that the specific sub exceptions are not sealed I wonder if the risk of breaking existing code is worth it? (But I do see the beauty of such a construct for new code!) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Jaikiran Pai Gesendet: Friday, March 25, 2022 10:27:40 AM An: core-libs-dev at openjdk.java.net Betreff: Re: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time IllegalFormatException. > > Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8283669 Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7950 From Alan.Bateman at oracle.com Fri Mar 25 09:49:46 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Mar 2022 09:49:46 +0000 Subject: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes In-Reply-To: References: Message-ID: On 25/03/2022 09:37, Bernd Eckenfels wrote: > I wonder should the CSR not describe what?s the advantage of this change is and what the compatibility problems are and why they don?t apply here? Especially given the fact that the specific sub exceptions are not sealed I wonder if the risk of breaking existing code is worth it? (But I do see the beauty of such a construct for new code!) IllegalFormatException does not have any accessible constructors so can't extended by classes outside of the java.util packages. So I think the only compatibility risk is doing something off label with deserialization to create sub-classes. -Alan From rafael.wth at gmail.com Fri Mar 25 10:02:27 2022 From: rafael.wth at gmail.com (Rafael Winterhalter) Date: Fri, 25 Mar 2022 11:02:27 +0100 Subject: Thread::getId final method In-Reply-To: <6ad92195-e9fc-d9fa-b817-4c912c8d4c9d@oracle.com> References: <6ad92195-e9fc-d9fa-b817-4c912c8d4c9d@oracle.com> Message-ID: Thanks for the info! For the use case I found, the override does not make any sense and a final method would have allowed for an easy fix if that would have been the way this was discovered. I think the method would make sense even before Loom. The overridable getter is also used in some MX beans what leads to weird exceptions there. Best regards, Rafael Alan Bateman schrieb am Fr., 25. M?rz 2022, 10:10: > On 25/03/2022 08:18, Rafael Winterhalter wrote: > > Hello, > > > > I was recently debugging an issue where threads' ids were used to > identify > > an origin thread. The issue turned out to be that the getId method was > > overridden to return 0 for a row of threads in unrelated code, what broke > > that processing. > > > > I do now wonder if it would be a good idea to offer a new method on > > java.lang.Thread that returns the thread id but that is final. Possibly, > > getId should be deprecated in favour of that new method. > Loom lends on thread identifiers and adds a final Thread::threadId > method, deprecating the existing getId method. It's potentially > something that could be done at any time. > > As background, when JSR-174 added Thread::getId it was concerned that > adding a final method would be source and binary incompatible. At the > time, the thread identifier was only used for monitoring purposes and > wasn't a major issue if it were overridden to have different semantics. > > Since then, some libraries and tools have been making use of it. We did > look at the impact of doing the breaking change and making it final. A > static analysis of 100k artifacts found only one override, something in > Apache ZooKeeper. There may be others in the wild but this is the only > case found at the time. So on the surface it didn't seem to have a > significant impact but a breaking change none the less and we chickened > out of that approach. > > -Alan > > From lancea at openjdk.java.net Fri Mar 25 10:48:48 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Fri, 25 Mar 2022 10:48:48 GMT Subject: RFR: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar [v2] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 20:59:20 GMT, Brent Christian wrote: >> Please review this change to the java/util/prefs/AddNodeChangeListener.jar test. >> >> Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh Preferences on each test run, MacOS does not seem to honor this, and still stores prefs in Library/. >> >> This test has long suffered intermittent failures. 8255031 added some debugging code; as of that change, the test fails fast as soon as an expected change event is not received. In particular, if the expected event is not received for adding the node, the test exits without removing the node. In this way, on Mac, the node can get "stuck" in the preferences of the machine. Future runs on the machine will already have the node, no node added change event will be generated (because the node was already there), the test will continue to fail without removing the node, etc. This matches observations on some CI machines. >> >> This change ensures that: >> * the test node is not present before the test >> * the test runs to completion, including removing the test node >> * the test node is not left behind after the test >> >> Thanks. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Add test failure message to 'couldn't remove' RuntimeException Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7908 From mrjarviscraft at gmail.com Fri Mar 25 11:41:07 2022 From: mrjarviscraft at gmail.com (Petr Portnov) Date: Fri, 25 Mar 2022 14:41:07 +0300 Subject: CompletionStage#{handle, whenComplete}[Async] should provide (Function, Function, ..) and (Consumer, Consumer, ..) overloads Message-ID: Hi there! CompletionStage and its subclasses (i.e. CompletableFuture) represent an either successful (T) or failed (Throwable). These states are logically mutually exclusive as can also be seen from the documentation [1]: > Two method forms (handle and whenComplete) support unconditional > computation whether the triggering stage completed normally or > exceptionally. The canonical example given there also proves this: > (result, exception) -> { > if (exception == null) { > // triggering stage completed normally > } else { > // triggering stage completed exceptionally > } > } However, the provided methods used for handling both values imply that they (from type-system standpoint) are not mutually exclusive: handle and handleAsync use BiFunction to handle the values which seems to be problematic in most cases due to the following reasons: - The states are described as non mutually exclusive (both values co-exist) and null is used specially to treat the absence of the failure, so the signature of the parameters is something like (T, null) ^ (null, Throwable). - Boilerplate null-check is almost always present as it is required to check for the present variant, also leading to extra indentation in most scenarios One might say that this can be solved by chaining thenApply[Async] and exceptionally[Async] calls but this is not true, because the latter may not want to handle the error produced by the former. The same problem is true for whenComplete[Async] which is even harder to replace with any other method: unlike it producing CompletionStage, thenAccept[Async] methods produce CompletionStage so the only way to reach the same behaviour is by utilizing thenApply[Async] with Function returning its argument (also forcing value overwrites on the side of implementation which normally would benefit from the fact of the value not being changed). It looks to me that it may be rational to add overloads to the mentioned methods which would consume pairs of Functions and Consumers respectively: - CompletionStage handle(Function resultFn, Function exceptionFn) - CompletionStage handleAsync(Function resultFn, Function exceptionFn) - CompletionStage handleAsync(Function resultFn, Function exceptionFn, Executor executor) - CompletionStage whenComplete(Consumer resultAction, Consumer exceptionAction) - CompletionStage whenCompleteAsync(Consumer resultAction, Consumer exceptionAction) - CompletionStage whenCompleteAsync(Consumer resultAction, Consumer exceptionAction, Executor executor) In order to maintain backwards-compatibility, the default implementations may simply delegate to the old ones doing the canonical null-check on the exception and then delegating to the corresponding handlers, for example: default CompletionStage handle(Function resultFn, Function exceptionFn) { return handle((result, exception) -> exception == null ? resultFn.apply(result) : exceptionFn.apply(exception)); } It also looks strange to me that while whenComplete[Async] methods use ? extends Throwable for the type of the exception, handle[Async] simply use Throwable. In my opinion, the former is more appropriate for handle[Async], thus it may be rational to apply this change to them. However, this may be considered a breaking change so I suggest discussing it. [1]: https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/CompletionStage.html ~ Peter From alanb at openjdk.java.net Fri Mar 25 11:57:50 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 25 Mar 2022 11:57:50 GMT Subject: RFR: 8240903: Add a regression test for JDK-8240734 [v3] In-Reply-To: <55kL-Nlz4WxBPchyPK-3ADg1ISK4VVwRRXFxSOvFjD8=.3b29dc38-18e2-4358-8f7a-077930f6db78@github.com> References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> <55kL-Nlz4WxBPchyPK-3ADg1ISK4VVwRRXFxSOvFjD8=.3b29dc38-18e2-4358-8f7a-077930f6db78@github.com> Message-ID: On Fri, 25 Mar 2022 05:16:28 GMT, Dongbo He wrote: >> This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked >> by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766) >> >> We found the issue can be produced stably with at least 64 modules. >> Note that we need to add the --date jmod option to avoid the timestamp issue. >> >> Testing: >> Added test case fails without fix for JDK-8240734, and passes otherwise. >> Tested with tier2 on linux x86. > > Dongbo He has updated the pull request incrementally with one additional commit since the last revision: > > Get date by 'date +%Y-%m-%dT%H:%M:%S%:z' The existing tests for the jmod tool are in test/jdk/tools/jmod. HashesTest.java might provide inspiration to avoid introducing a shell test. ------------- PR: https://git.openjdk.java.net/jdk/pull/7948 From redestad at openjdk.java.net Fri Mar 25 12:37:26 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 12:37:26 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling Message-ID: Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). ------------- Commit messages: - Fix names, typos - Avoid going through ZoneRules for ZoneOffsets Changes: https://git.openjdk.java.net/jdk/pull/7957/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7957&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283681 Stats: 126 lines in 5 files changed: 123 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7957/head:pull/7957 PR: https://git.openjdk.java.net/jdk/pull/7957 From duke at openjdk.java.net Fri Mar 25 12:37:28 2022 From: duke at openjdk.java.net (Richard Startin) Date: Fri, 25 Mar 2022 12:37:28 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:28:58 GMT, Claes Redestad wrote: > Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). test/micro/org/openjdk/bench/java/time/GetYearBench.java line 70: > 68: private static final long[] INSTANT_MILLIS = createInstants(); > 69: > 70: private static final int[] YEARS = new int[INSTANT_MILLIS.length]; Does it make any difference if these aren't constant? ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From jpai at openjdk.java.net Fri Mar 25 13:40:13 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 25 Mar 2022 13:40:13 GMT Subject: RFR: 8283683: Make ThreadLocalRandom a final class Message-ID: Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. ------------- Commit messages: - 8283683: Make ThreadLocalRandom a final class Changes: https://git.openjdk.java.net/jdk/pull/7958/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7958&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283683 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7958.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7958/head:pull/7958 PR: https://git.openjdk.java.net/jdk/pull/7958 From rriggs at openjdk.java.net Fri Mar 25 14:12:57 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Mar 2022 14:12:57 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling In-Reply-To: References: Message-ID: <8JR1yNJxpCaobtj31shTBskhEnhbNdnBr7pk1LvONGc=.59f1ba6c-e9a1-4059-88be-43ae10a38ce0@github.com> On Fri, 25 Mar 2022 12:28:58 GMT, Claes Redestad wrote: > Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). src/java.base/share/classes/java/time/ZoneRegion.java line 183: > 181: @Override > 182: /* package-private */ ZoneOffset getOffset(long epochSecond) { > 183: return getRules().getOffset(Instant.ofEpochSecond(epochSecond)); The nanoAdjustment passed to `ofEpochSecond` is discarded in this code. It may be larger than a second; see `Instant.ofEpochSecond(sec, nano)` for the details. Adding a second parameter to the `getOffset` method could be the remedy. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From jpai at openjdk.java.net Fri Mar 25 14:16:47 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 25 Mar 2022 14:16:47 GMT Subject: RFR: 8283683: Make ThreadLocalRandom a final class In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. > > tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. Hello @DougLea, do you think this change is worth doing and perhaps something that you would be willing to include in any of your future bulk updates in this area? ------------- PR: https://git.openjdk.java.net/jdk/pull/7958 From dl at openjdk.java.net Fri Mar 25 14:29:49 2022 From: dl at openjdk.java.net (Doug Lea) Date: Fri, 25 Mar 2022 14:29:49 GMT Subject: RFR: 8283683: Make ThreadLocalRandom a final class In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. > > tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. Yes, thanks; this is a good idea. As noted, it is impossible to subclass anyway because of private constructor. ------------- PR: https://git.openjdk.java.net/jdk/pull/7958 From redestad at openjdk.java.net Fri Mar 25 14:35:46 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 14:35:46 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v2] In-Reply-To: References: Message-ID: > Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Add nanoOfSecond parameter, make micro less reliant on constants ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7957/files - new: https://git.openjdk.java.net/jdk/pull/7957/files/faf35394..355f192a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7957&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7957&range=00-01 Stats: 15 lines in 5 files changed: 2 ins; 0 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/7957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7957/head:pull/7957 PR: https://git.openjdk.java.net/jdk/pull/7957 From redestad at openjdk.java.net Fri Mar 25 14:35:47 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 14:35:47 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v2] In-Reply-To: <8JR1yNJxpCaobtj31shTBskhEnhbNdnBr7pk1LvONGc=.59f1ba6c-e9a1-4059-88be-43ae10a38ce0@github.com> References: <8JR1yNJxpCaobtj31shTBskhEnhbNdnBr7pk1LvONGc=.59f1ba6c-e9a1-4059-88be-43ae10a38ce0@github.com> Message-ID: On Fri, 25 Mar 2022 14:09:03 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Add nanoOfSecond parameter, make micro less reliant on constants > > src/java.base/share/classes/java/time/ZoneRegion.java line 183: > >> 181: @Override >> 182: /* package-private */ ZoneOffset getOffset(long epochSecond) { >> 183: return getRules().getOffset(Instant.ofEpochSecond(epochSecond)); > > The nanoAdjustment passed to `ofEpochSecond` is discarded in this code. > It may be larger than a second; see `Instant.ofEpochSecond(sec, nano)` for the details. > Adding a second parameter to the `getOffset` method could be the remedy. Done. Sadly it seems the smaller improvement I got on `getYearFromMillisZoneRegion/-UTC` was due avoiding the added arithmetic in `Instant.ofEpochSecond(sec, nanos)`: Benchmark Mode Cnt Score Error Units GetYearBench.getYearFromMillisZoneOffset thrpt 15 27.579 ? 0.030 ops/ms GetYearBench.getYearFromMillisZoneRegion thrpt 15 9.570 ? 0.091 ops/ms GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 28.063 ? 0.030 ops/ms Benchmark Mode Cnt Score Error Units GetYearBench.getYearFromMillisZoneOffset thrpt 15 34.791 ? 0.030 ops/ms GetYearBench.getYearFromMillisZoneRegion thrpt 15 9.526 ? 0.122 ops/ms GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 28.056 ? 0.040 ops/ms `getYearFromMillisZoneOffset` is still good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From redestad at openjdk.java.net Fri Mar 25 14:35:47 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 14:35:47 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v2] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:33:21 GMT, Richard Startin wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Add nanoOfSecond parameter, make micro less reliant on constants > > test/micro/org/openjdk/bench/java/time/GetYearBench.java line 70: > >> 68: private static final long[] INSTANT_MILLIS = createInstants(); >> 69: >> 70: private static final int[] YEARS = new int[INSTANT_MILLIS.length]; > > Does it make any difference if these aren't constant? Interestingly a slight increase in the measured gain (14% -> 25%). I think we should favor non-constant data to subdue irrelevant JIT shenanigans so I pushed the changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From jpai at openjdk.java.net Fri Mar 25 14:51:54 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Fri, 25 Mar 2022 14:51:54 GMT Subject: RFR: 8283683: Make ThreadLocalRandom a final class In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. > > tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. Thank you Doug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7958 From rriggs at openjdk.java.net Fri Mar 25 14:55:48 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Mar 2022 14:55:48 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v2] In-Reply-To: References: <8JR1yNJxpCaobtj31shTBskhEnhbNdnBr7pk1LvONGc=.59f1ba6c-e9a1-4059-88be-43ae10a38ce0@github.com> Message-ID: On Fri, 25 Mar 2022 14:28:41 GMT, Claes Redestad wrote: >> src/java.base/share/classes/java/time/ZoneRegion.java line 183: >> >>> 181: @Override >>> 182: /* package-private */ ZoneOffset getOffset(long epochSecond) { >>> 183: return getRules().getOffset(Instant.ofEpochSecond(epochSecond)); >> >> The nanoAdjustment passed to `ofEpochSecond` is discarded in this code. >> It may be larger than a second; see `Instant.ofEpochSecond(sec, nano)` for the details. >> Adding a second parameter to the `getOffset` method could be the remedy. > > Done. > > Sadly it seems the smaller improvement I got on `getYearFromMillisZoneRegion/-UTC` was due avoiding the added arithmetic in `Instant.ofEpochSecond(sec, nanos)`: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 27.579 ? 0.030 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 9.570 ? 0.091 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 28.063 ? 0.030 ops/ms > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 34.791 ? 0.030 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 9.526 ? 0.122 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 28.056 ? 0.040 ops/ms > > > `getYearFromMillisZoneOffset` is still good. I would expect that `nanoAdjustment` is zero in most cases, would it hurt performance to test for zero and skip the math? ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From redestad at openjdk.java.net Fri Mar 25 15:09:49 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 15:09:49 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v2] In-Reply-To: References: <8JR1yNJxpCaobtj31shTBskhEnhbNdnBr7pk1LvONGc=.59f1ba6c-e9a1-4059-88be-43ae10a38ce0@github.com> Message-ID: On Fri, 25 Mar 2022 14:52:09 GMT, Roger Riggs wrote: >> Done. >> >> Sadly it seems the smaller improvement I got on `getYearFromMillisZoneRegion/-UTC` was due avoiding the added arithmetic in `Instant.ofEpochSecond(sec, nanos)`: >> >> Benchmark Mode Cnt Score Error Units >> GetYearBench.getYearFromMillisZoneOffset thrpt 15 27.579 ? 0.030 ops/ms >> GetYearBench.getYearFromMillisZoneRegion thrpt 15 9.570 ? 0.091 ops/ms >> GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 28.063 ? 0.030 ops/ms >> >> Benchmark Mode Cnt Score Error Units >> GetYearBench.getYearFromMillisZoneOffset thrpt 15 34.791 ? 0.030 ops/ms >> GetYearBench.getYearFromMillisZoneRegion thrpt 15 9.526 ? 0.122 ops/ms >> GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 28.056 ? 0.040 ops/ms >> >> >> `getYearFromMillisZoneOffset` is still good. > > I would expect that `nanoAdjustment` is zero in most cases, would it hurt performance to test for zero and skip the math? Actually I think it might be fairly common with a `nanoAdjustment` (e.g. timestamps with milliseconds), so not sure such a test is profitable. But I think it was correct to omit the nano parts for the `ZonedDateTime` constructor, since it's validating that the `nanoOfSecond` parameter is in the range 0-999999999. I'll revert the change to add the 2nd parameter to the new, internal getOffset method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From redestad at openjdk.java.net Fri Mar 25 15:16:42 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 15:16:42 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v3] In-Reply-To: References: Message-ID: > Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change to add 2nd parameter to ZoneId::getOffset ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7957/files - new: https://git.openjdk.java.net/jdk/pull/7957/files/355f192a..a04589b7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7957&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7957&range=01-02 Stats: 35 lines in 5 files changed: 29 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/7957.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7957/head:pull/7957 PR: https://git.openjdk.java.net/jdk/pull/7957 From scolebourne at openjdk.java.net Fri Mar 25 15:20:45 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Fri, 25 Mar 2022 15:20:45 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v2] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 14:35:46 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Add nanoOfSecond parameter, make micro less reliant on constants src/java.base/share/classes/java/time/ZoneOffset.java line 512: > 510: @Override > 511: /* package-private */ ZoneOffset getOffset(long epochSecond, int nanoOfSecond) { > 512: return this; An alternate approach would be for `ZoneOffset` to cache the instance of `ZoneRules` either on construction or first use (racy idiom would be OK). That way this issue is solved for the many different places that call `zoneId.getRules()`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From redestad at openjdk.java.net Fri Mar 25 15:31:46 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 15:31:46 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v2] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:17:02 GMT, Stephen Colebourne wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Add nanoOfSecond parameter, make micro less reliant on constants > > src/java.base/share/classes/java/time/ZoneOffset.java line 512: > >> 510: @Override >> 511: /* package-private */ ZoneOffset getOffset(long epochSecond, int nanoOfSecond) { >> 512: return this; > > An alternate approach would be for `ZoneOffset` to cache the instance of `ZoneRules` either on construction or first use (racy idiom would be OK). That way this issue is solved for the many different places that call `zoneId.getRules()`. Why not both? I measured an improvement using that alone, but specifically avoiding going via getRules is faster still (without adversely affecting `ZoneRegion` paths). I've added the cache in `ZoneOffset`, along with an override of `ZoneId::normalized` in `ZoneOffset` to shortcut the `getRules`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From rriggs at openjdk.java.net Fri Mar 25 15:40:46 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Mar 2022 15:40:46 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. src/java.base/share/classes/java/util/Locale.java line 245: > 243: *

    Factory Method

    > 244: * > 245: *

    The method {@link #forLanguageTag} obtains a {@code Locale} The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory. Yes, it already exists and does what's required but you might get better uptake with a more natural name. Some alternatives: - `Locale.of("en_US")` - short and conventional - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories - `Locale.forLanguage("en_US")` - natural but less conventional ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From scolebourne at openjdk.java.net Fri Mar 25 15:45:41 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Fri, 25 Mar 2022 15:45:41 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v3] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change to add 2nd parameter to ZoneId::getOffset LGTM ------------- Marked as reviewed by scolebourne (Author). PR: https://git.openjdk.java.net/jdk/pull/7957 From rriggs at openjdk.java.net Fri Mar 25 16:21:52 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Mar 2022 16:21:52 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 22:01:30 GMT, Naoto Sato wrote: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Given the large number of cleanups, I would have suggested to keep them separate from the change to re-focus the API on factories. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Fri Mar 25 16:21:52 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 16:21:52 GMT Subject: RFR: 8282819: Deprecate Locale class constructors In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:37:36 GMT, Roger Riggs wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > src/java.base/share/classes/java/util/Locale.java line 245: > >> 243: *

    Factory Method

    >> 244: * >> 245: *

    The method {@link #forLanguageTag} obtains a {@code Locale} > > The factory name `forLanguageTag` is a bit off-putting, it doesn't seem like the best name for the factory. > Yes, it already exists and does what's required but you might get better uptake with a more natural name. > > Some alternatives: > - `Locale.of("en_US")` - short and conventional > - `Locale.ofLanguage("en_US")` - 'of' prefix is used in other factories > - `Locale.forLanguage("en_US")` - natural but less conventional I was thinking of a *new* factory method, along the line with Stuart's suggestion, something like this: Locale.of(String... elements) where elements can either `(lang)`, `(lang, ctry)`, `(lang, ctry, vrnt)`, or `(lang, ctry, vrnt, scpt)`. Either element can be an empty string, but cannot be null. These elements are *not* language tags, but conventional arguments to constructors, so it is compatible (and works as a stop-gap) to the old constructors. This way third parties will not have to deal with the boilerplate code mentioned above on migration. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From bchristi at openjdk.java.net Fri Mar 25 17:11:49 2022 From: bchristi at openjdk.java.net (Brent Christian) Date: Fri, 25 Mar 2022 17:11:49 GMT Subject: Integrated: 8283349 : Robustness improvements to java/util/prefs/AddNodeChangeListener.jar In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 17:59:15 GMT, Brent Christian wrote: > Please review this change to the java/util/prefs/AddNodeChangeListener.jar test. > > Although the test specifies "-Djava.util.prefs.userRoot=." to ensure a fresh Preferences on each test run, MacOS does not seem to honor this, and still stores prefs in Library/. > > This test has long suffered intermittent failures. 8255031 added some debugging code; as of that change, the test fails fast as soon as an expected change event is not received. In particular, if the expected event is not received for adding the node, the test exits without removing the node. In this way, on Mac, the node can get "stuck" in the preferences of the machine. Future runs on the machine will already have the node, no node added change event will be generated (because the node was already there), the test will continue to fail without removing the node, etc. This matches observations on some CI machines. > > This change ensures that: > * the test node is not present before the test > * the test runs to completion, including removing the test node > * the test node is not left behind after the test > > Thanks. This pull request has now been integrated. Changeset: 656cba7a Author: Brent Christian URL: https://git.openjdk.java.net/jdk/commit/656cba7af376d6460202591230ac95d2366de9f3 Stats: 70 lines in 1 file changed: 30 ins; 17 del; 23 mod 8283349: Robustness improvements to java/util/prefs/AddNodeChangeListener.jar Reviewed-by: dfuchs, naoto, lancea ------------- PR: https://git.openjdk.java.net/jdk/pull/7908 From naoto at openjdk.java.net Fri Mar 25 17:32:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 17:32:44 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v3] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change to add 2nd parameter to ZoneId::getOffset Marked as reviewed by naoto (Reviewer). test/micro/org/openjdk/bench/java/time/GetYearBench.java line 66: > 64: private TimeZone UTC = TimeZone.getTimeZone("UTC"); > 65: > 66: private TimeZone LONDON = TimeZone.getTimeZone("Europe/London"); Nit: No need to use `TimeZone.getTimeZone()` here (and later convert them to `toZoneId()`). `ZoneId.of()` should suffice. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From joehw at openjdk.java.net Fri Mar 25 18:14:50 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Fri, 25 Mar 2022 18:14:50 GMT Subject: Integrated: 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 18:21:05 GMT, Joe Wang wrote: > The issue was caused by the difference on handling control characters between the parser and serializer. The parser rejected control characters while the serializer converted them to NCRs. The fix is for the later to be aligned with the parser, reporting error upon encountering control characters. > > Mach5 tier2 passed. This pull request has now been integrated. Changeset: f4fd53d0 Author: Joe Wang URL: https://git.openjdk.java.net/jdk/commit/f4fd53d0aee67319bf2c7bcaa671c2e97e66383f Stats: 197 lines in 4 files changed: 182 ins; 3 del; 12 mod 8273370: Preferences.exportSubtree() generates invalid XML if value contains control char Reviewed-by: lancea, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7945 From alexey.semenyuk at oracle.com Fri Mar 25 18:57:24 2022 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 25 Mar 2022 14:57:24 -0400 Subject: [External] : Re: jpackage Windows support for 4 digits version In-Reply-To: References: <19828289-330b-ceaf-8c34-f34ec8fd7b1a@oracle.com> <36c02309-debc-033a-84c2-8db8bde14842@oracle.com> Message-ID: Sverre, exe installers generated by jpackage are just wrappers for msi installers. Moving workaround you have in Gradle into jpackage will not solve the problem, but will hide it. This doesn't look appealing. We need a better solution. I created https://bugs.openjdk.java.net/browse/JDK-8283707 CR to track your request. - Alexey On 3/25/2022 3:21 AM, Sverre Moe wrote: > Hi, > > I was hoping something could be done to allow 4 fields?in the version > on Windows when using jpackage. > Even though Windows will ignore the fourth component when installing, > that is ok, but if we could build just build an EXE with 4 fields > version. If by some configuration with jpackage, or the WiX Toolset it > uses to build an EXE. > > I wanted to avoid having to configure an exception for Windows in > Gradle like this > ? ? jpackage { > ? ? ? ? if (isWindows) { > ? ? ? ? ? ? appVersion = applicationVersion.substring(0, > applicationVersion.lastIndexOf(".")) > ? ? ? ? } else { > ? ? ? ? ? ? appVersion = applicationVersion > ? ? ? ? } > ? ? } > > I found someone who made a solution to allow a version with 4 fields > on Windows. > https://github.com/hvandrie/msiCAFindRelatedProductsEx > However that would be a much more complex workaround than the one above. > > > > /Sverre > > > fre. 25. mar. 2022 kl. 08:00 skrev David Holmes : > > On 25/03/2022 5:14 am, Alexey Semenyuk wrote: > > Hi Sverre, > > > > Oh, I misunderstood the problem. I though the issue was with > parsing WiX > > version string, but the problem is that jpackage doesn't like > the value > > of --version cli parameter. > > On windows this value should satisfy constrains of MSI > ProductVersion > > property [1]: > > The format of the string is as follows: > > major.minor.build > > The first field is the major version and has a maximum value of > 255. The > > second field is the minor version and has a maximum value of > 255. The > > third field is called the build version or the update version > and has a > > maximum value of 65,535. > > It also states: > > "Note that Windows Installer uses only the first three fields of the > product version. If you include a fourth field in your product > version, > the installer ignores the fourth field." > > So I think ignoring that fourth field is what is being requested. > > Cheers, > David > > > If not doing validation early, wix candle will fail later. This is > > platform limitation, not the limitation of jpackage. > > > > [1] > https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > > > > - Alexey > > > > On 3/24/2022 2:04 PM, Sverre Moe wrote: > >> Hi, > >> > >> This has been attempted on Java 15, Java 16 and the latest Java 17. > >> > >> This is the output from Java 17 > >> > >> 14:46:49 > >> > ?C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat > > >> ? ?--no-daemon --version > >> 14:46:51 > >> 14:46:51 > ?------------------------------------------------------------ > >> 14:46:51 ?Gradle 7.3.3 > >> 14:46:51 > ?------------------------------------------------------------ > >> 14:46:51 > >> 14:46:51 ?Build time: ? 2021-12-22 12:37:54 UTC > >> 14:46:51 ?Revision: 6f556c80f945dc54b50e0be633da6c62dbe8dc71 > >> 14:46:51 > >> 14:46:51 ?Kotlin: ? ? ? 1.5.31 > >> 14:46:51 ?Groovy: ? ? ? 3.0.9 > >> 14:46:51 ?Ant: ? ? ? ? ?Apache Ant(TM) version 1.10.11 compiled on > >> July 10 2021 > >> 14:46:51 ?JVM: ? ? ? ? ?17.0.2 (Eclipse Adoptium 17.0.2+8) > >> 14:46:51 ?OS: ? ? ? ? ? Windows 10 10.0 amd64 > >> > >> > >> 14:46:53 > >> > ?C:\cygwin64\home\build\jenkins-test\workspace\our-awesome-project_sverre_SF-99>gradlew.bat > > >> ? ?--no-daemon --stacktrace --refresh-dependencies -Pheadless > >> createPackage > >> 14:48:51 ?> Task :jpackage > >> 14:48:51 ?[14:49:12.348] Running candle.exe > >> 14:48:51 ?[14:49:12.386] Running C:\Program Files (x86)\WiX > Toolset > >> v3.11\bin\candle.exe > >> 14:48:51 ?[14:49:12.762] Running light.exe > >> 14:48:51 ?[14:49:12.773] Running C:\Program Files (x86)\WiX > Toolset > >> v3.11\bin\light.exe > >> 14:48:51 ?[14:49:13.207] Detected [candle.exe] version > [3.11.2.4516]. > >> 14:48:51 ?[14:49:13.208] Detected [light.exe] version > [3.11.2.4516]. > >> 14:48:51 ?[14:49:13.210] WiX 3.11.2.4516 detected. Enabling > advanced > >> cleanup action. > >> 14:48:51 ?[14:49:13.211] jdk.jpackage.internal.ConfigException: > >> Version sting may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) > > >> > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) > > >> > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) > > >> > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) > > >> > >> 14:48:51 ? at > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > >> 14:48:51 ? at > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > >> 14:48:51 ?Caused by: java.lang.IllegalArgumentException: > Version sting > >> may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) > > >> > >> 14:48:51 ? ... 5 more > >> 14:48:51 ?[14:49:13.218] jdk.jpackage.internal.PackagerException: > >> Bundler EXE Installer Package skipped because of a configuration > >> problem: Version sting may have between 1 and 3 components: 1, > 1.2, > >> 1.2.3. > >> 14:48:51 ?Advice to fix: Set value of --app-version parameter > >> according to these rules: > >> > https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > >> > > > >> > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:688) > > >> > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.processArguments(Arguments.java:550) > > >> > >> 14:48:51 ? at > jdk.jpackage/jdk.jpackage.main.Main.execute(Main.java:91) > >> 14:48:51 ? at > jdk.jpackage/jdk.jpackage.main.Main.main(Main.java:52) > >> 14:48:51 ?Caused by: jdk.jpackage.internal.ConfigException: > Version > >> sting may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:319) > > >> > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:93) > > >> > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.Arguments.generateBundle(Arguments.java:675) > > >> > >> 14:48:51 ? ... 3 more > >> 14:48:51 ?Caused by: java.lang.IllegalArgumentException: > Version sting > >> may have between 1 and 3 components: 1, 1.2, 1.2.3. > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.MsiVersion.of(MsiVersion.java:46) > >> 14:48:51 ? at > >> > jdk.jpackage/jdk.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:317) > > >> > >> 14:48:51 ? ... 5 more > >> 14:48:51 > >> 14:48:51 > >> 14:48:51 ?> Task :jpackage FAILED > >> 14:48:51 > >> 14:48:51 ?FAILURE: Build failed with an exception. > >> 14:48:51 > >> 14:48:51 ?* What went wrong: > >> 14:48:51 ?Execution failed for task ':jpackage'. > >> 14:48:51 ?> Process 'command 'C:\Program Files\Eclipse > >> Adoptium\jdk-17.0.2.8-hotspot/bin/jpackage.exe'' finished with > >> non-zero exit > >> > >> > >> > >> tor. 24. mar. 2022 kl. 17:39 skrev Alexey Semenyuk > >> : > >> > >> ??? Hi Sverre, > >> > >> ??? The output comes from quite old jpackage (jdk15, I guess). > Please try > >> ??? jpackage from the newer jdk (the latest one would be the best > >> ??? option). > >> ??? They don't have this issue. > >> > >> ??? - Alexey > >> > >> ??? On 3/23/2022 10:01 AM, Sverre Moe wrote: > >> ??? > Could jpackage instruct WiX when building a native > application > >> ??? on Windows, > >> ??? > to support 4 digits in the version? > >> ??? > > >> ??? > 14:41:18? Detected [light.exe] version [3.11.2.4516]. > >> ??? > 14:41:18? Detected [candle.exe] version [3.11.2.4516]. > >> ??? > 14:41:18? WiX 3.11.2.4516 detected. Enabling advanced cleanup > >> ??? action. > >> ??? > 14:41:18? Version sting may have up to 3 components - > >> ??? major.minor.build . > >> ??? > 14:41:18 jdk.incubator.jpackage.internal.ConfigException: > >> ??? Version string > >> ??? > is not compatible with MSI rules [1.10.3.1] > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > > >> > >> ??? > 14:41:18 jdk.incubator.jpackage.internal.PackagerException: > >> ??? Bundler EXE > >> ??? > Installer Package skipped because of a configuration problem: > >> ??? Version > >> ??? > string is not compatible with MSI rules [1.10.3.1] > >> ??? > 14:41:18? Advice to fix: Set the bundler argument > >> ??? "win.msi.productVersion" > >> ??? > according to these rules: > >> ??? > > >> https://msdn.microsoft.com/en-us/library/aa370859%28v=VS.85%29.aspx > >> > >> > > > >> > >> ??? . > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:653) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.processArguments(Arguments.java:514) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.execute(Main.java:97) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.main.Main.main(Main.java:51) > > >> > >> ??? > 14:41:18? Caused by: > >> ??? jdk.incubator.jpackage.internal.ConfigException: > >> ??? > Version string is not compatible with MSI rules [1.10.3.1] > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinMsiBundler.validate(WinMsiBundler.java:256) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.WinExeBundler.validate(WinExeBundler.java:99) > > >> > >> ??? > 14:41:18? ?at > >> ??? > > >> > >> > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Arguments.generateBundle(Arguments.java:640) > > >> > >> ??? > 14:41:18? ?... 3 more > >> ??? > > >> ??? > Perhaps something like this solution could be > incorporated with the > >> ??? > JPackage tool. > >> ??? > https://github.com/hvandrie/msiCAFindRelatedProductsEx > >> > >> > > > >> > >> ??? > jpackage --windows-version-components=4 > >> > From rriggs at openjdk.java.net Fri Mar 25 19:39:47 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Fri, 25 Mar 2022 19:39:47 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v3] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change to add 2nd parameter to ZoneId::getOffset Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From naoto at openjdk.java.net Fri Mar 25 21:53:27 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 21:53:27 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v2] In-Reply-To: References: Message-ID: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added a new factory method, removed pure refactoring from Locale API changes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7947/files - new: https://git.openjdk.java.net/jdk/pull/7947/files/9ff69cbe..e874ff7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=00-01 Stats: 887 lines in 193 files changed: 37 ins; 67 del; 783 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Fri Mar 25 22:14:48 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 22:14:48 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v2] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 01:56:33 GMT, Naoto Sato wrote: >> src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java line 375: >> >>> 373: (locale.getLanguage().isEmpty() ? "und" : locale.getLanguage()) + >>> 374: (locale.getCountry().isEmpty() ? "" : "-" + locale.getCountry()) + >>> 375: (locale.getVariant().isEmpty() ? "" : "-x-lvariant-" + locale.getVariant())); >> >> It seems like this snippet (and ones very similar to it) are repeated several times throughout the JDK code as replacements for the two- and three-arg constructors. This seems like a fair increase in complexity, and the use of "und" and "-x-lvariant-" are quite non-obvious. Would we recommend that third party code that uses the Locale constructors replace them with this snippet? Is there something better that we can provide? > > True. One solution could be to expose `Locale.getInstance()`, which is currently a package-private static method, for this purpose. Though that means promoting `ill-formed` locale objects which defy some part of the deprecation cause. Introduced a new `Locale.of(String...)` method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From redestad at openjdk.java.net Fri Mar 25 22:41:56 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 22:41:56 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v3] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 15:16:42 GMT, Claes Redestad wrote: >> Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). >> >> It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change to add 2nd parameter to ZoneId::getOffset Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From redestad at openjdk.java.net Fri Mar 25 22:41:56 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 22:41:56 GMT Subject: RFR: 8283681: Improve ZonedDateTime offset handling [v3] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 17:27:32 GMT, Naoto Sato wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Override ZoneOffset::normalized, cache ZoneOffset::getRules, revert change to add 2nd parameter to ZoneId::getOffset > > test/micro/org/openjdk/bench/java/time/GetYearBench.java line 66: > >> 64: private TimeZone UTC = TimeZone.getTimeZone("UTC"); >> 65: >> 66: private TimeZone LONDON = TimeZone.getTimeZone("Europe/London"); > > Nit: No need to use `TimeZone.getTimeZone()` here (and later convert them to `toZoneId()`). `ZoneId.of()` should suffice. It was somewhat intentional to do it like way in this microbenchmark experiment to check that the `toZoneId()` doesn't cause surprises and ideally that it doesn't cost anything. ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From redestad at openjdk.java.net Fri Mar 25 22:41:58 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Fri, 25 Mar 2022 22:41:58 GMT Subject: Integrated: 8283681: Improve ZonedDateTime offset handling In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 12:28:58 GMT, Claes Redestad wrote: > Richard Startin prompted me to have a look at a case where java.time underperforms relative to joda time (https://twitter.com/richardstartin/status/1506975932271190017). > > It seems the java.time test of his suffer from heavy allocations due ZoneOffset::getRules allocating a new ZoneRules object every time and escape analysis failing to do the thing in his test. The patch here adds a simple specialization so that when creating ZonedDateTimes using a ZoneOffset we don't query the rules at all. This removes the risk of extra allocations and slightly speeds up ZonedDateTime creation for both ZoneOffset (+14%) and ZoneRegion (+5%) even when EA works like it should (the case in the here provided microbenchmark). This pull request has now been integrated. Changeset: 7bac0a87 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/7bac0a878d918745ed036954cbbee590ce810c71 Stats: 156 lines in 5 files changed: 152 ins; 0 del; 4 mod 8283681: Improve ZonedDateTime offset handling Reviewed-by: scolebourne, naoto, rriggs ------------- PR: https://git.openjdk.java.net/jdk/pull/7957 From naoto at openjdk.java.net Fri Mar 25 22:51:23 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Fri, 25 Mar 2022 22:51:23 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v3] In-Reply-To: References: Message-ID: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed a build failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7947/files - new: https://git.openjdk.java.net/jdk/pull/7947/files/e874ff7e..b4d040af Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From darcy at openjdk.java.net Fri Mar 25 23:33:48 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 25 Mar 2022 23:33:48 GMT Subject: RFR: JDK-8283668: Update IllegalFormatException to use sealed classes In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time IllegalFormatException. > > Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8283669 > _Mailing list message from [Alan Bateman](mailto:Alan.Bateman at oracle.com) on [core-libs-dev](mailto:core-libs-dev at mail.openjdk.java.net):_ > > On 25/03/2022 09:37, Bernd Eckenfels wrote: > > > I wonder should the CSR not describe what?s the advantage of this change is and what the compatibility problems are and why they don?t apply here? Especially given the fact that the specific sub exceptions are not sealed I wonder if the risk of breaking existing code is worth it? (But I do see the beauty of such a construct for new code!) > > IllegalFormatException does not have any accessible constructors so can't extended by classes outside of the java.util packages. So I think the only compatibility risk is doing something off label with deserialization to create sub-classes. > > -Alan Right; the general user "interface" in question is "this class cannot be extended outside of the JDK." Altering the way that property is implemented, no accessible constructor or being declared sealed, etc. is considered a compatible change. -Joe ------------- PR: https://git.openjdk.java.net/jdk/pull/7950 From darcy at openjdk.java.net Fri Mar 25 23:33:48 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Fri, 25 Mar 2022 23:33:48 GMT Subject: Integrated: JDK-8283668: Update IllegalFormatException to use sealed classes In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 04:17:57 GMT, Joe Darcy wrote: > Working down the list of candidates to be sealed, this time IllegalFormatException. > > Please also review the companion CSR: https://bugs.openjdk.java.net/browse/JDK-8283669 This pull request has now been integrated. Changeset: f520b4f8 Author: Joe Darcy URL: https://git.openjdk.java.net/jdk/commit/f520b4f891b71c630bc13f5db4f305194ef227e5 Stats: 38 lines in 13 files changed: 12 ins; 0 del; 26 mod 8283668: Update IllegalFormatException to use sealed classes Reviewed-by: iris, jpai ------------- PR: https://git.openjdk.java.net/jdk/pull/7950 From smarks at openjdk.java.net Sat Mar 26 00:22:36 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Sat, 26 Mar 2022 00:22:36 GMT Subject: RFR: 8283683: Make ThreadLocalRandom a final class In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. > > tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. LGTM ------------- Marked as reviewed by smarks (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7958 From chegar at openjdk.java.net Sat Mar 26 10:44:45 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Sat, 26 Mar 2022 10:44:45 GMT Subject: RFR: 8283683: Make ThreadLocalRandom a final class In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. > > tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. LGTM. ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7958 From chegar at openjdk.java.net Sat Mar 26 10:58:44 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Sat, 26 Mar 2022 10:58:44 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: References: Message-ID: <8vSPui0B7okCUb_-haCOqdn_dvc7fFrqRBZMuFLMYcM=.c8a0ee01-4cf0-4e76-8e23-608b4739b3ab@github.com> On Thu, 24 Mar 2022 17:43:31 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - update jmh > - refine javadoc; refine implement when expectedSize < 0 This is a very nice addition. In Elasticsearch we have such API points, which are tedious to get right and test. src/java.base/share/classes/java/util/HashMap.java line 2584: > 2582: > 2583: /** > 2584: * Creates a new, empty HashMap with an initial table size You probably wanna allow for a non-NEW instance for the corner case where the given size is 0 - no elements. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From lancea at openjdk.java.net Sat Mar 26 11:33:44 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Sat, 26 Mar 2022 11:33:44 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v3] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 22:51:23 GMT, Naoto Sato wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a build failure Hi Naoto, I think the changes look good. One suggestion As part of the PR, we should probably update test/jdk/java/util/Locale/LocaleTest.java. or perhaps add a new test for Locale.of() for completeness. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From duke at openjdk.java.net Sat Mar 26 12:17:44 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sat, 26 Mar 2022 12:17:44 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: <8vSPui0B7okCUb_-haCOqdn_dvc7fFrqRBZMuFLMYcM=.c8a0ee01-4cf0-4e76-8e23-608b4739b3ab@github.com> References: <8vSPui0B7okCUb_-haCOqdn_dvc7fFrqRBZMuFLMYcM=.c8a0ee01-4cf0-4e76-8e23-608b4739b3ab@github.com> Message-ID: <9xOIzpVfoi4tu05CHaap0g5c-Evd_vGTl-3LQrqHFLQ=.95d68d62-9211-4986-925a-b4eda60e22c6@github.com> On Sat, 26 Mar 2022 10:53:05 GMT, Chris Hegarty wrote: > You probably wanna allow for a non-NEW instance for the corner case where the given size is 0 - no elements. @ChrisHegarty I guess we shouldn't. I want to make it 100% equals to `new HashMap()` constructor, thus migrate all usecases. So if we apply this, and when the original usage use this map object as a lock, or put some elements after the call(sometimes people cannot decide if they would really put elements in this map), bad things would happen. Besides, there already a function` Map.of()` for such functionality, so programmer should use that instead if they really want a shared empty map. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Sat Mar 26 12:54:42 2022 From: duke at openjdk.java.net (liach) Date: Sat, 26 Mar 2022 12:54:42 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: <9xOIzpVfoi4tu05CHaap0g5c-Evd_vGTl-3LQrqHFLQ=.95d68d62-9211-4986-925a-b4eda60e22c6@github.com> References: <8vSPui0B7okCUb_-haCOqdn_dvc7fFrqRBZMuFLMYcM=.c8a0ee01-4cf0-4e76-8e23-608b4739b3ab@github.com> <9xOIzpVfoi4tu05CHaap0g5c-Evd_vGTl-3LQrqHFLQ=.95d68d62-9211-4986-925a-b4eda60e22c6@github.com> Message-ID: <188eCep4oPiJnnfdyhQSMhhrTTa6HWlAS3hpthkAqcE=.5182c71b-1616-43bb-92f0-4193dce830af@github.com> On Sat, 26 Mar 2022 12:14:25 GMT, XenoAmess wrote: >> src/java.base/share/classes/java/util/HashMap.java line 2584: >> >>> 2582: >>> 2583: /** >>> 2584: * Creates a new, empty HashMap with an initial table size >> >> You probably wanna allow for a non-NEW instance for the corner case where the given size is 0 - no elements. > >> You probably wanna allow for a non-NEW instance for the corner case where the given size is 0 - no elements. > > @ChrisHegarty I guess we shouldn't. > > I want to make it 100% equals to `new HashMap()` constructor, thus migrate all usecases. > > So if we apply this, and when the original usage use this map object as a lock, or put some elements after the call(sometimes people cannot decide if they would really put elements in this map), bad things would happen. > > Besides, there already a function` Map.of()` for such functionality, so programmer should use that instead if they really want a shared empty map. hash maps are modifiable. empty instances can be changed, and returning such shared instances are inherently unsafe. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From dcubed at openjdk.java.net Sat Mar 26 13:13:11 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 26 Mar 2022 13:13:11 GMT Subject: RFR: 8283720: ProblemList java/time/test/java/time/TestZoneOffset.java Message-ID: A trivial fix to ProblemList java/time/test/java/time/TestZoneOffset.java. ------------- Commit messages: - 8283720: ProblemList java/time/test/java/time/TestZoneOffset.java Changes: https://git.openjdk.java.net/jdk/pull/7970/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7970&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283720 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7970.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7970/head:pull/7970 PR: https://git.openjdk.java.net/jdk/pull/7970 From alanb at openjdk.java.net Sat Mar 26 13:28:48 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Sat, 26 Mar 2022 13:28:48 GMT Subject: RFR: 8283720: ProblemList java/time/test/java/time/TestZoneOffset.java In-Reply-To: References: Message-ID: On Sat, 26 Mar 2022 13:04:33 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/time/test/java/time/TestZoneOffset.java. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7970 From dcubed at openjdk.java.net Sat Mar 26 13:34:50 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 26 Mar 2022 13:34:50 GMT Subject: Integrated: 8283720: ProblemList java/time/test/java/time/TestZoneOffset.java In-Reply-To: References: Message-ID: <3V6sOmgnrtvl0UkHYfQc32MjL0c4B4nEJmmr06I7zcU=.f18954c6-bbe6-41fd-81c2-f7ab9773d714@github.com> On Sat, 26 Mar 2022 13:04:33 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/time/test/java/time/TestZoneOffset.java. This pull request has now been integrated. Changeset: c587b29b Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/c587b29bc9ca7e6d3879fda7df099b7411624f19 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8283720: ProblemList java/time/test/java/time/TestZoneOffset.java Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7970 From dcubed at openjdk.java.net Sat Mar 26 13:34:49 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 26 Mar 2022 13:34:49 GMT Subject: RFR: 8283720: ProblemList java/time/test/java/time/TestZoneOffset.java In-Reply-To: References: Message-ID: On Sat, 26 Mar 2022 13:25:00 GMT, Alan Bateman wrote: >> A trivial fix to ProblemList java/time/test/java/time/TestZoneOffset.java. > > Marked as reviewed by alanb (Reviewer). @AlanBateman - Thanks for the fast review! Especially for a Saturday... ------------- PR: https://git.openjdk.java.net/jdk/pull/7970 From duke at openjdk.java.net Sat Mar 26 16:38:41 2022 From: duke at openjdk.java.net (liach) Date: Sat, 26 Mar 2022 16:38:41 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3] In-Reply-To: References: Message-ID: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com> On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType Just curious, this issue asks to replace set constructions with `Set.of`, but there is no such code changes in this pull request. Is there any set creation patterns that aren't detected by your ide cleanups, such as `Collections.addAll(set, elements)` for creating hash set contents from array? ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From darcy at openjdk.java.net Sat Mar 26 17:58:49 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Sat, 26 Mar 2022 17:58:49 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks Independent of performance improvements, the proposed changes may be tolerable from a code maintenance point of view, but I think VM intrinsics would be a better fit here. If the Java-level changes are kept, I think a short comment to explain the intent of the loop would be appropriate; e.g. something like // unroll (31 * h + (v & 0xff)) recurrence; constants are 31^k in in arithmetic ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From duke at openjdk.java.net Sat Mar 26 19:27:40 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Sat, 26 Mar 2022 19:27:40 GMT Subject: RFR: 8282662: Use List/Set.of() factory methods to reduce memory consumption [v3] In-Reply-To: References: Message-ID: On Thu, 10 Mar 2022 08:52:17 GMT, ?????? ??????? wrote: >> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2. >> >> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time): >> - `MethodHandles.longestParameterList()` never returns null >> - parameter types are never null >> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null >> - exceptions types of method signature are never null > > ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: > > 8282662: Revert dubious changes in MethodType There were changes with `Set.of()`, but I've reverted them as dubious. I'll rename the ticket and PR's title. As of the second question I didn't look namely for `Collections.addAll(set, elements)`, if I find any feasible for replacement with `Set.of()` then I'll add it. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From djelinski at openjdk.java.net Sat Mar 26 20:29:48 2022 From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Sat, 26 Mar 2022 20:29:48 GMT Subject: RFR: 8282429: StringBuilder/StringBuffer.toString() skip compressing for UTF16 strings [v5] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 00:35:14 GMT, Xin Liu wrote: >> If AbstractStringBuilder only grow, the inflated value which has been encoded in UTF16 can't be compressed. >> toString() can skip compression in this case. This can save an ArrayAllocation in StringUTF16::compress(). >> >> java.io.BufferedRead::readLine() is a case that StringBuilder grows only. >> >> In microbench, we expect to see that allocation/op reduces 20%. The initial capacity of StringBuilder is S in bytes. When it encounters the 1st character that can't be encoded in LATIN1, it inflates and allocate a new array of 2*S. `toString()` will try to compress that value so it need to allocate S bytes. The last step allocates 2*S bytes because it has to copy the string. so it requires to allocate 5 * S bytes in total. By skipping the failed compression, it only allocates 4 * S bytes. that's 20%. In real execution, we observe 16% allocation reduction, tracked by JMH GC profiler `gc.alloc.rate.norm `. I think it's because HotSpot can't track all allocations. >> >> Not only allocation drops, the runtime performance(ns/op) also increases from 3.34% to 18.91%. >> >> Before: >> >> $$make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o before.log -jvm $HOME/Devel/jdk_baseline/bin/java" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 649.846 ? 76.291 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 872.855 ? 128.259 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 880.121 ? 0.050 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 707.730 ? 194.421 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 706.602 ? 94.504 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 0.001 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 0.001 ? 0.001 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 113.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 85.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1316.652 ? 112.771 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 800.864 ? 76.869 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1648.288 ? 0.162 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 599.736 ? 174.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1229.669 ? 318.518 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.001 ? 0.001 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.001 ? 0.002 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 133.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 92.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 5204.303 ? 418.115 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 768.730 ? 72.945 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 6256.844 ? 0.358 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 655.852 ? 121.602 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 5315.265 ? 578.878 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.014 ? 0.011 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 96.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 86.000 ms >> >> >> After >> >> $make test TEST="micro:org.openjdk.bench.java.lang.StringBuilders.toStringWithMixedChars" MICRO="OPTIONS=-prof gc -gc true -o after.log" >> >> Benchmark (MIXED_SIZE) Mode Cnt Score Error Units >> StringBuilders.toStringWithMixedChars 128 avgt 15 627.522 ? 54.804 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 128 avgt 15 751.353 ? 83.478 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 128 avgt 15 736.120 ? 0.062 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 128 avgt 15 589.102 ? 164.083 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 128 avgt 15 575.425 ? 127.021 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 128 avgt 15 ? 10?? MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 128 avgt 15 ? 10?? B/op >> StringBuilders.toStringWithMixedChars:?gc.count 128 avgt 15 116.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 128 avgt 15 86.000 ms >> StringBuilders.toStringWithMixedChars 256 avgt 15 1185.884 ? 137.364 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 256 avgt 15 746.179 ? 92.534 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 256 avgt 15 1376.244 ? 0.125 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 256 avgt 15 579.137 ? 208.636 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 256 avgt 15 1055.150 ? 307.010 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 256 avgt 15 0.002 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 256 avgt 15 0.003 ? 0.003 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 256 avgt 15 126.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 256 avgt 15 97.000 ms >> StringBuilders.toStringWithMixedChars 1024 avgt 15 4220.415 ? 440.169 ns/op >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate 1024 avgt 15 791.945 ? 75.231 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.alloc.rate.norm 1024 avgt 15 5217.435 ? 0.543 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space 1024 avgt 15 657.270 ? 235.803 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Eden_Space.norm 1024 avgt 15 4232.470 ? 1267.388 B/op >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space 1024 avgt 15 0.005 ? 0.002 MB/sec >> StringBuilders.toStringWithMixedChars:?gc.churn.G1_Survivor_Space.norm 1024 avgt 15 0.033 ? 0.014 B/op >> StringBuilders.toStringWithMixedChars:?gc.count 1024 avgt 15 202.000 counts >> StringBuilders.toStringWithMixedChars:?gc.time 1024 avgt 15 121.000 ms > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > rewording the comment of 'maybeLatin1'. LGTM ------------- Marked as reviewed by djelinski (Committer). PR: https://git.openjdk.java.net/jdk/pull/7671 From chegar at openjdk.java.net Sat Mar 26 20:35:46 2022 From: chegar at openjdk.java.net (Chris Hegarty) Date: Sat, 26 Mar 2022 20:35:46 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: <188eCep4oPiJnnfdyhQSMhhrTTa6HWlAS3hpthkAqcE=.5182c71b-1616-43bb-92f0-4193dce830af@github.com> References: <8vSPui0B7okCUb_-haCOqdn_dvc7fFrqRBZMuFLMYcM=.c8a0ee01-4cf0-4e76-8e23-608b4739b3ab@github.com> <9xOIzpVfoi4tu05CHaap0g5c-Evd_vGTl-3LQrqHFLQ=.95d68d62-9211-4986-925a-b4eda60e22c6@github.com> <188eCep4oPiJnnfdyhQSMhhrTTa6HWlAS3hpthkAqcE=.5182c71b-1616-43bb-92f0-4193dce830af@github.com> Message-ID: <7maJ4O6FjyUiWACVQjvUydhce6sRvsQDsVoi6G3cp6w=.ed38a707-9f4e-4ab1-8f2f-1853f1dbf7ee@github.com> On Sat, 26 Mar 2022 12:51:04 GMT, liach wrote: >>> You probably wanna allow for a non-NEW instance for the corner case where the given size is 0 - no elements. >> >> @ChrisHegarty I guess we shouldn't. >> >> I want to make it 100% equals to `new HashMap()` constructor, thus migrate all usecases. >> >> So if we apply this, and when the original usage use this map object as a lock, or put some elements after the call(sometimes people cannot decide if they would really put elements in this map), bad things would happen. >> >> Besides, there already a function` Map.of()` for such functionality, so programmer should use that instead if they really want a shared empty map. > > hash maps are modifiable. empty instances can be changed, and returning such shared instances are inherently unsafe. Yeah, sorry. Ignore my comment, I was wrong. I completely agree with your reasoning. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Sun Mar 27 04:41:43 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 27 Mar 2022 04:41:43 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 17:43:31 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - update jmh > - refine javadoc; refine implement when expectedSize < 0 > /csr @ChrisHegarty @liach Hi. actually I don't know how to create a CSR request. I have no account on your internal jira. So I write an email to `csr-discuss at openjdk.java.net` , but no response. If there be anything more I should do now, please just tell me. Thanks a lot. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From smarks at openjdk.java.net Sun Mar 27 05:02:53 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Sun, 27 Mar 2022 05:02:53 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 17:43:31 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - update jmh > - refine javadoc; refine implement when expectedSize < 0 I'll sponsor this PR, and I can create a CSR as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Sun Mar 27 08:43:40 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sun, 27 Mar 2022 08:43:40 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks The?`(length &?~(8?-?1))` computation should?probably be?moved outside?of the?loop. src/java.base/share/classes/java/lang/StringLatin1.java line 195: > 193: int i = 0; > 194: int length = value.length; > 195: for (; i < (length & ~(8 - 1)); i += 8) { Suggestion: for (int end = (length & ~(8 - 1)); i < end; i += 8) { src/java.base/share/classes/java/lang/StringUTF16.java line 418: > 416: int i = 0; > 417: int length = value.length >> 1; > 418: for (; i < (length & ~(8 - 1)); i += 8) { Suggestion: for (int end = (length & ~(8 - 1)); i < end; i += 8) { ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From duke at openjdk.java.net Sun Mar 27 08:50:49 2022 From: duke at openjdk.java.net (XenoAmess) Date: Sun, 27 Mar 2022 08:50:49 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: References: Message-ID: <6lZDU1Ax-DoXXnrl1tyTUoBnQTkDQ08KlDudCM2gBg0=.24e003ab-dc58-447d-a029-a95e324e1704@github.com> On Thu, 24 Mar 2022 17:43:31 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - update jmh > - refine javadoc; refine implement when expectedSize < 0 So I myself think, the functions looks good now. The first step, to make such functions, seems completed. Should we go into the next step now, means to change some usage to these functions in java.base? ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Sun Mar 27 08:51:41 2022 From: duke at openjdk.java.net (ExE Boss) Date: Sun, 27 Mar 2022 08:51:41 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v3] In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 22:51:23 GMT, Naoto Sato wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Fixed a build failure src/java.base/share/classes/java/util/Locale.java line 819: > 817: * @since 19 > 818: */ > 819: public static Locale of(String... fields) { Arguably, there?should?be `Locale.of`?overloads taking?0 to?4?arguments, so?that it?s?not?necessary to?box the?fields in?a?`String`?array. src/java.base/share/classes/java/util/Locale.java line 825: > 823: case 2 -> getInstance(fields[0], "", fields[1], "", null); > 824: case 3 -> getInstance(fields[0], "", fields[1], fields[2], null); > 825: default -> getInstance(fields[0], fields[3], fields[1], fields[2], null); This?should probably?throw `IllegalArgumentException` when?more?than 4?fields are?passed: Suggestion: case 4 -> getInstance(fields[0], fields[3], fields[1], fields[2], null); default -> throw new IllegalArgumentException(/* TODO: message */); ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From duke at openjdk.java.net Mon Mar 28 05:32:20 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Mon, 28 Mar 2022 05:32:20 GMT Subject: RFR: 8283726: x86 intrinsics for compare method in Integer and Long Message-ID: Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long. ------------- Commit messages: - add JMH benchmarks - 8283726: x86 intrinsics for compare method in Integer and Long Changes: https://git.openjdk.java.net/jdk/pull/7975/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7975&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283726 Stats: 430 lines in 13 files changed: 428 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7975.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7975/head:pull/7975 PR: https://git.openjdk.java.net/jdk/pull/7975 From duke at openjdk.java.net Mon Mar 28 05:32:20 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Mon, 28 Mar 2022 05:32:20 GMT Subject: RFR: 8283726: x86 intrinsics for compare method in Integer and Long In-Reply-To: References: Message-ID: On Sun, 27 Mar 2022 06:15:34 GMT, Vamsi Parasa wrote: > Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long. This is both complicated and inefficient, I would suggest building the intrinsic in the IR graph so that the compiler can simplify `Integer.compareUnsigned(x, y) < 0` into `x u< y`. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7975 From jiefu at openjdk.java.net Mon Mar 28 07:49:49 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 28 Mar 2022 07:49:49 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API [v2] In-Reply-To: References: Message-ID: On Mon, 21 Mar 2022 01:19:57 GMT, Xiaohong Gong wrote: > The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files. > > > Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector? > > From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short. Thanks! There seems no vectorized negation instructions for {byte, short, int, long} on x86, so this should be fine on x86. I tested the patch on x86 and the performance number looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From xgong at openjdk.java.net Mon Mar 28 07:49:49 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 28 Mar 2022 07:49:49 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API [v2] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 07:40:48 GMT, Jie Fu wrote: >> The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files. >> >>> Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector? >> >> From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short. Thanks! > >> The compiler can get the real type info from `Op_NegVI` that can also handle the `BYTE ` and `SHORT ` basic type. I just don't want to add more new IRs which also need more match rules in the ad files. >> >> > Is there any performance drop for byte/short negation operation if both of them are handled as a NegVI vector? >> >> From the benchmark results I showed in the commit message, I didn't see not any performance drop for byte/short. Thanks! > > There seems no vectorized negation instructions for {byte, short, int, long} on x86, so this should be fine on x86. > I tested the patch on x86 and the performance number looks good. Thanks for doing this! Yeah, I think the performance for masked negation operations might improve on non avx-512 systems. ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From jiefu at openjdk.java.net Mon Mar 28 07:49:50 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 28 Mar 2022 07:49:50 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API [v2] In-Reply-To: References: Message-ID: On Tue, 22 Mar 2022 09:58:23 GMT, Xiaohong Gong wrote: >> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. >> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. >> >> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: >> - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. >> - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. >> >> So with this patch, the following transformations are applied: >> >> For non-masked negation with NEON: >> >> movi v16.4s, #0x0 >> sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s >> >> and with SVE: >> >> mov z16.s, #0 >> sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s >> >> For masked negation with NEON: >> >> movi v17.4s, #0x1 >> mvn v19.16b, v18.16b >> mov v20.16b, v16.16b ==> neg v18.4s, v17.4s >> bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b >> add v19.4s, v20.4s, v17.4s >> mov v18.16b, v16.16b >> bsl v18.16b, v19.16b, v20.16b >> >> and with SVE: >> >> mov z16.s, #-1 >> mov z17.s, #1 ==> neg z16.s, p0/m, z16.s >> eor z18.s, p0/m, z18.s, z16.s >> add z18.s, p0/m, z18.s, z17.s >> >> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): >> >> NEON: >> Benchmark Gain >> Byte128Vector.NEG 1.029 >> Byte128Vector.NEGMasked 1.757 >> Short128Vector.NEG 1.041 >> Short128Vector.NEGMasked 1.659 >> Int128Vector.NEG 1.005 >> Int128Vector.NEGMasked 1.513 >> Long128Vector.NEG 1.003 >> Long128Vector.NEGMasked 1.878 >> >> SVE with 512-bits: >> Benchmark Gain >> ByteMaxVector.NEG 1.10 >> ByteMaxVector.NEGMasked 1.165 >> ShortMaxVector.NEG 1.056 >> ShortMaxVector.NEGMasked 1.195 >> IntMaxVector.NEG 1.002 >> IntMaxVector.NEGMasked 1.239 >> LongMaxVector.NEG 1.031 >> LongMaxVector.NEGMasked 1.191 >> >> X86 (non AVX-512): >> Benchmark Gain >> ByteMaxVector.NEGMasked 1.254 >> ShortMaxVector.NEGMasked 1.359 >> IntMaxVector.NEGMasked 1.431 >> LongMaxVector.NEGMasked 1.989 >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Add a superclass for vector negation src/hotspot/share/opto/vectornode.cpp line 1592: > 1590: > 1591: // Generate other vector nodes to implement the masked/non-masked vector negation. > 1592: Node* VectorNode::degenerate_vector_integral_negate(Node* n, int vlen, BasicType bt, PhaseGVN* phase, bool is_predicated) { Shall we move this declaration in `class NegVNode` since it is only used by NegVNode::Ideal ? ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From xgong at openjdk.java.net Mon Mar 28 07:49:50 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 28 Mar 2022 07:49:50 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API [v2] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 07:43:29 GMT, Jie Fu wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a superclass for vector negation > > src/hotspot/share/opto/vectornode.cpp line 1592: > >> 1590: >> 1591: // Generate other vector nodes to implement the masked/non-masked vector negation. >> 1592: Node* VectorNode::degenerate_vector_integral_negate(Node* n, int vlen, BasicType bt, PhaseGVN* phase, bool is_predicated) { > > Shall we move this declaration in `class NegVNode` since it is only used by NegVNode::Ideal ? I think it can be. Thanks for pointing out this. I will change this later. ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From jiefu at openjdk.java.net Mon Mar 28 08:03:50 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Mon, 28 Mar 2022 08:03:50 GMT Subject: RFR: 8282162: [vector] Optimize vector negation API In-Reply-To: References: <-E5E_NBci6gsGyOV5nWuTUNKLVnjiw2IiWjjgv2vFz0=.ebe7c447-ede9-4437-815c-a2004f9d6ce1@github.com> Message-ID: <4Ecgum5Cb8oDUN02LIkOsU_3tYOLXASEq1znc3JhT28=.d69bc461-d84c-405a-9aad-945b04ca1a1e@github.com> On Tue, 15 Mar 2022 02:47:20 GMT, Xiaohong Gong wrote: > > Note that in terms of Java semantics, negation of floating point values needs to be implemented as subtraction from negative zero rather than positive zero: > > double negate(double arg) {return -0.0 - arg; } > > This is to handle signed zeros correctly. > > Hi @jddarcy ,thanks for looking at this PR and thanks for the notes on the floating point negation! Yeah, this really makes sense to me. Kindly note that this patch didn't touch the negation of the floating point values. For Vector API, the vector floating point negation has been intrinsified to `NegVF/D` node by compiler that we directly generate the negation instructions for them. Thanks! I would suggest changing the JBS title like `[vector] Optimize non-floating vector negation API` . ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From Alan.Bateman at oracle.com Mon Mar 28 08:53:30 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Mar 2022 09:53:30 +0100 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: <3e79090c-906e-6e89-31fa-9258cfdf830b@oracle.com> Message-ID: <3253df5a-c294-18c8-3e2b-46072c9a4501@oracle.com> On 22/03/2022 12:28, Volker Simonis wrote: > : > I don't really understand this concern? Do you mean what happens if > another thread is changing the content of the output buffer during an > inflate? I think such a use case has never been well-defined and > amending the specification won't change anything for such a situation. The setup means that user code has access to temporary storage used by the inflater library. It's important that nothing sensitive leaks, also important that flipping bits in any of the bytes in that temporary buffer doesn't lead to something that is considered a security issue. If you are confident that nothing bad can happen they great, I'm just pointing out things to consider when allow for the behavior discussed here. -Alan From luhenry at openjdk.java.net Mon Mar 28 09:08:43 2022 From: luhenry at openjdk.java.net (Ludovic Henry) Date: Mon, 28 Mar 2022 09:08:43 GMT Subject: RFR: 8282664: Unroll by hand StringUTF16 and StringLatin1 polynomial hash loops [v2] In-Reply-To: References: Message-ID: On Fri, 4 Mar 2022 17:44:44 GMT, Ludovic Henry wrote: >> Despite the hash value being cached for Strings, computing the hash still represents a significant CPU usage for applications handling lots of text. >> >> Even though it would be generally better to do it through an enhancement to the autovectorizer, the complexity of doing it by hand is trivial and the gain is sizable (2x speedup) even without the Vector API. The algorithm has been proposed by Richard Startin and Paul Sandoz [1]. >> >> Speedup are as follows on a `Intel(R) Xeon(R) E-2276G CPU @ 3.80GHz` >> >> >> Benchmark (size) Mode Cnt Score Error Units >> StringHashCode.Algorithm.scalarLatin1 0 avgt 25 2.111 ? 0.210 ns/op >> StringHashCode.Algorithm.scalarLatin1 1 avgt 25 3.500 ? 0.127 ns/op >> StringHashCode.Algorithm.scalarLatin1 10 avgt 25 7.001 ? 0.099 ns/op >> StringHashCode.Algorithm.scalarLatin1 100 avgt 25 61.285 ? 0.444 ns/op >> StringHashCode.Algorithm.scalarLatin1 1000 avgt 25 628.995 ? 0.846 ns/op >> StringHashCode.Algorithm.scalarLatin1 10000 avgt 25 6307.990 ? 4.071 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 0 avgt 25 2.358 ? 0.092 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1 avgt 25 3.631 ? 0.159 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10 avgt 25 7.049 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 100 avgt 25 33.626 ? 1.218 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 1000 avgt 25 317.811 ? 1.225 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled16 10000 avgt 25 3212.333 ? 14.621 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 0 avgt 25 2.356 ? 0.097 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1 avgt 25 3.630 ? 0.158 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10 avgt 25 8.724 ? 0.065 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 100 avgt 25 32.402 ? 0.019 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 1000 avgt 25 321.949 ? 0.251 ns/op >> StringHashCode.Algorithm.scalarLatin1Unrolled8 10000 avgt 25 3202.083 ? 1.667 ns/op >> StringHashCode.Algorithm.scalarUTF16 0 avgt 25 2.135 ? 0.191 ns/op >> StringHashCode.Algorithm.scalarUTF16 1 avgt 25 5.202 ? 0.362 ns/op >> StringHashCode.Algorithm.scalarUTF16 10 avgt 25 11.105 ? 0.112 ns/op >> StringHashCode.Algorithm.scalarUTF16 100 avgt 25 75.974 ? 0.702 ns/op >> StringHashCode.Algorithm.scalarUTF16 1000 avgt 25 716.429 ? 3.290 ns/op >> StringHashCode.Algorithm.scalarUTF16 10000 avgt 25 7095.459 ? 43.847 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 0 avgt 25 2.381 ? 0.038 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1 avgt 25 5.268 ? 0.422 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10 avgt 25 11.248 ? 0.178 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 100 avgt 25 52.966 ? 0.089 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 1000 avgt 25 450.912 ? 1.834 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled16 10000 avgt 25 4403.988 ? 2.927 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 0 avgt 25 2.401 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1 avgt 25 5.091 ? 0.396 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10 avgt 25 12.801 ? 0.189 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 100 avgt 25 52.068 ? 0.032 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 1000 avgt 25 453.270 ? 0.340 ns/op >> StringHashCode.Algorithm.scalarUTF16Unrolled8 10000 avgt 25 4433.112 ? 2.699 ns/op >> >> >> At Datadog, we handle a great amount of text (through logs management for example), and hashing String represents a large part of our CPU usage. It's very unlikely that we are the only one as String.hashCode is such a core feature of the JVM-based languages with its use in HashMap for example. Having even only a 2x speedup would allow us to save thousands of CPU cores per month and improve correspondingly the energy/carbon impact. >> >> [1] https://static.rainfocus.com/oracle/oow18/sess/1525822677955001tLqU/PF/codeone18-vector-API-DEV5081_1540354883936001Q3Sv.pdf > > Ludovic Henry has updated the pull request incrementally with one additional commit since the last revision: > > Add UTF-16 benchmarks I'm currently working on the vectorized intrinsic. It's taking more time due to end of quarter activities but I'm getting around to it :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7700 From simonis at openjdk.java.net Mon Mar 28 09:46:07 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 28 Mar 2022 09:46:07 GMT Subject: RFR: 8283758: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) Message-ID: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. ### TL;DR `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`*k* `]` (where *k* is the number of inflated bytes). >From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). ------------- Commit messages: - 8283758: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) Changes: https://git.openjdk.java.net/jdk/pull/7986/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283758 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7986.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986 PR: https://git.openjdk.java.net/jdk/pull/7986 From xgong at openjdk.java.net Mon Mar 28 09:56:22 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Mon, 28 Mar 2022 09:56:22 GMT Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3] In-Reply-To: References: Message-ID: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> > The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. > And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. > > To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: > - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. > - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. > > So with this patch, the following transformations are applied: > > For non-masked negation with NEON: > > movi v16.4s, #0x0 > sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s > > and with SVE: > > mov z16.s, #0 > sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s > > For masked negation with NEON: > > movi v17.4s, #0x1 > mvn v19.16b, v18.16b > mov v20.16b, v16.16b ==> neg v18.4s, v17.4s > bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b > add v19.4s, v20.4s, v17.4s > mov v18.16b, v16.16b > bsl v18.16b, v19.16b, v20.16b > > and with SVE: > > mov z16.s, #-1 > mov z17.s, #1 ==> neg z16.s, p0/m, z16.s > eor z18.s, p0/m, z18.s, z16.s > add z18.s, p0/m, z18.s, z17.s > > Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): > > NEON: > Benchmark Gain > Byte128Vector.NEG 1.029 > Byte128Vector.NEGMasked 1.757 > Short128Vector.NEG 1.041 > Short128Vector.NEGMasked 1.659 > Int128Vector.NEG 1.005 > Int128Vector.NEGMasked 1.513 > Long128Vector.NEG 1.003 > Long128Vector.NEGMasked 1.878 > > SVE with 512-bits: > Benchmark Gain > ByteMaxVector.NEG 1.10 > ByteMaxVector.NEGMasked 1.165 > ShortMaxVector.NEG 1.056 > ShortMaxVector.NEGMasked 1.195 > IntMaxVector.NEG 1.002 > IntMaxVector.NEGMasked 1.239 > LongMaxVector.NEG 1.031 > LongMaxVector.NEGMasked 1.191 > > X86 (non AVX-512): > Benchmark Gain > ByteMaxVector.NEGMasked 1.254 > ShortMaxVector.NEGMasked 1.359 > IntMaxVector.NEGMasked 1.431 > LongMaxVector.NEGMasked 1.989 > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: Make "degenerate_vector_integral_negate" to be "NegVI" private ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7782/files - new: https://git.openjdk.java.net/jdk/pull/7782/files/97c8119a..48f4d6be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7782&range=01-02 Stats: 15 lines in 2 files changed: 6 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7782.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7782/head:pull/7782 PR: https://git.openjdk.java.net/jdk/pull/7782 From volker.simonis at gmail.com Mon Mar 28 10:02:49 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Mar 2022 12:02:49 +0200 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: <3253df5a-c294-18c8-3e2b-46072c9a4501@oracle.com> References: <3e79090c-906e-6e89-31fa-9258cfdf830b@oracle.com> <3253df5a-c294-18c8-3e2b-46072c9a4501@oracle.com> Message-ID: On Mon, Mar 28, 2022 at 10:53 AM Alan Bateman wrote: > > On 22/03/2022 12:28, Volker Simonis wrote: > > : > > I don't really understand this concern? Do you mean what happens if > > another thread is changing the content of the output buffer during an > > inflate? I think such a use case has never been well-defined and > > amending the specification won't change anything for such a situation. > The setup means that user code has access to temporary storage used by > the inflater library. It's important that nothing sensitive leaks, also > important that flipping bits in any of the bytes in that temporary > buffer doesn't lead to something that is considered a security issue. If > you are confident that nothing bad can happen they great, I'm just > pointing out things to consider when allow for the behavior discussed here. As I wrote before, the extra data written into the output buffer isn't sensitive because it can only originate from the history buffer (aka "sliding window"). Also, this data is already exposed today if the `Inflater` class is being used stand-alone, because in contrast to `InflaterInputStream::read(..)`, `Inflater::inflate(..)` doesn't guarantee to leave the content beyond the last read byte unaffected. Finally, the referenced zlib-chromium implementation with the mentioned behavior is the default zlib implementation in on Android and Chrome browsers. I've created a pull request and an associated CSR for this issue under: https://github.com/openjdk/jdk/pull/7986 https://bugs.openjdk.java.net/browse/JDK-8283758 Finally I've also created a PR to fix the ZipFSOutputStreamTest mentioned in my initial mail: https://github.com/openjdk/jdk/pull/7984 Can you please kindly take a look and review? Thank you and best regards, Volker PS: just saw you've already approved https://github.com/openjdk/jdk/pull/7984 :) > > -Alan From lancea at openjdk.java.net Mon Mar 28 10:21:47 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 28 Mar 2022 10:21:47 GMT Subject: RFR: 8283758: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: On Mon, 28 Mar 2022 09:37:58 GMT, Volker Simonis wrote: > Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. > > The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. > > ### TL;DR > > `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. > > The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. > > The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. > > These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`* k*`]` (where *k* is the number of inflated bytes). > > From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). Hi Volker, I believe your PR should point to the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8282648) in the title, which references the CSR and not the CSR directly in the title. ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From redestad at openjdk.java.net Mon Mar 28 10:40:51 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 28 Mar 2022 10:40:51 GMT Subject: RFR: 8283774: TestZoneOffset::test_immutable should ignore ZoneOffset::rules Message-ID: - Add capability to ignore fields explicitly when checking for immutability of classes in java.time - Use this to avoid a test failure due the new `rules` cache in `ZoneOffset` - Remove `TestZoneOffset` from problem list. ------------- Commit messages: - TestZoneOffset::test_immutable should ignore ZoneOffset::rules Changes: https://git.openjdk.java.net/jdk/pull/7989/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7989&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283774 Stats: 12 lines in 3 files changed: 6 ins; 3 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/7989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7989/head:pull/7989 PR: https://git.openjdk.java.net/jdk/pull/7989 From simonis at openjdk.java.net Mon Mar 28 10:55:30 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 28 Mar 2022 10:55:30 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: > Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. > > The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. > > ### TL;DR > > `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. > > The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. > > The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. > > These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`* k*`]` (where *k* is the number of inflated bytes). > > From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). Volker Simonis 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: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7986/files - new: https://git.openjdk.java.net/jdk/pull/7986/files/128166ff..b55fc332 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7986.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986 PR: https://git.openjdk.java.net/jdk/pull/7986 From simonis at openjdk.java.net Mon Mar 28 10:55:31 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Mon, 28 Mar 2022 10:55:31 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: On Mon, 28 Mar 2022 10:18:32 GMT, Lance Andersen wrote: > Hi Volker, > > I believe your PR should point to the [JBS issue](https://bugs.openjdk.java.net/browse/JDK-8282648) in the title, which references the CSR and not the CSR directly in the title. Sorry, you're right of course :) ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From jpai at openjdk.java.net Mon Mar 28 11:10:48 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 28 Mar 2022 11:10:48 GMT Subject: RFR: 8283683: Make ThreadLocalRandom a final class In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. > > tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. Thank you everyone for the reviews of the PR and the CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7958 From jpai at openjdk.java.net Mon Mar 28 11:10:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 28 Mar 2022 11:10:49 GMT Subject: Integrated: 8283683: Make ThreadLocalRandom a final class In-Reply-To: References: Message-ID: On Fri, 25 Mar 2022 13:32:21 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which marks the `ThreadLocalRandom` class as `final`? Related JBS issue https://bugs.openjdk.java.net/browse/JDK-8283683. > > A CSR has been filed too https://bugs.openjdk.java.net/browse/JDK-8283688. > > tier1, tier2 and tier3 tests have been run with this change and no related failures have been noticed. This pull request has now been integrated. Changeset: 85672667 Author: Jaikiran Pai URL: https://git.openjdk.java.net/jdk/commit/8567266795cd1171f5b353d0e0813e7eeff319c2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8283683: Make ThreadLocalRandom a final class Reviewed-by: smarks, chegar ------------- PR: https://git.openjdk.java.net/jdk/pull/7958 From omikhaltcova at openjdk.java.net Mon Mar 28 11:47:41 2022 From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova) Date: Mon, 28 Mar 2022 11:47:41 GMT Subject: RFR: JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder [v2] In-Reply-To: References: Message-ID: <5oQ5rvx7Hp6ppvo1y8LJ28RnQ1J68ASo0Tj6GpfiQ2c=.47b86070-8d6c-40c7-b2c8-0874598083f3@github.com> On Tue, 15 Mar 2022 21:11:31 GMT, Roger Riggs wrote: >> Quoting related changes in https://bugs.openjdk.java.net/browse/JDK-8250568 modified the way that >> process builder recognized argument strings, causing some arguments to be doubly quoted and malformed. >> >> ProcessBuilder encodes command arguments in two ways, a looser legacy encoding >> and stricter encoding that prevents quotes from being misinterpreted. >> The system property jdk.lang.Process.allowAmbiguousCommands controls which is in effect. >> >> When the property is "true" or not set, arguments are inserted into the Windows command line >> with minimal changes. Arguments containing space or tab are quoted to prevent them being split. >> Arguments that start and end with double-quote are left alone. >> Some executables interpret a backslash before the final quote as an escape; if the argument >> contains first and last quotes, backslashes are ignored. >> >> When the allowAmbigousCommands property is `false`, care is taken to ensure that >> the final quote of an argument is the closing quote for the argument and is not >> interpreted as a literal quote by a preceding quote (or an odd number of quotes). >> >> The PR includes a test matrix of the cases where an argument with spaces and a final backslash >> is passed with each combination of `allowAmbiguousCommands = true and false`, >> launched executable, java, .cmd, and .vbs and when the argument is surrounded with double-quotes. >> >> The priority for allowAmbiguousCommands = false is that no argument is split or joined to another argument. >> In some cases, backslashes are doubled to prevent a double-quote from being interpreted incorrectly. >> The trailing backslash in an argument occurs rarely exception when the argument is a directory. >> In that case, the addition of trailing backslashes is benign when the string is used as a filesystem path. >> >> See also PR#7504, for background and a proposal. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactored ArgCheck test to be more readable and easier to maintain and backport @RogerRiggs when do you plan to merge this patch approximately? ------------- PR: https://git.openjdk.java.net/jdk/pull/7709 From redestad at openjdk.java.net Mon Mar 28 12:00:52 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Mon, 28 Mar 2022 12:00:52 GMT Subject: RFR: 8283781: Avoid allocating unused lastRulesCaches Message-ID: This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily. ------------- Commit messages: - Merge branch 'master' into lastRulesCache - Avoid allocating unused lastRulesCaches Changes: https://git.openjdk.java.net/jdk/pull/7990/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7990&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283781 Stats: 16 lines in 1 file changed: 9 ins; 2 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7990/head:pull/7990 PR: https://git.openjdk.java.net/jdk/pull/7990 From jlaskey at openjdk.java.net Mon Mar 28 12:48:20 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 28 Mar 2022 12:48:20 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v13] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update Carrier API ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/7f8de3b5..b74e204e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=11-12 Stats: 233 lines in 2 files changed: 73 ins; 108 del; 52 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Mon Mar 28 13:11:37 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 28 Mar 2022 13:11:37 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v14] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Update javadoc ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/b74e204e..c5d03e82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=12-13 Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From rriggs at openjdk.java.net Mon Mar 28 14:20:49 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Mar 2022 14:20:49 GMT Subject: RFR: 8283781: Avoid allocating unused lastRulesCaches In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote: > This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily. LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7990 From rriggs at openjdk.java.net Mon Mar 28 14:24:50 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Mar 2022 14:24:50 GMT Subject: RFR: JDK-8282008: Incorrect handling of quoted arguments in ProcessBuilder [v2] In-Reply-To: <5oQ5rvx7Hp6ppvo1y8LJ28RnQ1J68ASo0Tj6GpfiQ2c=.47b86070-8d6c-40c7-b2c8-0874598083f3@github.com> References: <5oQ5rvx7Hp6ppvo1y8LJ28RnQ1J68ASo0Tj6GpfiQ2c=.47b86070-8d6c-40c7-b2c8-0874598083f3@github.com> Message-ID: On Mon, 28 Mar 2022 11:44:56 GMT, Olga Mikhaltsova wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactored ArgCheck test to be more readable and easier to maintain and backport > > @RogerRiggs when do you plan to merge this patch approximately? @omikhaltsova Its taken more time than expected to get the reviews needed. Perhaps in a week or so. ------------- PR: https://git.openjdk.java.net/jdk/pull/7709 From rriggs at openjdk.java.net Mon Mar 28 14:25:46 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Mar 2022 14:25:46 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread [v2] In-Reply-To: References: Message-ID: <9u8qzbXIVoZUBjq3sOEuzXQCzg-IEhU7RMxvp2qsynY=.82573099-d5e3-4349-994a-fd2dc02b9e80@github.com> On Fri, 18 Mar 2022 15:23:27 GMT, Roger Riggs wrote: >> The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. >> The result is retention of the class loader. >> >> The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. >> The test verifies that the process reaper threads have a null context classloader. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Folded lines to reduce max line length @AlanBateman Please review and approve ------------- PR: https://git.openjdk.java.net/jdk/pull/7131 From jlaskey at openjdk.java.net Mon Mar 28 14:42:49 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 28 Mar 2022 14:42:49 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v14] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 13:11:37 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Update javadoc The API has been changed to ensure consistency between the constructor and components. A factory method `of(MethodType)` has been added that produces a `Carrier` instance that provides a consistent constructor and components unit. `of(Class...)` is also added, and `Carrier` instances are now cached. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From jpai at openjdk.java.net Mon Mar 28 15:04:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Mon, 28 Mar 2022 15:04:49 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: On Mon, 28 Mar 2022 10:55:30 GMT, Volker Simonis wrote: >> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. >> >> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. >> >> ### TL;DR >> >> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. >> >> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. >> >> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. >> >> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+` *k*`]` (where *k* is the number of inflated bytes). >> >> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). > > Volker Simonis 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: > > 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 133: > 131: * Unlike the {@link InputStream#read(byte[],int,int) overridden method} > 132: * of {@code InputStream}, this method might write more bytes than the returned > 133: * number of inflated bytes into the buffer {@code b}. Hello Volker, I think this comment should be a bit more clear and state what exactly it means by writing more bytes than the returned value. Specifically, I think it should clearly state that even though it might write additional data, it will however not write/change data starting and beyond `off + len` index in the passed array. ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From alanb at openjdk.java.net Mon Mar 28 15:05:41 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 28 Mar 2022 15:05:41 GMT Subject: RFR: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread [v2] In-Reply-To: References: Message-ID: <7qbJ_LtlTcFf2RLUktiRHOfPO-wPID-oicJEYD-nMmI=.56404a8e-8814-447b-a56f-867f78be188d@github.com> On Fri, 18 Mar 2022 15:23:27 GMT, Roger Riggs wrote: >> The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. >> The result is retention of the class loader. >> >> The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. >> The test verifies that the process reaper threads have a null context classloader. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Folded lines to reduce max line length Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7131 From rriggs at openjdk.java.net Mon Mar 28 15:48:49 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Mar 2022 15:48:49 GMT Subject: Integrated: 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 15:57:58 GMT, Roger Riggs wrote: > The thread factory used to create the process reaper threads unnecessarily inherits the callers thread context classloader. > The result is retention of the class loader. > > The thread factory used for the pool of process reaper threads is modified to use an InnocuousThread with a given stacksize. > The test verifies that the process reaper threads have a null context classloader. This pull request has now been integrated. Changeset: f0282d7d Author: Roger Riggs URL: https://git.openjdk.java.net/jdk/commit/f0282d7def8c043d95e9b86da926b7d45224c31c Stats: 109 lines in 3 files changed: 91 ins; 6 del; 12 mod 8279488: ProcessBuilder inherits contextClassLoader when spawning a process reaper thread Reviewed-by: alanb ------------- PR: https://git.openjdk.java.net/jdk/pull/7131 From rriggs at openjdk.java.net Mon Mar 28 15:57:49 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Mar 2022 15:57:49 GMT Subject: RFR: 8283774: TestZoneOffset::test_immutable should ignore ZoneOffset::rules In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 10:35:04 GMT, Claes Redestad wrote: > - Add capability to ignore fields explicitly when checking for immutability of classes in java.time > - Use this to avoid a test failure due the new `rules` cache in `ZoneOffset` > - Remove `TestZoneOffset` from problem list. Update Copyright dates before push. ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7989 From naoto at openjdk.java.net Mon Mar 28 16:02:51 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 16:02:51 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v3] In-Reply-To: References: Message-ID: On Sat, 26 Mar 2022 11:30:53 GMT, Lance Andersen wrote: > One suggestion As part of the PR, we should probably update test/jdk/java/util/Locale/LocaleTest.java. or perhaps add a new test for Locale.of() for completeness. Thanks, Lance. Sure, I will add some new unit tests for the new method. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Mon Mar 28 16:02:52 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 16:02:52 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v3] In-Reply-To: References: Message-ID: On Sun, 27 Mar 2022 08:45:01 GMT, ExE Boss wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed a build failure > > src/java.base/share/classes/java/util/Locale.java line 819: > >> 817: * @since 19 >> 818: */ >> 819: public static Locale of(String... fields) { > > Arguably, there?should?be `Locale.of`?overloads taking?0 to?4?arguments, so?that it?s?not?necessary to?box the?fields in?a?`String`?array. While it is true for completeness, I would limit the addition of new method as little as possible, because there are already several ways to obtain a Locale object. > src/java.base/share/classes/java/util/Locale.java line 825: > >> 823: case 2 -> getInstance(fields[0], "", fields[1], "", null); >> 824: case 3 -> getInstance(fields[0], "", fields[1], fields[2], null); >> 825: default -> getInstance(fields[0], fields[3], fields[1], fields[2], null); > > This?should probably?throw `IllegalArgumentException` when?more?than 4?fields are?passed: > Suggestion: > > case 4 -> getInstance(fields[0], fields[3], fields[1], fields[2], null); > default -> throw new IllegalArgumentException(/* TODO: message */); Thanks for the suggestion. Will incorporate the exception in the spec/impl. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Mon Mar 28 16:19:49 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 16:19:49 GMT Subject: RFR: 8283781: Avoid allocating unused lastRulesCaches In-Reply-To: References: Message-ID: <8LXzDrnkPyTwy3doogVJg6iE1i4UM0vuBLk1QEUVubY=.b578ce93-be1c-43a5-b372-0f0edf763c7f@github.com> On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote: > This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7990 From naoto at openjdk.java.net Mon Mar 28 16:24:43 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 16:24:43 GMT Subject: RFR: 8283774: TestZoneOffset::test_immutable should ignore ZoneOffset::rules In-Reply-To: References: Message-ID: <-FsWgCvmCMU0o02joFrQUw7jySY0oCtRTi9xEejEkPo=.6254c6e0-085d-40c7-aee4-ff19b866ebee@github.com> On Mon, 28 Mar 2022 10:35:04 GMT, Claes Redestad wrote: > - Add capability to ignore fields explicitly when checking for immutability of classes in java.time > - Use this to avoid a test failure due the new `rules` cache in `ZoneOffset` > - Remove `TestZoneOffset` from problem list. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7989 From vromero at openjdk.java.net Mon Mar 28 16:59:11 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 28 Mar 2022 16:59:11 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 Message-ID: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. TIA ------------- Commit messages: - additional adaptations after the automatic conversion - 8282508: Updating ASM to 9.2 for JDK 19 Changes: https://git.openjdk.java.net/jdk/pull/8000/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8000&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282508 Stats: 1762 lines in 136 files changed: 544 ins; 765 del; 453 mod Patch: https://git.openjdk.java.net/jdk/pull/8000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8000/head:pull/8000 PR: https://git.openjdk.java.net/jdk/pull/8000 From naoto at openjdk.java.net Mon Mar 28 17:02:33 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 17:02:33 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v4] In-Reply-To: References: Message-ID: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: New unit test. IllegalArgumentException. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7947/files - new: https://git.openjdk.java.net/jdk/pull/7947/files/b4d040af..9d9d3a69 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=02-03 Stats: 87 lines in 2 files changed: 83 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From lancea at openjdk.java.net Mon Mar 28 17:11:42 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 28 Mar 2022 17:11:42 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 In-Reply-To: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: <7vrkOUKPcBOPpk0mNRtLoIYBBbqDMfE_k5zUQIURzxA=.4890939e-a5d7-4912-b65b-70f461074b15@github.com> On Mon, 28 Mar 2022 16:49:58 GMT, Vicente Romero wrote: > Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. There are basically two commits here, one that was automatically generated and that mostly changes file headers etc and another one, smaller, that make changes to the code to adapt it to our needs, JDK version etc. In this second commit one can see that two classes that were removed by the automatically generated change have been copied back: > > jdk.internal.org.objectweb.asm.commons.RemappingMethodAdapter > jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter > > This is because package: `jdk.jfr.internal.instrument` needs them. > > TIA With this fix, I believe [JDK-8282446](https://bugs.openjdk.java.net/browse/JDK-8282446) should also be addressed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8000 From lancea at openjdk.java.net Mon Mar 28 17:17:48 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 28 Mar 2022 17:17:48 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v4] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 17:02:33 GMT, Naoto Sato wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > New unit test. IllegalArgumentException. Changes look fine. I would suggest adding a comment describing the new tests. Also one additional suggestion below test/jdk/java/util/Locale/TestOf.java line 79: > 77: @Test (expectedExceptions = IllegalArgumentException.class) > 78: public void test_IAE() { > 79: Locale.of("en", "", "", "", ""); I would consider using `assertThrows(IllegalArgumentException.class, () -> Locale.of("en", "", "", "", "")); ` instead of the expectedExceptions annotation element as it is the preferred way forward ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7947 From alanb at openjdk.java.net Mon Mar 28 17:24:42 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 28 Mar 2022 17:24:42 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: <1sKjAAYDEF8k2rEcGbZWvlqrz-UHc6FIFCQhXTc05VI=.4f18af62-4de2-49b5-aeac-e5b72eb38845@github.com> On Mon, 28 Mar 2022 15:01:30 GMT, Jaikiran Pai wrote: >> Volker Simonis 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: >> >> 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) > > src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 133: > >> 131: * Unlike the {@link InputStream#read(byte[],int,int) overridden method} >> 132: * of {@code InputStream}, this method might write more bytes than the returned >> 133: * number of inflated bytes into the buffer {@code b}. > > Hello Volker, I think this comment should be a bit more clear and state what exactly it means by writing more bytes than the returned value. Specifically, I think it should clearly state that even though it might write additional data, it will however not write/change data starting and beyond `off + len` index in the passed array. I think this require a bit of word smithing. If the return value is 'n' then it should make it clear that the values in elements b[off + n] to b[off + len - 1] are undefined, their values may or may have been changed by the inflate/read operation. For completeness, the expectation for when inflate fails should be specified too, the contents of b[off] to b[off + len - 1] will be undefined. ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From Alan.Bateman at oracle.com Mon Mar 28 17:33:27 2022 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 28 Mar 2022 18:33:27 +0100 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: <3e79090c-906e-6e89-31fa-9258cfdf830b@oracle.com> <3253df5a-c294-18c8-3e2b-46072c9a4501@oracle.com> Message-ID: On 28/03/2022 11:02, Volker Simonis wrote: > : > As I wrote before, the extra data written into the output buffer isn't > sensitive because it can only originate from the history buffer (aka > "sliding window"). Also, this data is already exposed today if the > `Inflater` class is being used stand-alone, because in contrast to > `InflaterInputStream::read(..)`, `Inflater::inflate(..)` doesn't > guarantee to leave the content beyond the last read byte unaffected. > Finally, the referenced zlib-chromium implementation with the > mentioned behavior is the default zlib implementation in on Android > and Chrome browsers. If you are satisfied that flipping bits during an inflate operation cannot never lead to something bad happening then okay. I'ts important to ask about such as matters. -Alan From forax at openjdk.java.net Mon Mar 28 17:53:47 2022 From: forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax) Date: Mon, 28 Mar 2022 17:53:47 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 In-Reply-To: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: On Mon, 28 Mar 2022 16:49:58 GMT, Vicente Romero wrote: > Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. There are basically two commits here, one that was automatically generated and that mostly changes file headers etc and another one, smaller, that make changes to the code to adapt it to our needs, JDK version etc. In this second commit one can see that two classes that were removed by the automatically generated change have been copied back: > > jdk.internal.org.objectweb.asm.commons.RemappingMethodAdapter > jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter > > This is because package: `jdk.jfr.internal.instrument` needs them. > > TIA I suppose that you are raising commons.RemappingMethodAdapter and commons.RemappingAnnotationAdapter from the dead because you want to fix the code in jdk.jfr.internal.instrument later ? Otherwise it's a little dangerous because that code as started to drift, the new remapper has new code not supported by the old remapper. BTW, @deprecated on ASM source is equivalent to. @Deprecated + forRemoval in the JDK. The support of Java 19 is fine, the same code will be included in ASM soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/8000 From jlaskey at openjdk.java.net Mon Mar 28 17:58:28 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 28 Mar 2022 17:58:28 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v15] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add carrierClass accessor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/c5d03e82..024d24cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=13-14 Stats: 30 lines in 2 files changed: 23 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From jlaskey at openjdk.java.net Mon Mar 28 18:09:29 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Mon, 28 Mar 2022 18:09:29 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v16] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Clean up @return ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/024d24cb..e577e16a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=15 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=14-15 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From volker.simonis at gmail.com Mon Mar 28 18:12:51 2022 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 28 Mar 2022 20:12:51 +0200 Subject: RFC: JDK-8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) In-Reply-To: References: <3e79090c-906e-6e89-31fa-9258cfdf830b@oracle.com> <3253df5a-c294-18c8-3e2b-46072c9a4501@oracle.com> Message-ID: On Mon, Mar 28, 2022 at 7:33 PM Alan Bateman wrote: > > On 28/03/2022 11:02, Volker Simonis wrote: > > : > > As I wrote before, the extra data written into the output buffer isn't > > sensitive because it can only originate from the history buffer (aka > > "sliding window"). Also, this data is already exposed today if the > > `Inflater` class is being used stand-alone, because in contrast to > > `InflaterInputStream::read(..)`, `Inflater::inflate(..)` doesn't > > guarantee to leave the content beyond the last read byte unaffected. > > Finally, the referenced zlib-chromium implementation with the > > mentioned behavior is the default zlib implementation in on Android > > and Chrome browsers. > If you are satisfied that flipping bits during an inflate operation > cannot never lead to something bad happening then okay. I'ts important > to ask about such as matters. > Sure. Thanks for your comments. > -Alan From lancea at openjdk.java.net Mon Mar 28 18:26:49 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 28 Mar 2022 18:26:49 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: <1sKjAAYDEF8k2rEcGbZWvlqrz-UHc6FIFCQhXTc05VI=.4f18af62-4de2-49b5-aeac-e5b72eb38845@github.com> References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> <1sKjAAYDEF8k2rEcGbZWvlqrz-UHc6FIFCQhXTc05VI=.4f18af62-4de2-49b5-aeac-e5b72eb38845@github.com> Message-ID: On Mon, 28 Mar 2022 17:21:40 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/util/zip/InflaterInputStream.java line 133: >> >>> 131: * Unlike the {@link InputStream#read(byte[],int,int) overridden method} >>> 132: * of {@code InputStream}, this method might write more bytes than the returned >>> 133: * number of inflated bytes into the buffer {@code b}. >> >> Hello Volker, I think this comment should be a bit more clear and state what exactly it means by writing more bytes than the returned value. Specifically, I think it should clearly state that even though it might write additional data, it will however not write/change data starting and beyond `off + len` index in the passed array. > > I think this require a bit of word smithing. If the return value is 'n' then it should make it clear that the values in elements b[off + n] to b[off + len - 1] are undefined, their values may or may have been changed by the inflate/read operation. For completeness, the expectation for when inflate fails should be specified too, the contents of b[off] to b[off + len - 1] will be undefined. Hi Volker, I believe you are heading in the right direction. I agree with Alan and Jai that we could use a bit more clarification ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From achung at openjdk.java.net Mon Mar 28 18:35:54 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 28 Mar 2022 18:35:54 GMT Subject: Integrated: 8280400: JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 21:09:30 GMT, Alisen Chung wrote: > msg drop for jdk19, Mar 9, 2022 This pull request has now been integrated. Changeset: c0aecd15 Author: Alisen Chung Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/c0aecd15ae8d7abf37901f785fccaff2317c3b23 Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod 8280400: JDK 19 L10n resource files update - msgdrop 10 Reviewed-by: naoto, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/7765 From naoto at openjdk.java.net Mon Mar 28 18:51:30 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 18:51:30 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v5] In-Reply-To: References: Message-ID: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Refined test cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7947/files - new: https://git.openjdk.java.net/jdk/pull/7947/files/9d9d3a69..86c7b586 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=03-04 Stats: 9 lines in 1 file changed: 4 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Mon Mar 28 18:51:31 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 18:51:31 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v4] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 17:13:44 GMT, Lance Andersen wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> New unit test. IllegalArgumentException. > > test/jdk/java/util/Locale/TestOf.java line 79: > >> 77: @Test (expectedExceptions = IllegalArgumentException.class) >> 78: public void test_IAE() { >> 79: Locale.of("en", "", "", "", ""); > > I would consider using `assertThrows(IllegalArgumentException.class, () -> Locale.of("en", "", "", "", "")); ` instead of the expectedExceptions annotation element as it is the preferred way forward Thanks. Modified as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From lancea at openjdk.java.net Mon Mar 28 19:13:48 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Mon, 28 Mar 2022 19:13:48 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v5] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 18:51:30 GMT, Naoto Sato wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Refined test cases Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From aturbanov at openjdk.java.net Mon Mar 28 19:25:05 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 28 Mar 2022 19:25:05 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls Message-ID: In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. ------------- Commit messages: - [PATCH] Simplify String.indexOf/lastIndexOf calls Changes: https://git.openjdk.java.net/jdk/pull/7877/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7877&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283800 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/7877.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7877/head:pull/7877 PR: https://git.openjdk.java.net/jdk/pull/7877 From aturbanov at openjdk.java.net Mon Mar 28 19:26:03 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Mon, 28 Mar 2022 19:26:03 GMT Subject: RFR: 8283801: Cleanup confusing String.toString calls Message-ID: <-ZqXmYduQRz20bw-aAD90xx3DLNuq4xoM6Wi4zWN520=.21c06a63-7038-4c0c-ae06-f708b8cbbb64@github.com> String.toString() calls doesn't make much sense. Only one place, where it could be used - to generate NPE. But in a few places of JDK codebase it's called, even when NPE will happen anyway. I propose to cleanup such places. Found by IntelliJ IDEA inspection `Redundant 'String' operation`. ------------- Commit messages: - [PATCH] Cleanup confusing String.toString calls Changes: https://git.openjdk.java.net/jdk/pull/7878/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7878&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283801 Stats: 14 lines in 4 files changed: 0 ins; 4 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/7878.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7878/head:pull/7878 PR: https://git.openjdk.java.net/jdk/pull/7878 From vromero at openjdk.java.net Mon Mar 28 20:04:42 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Mon, 28 Mar 2022 20:04:42 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 In-Reply-To: References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: <11LI4P7uTKYC8zqCq-J4bNTiLcPLjsglRsrCKeV8fjg=.e2df9cd2-1030-4925-9a81-475432889a08@github.com> On Mon, 28 Mar 2022 17:50:25 GMT, R?mi Forax wrote: > I suppose that you are raising commons.RemappingMethodAdapter and commons.RemappingAnnotationAdapter from the dead because you want to fix the code in jdk.jfr.internal.instrument later ? correct, I would prefer the team maintaining jdk.jfr.internal.instrument to do that update after this PR has been pushed > > Otherwise it's a little dangerous because that code as started to drift, the new remapper has new code not supported by the old remapper. BTW, @deprecated on ASM source is equivalent to. @deprecated + forRemoval in the JDK. > > The support of Java 19 is fine, the same code will be included in ASM soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/8000 From xuelei at openjdk.java.net Mon Mar 28 20:11:42 2022 From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan) Date: Mon, 28 Mar 2022 20:11:42 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. Please add a noreg- label to the bug. Otherwise, looks good to me. ------------- Marked as reviewed by xuelei (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7877 From bpb at openjdk.java.net Mon Mar 28 20:11:42 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 28 Mar 2022 20:11:42 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7877 From bpb at openjdk.java.net Mon Mar 28 20:14:48 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Mon, 28 Mar 2022 20:14:48 GMT Subject: RFR: 8283801: Cleanup confusing String.toString calls In-Reply-To: <-ZqXmYduQRz20bw-aAD90xx3DLNuq4xoM6Wi4zWN520=.21c06a63-7038-4c0c-ae06-f708b8cbbb64@github.com> References: <-ZqXmYduQRz20bw-aAD90xx3DLNuq4xoM6Wi4zWN520=.21c06a63-7038-4c0c-ae06-f708b8cbbb64@github.com> Message-ID: On Sun, 20 Mar 2022 13:20:31 GMT, Andrey Turbanov wrote: > String.toString() calls doesn't make much sense. Only one place, where it could be used - to generate NPE. But in a few places of JDK codebase it's called, even when NPE will happen anyway. > I propose to cleanup such places. > Found by IntelliJ IDEA inspection `Redundant 'String' operation`. Likewise, please add a `noreg-` label to the issue, perhaps `noreg-cleanup`. Otherwise fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7878 From duke at openjdk.java.net Mon Mar 28 20:38:43 2022 From: duke at openjdk.java.net (ExE Boss) Date: Mon, 28 Mar 2022 20:38:43 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v16] In-Reply-To: References: Message-ID: <153RNHPysiDDUclXTMKPstnO5mEgd1WMaWfLBlFCblw=.f8f41e4b-5468-4a39-bf92-23b3126911ae@github.com> On Mon, 28 Mar 2022 18:09:29 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Clean up @return src/java.base/share/classes/java/lang/runtime/Carrier.java line 330: > 328: * Constructor. > 329: * > 330: * @param primitiveCount slot count required for primitives This?isn?t the?slot?count, but?the?`long[]` array?length, which?is?half the?slot?count for?`long`s. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From rriggs at openjdk.java.net Mon Mar 28 21:09:43 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Mon, 28 Mar 2022 21:09:43 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v3] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 16:00:14 GMT, Naoto Sato wrote: >> src/java.base/share/classes/java/util/Locale.java line 819: >> >>> 817: * @since 19 >>> 818: */ >>> 819: public static Locale of(String... fields) { >> >> Arguably, there?should?be `Locale.of`?overloads taking?0 to?4?arguments, so?that it?s?not?necessary to?box the?fields in?a?`String`?array. > > While it is true for completeness, I would limit the addition of new method as little as possible, because there are already several ways to obtain a Locale object. As with other varargs method calls, it is possible to pass an array with the values. I think it would be useful to describe the arguments as using the varargs nomenclature and indicate the values are in the array. For example, the `java.util.List.of(E... elements)` method is explicit about the array. Anther API using varargs EnumSet. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From achung at openjdk.java.net Mon Mar 28 21:30:15 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 28 Mar 2022 21:30:15 GMT Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 Message-ID: This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. ------------- Commit messages: - Revert "8280400: JDK 19 L10n resource files update - msgdrop 10" Changes: https://git.openjdk.java.net/jdk/pull/8005/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8005&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283806 Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod Patch: https://git.openjdk.java.net/jdk/pull/8005.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8005/head:pull/8005 PR: https://git.openjdk.java.net/jdk/pull/8005 From kcr at openjdk.java.net Mon Mar 28 21:30:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Mar 2022 21:30:16 GMT Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote: > This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. I confirm that this is an exact backout of [JDK-8280400](https://bugs.openjdk.java.net/browse/JDK-8280400). ------------- Marked as reviewed by kcr (Author). PR: https://git.openjdk.java.net/jdk/pull/8005 From lmesnik at openjdk.java.net Mon Mar 28 21:49:55 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Mon, 28 Mar 2022 21:49:55 GMT Subject: RFR: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7877 From naoto at openjdk.java.net Mon Mar 28 22:16:43 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 22:16:43 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v6] In-Reply-To: References: Message-ID: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added an @apiNote describing the single array argument ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7947/files - new: https://git.openjdk.java.net/jdk/pull/7947/files/86c7b586..b1d36b52 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=04-05 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Mon Mar 28 22:16:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 22:16:44 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v3] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 21:06:35 GMT, Roger Riggs wrote: >> While it is true for completeness, I would limit the addition of new method as little as possible, because there are already several ways to obtain a Locale object. > > As with other varargs method calls, it is possible to pass an array with the values. > I think it would be useful to describe the arguments as using the varargs nomenclature and indicate > the values are in the array. For example, the `java.util.List.of(E... elements)` method is explicit > about the array. Anther API using varargs EnumSet. Added the explanation following the `List.of(E... elements)` javadoc. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Mon Mar 28 22:44:36 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Mon, 28 Mar 2022 22:44:36 GMT Subject: RFR: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote: > This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. LGTM ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8005 From achung at openjdk.java.net Mon Mar 28 23:40:44 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Mon, 28 Mar 2022 23:40:44 GMT Subject: Integrated: 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 21:20:00 GMT, Alisen Chung wrote: > This reverts commit c0aecd15ae8d7abf37901f785fccaff2317c3b23. This pull request has now been integrated. Changeset: 634800a5 Author: Alisen Chung Committer: Naoto Sato URL: https://git.openjdk.java.net/jdk/commit/634800a536e7f9d148a4caa2663a60a2c5fc4929 Stats: 11316 lines in 139 files changed: 1252 ins; 9124 del; 940 mod 8283806: [BACKOUT] JDK 19 L10n resource files update - msgdrop 10 Reviewed-by: kcr, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/8005 From igraves at openjdk.java.net Tue Mar 29 00:05:45 2022 From: igraves at openjdk.java.net (Ian Graves) Date: Tue, 29 Mar 2022 00:05:45 GMT Subject: Integrated: 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS In-Reply-To: References: Message-ID: <8FoJoY5TtmWbF9VxZqjJ1VG5ed0DxbZodC67CuXcav0=.d1e0df93-8994-41c6-bdbc-66377b12aaa7@github.com> On Fri, 18 Feb 2022 19:47:09 GMT, Ian Graves wrote: > Proposed change in behavior to correct inconsistencies between `\w` and `\b` metacharacters This pull request has now been integrated. Changeset: f01cce23 Author: Ian Graves URL: https://git.openjdk.java.net/jdk/commit/f01cce235b62e378e91a3bae32942e2f3dfc5c7e Stats: 97 lines in 2 files changed: 79 ins; 6 del; 12 mod 8264160: Regex \b is not consistent with \w without UNICODE_CHARACTER_CLASS Reviewed-by: lancea, bpb, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7539 From smarks at openjdk.java.net Tue Mar 29 01:25:06 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 29 Mar 2022 01:25:06 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final Message-ID: Pretty much just what it says. ------------- Commit messages: - Make ObjectStreamClass final. Changes: https://git.openjdk.java.net/jdk/pull/8009/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8009&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283715 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8009/head:pull/8009 PR: https://git.openjdk.java.net/jdk/pull/8009 From smarks at openjdk.java.net Tue Mar 29 01:25:07 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 29 Mar 2022 01:25:07 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 01:07:33 GMT, Stuart Marks wrote: > Pretty much just what it says. Please review CSR request [JDK-8283811](https://bugs.openjdk.java.net/browse/JDK-8283811). ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From darcy at openjdk.java.net Tue Mar 29 01:34:39 2022 From: darcy at openjdk.java.net (Joe Darcy) Date: Tue, 29 Mar 2022 01:34:39 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 01:07:33 GMT, Stuart Marks wrote: > Pretty much just what it says. Marked as reviewed by darcy (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From jpai at openjdk.java.net Tue Mar 29 02:01:47 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Mar 2022 02:01:47 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: On Mon, 28 Mar 2022 10:55:30 GMT, Volker Simonis wrote: >> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. >> >> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. >> >> ### TL;DR >> >> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. >> >> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. >> >> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. >> >> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+` *k*`]` (where *k* is the number of inflated bytes). >> >> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). > > Volker Simonis 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: > > 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) Hello Volker, An additional thing that we might have to consider here is whether adding this javadoc change to `InflaterInputStream` is ever going to "show up" to end user applications. What I mean is, I think in many cases the end user applications won't even know they are dealing with an `InflaterInputStream`. For example, the following code: ZipFile zf = ... ZipEntry ze = zf.getEntry("some-file"); InputStream is = zf.getInputStream(ze); As we see above, none of these APIs talk about `InflaterInputStream` (the return type of `ZipFile.getInpustream(...)` is an `InputStream`). So end users won't be able to view this spec change. Perhaps we should also add some note in the `ZipFile.getInpustream(....)` API to make a mention of this potential difference in behaviour of the returned stream? ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From jbhateja at openjdk.java.net Tue Mar 29 02:44:43 2022 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 29 Mar 2022 02:44:43 GMT Subject: RFR: 8283726: x86 intrinsics for compare method in Integer and Long In-Reply-To: References: Message-ID: On Sun, 27 Mar 2022 06:15:34 GMT, Vamsi Parasa wrote: > Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long. src/hotspot/cpu/x86/x86_64.ad line 12107: > 12105: instruct compareSignedI_rReg(rRegI dst, rRegI op1, rRegI op2, rRegI tmp, rFlagsReg cr) > 12106: %{ > 12107: match(Set dst (CompareSignedI op1 op2)); Please also include these patterns in x86_32.ad src/hotspot/cpu/x86/x86_64.ad line 12125: > 12123: __ movl(tmp, 0); > 12124: __ bind(done); > 12125: __ movl(dest, tmp); Please move this in macro-assembly routine. src/hotspot/cpu/x86/x86_64.ad line 12178: > 12176: __ movl(tmp, 0); > 12177: __ bind(done); > 12178: __ movl(dest, tmp); Please move this into a macro-assembly routine. src/hotspot/cpu/x86/x86_64.ad line 12204: > 12202: __ movl(tmp, 0); > 12203: __ bind(done); > 12204: __ movl(dest, tmp); Please move this into macro-assembly routine. src/hotspot/share/classfile/vmIntrinsics.hpp line 239: > 237: do_intrinsic(_compareUnsigned_i, java_lang_Integer, compare_unsigned_name, int2_int_signature, F_S) \ > 238: do_name( compare_unsigned_name, "compareUnsigned") \ > 239: do_intrinsic(_compareUnsigned_l, java_lang_Long, compare_unsigned_name, long2_int_signature, F_S) \ Creating these methods as intrinsic will create a box around the underneath comparison logic, this shall prevent any regular constant folding which could have optimized out certain control paths, I would suggest to to handle constant folding for newly added nodes in associated Value routines. src/hotspot/share/opto/comparenode.hpp line 67: > 65: CompareUnsignedLNode(Node* in1, Node* in2) : CompareNode(in1, in2) {} > 66: virtual int Opcode() const; > 67: }; Intent here seems to be to enable further auto-vectorization of newly create IR nodes. test/micro/org/openjdk/bench/java/lang/CompareInteger.java line 78: > 76: input2[i] = tmp; > 77: } > 78: } Logic re-organization suggestion:- for (int i = 0 ; i < BUFFER_SIZE; i++) { input1[i] = rng.nextLong(); } if (mode.equals("equals") { GRADIANT = 0; } else if (mode.equals("greaterThanEquals")) { GRADIANT = 1; } else { assert mode.equals("lessThanEqual"); GRADIANT = -1; } for(int i = 0 ; i < BUFFER_SIZE; i++) { input2[i] = input1[i] + i*GRADIANT; } test/micro/org/openjdk/bench/java/lang/CompareLong.java line 5: > 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > 4: * > 5: * This code is free software; you can redistribute it and/or modify it We can unify this benchmark along with integer compare micro. ------------- PR: https://git.openjdk.java.net/jdk/pull/7975 From vromero at openjdk.java.net Tue Mar 29 04:28:33 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Mar 2022 04:28:33 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 [v2] In-Reply-To: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: > Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. There are basically two commits here, one that was automatically generated and that mostly changes file headers etc and another one, smaller, that make changes to the code to adapt it to our needs, JDK version etc. In this second commit one can see that two classes that were removed by the automatically generated change have been copied back: > > jdk.internal.org.objectweb.asm.commons.RemappingMethodAdapter > jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter > > This is because package: `jdk.jfr.internal.instrument` needs them. > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: addressing review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8000/files - new: https://git.openjdk.java.net/jdk/pull/8000/files/2e468674..41ae618e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8000&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8000&range=00-01 Stats: 83 lines in 2 files changed: 82 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8000/head:pull/8000 PR: https://git.openjdk.java.net/jdk/pull/8000 From vromero at openjdk.java.net Tue Mar 29 04:28:33 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 29 Mar 2022 04:28:33 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 In-Reply-To: <7vrkOUKPcBOPpk0mNRtLoIYBBbqDMfE_k5zUQIURzxA=.4890939e-a5d7-4912-b65b-70f461074b15@github.com> References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> <7vrkOUKPcBOPpk0mNRtLoIYBBbqDMfE_k5zUQIURzxA=.4890939e-a5d7-4912-b65b-70f461074b15@github.com> Message-ID: On Mon, 28 Mar 2022 17:08:12 GMT, Lance Andersen wrote: > With this fix, I believe [JDK-8282446](https://bugs.openjdk.java.net/browse/JDK-8282446) should also be addressed. Thanks for mentioning this. I have uploaded another commit [41ae618e3a5ce696e3400a8654d98801226d7c1b](https://github.com/openjdk/jdk/pull/8000/commits/41ae618e3a5ce696e3400a8654d98801226d7c1b), which addresses this issue. ------------- PR: https://git.openjdk.java.net/jdk/pull/8000 From jiefu at openjdk.java.net Tue Mar 29 05:08:42 2022 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 29 Mar 2022 05:08:42 GMT Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3] In-Reply-To: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> References: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> Message-ID: On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong wrote: >> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. >> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. >> >> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: >> - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. >> - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. >> >> So with this patch, the following transformations are applied: >> >> For non-masked negation with NEON: >> >> movi v16.4s, #0x0 >> sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s >> >> and with SVE: >> >> mov z16.s, #0 >> sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s >> >> For masked negation with NEON: >> >> movi v17.4s, #0x1 >> mvn v19.16b, v18.16b >> mov v20.16b, v16.16b ==> neg v18.4s, v17.4s >> bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b >> add v19.4s, v20.4s, v17.4s >> mov v18.16b, v16.16b >> bsl v18.16b, v19.16b, v20.16b >> >> and with SVE: >> >> mov z16.s, #-1 >> mov z17.s, #1 ==> neg z16.s, p0/m, z16.s >> eor z18.s, p0/m, z18.s, z16.s >> add z18.s, p0/m, z18.s, z17.s >> >> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): >> >> NEON: >> Benchmark Gain >> Byte128Vector.NEG 1.029 >> Byte128Vector.NEGMasked 1.757 >> Short128Vector.NEG 1.041 >> Short128Vector.NEGMasked 1.659 >> Int128Vector.NEG 1.005 >> Int128Vector.NEGMasked 1.513 >> Long128Vector.NEG 1.003 >> Long128Vector.NEGMasked 1.878 >> >> SVE with 512-bits: >> Benchmark Gain >> ByteMaxVector.NEG 1.10 >> ByteMaxVector.NEGMasked 1.165 >> ShortMaxVector.NEG 1.056 >> ShortMaxVector.NEGMasked 1.195 >> IntMaxVector.NEG 1.002 >> IntMaxVector.NEGMasked 1.239 >> LongMaxVector.NEG 1.031 >> LongMaxVector.NEGMasked 1.191 >> >> X86 (non AVX-512): >> Benchmark Gain >> ByteMaxVector.NEGMasked 1.254 >> ShortMaxVector.NEGMasked 1.359 >> IntMaxVector.NEGMasked 1.431 >> LongMaxVector.NEGMasked 1.989 >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Make "degenerate_vector_integral_negate" to be "NegVI" private Obvious performance improvement had ben observed on x86 for integral vector negation. So I think it's good to go. LGTM Thanks. Note: I didn't check the aarch64 code change. ------------- Marked as reviewed by jiefu (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7782 From xgong at openjdk.java.net Tue Mar 29 06:00:43 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Tue, 29 Mar 2022 06:00:43 GMT Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3] In-Reply-To: References: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> Message-ID: <3b3zK9Dbs2d-PFUsnmAJJlmp2OddRhHEDYb5ISm8fvs=.728bf5b9-aff5-45bf-a436-f17fa7be50be@github.com> On Tue, 29 Mar 2022 05:05:43 GMT, Jie Fu wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Make "degenerate_vector_integral_negate" to be "NegVI" private > > Note: I didn't check the aarch64 code change. Thanks for the review @DamonFool ! ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From jpai at openjdk.java.net Tue Mar 29 08:40:46 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Mar 2022 08:40:46 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final In-Reply-To: References: Message-ID: <9eU3sUzmXZTMd-_LJuTQ9ZYFFQ0DLUkkeGgM4biHoHU=.efcce143-8177-4ff0-910f-8430b314c18c@github.com> On Tue, 29 Mar 2022 01:07:33 GMT, Stuart Marks wrote: > Pretty much just what it says. Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From jpai at openjdk.java.net Tue Mar 29 08:46:49 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Mar 2022 08:46:49 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 01:07:33 GMT, Stuart Marks wrote: > Pretty much just what it says. The test failures caught by GitHub Actions jobs look related to the area of this change: 2022-03-29T02:21:21.2187570Z at CheckCSMs.main(CheckCSMs.java:98) 2022-03-29T02:21:21.2188140Z at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) 2022-03-29T02:21:21.2188650Z at java.base/java.lang.reflect.Method.invoke(Method.java:577) 2022-03-29T02:21:21.2189060Z at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) 2022-03-29T02:21:21.2189420Z at java.base/java.lang.Thread.run(Thread.java:828) 2022-03-29T02:21:21.2189590Z 2022-03-29T02:21:21.2190030Z JavaTest Message: Test threw exception: java.lang.RuntimeException: Unexpected non-final instance method: 2022-03-29T02:21:21.2190400Z java/io/ObjectStreamField#getType ()Ljava/lang/Class; ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From aturbanov at openjdk.java.net Tue Mar 29 09:25:59 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Tue, 29 Mar 2022 09:25:59 GMT Subject: RFR: 8283846: Remove unused jdk.internal.reflect.SignatureIterator Message-ID: It was no longer used due to JDK-4479184 long ago. ------------- Commit messages: - [PATCH] Remove unused jdk.internal.reflect.SignatureIterator Changes: https://git.openjdk.java.net/jdk/pull/8013/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8013&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283846 Stats: 81 lines in 1 file changed: 0 ins; 81 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8013.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8013/head:pull/8013 PR: https://git.openjdk.java.net/jdk/pull/8013 From redestad at openjdk.java.net Tue Mar 29 09:35:48 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 09:35:48 GMT Subject: RFR: 8283781: Avoid allocating unused lastRulesCaches In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote: > This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily. Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7990 From redestad at openjdk.java.net Tue Mar 29 09:35:48 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 09:35:48 GMT Subject: Integrated: 8283781: Avoid allocating unused lastRulesCaches In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 11:52:38 GMT, Claes Redestad wrote: > This address a minor inefficiency in that the `ZoneRules` of any `ZoneOffset` (and some `ZoneRegion`s) allocate `lastRulesCache` unnecessarily. This pull request has now been integrated. Changeset: 0e788e0e Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/0e788e0ecbf44f1feee817fe22123a8523da5ee3 Stats: 16 lines in 1 file changed: 9 ins; 2 del; 5 mod 8283781: Avoid allocating unused lastRulesCaches Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7990 From dfuchs at openjdk.java.net Tue Mar 29 09:36:50 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 29 Mar 2022 09:36:50 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 01:07:33 GMT, Stuart Marks wrote: > Pretty much just what it says. Yes - it looks like jdk/internal/reflect/CallerSensitive/CheckCSMs.java needs to be updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From redestad at openjdk.java.net Tue Mar 29 09:43:19 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 09:43:19 GMT Subject: RFR: 8283774: TestZoneOffset::test_immutable should ignore ZoneOffset::rules [v2] In-Reply-To: References: Message-ID: > - Add capability to ignore fields explicitly when checking for immutability of classes in java.time > - Use this to avoid a test failure due the new `rules` cache in `ZoneOffset` > - Remove `TestZoneOffset` from problem list. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Copyrights ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7989/files - new: https://git.openjdk.java.net/jdk/pull/7989/files/44a8cc6b..4da4429b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7989&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7989&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/7989.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7989/head:pull/7989 PR: https://git.openjdk.java.net/jdk/pull/7989 From redestad at openjdk.java.net Tue Mar 29 09:43:20 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 09:43:20 GMT Subject: RFR: 8283774: TestZoneOffset::test_immutable should ignore ZoneOffset::rules In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 10:35:04 GMT, Claes Redestad wrote: > - Add capability to ignore fields explicitly when checking for immutability of classes in java.time > - Use this to avoid a test failure due the new `rules` cache in `ZoneOffset` > - Remove `TestZoneOffset` from problem list. Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/7989 From redestad at openjdk.java.net Tue Mar 29 09:43:21 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 09:43:21 GMT Subject: Integrated: 8283774: TestZoneOffset::test_immutable should ignore ZoneOffset::rules In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 10:35:04 GMT, Claes Redestad wrote: > - Add capability to ignore fields explicitly when checking for immutability of classes in java.time > - Use this to avoid a test failure due the new `rules` cache in `ZoneOffset` > - Remove `TestZoneOffset` from problem list. This pull request has now been integrated. Changeset: cc598e03 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/cc598e03de39dd6e8d7e208a69d85b6a9cd0062f Stats: 14 lines in 3 files changed: 6 ins; 3 del; 5 mod 8283774: TestZoneOffset::test_immutable should ignore ZoneOffset::rules Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/7989 From duke at openjdk.java.net Tue Mar 29 09:51:42 2022 From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=) Date: Tue, 29 Mar 2022 09:51:42 GMT Subject: RFR: 8282662: Use List.of() factory method to reduce memory consumption [v3] In-Reply-To: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com> References: <4Rqp6XHMwZxKTmz1Hlqd2zYEUsQ8Mhwl-oehGG7YMrA=.80412db9-4d08-41b0-a486-5696eeb45f95@github.com> Message-ID: On Sat, 26 Mar 2022 16:35:14 GMT, liach wrote: >> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision: >> >> 8282662: Revert dubious changes in MethodType > > Just curious, this issue asks to replace set constructions with `Set.of`, but there is no such code changes in this pull request. Is there any set creation patterns that aren't detected by your ide cleanups, such as `Collections.addAll(set, elements)` for creating hash set contents from array? @liach I've found a couple of places: - `AsynchronousFileChannel.open()` - `FileChannel.open()` - `DecimalStyle.getAvailableLocales()` They all either rely on user input, i.e. might throw NPE or IAE for nulls or duplicates respectively, or return the set, which is currently modifiable `HashSet`. I think the possible win isn't worth the effort. ------------- PR: https://git.openjdk.java.net/jdk/pull/7729 From redestad at openjdk.java.net Tue Mar 29 10:45:18 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 10:45:18 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay Message-ID: In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. ------------- Commit messages: - Explicitly check that year in successfully created LocalDates is valid - Copyright - Redundant verification of year in LocalDate::ofEpochDay Changes: https://git.openjdk.java.net/jdk/pull/8014/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8014&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283782 Stats: 38 lines in 2 files changed: 33 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/8014.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8014/head:pull/8014 PR: https://git.openjdk.java.net/jdk/pull/8014 From jpai at openjdk.java.net Tue Mar 29 11:16:56 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Tue, 29 Mar 2022 11:16:56 GMT Subject: RFR: 8003417: WeakHashMap$HashIterator removes wrong entry In-Reply-To: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com> References: <2LIk6SBB2yLsEe5GlCT2K7vcVnxrJ1_-rn7AzO6tZZI=.22c5cfa1-b37d-4dcb-9198-a5f707407d38@github.com> Message-ID: On Sat, 20 Nov 2021 10:08:41 GMT, Jaikiran Pai wrote: > Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.java.net/browse/JDK-8003417? > > The issue notes that this is applicable for `WeakHashMap` which have `null` keys. However, the issue is even applicable for `WeakHashMap` instances which don't have `null` keys, as reproduced and shown by the newly added jtreg test case in this PR. > > The root cause of the issue is that once the iterator is used to iterate till the end and the `remove()` is called, then the `WeakHashMap$HashIterator#remove()` implementation used to pass `null` as the key to remove from the map, instead of the key of the last returned entry. The commit in this PR fixes that part. > > A new jtreg test has been added which reproduces the issue as well as verifies the fix. > `tier1` testing and this new test have passed after this change. However, I guess this will require a JCK run to be run too, perhaps? If so, I will need help from someone who has access to them to have this run against those please. (work is currently in progress on this one) ------------- PR: https://git.openjdk.java.net/jdk/pull/6488 From jlaskey at openjdk.java.net Tue Mar 29 12:16:46 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 29 Mar 2022 12:16:46 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v16] In-Reply-To: <153RNHPysiDDUclXTMKPstnO5mEgd1WMaWfLBlFCblw=.f8f41e4b-5468-4a39-bf92-23b3126911ae@github.com> References: <153RNHPysiDDUclXTMKPstnO5mEgd1WMaWfLBlFCblw=.f8f41e4b-5468-4a39-bf92-23b3126911ae@github.com> Message-ID: On Mon, 28 Mar 2022 20:32:02 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Clean up @return > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 330: > >> 328: * Constructor. >> 329: * >> 330: * @param primitiveCount slot count required for primitives > > This?isn?t the?slot?count, but?the?`long[]` array?length, which?is?half the?slot?count for?`long`s. Thanks for pointing this out. It is the slot count, but I was over-allocating the long array. diff --git a/src/java.base/share/classes/java/lang/runtime/Carrier.java b/src/java.base/share/classes/java/lang/runtime/Carrier.java index 50a32346417..775df6cb4c3 100644 --- a/src/java.base/share/classes/java/lang/runtime/Carrier.java +++ b/src/java.base/share/classes/java/lang/runtime/Carrier.java @@ -331,7 +331,7 @@ public final class Carrier { * @param objectCount slot count required for objects */ CarrierArray(int primitiveCount, int objectCount) { - this.primitives = new long[primitiveCount]; + this.primitives = new long[(primitiveCount + 1) / 2]; this.objects = new Object[objectCount]; } @@ -432,10 +432,10 @@ public final class Carrier { int longCount = carrierShape.longCount(); int intCount = carrierShape.intCount(); int objectCount = carrierShape.objectCount(); - int primitiveSlots = longCount * LONG_SLOTS + intCount; + int primitiveCount = longCount * LONG_SLOTS + intCount; MethodHandle constructor = MethodHandles.insertArguments(CONSTRUCTOR, - 0, primitiveSlots, objectCount); + 0, primitiveCount, objectCount); // long array index int index = 0; ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From simonis at openjdk.java.net Tue Mar 29 12:43:25 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 29 Mar 2022 12:43:25 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v3] In-Reply-To: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: > Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. > > The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. > > ### TL;DR > > `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. > > The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. > > The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. > > These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+`* k*`]` (where *k* is the number of inflated bytes). > > From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: Extended API-doc based on reviewer feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7986/files - new: https://git.openjdk.java.net/jdk/pull/7986/files/b55fc332..62a46591 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7986&range=01-02 Stats: 9 lines in 1 file changed: 5 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/7986.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7986/head:pull/7986 PR: https://git.openjdk.java.net/jdk/pull/7986 From simonis at openjdk.java.net Tue Mar 29 12:43:26 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 29 Mar 2022 12:43:26 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> <1sKjAAYDEF8k2rEcGbZWvlqrz-UHc6FIFCQhXTc05VI=.4f18af62-4de2-49b5-aeac-e5b72eb38845@github.com> Message-ID: On Mon, 28 Mar 2022 18:23:46 GMT, Lance Andersen wrote: >> I think this require a bit of word smithing. If the return value is 'n' then it should make it clear that the values in elements b[off + n] to b[off + len - 1] are undefined, their values may or may have been changed by the inflate/read operation. For completeness, the expectation for when inflate fails should be specified too, the contents of b[off] to b[off + len - 1] will be undefined. > > Hi Volker, > > I believe you are heading in the right direction. I agree with Alan and Jai that we could use a bit more clarification Thanks for your comments. I've updated the API-doc according to your recommendations. Please feel free to propose new/better wording :) I'll wait with updating the CSR until we reach final agreement in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From simonis at openjdk.java.net Tue Mar 29 12:48:49 2022 From: simonis at openjdk.java.net (Volker Simonis) Date: Tue, 29 Mar 2022 12:48:49 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: <5n-I0E5OO7uAHLo7fWdPqgAojcWpMMIB_AhGrxSKRVA=.a38c974d-eafd-4bbf-85ec-2eb457105b59@github.com> On Tue, 29 Mar 2022 01:58:05 GMT, Jaikiran Pai wrote: > Hello Volker, An additional thing that we might have to consider here is whether adding this javadoc change to `InflaterInputStream` is ever going to "show up" to end user applications. What I mean is, I think in many cases the end user applications won't even know they are dealing with an `InflaterInputStream`. For example, the following code: > > ``` > ZipFile zf = ... > ZipEntry ze = zf.getEntry("some-file"); > InputStream is = zf.getInputStream(ze); > ``` > > As we see above, none of these APIs talk about `InflaterInputStream` (the return type of `ZipFile.getInpustream(...)` is an `InputStream`). So end users won't be able to view this spec change. Perhaps we should also add some note in the `ZipFile.getInpustream(....)` API to make a mention of this potential difference in behaviour of the returned stream? You are right with your observation and I'll be happy to add a corresponding comment if @LanceAndersen and @AlanBateman agree. Please let me know what you think? ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From jlaskey at openjdk.java.net Tue Mar 29 13:49:37 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 29 Mar 2022 13:49:37 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v17] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Add condy static methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/e577e16a..23122263 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=16 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=15-16 Stats: 99 lines in 2 files changed: 75 ins; 9 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From rriggs at openjdk.java.net Tue Mar 29 13:53:47 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Mar 2022 13:53:47 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v3] In-Reply-To: References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> Message-ID: On Tue, 29 Mar 2022 12:43:25 GMT, Volker Simonis wrote: >> Add an API note to `InflaterInputStream::read(byte[] b, int off, int len)` to highlight that it might write more bytes than the returned number of inflated bytes into the buffer `b`. >> >> The superclass `java.io.InputStream` specifies that `read(byte[] b, int off, int len)` will leave the content beyond the last read byte in the read buffer `b` unaffected. However, the overridden `read` method in `InflaterInputStream` passes the read buffer `b` to `Inflater::inflate(byte[] b, int off, int len)` which doesn't provide this guarantee. Depending on implementation details, `Inflater::inflate` might write more than the returned number of inflated bytes into the buffer `b`. >> >> ### TL;DR >> >> `java.util.zip.Inflater` is the Java wrapper class for zlib's inflater functionality. `Inflater::inflate(byte[] output, int off, int len)` currently calls zlib's native `inflate(..)` function and passes the address of `output[off]` and `len` to it via JNI. >> >> The specification of zlib's `inflate(..)` function (i.e. the [API documentation in the original zlib implementation](https://github.com/madler/zlib/blob/cacf7f1d4e3d44d871b605da3b647f07d718623f/zlib.h#L400)) doesn't give any guarantees with regard to usage of the output buffer. It only states that upon completion the function will return the number of bytes that have been written (i.e. "inflated") into the output buffer. >> >> The original zlib implementation only wrote as many bytes into the output buffer as it inflated. However, this is not a hard requirement and newer, more performant implementations of the zlib library like [zlib-chromium](https://chromium.googlesource.com/chromium/src/third_party/zlib/) or [zlib-cloudflare](https://github.com/cloudflare/zlib) can use more bytes of the output buffer than they actually inflate as a scratch buffer. See https://github.com/simonis/zlib-chromium for a more detailed description of their approach and its performance benefit. >> >> These new zlib versions can still be used transparently from Java (e.g. by putting them into the `LD_LIBRARY_PATH` or by using `LD_PRELOAD`), because they still fully comply to specification of `Inflater::inflate(..)`. However, we might run into problems when using the `Inflater` functionality from the `InflaterInputStream` class. `InflaterInputStream` is derived from from `InputStream` and as such, its `read(byte[] b, int off, int len)` method is quite constrained. It specifically specifies that if *k* bytes have been read, then "these bytes will be stored in elements `b[off]` through `b[off+`*k*`-1]`, leaving elements `b[off+`*k*`]` through `b[off+len-1]` **unaffected**". But `InflaterInputStream::read(byte[] b, int off, int len)` (which is constrained by `InputStream::read(..)`'s specification) calls `Inflater::inflate(byte[] b, int off, int len)` and directly passes its output buffer down to the native zlib `inflate(..)` method which is free to change the bytes beyond `b[off+` *k*`]` (where *k* is the number of inflated bytes). >> >> From a practical point of view, I don't see this as a big problem, because callers of `InflaterInputStream::read(byte[] b, int off, int len)` can never know how many bytes will be written into the output buffer `b` (and in fact its content can always be completely overwritten). It therefore makes no sense to depend on any data there being untouched after the call. Also, having used zlib-cloudflare productively for about two years, we haven't seen real-world issues because of this behavior yet. However, from a specification point of view it is easy to artificially construct a program which violates `InflaterInputStream::read(..)`'s postcondition if using one of the alterantive zlib implementations. A recently integrated JTreg test (test/jdk/jdk/nio/zipfs/ZipFSOutputStreamTest.java) "unintentionally" fails with zlib-chromium but can fixed easily to run with alternative implementations as well (see [JDK-8283756](https://bugs.openjdk.java.net/browse/JDK-8283756)). > > Volker Simonis has updated the pull request incrementally with one additional commit since the last revision: > > Extended API-doc based on reviewer feedback One other way to communicate changes is in the release-note. I added release-note=yes to the bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From rriggs at openjdk.java.net Tue Mar 29 13:59:57 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Mar 2022 13:59:57 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 10:37:20 GMT, Claes Redestad wrote: > In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. > > This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. test/jdk/java/time/test/java/time/TestLocalDate.java line 432: > 430: long minYear = ChronoField.YEAR.range().getMinimum(); > 431: long maxYear = ChronoField.YEAR.range().getMinimum(); > 432: for (int i = 0; i < 500; i++) { The 500 seems like it would burn a lot of cycles mostly redundant. How about { 1, 2, 3, 28, 29, 30, 31, 32, 363, 364, 365, 366, 367}. ------------- PR: https://git.openjdk.java.net/jdk/pull/8014 From duke at openjdk.java.net Tue Mar 29 14:03:52 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 29 Mar 2022 14:03:52 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v17] In-Reply-To: References: Message-ID: <5s7NFFHFPJsmdljZf0NUXOWMsJeQd-c2C_X06xeU3ww=.59bccb19-01a6-43b8-bcfe-d900e455348f@github.com> On Tue, 29 Mar 2022 13:49:37 GMT, Jim Laskey wrote: >> We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. >> >> See JBS for details. > > Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: > > Add condy static methods src/java.base/share/classes/java/lang/runtime/Carrier.java line 335: > 333: CarrierArray(int primitiveCount, int objectCount) { > 334: this.primitives = > 335: primitiveCount != 0 ? new long[(primitiveCount + 1) / 2] : null; It?might be?better to?use an?unsigned?shift here: Suggestion: primitiveCount != 0 ? new long[(primitiveCount + 1) >>> 1] : null; ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From redestad at openjdk.java.net Tue Mar 29 14:07:41 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 14:07:41 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay [v2] In-Reply-To: References: Message-ID: <1ABu8Gfm1C3z0LEnnVsCsmvlLLxzPeb1lbo2iSos5Zo=.d84e35de-07be-4b8a-8108-b1fb9f1b30dd@github.com> > In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. > > This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: Sparse out the range of offsets tested ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8014/files - new: https://git.openjdk.java.net/jdk/pull/8014/files/6f82eb7d..44a11aa7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8014&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8014&range=00-01 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/8014.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8014/head:pull/8014 PR: https://git.openjdk.java.net/jdk/pull/8014 From redestad at openjdk.java.net Tue Mar 29 14:07:41 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 14:07:41 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay [v2] In-Reply-To: References: Message-ID: <9wp8IIHy8iXZkoajS4o7P9PqCnQmt3MPOoLbuLfslzQ=.8e7a178a-c403-48e2-9d94-28ad18833942@github.com> On Tue, 29 Mar 2022 13:56:09 GMT, Roger Riggs wrote: >> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: >> >> Sparse out the range of offsets tested > > test/jdk/java/time/test/java/time/TestLocalDate.java line 432: > >> 430: long minYear = ChronoField.YEAR.range().getMinimum(); >> 431: long maxYear = ChronoField.YEAR.range().getMinimum(); >> 432: for (int i = 0; i < 500; i++) { > > The 500 seems like it would burn a lot of cycles mostly redundant. > How about { 1, 2, 3, 28, 29, 30, 31, 32, 363, 364, 365, 366, 367}. Yes, makes sense to avoid useless work. Added 0 to the list. ------------- PR: https://git.openjdk.java.net/jdk/pull/8014 From rriggs at openjdk.java.net Tue Mar 29 14:13:49 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Mar 2022 14:13:49 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 01:07:33 GMT, Stuart Marks wrote: > Pretty much just what it says. Close by is `java.io.ObjectStreamField` which seems also useful to make final. Though it does have a public constructor so is more likely to raise a compatibility concern. ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From rriggs at openjdk.java.net Tue Mar 29 14:22:48 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Mar 2022 14:22:48 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay [v2] In-Reply-To: <1ABu8Gfm1C3z0LEnnVsCsmvlLLxzPeb1lbo2iSos5Zo=.d84e35de-07be-4b8a-8108-b1fb9f1b30dd@github.com> References: <1ABu8Gfm1C3z0LEnnVsCsmvlLLxzPeb1lbo2iSos5Zo=.d84e35de-07be-4b8a-8108-b1fb9f1b30dd@github.com> Message-ID: <9TPlgwGQJElk3VswU4f7hbFF0gA2XQj0LzaG3pzpIi4=.561de802-6105-4cd4-8980-818984947297@github.com> On Tue, 29 Mar 2022 14:07:41 GMT, Claes Redestad wrote: >> In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. >> >> This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > Sparse out the range of offsets tested Thanks ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8014 From rriggs at openjdk.java.net Tue Mar 29 14:55:17 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Tue, 29 Mar 2022 14:55:17 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v6] In-Reply-To: References: Message-ID: On Mon, 28 Mar 2022 22:16:43 GMT, Naoto Sato wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added an @apiNote describing the single array argument src/java.base/share/classes/sun/util/locale/provider/JRELocaleConstants.java line 38: > 36: */ > 37: public class JRELocaleConstants { > 38: public static final Locale JA_JP_JP = Locale.forLanguageTag("ja-JP-x-lvariant-JP"); You might use the new factory here. src/java.base/share/classes/sun/util/resources/LocaleData.java line 249: > 247: // TODO: avoid hard-coded Locales > 248: private static final Set JAVA_BASE_LOCALES > 249: = Set.of(Locale.ROOT, Locale.ENGLISH, Locale.US, Locale.forLanguageTag("en-US-POSIX")); Use new factory? ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From redestad at openjdk.java.net Tue Mar 29 15:27:28 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 15:27:28 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay [v3] In-Reply-To: References: Message-ID: > In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. > > This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: typo: to -> of ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8014/files - new: https://git.openjdk.java.net/jdk/pull/8014/files/44a11aa7..ef0ca1b3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8014&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8014&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8014.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8014/head:pull/8014 PR: https://git.openjdk.java.net/jdk/pull/8014 From duke at openjdk.java.net Tue Mar 29 15:52:42 2022 From: duke at openjdk.java.net (liach) Date: Tue, 29 Mar 2022 15:52:42 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v17] In-Reply-To: <5s7NFFHFPJsmdljZf0NUXOWMsJeQd-c2C_X06xeU3ww=.59bccb19-01a6-43b8-bcfe-d900e455348f@github.com> References: <5s7NFFHFPJsmdljZf0NUXOWMsJeQd-c2C_X06xeU3ww=.59bccb19-01a6-43b8-bcfe-d900e455348f@github.com> Message-ID: On Tue, 29 Mar 2022 13:58:56 GMT, ExE Boss wrote: >> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: >> >> Add condy static methods > > src/java.base/share/classes/java/lang/runtime/Carrier.java line 335: > >> 333: CarrierArray(int primitiveCount, int objectCount) { >> 334: this.primitives = >> 335: primitiveCount != 0 ? new long[(primitiveCount + 1) / 2] : null; > > It?might be?better to?use an?unsigned?shift here: > Suggestion: > > primitiveCount != 0 ? new long[(primitiveCount + 1) >>> 1] : null; doesn't the compiler (either javac or hotspot) automatically do that? ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From bpb at openjdk.java.net Tue Mar 29 15:55:51 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Tue, 29 Mar 2022 15:55:51 GMT Subject: RFR: 8283846: Remove unused jdk.internal.reflect.SignatureIterator In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 09:15:01 GMT, Andrey Turbanov wrote: > It was no longer used due to JDK-4479184 long ago. It builds so looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8013 From jlaskey at openjdk.java.net Tue Mar 29 15:59:50 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 29 Mar 2022 15:59:50 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v17] In-Reply-To: References: <5s7NFFHFPJsmdljZf0NUXOWMsJeQd-c2C_X06xeU3ww=.59bccb19-01a6-43b8-bcfe-d900e455348f@github.com> Message-ID: On Tue, 29 Mar 2022 15:49:51 GMT, liach wrote: >> src/java.base/share/classes/java/lang/runtime/Carrier.java line 335: >> >>> 333: CarrierArray(int primitiveCount, int objectCount) { >>> 334: this.primitives = >>> 335: primitiveCount != 0 ? new long[(primitiveCount + 1) / 2] : null; >> >> It?might be?better to?use an?unsigned?shift here: >> Suggestion: >> >> primitiveCount != 0 ? new long[(primitiveCount + 1) >>> 1] : null; > > doesn't the compiler (either javac or hotspot) automatically do that? Yes, the compilers handle this. I did however switch to primitiveCount != 0 ? new long[(primitiveCount + 1) / LONG_SLOTS] : null; ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From smarks at openjdk.java.net Tue Mar 29 16:07:18 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 29 Mar 2022 16:07:18 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v2] In-Reply-To: References: Message-ID: > Pretty much just what it says. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Adjust nonfinal CSMs and rework error reporting in CheckCSMs.java test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8009/files - new: https://git.openjdk.java.net/jdk/pull/8009/files/4b9bf990..77b6d79f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8009&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8009&range=00-01 Stats: 8 lines in 1 file changed: 2 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8009/head:pull/8009 PR: https://git.openjdk.java.net/jdk/pull/8009 From smarks at openjdk.java.net Tue Mar 29 16:14:41 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Tue, 29 Mar 2022 16:14:41 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 16:07:18 GMT, Stuart Marks wrote: >> Pretty much just what it says. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Adjust nonfinal CSMs and rework error reporting in CheckCSMs.java test Yes, the CheckCSMs test needed to be updated to remove ObjectStreamClass#forClass from the list of non-final CSMs, as that method is now part of a final class. The error message about ObjectStreamField#getType is misleading; I've fixed up the error reporting for this case. It would indeed be interesting to make adjustments to ObjectStreamField. However, it's publicly subclassable, and it's not serializable, so a different set of dynamics apply. I'd like to consider that effort separately from this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From joehw at openjdk.java.net Tue Mar 29 16:47:10 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 29 Mar 2022 16:47:10 GMT Subject: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables Message-ID: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> Resets state of a Catalog instance on each matching call so that it can be reused. Adjusts CatalogResolver's resolve routine so that it continues to observes the PREFER feature in a resolution process. Without the adjustment, PreferFeatureTest would fail. Mach5 XML tests passed: https://mach5.us.oracle.com/mdash/jobs/huizwang-open-20220329-0148-30563542 ------------- Commit messages: - 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables Changes: https://git.openjdk.java.net/jdk/pull/8018/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8018&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253569 Stats: 220 lines in 5 files changed: 198 ins; 18 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/8018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8018/head:pull/8018 PR: https://git.openjdk.java.net/jdk/pull/8018 From mchung at openjdk.java.net Tue Mar 29 16:54:48 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 29 Mar 2022 16:54:48 GMT Subject: RFR: 8283846: Remove unused jdk.internal.reflect.SignatureIterator In-Reply-To: References: Message-ID: <7DZfRbhgwOhOG2munUyisBtzcSo18pNEXVxyx0UJ_IE=.20f83cd5-919c-479e-9342-4ca2fde11496@github.com> On Tue, 29 Mar 2022 09:15:01 GMT, Andrey Turbanov wrote: > It was no longer used due to JDK-4479184 long ago. Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8013 From mchung at openjdk.java.net Tue Mar 29 16:57:40 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 29 Mar 2022 16:57:40 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 16:07:18 GMT, Stuart Marks wrote: >> Pretty much just what it says. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Adjust nonfinal CSMs and rework error reporting in CheckCSMs.java test Marked as reviewed by mchung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From iris at openjdk.java.net Tue Mar 29 16:59:47 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 29 Mar 2022 16:59:47 GMT Subject: RFR: 8283846: Remove unused jdk.internal.reflect.SignatureIterator In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 09:15:01 GMT, Andrey Turbanov wrote: > It was no longer used due to JDK-4479184 long ago. Nice clean-up. ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8013 From dfuchs at openjdk.java.net Tue Mar 29 17:03:56 2022 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Tue, 29 Mar 2022 17:03:56 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 16:07:18 GMT, Stuart Marks wrote: >> Pretty much just what it says. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Adjust nonfinal CSMs and rework error reporting in CheckCSMs.java test Nice update to the test! ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8009 From mchung at openjdk.java.net Tue Mar 29 17:03:56 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 29 Mar 2022 17:03:56 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 16:07:18 GMT, Stuart Marks wrote: >> Pretty much just what it says. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Adjust nonfinal CSMs and rework error reporting in CheckCSMs.java test Looks good. Thanks for improving the error reporting in CheckCSMs test. ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From naoto at openjdk.java.net Tue Mar 29 17:11:38 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 29 Mar 2022 17:11:38 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay [v3] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 15:27:28 GMT, Claes Redestad wrote: >> In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. >> >> This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > typo: to -> of Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8014 From psandoz at openjdk.java.net Tue Mar 29 17:15:42 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 29 Mar 2022 17:15:42 GMT Subject: RFR: 8283470: Update java.lang.invoke.VarHandle to use sealed classes In-Reply-To: References: Message-ID: <_STINvbpx6xcv-Ksq6loBrN90B-AIlxfKZJJFVYcgZU=.25e708e9-1414-492b-a4f9-7820b5c44389@github.com> On Wed, 23 Mar 2022 16:27:29 GMT, Mandy Chung wrote: > This patch changes VarHandle and its implementation hierarchy to use sealed classes. All VarHandle permitted classes are package-private and either final or sealed abstract classes. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8283540 Marked as reviewed by psandoz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/7926 From psandoz at openjdk.java.net Tue Mar 29 17:35:46 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 29 Mar 2022 17:35:46 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v4] In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 23:22:31 GMT, Mandy Chung wrote: >> A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. > > Mandy Chung has updated the pull request incrementally with one additional commit since the last revision: > > per feedback Moving the check under the `!isInstance(recv)` check is better. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7766 From psandoz at openjdk.java.net Tue Mar 29 18:08:43 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Tue, 29 Mar 2022 18:08:43 GMT Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3] In-Reply-To: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> References: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> Message-ID: On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong wrote: >> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. >> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. >> >> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: >> - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. >> - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. >> >> So with this patch, the following transformations are applied: >> >> For non-masked negation with NEON: >> >> movi v16.4s, #0x0 >> sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s >> >> and with SVE: >> >> mov z16.s, #0 >> sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s >> >> For masked negation with NEON: >> >> movi v17.4s, #0x1 >> mvn v19.16b, v18.16b >> mov v20.16b, v16.16b ==> neg v18.4s, v17.4s >> bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b >> add v19.4s, v20.4s, v17.4s >> mov v18.16b, v16.16b >> bsl v18.16b, v19.16b, v20.16b >> >> and with SVE: >> >> mov z16.s, #-1 >> mov z17.s, #1 ==> neg z16.s, p0/m, z16.s >> eor z18.s, p0/m, z18.s, z16.s >> add z18.s, p0/m, z18.s, z17.s >> >> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): >> >> NEON: >> Benchmark Gain >> Byte128Vector.NEG 1.029 >> Byte128Vector.NEGMasked 1.757 >> Short128Vector.NEG 1.041 >> Short128Vector.NEGMasked 1.659 >> Int128Vector.NEG 1.005 >> Int128Vector.NEGMasked 1.513 >> Long128Vector.NEG 1.003 >> Long128Vector.NEGMasked 1.878 >> >> SVE with 512-bits: >> Benchmark Gain >> ByteMaxVector.NEG 1.10 >> ByteMaxVector.NEGMasked 1.165 >> ShortMaxVector.NEG 1.056 >> ShortMaxVector.NEGMasked 1.195 >> IntMaxVector.NEG 1.002 >> IntMaxVector.NEGMasked 1.239 >> LongMaxVector.NEG 1.031 >> LongMaxVector.NEGMasked 1.191 >> >> X86 (non AVX-512): >> Benchmark Gain >> ByteMaxVector.NEGMasked 1.254 >> ShortMaxVector.NEGMasked 1.359 >> IntMaxVector.NEGMasked 1.431 >> LongMaxVector.NEGMasked 1.989 >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Make "degenerate_vector_integral_negate" to be "NegVI" private Java changes are good. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7782 From mcimadamore at openjdk.java.net Tue Mar 29 18:13:05 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 29 Mar 2022 18:13:05 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v12] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 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 27 additional commits since the last revision: - Use thread local storage to optimize attach of async threads - Drop support for Constable from MemoryLayout/FunctionDescriptor - Merge branch 'master' into foreign-preview - Revert changes to RunTests.gmk - Add --enable-preview to micro benchmark java options - Address more review comments - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java Co-authored-by: Jorn Vernee - Address review comments - Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java Co-authored-by: Jorn Vernee - ... and 17 more: https://git.openjdk.java.net/jdk/compare/02333d66...55aee872 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/504b564a..55aee872 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=10-11 Stats: 99257 lines in 1550 files changed: 79659 ins; 15544 del; 4054 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From mcimadamore at openjdk.java.net Tue Mar 29 18:23:41 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 29 Mar 2022 18:23:41 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v13] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Switch to daemon threads for async upcalls ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/55aee872..43dc6be3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=12 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From lancea at openjdk.java.net Tue Mar 29 18:30:01 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 29 Mar 2022 18:30:01 GMT Subject: RFR: 8283889: Fix typo in package-info.java Message-ID: Hi all, Please review this trivial fix which addresses a typo in src/java.sql/share/classes/java/sql/package-info.java make docs is clean and I am also running mach5 tier1 as an extra sanity check so there are no surprises when the patch is pushed Best Lance ------------- Commit messages: - Fix typo in package-info.java Changes: https://git.openjdk.java.net/jdk/pull/8020/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8020&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283889 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8020.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8020/head:pull/8020 PR: https://git.openjdk.java.net/jdk/pull/8020 From joehw at openjdk.java.net Tue Mar 29 18:35:45 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Tue, 29 Mar 2022 18:35:45 GMT Subject: RFR: 8283889: Fix typo in package-info.java In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 18:23:31 GMT, Lance Andersen wrote: > Hi all, > > Please review this trivial fix which addresses a typo in src/java.sql/share/classes/java/sql/package-info.java > > make docs is clean and I am also running mach5 tier1 as an extra sanity check so there are no surprises when the patch is pushed > > Best > Lance Marked as reviewed by joehw (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8020 From jlaskey at openjdk.java.net Tue Mar 29 18:51:36 2022 From: jlaskey at openjdk.java.net (Jim Laskey) Date: Tue, 29 Mar 2022 18:51:36 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v18] In-Reply-To: References: Message-ID: > We propose to provide a runtime anonymous carrier class object generator; java.lang.runtime.Carrier. This generator class is designed to share anonymous classes when shapes are similar. For example, if several clients require objects containing two integer fields, then Carrier will ensure that each client generates carrier objects using the same underlying anonymous class. > > See JBS for details. Jim Laskey has updated the pull request incrementally with one additional commit since the last revision: Use LONG_SLOTS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7744/files - new: https://git.openjdk.java.net/jdk/pull/7744/files/23122263..f9c8730a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=17 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7744&range=16-17 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7744.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7744/head:pull/7744 PR: https://git.openjdk.java.net/jdk/pull/7744 From duke at openjdk.java.net Tue Mar 29 19:02:43 2022 From: duke at openjdk.java.net (ExE Boss) Date: Tue, 29 Mar 2022 19:02:43 GMT Subject: RFR: JDK-8282798 java.lang.runtime.Carrier [v17] In-Reply-To: References: <5s7NFFHFPJsmdljZf0NUXOWMsJeQd-c2C_X06xeU3ww=.59bccb19-01a6-43b8-bcfe-d900e455348f@github.com> Message-ID: On Tue, 29 Mar 2022 15:56:37 GMT, Jim Laskey wrote: >> doesn't the compiler (either javac or hotspot) automatically do that? > > Yes, the compilers handle this. I did however switch to > > > primitiveCount != 0 ? new long[(primitiveCount + 1) / LONG_SLOTS] : null; > doesn't the compiler (either javac or hotspot) automatically do that? Only?for?multiplication, because `-1?>>?1?==?-1`, `-1?>>>?1?==?Integer.MAX_VALUE`, and?`-1?/?2?==?0`. ------------- PR: https://git.openjdk.java.net/jdk/pull/7744 From redestad at openjdk.java.net Tue Mar 29 19:52:46 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 19:52:46 GMT Subject: RFR: 8283782: Redundant verification of year in LocalDate::ofEpochDay [v3] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 15:27:28 GMT, Claes Redestad wrote: >> In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. >> >> This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. > > Claes Redestad has updated the pull request incrementally with one additional commit since the last revision: > > typo: to -> of Thanks for reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/8014 From redestad at openjdk.java.net Tue Mar 29 19:52:47 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Tue, 29 Mar 2022 19:52:47 GMT Subject: Integrated: 8283782: Redundant verification of year in LocalDate::ofEpochDay In-Reply-To: References: Message-ID: <-NdRQPnHz8pi2M19zaI9kTNjXsfOeFyIB70bzVM7YQs=.0f762e25-c414-4ae9-a836-c37238807512@github.com> On Tue, 29 Mar 2022 10:37:20 GMT, Claes Redestad wrote: > In `LocalDate::ofEpochDays` we validate the epoch day input, then we also validate the year derived from that value. This second validation is redundant since the minimum and maximum valid epoch day line up with the first and last day of the minimum and maximum valid year, respectively. This patch replace this redundant runtime validation with a test. > > This reduces code complexity (increasing chance for inlining to happen) and removes a couple of branches from generated code. This pull request has now been integrated. Changeset: 072f2c46 Author: Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/072f2c461e8b0f10bdecadda31b3facfbe6da681 Stats: 39 lines in 2 files changed: 34 ins; 2 del; 3 mod 8283782: Redundant verification of year in LocalDate::ofEpochDay Reviewed-by: rriggs, naoto ------------- PR: https://git.openjdk.java.net/jdk/pull/8014 From mchung at openjdk.java.net Tue Mar 29 20:02:36 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 29 Mar 2022 20:02:36 GMT Subject: RFR: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver [v5] In-Reply-To: References: Message-ID: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. Mandy Chung 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: - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8282776 - per feedback - Add exception message - Move the null check after isInstance check - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8282776 - JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7766/files - new: https://git.openjdk.java.net/jdk/pull/7766/files/55c38cf8..5c1d777b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7766&range=03-04 Stats: 124526 lines in 1656 files changed: 92323 ins; 27724 del; 4479 mod Patch: https://git.openjdk.java.net/jdk/pull/7766.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7766/head:pull/7766 PR: https://git.openjdk.java.net/jdk/pull/7766 From mchung at openjdk.java.net Tue Mar 29 20:02:36 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 29 Mar 2022 20:02:36 GMT Subject: Integrated: JDK-8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver In-Reply-To: References: Message-ID: On Wed, 9 Mar 2022 22:52:41 GMT, Mandy Chung wrote: > A simple patch to call `Objects.requireNonNull(recv)` for an explicit null receiver check rather than NPE thrown by `Object::getClass`. The message of NPE generated by JEP 358 (Helpful NullPointerExceptions) is supposed to be helpful but not in this case. This pull request has now been integrated. Changeset: 489b27d2 Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/489b27d2c0284f9248bfb0448950698a3f9dee36 Stats: 16 lines in 1 file changed: 10 ins; 0 del; 6 mod 8282776: Bad NullPointerException message when invoking an interface MethodHandle on a null receiver Reviewed-by: psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/7766 From iris at openjdk.java.net Tue Mar 29 20:13:54 2022 From: iris at openjdk.java.net (Iris Clark) Date: Tue, 29 Mar 2022 20:13:54 GMT Subject: RFR: 8283889: Fix typo in package-info.java In-Reply-To: References: Message-ID: <69RHiiPheNsxFtbnygzbKDpYTG-vtxLGvgrNAU7QFmM=.6b7e9405-cb33-4e95-b062-57197347c061@github.com> On Tue, 29 Mar 2022 18:23:31 GMT, Lance Andersen wrote: > Hi all, > > Please review this trivial fix which addresses a typo in src/java.sql/share/classes/java/sql/package-info.java > > make docs is clean and I am also running mach5 tier1 as an extra sanity check so there are no surprises when the patch is pushed > > Best > Lance Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8020 From mchung at openjdk.java.net Tue Mar 29 20:14:25 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Tue, 29 Mar 2022 20:14:25 GMT Subject: RFR: 8283060: RawNativeLibraries should allow multiple clients to load/unload the same library Message-ID: A small improvement to `RawNativeLibraries`. `RawNativeLibraries::load` returns the same `NativeLibrary` instance of a given path if it's called multiple times. This means that multiple clients have to coordinate that the last one using the loaded library is the one to close the library by calling `RawNativeLibraries::unload`; otherwise, an exception may be thrown. This patch changes `RawNativeLibraries::load` to delegate to the underlying platform-specific library loading mechanism e.g. dlopen/dlclose that keeps the reference count. So each call to `RawNativeLibraries::load` and `unload` is simply a call to dlopen and dlclose respectively. Each client of calling `RawNativeLibraries::load` is responsible for calling `RawNativeLibraries::unload`. This will be consistent with the current behavior when you call `load` and `unload` with a different `RawNativeLibraries` instance. ------------- Commit messages: - 8283060: RawNativeLibraries should allow multiple clients to load/unload the same library Changes: https://git.openjdk.java.net/jdk/pull/8022/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8022&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283060 Stats: 66 lines in 3 files changed: 43 ins; 10 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/8022.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8022/head:pull/8022 PR: https://git.openjdk.java.net/jdk/pull/8022 From lancea at openjdk.java.net Tue Mar 29 20:42:47 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 29 Mar 2022 20:42:47 GMT Subject: Integrated: 8283889: Fix Typo in open/src/java.sql/share/classes/java/sql/package-info.java In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 18:23:31 GMT, Lance Andersen wrote: > Hi all, > > Please review this trivial fix which addresses a typo in src/java.sql/share/classes/java/sql/package-info.java > > make docs is clean and I am also running mach5 tier1 as an extra sanity check so there are no surprises when the patch is pushed > > Best > Lance This pull request has now been integrated. Changeset: 272d6531 Author: Lance Andersen URL: https://git.openjdk.java.net/jdk/commit/272d6531ef94534d2044377f126744b5139f7ae9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8283889: Fix Typo in open/src/java.sql/share/classes/java/sql/package-info.java Reviewed-by: joehw, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/8020 From naoto at openjdk.java.net Tue Mar 29 21:28:44 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 29 Mar 2022 21:28:44 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v7] In-Reply-To: References: Message-ID: > Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Changed from var-args to conventional args. Reflected suggestions. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7947/files - new: https://git.openjdk.java.net/jdk/pull/7947/files/b1d36b52..8ac9d11d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7947&range=05-06 Stats: 132 lines in 4 files changed: 76 ins; 3 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/7947.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7947/head:pull/7947 PR: https://git.openjdk.java.net/jdk/pull/7947 From lancea at openjdk.java.net Tue Mar 29 21:30:43 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Tue, 29 Mar 2022 21:30:43 GMT Subject: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables In-Reply-To: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> References: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> Message-ID: <1N_EVqYG6MbVBBRDaeAGSyC7L2Q5AY3XlZmOcds5Z_E=.b99a2918-74e5-4cb7-ae9b-d4b88eab396d@github.com> On Tue, 29 Mar 2022 16:39:50 GMT, Joe Wang wrote: > Resets state of a Catalog instance on each matching call so that it can be reused. Adjusts CatalogResolver's resolve routine so that it continues to observes the PREFER feature in a resolution process. Without the adjustment, PreferFeatureTest would fail. > > Mach5 XML tests passed: https://mach5.us.oracle.com/mdash/jobs/huizwang-open-20220329-0148-30563542 looks fine Joe ------------- Marked as reviewed by lancea (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8018 From naoto at openjdk.java.net Tue Mar 29 21:34:52 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 29 Mar 2022 21:34:52 GMT Subject: RFR: 8282819: Deprecate Locale class constructors [v7] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 21:28:44 GMT, Naoto Sato wrote: >> Proposing to deprecate the constructors in the `java.util.Locale` class. There is already a factory method and a builder to return singletons, so there is no need to have constructors anymore unless one purposefully wants to create `ill-formed` Locale objects, which is discouraged. We cannot terminally deprecate those constructors for the compatibility to serialized objects created with older JDKs. Please see the draft CSR for more detail. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Changed from var-args to conventional args. Reflected suggestions. Per a comment in the CSR discussion (https://bugs.openjdk.java.net/browse/JDK-8283478?focusedCommentId=14485037&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14485037), I changed the arguments to var-args to conventional ones. ------------- PR: https://git.openjdk.java.net/jdk/pull/7947 From naoto at openjdk.java.net Tue Mar 29 21:45:40 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Tue, 29 Mar 2022 21:45:40 GMT Subject: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables In-Reply-To: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> References: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> Message-ID: On Tue, 29 Mar 2022 16:39:50 GMT, Joe Wang wrote: > Resets state of a Catalog instance on each matching call so that it can be reused. Adjusts CatalogResolver's resolve routine so that it continues to observes the PREFER feature in a resolution process. Without the adjustment, PreferFeatureTest would fail. > > Mach5 XML tests passed: https://mach5.us.oracle.com/mdash/jobs/huizwang-open-20220329-0148-30563542 src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java line 44: > 42: > 43: //Indicates whether this is the Catalog instance (vs a Catalog entry) > 44: boolean isCatalogInstance = false; Can we eliminate this instance variable, by checking whether the type is `Catalog` or not in `resetOnStart()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/8018 From duke at openjdk.java.net Tue Mar 29 22:07:49 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 29 Mar 2022 22:07:49 GMT Subject: RFR: 8283726: x86 intrinsics for compare method in Integer and Long In-Reply-To: References: Message-ID: On Sun, 27 Mar 2022 06:57:58 GMT, Quan Anh Mai wrote: > This is both complicated and inefficient, I would suggest building the intrinsic in the IR graph so that the compiler can simplify `Integer.compareUnsigned(x, y) < 0` into `x u< y`. Thanks. Thank you for the suggestion! This intrinsic uses 1 cmp instruction instead of two and shows ~10% improvement due to better branch prediction. Even without the intrinsic, the compiler is currently able to reduce it to x u< y but is still generating two cmp (unsigned) instructions as Integer.compareUnsigned(x, y) is implemented as x u< y? -1 : (x ==y ? 0 : 1). ------------- PR: https://git.openjdk.java.net/jdk/pull/7975 From duke at openjdk.java.net Tue Mar 29 22:07:52 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Tue, 29 Mar 2022 22:07:52 GMT Subject: RFR: 8283726: x86 intrinsics for compare method in Integer and Long In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 02:24:21 GMT, Jatin Bhateja wrote: >> Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long. > > src/hotspot/cpu/x86/x86_64.ad line 12107: > >> 12105: instruct compareSignedI_rReg(rRegI dst, rRegI op1, rRegI op2, rRegI tmp, rFlagsReg cr) >> 12106: %{ >> 12107: match(Set dst (CompareSignedI op1 op2)); > > Please also include these patterns in x86_32.ad Will update x86_32.ad as well. > src/hotspot/cpu/x86/x86_64.ad line 12125: > >> 12123: __ movl(tmp, 0); >> 12124: __ bind(done); >> 12125: __ movl(dest, tmp); > > Please move this in macro-assembly routine. Sure, will refactor it into a macro-assembly > src/hotspot/cpu/x86/x86_64.ad line 12178: > >> 12176: __ movl(tmp, 0); >> 12177: __ bind(done); >> 12178: __ movl(dest, tmp); > > Please move this into a macro-assembly routine. Sure, will do that and update it soon. > src/hotspot/cpu/x86/x86_64.ad line 12204: > >> 12202: __ movl(tmp, 0); >> 12203: __ bind(done); >> 12204: __ movl(dest, tmp); > > Please move this into macro-assembly routine. Sure, will do that and update it soon. > src/hotspot/share/opto/comparenode.hpp line 67: > >> 65: CompareUnsignedLNode(Node* in1, Node* in2) : CompareNode(in1, in2) {} >> 66: virtual int Opcode() const; >> 67: }; > > Intent here seems to be to enable further auto-vectorization of newly create IR nodes. Yes, that is the intention. > test/micro/org/openjdk/bench/java/lang/CompareInteger.java line 78: > >> 76: input2[i] = tmp; >> 77: } >> 78: } > > Logic re-organization suggestion:- > > > for (int i = 0 ; i < BUFFER_SIZE; i++) { > input1[i] = rng.nextLong(); > } > > if (mode.equals("equals") { > GRADIANT = 0; > } else if (mode.equals("greaterThanEquals")) { > GRADIANT = 1; > } else { > assert mode.equals("lessThanEqual"); > GRADIANT = -1; > } > > for(int i = 0 ; i < BUFFER_SIZE; i++) { > input2[i] = input1[i] + i*GRADIANT; > } The suggested refactoring is definitely elegant but one rare possibility is overflow due to the addition/subtraction. The swap logic doesn't have that problem. > test/micro/org/openjdk/bench/java/lang/CompareLong.java line 5: > >> 3: * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> 4: * >> 5: * This code is free software; you can redistribute it and/or modify it > > We can unify this benchmark along with integer compare micro. Sure, will do the unification. ------------- PR: https://git.openjdk.java.net/jdk/pull/7975 From duke at openjdk.java.net Tue Mar 29 23:30:38 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Tue, 29 Mar 2022 23:30:38 GMT Subject: RFR: 8283726: x86 intrinsics for compare method in Integer and Long In-Reply-To: References: Message-ID: <-6o83x73qUUHraAA9swfhdp-G8PGu9xOvVTLGeOcGtI=.b8db34be-79fd-4a7d-94e6-6a44fd2a4892@github.com> On Tue, 29 Mar 2022 21:56:18 GMT, Vamsi Parasa wrote: >> This is both complicated and inefficient, I would suggest building the intrinsic in the IR graph so that the compiler can simplify `Integer.compareUnsigned(x, y) < 0` into `x u< y`. Thanks. > >> This is both complicated and inefficient, I would suggest building the intrinsic in the IR graph so that the compiler can simplify `Integer.compareUnsigned(x, y) < 0` into `x u< y`. Thanks. > > Thank you for the suggestion! This intrinsic uses 1 cmp instruction instead of two and shows ~10% improvement due to better branch prediction. Even without the intrinsic, the compiler is currently able to reduce it to x u< y but is still generating two cmp (unsigned) instructions as Integer.compareUnsigned(x, y) is implemented as x u< y? -1 : (x ==y ? 0 : 1). @vamsi-parasa But normally the result of the `compare` methods is not used as a raw integer (it is useless to do so since the methods do not have any promise regarding the value of the result, only its sign). The idiom is to compare the result with 0, such as `Integer.compare(x, y) > 0`, the compiler can reduce this to `x > y` (last time I checked it does not do so but in principle this is possible). Your intrinsic prevents the compiler to do such transformations, hurting the performance of real programs. > Even without the intrinsic, the compiler is currently able to reduce it to x u< y It is because the compiler can recognise the pattern `x + MIN_VALUE < y + MIN_VALUE` and transforms it into `x u< y`. This transformation is fragile however if one of the arguments is in the form `x + con`, in such cases constant propagation may lead to slight deviations from recognised patterns, defeat the transformations. As a result, it may be justifiable to have a dedicated intrinsic for that since unsigned comparisons are pretty basic operations that are needed for optimal range check performance. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/7975 From smarks at openjdk.java.net Wed Mar 30 00:16:41 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 30 Mar 2022 00:16:41 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: References: Message-ID: On Thu, 24 Mar 2022 17:43:31 GMT, XenoAmess wrote: >> 8186958: Need method to create pre-sized HashMap > > XenoAmess has updated the pull request incrementally with two additional commits since the last revision: > > - update jmh > - refine javadoc; refine implement when expectedSize < 0 OK, finally got some time to look at this. Here's a rewrite of the spec words, at least for HashMap::newHashMap. If this settles down, I'll write the CSR for this and LHM and WHM. /** * Creates a new, empty HashMap suitable for the expected number of mappings. * The returned map uses the default load factor of 0.75, and its initial capacity is * generally large enough so that the expected number of mappings can be added * without resizing the map. * * @param numMappings the expected number of mappings * @param the type of keys maintained by this map * @param the type of mapped values * @return the newly created map * @throws IllegalArgumentException if numMappings is negative * @since 19 */ The original wording was taken from CHM, which generally is a reasonable thing to do. Unfortunately, it's wrong. :-) "Table size" isn't accurate; HashMap uses "capacity" as the term for the number of buckets (== length of the internal table array). "Size" means "number of mappings" so its use of "table size" confuses these two concepts. The CHM wording also uses "elements" which applies to linear collections; the things inside a map are usually referred to as "mappings" or "entries". (I guess we should fix up CHM at some point too.) While "expectedSize" isn't inaccurate, it's not tied to the main text, so I've renamed it to numMappings. There are a couple other javadoc style rules operating here. The first sentence is generally a sentence fragment that is short and descriptive, as it will be pulled into a summary table. (It's often written as if it were a sentence that begins "This method..." but those words are elided.) Details are in the rest of the first paragraph. The text for `@param`, `@return`, and `@throws` are generally also sentence fragments, and they have no initial capital letter nor trailing period. -- On performance and benchmarking: this is a distraction from the main point of this effort, which is to add an API that allows callers a correct and convenient way to create a properly-sized HashMap. Any work spent on optimizing performance is almost certainly wasted. First, the benchmark: it's entirely unclear what this is measuring. It's performing the operation 2^31 times, but it sends the result to a black hole so that the JIT doesn't eliminate the computation. One of the actual results is 0.170 ops/sec. This includes both the operation and the black hole, so we don't actually have any idea what that result represents. _Maybe_ it's possible to infer some idea of relative performance of the different operations by comparing the results. It's certainly plausible that the integer code is faster than the float or double code. But the benchmark doesn't tell us how long the actual computation takes. Second, how significant is the cost of the computation? I'll assert that it's insignificant. The table length is computed once at HashMap creation time, and it's amortized over the addition of all the initial entries and subsequent queries and updates to the HashMap. Any of the computations (whether integer or floating point) are a handful of nanoseconds. This will be swamped by the first hashCode computation that causes a cache miss. Third: I'll stipulate that the integer computation is probably a few ns faster than the floating-point computation. But the computation is entirely non-obvious. To make up for it being non-obvious, there's a big comment that explains it all. It's not worth doing something that increases performance by an insignificant amount that also requires a big explanation. Finally, note that most of the callers are already doing a floating-point computation to compute the desired capacity, and it doesn't seem to be a problem. Sorry, you probably spent a bunch of time on this already, but trying to optimize the performance here just isn't worthwhile. Let's please just stick with our good old `(int) Math.ceil(numMappings / 0.75)`. -- There should be regression tests added for the three new methods. I haven't thought much about this. It might be possible to reuse some of the infrastructure in the WhiteBoxResizeTest we worked on previously. -- I think it would be good to include updates to some of the use sites in this PR. It's often useful to put new APIs into practice. One usually learns something from the effort. Even though this is a really simple API, looking at use sites can illuminating, to see how the code reads. This might affect the method name, for example. You don't need to update all of the use sites in the JDK, but it would be good to choose a reasonable sample. Maybe the ones from a single package, or a handful (like java.lang or java.util). Maybe include Class::enumConstantDirectory. If this use site is updated, then maybe it will allow us to get rid of that ConstantDirectoryOptimalCapacity test that we problem-listed in the previous PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From joehw at openjdk.java.net Wed Mar 30 00:46:49 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 30 Mar 2022 00:46:49 GMT Subject: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables [v2] In-Reply-To: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> References: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> Message-ID: > Resets state of a Catalog instance on each matching call so that it can be reused. Adjusts CatalogResolver's resolve routine so that it continues to observes the PREFER feature in a resolution process. Without the adjustment, PreferFeatureTest would fail. > > Mach5 XML tests passed: https://mach5.us.oracle.com/mdash/jobs/huizwang-open-20220329-0148-30563542 Joe Wang has updated the pull request incrementally with one additional commit since the last revision: remove variable, check instance instead. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8018/files - new: https://git.openjdk.java.net/jdk/pull/8018/files/14513d7b..16bebbcf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8018&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8018&range=00-01 Stats: 6 lines in 2 files changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8018.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8018/head:pull/8018 PR: https://git.openjdk.java.net/jdk/pull/8018 From joehw at openjdk.java.net Wed Mar 30 00:46:52 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 30 Mar 2022 00:46:52 GMT Subject: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables [v2] In-Reply-To: References: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> Message-ID: On Tue, 29 Mar 2022 21:41:52 GMT, Naoto Sato wrote: >> Joe Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> remove variable, check instance instead. > > src/java.xml/share/classes/javax/xml/catalog/GroupEntry.java line 44: > >> 42: >> 43: //Indicates whether this is the Catalog instance (vs a Catalog entry) >> 44: boolean isCatalogInstance = false; > > Can we eliminate this instance variable, by checking whether the type is `Catalog` or not in `resetOnStart()`? Yes, thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8018 From jpai at openjdk.java.net Wed Mar 30 00:47:39 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 30 Mar 2022 00:47:39 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v2] In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 16:07:18 GMT, Stuart Marks wrote: >> Pretty much just what it says. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Adjust nonfinal CSMs and rework error reporting in CheckCSMs.java test Hello Stuart, the test change looks fine to me. Just a minor note - the copyright year of the test will need an update. ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From achung at openjdk.java.net Wed Mar 30 00:54:29 2022 From: achung at openjdk.java.net (Alisen Chung) Date: Wed, 30 Mar 2022 00:54:29 GMT Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10 Message-ID: redo of 8280400 ------------- Commit messages: - 8280400: JDK 19 L10n resource files update - msgdrop 10 Changes: https://git.openjdk.java.net/jdk/pull/8026/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8026&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283805 Stats: 11316 lines in 139 files changed: 9124 ins; 1252 del; 940 mod Patch: https://git.openjdk.java.net/jdk/pull/8026.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8026/head:pull/8026 PR: https://git.openjdk.java.net/jdk/pull/8026 From njian at openjdk.java.net Wed Mar 30 01:24:45 2022 From: njian at openjdk.java.net (Ningsheng Jian) Date: Wed, 30 Mar 2022 01:24:45 GMT Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3] In-Reply-To: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> References: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> Message-ID: <7Vq50g457PgQqxorybsnpP2N4frte8_-AKtJCHY5OdU=.cdf5b05c-fc17-4c63-b522-8866aa3bceb9@github.com> On Mon, 28 Mar 2022 09:56:22 GMT, Xiaohong Gong wrote: >> The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. >> And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. >> >> To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: >> - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. >> - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. >> >> So with this patch, the following transformations are applied: >> >> For non-masked negation with NEON: >> >> movi v16.4s, #0x0 >> sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s >> >> and with SVE: >> >> mov z16.s, #0 >> sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s >> >> For masked negation with NEON: >> >> movi v17.4s, #0x1 >> mvn v19.16b, v18.16b >> mov v20.16b, v16.16b ==> neg v18.4s, v17.4s >> bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b >> add v19.4s, v20.4s, v17.4s >> mov v18.16b, v16.16b >> bsl v18.16b, v19.16b, v20.16b >> >> and with SVE: >> >> mov z16.s, #-1 >> mov z17.s, #1 ==> neg z16.s, p0/m, z16.s >> eor z18.s, p0/m, z18.s, z16.s >> add z18.s, p0/m, z18.s, z17.s >> >> Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): >> >> NEON: >> Benchmark Gain >> Byte128Vector.NEG 1.029 >> Byte128Vector.NEGMasked 1.757 >> Short128Vector.NEG 1.041 >> Short128Vector.NEGMasked 1.659 >> Int128Vector.NEG 1.005 >> Int128Vector.NEGMasked 1.513 >> Long128Vector.NEG 1.003 >> Long128Vector.NEGMasked 1.878 >> >> SVE with 512-bits: >> Benchmark Gain >> ByteMaxVector.NEG 1.10 >> ByteMaxVector.NEGMasked 1.165 >> ShortMaxVector.NEG 1.056 >> ShortMaxVector.NEGMasked 1.195 >> IntMaxVector.NEG 1.002 >> IntMaxVector.NEGMasked 1.239 >> LongMaxVector.NEG 1.031 >> LongMaxVector.NEGMasked 1.191 >> >> X86 (non AVX-512): >> Benchmark Gain >> ByteMaxVector.NEGMasked 1.254 >> ShortMaxVector.NEGMasked 1.359 >> IntMaxVector.NEGMasked 1.431 >> LongMaxVector.NEGMasked 1.989 >> >> [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 >> [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 > > Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: > > Make "degenerate_vector_integral_negate" to be "NegVI" private AArch64 changes look good to me. ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/jdk/pull/7782 From dongbohe at openjdk.java.net Wed Mar 30 01:28:36 2022 From: dongbohe at openjdk.java.net (Dongbo He) Date: Wed, 30 Mar 2022 01:28:36 GMT Subject: RFR: 8240903: Add a regression test for JDK-8240734 [v4] In-Reply-To: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> Message-ID: > This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked > by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766) > > We found the issue can be produced stably with at least 64 modules. > Note that we need to add the --date jmod option to avoid the timestamp issue. > > Testing: > Added test case fails without fix for JDK-8240734, and passes otherwise. > Tested with tier2 on linux x86. Dongbo He has updated the pull request incrementally with one additional commit since the last revision: Change shell test io java test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7948/files - new: https://git.openjdk.java.net/jdk/pull/7948/files/aea79a40..6b185934 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=02-03 Stats: 279 lines in 4 files changed: 136 ins; 142 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7948/head:pull/7948 PR: https://git.openjdk.java.net/jdk/pull/7948 From dongbohe at openjdk.java.net Wed Mar 30 01:30:20 2022 From: dongbohe at openjdk.java.net (Dongbo He) Date: Wed, 30 Mar 2022 01:30:20 GMT Subject: RFR: 8240903: Add a regression test for JDK-8240734 [v3] In-Reply-To: References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> <55kL-Nlz4WxBPchyPK-3ADg1ISK4VVwRRXFxSOvFjD8=.3b29dc38-18e2-4358-8f7a-077930f6db78@github.com> Message-ID: <3kOMPdoRE4wrCCvfO1RZxqmnOQ99bg1QVZSFHR3aV6A=.288ab113-fa16-4394-8069-d866e525434e@github.com> On Fri, 25 Mar 2022 11:54:52 GMT, Alan Bateman wrote: > The existing tests for the jmod tool are in test/jdk/tools/jmod. HashesTest.java might provide inspiration to avoid introducing a shell test. Hi, Alan I have rewritten this test in Java in the latest commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/7948 From xgong at openjdk.java.net Wed Mar 30 01:31:39 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 30 Mar 2022 01:31:39 GMT Subject: RFR: 8282162: [vector] Optimize integral vector negation API [v3] In-Reply-To: References: <-sL2chUr7o8qwgvCm4qS_teHYtUu9rVGUa2GFWb9yC8=.14b0f006-56dc-4245-9746-ff248478e9ed@github.com> Message-ID: On Tue, 29 Mar 2022 18:05:56 GMT, Paul Sandoz wrote: >> Xiaohong Gong has updated the pull request incrementally with one additional commit since the last revision: >> >> Make "degenerate_vector_integral_negate" to be "NegVI" private > > Java changes are good. Thanks for the review @PaulSandoz @nsjian ! ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From xgong at openjdk.java.net Wed Mar 30 01:42:41 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 30 Mar 2022 01:42:41 GMT Subject: Integrated: 8282162: [vector] Optimize integral vector negation API In-Reply-To: References: Message-ID: <5MWaq1vZaLt2tM_0lFQ_QJcHxe5iWZ_VTNFYsUmmGm4=.1b73fdb1-2450-4419-ab63-fe851659cbd3@github.com> On Fri, 11 Mar 2022 06:29:22 GMT, Xiaohong Gong wrote: > The current vector `"NEG"` is implemented with substraction a vector by zero in case the architecture does not support the negation instruction. And to fit the predicate feature for architectures that support it, the masked vector `"NEG" ` is implemented with pattern `"v.not(m).add(1, m)"`. They both can be optimized to a single negation instruction for ARM SVE. > And so does the non-masked "NEG" for NEON. Besides, implementing the masked "NEG" with substraction for architectures that support neither negation instruction nor predicate feature can also save several instructions than the current pattern. > > To optimize the VectorAPI negation, this patch moves the implementation from Java side to hotspot. The compiler will generate different nodes according to the architecture: > - Generate the (predicated) negation node if architecture supports it, otherwise, generate "`zero.sub(v)`" pattern for non-masked operation. > - Generate `"zero.sub(v, m)"` for masked operation if the architecture does not have predicate feature, otherwise generate the original pattern `"v.xor(-1, m).add(1, m)"`. > > So with this patch, the following transformations are applied: > > For non-masked negation with NEON: > > movi v16.4s, #0x0 > sub v17.4s, v16.4s, v17.4s ==> neg v17.4s, v17.4s > > and with SVE: > > mov z16.s, #0 > sub z18.s, z16.s, z17.s ==> neg z16.s, p7/m, z16.s > > For masked negation with NEON: > > movi v17.4s, #0x1 > mvn v19.16b, v18.16b > mov v20.16b, v16.16b ==> neg v18.4s, v17.4s > bsl v20.16b, v19.16b, v18.16b bsl v19.16b, v18.16b, v17.16b > add v19.4s, v20.4s, v17.4s > mov v18.16b, v16.16b > bsl v18.16b, v19.16b, v20.16b > > and with SVE: > > mov z16.s, #-1 > mov z17.s, #1 ==> neg z16.s, p0/m, z16.s > eor z18.s, p0/m, z18.s, z16.s > add z18.s, p0/m, z18.s, z17.s > > Here are the performance gains for benchmarks (see [1][2]) on ARM and x86 machines(note that the non-masked negation benchmarks do not have any improvement on X86 since no instructions are changed): > > NEON: > Benchmark Gain > Byte128Vector.NEG 1.029 > Byte128Vector.NEGMasked 1.757 > Short128Vector.NEG 1.041 > Short128Vector.NEGMasked 1.659 > Int128Vector.NEG 1.005 > Int128Vector.NEGMasked 1.513 > Long128Vector.NEG 1.003 > Long128Vector.NEGMasked 1.878 > > SVE with 512-bits: > Benchmark Gain > ByteMaxVector.NEG 1.10 > ByteMaxVector.NEGMasked 1.165 > ShortMaxVector.NEG 1.056 > ShortMaxVector.NEGMasked 1.195 > IntMaxVector.NEG 1.002 > IntMaxVector.NEGMasked 1.239 > LongMaxVector.NEG 1.031 > LongMaxVector.NEGMasked 1.191 > > X86 (non AVX-512): > Benchmark Gain > ByteMaxVector.NEGMasked 1.254 > ShortMaxVector.NEGMasked 1.359 > IntMaxVector.NEGMasked 1.431 > LongMaxVector.NEGMasked 1.989 > > [1] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1881 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1896 This pull request has now been integrated. Changeset: d0668568 Author: Xiaohong Gong Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/d06685680c17583d56dc3d788d9a2ecea8812bc8 Stats: 325 lines in 15 files changed: 275 ins; 25 del; 25 mod 8282162: [vector] Optimize integral vector negation API Reviewed-by: jiefu, psandoz, njian ------------- PR: https://git.openjdk.java.net/jdk/pull/7782 From dongbohe at openjdk.java.net Wed Mar 30 01:55:30 2022 From: dongbohe at openjdk.java.net (Dongbo He) Date: Wed, 30 Mar 2022 01:55:30 GMT Subject: RFR: 8240903: Add test to check that jmod hashes are reproducible [v5] In-Reply-To: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> References: <7UZXk2V7yrTN2pGpmRusmf_vNG9Bs2RYjrnwwEoTYE0=.bdc4ef9f-2afb-40b7-9f22-b720b3094fde@github.com> Message-ID: > This creates a regression test for [JDK-8240734](https://bugs.openjdk.java.net/browse/JDK-8240734). This was once blocked > by a time stamp issue which has been resolved by: [JDK-8276766 ](https://bugs.openjdk.java.net/browse/JDK-8276766) > > We found the issue can be produced stably with at least 64 modules. > Note that we need to add the --date jmod option to avoid the timestamp issue. > > Testing: > Added test case fails without fix for JDK-8240734, and passes otherwise. > Tested with tier2 on linux x86. Dongbo He 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: - Merge branch 'master' into 8240903 - Delete extra blank links - Change shell test io java test - Get date by 'date +%Y-%m-%dT%H:%M:%S%:z' - Update Copyright - 8240903: Add a regression test for JDK-8240734 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7948/files - new: https://git.openjdk.java.net/jdk/pull/7948/files/6b185934..34b8008d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7948&range=03-04 Stats: 3635 lines in 166 files changed: 2489 ins; 556 del; 590 mod Patch: https://git.openjdk.java.net/jdk/pull/7948.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7948/head:pull/7948 PR: https://git.openjdk.java.net/jdk/pull/7948 From vromero at openjdk.java.net Wed Mar 30 02:56:41 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Mar 2022 02:56:41 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 [v3] In-Reply-To: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: > Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. There are basically two commits here, one that was automatically generated and that mostly changes file headers etc and another one, smaller, that make changes to the code to adapt it to our needs, JDK version etc. In this second commit one can see that two classes that were removed by the automatically generated change have been copied back: > > jdk.internal.org.objectweb.asm.commons.RemappingMethodAdapter > jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter > > This is because package: `jdk.jfr.internal.instrument` needs them. > > TIA Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: fixing files missing new line at the end ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8000/files - new: https://git.openjdk.java.net/jdk/pull/8000/files/41ae618e..f5e0d931 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8000&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8000&range=01-02 Stats: 252 lines in 129 files changed: 125 ins; 0 del; 127 mod Patch: https://git.openjdk.java.net/jdk/pull/8000.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8000/head:pull/8000 PR: https://git.openjdk.java.net/jdk/pull/8000 From sundar at openjdk.java.net Wed Mar 30 05:20:38 2022 From: sundar at openjdk.java.net (Athijegannathan Sundararajan) Date: Wed, 30 Mar 2022 05:20:38 GMT Subject: RFR: 8283060: RawNativeLibraries should allow multiple clients to load/unload the same library In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 20:05:50 GMT, Mandy Chung wrote: > A small improvement to `RawNativeLibraries`. `RawNativeLibraries::load` returns the same `NativeLibrary` instance of a given path if it's called multiple times. This means that multiple clients have to coordinate that the last one using the loaded library is the one to close the library by calling `RawNativeLibraries::unload`; otherwise, an exception may be thrown. > > This patch changes `RawNativeLibraries::load` to delegate to the underlying platform-specific library loading mechanism e.g. dlopen/dlclose that keeps the reference count. So each call to `RawNativeLibraries::load` and `unload` is simply a call to dlopen and dlclose respectively. Each client of calling `RawNativeLibraries::load` is responsible for calling `RawNativeLibraries::unload`. This will be consistent with the current behavior when you call `load` and `unload` with a different `RawNativeLibraries` instance. LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8022 From smarks at openjdk.java.net Wed Mar 30 06:22:33 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 30 Mar 2022 06:22:33 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v3] In-Reply-To: References: Message-ID: <0M7TbVLjiVXWDiVZtb4L4-WI9Ow2uBslXip5TZ1NJtg=.501941a8-f559-43dd-b794-ea44ded3a29e@github.com> > Pretty much just what it says. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Update copyright year. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8009/files - new: https://git.openjdk.java.net/jdk/pull/8009/files/77b6d79f..7ca24f1d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8009&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8009&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8009.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8009/head:pull/8009 PR: https://git.openjdk.java.net/jdk/pull/8009 From jpai at openjdk.java.net Wed Mar 30 06:22:33 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 30 Mar 2022 06:22:33 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v3] In-Reply-To: <0M7TbVLjiVXWDiVZtb4L4-WI9Ow2uBslXip5TZ1NJtg=.501941a8-f559-43dd-b794-ea44ded3a29e@github.com> References: <0M7TbVLjiVXWDiVZtb4L4-WI9Ow2uBslXip5TZ1NJtg=.501941a8-f559-43dd-b794-ea44ded3a29e@github.com> Message-ID: <-_vmFb3B-UeivL6ovpU7Zj1nPYJcXa6Y3B7Rtr8x11w=.b99963a6-902f-44ba-a924-ccecddba4e4a@github.com> On Wed, 30 Mar 2022 06:17:54 GMT, Stuart Marks wrote: >> Pretty much just what it says. > > Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year. Marked as reviewed by jpai (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From smarks at openjdk.java.net Wed Mar 30 06:22:34 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 30 Mar 2022 06:22:34 GMT Subject: RFR: 8283715: Update ObjectStreamClass to be final [v2] In-Reply-To: References: Message-ID: <5IGBBYc3QPmj2xWQE54auJ7ZKYjlxWf-9jOvSd7ov6E=.bca5cc0e-e624-4b94-87f2-24b135008554@github.com> On Wed, 30 Mar 2022 00:43:57 GMT, Jaikiran Pai wrote: >> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust nonfinal CSMs and rework error reporting in CheckCSMs.java test > > Hello Stuart, the test change looks fine to me. Just a minor note - the copyright year of the test will need an update. @jaikiran Thanks, I've updated the copyright year. I will integrate when I can keep an eye on the subsequent builds. ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From aturbanov at openjdk.java.net Wed Mar 30 06:59:42 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 30 Mar 2022 06:59:42 GMT Subject: Integrated: 8283846: Remove unused jdk.internal.reflect.SignatureIterator In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 09:15:01 GMT, Andrey Turbanov wrote: > It was no longer used due to JDK-4479184 long ago. This pull request has now been integrated. Changeset: b323f54f Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/b323f54feef13a47bb02af608eb1f6474692d905 Stats: 81 lines in 1 file changed: 0 ins; 81 del; 0 mod 8283846: Remove unused jdk.internal.reflect.SignatureIterator Reviewed-by: bpb, mchung, iris ------------- PR: https://git.openjdk.java.net/jdk/pull/8013 From aturbanov at openjdk.java.net Wed Mar 30 07:11:38 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 30 Mar 2022 07:11:38 GMT Subject: Integrated: 8283800: Simplify String.indexOf/lastIndexOf calls In-Reply-To: References: Message-ID: On Sun, 20 Mar 2022 12:45:34 GMT, Andrey Turbanov wrote: > In a few places String.indexOf/lastIndexOf methods are called with default parameter for index: `0` for `indexOf`, length() for `lastIndexOf`. > I propose to cleanup such calls. It makes code a bit easier to read. In case of `indexOf` it even could be faster, as there is separate intrinsic for `indexOf` call without index argument. This pull request has now been integrated. Changeset: 9bb916db Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/9bb916db0a6af2c6476c0bfbc55c1bb8721b4354 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod 8283800: Simplify String.indexOf/lastIndexOf calls Reviewed-by: xuelei, bpb, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/7877 From thartmann at openjdk.java.net Wed Mar 30 08:21:39 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 30 Mar 2022 08:21:39 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog,dlog10,dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Tue, 25 May 2021 15:32:40 GMT, gregcawthorne wrote: >> Glibc 2.29 onwards provides optimised versions of log,log10,exp. >> These functions have an accuracy of 0.9ulp or better in glibc >> 2.29. >> >> Therefore this patch adds code to parse, store and check >> the runtime glibcs version in os_linux.cpp/hpp. >> This is then used to select the glibcs implementation of >> log, log10, exp at runtime for c1 and c2, iff we have >> glibc 2.29 or greater. >> >> This will ensure OpenJDK can benefit from future improvements >> to glibc. >> >> Glibc adheres to the ieee754 standard, unless stated otherwise >> in its spec. >> >> As there are no stated exceptions in the current glibc spec >> for dlog, dlog10 and dexp, we can assume they currently follow >> ieee754 (which testing confirms). As such, future version of >> glibc are unlikely to lose this compliance with ieee754 in >> future. >> >> W.r.t performance this patch sees ~15-30% performance improvements for >> log and log10, with ~50-80% performance improvements for exp for the >> common input ranged (which output real numbers). However for the NaN >> and inf output ranges we see a slow down of up to a factor of 2 for >> some functions and architectures. >> >> Due to this being the uncommon case we assert that this is a >> worthwhile tradeoff. > > greg.cawthorne at arm.com > > Should work @gregcawthorne any plans to re-open and fix this? ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From lancea at openjdk.java.net Wed Mar 30 10:30:41 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 30 Mar 2022 10:30:41 GMT Subject: RFR: 8282648: Problems due to conflicting specification of Inflater::inflate(..) and InflaterInputStream::read(..) [v2] In-Reply-To: <5n-I0E5OO7uAHLo7fWdPqgAojcWpMMIB_AhGrxSKRVA=.a38c974d-eafd-4bbf-85ec-2eb457105b59@github.com> References: <9xRWWYTN0kk2lTeN15qoQ9lvti2WsMutJPAaKDmZ6wA=.96d17cd0-4d9f-4cc0-9e1d-b885d249d0c6@github.com> <5n-I0E5OO7uAHLo7fWdPqgAojcWpMMIB_AhGrxSKRVA=.a38c974d-eafd-4bbf-85ec-2eb457105b59@github.com> Message-ID: On Tue, 29 Mar 2022 12:45:51 GMT, Volker Simonis wrote: > > Hello Volker, An additional thing that we might have to consider here is whether adding this javadoc change to `InflaterInputStream` is ever going to "show up" to end user applications. What I mean is, I think in many cases the end user applications won't even know they are dealing with an `InflaterInputStream`. For example, the following code: > > ``` > > ZipFile zf = ... > > ZipEntry ze = zf.getEntry("some-file"); > > InputStream is = zf.getInputStream(ze); > > ``` > > > > > > > > > > > > > > > > > > > > > > > > As we see above, none of these APIs talk about `InflaterInputStream` (the return type of `ZipFile.getInpustream(...)` is an `InputStream`). So end users won't be able to view this spec change. Perhaps we should also add some note in the `ZipFile.getInpustream(....)` API to make a mention of this potential difference in behaviour of the returned stream? > > You are right with your observation and I'll be happy to add a corresponding comment if @LanceAndersen and @AlanBateman agree. Please let me know what you think? Hi Volker, I believe Jai raises a valid point given these javadocs probably have had limited updates if any since the API was originally added. We should look at ZipInputStream and GZipInputStream as well if we decide to update the ZipFile::getInputStream(where we could borrow some wording from the ZipInputStream class description as a start to some word smithing). As Roger points out we will need a release note for this change as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/7986 From xgong at openjdk.java.net Wed Mar 30 10:38:19 2022 From: xgong at openjdk.java.net (Xiaohong Gong) Date: Wed, 30 Mar 2022 10:38:19 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature Message-ID: Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): @ForceInline public static ByteVector fromArray(VectorSpecies species, byte[] a, int offset, VectorMask m) { ByteSpecies vsp = (ByteSpecies) species; if (offset >= 0 && offset <= (a.length - species.length())) { return vsp.dummyVector().fromArray0(a, offset, m); } // FIXME: optimize checkMaskFromIndexSize(offset, vsp, m, 1, a.length); return vsp.vOp(m, i -> a[offset + i]); } Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. Also adds the same vectorization support for masked: - fromByteArray/fromByteBuffer - fromBooleanArray - fromCharArray The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: Benchmark before After Units LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms Similar performance gain can also be observed on 512-bit SVE system. ------------- Commit messages: - 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature Changes: https://git.openjdk.java.net/jdk/pull/8035/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8035&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283667 Stats: 821 lines in 43 files changed: 314 ins; 117 del; 390 mod Patch: https://git.openjdk.java.net/jdk/pull/8035.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8035/head:pull/8035 PR: https://git.openjdk.java.net/jdk/pull/8035 From kcr at openjdk.java.net Wed Mar 30 11:35:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 30 Mar 2022 11:35:38 GMT Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung wrote: > redo of 8280400 Since this is identical to the original fix, I would expect the same Tier2 test failure as reported in [JDK-8283804](https://bugs.openjdk.java.net/browse/JDK-8283804). ------------- PR: https://git.openjdk.java.net/jdk/pull/8026 From duke at openjdk.java.net Wed Mar 30 11:38:38 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Wed, 30 Mar 2022 11:38:38 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 10:31:59 GMT, Xiaohong Gong wrote: > Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. > > This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): > > > @ForceInline > public static > ByteVector fromArray(VectorSpecies species, > byte[] a, int offset, > VectorMask m) { > ByteSpecies vsp = (ByteSpecies) species; > if (offset >= 0 && offset <= (a.length - species.length())) { > return vsp.dummyVector().fromArray0(a, offset, m); > } > > // FIXME: optimize > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > return vsp.vOp(m, i -> a[offset + i]); > } > > Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. > > Also adds the same vectorization support for masked: > - fromByteArray/fromByteBuffer > - fromBooleanArray > - fromCharArray > > The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: > > Benchmark before After Units > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms > > Similar performance gain can also be observed on 512-bit SVE system. AVX has `vmaskmovpd` and `vmaskmovps` for masked loads and stores, which do not required predicate vectors. I think the implementation should make it possible to take advantage of these instructions. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From shade at openjdk.java.net Wed Mar 30 11:47:10 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 30 Mar 2022 11:47:10 GMT Subject: RFR: 8283994: Make Xerces DatatypeException stackless Message-ID: See bug report for more details. This change improves SPECjvm2008:xml.validation for about +3%: baseline: 298.353 ? 1.008 ops/min patched: 309.912 ? 1.347 ops/min Of course, the real improvements might be even higher, as exception might be thrown from much deeper call hierarchy. Additional testing: - [x] Linux x86_64 fastdebug, `jaxp_all` - [x] Linux x86_64 fastdebug, `javax/xml` ------------- Commit messages: - Fix Changes: https://git.openjdk.java.net/jdk/pull/8036/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8036&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283994 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8036.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8036/head:pull/8036 PR: https://git.openjdk.java.net/jdk/pull/8036 From jvernee at openjdk.java.net Wed Mar 30 11:54:37 2022 From: jvernee at openjdk.java.net (Jorn Vernee) Date: Wed, 30 Mar 2022 11:54:37 GMT Subject: RFR: 8283060: RawNativeLibraries should allow multiple clients to load/unload the same library In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 20:05:50 GMT, Mandy Chung wrote: > A small improvement to `RawNativeLibraries`. `RawNativeLibraries::load` returns the same `NativeLibrary` instance of a given path if it's called multiple times. This means that multiple clients have to coordinate that the last one using the loaded library is the one to close the library by calling `RawNativeLibraries::unload`; otherwise, an exception may be thrown. > > This patch changes `RawNativeLibraries::load` to delegate to the underlying platform-specific library loading mechanism e.g. dlopen/dlclose that keeps the reference count. So each call to `RawNativeLibraries::load` and `unload` is simply a call to dlopen and dlclose respectively. Each client of calling `RawNativeLibraries::load` is responsible for calling `RawNativeLibraries::unload`. This will be consistent with the current behavior when you call `load` and `unload` with a different `RawNativeLibraries` instance. Marked as reviewed by jvernee (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8022 From redestad at openjdk.java.net Wed Mar 30 12:14:56 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 30 Mar 2022 12:14:56 GMT Subject: RFR: 8283996: Reduce cost of year and month calculations Message-ID: A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups. Baseline: Benchmark Mode Cnt Score Error Units GetYearBench.getYearFromMillisZoneOffset thrpt 15 18.492 ? 0.017 ops/ms GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.121 ? 0.135 ops/ms GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 18.936 ? 0.012 ops/ms GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 9.283 ? 0.222 ops/ms Patched: Benchmark Mode Cnt Score Error Units GetYearBench.getYearFromMillisZoneOffset thrpt 15 20.931 ? 0.013 ops/ms GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.858 ? 0.167 ops/ms GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 20.923 ? 0.017 ops/ms GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 10.028 ? 0.182 ops/ms Testing: java.time tests locally, CI tier1+2 ongoing. ------------- Commit messages: - Reduce cost of year and month calculations Changes: https://git.openjdk.java.net/jdk/pull/8039/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8039&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283996 Stats: 12 lines in 2 files changed: 6 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8039.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8039/head:pull/8039 PR: https://git.openjdk.java.net/jdk/pull/8039 From naoto at openjdk.java.net Wed Mar 30 12:38:40 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 30 Mar 2022 12:38:40 GMT Subject: RFR: 8253569: javax.xml.catalog.Catalog.matchURI() implementation should reset state variables [v2] In-Reply-To: References: <1Oj29blLOnG_W5kJOYf1GtzzV3UVfw7Ek6Cx1PPA9us=.4102b61e-fb00-4153-b0f7-6311259ef991@github.com> Message-ID: On Wed, 30 Mar 2022 00:46:49 GMT, Joe Wang wrote: >> Resets state of a Catalog instance on each matching call so that it can be reused. Adjusts CatalogResolver's resolve routine so that it continues to observes the PREFER feature in a resolution process. Without the adjustment, PreferFeatureTest would fail. >> >> Mach5 XML tests passed: https://mach5.us.oracle.com/mdash/jobs/huizwang-open-20220329-0148-30563542 > > Joe Wang has updated the pull request incrementally with one additional commit since the last revision: > > remove variable, check instance instead. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8018 From jpai at openjdk.java.net Wed Mar 30 13:24:38 2022 From: jpai at openjdk.java.net (Jaikiran Pai) Date: Wed, 30 Mar 2022 13:24:38 GMT Subject: RFR: 8283060: RawNativeLibraries should allow multiple clients to load/unload the same library In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 20:05:50 GMT, Mandy Chung wrote: > A small improvement to `RawNativeLibraries`. `RawNativeLibraries::load` returns the same `NativeLibrary` instance of a given path if it's called multiple times. This means that multiple clients have to coordinate that the last one using the loaded library is the one to close the library by calling `RawNativeLibraries::unload`; otherwise, an exception may be thrown. > > This patch changes `RawNativeLibraries::load` to delegate to the underlying platform-specific library loading mechanism e.g. dlopen/dlclose that keeps the reference count. So each call to `RawNativeLibraries::load` and `unload` is simply a call to dlopen and dlclose respectively. Each client of calling `RawNativeLibraries::load` is responsible for calling `RawNativeLibraries::unload`. This will be consistent with the current behavior when you call `load` and `unload` with a different `RawNativeLibraries` instance. src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line 49: > 47: public final class RawNativeLibraries { > 48: final Set libraries = ConcurrentHashMap.newKeySet(); > 49: final Class caller; Hello Mandy, Apart from the `caller` being used for checks while constructing a `RawNativeLibraries` in `RawNativeLibraries.newInstance(MethodHandles.Lookup trustedCaller)`, I don't see this instance member being used anywhere. Do you think we need to store this as an instance member? ------------- PR: https://git.openjdk.java.net/jdk/pull/8022 From naoto at openjdk.java.net Wed Mar 30 15:48:38 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 30 Mar 2022 15:48:38 GMT Subject: RFR: 8283805: [REDO] JDK 19 L10n resource files update - msgdrop 10 In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 00:43:49 GMT, Alisen Chung wrote: > redo of 8280400 I believe `src/jdk.localedata/share/classes/sun/util/resources/ext/CurrencyNames_zh_CN.properties` and `test/jdk/sun/text/resources/LocaleData` have to be adjusted according to the l10n changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/8026 From smarks at openjdk.java.net Wed Mar 30 15:54:40 2022 From: smarks at openjdk.java.net (Stuart Marks) Date: Wed, 30 Mar 2022 15:54:40 GMT Subject: Integrated: 8283715: Update ObjectStreamClass to be final In-Reply-To: References: Message-ID: On Tue, 29 Mar 2022 01:07:33 GMT, Stuart Marks wrote: > Pretty much just what it says. This pull request has now been integrated. Changeset: ae57258b Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/ae57258b46b8b6953148cd8cf71faf75eef118da Stats: 10 lines in 2 files changed: 2 ins; 1 del; 7 mod 8283715: Update ObjectStreamClass to be final Reviewed-by: darcy, jpai, mchung, dfuchs ------------- PR: https://git.openjdk.java.net/jdk/pull/8009 From bpb at openjdk.java.net Wed Mar 30 16:11:00 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 30 Mar 2022 16:11:00 GMT Subject: RFR: 5087440: (ch spec) java.io,nio bulk read(...) end-of-stream return value descriptions ambiguous Message-ID: <3hL1R9thiKOHIbNATyHkm7sSdEDduOF-Rz0xO8MYEYg=.4c7eba75-54fd-4120-abce-b251aea2c62b@github.com> Minimal version of possible fixes: make the bulk read `@return` verbiage consistent in the `java.io` package. ------------- Commit messages: - 5087440: (ch spec) java.io,nio bulk read(...) end-of-stream return value descriptions ambiguous Changes: https://git.openjdk.java.net/jdk/pull/8044/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8044&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-5087440 Stats: 14 lines in 3 files changed: 5 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/8044.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8044/head:pull/8044 PR: https://git.openjdk.java.net/jdk/pull/8044 From bpb at openjdk.java.net Wed Mar 30 16:11:38 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 30 Mar 2022 16:11:38 GMT Subject: RFR: 8283996: Reduce cost of year and month calculations In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad wrote: > A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups. > > Baseline: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 18.492 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.121 ? 0.135 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 18.936 ? 0.012 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 9.283 ? 0.222 ops/ms > > Patched: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 20.931 ? 0.013 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.858 ? 0.167 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 20.923 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 10.028 ? 0.182 ops/ms > > > Testing: java.time tests locally, CI tier1+2 ongoing. Looks all right assuming tests pass. ------------- Marked as reviewed by bpb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8039 From rriggs at openjdk.java.net Wed Mar 30 16:14:45 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 30 Mar 2022 16:14:45 GMT Subject: RFR: 5087440: (ch spec) java.io, nio bulk read(...) end-of-stream return value descriptions ambiguous In-Reply-To: <3hL1R9thiKOHIbNATyHkm7sSdEDduOF-Rz0xO8MYEYg=.4c7eba75-54fd-4120-abce-b251aea2c62b@github.com> References: <3hL1R9thiKOHIbNATyHkm7sSdEDduOF-Rz0xO8MYEYg=.4c7eba75-54fd-4120-abce-b251aea2c62b@github.com> Message-ID: On Wed, 30 Mar 2022 16:05:03 GMT, Brian Burkhalter wrote: > Minimal version of possible fixes: make the bulk read `@return` verbiage consistent in the `java.io` package. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8044 From duke at openjdk.java.net Wed Mar 30 16:17:38 2022 From: duke at openjdk.java.net (Quan Anh Mai) Date: Wed, 30 Mar 2022 16:17:38 GMT Subject: RFR: 8283667: [vectorapi] Vectorization for masked load with IOOBE with predicate feature In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 10:31:59 GMT, Xiaohong Gong wrote: > Currently the vector load with mask when the given index happens out of the array boundary is implemented with pure java scalar code to avoid the IOOBE (IndexOutOfBoundaryException). This is necessary for architectures that do not support the predicate feature. Because the masked load is implemented with a full vector load and a vector blend applied on it. And a full vector load will definitely cause the IOOBE which is not valid. However, for architectures that support the predicate feature like SVE/AVX-512/RVV, it can be vectorized with the predicated load instruction as long as the indexes of the masked lanes are within the bounds of the array. For these architectures, loading with unmasked lanes does not raise exception. > > This patch adds the vectorization support for the masked load with IOOBE part. Please see the original java implementation (FIXME: optimize): > > > @ForceInline > public static > ByteVector fromArray(VectorSpecies species, > byte[] a, int offset, > VectorMask m) { > ByteSpecies vsp = (ByteSpecies) species; > if (offset >= 0 && offset <= (a.length - species.length())) { > return vsp.dummyVector().fromArray0(a, offset, m); > } > > // FIXME: optimize > checkMaskFromIndexSize(offset, vsp, m, 1, a.length); > return vsp.vOp(m, i -> a[offset + i]); > } > > Since it can only be vectorized with the predicate load, the hotspot must check whether the current backend supports it and falls back to the java scalar version if not. This is different from the normal masked vector load that the compiler will generate a full vector load and a vector blend if the predicate load is not supported. So to let the compiler make the expected action, an additional flag (i.e. `usePred`) is added to the existing "loadMasked" intrinsic, with the value "true" for the IOOBE part while "false" for the normal load. And the compiler will fail to intrinsify if the flag is "true" and the predicate load is not supported by the backend, which means that normal java path will be executed. > > Also adds the same vectorization support for masked: > - fromByteArray/fromByteBuffer > - fromBooleanArray > - fromCharArray > > The performance for the new added benchmarks improve about `1.88x ~ 30.26x` on the x86 AVX-512 system: > > Benchmark before After Units > LoadMaskedIOOBEBenchmark.byteLoadArrayMaskIOOBE 737.542 1387.069 ops/ms > LoadMaskedIOOBEBenchmark.doubleLoadArrayMaskIOOBE 118.366 330.776 ops/ms > LoadMaskedIOOBEBenchmark.floatLoadArrayMaskIOOBE 233.832 6125.026 ops/ms > LoadMaskedIOOBEBenchmark.intLoadArrayMaskIOOBE 233.816 7075.923 ops/ms > LoadMaskedIOOBEBenchmark.longLoadArrayMaskIOOBE 119.771 330.587 ops/ms > LoadMaskedIOOBEBenchmark.shortLoadArrayMaskIOOBE 431.961 939.301 ops/ms > > Similar performance gain can also be observed on 512-bit SVE system. src/hotspot/share/opto/vectorIntrinsics.cpp line 1234: > 1232: bool use_predicate = false; > 1233: if (is_store) { > 1234: // Masked vector store always uses the predicated store. Can masked store be implemented as Load + Blend + Store? ------------- PR: https://git.openjdk.java.net/jdk/pull/8035 From bpb at openjdk.java.net Wed Mar 30 16:28:16 2022 From: bpb at openjdk.java.net (Brian Burkhalter) Date: Wed, 30 Mar 2022 16:28:16 GMT Subject: RFR: 5087440: java.io bulk read(...) end-of-stream return value descriptions ambiguous [v2] In-Reply-To: <3hL1R9thiKOHIbNATyHkm7sSdEDduOF-Rz0xO8MYEYg=.4c7eba75-54fd-4120-abce-b251aea2c62b@github.com> References: <3hL1R9thiKOHIbNATyHkm7sSdEDduOF-Rz0xO8MYEYg=.4c7eba75-54fd-4120-abce-b251aea2c62b@github.com> Message-ID: > Minimal version of possible fixes: make the bulk read `@return` verbiage consistent in the `java.io` package. Brian Burkhalter 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: 5087440: java.io bulk read(...) end-of-stream return value descriptions ambiguous ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8044/files - new: https://git.openjdk.java.net/jdk/pull/8044/files/360a5a9c..3de7caa8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8044&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8044&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8044.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8044/head:pull/8044 PR: https://git.openjdk.java.net/jdk/pull/8044 From lancea at openjdk.java.net Wed Mar 30 16:33:37 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 30 Mar 2022 16:33:37 GMT Subject: RFR: 5087440: java.io bulk read(...) end-of-stream return value descriptions ambiguous [v2] In-Reply-To: References: <3hL1R9thiKOHIbNATyHkm7sSdEDduOF-Rz0xO8MYEYg=.4c7eba75-54fd-4120-abce-b251aea2c62b@github.com> Message-ID: On Wed, 30 Mar 2022 16:28:16 GMT, Brian Burkhalter wrote: >> Minimal version of possible fixes: make the bulk read `@return` verbiage consistent in the `java.io` package. > > Brian Burkhalter 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: > > 5087440: java.io bulk read(...) end-of-stream return value descriptions ambiguous Marked as reviewed by lancea (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8044 From vromero at openjdk.java.net Wed Mar 30 16:36:37 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Wed, 30 Mar 2022 16:36:37 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 [v3] In-Reply-To: References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: On Wed, 30 Mar 2022 02:56:41 GMT, Vicente Romero wrote: >> Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. There are basically two commits here, one that was automatically generated and that mostly changes file headers etc and another one, smaller, that make changes to the code to adapt it to our needs, JDK version etc. In this second commit one can see that two classes that were removed by the automatically generated change have been copied back: >> >> jdk.internal.org.objectweb.asm.commons.RemappingMethodAdapter >> jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter >> >> This is because package: `jdk.jfr.internal.instrument` needs them. >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing files missing new line at the end anymore comments on this one? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/8000 From lancea at openjdk.java.net Wed Mar 30 16:49:30 2022 From: lancea at openjdk.java.net (Lance Andersen) Date: Wed, 30 Mar 2022 16:49:30 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 [v3] In-Reply-To: References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: On Wed, 30 Mar 2022 02:56:41 GMT, Vicente Romero wrote: >> Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. There are basically two commits here, one that was automatically generated and that mostly changes file headers etc and another one, smaller, that make changes to the code to adapt it to our needs, JDK version etc. In this second commit one can see that two classes that were removed by the automatically generated change have been copied back: >> >> jdk.internal.org.objectweb.asm.commons.RemappingMethodAdapter >> jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter >> >> This is because package: `jdk.jfr.internal.instrument` needs them. >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing files missing new line at the end The changes look reasonable to me ------------- PR: https://git.openjdk.java.net/jdk/pull/8000 From naoto at openjdk.java.net Wed Mar 30 16:52:59 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 30 Mar 2022 16:52:59 GMT Subject: RFR: 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails: DateTimeParseException Message-ID: Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do. ------------- Commit messages: - 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails: DateTimeParseException Changes: https://git.openjdk.java.net/jdk/pull/8045/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8045&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283842 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/8045.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8045/head:pull/8045 PR: https://git.openjdk.java.net/jdk/pull/8045 From egahlin at openjdk.java.net Wed Mar 30 17:01:41 2022 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Wed, 30 Mar 2022 17:01:41 GMT Subject: RFR: 8282508: Updating ASM to 9.2 for JDK 19 [v3] In-Reply-To: References: <5WK8EEFb8K9Pdh5_cyMDsxO2DBTYhUD6mzUgFWZDEIY=.c32f02be-a36f-48cb-ac50-a36d87542baf@github.com> Message-ID: <81ixVWy9jO5cDPGJfieLS1UmaA4KAyvxgnCOZ4YBAwM=.305e48ff-c975-41bf-83c3-31079cc22aca@github.com> On Wed, 30 Mar 2022 02:56:41 GMT, Vicente Romero wrote: >> Please review this PR which is updating the ASM included in the JDK to ASM 9.2. This version should be included in JDK19. There are basically two commits here, one that was automatically generated and that mostly changes file headers etc and another one, smaller, that make changes to the code to adapt it to our needs, JDK version etc. In this second commit one can see that two classes that were removed by the automatically generated change have been copied back: >> >> jdk.internal.org.objectweb.asm.commons.RemappingMethodAdapter >> jdk.internal.org.objectweb.asm.commons.RemappingAnnotationAdapter >> >> This is because package: `jdk.jfr.internal.instrument` needs them. >> >> TIA > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > fixing files missing new line at the end JFR parts look OK. ------------- Marked as reviewed by egahlin (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8000 From redestad at openjdk.java.net Wed Mar 30 17:03:34 2022 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 30 Mar 2022 17:03:34 GMT Subject: RFR: 8283996: Reduce cost of year and month calculations In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 16:08:15 GMT, Brian Burkhalter wrote: > Looks all right assuming tests pass. Thanks! Tier1+2 testing passed. ------------- PR: https://git.openjdk.java.net/jdk/pull/8039 From iris at openjdk.java.net Wed Mar 30 17:12:40 2022 From: iris at openjdk.java.net (Iris Clark) Date: Wed, 30 Mar 2022 17:12:40 GMT Subject: RFR: 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails: DateTimeParseException In-Reply-To: References: Message-ID: <_9oBG0kA1bJ0HooNdvBt3luwxUmWlAE-k1PzTsaS9cY=.1e0d8ecf-1938-47db-9a8a-b7e8ab9a9eff@github.com> On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato wrote: > Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do. Marked as reviewed by iris (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8045 From mchung at openjdk.java.net Wed Mar 30 17:18:46 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 30 Mar 2022 17:18:46 GMT Subject: RFR: 8283060: RawNativeLibraries should allow multiple clients to load/unload the same library In-Reply-To: References: Message-ID: <_evOVRlDFPEHkxRPadlsa9VZ1eVl7ICy0KoAXC5EMCA=.161a40ba-bf5b-4e52-b51b-27e78989ca39@github.com> On Wed, 30 Mar 2022 13:21:41 GMT, Jaikiran Pai wrote: >> A small improvement to `RawNativeLibraries`. `RawNativeLibraries::load` returns the same `NativeLibrary` instance of a given path if it's called multiple times. This means that multiple clients have to coordinate that the last one using the loaded library is the one to close the library by calling `RawNativeLibraries::unload`; otherwise, an exception may be thrown. >> >> This patch changes `RawNativeLibraries::load` to delegate to the underlying platform-specific library loading mechanism e.g. dlopen/dlclose that keeps the reference count. So each call to `RawNativeLibraries::load` and `unload` is simply a call to dlopen and dlclose respectively. Each client of calling `RawNativeLibraries::load` is responsible for calling `RawNativeLibraries::unload`. This will be consistent with the current behavior when you call `load` and `unload` with a different `RawNativeLibraries` instance. > > src/java.base/share/classes/jdk/internal/loader/RawNativeLibraries.java line 49: > >> 47: public final class RawNativeLibraries { >> 48: final Set libraries = ConcurrentHashMap.newKeySet(); >> 49: final Class caller; > > Hello Mandy, > Apart from the `caller` being used for checks while constructing a `RawNativeLibraries` in `RawNativeLibraries.newInstance(MethodHandles.Lookup trustedCaller)`, I don't see this instance member being used anywhere. Do you think we need to store this as an instance member? I keep it as a record and for debugging use in case. ------------- PR: https://git.openjdk.java.net/jdk/pull/8022 From mchung at openjdk.java.net Wed Mar 30 17:41:36 2022 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 30 Mar 2022 17:41:36 GMT Subject: Integrated: 8283470: Update java.lang.invoke.VarHandle to use sealed classes In-Reply-To: References: Message-ID: On Wed, 23 Mar 2022 16:27:29 GMT, Mandy Chung wrote: > This patch changes VarHandle and its implementation hierarchy to use sealed classes. All VarHandle permitted classes are package-private and either final or sealed abstract classes. > > Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8283540 This pull request has now been integrated. Changeset: e61ccfba Author: Mandy Chung URL: https://git.openjdk.java.net/jdk/commit/e61ccfba7fa747c24e34a7539871a34630693af5 Stats: 58 lines in 5 files changed: 42 ins; 5 del; 11 mod 8283470: Update java.lang.invoke.VarHandle to use sealed classes Reviewed-by: darcy, psandoz ------------- PR: https://git.openjdk.java.net/jdk/pull/7926 From rriggs at openjdk.java.net Wed Mar 30 18:02:39 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 30 Mar 2022 18:02:39 GMT Subject: RFR: 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails: DateTimeParseException In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato wrote: > Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8045 From mcimadamore at openjdk.java.net Wed Mar 30 18:06:28 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 30 Mar 2022 18:06:28 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v14] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix bad usage of `@link` with primitive array types ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/43dc6be3..0bcc8664 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=13 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=12-13 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From joehw at openjdk.java.net Wed Mar 30 19:08:27 2022 From: joehw at openjdk.java.net (Joe Wang) Date: Wed, 30 Mar 2022 19:08:27 GMT Subject: RFR: 8283994: Make Xerces DatatypeException stackless In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 11:38:59 GMT, Aleksey Shipilev wrote: > See bug report for more details. This change improves SPECjvm2008:xml.validation for about +3%: > > > baseline: 298.353 ? 1.008 ops/min > patched: 309.912 ? 1.347 ops/min > > Of course, the real improvements might be even higher, as exception might be thrown from much deeper call hierarchy. > > Additional testing: > - [x] Linux x86_64 fastdebug, `jaxp_all` > - [x] Linux x86_64 fastdebug, `javax/xml` Marked as reviewed by joehw (Reviewer). src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/dv/DatatypeException.java line 2: > 1: /* > 2: * Copyright (c) 2017, 2022, Oracle and/or its affiliates. All rights reserved. Update the LastModified tag below as well. Otherwise, looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/8036 From scolebourne at openjdk.java.net Wed Mar 30 19:11:39 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 30 Mar 2022 19:11:39 GMT Subject: RFR: 8283996: Reduce cost of year and month calculations In-Reply-To: References: Message-ID: <8A2--PpHwO1GgHz1_6LYloWYKTrlNYia_kl30ZBEPqU=.4319d914-b329-49cb-9936-8961474e6057@github.com> On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad wrote: > A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups. > > Baseline: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 18.492 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.121 ? 0.135 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 18.936 ? 0.012 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 9.283 ? 0.222 ops/ms > > Patched: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 20.931 ? 0.013 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.858 ? 0.167 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 20.923 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 10.028 ? 0.182 ops/ms > > > Testing: java.time tests locally, CI tier1+2 ongoing. I'm happy, based on the assertion that it produces the same result and is faster. ------------- Marked as reviewed by scolebourne (Author). PR: https://git.openjdk.java.net/jdk/pull/8039 From scolebourne at openjdk.java.net Wed Mar 30 19:13:36 2022 From: scolebourne at openjdk.java.net (Stephen Colebourne) Date: Wed, 30 Mar 2022 19:13:36 GMT Subject: RFR: 8283842: TestZoneTextPrinterParser.test_roundTripAtOverlap fails: DateTimeParseException In-Reply-To: References: Message-ID: <3Wk-LQz1rZR4XwqZX-04hy2hweNoXCq8VLS-Ry_urjM=.3395e29f-78ce-466e-9a45-2a25fad50170@github.com> On Wed, 30 Mar 2022 16:46:40 GMT, Naoto Sato wrote: > Fixes test failures caused by depending on the default locale. Specifying explicit `Locale.US` will do. Marked as reviewed by scolebourne (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/8045 From naoto at openjdk.java.net Wed Mar 30 19:50:40 2022 From: naoto at openjdk.java.net (Naoto Sato) Date: Wed, 30 Mar 2022 19:50:40 GMT Subject: RFR: 8283996: Reduce cost of year and month calculations In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad wrote: > A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups. > > Baseline: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 18.492 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.121 ? 0.135 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 18.936 ? 0.012 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 9.283 ? 0.222 ops/ms > > Patched: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 20.931 ? 0.013 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.858 ? 0.167 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 20.923 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 10.028 ? 0.182 ops/ms > > > Testing: java.time tests locally, CI tier1+2 ongoing. Marked as reviewed by naoto (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8039 From cushon at openjdk.java.net Wed Mar 30 20:20:44 2022 From: cushon at openjdk.java.net (Liam Miller-Cushon) Date: Wed, 30 Mar 2022 20:20:44 GMT Subject: RFR: 8283340: Remove support for -Dsun.misc.URLClassPath.disableJarChecking In-Reply-To: References: Message-ID: On Fri, 18 Mar 2022 18:59:16 GMT, Sean Mullan wrote: >> I don't know what the motivation for this change is but there is more to this story and I think will require agreement from the security area before removing it. > > I agree with @AlanBateman. Please don't proceed with this fix until further notice. @seanjmullan are there any updates here? Or is the suggestion to drop the PR, because the code is definitely still needed? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/7861 From mcimadamore at openjdk.java.net Wed Mar 30 20:59:34 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 30 Mar 2022 20:59:34 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v15] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Tweak FunctionDescriptor::argumentLayouts to return an immutable list ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7888/files - new: https://git.openjdk.java.net/jdk/pull/7888/files/0bcc8664..af41a76c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=14 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=13-14 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From aturbanov at openjdk.java.net Wed Mar 30 21:12:38 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 30 Mar 2022 21:12:38 GMT Subject: RFR: 8283801: Cleanup confusing String.toString calls In-Reply-To: <-ZqXmYduQRz20bw-aAD90xx3DLNuq4xoM6Wi4zWN520=.21c06a63-7038-4c0c-ae06-f708b8cbbb64@github.com> References: <-ZqXmYduQRz20bw-aAD90xx3DLNuq4xoM6Wi4zWN520=.21c06a63-7038-4c0c-ae06-f708b8cbbb64@github.com> Message-ID: On Sun, 20 Mar 2022 13:20:31 GMT, Andrey Turbanov wrote: > String.toString() calls doesn't make much sense. Only one place, where it could be used - to generate NPE. But in a few places of JDK codebase it's called, even when NPE will happen anyway. > I propose to cleanup such places. > Found by IntelliJ IDEA inspection `Redundant 'String' operation`. Thank you for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/7878 From aturbanov at openjdk.java.net Wed Mar 30 21:12:39 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 30 Mar 2022 21:12:39 GMT Subject: Integrated: 8283801: Cleanup confusing String.toString calls In-Reply-To: <-ZqXmYduQRz20bw-aAD90xx3DLNuq4xoM6Wi4zWN520=.21c06a63-7038-4c0c-ae06-f708b8cbbb64@github.com> References: <-ZqXmYduQRz20bw-aAD90xx3DLNuq4xoM6Wi4zWN520=.21c06a63-7038-4c0c-ae06-f708b8cbbb64@github.com> Message-ID: <1DfFA9Sufk6AM1kJgYtrpel08vkM3z2yvQUj7PIPZIk=.bf733b72-954c-4764-aad9-134956d42717@github.com> On Sun, 20 Mar 2022 13:20:31 GMT, Andrey Turbanov wrote: > String.toString() calls doesn't make much sense. Only one place, where it could be used - to generate NPE. But in a few places of JDK codebase it's called, even when NPE will happen anyway. > I propose to cleanup such places. > Found by IntelliJ IDEA inspection `Redundant 'String' operation`. This pull request has now been integrated. Changeset: b8dd21b7 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/b8dd21b790f36450de9aa0acc56251715b1a33e9 Stats: 14 lines in 4 files changed: 0 ins; 4 del; 10 mod 8283801: Cleanup confusing String.toString calls Reviewed-by: bpb ------------- PR: https://git.openjdk.java.net/jdk/pull/7878 From mcimadamore at openjdk.java.net Wed Mar 30 21:51:16 2022 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 30 Mar 2022 21:51:16 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/424 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: - Merge branch 'master' into foreign-preview - Tweak FunctionDescriptor::argumentLayouts to return an immutable list - Fix bad usage of `@link` with primitive array types - Switch to daemon threads for async upcalls - Use thread local storage to optimize attach of async threads - Drop support for Constable from MemoryLayout/FunctionDescriptor - Merge branch 'master' into foreign-preview - Revert changes to RunTests.gmk - Add --enable-preview to micro benchmark java options - Address more review comments - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5 ------------- Changes: https://git.openjdk.java.net/jdk/pull/7888/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7888&range=15 Stats: 64862 lines in 366 files changed: 43028 ins; 19321 del; 2513 mod Patch: https://git.openjdk.java.net/jdk/pull/7888.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7888/head:pull/7888 PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Wed Mar 30 22:02:37 2022 From: duke at openjdk.java.net (Muescha) Date: Wed, 30 Mar 2022 22:02:37 GMT Subject: RFR: JDK-8277095 : Empty streams create too many objects [v2] In-Reply-To: References: Message-ID: On Tue, 16 Nov 2021 20:53:26 GMT, kabutz wrote: >> This is a draft proposal for how we could improve stream performance for the case where the streams are empty. Empty collections are common-place. If we iterate over them with an Iterator, we would have to create one small Iterator object (which could often be eliminated) and if it is empty we are done. However, with Streams we first have to build up the entire pipeline, until we realize that there is no work to do. With this example, we change Collection#stream() to first check if the collection is empty, and if it is, we simply return an EmptyStream. We also have EmptyIntStream, EmptyLongStream and EmptyDoubleStream. We have taken great care for these to have the same characteristics and behaviour as the streams returned by Stream.empty(), IntStream.empty(), etc. >> >> Some of the JDK tests fail with this, due to ClassCastExceptions (our EmptyStream is not an AbstractPipeline) and AssertionError, since we can call some methods repeatedly on the stream without it failing. On the plus side, creating a complex stream on an empty stream gives us upwards of 50x increase in performance due to a much smaller object allocation rate. This PR includes the code for the change, unit tests and also a JMH benchmark to demonstrate the improvement. > > kabutz has updated the pull request incrementally with one additional commit since the last revision: > > Refactored empty stream implementations to reduce duplicate code and improved unordered() > Added StreamSupport.empty for primitive spliterators and use that in Arrays.stream() satisfy the bot with a comment - we are on day 20 now :) @kabutz i hope that was ok? ------------- PR: https://git.openjdk.java.net/jdk/pull/6275 From rriggs at openjdk.java.net Wed Mar 30 22:19:33 2022 From: rriggs at openjdk.java.net (Roger Riggs) Date: Wed, 30 Mar 2022 22:19:33 GMT Subject: RFR: 8283996: Reduce cost of year and month calculations In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 12:06:39 GMT, Claes Redestad wrote: > A few integer divisions and multiplications can be replaced with test + addition, leading to a decent speed-up on java.time microbenchmarks such as `GetYearBench`. Numbers from my local x86 workstation, seeing similar speed-up on aarch64 and other x86 setups. > > Baseline: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 18.492 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.121 ? 0.135 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 18.936 ? 0.012 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 9.283 ? 0.222 ops/ms > > Patched: > > Benchmark Mode Cnt Score Error Units > GetYearBench.getYearFromMillisZoneOffset thrpt 15 20.931 ? 0.013 ops/ms > GetYearBench.getYearFromMillisZoneRegion thrpt 15 6.858 ? 0.167 ops/ms > GetYearBench.getYearFromMillisZoneRegionNormalized thrpt 15 20.923 ? 0.017 ops/ms > GetYearBench.getYearFromMillisZoneRegionUTC thrpt 15 10.028 ? 0.182 ops/ms > > > Testing: java.time tests locally, CI tier1+2 ongoing. Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8039 From duke at openjdk.java.net Wed Mar 30 22:25:44 2022 From: duke at openjdk.java.net (ExE Boss) Date: Wed, 30 Mar 2022 22:25:44 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v15] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 20:59:34 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Tweak FunctionDescriptor::argumentLayouts to return an immutable list src/java.base/share/classes/java/lang/foreign/FunctionDescriptor.java line 73: > 71: */ > 72: public List argumentLayouts() { > 73: return Collections.unmodifiableList(argLayouts); This?change doesn?t?seem to?be?necessary, as?`FunctionDescriptor` is?already?created?with?`List.of(?)` (or?`Stream.toList()` in?the?case of?`FunctionDescriptor.VariadicFunction`), which?produce immutable?lists (although?`Stream.toList()` permits?`null`s, which?`Stream.collect(Collectors.toImmutableList())` and?`List.of(?)`?doesn?t). ------------- PR: https://git.openjdk.java.net/jdk/pull/7888 From psandoz at openjdk.java.net Wed Mar 30 22:44:42 2022 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 30 Mar 2022 22:44:42 GMT Subject: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v16] In-Reply-To: References: Message-ID: On Wed, 30 Mar 2022 21:51:16 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-424 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/424 > > Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits: > > - Merge branch 'master' into foreign-preview > - Tweak FunctionDescriptor::argumentLayouts to return an immutable list > - Fix bad usage of `@link` with primitive array types > - Switch to daemon threads for async upcalls > - Use thread local storage to optimize attach of async threads > - Drop support for Constable from MemoryLayout/FunctionDescriptor > - Merge branch 'master' into foreign-preview > - Revert changes to RunTests.gmk > - Add --enable-preview to micro benchmark java options > - Address more review comments > - ... and 21 more: https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5 Java code looks good (i did not go through the tests). As is common no comments, since code was reviewed in smaller steps in the panama-foreign respository. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/7888 From duke at openjdk.java.net Wed Mar 30 23:11:22 2022 From: duke at openjdk.java.net (Vamsi Parasa) Date: Wed, 30 Mar 2022 23:11:22 GMT Subject: RFR: 8283726: x86 intrinsics for compare method in Integer and Long [v2] In-Reply-To: References: Message-ID: > Implements x86 intrinsics for compare() method in java.lang.Integer and java.lang.Long. Vamsi Parasa 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: - refactored x86_64.ad code to macro assembly routines - Merge branch 'master' of https://git.openjdk.java.net/jdk into cmp - add JMH benchmarks - 8283726: x86 intrinsics for compare method in Integer and Long ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7975/files - new: https://git.openjdk.java.net/jdk/pull/7975/files/b0c3314d..79e4aa50 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7975&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7975&range=00-01 Stats: 5452 lines in 218 files changed: 3925 ins; 856 del; 671 mod Patch: https://git.openjdk.java.net/jdk/pull/7975.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7975/head:pull/7975 PR: https://git.openjdk.java.net/jdk/pull/7975 From duke at openjdk.java.net Wed Mar 30 23:21:20 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 30 Mar 2022 23:21:20 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v8] In-Reply-To: References: Message-ID: > 8186958: Need method to create pre-sized HashMap XenoAmess has updated the pull request incrementally with one additional commit since the last revision: update codes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/7928/files - new: https://git.openjdk.java.net/jdk/pull/7928/files/293b949c..fe0f31c8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7928&range=06-07 Stats: 61 lines in 3 files changed: 4 ins; 24 del; 33 mod Patch: https://git.openjdk.java.net/jdk/pull/7928.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7928/head:pull/7928 PR: https://git.openjdk.java.net/jdk/pull/7928 From duke at openjdk.java.net Wed Mar 30 23:21:20 2022 From: duke at openjdk.java.net (XenoAmess) Date: Wed, 30 Mar 2022 23:21:20 GMT Subject: RFR: 8186958: Need method to create pre-sized HashMap [v7] In-Reply-To: References: Message-ID: <-st52VdVxyyYRTgqZwMlUNkFhfCCgcamsAHqOkSG_PA=.1e435fe4-8c41-485d-9f1a-420de0e19b78@github.com> On Wed, 30 Mar 2022 00:12:59 GMT, Stuart Marks wrote: >> XenoAmess has updated the pull request incrementally with two additional commits since the last revision: >> >> - update jmh >> - refine javadoc; refine implement when expectedSize < 0 > > OK, finally got some time to look at this. Here's a rewrite of the spec words, at least for HashMap::newHashMap. If this settles down, I'll write the CSR for this and LHM and WHM. > > /** > * Creates a new, empty HashMap suitable for the expected number of mappings. > * The returned map uses the default load factor of 0.75, and its initial capacity is > * generally large enough so that the expected number of mappings can be added > * without resizing the map. > * > * @param numMappings the expected number of mappings > * @param the type of keys maintained by this map > * @param the type of mapped values > * @return the newly created map > * @throws IllegalArgumentException if numMappings is negative > * @since 19 > */ > > The original wording was taken from CHM, which generally is a reasonable thing to do. Unfortunately, it's wrong. :-) "Table size" isn't accurate; HashMap uses "capacity" as the term for the number of buckets (== length of the internal table array). "Size" means "number of mappings" so its use of "table size" confuses these two concepts. The CHM wording also uses "elements" which applies to linear collections; the things inside a map are usually referred to as "mappings" or "entries". (I guess we should fix up CHM at some point too.) > > While "expectedSize" isn't inaccurate, it's not tied to the main text, so I've renamed it to numMappings. > > There are a couple other javadoc style rules operating here. The first sentence is generally a sentence fragment that is short and descriptive, as it will be pulled into a summary table. (It's often written as if it were a sentence that begins "This method..." but those words are elided.) Details are in the rest of the first paragraph. The text for `@param`, `@return`, and `@throws` are generally also sentence fragments, and they have no initial capital letter nor trailing period. > > -- > > On performance and benchmarking: this is a distraction from the main point of this effort, which is to add an API that allows callers a correct and convenient way to create a properly-sized HashMap. Any work spent on optimizing performance is almost certainly wasted. > > First, the benchmark: it's entirely unclear what this is measuring. It's performing the operation 2^31 times, but it sends the result to a black hole so that the JIT doesn't eliminate the computation. One of the actual results is 0.170 ops/sec. This includes both the operation and the black hole, so we don't actually have any idea what that result represents. _Maybe_ it's possible to infer some idea of relative performance of the different operations by comparing the results. It's certainly plausible that the integer code is faster than the float or double code. But the benchmark doesn't tell us how long the actual computation takes. > > Second, how significant is the cost of the computation? I'll assert that it's insignificant. The table length is computed once at HashMap creation time, and it's amortized over the addition of all the initial entries and subsequent queries and updates to the HashMap. Any of the computations (whether integer or floating point) are a handful of nanoseconds. This will be swamped by the first hashCode computation that causes a cache miss. > > Third: I'll stipulate that the integer computation is probably a few ns faster than the floating-point computation. But the computation is entirely non-obvious. To make up for it being non-obvious, there's a big comment that explains it all. It's not worth doing something that increases performance by an insignificant amount that also requires a big explanation. > > Finally, note that most of the callers are already doing a floating-point computation to compute the desired capacity, and it doesn't seem to be a problem. > > Sorry, you probably spent a bunch of time on this already, but trying to optimize the performance here just isn't worthwhile. Let's please just stick with our good old `(int) Math.ceil(numMappings / 0.75)`. > > -- > > There should be regression tests added for the three new methods. I haven't thought much about this. It might be possible to reuse some of the infrastructure in the WhiteBoxResizeTest we worked on previously. > > -- > > I think it would be good to include updates to some of the use sites in this PR. It's often useful to put new APIs into practice. One usually learns something from the effort. Even though this is a really simple API, looking at use sites can illuminating, to see how the code reads. This might affect the method name, for example. > > You don't need to update all of the use sites in the JDK, but it would be good to choose a reasonable sample. Maybe the ones from a single package, or a handful (like java.lang or java.util). Maybe include Class::enumConstantDirectory. If this use site is updated, then maybe it will allow us to get rid of that ConstantDirectoryOptimalCapacity test that we problem-listed in the previous PR. @stuart-marks codes and javadocs done. usages and tests are on the way. ------------- PR: https://git.openjdk.java.net/jdk/pull/7928 From serban.iordache at gmail.com Wed Mar 16 19:34:50 2022 From: serban.iordache at gmail.com (Serban Iordache) Date: Wed, 16 Mar 2022 20:34:50 +0100 Subject: Fwd: JDK-17 jpackage: error when using --add-launcher with --runtime-image In-Reply-To: References: Message-ID: Hi, When using --add-launcher together with --runtime-image, jpackager exits with the error message: java.lang.ClassCastException: class java.util.ImmutableCollections$List12 cannot be cast to class java.lang.String (java.util.ImmutableCollections$List12 and java.lang.String are in module java.base of loader 'bootstrap') For example, the following command fails: jpackage --dest pkg --name main --module example/example.Main --runtime-image ./image --add-launcher secondary=./secondary.properties However, it works when using --module-path instead of --runtime-image: jpackage --dest pkg --name main --module example/example.Main --module-path ./mods --win-console --add-launcher secondary=./secondary.properties A reproducer is available here: https://github.com/SSCCE/jpackage-launcher-issue. This error seems to occur only in JDK-17. JDK-16 is not affected by this issue: https://github.com/SSCCE/jpackage-launcher-issue/actions/runs/1933837183. - Serban