From darcy at openjdk.org Thu Dec 1 05:44:44 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Dec 2022 05:44:44 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v3] In-Reply-To: References: Message-ID: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com> > Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. Joe Darcy has updated the pull request 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: - Respond to review feedback. - Merge branch 'master' into JDK-8297215 - Respond to review feedback. - JDK-8297215: Update libs tests to use @enablePreview ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11222/files - new: https://git.openjdk.org/jdk/pull/11222/files/f3fc9e26..6d11bbca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=01-02 Stats: 47274 lines in 976 files changed: 24551 ins; 8961 del; 13762 mod Patch: https://git.openjdk.org/jdk/pull/11222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222 PR: https://git.openjdk.org/jdk/pull/11222 From thomas.stuefe at gmail.com Thu Dec 1 07:26:07 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Dec 2022 08:26:07 +0100 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: References: <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com> Message-ID: Hi Carter, Stefan, thank you, I think it is good to have this discussion, it is important. Side note, the discussion steered away from my original question - whether to instrument the JDK with NMT. I still would love to discuss that, too. About opening NMT up for user consumption, that is of course possible. But I think the bigger question is which data we want to open for user consumption, and at what granularity. And what contracts do we enter when we do this. NMT was originally a hotspot-dev-centric tool. It has a lot of idiosyncrasies. Interpreting the results needs detailed knowledge about hotspot memory management. Some examples: - its reports are not consistent across JDK versions, not even across different patch levels of the same JDK. So you cannot compare results, say, between JDK11 and 17. - before a certain version X (I believe JDK 11), the full thread stacks were accounted for instead of just the in-use portion of the thread stacks. I remember reading blogs about how thread stack consumption went down when all that changed was NMT reporting. - The memory sizes it shows may not have much to do with real RSS. It systematically underreports some things, since it omits libc overhead and retention, usage by system- and JNI libraries. But it also overreports things since it mostly (not always) accounts in terms of "committed" memory, which usually means mmap()ed or malloc()ed memory. But that is just committed, not physical memory, it does not translate to RSS usage directly. That memory may never be touched. OTOH NMT probes thread stacks with mincore(), so for that section, "committed" really means "physical". I am fine with opening up NMT via JFR. But does this mean we have to be more consistent? Do we have to care about downward compatibility of NMT reports? Are we then still free to redesign the tag system (see my original mail) or will this tie us down with the current NMT tag system forever? As a negative example, JFR exposes metaspace allocator details (chunk statistics) which have been broken ever since JDK 16 when the underlying implementation changed. Therefore I am curious about what end users use NMT really for. @Carter: can you give us examples of which NMT sections had been particularly useful to you? Maybe we can define a subset to expose instead of exposing all tags. E.g. I can see thread stack usage being very useful, but things like ObjectMonitor footprint not so much. Cheers, Thomas On Wed, Nov 30, 2022 at 9:45 PM Carter Kozak wrote: > This looks fantastic, thank you so much! I can confirm that the proposed > design would solve my use-case. > > I'd enjoy discussing the NMT event contract somewhere more specific > to the implementation, but I don't want to muddle this thread with > implementation details. > > Carter Kozak > > On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote: > > Hi Carter, > > Your mail made me pick up an old item from my wishlist: to have native > memory tracking information available in JFR recordings. When we, in GC, > do improvements to decrease the native memory overhead of our > algorithms, NMT is a very good tool to track the progress. We have > scripts that sound very similar to what you describe and more than once > I've been thinking about adding this information into JFR. But it has > not been a priority and the greater value has been unclear. > > Hearing that others might also benefit from such a change I took a > discussion with the JFR team on how to best proceed with this. I have > created a branch for this and will probably create a PR for it shortly, > but I thought I would drop it here first: > https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt > > The change adds two new JFR events: one for the total usage and one for > the usage of each memory type. These are sent only if Native Memory > Tracking is turned on, and they are enabled in the default JFR profile > with an interval of 1s. This might change during reviewing but it was a > good starting point. > > With this you will be able to use JFR streaming to access the events > from within your running process. I hope this will help your use cases > and please let us know if you have any comments or suggestions. > > Thanks, > Stefan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Thu Dec 1 08:02:15 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 1 Dec 2022 08:02:15 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v3] In-Reply-To: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com> References: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com> Message-ID: On Thu, 1 Dec 2022 05:44:44 GMT, Joe Darcy wrote: >> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. > > 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 four additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8297215 > - Respond to review feedback. > - JDK-8297215: Update libs tests to use @enablePreview Latest update looks good, will make the test changes easy when features move from preview to permanent. test/jdk/java/net/Socket/Timeouts.java line 30: > 28: * @build jdk.test.lib.Utils > 29: * @enablePreview > 30: * @compile Timeouts.java I assume the `@compile` can be dropped from this one, doesn't matter. ------------- Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11222 From sspitsyn at openjdk.org Thu Dec 1 08:56:26 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 1 Dec 2022 08:56:26 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v3] In-Reply-To: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com> References: <6TQkLW3qFJge_NHSssVQFJm6y79L1IDtO1HmMgMFE24=.8ba6b5ae-39c8-4d4b-b1f9-9913f484827a@github.com> Message-ID: On Thu, 1 Dec 2022 05:44:44 GMT, Joe Darcy wrote: >> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. > > 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 four additional commits since the last revision: > > - Respond to review feedback. > - Merge branch 'master' into JDK-8297215 > - Respond to review feedback. > - JDK-8297215: Update libs tests to use @enablePreview Looks good. Posted several nits though. Thanks, Serguei test/jdk/java/lang/Thread/virtual/GetStackTraceWhenRunnable.java line 29: > 27: * @requires vm.continuations > 28: * @enablePreview > 29: * @compile GetStackTraceWhenRunnable.java Nit: Is the line 29 for compiling necessary? test/jdk/java/lang/instrument/ParallelTransformerLoaderTest.java line 37: > 35: * @library /test/lib > 36: * @run build TestClass1 TestClass2 TestClass3 > 37: * @compile --enable-preview -source ${jdk.version} ParallelTransformerLoaderTest.java Nit: This change is strange. It is either not needed or missing something. test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 41: > 39: * @test > 40: * @enablePreview > 41: * @compile SwitchBootstrapsTest.java Nit: Is the line 41 for compiling necessary? test/jdk/java/net/vthread/HttpALot.java line 32: > 30: * @library /test/lib > 31: * @enablePreview > 32: * @compile HttpALot.java Nit: Is the line 32 for compiling necessary? test/jdk/java/net/vthread/InterruptHttp.java line 29: > 27: * @library /test/lib > 28: * @enablePreview > 29: * @compile InterruptHttp.java Nit: Is the line 29 for compiling necessary? test/jdk/jdk/jfr/event/runtime/TestThreadSleepEvent.java line 44: > 42: * @library /test/lib > 43: * @enablePreview > 44: * @compile TestThreadSleepEvent.java Nit: Is the line 44 for compiling necessary? test/jdk/jdk/jfr/threading/TestManyVirtualThreads.java line 47: > 45: * @modules jdk.jfr/jdk.jfr.internal > 46: * @enablePreview > 47: * @compile TestManyVirtualThreads.java Nit: Not sure the line 47 for compiling is necessary? test/jdk/jdk/jfr/threading/TestNestedVirtualThreads.java line 45: > 43: * @modules jdk.jfr/jdk.jfr.internal > 44: * @enablePreview > 45: * @compile TestNestedVirtualThreads.java Nit: Not sure the line 45 for compiling is necessary? ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11222 From coleenp at openjdk.org Thu Dec 1 09:37:40 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Dec 2022 09:37:40 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 22:14:06 GMT, David Holmes wrote: >> add() is supposed to add a new object with tag. There is an assert() in its body that checks it. By removing the assert, add() can be used for updating as well. > > Are you suggesting that `add` can also act as a `replace` operation? I would think we would want a separate method for that. Yes, this could have a replace operation that does below which would be better: void JvmtiTagMapTable::replace(oop o, jlong tag) { JvmtiTagMapEntry key(o); bool is_added = _rrht_table.put(new_entry, tag); assert(!is_added, "should not be added"); } ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Thu Dec 1 09:37:42 2022 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 1 Dec 2022 09:37:42 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable In-Reply-To: References: Message-ID: On Tue, 29 Nov 2022 23:07:15 GMT, Coleen Phillimore wrote: >> Are you suggesting that `add` can also act as a `replace` operation? I would think we would want a separate method for that. > > Yes, this could have a replace operation that does below which would be better: > > void JvmtiTagMapTable::replace(oop o, jlong tag) { > JvmtiTagMapEntry key(o); > bool is_added = _rrht_table.put(new_entry, tag); > assert(!is_added, "should not be added"); > } I didn't notice the suggested name (`replace()`), so It is implemented as `update()` method. It is tested locally by running tests vmTestbse/nsk/jvmti and vmTEstbase//nck/jdi. tier1-5 are also passed. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From coleenp at openjdk.org Thu Dec 1 09:37:46 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Dec 2022 09:37:46 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable In-Reply-To: References: Message-ID: On Tue, 22 Nov 2022 14:48:11 GMT, Afshin Zafari wrote: > test of tier1-5 passed. src/hotspot/share/prims/jvmtiTagMapTable.hpp line 41: > 39: JvmtiTagMapEntry* next() const { > 40: return (JvmtiTagMapEntry*)HashtableEntry::next(); > 41: } This should add a comment above JvmtiTagMapEntry that the entry is the key (could be renamed JvmtiTagMapKey). Also add a comment above that the oop is needed for lookup rather than creating a WeakHandle during lookup because the HeapWalker may walk soon to be dead objects and creating a WeakHandle for an otherwise dead object makes G1 unhappy. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From stefan.johansson at oracle.com Thu Dec 1 10:52:50 2022 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 1 Dec 2022 11:52:50 +0100 Subject: [External] : Re: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: References: <4f7deee9-366d-05a2-9268-09a25a138d8d@oracle.com> Message-ID: <4a2dbc13-dc65-e8ba-a40c-ff6b1cef931d@oracle.com> Hi Thomas and Carter, I opened up a PR for this to allow more specific comments on the implementation: https://github.com/openjdk/jdk/pull/11449 If this discussion leads to us not wanting to proceed with the change I will withdraw the PR. Some more comments below. On 2022-12-01 08:26, Thomas St?fe wrote: > Hi Carter, Stefan, > > thank you, I think it is good to have this discussion, it is important. > > Side note, the discussion steered away from my original question - > whether to instrument the JDK with NMT. I still would love to discuss > that, too. > Sorry for that :) > About opening NMT up for user consumption, that is of course possible. > But I think the bigger question is which data we want to open for user > consumption, and at what granularity. And what contracts do we enter > when we do this. > To me this is not so much opening it up, but just making it much simpler to get the already available data (JFR instead of jcmd). I get your point that when we make it easier it will likely get more visibility and that could generate expectations. To me the contract on these events should not be much harder than, for example, the contract we have on the format of GC logs. So we should not be locked down by this. > NMT was originally a hotspot-dev-centric tool. It has a lot of > idiosyncrasies. Interpreting the results needs detailed knowledge about > hotspot memory management. Some examples: > > - its reports are not consistent across JDK versions, not even across > different patch levels of the same JDK. So you cannot compare results, > say, between JDK11 and 17. > - before a certain version X (I believe JDK 11), the full thread stacks > were accounted for instead of just the in-use portion of the thread > stacks. I remember reading blogs about how thread stack consumption went > down when all that changed was NMT reporting. > - The memory sizes it shows may not have much to do with real RSS. It > systematically underreports some things, since it omits libc overhead > and retention, usage by system- and JNI libraries. But it also > overreports things since it mostly (not always) accounts in terms of > "committed" memory, which usually means mmap()ed or malloc()ed memory. > But that is just committed, not physical memory, it does not translate > to RSS usage directly. That memory may never be touched. OTOH NMT probes > thread stacks with mincore(), so for that section, "committed" really > means "physical". > I agree that NMT is a low-level tool and that it's not perfect. But in some cases I think it's the best way to see the memory consumption of the JVM. Especially since you can zoom in on certain areas. > I am fine with opening up NMT via JFR. But does this mean we have to be > more consistent? Do we have to care about downward compatibility of NMT > reports? Are we then still free to redesign the tag system (see my > original mail) or will this tie us down with the current NMT tag system > forever? As a negative example, JFR exposes metaspace allocator details > (chunk statistics) which have been broken ever since JDK 16 when the > underlying implementation changed. > I think a tag based system for NMT would be awesome and it would be really sad if exposing the NMT information through JFR would stop us from doing this. Hopefully the only thing we need to do when improving NMT is to do CSRs. One possible way to avoid constraints even more would be to tag those events as "experimental" at first. This would signal that user should not rely on them. > Therefore I am curious about what end users use NMT really for. > > @Carter: can you give us examples of which NMT sections had been > particularly useful to you? Maybe we can define a subset to expose > instead of exposing all tags. E.g. I can see thread stack usage being > very useful, but things like ObjectMonitor footprint not so much. > I agree that not to many users would care about the ObjectMonitor footprint, but unless we get constrained by what we report I would like to report all. If there are constraints, this might be a good middle road. Thanks, Stefan > Cheers, Thomas > > > > > On Wed, Nov 30, 2022 at 9:45 PM Carter Kozak > wrote: > > __ > This looks fantastic, thank you so much! I can confirm that the > proposed > design would solve my use-case. > > I'd enjoy discussing the NMT event? contract somewhere more specific > to the implementation, but I don't want to muddle this thread with > implementation details. > > Carter Kozak > > On Wed, Nov 30, 2022, at 03:37, Stefan Johansson wrote: >> Hi Carter, >> >> Your mail made me pick up an old item from my wishlist: to have >> native >> memory tracking information available in JFR recordings. When we, >> in GC, >> do improvements to decrease the native memory overhead of our >> algorithms, NMT is a very good tool to track the progress. We have >> scripts that sound very similar to what you describe and more than >> once >> I've been thinking about adding this information into JFR. But it has >> not been a priority and the greater value has been unclear. >> >> Hearing that others might also benefit from such a change I took a >> discussion with the JFR team on how to best proceed with this. I have >> created a branch for this and will probably create a PR for it >> shortly, >> but I thought I would drop it here first: >> https://github.com/kstefanj/jdk/tree/8157023-jfr-events-for-nmt >> >> >> The change adds two new JFR events: one for the total usage and >> one for >> the usage of each memory type. These are sent only if Native Memory >> Tracking is turned on, and they are enabled in the default JFR >> profile >> with an interval of 1s. This might change during reviewing but it >> was a >> good starting point. >> >> With this you will be able to use JFR streaming to access the events >> from within your running process. I hope this will help your use >> cases >> and please let us know if you have any comments or suggestions. >> >> Thanks, >> Stefan > From kevinw at openjdk.org Thu Dec 1 12:39:05 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 1 Dec 2022 12:39:05 GMT Subject: RFR: 8297794: Deprecate JMX Management Applets for Removal [v4] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote: >> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal. >> >> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools. >> >> More details in bug, and CSR JDK-8297795 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary Suppression nit Added release-note in a subtask for the issue. ------------- PR: https://git.openjdk.org/jdk/pull/11430 From coleenp at openjdk.org Thu Dec 1 14:57:07 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 1 Dec 2022 14:57:07 GMT Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero Message-ID: This has verification code that I'm going to remove so we can backport this. ------------- Commit messages: - remove verification code. - 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero Changes: https://git.openjdk.org/jdk/pull/11444/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11444&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291830 Stats: 21 lines in 5 files changed: 9 ins; 4 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/11444.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11444/head:pull/11444 PR: https://git.openjdk.org/jdk/pull/11444 From dfuchs at openjdk.org Thu Dec 1 16:05:30 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 1 Dec 2022 16:05:30 GMT Subject: RFR: 8297794: Deprecate JMX Management Applets for Removal [v4] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote: >> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal. >> >> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools. >> >> More details in bug, and CSR JDK-8297795 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary Suppression nit LGTM ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11430 From darcy at openjdk.org Thu Dec 1 18:00:11 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Dec 2022 18:00:11 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v4] In-Reply-To: References: Message-ID: > Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11222/files - new: https://git.openjdk.org/jdk/pull/11222/files/6d11bbca..c0bef63e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=02-03 Stats: 5 lines in 5 files changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222 PR: https://git.openjdk.org/jdk/pull/11222 From thomas.stuefe at gmail.com Thu Dec 1 18:14:52 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 1 Dec 2022 19:14:52 +0100 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: References: Message-ID: Are there any opinions about whether or not to extend NMT across the JDK? This blocks https://bugs.openjdk.org/browse/JDK-8296360, and I had a PR prepared as https://github.com/openjdk/jdk/pull/10988. Originally I was hoping to get this into JDK 20, but I don't think that is realistic anymore. I am fine with postponing my work in favor of a baseline discussion, but so far there is very little discussion about this topic. How should I proceed? Thanks, Thomas On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe wrote: > Hi Alan, > > (replaced hotspot-runtime-dev with hotspot-dev, since its more of a > general topic) > > thank you for your time! > > I am very happy to talk this through. I think native memory observability > in the JDK (and customer code!) is sorely lacking. Witness the countless > "where did my native memory go" blog articles. At SAP we have been > struggling with this topic for a long time and have come up with a mixture > of solutions. The aforementioned tracker was one, which extended our > version of NMT across the JDK. Our SapMachine MallocTracer, which allows us > to trace uninstrumented customer code, another. We even experimented with > exchanging the allocator (using jemalloc) to gain insights. But that is a > whole different topic with deep logistical implications, I don't want to > touch it here. Exchanging the allocator does not help to observe virtual > memory or the brk segment, of course. > > And to make the picture complete, another insight we currently lack is the > implicit allocator overhead, which can be very significant and is hidden by > the libc. We also have observability for that in the SapMachine, and I miss > it in OpenJDK. > > As you noticed, my original intent was just to instrument Zlib and > possibly improve tracking for DBBs. Although, thinking beyond that, another > attractive instrumentation target would be mapped NIO buffers at least. > > So I think native memory observability is important. Arguably we could > even extend observability to cover other OS resources, e.g. file handles. > If we shift code around, to java/Panama: data that move the java heap does > not need to be tracked, but other memory will always come from one of the > basic system APIs, regardless of who allocates it and where in the stack > allocation happens. Be it native JDK code, Panama, or even customer JNI > code. > > If we agree on the importance of native memory observability, then I > believe NMT is the right tool for it. It is a good tool. The machinery is > already there. It covers both C-heap and virtual memory APIs, as well as > thread stacks, and could easily be extended to cover sbrk if needed. And I > assume that whatever shape OpenJDK takes on in the future, there always > will be a libjvm.so at its core, so we will always have it. But even if > not, NMT could be separated from libjvm.so quite easily, since it has no > deep ties with the JVM. > > About coupling JVM with outside code: We don't have to directly link > against libjvm.so. We can keep things loose if the intent is to be runnable > without a JVM, or be JVM-version-agnostic. That could take the form of a > function-pointer interface like JVMTI. Or outside code could dynamically > dlsym the JVM allocation hooks. In any case gracefully falling back to > system allocation routines when necessary. > > And I agree, polluting the NMT tag space with outside meaning is ugly. I > only did it because I planned to go no further than instrumenting Zlib and > possibly DBBs. But if we take this further, my preferred solution would be > a reserved tag range or -ranges for outside use, whose inner meaning would > be opaque to the JVM. Kind of like SIGRTMIN+SIGRTMAX. Then, outside code > could register tags and their meta information with the JVM, or we find a > different way to convey the tag meaning to NMT (config files, or > callbacks). That could even be opened up for customer use. > > This also touches on another question, that of NMT tag space. NMT tags are > very useful since they allow cheap tracking without capturing call stacks. > However, tags are underused and show growing pains since they are too > one-dimensional and restrictive. We had competing interests in the past > about tag granularity. It is all over the place. We have coarse-grained > tags like "mtThread", and very fine-grained ones like "mtObjectMonitor". > There are several ways we could improve, e.g., by making them combinable > like UL does, or allowing for a hierarchy of them - either a hard-wired > limited one like "domain"+"tag", or an unlimited tree-like one. Technically > interesting since whatever the new encoding is, they still must fit into a > malloc header. I opened https://bugs.openjdk.org/browse/JDK-8281819 to > track ideas like these. > > Instrumenting Panama allocations, including the ability to tag > allocations, would be a very good idea. For instance, if we ever remove the > native Zlib layer and convert it to java using Panama, we can do the same > with Panama I do now natively - use the Zlib zalloc interface to hook in > JVM memory allocation functions. The result could be completely identical, > and the end user looking at the NMT output need never know that anything > changed. > > And that goes for all instrumentation - if today we add it to JNI code, > and that code gets removed tomorrow, we can add it to Panama code too. > Unless data structures move to the heap, in which case there is no need to > track them. > > You mentioned that NMT was more of an in-house support tool. Our > experience is different. Even though it was positioned as a tool for JVM > developers, and we never cared for the backward compatibility or > consistency, it gets used a *lot* by our customers. We have to explain its > output frequently. Also, many blog articles exist documenting its use. So, > maybe it would be okay to elevate it to a user-facing tool since it seems > to occupy that role anyway. We may also open up consumption of NMT results > via java APIs, or expose its results via MXBeans. > > If this is to be a JEP, okay, but I'm afraid it would stall things a bit. > I am interested in getting a simpler and quicker solution for older support > releases at least, possibly based on my PR. I know that would be > unconventional though. > > Thank you, > > Thomas > > > On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman > wrote: > >> On 04/11/2022 16:54, Thomas St?fe wrote: >> > Hi all, >> > >> > I am currently working on https://bugs.openjdk.org/browse/JDK-8296360; >> > I was preparing the final PR [1], but then Alan did ask me to discuss >> > this on core-libs first. >> > >> > Backstory: >> > >> > NMT tracks hotspot native allocations but does not cover the JDK >> > libraries (small exception: Unsafe.AllocateMemory). However, the >> > native memory footprint of JDK libraries can be significant. We have >> > no in-VM tracker for these and need tools like valgrind or our >> > SapMachine MallocTracer [2] to observe them. >> >> Thanks for starting a discussion on this as this is a topic that >> requires agreement from several areas. If this is the start of something >> bigger, where you want to have all allocation sites in the libraries >> using NMT, then I think it needs a write-up, maybe a JEP. >> >> For starters, I think it needs some agreement on using NMT for memory >> allocated outside of libjvm. You mentioned Unsafe as an exception but >> that is implemented in the VM so you get tracking for free, albeit I >> think all allocations are in the "mtOther" category. >> >> A general concern is that it creates more coupling between the VM code >> and the libraries code. As you probably know, we've removed most of the >> dependences on JVM_* functions from non-core areas over many years. So I >> think that needs consideration as I assume we don't want >> memory/allocation.hpp declaring a dozen catagories for allocations done >> in say java.desktop module for example. Maybe your proposal will be >> strictly limited to java.base but even then, do we really want the VM >> even knowing about categories that are specific to zip compression or >> decompression? >> >> There are probably longer term trends that should be part of the >> discussion too. One general trend is that "run time" is becoming more >> and more a hybrid of code in libvm and the Java libraries. Lambdas, >> module system, virtual threads implementations are a few examples in the >> last few release. This comes with many "Java on Java" challenges, >> including serviceability where users of the platform will expect tools >> to just work and won't care where the code is. NMT is probably more for >> support teams and not something that most developers will ever use but I >> think is part of the challenge of having serviceability solutions "just >> work". >> >> In addition to having more of the Java runtime written in Java, there >> will likely be less JNI code in the future. It's very possible that the >> JNI code (including the JNI methods in libzip) will be replaced with >> code that uses Panama memory and linker APIs once they are become >> permanent. The effect of that would to have a lot of the memory >> allocations be tracked in the mtOther category again. Maybe integration >> with memory tracking should be looked at in conjunction with these APIs >> and this migration. I could imagine the proposed "Arena" API >> (MemorySession in Java 19) having some integration with NMT and it might >> be interesting to look into that. >> >> So yes, this topic does need broader discussion and it might be a bit >> premature to start with a PR for libzip without talking about the bigger >> picture first. >> >> -Alan >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From egahlin at openjdk.org Thu Dec 1 19:21:23 2022 From: egahlin at openjdk.org (Erik Gahlin) Date: Thu, 1 Dec 2022 19:21:23 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v4] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 18:00:11 GMT, Joe Darcy wrote: >> Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. test/jdk/jdk/jfr/threading/TestDeepVirtualStackTrace.java line 46: > 44: * @modules jdk.jfr/jdk.jfr.internal > 45: * @enablePreview > 46: * @compile TestDeepVirtualStackTrace.java Is compilation needed here? ------------- PR: https://git.openjdk.org/jdk/pull/11222 From jjg at openjdk.org Thu Dec 1 19:36:16 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:36:16 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> > Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. > > "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. > > "Normalized" means... > * Use `https:` where possible (includes pretty much all cases) > * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) > * Point to the root page of a multi-page spec > * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) > > In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. > > The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. > > That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. > > Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. > > To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ > > In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. Jonathan Gibbons 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: - Change ietf.org URLs to use rfc-editor.org - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags - Remove updates from unexported files - Prefix RFC titles with `RFC NNNN:` - JDK-8296547: Add @spec tags to API ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11073/files - new: https://git.openjdk.org/jdk/pull/11073/files/3905ac83..07882ffc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11073&range=02-03 Stats: 83309 lines in 1834 files changed: 38491 ins; 27762 del; 17056 mod Patch: https://git.openjdk.org/jdk/pull/11073.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11073/head:pull/11073 PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Dec 1 19:40:16 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:40:16 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> Message-ID: On Thu, 10 Nov 2022 23:51:19 GMT, Naoto Sato wrote: >> Jonathan Gibbons 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: >> >> - Change ietf.org URLs to use rfc-editor.org >> - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags >> - Remove updates from unexported files >> - Prefix RFC titles with `RFC NNNN:` >> - JDK-8296547: Add @spec tags to API > > src/java.base/share/classes/java/lang/Character.java line 172: > >> 170: * occur. For example, in a future release, synchronization may fail. >> 171: * >> 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 > > This should probably be removed, as the original link (explaining `U+n` notation) is broken. @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From jjg at openjdk.org Thu Dec 1 19:57:33 2022 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 1 Dec 2022 19:57:33 GMT Subject: RFR: 8296546: Add @spec tags to API [v3] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> Message-ID: On Wed, 23 Nov 2022 23:04:36 GMT, Joe Wang wrote: >> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove updates from unexported files > > src/java.xml/share/classes/javax/xml/XMLConstants.java line 35: > >> 33: * @spec https://www.w3.org/TR/REC-xml-names Namespaces in XML 1.0 (Third Edition) >> 34: * @spec https://www.w3.org/TR/xml-names11 Namespaces in XML 1.1 (Second Edition) >> 35: * @spec https://www.w3.org/TR/xmlschema-1 XML Schema Part 1: Structures Second Edition > > Hi Jon, > > I would agree with what Alan said earlier that the @see ref can be dropped. This particular class (XMLConstants.java [1]) is a good example for that argument: in the resulting javadoc, 5 specs were listed in the "External Specifications" section, 6 in "See Also:", and then they were listed again for each field. That's a lot of duplicates. Adding to the confusion was that the @spec and @see were not always the same, e.g. @spec XML 1.0. > points to the fifth edition while @see second. > > A minor comment is that the '@spec's were rendered in one line while the @see refs a list. I would see the later is easier to read. > > [1] http://cr.openjdk.java.net/~jjg/8296546/api.00/java.xml/javax/xml/XMLConstants.html The presentation of lists of `@spec` tags was fixed separately (JDK-8297802), and is incorporated into the latest docs that demo this work. The same algorithm is now used for both `@see` and `@spec` tags ... if the links are short and do not contain commas, they will be displayed as an inline list; otherwise, they will be displayed in a bulleted list. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From amenkov at openjdk.org Thu Dec 1 20:04:54 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Dec 2022 20:04:54 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v3] In-Reply-To: References: Message-ID: <7j_rN1OaZ5ASMkesFC9RBgOEILGqYbBW2tX3jFOoVlQ=.56eaf3b0-6ff7-4541-a1ed-b8b12dcc2bf4@github.com> > com.sun.jdi.ObjectReference::setValue spec says that final static fields cannot be modified, but openjdk implementation throws IllegalArgumentException for any final fields (static or instance). > > The fix updates the spec to prohibit any final field modification > CSR: JDK-8281652 Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: updated test to test instance final fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11279/files - new: https://git.openjdk.org/jdk/pull/11279/files/5d98874c..55a4616b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11279&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11279&range=01-02 Stats: 34 lines in 3 files changed: 22 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11279.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11279/head:pull/11279 PR: https://git.openjdk.org/jdk/pull/11279 From amenkov at openjdk.org Thu Dec 1 20:09:53 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Dec 2022 20:09:53 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v3] In-Reply-To: <7j_rN1OaZ5ASMkesFC9RBgOEILGqYbBW2tX3jFOoVlQ=.56eaf3b0-6ff7-4541-a1ed-b8b12dcc2bf4@github.com> References: <7j_rN1OaZ5ASMkesFC9RBgOEILGqYbBW2tX3jFOoVlQ=.56eaf3b0-6ff7-4541-a1ed-b8b12dcc2bf4@github.com> Message-ID: <4Fr10rDeelf6QUZf9VQ1GhmkYBqNhzM2bHKn9PM3u68=.2907dd2c-6a17-4e62-bca9-131059d27dd9@github.com> On Thu, 1 Dec 2022 20:04:54 GMT, Alex Menkov wrote: >> com.sun.jdi.ObjectReference::setValue spec says that final static fields cannot be modified, but openjdk implementation throws IllegalArgumentException for any final fields (static or instance). >> >> The fix updates the spec to prohibit any final field modification >> CSR: JDK-8281652 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated test to test instance final fields The only test for final fields is vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004. It tested only static final fields. I added testing for instance final fields ------------- PR: https://git.openjdk.org/jdk/pull/11279 From darcy at openjdk.org Thu Dec 1 20:32:49 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Dec 2022 20:32:49 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v5] In-Reply-To: References: Message-ID: > Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. Joe Darcy has updated the pull request 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: - Remove unnecessary @compile directives. - Merge branch 'master' into JDK-8297215 - Respond to review feedback. - Respond to review feedback. - Merge branch 'master' into JDK-8297215 - Respond to review feedback. - JDK-8297215: Update libs tests to use @enablePreview ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11222/files - new: https://git.openjdk.org/jdk/pull/11222/files/c0bef63e..d03ba044 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11222&range=03-04 Stats: 6073 lines in 149 files changed: 3996 ins; 1399 del; 678 mod Patch: https://git.openjdk.org/jdk/pull/11222.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11222/head:pull/11222 PR: https://git.openjdk.org/jdk/pull/11222 From darcy at openjdk.org Thu Dec 1 20:32:53 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Dec 2022 20:32:53 GMT Subject: RFR: JDK-8297215: Update libs tests to use @enablePreview [v4] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 19:19:01 GMT, Erik Gahlin wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > test/jdk/jdk/jfr/threading/TestDeepVirtualStackTrace.java line 46: > >> 44: * @modules jdk.jfr/jdk.jfr.internal >> 45: * @enablePreview >> 46: * @compile TestDeepVirtualStackTrace.java > > Is compilation needed here? For the two tests that compiled a single file, I remove the @compile directive. Any additional refactoring left for future work. ------------- PR: https://git.openjdk.org/jdk/pull/11222 From darcy at openjdk.org Thu Dec 1 20:41:35 2022 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 1 Dec 2022 20:41:35 GMT Subject: Integrated: JDK-8297215: Update libs tests to use @enablePreview In-Reply-To: References: Message-ID: On Thu, 17 Nov 2022 21:48:11 GMT, Joe Darcy wrote: > Similar to an update recently done for langtools tests, update the libraries regression tests to take advantage of the @enablePreview jtreg feature. This pull request has now been integrated. Changeset: 770ff5a8 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/770ff5a812d7b895ed2badfef9bb4e0b211d55bb Stats: 101 lines in 35 files changed: 12 ins; 2 del; 87 mod 8297215: Update libs tests to use @enablePreview Reviewed-by: alanb, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11222 From cjplummer at openjdk.org Thu Dec 1 21:16:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 1 Dec 2022 21:16:10 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v3] In-Reply-To: <7j_rN1OaZ5ASMkesFC9RBgOEILGqYbBW2tX3jFOoVlQ=.56eaf3b0-6ff7-4541-a1ed-b8b12dcc2bf4@github.com> References: <7j_rN1OaZ5ASMkesFC9RBgOEILGqYbBW2tX3jFOoVlQ=.56eaf3b0-6ff7-4541-a1ed-b8b12dcc2bf4@github.com> Message-ID: On Thu, 1 Dec 2022 20:04:54 GMT, Alex Menkov wrote: >> com.sun.jdi.ObjectReference::setValue spec says that final static fields cannot be modified, but openjdk implementation throws IllegalArgumentException for any final fields (static or instance). >> >> The fix updates the spec to prohibit any final field modification >> CSR: JDK-8281652 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > updated test to test instance final fields test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004t.java line 54: > 52: static final char iCharFld = 'a'; > 53: static final boolean iBooleanFld = false; > 54: static final String iStrFld = "instance field"; I don't think you meant for these fields to be static. ------------- PR: https://git.openjdk.org/jdk/pull/11279 From naoto at openjdk.org Thu Dec 1 21:23:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 1 Dec 2022 21:23:09 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <4PBH5ikKAEFzv_15GkmEi9BxdB60gRMrDJIBEIaEy0Q=.f335bafb-3fbf-4902-8121-cdf99ed92589@github.com> Message-ID: On Thu, 1 Dec 2022 19:37:28 GMT, Jonathan Gibbons wrote: >> src/java.base/share/classes/java/lang/Character.java line 172: >> >>> 170: * occur. For example, in a future release, synchronization may fail. >>> 171: * >>> 172: * @spec https://www.unicode.org/reports/tr27 Unicode 3.1.0 >> >> This should probably be removed, as the original link (explaining `U+n` notation) is broken. > > @naotoj The edits are driven by a script, using info about existing links in the same doc comment. If you don't think this reference is appropriate, it would be better to either remove the existing link (and I'll regenerate this patch) or else this patch goes through and you fix up both the existing link and the `@spec` tag afterwards. Either way is fine with me. I will fix it up if you choose the latter. ------------- PR: https://git.openjdk.org/jdk/pull/11073 From amenkov at openjdk.org Thu Dec 1 22:23:59 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Dec 2022 22:23:59 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v3] In-Reply-To: References: <7j_rN1OaZ5ASMkesFC9RBgOEILGqYbBW2tX3jFOoVlQ=.56eaf3b0-6ff7-4541-a1ed-b8b12dcc2bf4@github.com> Message-ID: On Thu, 1 Dec 2022 21:12:27 GMT, Chris Plummer wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> updated test to test instance final fields > > test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004t.java line 54: > >> 52: static final char iCharFld = 'a'; >> 53: static final boolean iBooleanFld = false; >> 54: static final String iStrFld = "instance field"; > > I don't think you meant for these fields to be static. Oh, sure. Incomplete change (or I did undo accidentally) ------------- PR: https://git.openjdk.org/jdk/pull/11279 From amenkov at openjdk.org Thu Dec 1 22:24:00 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Dec 2022 22:24:00 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v3] In-Reply-To: References: <7j_rN1OaZ5ASMkesFC9RBgOEILGqYbBW2tX3jFOoVlQ=.56eaf3b0-6ff7-4541-a1ed-b8b12dcc2bf4@github.com> Message-ID: On Thu, 1 Dec 2022 22:20:39 GMT, Alex Menkov wrote: >> test/hotspot/jtreg/vmTestbase/nsk/jdi/ObjectReference/setValue/setvalue004t.java line 54: >> >>> 52: static final char iCharFld = 'a'; >>> 53: static final boolean iBooleanFld = false; >>> 54: static final String iStrFld = "instance field"; >> >> I don't think you meant for these fields to be static. > > Oh, sure. Incomplete change (or I did undo accidentally) Fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11279 From amenkov at openjdk.org Thu Dec 1 23:04:37 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 Dec 2022 23:04:37 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v4] In-Reply-To: References: Message-ID: > com.sun.jdi.ObjectReference::setValue spec says that final static fields cannot be modified, but openjdk implementation throws IllegalArgumentException for any final fields (static or instance). > > The fix updates the spec to prohibit any final field modification > CSR: JDK-8281652 Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Fixed test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11279/files - new: https://git.openjdk.org/jdk/pull/11279/files/55a4616b..ab58e581 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11279&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11279&range=02-03 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/11279.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11279/head:pull/11279 PR: https://git.openjdk.org/jdk/pull/11279 From cjplummer at openjdk.org Fri Dec 2 00:30:09 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Dec 2022 00:30:09 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v4] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 23:04:37 GMT, Alex Menkov wrote: >> com.sun.jdi.ObjectReference::setValue spec says that final static fields cannot be modified, but openjdk implementation throws IllegalArgumentException for any final fields (static or instance). >> >> The fix updates the spec to prohibit any final field modification >> CSR: JDK-8281652 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11279 From sspitsyn at openjdk.org Fri Dec 2 01:46:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Dec 2022 01:46:49 GMT Subject: RFR: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification [v4] In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 23:04:37 GMT, Alex Menkov wrote: >> com.sun.jdi.ObjectReference::setValue spec says that final static fields cannot be modified, but openjdk implementation throws IllegalArgumentException for any final fields (static or instance). >> >> The fix updates the spec to prohibit any final field modification >> CSR: JDK-8281652 > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11279 From sspitsyn at openjdk.org Fri Dec 2 07:26:17 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 2 Dec 2022 07:26:17 GMT Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore wrote: > The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it. Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old. > > Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done). Coleen, This looks good. Wow, it is great you've found the root cause! It was not easy for sure. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11444 From dfuchs at openjdk.org Fri Dec 2 12:15:23 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 2 Dec 2022 12:15:23 GMT Subject: RFR: 8296546: Add @spec tags to API [v4] In-Reply-To: <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> References: <5uS_XWg0xRt6Rp20wY65rAmNRcDrp5XN_74k1aQ_4jk=.9f458354-9bca-473e-b60e-e520fa90724b@github.com> <0SjUCtMo9Z9Oiq-ITr1-CA8_RoibtPkzfAZPdaR4tSU=.950b338f-e68c-4825-8831-872fbbd04956@github.com> Message-ID: <4EIiX-uBShLoH1cl1MdngnvCc1HfVFXT_GJgFl5LoTE=.b07eefdf-8c2d-439e-a3c1-8ecfe323e2fd@github.com> On Thu, 1 Dec 2022 19:36:16 GMT, Jonathan Gibbons wrote: >> Please review a "somewhat automated" change to insert `@spec` tags into doc comments, as appropriate, to leverage the recent new javadoc feature to generate a new page listing the references to all external specifications listed in the `@spec` tags. >> >> "Somewhat automated" means that I wrote and used a temporary utility to scan doc comments looking for HTML links to selected sites, such as `ietf.org`, `unicode.org`, `w3.org`. These links may be in the main description of a doc comment, or in `@see` tags. For each link, the URL is examined, and "normalized", and inserted into the doc comment with a new `@spec` tag, giving the link and tile for the spec. >> >> "Normalized" means... >> * Use `https:` where possible (includes pretty much all cases) >> * Use a single consistent host name for all URLs coming from the same spec site (i.e. don't use different aliases for the same site) >> * Point to the root page of a multi-page spec >> * Use a consistent form of the spec, preferring HTML over plain text where both are available (this mostly applies to IETF specs) >> >> In addition, a "standard" title is determined for all specs, determined either from the content of the (main) spec page or from site index pages. >> >> The net effect is (or should be) that **all** the changes are to just **add** new `@spec` tags, based on the links found in each doc comment. There should be no other changes to the doc comments, or to the implementation of any classes and interfaces. >> >> That being said, the utility I wrote does have additional abilities, to update the links that it finds (e.g. changing to use `https:` etc,) but those features are _not_ being used here, but could be used in followup PRs if component teams so desired. I did notice while working on this overall feature that many of our links do point to "outdated" pages, some with eye-catching notices declaring that the spec has been superseded. Determining how, when and where to update such links is beyond the scope of this PR. >> >> Going forward, it is to be hoped that component teams will maintain the underlying links, and the URLs in `@spec` tags, such that if references to external specifications are updated, this will include updating the `@spec` tags. >> >> To see the effect of all these new `@spec` tags, see http://cr.openjdk.java.net/~jjg/8296546/api.00/ >> >> In particular, see the new [External Specifications](http://cr.openjdk.java.net/~jjg/8296546/api.00/external-specs.html) page, which you can also find via the new link near the top of the [Index](http://cr.openjdk.java.net/~jjg/8296546/api.00/index-files/index-1.html) pages. > > Jonathan Gibbons has updated the pull request 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: > > - Change ietf.org URLs to use rfc-editor.org > - Merge remote-tracking branch 'upstream/master' into 8296546.add-spec-tags > - Remove updates from unexported files > - Prefix RFC titles with `RFC NNNN:` > - JDK-8296547: Add @spec tags to API I have reviewed again the java.net, java.net.http, jdk.httpserver, java.naming, and javax.management changes - and I spotted a few places where the `@spec` duplicates an `@see` (noted below). I believe the duplicated `@see` should be removed now. src/java.base/share/classes/java/net/StandardSocketOptions.java line 62: > 60: * @spec https://www.rfc-editor.org/info/rfc919 RFC 919: Broadcasting Internet Datagrams > 61: * @see RFC 929: > 62: * Broadcasting Internet Datagrams This `@see` line should now be removed since it's referencing the exact same document. src/java.base/share/classes/java/net/StandardSocketOptions.java line 83: > 81: * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers > 82: * @see RFC 1122 > 83: * Requirements for Internet Hosts -- Communication Layers Same remark here: please remove the `@see` src/java.base/share/classes/java/net/StandardSocketOptions.java line 154: > 152: * @spec https://www.rfc-editor.org/info/rfc1323 RFC 1323: TCP Extensions for High Performance > 153: * @see RFC 1323: TCP > 154: * Extensions for High Performance Remove the `@see` src/java.base/share/classes/java/net/StandardSocketOptions.java line 186: > 184: * > 185: * @spec https://www.rfc-editor.org/info/rfc793 RFC 793: Transmission Control Protocol > 186: * @see RFC 793: Transmission Remove the @see src/java.base/share/classes/java/net/StandardSocketOptions.java line 377: > 375: * @spec https://www.rfc-editor.org/info/rfc1122 RFC 1122: Requirements for Internet Hosts - Communication Layers > 376: * @see RFC 1122: > 377: * Requirements for Internet Hosts -- Communication Layers Remove the @see src/java.management/share/classes/javax/management/remote/JMXServiceURL.java line 122: > 120: * @see 121: * href="http://www.ietf.org/rfc/rfc2609.txt">RFC 2609, > 122: * "Service Templates and Service: Schemes" The two `@see` should now be removed ------------- Changes requested by dfuchs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11073 From coleenp at openjdk.org Fri Dec 2 14:13:22 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Dec 2022 14:13:22 GMT Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore wrote: > The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it. Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old. > > Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done). Thanks Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/11444 From eosterlund at openjdk.org Fri Dec 2 15:05:47 2022 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Fri, 2 Dec 2022 15:05:47 GMT Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore wrote: > The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it. Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old. > > Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done). Looks good. ------------- Marked as reviewed by eosterlund (Reviewer). PR: https://git.openjdk.org/jdk/pull/11444 From ihse at openjdk.org Fri Dec 2 16:54:09 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 16:54:09 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code Message-ID: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) Doing so has a dual benefit: 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. ------------- Commit messages: - 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code Changes: https://git.openjdk.org/jdk/pull/11490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298046 Stats: 28 lines in 16 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/11490.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11490/head:pull/11490 PR: https://git.openjdk.org/jdk/pull/11490 From ihse at openjdk.org Fri Dec 2 16:54:11 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 16:54:11 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. **A note to reviewers:** This PR has been automatically generated by converting all trailing spaces in key-value lines (ignoring empty lines and comments) in the property files into unicode sequences. In a way, this is a no-op, converting one representation of the already existing space into another. But I think that most of these instances are likely to be bugs, and should thus be fixed. I think the easiest way to fix those instances is to use the Github "suggestion" review mechanism: If you see a value where the trailing space should be removed, press the blue `+` in the gutter as usual, and then in the comment box press the `+/-` icon (or press `ctrl-G`/`cmd-G`). Now you get a copy of the offending line, and can edit it to remove the trailing unicode sequence. I can then easily accept the suggestion into the PR. But you can also come with review feedback like "remove trailing spaces for all files in directory XXX" and I'll fix that for you. ------------- PR: https://git.openjdk.org/jdk/pull/11490 From coleenp at openjdk.org Fri Dec 2 17:02:13 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Dec 2022 17:02:13 GMT Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero [v2] In-Reply-To: References: Message-ID: > The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it. Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old. > > Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done). Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Kim's offline improvements. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11444/files - new: https://git.openjdk.org/jdk/pull/11444/files/2f8d5517..483da5e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11444&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11444&range=00-01 Stats: 9 lines in 3 files changed: 0 ins; 3 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/11444.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11444/head:pull/11444 PR: https://git.openjdk.org/jdk/pull/11444 From ihse at openjdk.org Fri Dec 2 17:12:37 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 17:12:37 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: On Mon, 24 Oct 2022 19:21:07 GMT, Magnus Ihse Bursie wrote: >> Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. >> >> With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). >> >> The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "Remove check for .properties from jcheck" > > This reverts commit c91fdaa19dc06351598bd1c0614e1af3bfa08ae2. > - Change trailing space and tab in values to unicode encoding This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs: [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit. [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Fri Dec 2 17:12:39 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 17:12:39 GMT Subject: Withdrawn: 8295729: Add jcheck whitespace checking for properties files In-Reply-To: References: Message-ID: On Thu, 20 Oct 2022 11:58:58 GMT, Magnus Ihse Bursie wrote: > Properties files is essentially source code. It should have the same whitespace checks as all other source code, so we don't get spurious trailing whitespace changes. > > With the new Skara jcheck, it is possible to increase the coverage of the whitespace checks (in the old mercurial version, this was more or less impossible). > > The only manual change is to `.jcheck/conf`. All other changes were made by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From ihse at openjdk.org Fri Dec 2 17:14:23 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 17:14:23 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files Message-ID: [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files. To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046). That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns. When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well. The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. ------------- Commit messages: - 8298047: Remove all non-significant trailing whitespace from properties files Changes: https://git.openjdk.org/jdk/pull/11491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298047 Stats: 693 lines in 264 files changed: 0 ins; 0 del; 693 mod Patch: https://git.openjdk.org/jdk/pull/11491.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11491/head:pull/11491 PR: https://git.openjdk.org/jdk/pull/11491 From angorya at openjdk.org Fri Dec 2 17:15:19 2022 From: angorya at openjdk.org (Andy Goryachev) Date: Fri, 2 Dec 2022 17:15:19 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: References: Message-ID: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com> On Fri, 2 Dec 2022 17:10:17 GMT, Magnus Ihse Bursie wrote: > and instead I have split up this work in five different bugs would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource? ------------- PR: https://git.openjdk.org/jdk/pull/10792 From kbarrett at openjdk.org Fri Dec 2 17:18:12 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 2 Dec 2022 17:18:12 GMT Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero [v2] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 17:02:13 GMT, Coleen Phillimore wrote: >> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it. Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old. >> >> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Kim's offline improvements. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.org/jdk/pull/11444 From coleenp at openjdk.org Fri Dec 2 17:57:19 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Dec 2022 17:57:19 GMT Subject: RFR: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero [v2] In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 17:02:13 GMT, Coleen Phillimore wrote: >> The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it. Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old. >> >> Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done). > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Kim's offline improvements. Thanks for reviewing Serguei, Erik. Kim, thank you for the cleaner implementation with swap and for reviewing. ------------- PR: https://git.openjdk.org/jdk/pull/11444 From coleenp at openjdk.org Fri Dec 2 19:12:19 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 Dec 2022 19:12:19 GMT Subject: Integrated: 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero In-Reply-To: References: Message-ID: On Thu, 1 Dec 2022 02:01:54 GMT, Coleen Phillimore wrote: > The code for RedefineVerifyMark in redefinition replaces the OopHandle mirror so that the verification has the right mirror, but it really should just copy it. Replacing an OopHandle in the ClassLoaderData didn't set the has_modified_oops flag so GC wasn't noticing that this handle is old. > > Tested with tier1-4 and tier6 in progress (linux-x64 and windows-x64 done). This pull request has now been integrated. Changeset: fb6fd032 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/fb6fd03233b0eb001e2995d20a079b6af31d2b9b Stats: 18 lines in 5 files changed: 6 ins; 4 del; 8 mod 8291830: jvmti/RedefineClasses/StressRedefine failed: assert(!is_null(v)) failed: narrow klass value can never be zero Reviewed-by: sspitsyn, eosterlund, kbarrett ------------- PR: https://git.openjdk.org/jdk/pull/11444 From mullan at openjdk.org Fri Dec 2 19:31:10 2022 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 2 Dec 2022 19:31:10 GMT Subject: RFR: 8297794: Deprecate JMX Management Applets for Removal [v4] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote: >> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal. >> >> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools. >> >> More details in bug, and CSR JDK-8297795 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary Suppression nit Marked as reviewed by mullan (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11430 From amenkov at openjdk.org Fri Dec 2 20:21:11 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 2 Dec 2022 20:21:11 GMT Subject: Integrated: 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification In-Reply-To: References: Message-ID: <0yg1bWst4HXqOJp_CCMh2EOxpSdTjn50cFH1jXgEV6g=.804e178c-b648-46fa-ab5f-6ac1e08f2169@github.com> On Mon, 21 Nov 2022 22:58:54 GMT, Alex Menkov wrote: > com.sun.jdi.ObjectReference::setValue spec says that final static fields cannot be modified, but openjdk implementation throws IllegalArgumentException for any final fields (static or instance). > > The fix updates the spec to prohibit any final field modification > CSR: JDK-8281652 This pull request has now been integrated. Changeset: 2821fa98 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/2821fa9883cc9687b53e3bb5655732a614cff8fc Stats: 37 lines in 4 files changed: 22 ins; 2 del; 13 mod 8280798: com.sun.jdi.ObjectReference::setValue spec should prohibit any final field modification Reviewed-by: alanb, cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11279 From rriggs at openjdk.org Fri Dec 2 21:02:17 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 2 Dec 2022 21:02:17 GMT Subject: RFR: 8297794: Deprecate JMX Management Applets for Removal [v4] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote: >> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal. >> >> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools. >> >> More details in bug, and CSR JDK-8297795 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary Suppression nit LGTM ------------- Marked as reviewed by rriggs (Reviewer). PR: https://git.openjdk.org/jdk/pull/11430 From cjplummer at openjdk.org Fri Dec 2 21:28:23 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Dec 2022 21:28:23 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Fri, 2 Dec 2022 16:42:57 GMT, Magnus Ihse Bursie wrote: > According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. > > We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). > > After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) > > Doing so has a dual benefit: > > 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended > > 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. > > Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. Changes requested by cjplummer (Reviewer). src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_de.properties line 27: > 25: > 26: ONE_DAY=\ 1 Tag > 27: ONE_HOUR=\ 1 Stunde\u0020 Suggestion: ONE_HOUR=\ 1 Stunde src/jdk.jconsole/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties line 174: > 172: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON=\u53D6\u6D88\u8BA2\u9605(&U) > 173: MBEANS_TAB_UNSUBSCRIBE_NOTIFICATIONS_BUTTON_TOOLTIP=\u505C\u6B62\u76D1\u542C\u901A\u77E5 > 174: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean:\u0020 Suggestion: MANAGE_HOTSPOT_MBEANS_IN_COLON_=\u7BA1\u7406\u4EE5\u4E0B\u4F4D\u7F6E\u7684 HotSpot MBean: src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties line 37: > 35: raw.description = Startet das Ziel mit einer vom Benutzer angegebenen Befehlszeile und wird daran angeh\u00E4ngt > 36: sun.home = Home-Verzeichnis des SDK oder der Laufzeitumgebung, die zum Starten der Anwendung verwendet wird > 37: sun.home.label = Home\u0020 Suggestion: sun.home.label = Home src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_de.properties line 51: > 49: generic_attaching.address = Adresse zum Anh\u00E4ngen f\u00FCr VM-Verbindungen > 50: generic_attaching.address.label = Adresse > 51: generic_attaching.timeout = Timeout beim Warten auf das Anh\u00E4ngen\u0020 Suggestion: generic_attaching.timeout = Timeout beim Warten auf das Anh\u00E4ngen src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties line 37: > 35: raw.description = \u30E6\u30FC\u30B6\u30FC\u304C\u6307\u5B9A\u3057\u305F\u30B3\u30DE\u30F3\u30C9\u30E9\u30A4\u30F3\u3092\u4F7F\u7528\u3057\u3066\u30BF\u30FC\u30B2\u30C3\u30C8\u3092\u8D77\u52D5\u3057\u3001\u63A5\u7D9A\u3057\u307E\u3059 > 36: sun.home = SDK\u306E\u30DB\u30FC\u30E0\u30FB\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA\u307E\u305F\u306F\u3001\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u306E\u8D77\u52D5\u306B\u4F7F\u7528\u3055\u308C\u308B\u5B9F\u884C\u74B0\u5883 > 37: sun.home.label = \u30DB\u30FC\u30E0\u0020 Suggestion: sun.home.label = \u30DB\u30FC\u30E0 src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties line 51: > 49: generic_attaching.address = VM\u306B\u63A5\u7D9A\u3059\u308B\u30A2\u30C9\u30EC\u30B9 > 50: generic_attaching.address.label = \u30A2\u30C9\u30EC\u30B9 > 51: generic_attaching.timeout = \u63A5\u7D9A\u3092\u5F85\u3064\u9593\u306E\u30BF\u30A4\u30E0\u30A2\u30A6\u30C8\u0020 Suggestion: generic_attaching.timeout = \u63A5\u7D9A\u3092\u5F85\u3064\u9593\u306E\u30BF\u30A4\u30E0\u30A2\u30A6\u30C8 src/jdk.jdi/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties line 37: > 35: raw.description = \u4F7F\u7528\u7528\u6237\u6307\u5B9A\u7684\u547D\u4EE4\u884C\u542F\u52A8\u76EE\u6807\u5E76\u9644\u52A0\u5230\u8BE5\u76EE\u6807 > 36: sun.home = \u7528\u4E8E\u542F\u52A8\u5E94\u7528\u7A0B\u5E8F\u7684 SDK \u6216\u8FD0\u884C\u65F6\u73AF\u5883\u7684\u4E3B\u76EE\u5F55 > 37: sun.home.label = \u4E3B\u76EE\u5F55\u0020 Suggestion: sun.home.label = \u4E3B\u76EE\u5F55 src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 27: > 25: > 26: agent.err.error = Error > 27: agent.err.exception = Exception thrown by the agent\u0020 Suggestion: agent.err.exception = Exception thrown by the agent src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent.properties line 38: > 36: > 37: agent.err.agentclass.notfound = Management agent class not found > 38: agent.err.agentclass.failed = Management agent class failed\u0020 Suggestion: agent.err.agentclass.failed = Management agent class failed src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_de.properties line 27: > 25: > 26: agent.err.error = Fehler > 27: agent.err.exception = Ausnahme von Agent ausgel\u00F6st\u0020 Suggestion: agent.err.exception = Ausnahme von Agent ausgel\u00F6st src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties line 27: > 25: > 26: agent.err.error = Error > 27: agent.err.exception = Excepci\u00F3n devuelta por el agente\u0020 Suggestion: agent.err.exception = Excepci\u00F3n devuelta por el agente src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_es.properties line 38: > 36: > 37: agent.err.agentclass.notfound = Clase de agente de gesti\u00F3n no encontrada > 38: agent.err.agentclass.failed = Fallo de clase de agente de gesti\u00F3n\u0020 Suggestion: agent.err.agentclass.failed = Fallo de clase de agente de gesti\u00F3n src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties line 27: > 25: > 26: agent.err.error = Erreur > 27: agent.err.exception = Exception envoy\u00E9e par l'agent\u0020 Suggestion: agent.err.exception = Exception envoy\u00E9e par l'agent src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_fr.properties line 38: > 36: > 37: agent.err.agentclass.notfound = Classe d'agents de gestion introuvable > 38: agent.err.agentclass.failed = Echec de la classe d'agents de gestion\u0020 Suggestion: agent.err.agentclass.failed = Echec de la classe d'agents de gestion src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties line 27: > 25: > 26: agent.err.error = Errore > 27: agent.err.exception = Eccezione dell'agente\u0020 Suggestion: agent.err.exception = Eccezione dell'agente src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_it.properties line 38: > 36: > 37: agent.err.agentclass.notfound = Classe agente gestione non trovata > 38: agent.err.agentclass.failed = Errore classe agente gestione\u0020 Suggestion: agent.err.agentclass.failed = Errore classe agente gestione src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties line 27: > 25: > 26: agent.err.error = \u30A8\u30E9\u30FC > 27: agent.err.exception = \u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u304C\u4F8B\u5916\u3092\u30B9\u30ED\u30FC\u3057\u307E\u3057\u305F\u0020 Suggestion: agent.err.exception = \u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u304C\u4F8B\u5916\u3092\u30B9\u30ED\u30FC\u3057\u307E\u3057\u305F src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ja.properties line 38: > 36: > 37: agent.err.agentclass.notfound = \u7BA1\u7406\u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u30FB\u30AF\u30E9\u30B9\u304C\u898B\u3064\u304B\u308A\u307E\u305B\u3093 > 38: agent.err.agentclass.failed = \u7BA1\u7406\u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u30FB\u30AF\u30E9\u30B9\u304C\u5931\u6557\u3057\u307E\u3057\u305F\u0020 Suggestion: agent.err.agentclass.failed = \u7BA1\u7406\u30A8\u30FC\u30B8\u30A7\u30F3\u30C8\u30FB\u30AF\u30E9\u30B9\u304C\u5931\u6557\u3057\u307E\u3057\u305F src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27: > 25: > 26: agent.err.error = \uC624\uB958 > 27: agent.err.exception = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4.\u0020 Suggestion: agent.err.exception = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4. src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 38: > 36: > 37: agent.err.agentclass.notfound = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uCC3E\uC744 \uC218 \uC5C6\uC2B5\uB2C8\uB2E4. > 38: agent.err.agentclass.failed = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4.\u0020 Suggestion: agent.err.agentclass.failed = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4. src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties line 27: > 25: > 26: agent.err.error = Erro > 27: agent.err.exception = Exce\u00E7\u00E3o gerada pelo agente\u0020 Suggestion: agent.err.exception = Exce\u00E7\u00E3o gerada pelo agente src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_pt_BR.properties line 38: > 36: > 37: agent.err.agentclass.notfound = Classe do agente de gerenciamento n\u00E3o encontrada > 38: agent.err.agentclass.failed = Falha na classe do agente de gerenciamento\u0020 Suggestion: agent.err.agentclass.failed = Falha na classe do agente de gerenciamento src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties line 27: > 25: > 26: agent.err.error = Fel > 27: agent.err.exception = Agenten orsakade ett undantag\u0020 Suggestion: agent.err.exception = Agenten orsakade ett undantag src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_sv.properties line 38: > 36: > 37: agent.err.agentclass.notfound = Administrationsagentklassen hittades inte > 38: agent.err.agentclass.failed = Administrationsagentklassen utf\u00F6rdes inte\u0020 Suggestion: agent.err.agentclass.failed = Administrationsagentklassen utf\u00F6rdes inte src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties line 38: > 36: > 37: agent.err.agentclass.notfound = \u627E\u4E0D\u5230\u7BA1\u7406\u4EE3\u7406\u7C7B > 38: agent.err.agentclass.failed = \u7BA1\u7406\u4EE3\u7406\u7C7B\u5931\u8D25\u0020 Suggestion: agent.err.agentclass.failed = \u7BA1\u7406\u4EE3\u7406\u7C7B\u5931\u8D25 src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_CN.properties line 67: > 65: agent.err.invalid.option = \u6307\u5B9A\u7684\u9009\u9879\u65E0\u6548 > 66: > 67: jmxremote.ConnectorBootstrap.starting = \u6B63\u5728\u542F\u52A8 JMX \u8FDE\u63A5\u5668\u670D\u52A1\u5668:\u0020 Suggestion: jmxremote.ConnectorBootstrap.starting = \u6B63\u5728\u542F\u52A8 JMX \u8FDE\u63A5\u5668\u670D\u52A1\u5668: src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties line 27: > 25: > 26: agent.err.error = \u932F\u8AA4 > 27: agent.err.exception = \u4EE3\u7406\u7A0B\u5F0F\u767C\u751F\u7570\u5E38\u0020 Suggestion: agent.err.exception = \u4EE3\u7406\u7A0B\u5F0F\u767C\u751F\u7570\u5E38 src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_zh_TW.properties line 38: > 36: > 37: agent.err.agentclass.notfound = \u627E\u4E0D\u5230\u7BA1\u7406\u4EE3\u7406\u7A0B\u5F0F\u985E\u5225 > 38: agent.err.agentclass.failed = \u7BA1\u7406\u4EE3\u7406\u7A0B\u5F0F\u985E\u5225\u5931\u6557\u0020 Suggestion: agent.err.agentclass.failed = \u7BA1\u7406\u4EE3\u7406\u7A0B\u5F0F\u985E\u5225\u5931\u6557 ------------- PR: https://git.openjdk.org/jdk/pull/11490 From cjplummer at openjdk.org Fri Dec 2 21:28:23 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 2 Dec 2022 21:28:23 GMT Subject: RFR: 8298046: Fix hidden but significant trailing whitespace in properties files for serviceability code In-Reply-To: References: <5zDsJcRoc-qspV7yCf2m27PCmIn3R7YsUhXZ-PBXZiI=.93d0d47d-2eb9-4011-814c-6ab40f2d0c9b@github.com> Message-ID: On Fri, 2 Dec 2022 21:03:27 GMT, Chris Plummer wrote: >> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant. >> >> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: "). >> >> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.) >> >> Doing so has a dual benefit: >> >> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended >> >> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces. >> >> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belong with the serviceability team. > > src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 27: > >> 25: >> 26: agent.err.error = \uC624\uB958 >> 27: agent.err.exception = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4.\u0020 > > Suggestion: > > agent.err.exception = \uC5D0\uC774\uC804\uD2B8\uC5D0 \uC608\uC678\uC0AC\uD56D\uC774 \uBC1C\uC0DD\uD588\uC2B5\uB2C8\uB2E4. The pre-exiting period at the end also seems like a bug, but I'm not sure. I don't see it in the other locales. > src/jdk.management.agent/share/classes/jdk/internal/agent/resources/agent_ko.properties line 38: > >> 36: >> 37: agent.err.agentclass.notfound = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uCC3E\uC744 \uC218 \uC5C6\uC2B5\uB2C8\uB2E4. >> 38: agent.err.agentclass.failed = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4.\u0020 > > Suggestion: > > agent.err.agentclass.failed = \uAD00\uB9AC \uC5D0\uC774\uC804\uD2B8 \uD074\uB798\uC2A4\uB97C \uC2E4\uD328\uD588\uC2B5\uB2C8\uB2E4. ...and another extra period at the end that I'm unsure of. ------------- PR: https://git.openjdk.org/jdk/pull/11490 From dcubed at openjdk.org Fri Dec 2 22:30:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 2 Dec 2022 22:30:07 GMT Subject: RFR: 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 22:55:40 GMT, Daniel D. Daugherty wrote: > Misc stress testing related fixes: > > [JDK-8295424](https://bugs.openjdk.org/browse/JDK-8295424) adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest > [JDK-8297367](https://bugs.openjdk.org/browse/JDK-8297367) disable TestRedirectLinks.java in slowdebug mode > [JDK-8297369](https://bugs.openjdk.org/browse/JDK-8297369) disable Fuzz.java in slowdebug mode My jdk-20+26 stress run #1 includes these patches (as have stress runs for several earlier jdk-20 promotions) and there's no signs of issues with these patches on either linux-x64 or macosx-aarch64 stress testing. ------------- PR: https://git.openjdk.org/jdk/pull/11278 From ihse at openjdk.org Fri Dec 2 23:06:08 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 2 Dec 2022 23:06:08 GMT Subject: RFR: 8295729: Add jcheck whitespace checking for properties files [v3] In-Reply-To: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com> References: <2Ed-oJoEq8e9g8Og4JD8_Pddjj3A_O5KGSrJpaDFrmk=.bcd0280d-33bb-4570-81e0-6700ff65e921@github.com> Message-ID: On Fri, 2 Dec 2022 17:12:55 GMT, Andy Goryachev wrote: >> This turned out to be much more complicated than anticipated. I am going to close this PR (and bug), and instead I have split up this work in five different bugs: >> >> [JDK-8298047](https://bugs.openjdk.org/browse/JDK-8298047) is about removing all non-significant whitespace from all properties files, basically corresponding to how this PR looked after the second commit. >> >> [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046) is about fixing the significant whitespace, by turning it to unicode sequences or removing it, if it turns out there should not have been a space there. This work is split into four parts to be able to have one bug per component team. > >> and instead I have split up this work in five different bugs > > would you consider also adding a unit test to check whether the localized resources also contain leading/trailing whitespace, and possibly special characters (like {, }, , etc.) that are present in the main resource? @andy-goryachev-oracle No. Any such test is up to the component owners to write, if they deem it fitting. ------------- PR: https://git.openjdk.org/jdk/pull/10792 From lmesnik at openjdk.org Sat Dec 3 04:08:56 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 3 Dec 2022 04:08:56 GMT Subject: RFR: 8298054: ProblemList jdk/jfr/api/consumer/recordingstream/TestStop.java In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 03:58:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/api/consumer/recordingstream/TestStop.java. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11494 From dcubed at openjdk.org Sat Dec 3 04:16:09 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 3 Dec 2022 04:16:09 GMT Subject: RFR: 8298054: ProblemList jdk/jfr/api/consumer/recordingstream/TestStop.java In-Reply-To: References: Message-ID: On Sat, 3 Dec 2022 04:06:37 GMT, Leonid Mesnik wrote: >> A trivial fix to ProblemList jdk/jfr/api/consumer/recordingstream/TestStop.java. > > Marked as reviewed by lmesnik (Reviewer). @lmesnik - Thanks for the fast review! Especially for a Friday PM... ------------- PR: https://git.openjdk.org/jdk/pull/11494 From dcubed at openjdk.org Sat Dec 3 04:16:10 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 3 Dec 2022 04:16:10 GMT Subject: Integrated: 8298054: ProblemList jdk/jfr/api/consumer/recordingstream/TestStop.java In-Reply-To: References: Message-ID: <7KZRxzikDptio5tP4zIBaNJx9buENX-6YsQ3AQH_D64=.504321a2-f6f9-43e3-bedd-2a9721c6b083@github.com> On Sat, 3 Dec 2022 03:58:34 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList jdk/jfr/api/consumer/recordingstream/TestStop.java. This pull request has now been integrated. Changeset: 99e2ef49 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/99e2ef49a87fe88212fc2090ec5b5f4b3493025a Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8298054: ProblemList jdk/jfr/api/consumer/recordingstream/TestStop.java Reviewed-by: lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/11494 From serb at openjdk.org Mon Dec 5 06:10:04 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 5 Dec 2022 06:10:04 GMT Subject: RFR: 8298047: Remove all non-significant trailing whitespace from properties files In-Reply-To: References: Message-ID: On Fri, 2 Dec 2022 17:06:23 GMT, Magnus Ihse Bursie wrote: > [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729) was created in an attempt to remove all trailing whitespace from properties files, and enable a jcheck verification that they did not come back, similar to other source code. It turned out that this was not so simple, however, since trailing whitespace in values is actually significant in properties files. > > To address this, I have opened four bugs on different component teams to either remove the trailing significant whitespace (if it is there erroneously), or convert it to the unicode sequence `\u0020`: [JDK-8298042](https://bugs.openjdk.org/browse/JDK-8298042), [JDK-8298044](https://bugs.openjdk.org/browse/JDK-8298044), [JDK-8298045](https://bugs.openjdk.org/browse/JDK-8298045) and [JDK-8298046](https://bugs.openjdk.org/browse/JDK-8298046). > > That leaves all the other trailing spaces, in blank lines and in the end of comments. These serve no purpose and should just be removed, and is what this issue concerns. > > When this and the four "significant whitespace" bugs are all finally integrated, we can finally turn on the verification in jcheck for properties files as well. > > The changes in this PR is based on [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), in #10792. I have restored all the "delete trailing whitespace" changes, except for those with significance. These changes were in turned created by running `find . -type f -iname "*.properties" | xargs gsed -i -e 's/[ \t]*$//'`. The client changes look fine. ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11491 From alanb at openjdk.org Mon Dec 5 07:51:23 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 Dec 2022 07:51:23 GMT Subject: RFR: 8297794: Deprecate JMX Management Applets for Removal [v4] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote: >> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal. >> >> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools. >> >> More details in bug, and CSR JDK-8297795 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary Suppression nit Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11430 From aturbanov at openjdk.org Mon Dec 5 08:35:56 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 5 Dec 2022 08:35:56 GMT Subject: RFR: 8298090: Use String.join() instead of manual loop in DescriptorSupport.toString Message-ID: There is opportunity to use String.join in DescriptorSupport.toString implementation. Result code is much shorter and clearer. ------------- Commit messages: - [PATCH] Use String.join() instead of manual loop in DescriptorSupport Changes: https://git.openjdk.org/jdk/pull/10960/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10960&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298090 Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10960.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10960/head:pull/10960 PR: https://git.openjdk.org/jdk/pull/10960 From stsypanov at openjdk.org Mon Dec 5 08:35:57 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Mon, 5 Dec 2022 08:35:57 GMT Subject: RFR: 8298090: Use String.join() instead of manual loop in DescriptorSupport.toString In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 21:30:51 GMT, Andrey Turbanov wrote: > There is opportunity to use String.join in DescriptorSupport.toString implementation. Result code is much shorter and clearer. Marked as reviewed by stsypanov (Author). ------------- PR: https://git.openjdk.org/jdk/pull/10960 From kevinw at openjdk.org Mon Dec 5 09:20:31 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 5 Dec 2022 09:20:31 GMT Subject: RFR: 8297794: Deprecate JMX Management Applets for Removal [v4] In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 20:37:38 GMT, Kevin Walls wrote: >> Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal. >> >> This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools. >> >> More details in bug, and CSR JDK-8297795 > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary Suppression nit Thanks for all the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/11430 From kevinw at openjdk.org Mon Dec 5 09:30:55 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 5 Dec 2022 09:30:55 GMT Subject: Integrated: 8297794: Deprecate JMX Management Applets for Removal In-Reply-To: References: Message-ID: On Wed, 30 Nov 2022 12:08:22 GMT, Kevin Walls wrote: > Deprecate the Java Management Extension (JMX) Management Applet (m-let) feature for removal. > > This deprecation will have no impact on users of other JMX features, the JDK's built-in instrumentation, or any of the observability tools. > > More details in bug, and CSR JDK-8297795 This pull request has now been integrated. Changeset: 17666fbc Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/17666fbcae795a01ee462651c7694b5e4af30e32 Stats: 60 lines in 19 files changed: 41 ins; 2 del; 17 mod 8297794: Deprecate JMX Management Applets for Removal Reviewed-by: dfuchs, mullan, rriggs, alanb ------------- PR: https://git.openjdk.org/jdk/pull/11430 From mcimadamore at openjdk.org Mon Dec 5 10:31:52 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Dec 2022 10:31:52 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: References: Message-ID: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Fix Preview annotation for JEP 434 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10872/files - new: https://git.openjdk.org/jdk/pull/10872/files/8b5dc0f0..33b834ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=38 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10872&range=37-38 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10872.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10872/head:pull/10872 PR: https://git.openjdk.org/jdk/pull/10872 From sundar at openjdk.org Mon Dec 5 11:03:15 2022 From: sundar at openjdk.org (Athijegannathan Sundararajan) Date: Mon, 5 Dec 2022 11:03:15 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> References: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> Message-ID: On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Preview annotation for JEP 434 LGTM ------------- Marked as reviewed by sundar (Reviewer). PR: https://git.openjdk.org/jdk/pull/10872 From rkennke at amazon.de Mon Dec 5 11:03:18 2022 From: rkennke at amazon.de (Kennke, Roman) Date: Mon, 5 Dec 2022 12:03:18 +0100 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: References: Message-ID: <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de> Hi Thomas, I very much like the idea and also your proposals how to do it. Insights in JDK's native memory usage is sorely lacking and would be very useful! I don't have all that much to add about the details beyond what you already covered, though :-) Cheers, Roman > Are there any opinions about whether or not to extend NMT across the JDK? > > This blocks https://bugs.openjdk.org/browse/JDK-8296360 > , and I had a PR prepared > as https://github.com/openjdk/jdk/pull/10988 > . Originally I was hoping to > get this into JDK 20, but I don't think that is realistic anymore. I am > fine with postponing my work in favor of a baseline discussion, but so > far there is very little discussion about this topic. > > How should I proceed? > > Thanks, Thomas > > > > On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe > wrote: > > Hi Alan, > > (replaced hotspot-runtime-dev with hotspot-dev, since its more of a > general topic) > > thank?you for your time! > > I am very happy to talk this through. I think native memory > observability in the JDK (and customer code!) is sorely lacking. > Witness the countless "where did my native memory go" blog articles. > At SAP we have been struggling with this topic for a long time and > have come up with a mixture of solutions. The aforementioned tracker > was one, which extended our version of NMT across the JDK. Our > SapMachine MallocTracer, which allows us to trace uninstrumented > customer code, another. We even experimented with exchanging the > allocator (using jemalloc) to gain insights. But that is a whole > different topic with deep logistical implications, I don't want to > touch it here. Exchanging the allocator does not help to observe > virtual memory or the brk segment, of course. > > And to make the picture complete, another insight we currently lack > is the implicit allocator overhead, which can be very significant > and is hidden by the libc. We also have observability for that in > the SapMachine, and I miss it in OpenJDK. > > As you noticed, my original intent was just to instrument Zlib and > possibly improve tracking for DBBs. Although, thinking beyond that, > another attractive instrumentation target would be mapped NIO > buffers at least. > > So I think native memory observability is important. Arguably we > could even extend observability to cover other OS resources, e.g. > file handles. If we shift code around, to java/Panama: data that > move the java heap does not need to be tracked, but other memory > will always come from one of the basic system APIs, regardless of > who allocates it and where in the stack allocation happens. Be it > native JDK code, Panama, or even customer JNI code. > > If we agree on the importance of native memory observability, then I > believe NMT is the right tool for it. It is a good?tool.?The > machinery is already there. It covers both C-heap and virtual memory > APIs, as well as thread stacks, and could easily be extended to > cover sbrk if needed. And I assume that whatever shape OpenJDK takes > on in the future, there always will be a libjvm.so at its core, so > we will always have it. But even if not, NMT could be separated from > libjvm.so quite easily, since it has no deep ties with the JVM. > > About coupling JVM with outside code: We don't have to directly link > against libjvm.so. We can keep things loose if the intent is to be > runnable without a JVM, or be JVM-version-agnostic. That could take > the form of a function-pointer interface like JVMTI. Or outside code > could dynamically dlsym the JVM allocation hooks. In any case > gracefully falling back to system allocation routines when necessary. > > And I agree, polluting the NMT tag space with outside meaning is > ugly. I only did it because I planned to go no further than > instrumenting Zlib and possibly DBBs. But if we take this further, > my preferred solution would be a reserved tag range or -ranges for > outside use, whose?inner meaning would be opaque to the JVM. Kind of > like SIGRTMIN+SIGRTMAX. Then, outside code could register tags and > their meta information with the JVM, or we find a different way to > convey the tag meaning to NMT (config files, or callbacks). That > could even be opened up for customer use. > > This also touches on another question, that of NMT tag space. NMT > tags are very useful since they allow cheap tracking without > capturing call stacks. However, tags are underused and show growing > pains since they are too one-dimensional and restrictive. We had > competing interests in the past about tag granularity. It is?all > over the place. We have coarse-grained tags like "mtThread", and > very fine-grained ones like "mtObjectMonitor". There are several > ways we could improve, e.g., by making them combinable like UL does, > or allowing for a hierarchy of them - either a hard-wired limited > one like "domain"+"tag", or an unlimited tree-like one. Technically > interesting since whatever the new encoding is, they still must fit > into a malloc header. I opened > https://bugs.openjdk.org/browse/JDK-8281819 > to track ideas like these. > > Instrumenting Panama allocations, including the ability to tag > allocations, would be a very good idea. For instance, if we ever > remove the native Zlib layer and convert it to java using Panama, we > can do the same with Panama I do now natively - use the Zlib zalloc > interface to hook in JVM memory allocation functions. The result > could be completely identical, and the end user looking at the NMT > output need never know that anything changed. > > And that goes for all instrumentation - if today we add it to JNI > code, and that code gets removed tomorrow, we can add it to Panama > code too. Unless data structures move to the heap, in which case > there is no need to track them. > > You mentioned that NMT was more of an in-house support tool. Our > experience is different. Even though it was positioned as a tool for > JVM developers, and we never cared for the backward compatibility or > consistency, it gets used a *lot* by our customers. We have to > explain its output frequently. Also, many blog articles exist > documenting its use. So, maybe it would be okay to elevate it to a > user-facing tool since it seems to occupy that role anyway. We may > also open up consumption of NMT results via java APIs, or expose its > results via MXBeans. > > If this is to be a JEP, okay, but I'm afraid it would stall things a > bit. I am interested in getting a simpler and quicker solution for > older support releases at?least, possibly based on my PR. I know > that would be unconventional though. > > Thank you, > > Thomas > > > On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman > wrote: > > On 04/11/2022 16:54, Thomas St?fe wrote: > > Hi all, > > > > I am currently working on > https://bugs.openjdk.org/browse/JDK-8296360 > ; > > I was preparing the final PR [1], but then Alan did ask me to > discuss > > this on core-libs first. > > > > Backstory: > > > > NMT tracks hotspot native allocations but does not cover the JDK > > libraries (small exception: Unsafe.AllocateMemory). However, the > > native memory footprint of JDK libraries can be significant. > We have > > no in-VM tracker for these and need tools like valgrind or our > > SapMachine MallocTracer [2] to observe them. > > Thanks for starting a discussion on this as this is a topic that > requires agreement from several areas. If this is the start of > something > bigger, where you want to have all allocation sites in the > libraries > using NMT, then I think it needs a write-up, maybe a JEP. > > For starters, I think it needs some agreement on using NMT for > memory > allocated outside of libjvm. You mentioned Unsafe as an > exception but > that is implemented in the VM so you get tracking for free, > albeit I > think all allocations are in the "mtOther" category. > > A general concern is that it creates more coupling between the > VM code > and the libraries code. As you probably know, we've removed most > of the > dependences on JVM_* functions from non-core areas over many > years. So I > think that needs consideration as I assume we don't want > memory/allocation.hpp declaring a dozen catagories for > allocations done > in say java.desktop module for example. Maybe your proposal will be > strictly limited to java.base but even then, do we really want > the VM > even knowing about categories that are specific to zip > compression or > decompression? > > There are probably longer term trends that should be part of the > discussion too. One general trend is that "run time" is becoming > more > and more a hybrid of code in libvm and the Java libraries. Lambdas, > module system, virtual threads implementations are a few > examples in the > last few release. This comes with many "Java on Java" challenges, > including serviceability where users of the platform will expect > tools > to just work and won't care where the code is. NMT is probably > more for > support teams and not something that most developers will ever > use but I > think is part of the challenge of having serviceability > solutions "just > work". > > In addition to having more of the Java runtime written in Java, > there > will likely be less JNI code in the future. It's very possible > that the > JNI code (including the JNI methods in libzip) will be replaced > with > code that uses Panama memory and linker APIs once they are become > permanent. The effect of that would to have a lot of the memory > allocations be tracked in the mtOther category again. Maybe > integration > with memory tracking should be looked at in conjunction with > these APIs > and this migration. I could imagine the proposed "Arena" API > (MemorySession in Java 19) having some integration with NMT and > it might > be interesting to look into that. > > So yes, this topic does need broader discussion and it might be > a bit > premature to start with a PR for libzip without talking about > the bigger > picture first. > > -Alan > > > Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879 From thomas.stuefe at gmail.com Mon Dec 5 12:43:47 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 5 Dec 2022 13:43:47 +0100 Subject: Extend Native Memory Tracking over the JDK ? (was: Proposal: track zlib native memory usage with NMT) In-Reply-To: <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de> References: <5ceac3c4-4cc7-2ce5-822c-0ad498b1c476@amazon.de> Message-ID: Thank you for the positive encouragement, Roman :-) Cheers, Thomas On Mon, Dec 5, 2022 at 12:03 PM Kennke, Roman wrote: > Hi Thomas, > > I very much like the idea and also your proposals how to do it. Insights > in JDK's native memory usage is sorely lacking and would be very useful! > I don't have all that much to add about the details beyond what you > already covered, though :-) > > Cheers, > Roman > > > > Are there any opinions about whether or not to extend NMT across the JDK? > > > > This blocks https://bugs.openjdk.org/browse/JDK-8296360 > > , and I had a PR prepared > > as https://github.com/openjdk/jdk/pull/10988 > > . Originally I was hoping to > > get this into JDK 20, but I don't think that is realistic anymore. I am > > fine with postponing my work in favor of a baseline discussion, but so > > far there is very little discussion about this topic. > > > > How should I proceed? > > > > Thanks, Thomas > > > > > > > > On Wed, Nov 9, 2022 at 8:12 AM Thomas St?fe > > wrote: > > > > Hi Alan, > > > > (replaced hotspot-runtime-dev with hotspot-dev, since its more of a > > general topic) > > > > thank you for your time! > > > > I am very happy to talk this through. I think native memory > > observability in the JDK (and customer code!) is sorely lacking. > > Witness the countless "where did my native memory go" blog articles. > > At SAP we have been struggling with this topic for a long time and > > have come up with a mixture of solutions. The aforementioned tracker > > was one, which extended our version of NMT across the JDK. Our > > SapMachine MallocTracer, which allows us to trace uninstrumented > > customer code, another. We even experimented with exchanging the > > allocator (using jemalloc) to gain insights. But that is a whole > > different topic with deep logistical implications, I don't want to > > touch it here. Exchanging the allocator does not help to observe > > virtual memory or the brk segment, of course. > > > > And to make the picture complete, another insight we currently lack > > is the implicit allocator overhead, which can be very significant > > and is hidden by the libc. We also have observability for that in > > the SapMachine, and I miss it in OpenJDK. > > > > As you noticed, my original intent was just to instrument Zlib and > > possibly improve tracking for DBBs. Although, thinking beyond that, > > another attractive instrumentation target would be mapped NIO > > buffers at least. > > > > So I think native memory observability is important. Arguably we > > could even extend observability to cover other OS resources, e.g. > > file handles. If we shift code around, to java/Panama: data that > > move the java heap does not need to be tracked, but other memory > > will always come from one of the basic system APIs, regardless of > > who allocates it and where in the stack allocation happens. Be it > > native JDK code, Panama, or even customer JNI code. > > > > If we agree on the importance of native memory observability, then I > > believe NMT is the right tool for it. It is a good tool. The > > machinery is already there. It covers both C-heap and virtual memory > > APIs, as well as thread stacks, and could easily be extended to > > cover sbrk if needed. And I assume that whatever shape OpenJDK takes > > on in the future, there always will be a libjvm.so at its core, so > > we will always have it. But even if not, NMT could be separated from > > libjvm.so quite easily, since it has no deep ties with the JVM. > > > > About coupling JVM with outside code: We don't have to directly link > > against libjvm.so. We can keep things loose if the intent is to be > > runnable without a JVM, or be JVM-version-agnostic. That could take > > the form of a function-pointer interface like JVMTI. Or outside code > > could dynamically dlsym the JVM allocation hooks. In any case > > gracefully falling back to system allocation routines when necessary. > > > > And I agree, polluting the NMT tag space with outside meaning is > > ugly. I only did it because I planned to go no further than > > instrumenting Zlib and possibly DBBs. But if we take this further, > > my preferred solution would be a reserved tag range or -ranges for > > outside use, whose inner meaning would be opaque to the JVM. Kind of > > like SIGRTMIN+SIGRTMAX. Then, outside code could register tags and > > their meta information with the JVM, or we find a different way to > > convey the tag meaning to NMT (config files, or callbacks). That > > could even be opened up for customer use. > > > > This also touches on another question, that of NMT tag space. NMT > > tags are very useful since they allow cheap tracking without > > capturing call stacks. However, tags are underused and show growing > > pains since they are too one-dimensional and restrictive. We had > > competing interests in the past about tag granularity. It is all > > over the place. We have coarse-grained tags like "mtThread", and > > very fine-grained ones like "mtObjectMonitor". There are several > > ways we could improve, e.g., by making them combinable like UL does, > > or allowing for a hierarchy of them - either a hard-wired limited > > one like "domain"+"tag", or an unlimited tree-like one. Technically > > interesting since whatever the new encoding is, they still must fit > > into a malloc header. I opened > > https://bugs.openjdk.org/browse/JDK-8281819 > > to track ideas like > these. > > > > Instrumenting Panama allocations, including the ability to tag > > allocations, would be a very good idea. For instance, if we ever > > remove the native Zlib layer and convert it to java using Panama, we > > can do the same with Panama I do now natively - use the Zlib zalloc > > interface to hook in JVM memory allocation functions. The result > > could be completely identical, and the end user looking at the NMT > > output need never know that anything changed. > > > > And that goes for all instrumentation - if today we add it to JNI > > code, and that code gets removed tomorrow, we can add it to Panama > > code too. Unless data structures move to the heap, in which case > > there is no need to track them. > > > > You mentioned that NMT was more of an in-house support tool. Our > > experience is different. Even though it was positioned as a tool for > > JVM developers, and we never cared for the backward compatibility or > > consistency, it gets used a *lot* by our customers. We have to > > explain its output frequently. Also, many blog articles exist > > documenting its use. So, maybe it would be okay to elevate it to a > > user-facing tool since it seems to occupy that role anyway. We may > > also open up consumption of NMT results via java APIs, or expose its > > results via MXBeans. > > > > If this is to be a JEP, okay, but I'm afraid it would stall things a > > bit. I am interested in getting a simpler and quicker solution for > > older support releases at least, possibly based on my PR. I know > > that would be unconventional though. > > > > Thank you, > > > > Thomas > > > > > > On Sun, Nov 6, 2022 at 9:31 AM Alan Bateman > > wrote: > > > > On 04/11/2022 16:54, Thomas St?fe wrote: > > > Hi all, > > > > > > I am currently working on > > https://bugs.openjdk.org/browse/JDK-8296360 > > ; > > > I was preparing the final PR [1], but then Alan did ask me to > > discuss > > > this on core-libs first. > > > > > > Backstory: > > > > > > NMT tracks hotspot native allocations but does not cover the > JDK > > > libraries (small exception: Unsafe.AllocateMemory). However, > the > > > native memory footprint of JDK libraries can be significant. > > We have > > > no in-VM tracker for these and need tools like valgrind or our > > > SapMachine MallocTracer [2] to observe them. > > > > Thanks for starting a discussion on this as this is a topic that > > requires agreement from several areas. If this is the start of > > something > > bigger, where you want to have all allocation sites in the > > libraries > > using NMT, then I think it needs a write-up, maybe a JEP. > > > > For starters, I think it needs some agreement on using NMT for > > memory > > allocated outside of libjvm. You mentioned Unsafe as an > > exception but > > that is implemented in the VM so you get tracking for free, > > albeit I > > think all allocations are in the "mtOther" category. > > > > A general concern is that it creates more coupling between the > > VM code > > and the libraries code. As you probably know, we've removed most > > of the > > dependences on JVM_* functions from non-core areas over many > > years. So I > > think that needs consideration as I assume we don't want > > memory/allocation.hpp declaring a dozen catagories for > > allocations done > > in say java.desktop module for example. Maybe your proposal will > be > > strictly limited to java.base but even then, do we really want > > the VM > > even knowing about categories that are specific to zip > > compression or > > decompression? > > > > There are probably longer term trends that should be part of the > > discussion too. One general trend is that "run time" is becoming > > more > > and more a hybrid of code in libvm and the Java libraries. > Lambdas, > > module system, virtual threads implementations are a few > > examples in the > > last few release. This comes with many "Java on Java" challenges, > > including serviceability where users of the platform will expect > > tools > > to just work and won't care where the code is. NMT is probably > > more for > > support teams and not something that most developers will ever > > use but I > > think is part of the challenge of having serviceability > > solutions "just > > work". > > > > In addition to having more of the Java runtime written in Java, > > there > > will likely be less JNI code in the future. It's very possible > > that the > > JNI code (including the JNI methods in libzip) will be replaced > > with > > code that uses Panama memory and linker APIs once they are become > > permanent. The effect of that would to have a lot of the memory > > allocations be tracked in the mtOther category again. Maybe > > integration > > with memory tracking should be looked at in conjunction with > > these APIs > > and this migration. I could imagine the proposed "Arena" API > > (MemorySession in Java 19) having some integration with NMT and > > it might > > be interesting to look into that. > > > > So yes, this topic does need broader discussion and it might be > > a bit > > premature to start with a PR for libzip without talking about > > the bigger > > picture first. > > > > -Alan > > > > > > > > > > Amazon Development Center Germany GmbH > Krausenstr. 38 > 10117 Berlin > Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss > Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B > Sitz: Berlin > Ust-ID: DE 289 237 879 > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Mon Dec 5 13:16:44 2022 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 5 Dec 2022 13:16:44 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari 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: - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - Added update interface instead of Remove-Add pair. - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/0bcd27d0..cd0ca72c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=00-01 Stats: 62256 lines in 1240 files changed: 26769 ins; 22309 del; 13178 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From mcimadamore at openjdk.org Mon Dec 5 13:49:46 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Dec 2022 13:49:46 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> References: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> Message-ID: On Mon, 5 Dec 2022 10:31:52 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.org/jeps/434 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Fix Preview annotation for JEP 434 Note: there are 4 tests failing in x86: * MemoryLayoutPrincipalTotalityTest * MemoryLayoutTypeRetentionTest * TestLargeSegmentCopy * TestLinker These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes ------------- PR: https://git.openjdk.org/jdk/pull/10872 From mcimadamore at openjdk.org Mon Dec 5 13:55:22 2022 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Dec 2022 13:55:22 GMT Subject: Integrated: 8295044: Implementation of Foreign Function and Memory API (Second Preview) In-Reply-To: References: Message-ID: <7Ara-NxY9rdQzABZPYR9T-N7b1XLY99_6J-dG3cr2NY=.4151c690-0138-4ffd-a763-ff2456754189@github.com> On Wed, 26 Oct 2022 13:11:50 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-434 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.org/jeps/434 This pull request has now been integrated. Changeset: 73baadce Author: Maurizio Cimadamore URL: https://git.openjdk.org/jdk/commit/73baadceb60029f6340c1327118aeb59971c2434 Stats: 13808 lines in 255 files changed: 5780 ins; 4448 del; 3580 mod 8295044: Implementation of Foreign Function and Memory API (Second Preview) Co-authored-by: Jorn Vernee Co-authored-by: Per Minborg Co-authored-by: Maurizio Cimadamore Reviewed-by: jvernee, pminborg, psandoz, alanb, sundar ------------- PR: https://git.openjdk.org/jdk/pull/10872 From bhuang at openjdk.org Mon Dec 5 20:42:05 2022 From: bhuang at openjdk.org (Bill Huang) Date: Mon, 5 Dec 2022 20:42:05 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v7] In-Reply-To: References: Message-ID: > The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. > > Tests include: > java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java > java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java > javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Reduced host input timeout to 20 minutes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10825/files - new: https://git.openjdk.org/jdk/pull/10825/files/3ae1f797..c5648165 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/10825.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825 PR: https://git.openjdk.org/jdk/pull/10825 From dholmes at openjdk.org Tue Dec 6 04:57:11 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Dec 2022 04:57:11 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v2] In-Reply-To: References: Message-ID: <2R1SvRfKINep3LbJNfi35pZbDaKSbJY-SHCtvEOfz08=.39007aa6-aff1-4d30-9e8e-882f172d1c98@github.com> On Mon, 5 Dec 2022 13:16:44 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari 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: > > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap > - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - 8292741: Convert JvmtiTagMapTable to ResourceHashtable > - Added update interface instead of Remove-Add pair. > - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable This PR seems to be broken now - full of unexpected changes. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Tue Dec 6 10:06:53 2022 From: duke at openjdk.org (Afshin Zafari) Date: Tue, 6 Dec 2022 10:06:53 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v3] In-Reply-To: References: Message-ID: <4Lu6vFSdEefYOpSkb9-SVZtuIImXfl53AngEB3aGnCI=.b9ecadcb-b32c-4288-a2e8-72d3e888c0fc@github.com> > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/cd0ca72c..32392428 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=01-02 Stats: 56 lines in 3 files changed: 2 ins; 11 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From cjplummer at openjdk.org Tue Dec 6 22:07:17 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Dec 2022 22:07:17 GMT Subject: RFR: 8298221: Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64 Message-ID: <-XnzwbOX9jXBpxv-lpXvaln7cXEvTfMgBa7pJloGtYM=.9fa90881-d553-42e7-986a-f02da686dedf@github.com> Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64. It's causing the hosts to take 2 days or more to finish up the test task. ------------- Commit messages: - Remove extra blank line. - Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64 Changes: https://git.openjdk.org/jdk/pull/11549/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11549&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298221 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11549.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11549/head:pull/11549 PR: https://git.openjdk.org/jdk/pull/11549 From dcubed at openjdk.org Tue Dec 6 22:19:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 6 Dec 2022 22:19:07 GMT Subject: RFR: 8298221: Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64 In-Reply-To: <-XnzwbOX9jXBpxv-lpXvaln7cXEvTfMgBa7pJloGtYM=.9fa90881-d553-42e7-986a-f02da686dedf@github.com> References: <-XnzwbOX9jXBpxv-lpXvaln7cXEvTfMgBa7pJloGtYM=.9fa90881-d553-42e7-986a-f02da686dedf@github.com> Message-ID: On Tue, 6 Dec 2022 21:54:10 GMT, Chris Plummer wrote: > Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64. It's causing the hosts to take 2 days or more to finish up the test task. Thumbs up. This is a trivial fix. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/11549 From cjplummer at openjdk.org Tue Dec 6 22:46:10 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Dec 2022 22:46:10 GMT Subject: RFR: 8298221: Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64 In-Reply-To: <-XnzwbOX9jXBpxv-lpXvaln7cXEvTfMgBa7pJloGtYM=.9fa90881-d553-42e7-986a-f02da686dedf@github.com> References: <-XnzwbOX9jXBpxv-lpXvaln7cXEvTfMgBa7pJloGtYM=.9fa90881-d553-42e7-986a-f02da686dedf@github.com> Message-ID: On Tue, 6 Dec 2022 21:54:10 GMT, Chris Plummer wrote: > Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64. It's causing the hosts to take 2 days or more to finish up the test task. Thanks Dan! ------------- PR: https://git.openjdk.org/jdk/pull/11549 From cjplummer at openjdk.org Tue Dec 6 22:49:51 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 Dec 2022 22:49:51 GMT Subject: Integrated: 8298221: Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64 In-Reply-To: <-XnzwbOX9jXBpxv-lpXvaln7cXEvTfMgBa7pJloGtYM=.9fa90881-d553-42e7-986a-f02da686dedf@github.com> References: <-XnzwbOX9jXBpxv-lpXvaln7cXEvTfMgBa7pJloGtYM=.9fa90881-d553-42e7-986a-f02da686dedf@github.com> Message-ID: On Tue, 6 Dec 2022 21:54:10 GMT, Chris Plummer wrote: > Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64. It's causing the hosts to take 2 days or more to finish up the test task. This pull request has now been integrated. Changeset: 62baff50 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/62baff503ef5562e02e1900525acffa5d4ca8534 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8298221: Problem list gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java on macosx-aarch64 Reviewed-by: dcubed ------------- PR: https://git.openjdk.org/jdk/pull/11549 From sspitsyn at openjdk.org Tue Dec 6 22:56:03 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 6 Dec 2022 22:56:03 GMT Subject: RFR: 8298090: Use String.join() instead of manual loop in DescriptorSupport.toString In-Reply-To: References: Message-ID: <4p3vt1Tmh24-fsbYva_3ywvOWV8FjTQ7b2kMsaBnBsE=.0d58fa8b-fd28-417f-8383-1f33cedcb66c@github.com> On Wed, 2 Nov 2022 21:30:51 GMT, Andrey Turbanov wrote: > There is opportunity to use String.join in DescriptorSupport.toString implementation. Result code is much shorter and clearer. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/10960 From sspitsyn at openjdk.org Tue Dec 6 23:04:06 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 6 Dec 2022 23:04:06 GMT Subject: RFR: 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest In-Reply-To: References: <6tiK8h3MQgoNTHVnRtLGFJmH2HycabKnQvpE3PL413Q=.298830ac-77b9-4916-a568-10aba857b348@github.com> Message-ID: On Tue, 29 Nov 2022 22:30:10 GMT, Daniel D. Daugherty wrote: >> Sorry, I was not clear. >> The Fuzz.java has this order: >> >> +import jdk.test.lib.Platform; >> +import jtreg.SkippedException; >> >> I thought, you ordered imports by names. Then it is better to keep this order unified. >> It is really minor though. > > Sorry I'm still confused. As far as I can see, I've added the imports the > same way in both Fuzz.java and TestRedirectLinks.java. > > And the imports are in sort order: > 'jdk' comes before 'jtreg' and 'Platform' comes before 'SkippedException'. Sorry, copied fragment from a wrong file. This file has imports out of order: test/langtools/jdk/javadoc/doclet/testLinkOption/TestRedirectLinks.java + * @build jtreg.SkippedException + * @build jdk.test.lib.Platform ------------- PR: https://git.openjdk.org/jdk/pull/11278 From dcubed at openjdk.org Tue Dec 6 23:04:07 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 6 Dec 2022 23:04:07 GMT Subject: Integrated: 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest In-Reply-To: References: Message-ID: On Mon, 21 Nov 2022 22:55:40 GMT, Daniel D. Daugherty wrote: > Misc stress testing related fixes: > > [JDK-8295424](https://bugs.openjdk.org/browse/JDK-8295424) adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest > [JDK-8297367](https://bugs.openjdk.org/browse/JDK-8297367) disable TestRedirectLinks.java in slowdebug mode > [JDK-8297369](https://bugs.openjdk.org/browse/JDK-8297369) disable Fuzz.java in slowdebug mode This pull request has now been integrated. Changeset: 6e547052 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/6e5470525d5236901c219146f363d4860e6b8008 Stats: 17 lines in 3 files changed: 16 ins; 0 del; 1 mod 8295424: adjust timeout for another JLI GetObjectSizeIntrinsicsTest.java subtest 8297367: disable TestRedirectLinks.java in slowdebug mode 8297369: disable Fuzz.java in slowdebug mode Reviewed-by: sspitsyn, jjg, cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/11278 From lmesnik at openjdk.org Tue Dec 6 23:13:02 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 6 Dec 2022 23:13:02 GMT Subject: RFR: 8298090: Use String.join() instead of manual loop in DescriptorSupport.toString In-Reply-To: References: Message-ID: <7gu5Bf1TOMlVgORjG9Lpvtmz2kMiq2gfYyEkH-sTUqc=.aae97729-076c-486a-9cb9-b05b06bb8fd0@github.com> On Wed, 2 Nov 2022 21:30:51 GMT, Andrey Turbanov wrote: > There is opportunity to use String.join in DescriptorSupport.toString implementation. Result code is much shorter and clearer. Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/10960 From ayang at openjdk.org Wed Dec 7 11:24:58 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 7 Dec 2022 11:24:58 GMT Subject: RFR: 8298264: Merge OffsetTableContigSpace into TenuredSpace Message-ID: Small change of merging two classes to reduce inheritance chain length. Test: hotspot_gc ------------- Commit messages: - s1-merge-tenured-space Changes: https://git.openjdk.org/jdk/pull/11556/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298264 Stats: 84 lines in 6 files changed: 7 ins; 56 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/11556.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11556/head:pull/11556 PR: https://git.openjdk.org/jdk/pull/11556 From bhuang at openjdk.org Wed Dec 7 17:56:25 2022 From: bhuang at openjdk.org (Bill Huang) Date: Wed, 7 Dec 2022 17:56:25 GMT Subject: RFR: JDK-8295756 Improve NonLocalRegistry Manual Test Process [v8] In-Reply-To: References: Message-ID: > The current non local registry tests require a manual process that runs rmiregitrty on a different machine and changes the -Dregistry.host property in the source before running the tests on the local machine. This task is created to improve this manual process and provide a clearer instruction to the test engineer about the test requirement. > > Tests include: > java/rmi/registry/nonLocalRegistry/NonLocalSkeletonTest.java > java/rmi/registry/nonLocalRegistry/NonLocalRegistryTest.java > javax/management/remote/nonLocalAccess/NonLocalJMXRemoteTest.java Bill Huang has updated the pull request incrementally with one additional commit since the last revision: Reduced host input timeout to 5 minutes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/10825/files - new: https://git.openjdk.org/jdk/pull/10825/files/c5648165..761cf908 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10825&range=06-07 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/10825.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10825/head:pull/10825 PR: https://git.openjdk.org/jdk/pull/10825 From kevinw at openjdk.org Wed Dec 7 22:01:12 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 7 Dec 2022 22:01:12 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage Message-ID: Test should not check that Eden has decreased in used size if the GCCause is "No GC". These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. ------------- Commit messages: - 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage Changes: https://git.openjdk.org/jdk/pull/11572/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11572&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298173 Stats: 33 lines in 1 file changed: 8 ins; 4 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/11572.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11572/head:pull/11572 PR: https://git.openjdk.org/jdk/pull/11572 From dcubed at openjdk.org Wed Dec 7 22:41:05 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Dec 2022 22:41:05 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls wrote: > Test should not check that Eden has decreased in used size if the GCCause is "No GC". > > These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. > > Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. The variable renaming and code clean ups were a bit distracting. However, I'm okay with the changes to skip verification when "No GC" is the GCCause. What kind of testing was done? The bug is targeted at '21'. If you plan to fix this in '20' before the cutoff, then please change the target to '20'. If you don't plan to fix this in '20', then you'll need to ProblemList the test in '20' because this failure is rather noisy as we already have 6 sightings in the JDK20 CI. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/11572 From cjplummer at openjdk.org Wed Dec 7 22:51:08 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 Dec 2022 22:51:08 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage In-Reply-To: References: Message-ID: <3uITQINIchOdjOY5Sqv4UGemtNrwwalB68sM99QlXLI=.fbfe4859-eb97-4795-9ccd-ac2278d91550@github.com> On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls wrote: > Test should not check that Eden has decreased in used size if the GCCause is "No GC". > > These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. > > Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11572 From dcubed at openjdk.org Wed Dec 7 23:13:42 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Wed, 7 Dec 2022 23:13:42 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls wrote: > Test should not check that Eden has decreased in used size if the GCCause is "No GC". > > These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. > > Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. This bug appears to be a regression caused by the fix for: [JDK-8297247](https://bugs.openjdk.org/browse/JDK-8297247) Add GarbageCollectorMXBean for Remark and Cleanup pause time in G1 so I've bumped the priority from P4 -> P2 since it appears to be a regression. I've also retargeted the bug from '21' -> '20'. ------------- PR: https://git.openjdk.org/jdk/pull/11572 From sspitsyn at openjdk.org Thu Dec 8 01:02:41 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 8 Dec 2022 01:02:41 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage In-Reply-To: References: Message-ID: <7JDFx6faGfCZDia0c4xeYJQH6gpfPUXVx9u-sbBJrEA=.f387203f-bc3b-4a7b-8a2c-c993a37d8e44@github.com> On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls wrote: > Test should not check that Eden has decreased in used size if the GCCause is "No GC". > > These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. > > Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. Looks good. Posted one nit. Thanks, Serguei test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java line 94: > 92: numberOfGCMBeans = names.size(); > 93: for (ObjectName n : names) { > 94: if(mbs.isInstanceOf(n, "javax.management.NotificationEmitter")) { Nit: missed space in "if(". ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11572 From duke at openjdk.org Thu Dec 8 11:14:05 2022 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 8 Dec 2022 11:14:05 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v4] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - Merge branch 'jvmti_tagmap' of http://github.com/afshin-zafari/jdk into jvmti_tagmap - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - Added update interface instead of Remove-Add pair. - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable - Clean commit. ------------- Changes: https://git.openjdk.org/jdk/pull/11288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=03 Stats: 282 lines in 4 files changed: 42 ins; 104 del; 136 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From kevinw at openjdk.org Thu Dec 8 11:52:14 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Dec 2022 11:52:14 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage [v2] In-Reply-To: References: Message-ID: > Test should not check that Eden has decreased in used size if the GCCause is "No GC". > > These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. > > Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: nit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11572/files - new: https://git.openjdk.org/jdk/pull/11572/files/71607383..9ef9c94d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11572&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11572&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11572.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11572/head:pull/11572 PR: https://git.openjdk.org/jdk/pull/11572 From kevinw at openjdk.org Thu Dec 8 11:52:14 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Dec 2022 11:52:14 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage [v2] In-Reply-To: <7JDFx6faGfCZDia0c4xeYJQH6gpfPUXVx9u-sbBJrEA=.f387203f-bc3b-4a7b-8a2c-c993a37d8e44@github.com> References: <7JDFx6faGfCZDia0c4xeYJQH6gpfPUXVx9u-sbBJrEA=.f387203f-bc3b-4a7b-8a2c-c993a37d8e44@github.com> Message-ID: On Thu, 8 Dec 2022 00:58:36 GMT, Serguei Spitsyn wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> nit > > test/jdk/com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java line 94: > >> 92: numberOfGCMBeans = names.size(); >> 93: for (ObjectName n : names) { >> 94: if(mbs.isInstanceOf(n, "javax.management.NotificationEmitter")) { > > Nit: missed space in "if(". got it 8-) ------------- PR: https://git.openjdk.org/jdk/pull/11572 From kevinw at openjdk.org Thu Dec 8 11:58:44 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Dec 2022 11:58:44 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 23:10:11 GMT, Daniel D. Daugherty wrote: >> Test should not check that Eden has decreased in used size if the GCCause is "No GC". >> >> These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. >> >> Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. > > This bug appears to be a regression caused by the fix for: > > [JDK-8297247](https://bugs.openjdk.org/browse/JDK-8297247) Add GarbageCollectorMXBean for Remark and Cleanup pause time in G1 > > so I've bumped the priority from P4 -> P2 since it appears to be a regression. I've > also retargeted the bug from '21' -> '20'. Thanks for the reviews, thanks @dcubed-ojdk for the pointer to the other change - this did not start failing by coincidence, there are new notifications happening. It is hard to reproduce the failure, and they are mostly on linux aarch64, but I've seen one locally on linux x64. The failures show an event where Eden size does not change: the test says that eden before size <= after size is a failure. I cannot reproduce the problem with this change in mach5 or locally, in many runs. Yes, the cleanup changes are distracting, but "count"? That should be more meaningful. 8-) ------------- PR: https://git.openjdk.org/jdk/pull/11572 From kevinw at openjdk.org Thu Dec 8 12:13:06 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Dec 2022 12:13:06 GMT Subject: Integrated: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 21:50:11 GMT, Kevin Walls wrote: > Test should not check that Eden has decreased in used size if the GCCause is "No GC". > > These happen with the message "end of concurrent GC pause" which is logged by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). This GCMemoryManager only interacts with the old gen memory pool, so it is expected that eden usage does not change. > > Updated a few variable names to make it more obvious what count and number are recording, and some formatting. The key part of the change is at line 137 onwards. This pull request has now been integrated. Changeset: fbe7b007 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/fbe7b007383b034589e93d398706bebeb24461ee Stats: 33 lines in 1 file changed: 8 ins; 4 del; 21 mod 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage Reviewed-by: dcubed, cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11572 From stsypanov at openjdk.org Thu Dec 8 12:45:29 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Thu, 8 Dec 2022 12:45:29 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base Message-ID: Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like void iterate(T[] items) { if (items.length == 0) { return; } for (T item : items) { //... } } Here if (items.length == 0) { return; } is redundant and can be removed as length check is performed by for-each loop. ------------- Commit messages: - 8298380: Clean up redundant array length checks in JDK code base Changes: https://git.openjdk.org/jdk/pull/11589/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11589&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298380 Stats: 51 lines in 8 files changed: 0 ins; 14 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/11589.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11589/head:pull/11589 PR: https://git.openjdk.org/jdk/pull/11589 From dcubed at openjdk.org Thu Dec 8 15:40:02 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Dec 2022 15:40:02 GMT Subject: RFR: 8298173: GarbageCollectionNotificationContentTest test failed: no decrease in Eden usage In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 11:55:20 GMT, Kevin Walls wrote: >> This bug appears to be a regression caused by the fix for: >> >> [JDK-8297247](https://bugs.openjdk.org/browse/JDK-8297247) Add GarbageCollectorMXBean for Remark and Cleanup pause time in G1 >> >> so I've bumped the priority from P4 -> P2 since it appears to be a regression. I've >> also retargeted the bug from '21' -> '20'. > > Thanks for the reviews, thanks @dcubed-ojdk for the pointer to the other change - this did not start failing by coincidence, there are new notifications happening. > > It is hard to reproduce the failure, and they are mostly on linux aarch64, but I've seen one locally on linux x64. > The failures show an event where Eden size does not change: the test says that eden before size <= after size is a failure. > > I cannot reproduce the problem with this change in mach5 or locally, in many runs. > > Yes, the cleanup changes are distracting, but "count"? That should be more meaningful. 8-) > > Integrating now to be in jdk20. @kevinjwalls - Thanks for getting the fix integrated into JDK20. The CI will be less noisy today! ------------- PR: https://git.openjdk.org/jdk/pull/11572 From cjplummer at openjdk.org Thu Dec 8 15:56:33 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 8 Dec 2022 15:56:33 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx In-Reply-To: References: Message-ID: <4ytmjdF9Bv1S_BczN_1Kv5kgCMa1UexSnpoIzlOI2bw=.4af7177b-120a-43e9-beec-4f8b2985d174@github.com> On Thu, 8 Dec 2022 03:06:31 GMT, Chris Plummer wrote: > This fixes two separate CRs: > > [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes > [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx > > For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. > > For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. Ping. Trying to trigger email to serviceability-dev. ------------- PR: https://git.openjdk.org/jdk/pull/11576 From duke at openjdk.org Thu Dec 8 16:17:05 2022 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 8 Dec 2022 16:17:05 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v5] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - Added update interface instead of Remove-Add pair. - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: https://git.openjdk.org/jdk/pull/11288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=04 Stats: 288 lines in 4 files changed: 45 ins; 121 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Thu Dec 8 16:35:02 2022 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 8 Dec 2022 16:35:02 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v6] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari 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: - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - Merge branch 'master' into jvmti_tagmap - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - 8292741: Convert JvmtiTagMapTable to ResourceHashtable - Added update interface instead of Remove-Add pair. - JBS-8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/6ef59dff..4c00ac8f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=04-05 Stats: 81589 lines in 1191 files changed: 40421 ins; 34464 del; 6704 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From coleenp at openjdk.org Thu Dec 8 16:40:55 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 8 Dec 2022 16:40:55 GMT Subject: Withdrawn: 8296955: Kitchensink.java failed with "double free or corruption (!prev): " In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 14:22:15 GMT, Coleen Phillimore wrote: > Thanks to Kim for the diagnosis of this problem. G1 cleans up nmethods in parallel threads during a safepoint and may post or queue unload events to be posted. The event posting creates jmethodIDs. The jmethodID code assumes that it's thread safe in a safepoint, which it is not. > I removed this optimization, which isn't much of an optimization and is unsafe in the modern code. > Tested with tier1-5, where 5 found the original bug. > I'll also rebase this to JDK 20 repository and close this, but here's a preview. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/11594 From duke at openjdk.org Thu Dec 8 16:56:40 2022 From: duke at openjdk.org (Afshin Zafari) Date: Thu, 8 Dec 2022 16:56:40 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: > test of tier1-5 passed. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 8292741: Convert JvmtiTagMapTable to ResourceHashtable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11288/files - new: https://git.openjdk.org/jdk/pull/11288/files/4c00ac8f..d55d7612 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11288&range=05-06 Stats: 19 lines in 1 file changed: 0 ins; 19 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11288.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11288/head:pull/11288 PR: https://git.openjdk.org/jdk/pull/11288 From ayang at openjdk.org Thu Dec 8 17:48:53 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Thu, 8 Dec 2022 17:48:53 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 03:06:31 GMT, Chris Plummer wrote: > This fixes two separate CRs: > > [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes > [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx > > For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. > > For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. Marked as reviewed by ayang (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11576 From aturbanov at openjdk.org Thu Dec 8 19:41:08 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 8 Dec 2022 19:41:08 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 03:06:31 GMT, Chris Plummer wrote: > This fixes two separate CRs: > > [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes > [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx > > For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. > > For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java line 53: > 51: SATestUtils.skipIfCannotAttach(); // throws SkippedException if attach not expected to work. > 52: > 53: LingeredApp theApp = new LingeredApp(); Nit Suggestion: LingeredApp theApp = new LingeredApp(); ------------- PR: https://git.openjdk.org/jdk/pull/11576 From cjplummer at openjdk.org Thu Dec 8 19:55:24 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 8 Dec 2022 19:55:24 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx [v2] In-Reply-To: References: Message-ID: > This fixes two separate CRs: > > [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes > [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx > > For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. > > For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Delete extra space. Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11576/files - new: https://git.openjdk.org/jdk/pull/11576/files/e1543d5a..b403e129 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11576&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11576&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11576.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11576/head:pull/11576 PR: https://git.openjdk.org/jdk/pull/11576 From rriggs at openjdk.org Thu Dec 8 20:18:16 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 8 Dec 2022 20:18:16 GMT Subject: [jdk20] RFR: 8298402: ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 18:06:58 GMT, Daniel D. Daugherty wrote: > A trivial fix for several ProblemListings: > [JDK-8298402](https://bugs.openjdk.org/browse/JDK-8298402) ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64 > [JDK-8298414](https://bugs.openjdk.org/browse/JDK-8298414) ProblemList gc/TestFullGCCount.java on linux-x64 > [JDK-8298417](https://bugs.openjdk.org/browse/JDK-8298417) ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms > [JDK-8298419](https://bugs.openjdk.org/browse/JDK-8298419) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64 Marked as reviewed by rriggs (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/1 From dcubed at openjdk.org Thu Dec 8 20:20:26 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Dec 2022 20:20:26 GMT Subject: [jdk20] RFR: 8298402: ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 20:16:00 GMT, Roger Riggs wrote: >> A trivial fix for several ProblemListings: >> [JDK-8298402](https://bugs.openjdk.org/browse/JDK-8298402) ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64 >> [JDK-8298414](https://bugs.openjdk.org/browse/JDK-8298414) ProblemList gc/TestFullGCCount.java on linux-x64 >> [JDK-8298417](https://bugs.openjdk.org/browse/JDK-8298417) ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms >> [JDK-8298419](https://bugs.openjdk.org/browse/JDK-8298419) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64 > > Marked as reviewed by rriggs (Reviewer). @RogerRiggs - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk20/pull/1 From dcubed at openjdk.org Thu Dec 8 20:24:18 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 8 Dec 2022 20:24:18 GMT Subject: [jdk20] Integrated: 8298402: ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64 In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 18:06:58 GMT, Daniel D. Daugherty wrote: > A trivial fix for several ProblemListings: > [JDK-8298402](https://bugs.openjdk.org/browse/JDK-8298402) ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64 > [JDK-8298414](https://bugs.openjdk.org/browse/JDK-8298414) ProblemList gc/TestFullGCCount.java on linux-x64 > [JDK-8298417](https://bugs.openjdk.org/browse/JDK-8298417) ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms > [JDK-8298419](https://bugs.openjdk.org/browse/JDK-8298419) ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64 This pull request has now been integrated. Changeset: 553ba65d Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk20/commit/553ba65dc44b601e048c53cd1c48d668de9dcf1e Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod 8298402: ProblemList javax/swing/JFileChooser/4847375/bug4847375.java on windows-x64 8298414: ProblemList gc/TestFullGCCount.java on linux-x64 8298417: ProblemList vmTestbase/nsk/stress/strace/strace004.java on 2 platforms 8298419: ProblemList vmTestbase/nsk/monitoring/ThreadMXBean/ThreadInfo/Multi/Multi005/TestDescription.java on windows-x64 Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk20/pull/1 From cjplummer at openjdk.org Thu Dec 8 23:31:09 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 8 Dec 2022 23:31:09 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization Message-ID: 3 things to cleanup in this area: (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. ------------- Commit messages: - Cleanup JVMTI GenEnv() usage. Changes: https://git.openjdk.org/jdk/pull/11602/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11602&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287812 Stats: 47 lines in 2 files changed: 11 ins; 31 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/11602.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11602/head:pull/11602 PR: https://git.openjdk.org/jdk/pull/11602 From amenkov at openjdk.org Thu Dec 8 23:53:55 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 8 Dec 2022 23:53:55 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 22:40:57 GMT, Chris Plummer wrote: > 3 things to cleanup in this area: > > (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: > > `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` > > The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. > > (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. > > (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 180: > 178: */ > 179: int i; > 180: for (i = 0; i < nof_compatible_versions; ++i) { nof_compatible_versions and compatible_versions_list variables are not used now and can be deleted ------------- PR: https://git.openjdk.org/jdk/pull/11602 From dholmes at openjdk.org Fri Dec 9 00:14:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 Dec 2022 00:14:49 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. These all seem fine to me. You can count this as the review for hotspot and serviceability. :) ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11589 From amenkov at openjdk.org Fri Dec 9 00:14:50 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Dec 2022 00:14:50 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11589 From dholmes at openjdk.org Fri Dec 9 00:29:48 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 Dec 2022 00:29:48 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 22:40:57 GMT, Chris Plummer wrote: > (2) JVMTI_VERSION_1 suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. Does it? I guess it is a somewhat moot point inside the same VM but don't you only need to ask for the version of the environment that supports the API you are going to use? ------------- PR: https://git.openjdk.org/jdk/pull/11602 From serb at openjdk.org Fri Dec 9 00:46:18 2022 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 9 Dec 2022 00:46:18 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. The "client" changes in src/java.desktop looks fine ------------- Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.org/jdk/pull/11589 From cjplummer at openjdk.org Fri Dec 9 01:16:58 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 01:16:58 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: > 3 things to cleanup in this area: > > (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: > > `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` > > The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. > > (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. > > (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Get rid of some structs and statics that are no longer needed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11602/files - new: https://git.openjdk.org/jdk/pull/11602/files/badf087f..e84cba48 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11602&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11602&range=00-01 Stats: 30 lines in 1 file changed: 0 ins; 30 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11602.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11602/head:pull/11602 PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Fri Dec 9 01:16:59 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 01:16:59 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 23:51:33 GMT, Alex Menkov wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Get rid of some structs and statics that are no longer needed. > > src/jdk.jdwp.agent/share/native/libjdwp/debugInit.c line 180: > >> 178: */ >> 179: int i; >> 180: for (i = 0; i < nof_compatible_versions; ++i) { > > nof_compatible_versions and compatible_versions_list variables are not used now and can be deleted Yes, I meant to delete all that. Fixed now. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Fri Dec 9 01:27:42 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 01:27:42 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization In-Reply-To: References: Message-ID: <-ohwBc8Nh5KyTlmKBBj4LH2NJ7jzE1TQvQKtSWbxlCE=.8e84906f-c928-457e-a967-12b7c89d02ea@github.com> On Fri, 9 Dec 2022 00:27:47 GMT, David Holmes wrote: > > (2) JVMTI_VERSION_1 suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. > > Does it? I guess it is a somewhat moot point inside the same VM but don't you only need to ask for the version of the environment that supports the API you are going to use? Yes, but why would we need to allow the debug agent to bind to a version of JVMTI other than the one it was built with? I think there might be some historical context here that I'm missing. I know in the past there has been some conditional code in the debug agent based on what features JVMTI supports. For example, SuspendThreadList. I removed the code that was needed if SuspendThreadList was not supported, and we now assume that it is supported. Maybe the debug agent built by Oracle (probably actually Sun at the time) was also used by other JVMs, and was expected to work with older versions of JVMTI. I doubt that is the case anymore. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From dholmes at openjdk.org Fri Dec 9 01:45:55 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 Dec 2022 01:45:55 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization In-Reply-To: <-ohwBc8Nh5KyTlmKBBj4LH2NJ7jzE1TQvQKtSWbxlCE=.8e84906f-c928-457e-a967-12b7c89d02ea@github.com> References: <-ohwBc8Nh5KyTlmKBBj4LH2NJ7jzE1TQvQKtSWbxlCE=.8e84906f-c928-457e-a967-12b7c89d02ea@github.com> Message-ID: On Fri, 9 Dec 2022 01:23:31 GMT, Chris Plummer wrote: > Maybe the debug agent built by Oracle (probably actually Sun at the time) was also used by other JVMs, and was expected to work with older versions of JVMTI. I doubt that is the case anymore. I don't know what the deployment model for the debug agent is, but you have now made it so that it can't work with older versions. Does this affect the ability to run an earlier version of the debugger VM compared to the debugee VM? ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Fri Dec 9 01:57:57 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 01:57:57 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization In-Reply-To: References: <-ohwBc8Nh5KyTlmKBBj4LH2NJ7jzE1TQvQKtSWbxlCE=.8e84906f-c928-457e-a967-12b7c89d02ea@github.com> Message-ID: On Fri, 9 Dec 2022 01:43:46 GMT, David Holmes wrote: > I don't know what the deployment model for the debug agent is, but you have now made it so that it can't work with older versions. Does this affect the ability to run an earlier version of the debugger VM compared to the debugee VM? I don't believe so. The debugger can query the debug agent's capabilities (and most do so to support older versions). The debug agent imposes no type of versioning or capabilities on the debugger: https://docs.oracle.com/en/java/javase/17/docs/specs/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_CapabilitiesNew ------------- PR: https://git.openjdk.org/jdk/pull/11602 From sspitsyn at openjdk.org Fri Dec 9 02:52:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Dec 2022 02:52:54 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:55:24 GMT, Chris Plummer wrote: >> This fixes two separate CRs: >> >> [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes >> [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx >> >> For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. >> >> For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > > Delete extra space. > > Co-authored-by: Andrey Turbanov Looks good. Thanks, Serguei test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java line 35: > 33: * @modules java.base/jdk.internal.misc > 34: * java.management > 35: * @run main/timeout=240 gc.metaspace.CompressedClassSpaceSizeInJmapHeap Nit: unneeded space after 240. ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11576 From sspitsyn at openjdk.org Fri Dec 9 03:02:55 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 9 Dec 2022 03:02:55 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer wrote: >> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of some structs and statics that are no longer needed. Should we consider filing a CSR as potentially there is a minimal compatibility risk? ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Fri Dec 9 03:12:36 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 03:12:36 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx [v3] In-Reply-To: References: Message-ID: > This fixes two separate CRs: > > [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes > [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx > > For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. > > For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java Remove extra space. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11576/files - new: https://git.openjdk.org/jdk/pull/11576/files/b403e129..8002eae0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11576&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11576&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11576.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11576/head:pull/11576 PR: https://git.openjdk.org/jdk/pull/11576 From cjplummer at openjdk.org Fri Dec 9 03:12:39 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 03:12:39 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx [v2] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 19:55:24 GMT, Chris Plummer wrote: >> This fixes two separate CRs: >> >> [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes >> [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx >> >> For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. >> >> For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > > Delete extra space. > > Co-authored-by: Andrey Turbanov test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java line 35: > 33: * @modules java.base/jdk.internal.misc > 34: * java.management > 35: * @run main/timeout=240 gc.metaspace.CompressedClassSpaceSizeInJmapHeap Suggestion: * @run main/timeout=240 gc.metaspace.CompressedClassSpaceSizeInJmapHeap ------------- PR: https://git.openjdk.org/jdk/pull/11576 From vtewari at openjdk.org Fri Dec 9 06:24:54 2022 From: vtewari at openjdk.org (Vyom Tewari) Date: Fri, 9 Dec 2022 06:24:54 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. java.base changes looks ok to me. ------------- Marked as reviewed by vtewari (Committer). PR: https://git.openjdk.org/jdk/pull/11589 From alanb at openjdk.org Fri Dec 9 08:09:55 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Dec 2022 08:09:55 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer wrote: >> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of some structs and statics that are no longer needed. In the distant past it may have been useful to copy libjdwp/libsocket_dt from a JDK build into a build (JRE or embedded) that didn't have the debugger agent. Those days are long gone. Also since JDK 9, the JDK build generates a hash for each packaged module that is later use by jlink to detect any accidental mix 'n matching of modules from one JDK build with another. This will catch accidental attempts to use the jdk.jdwp.agent module one from build with java.base from another build. The error message "is your J2SE a 1.5 or newer version?" has come several times during JDK 19 and JDK 20 development, mostly in GHA with new tests attempting to run with --enable-preview and use JVMTI (jshell tests for example). JDK-8287812 was created to remove the confusing part of the error message but has since expanded to broader cleanup, which is okay. If virtual threads become permanent in JDK 21, and if the are outstanding ports of VM continuations, then it means that JVMTI may have to be disabled completely for those ports (in which case the error in PR will be seem widely, unless the tests are changed to skip) or JVMTI will have to be changed to work the alternative implementation of virtual threads (in which case this error should not be seen). ------------- PR: https://git.openjdk.org/jdk/pull/11602 From alanb at openjdk.org Fri Dec 9 08:14:58 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Dec 2022 08:14:58 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: <8-MZ9L33VF_B_cdF2EYlsdfDyQm_APY6CS2ow-MDSOo=.73bcbdc5-8de7-46f6-a312-61e80c0c3d31@github.com> On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer wrote: >> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of some structs and statics that are no longer needed. Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11602 From duke at openjdk.org Fri Dec 9 10:34:00 2022 From: duke at openjdk.org (Afshin Zafari) Date: Fri, 9 Dec 2022 10:34:00 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v2] In-Reply-To: <2R1SvRfKINep3LbJNfi35pZbDaKSbJY-SHCtvEOfz08=.39007aa6-aff1-4d30-9e8e-882f172d1c98@github.com> References: <2R1SvRfKINep3LbJNfi35pZbDaKSbJY-SHCtvEOfz08=.39007aa6-aff1-4d30-9e8e-882f172d1c98@github.com> Message-ID: On Tue, 6 Dec 2022 04:54:50 GMT, David Holmes wrote: > This PR seems to be broken now - full of unexpected changes. The PR changed files are correct now. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From stsypanov at openjdk.org Fri Dec 9 12:54:50 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Fri, 9 Dec 2022 12:54:50 GMT Subject: Integrated: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. This pull request has now been integrated. Changeset: e3c6cf8e Author: Sergey Tsypanov Committer: Julian Waters URL: https://git.openjdk.org/jdk/commit/e3c6cf8eaf931d9eb46b429a5ba8d3bbded3728a Stats: 51 lines in 8 files changed: 0 ins; 14 del; 37 mod 8298380: Clean up redundant array length checks in JDK code base Reviewed-by: dholmes, amenkov, serb, vtewari ------------- PR: https://git.openjdk.org/jdk/pull/11589 From rriggs at openjdk.org Fri Dec 9 14:38:03 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Dec 2022 14:38:03 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. @stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer. ------------- PR: https://git.openjdk.org/jdk/pull/11589 From stsypanov at openjdk.org Fri Dec 9 14:48:02 2022 From: stsypanov at openjdk.org (Sergey Tsypanov) Date: Fri, 9 Dec 2022 14:48:02 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 14:35:47 GMT, Roger Riggs wrote: >> Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like >> >> void iterate(T[] items) { >> if (items.length == 0) { >> return; >> } >> for (T item : items) { >> //... >> } >> } >> >> Here >> >> if (items.length == 0) { >> return; >> } >> >> is redundant and can be removed as length check is performed by for-each loop. > > @stsypanov , @TheShermanTanker You jumped the gun a bit on the integration and sponsoring. There was no approval for the core-libs parts from a "R"eviewer. @RogerRiggs changes are trivial. Should I revert any of them? ------------- PR: https://git.openjdk.org/jdk/pull/11589 From rriggs at openjdk.org Fri Dec 9 15:54:00 2022 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Dec 2022 15:54:00 GMT Subject: RFR: 8298380: Clean up redundant array length checks in JDK code base In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 12:37:17 GMT, Sergey Tsypanov wrote: > Newer version of IntelliJ IDEA introduces new [inspection](https://youtrack.jetbrains.com/issue/IDEA-301797/IDEA-should-report-redundant-array-length-check-in-certain-cases) detecting redundant array length check in snippets like > > void iterate(T[] items) { > if (items.length == 0) { > return; > } > for (T item : items) { > //... > } > } > > Here > > if (items.length == 0) { > return; > } > > is redundant and can be removed as length check is performed by for-each loop. No, just a reminder to be through in the process. ------------- PR: https://git.openjdk.org/jdk/pull/11589 From cjplummer at openjdk.org Fri Dec 9 18:44:05 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 18:44:05 GMT Subject: RFR: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx [v3] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 03:12:36 GMT, Chris Plummer wrote: >> This fixes two separate CRs: >> >> [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes >> [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx >> >> For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. >> >> For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Update test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > > Remove extra space. Thanks for the reviews! ------------- PR: https://git.openjdk.org/jdk/pull/11576 From cjplummer at openjdk.org Fri Dec 9 18:45:59 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 18:45:59 GMT Subject: Integrated: 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 03:06:31 GMT, Chris Plummer wrote: > This fixes two separate CRs: > > [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes > [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx > > For the first one the test was hitting an 8m timeout, but completing right after that. The test log said PASSED, but jtreg failed it anyway because it noticed the timeout. The fix is to double the default 120s timeout to 240s (which is 16m when the 4x timeoutfactor is applied. > > For the second one the issue seemed to be with having the test process spawn a jhsdb process that attached back to the test process. OSX didn't seem to be too happy about this. The fix is to instead create a LingeredApp process to attach to like all the other SA tests do. This pull request has now been integrated. Changeset: 99a6c478 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/99a6c47855ad82e81a80726cf3aa4522c547716d Stats: 9 lines in 2 files changed: 5 ins; 1 del; 3 mod 8298073: gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task timeout on macosx 8241293: CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes Reviewed-by: ayang, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11576 From cjplummer at openjdk.org Fri Dec 9 19:39:40 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 19:39:40 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 03:00:36 GMT, Serguei Spitsyn wrote: > Should we consider filing a CSR as potentially there is a minimal compatibility risk? It don't think it should be necessary. I don't believe there are any known compatibility issues here. Although we switched from requesting `JVMTI_VERSION_1` to requesting the current compile time `JVMTI_VERSION`, it's always been a requirement of the `compatible_versions()` check that the compile time and runtime major versions match up. What has changed somewhat is that the micro versions must also match up, but I don't think we bother with minor or micro versions anymore. There is one downside of requesting `JVMTI_VERSION` instead of `JVMTI_VERSION_1` that I'm now realizing. If you do try to drop a newer debug agent into an older jdk release, GetEnv() will fail. That's ok, but if we allowed it to succeed by fetching `JVMTI_VERSION_1`, then instead the `compatible_versions()` check would fail, which would give you a more meaningful error message. In other words, rather than a "GetEnv() failed" message you would get a "incompatible version" error message. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From dcubed at openjdk.org Fri Dec 9 19:42:14 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Dec 2022 19:42:14 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer wrote: >> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of some structs and statics that are no longer needed. I have a memory of the following concerning JVM/TI versions: - if you asked for JVMTI_VERSION, then you got the highest version supported by the JVM. - if you asked for JVMTI_VERSION_1, then you got the highest compatible version to VERSION_1. - if you asked for JVMTI_VERSION_1_1, then you got JVMTI_VERSION_1_1, no more, no less if the JVM supports it. Here's where things get gnarly: - if you asked for JVMTI_VERSION_1, could you get back JVMTI_VERSION_1_2 or JVMTI_VERSION_9 or JVMTI_VERSION_11 if the JVM in question supported each of those versions (and no higher)? - the assumption that I've always made is that each of JVMTI_VERSION_1_N are all considered compatible so asked for JVMTI_VERSION_1, you would get the highest compatible version in the JVMTI_VERSION_1_N set that is supported by the JVM on which you ask the question. - if you ask for JVMTI_VERSION_1 on a JVM that supports JVMTI_VERSION_1_N and JVMTI_VERSION_9 then I would expect you to get back JVMTI_VERSION_1_2 and not JVMTI_VERSION_9. Why? - My assumption is that you only change major version numbers when you make incompatible changes. Adding a new API is a compatible change because the older agent doesn't know how to use the new API. Changing the semantics of an existing API is NOT a compatible change so you bump the major number. So I'm assuming that JVMTI_VERSION_9 has incompatible changes relative to JVMTI_VERSION_1_N. Similarly I'm assuming that JVMTI_VERSION_11 has incompatible changes relative to JVMTI_VERSION_9 and JVMTI_VERSION_1_N. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From dcubed at openjdk.org Fri Dec 9 19:47:09 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 9 Dec 2022 19:47:09 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer wrote: >> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of some structs and statics that are no longer needed. Of course, it is possible that JVMTI_VERSION_9 is compatible with JVMTI_VERSION_1_N and JVMTI_VERSION_11 is compatible with both JVMTI_VERSION_9 and JVMTI_VERSION_1_N. We might have simply bumped the major number because we were in that train of thought back in the JDK9 days... I have not checked the compatibility matrices for the various JVM/TI releases in a very, very long time. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Fri Dec 9 21:07:54 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 21:07:54 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: <7WiygVpULUxVVZRqHMsOfvF1v9cxKTjoOhSXJJq489k=.f175fd37-f95f-4f03-aa7e-825d89fac7a7@github.com> On Fri, 9 Dec 2022 19:39:16 GMT, Daniel D. Daugherty wrote: > if you asked for JVMTI_VERSION_1, could you get back JVMTI_VERSION_1_2 or JVMTI_VERSION_9 or JVMTI_VERSION_11 if the JVM in question supported each of those versions (and no higher)? Yes, but the debug agent does a version check to make sure the runtime version matches the compile time version. Right now if I ask for JVMTI_VERSION_1 I will get back version 21, so it seems that GetEnv() always returns the version that was current when JVMTI was built, except of course it will fail if the requested version is newer. It seems we update the major version with every JDK release. Here's what currently is produced in jvmti.h: enum { JVMTI_VERSION_1 = 0x30010000, JVMTI_VERSION_1_0 = 0x30010000, JVMTI_VERSION_1_1 = 0x30010100, JVMTI_VERSION_1_2 = 0x30010200, JVMTI_VERSION_9 = 0x30090000, JVMTI_VERSION_11 = 0x300B0000, JVMTI_VERSION_19 = 0x30130000, JVMTI_VERSION = 0x30000000 + (21 * 0x10000) + ( 0 * 0x100) + 0 /* version: 21.0.0 */ }; So it seems right now there is no difference in the end result between using JVMTI_VERSION and JVMTI_VERSION_, assuming the compile and runtime versions match (you aren't dropping the debug agent into a different JDK build). Now for jvmti agents that possibly could end up running in various JDK releases, the difference is more meaningful. They probably do not want to use JDK_VERSION because this could cause the agent to fail to initialize with older JDK releases that the agent author intends for agent to work with. Instead they should specify the minimum JVMTI version that they require. Having said that it may at first seem odd that the debug agent would want to request JVMTI_VERSION_1, since it actually requires something newer, but the check to make sure that the runtime and compile time versions are the same will produce an error if indeed the runtime version is older than what we built against. So the advantage of requesting an old version and then doing a runtime version check is that is that you can produce a very specific error message if the versioning is not right. If you rely on GetEnv to catch versioning issues, all you know is that you got a JNI_EVERSION error code. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Fri Dec 9 22:26:53 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 9 Dec 2022 22:26:53 GMT Subject: RFR: 8298343: "Could not confirm if TargetJDK is hardened." warning for SA tests on macosx-aarch64-debug Message-ID: In the log for most SA tests on macos-aarch64-debug, you will see something like: STDOUT: Executable=/System/Volumes/Data/mesos/work_dir/jib-master/install/2022-12-07-2219530.chris.plummer.jdk/macosx-aarch64-debug.jdk/jdk-20/fastdebug/bin/java ... STDOUT: CodeDirectory v=20400 size=758 flags=0x2(adhoc) hashes=13+7 location=embedded STDOUT: Signature=adhoc ... Could not confirm if TargetJDK is hardened. Assuming not hardened. The message at the end shouldn't be happening. The problem is in `Platform.isHardenedOSX()`, which is searching for "flags=0x20002(adhoc,linker-signed)", but instead we are seeing "flags=0x2(adhoc)". This is due to [JDK-8293550](https://bugs.openjdk.org/browse/JDK-8293550), which is now explicitly adding adhoc signing. Previously we just allowed the linker to just do the default adhoc signing, which is why you would also see the "linker-signed" flag. Since we explicitly do adhoc signing now, "linker-signed" is missing. The fix is to just allow either form. Since it is possible to build without the explicit adhoc signing, we still need to support the old form that includes "linker-signed". There seems to be no adverse affects from this bug, other than seeing the above message, since the conclusion that the JDK is not hardened is the correct one. ------------- Commit messages: - Allow adhoc signing that is not linker signed. Changes: https://git.openjdk.org/jdk/pull/11619/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11619&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298343 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11619.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11619/head:pull/11619 PR: https://git.openjdk.org/jdk/pull/11619 From amenkov at openjdk.org Fri Dec 9 23:26:27 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Dec 2022 23:26:27 GMT Subject: RFR: 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker Message-ID: The fix updates the test to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint ------------- Commit messages: - Fixed suspendpolicy009 test Changes: https://git.openjdk.org/jdk/pull/11620/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11620&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298513 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11620.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11620/head:pull/11620 PR: https://git.openjdk.org/jdk/pull/11620 From amenkov at openjdk.org Fri Dec 9 23:31:18 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Dec 2022 23:31:18 GMT Subject: RFR: 8298514: vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java fails with usage tracker Message-ID: One more test fix to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint ------------- Commit messages: - Fixed thrdeathreq002 test Changes: https://git.openjdk.org/jdk/pull/11621/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11621&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298514 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11621.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11621/head:pull/11621 PR: https://git.openjdk.org/jdk/pull/11621 From amenkov at openjdk.org Fri Dec 9 23:34:07 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 9 Dec 2022 23:34:07 GMT Subject: RFR: 8298343: "Could not confirm if TargetJDK is hardened." warning for SA tests on macosx-aarch64-debug In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 22:16:44 GMT, Chris Plummer wrote: > In the log for most SA tests on macos-aarch64-debug, you will see something like: > > > STDOUT: Executable=/System/Volumes/Data/mesos/work_dir/jib-master/install/2022-12-07-2219530.chris.plummer.jdk/macosx-aarch64-debug.jdk/jdk-20/fastdebug/bin/java > ... > STDOUT: CodeDirectory v=20400 size=758 flags=0x2(adhoc) hashes=13+7 location=embedded > STDOUT: Signature=adhoc > ... > Could not confirm if TargetJDK is hardened. Assuming not hardened. > > > The message at the end shouldn't be happening. The problem is in `Platform.isHardenedOSX()`, which is searching for "flags=0x20002(adhoc,linker-signed)", but instead we are seeing "flags=0x2(adhoc)". This is due to [JDK-8293550](https://bugs.openjdk.org/browse/JDK-8293550), which is now explicitly adding adhoc signing. Previously we just allowed the linker to just do the default adhoc signing, which is why you would also see the "linker-signed" flag. Since we explicitly do adhoc signing now, "linker-signed" is missing. > > The fix is to just allow either form. Since it is possible to build without the explicit adhoc signing, we still need to support the old form that includes "linker-signed". > > There seems to be no adverse affects from this bug, other than seeing the above message, since the conclusion that the JDK is not hardened is the correct one. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11619 From alanb at openjdk.org Sat Dec 10 10:36:02 2022 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 10 Dec 2022 10:36:02 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 19:39:16 GMT, Daniel D. Daugherty wrote: > I have a memory of the following concerning JVM/TI versions: > > * if you asked for JVMTI_VERSION, then you got the highest version supported by the JVM. JVMTI_VERSION is defined in jvmti.h so its value depends on which JDK include directory was used when compiling the agent. If the JDK supports that version then it is required to return a JVMTI env that is compatible or fail with EVERSION. If the agent calls GetVersionNumber to see what version it got then it may be a newer (but compatible) version, which is what our implementation does. It may be that the agent was compiled with JVMTI_VERSION for a newer JDK release, in which case GetEnv must fail with EVERSION as an older JDK release doesn't know about new JVMTI versions. In any case, there should be no mix'ing and matching with the JDWP agent so GetEnv asking for JVMTI_VERSION should be okay. For a JDK build, the JVMTI version at build time will match run-time. A hash of the jdk.jdwp.agent module is generated at build/packaging time to prevent accidental linking with modules from different JDK builds. If someone does attempt to run jlink and use java.base from one build and jdk.jdwp.agent from another build then they will get an error that the hashes don't match. It is of course possible that someone does a slight of hand and copy a libjdwp/libdt_socket from one JDK build into a build from a different JDK release but I don't think we need to spend too much time on that as it's just not supported to do that. Also, as Chris says, the version compatibility check should catch it too. > * if you asked for JVMTI_VERSION_1, then you got the highest compatible version to VERSION_1. > * if you asked for JVMTI_VERSION_1_1, then you got JVMTI_VERSION_1_1, no more, no less if the JVM supports it. If you run on JDK 19 then you'll get a JVMTI_VERSION_19 in both cases. It might be in the future that we need to do some incompatible changes to JVMTI, like remove the deprecated heap functions, in which case it might have to return EVERSION for both cases. The is a bridge that we haven't got to yet but I expect it will require discussing JVMTI capabilities at the same time. In passing, I see that JvmtiExport::get_jvmti_interface doesn't reject 19.minor, I guess it should. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From dholmes at openjdk.org Mon Dec 12 01:00:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 Dec 2022 01:00:58 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable I'm still seeing a few oddities in the code. Overall it is very hard in the PR to get a good sense of the conversion process, but it seems fairly reasonable. It is hard to see how all the different parts of the APIs connect e.g. to understand why some methods are returning boolean values that are always true. Also please do not force-push. src/hotspot/share/prims/jvmtiTagMap.cpp line 1262: > 1260: // and record the reference and tag value. > 1261: // > 1262: bool do_entry(JvmtiTagMapKey& key, jlong& value) { I still see no point in this method returning a bool when it only ever returns true. src/hotspot/share/prims/jvmtiTagMapTable.cpp line 114: > 112: JvmtiTagMapKey new_entry(obj); > 113: bool is_updated = _table.put(new_entry, tag) == false; > 114: assert(is_updated, "should be updated and not added"); This API is confusing. You have `add` and `replace` but in product mode an `add` can `replace` and a `replace` can `add`. It isn't clear if these should be allowed rare conditions or fatal errors. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Dec 12 01:00:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 Dec 2022 01:00:58 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 22:17:14 GMT, David Holmes wrote: >> ResourceHashTable::put() returns true if the Key,Value is added, false if the Value is updated. > > But this doesn't do that, so ?? This issue is not resolved. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Mon Dec 12 01:00:58 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 Dec 2022 01:00:58 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: <0pbB8d_Ihehf2KgV16rg4dh7cLy_eeZE2lGwovLEiBs=.4a05bd73-4252-449a-ae46-448fda30e2e6@github.com> On Mon, 28 Nov 2022 01:23:10 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8292741: Convert JvmtiTagMapTable to ResourceHashtable > > src/hotspot/share/prims/jvmtiTagMapTable.cpp line 88: > >> 86: } >> 87: >> 88: JvmtiTagMapTable::~JvmtiTagMapTable() { > > Is this the only use of `clear`? If so we can just inline its code here and remove it from the API. This issue is not resolved. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From cjplummer at openjdk.org Mon Dec 12 01:03:39 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Dec 2022 01:03:39 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: <5IX08rESJFz5sIQIWOzq69akr2Zvf1AgiQuaFxiHGpw=.20c96c61-d561-4785-b45c-07d10e326b57@github.com> On Sat, 10 Dec 2022 10:29:43 GMT, Alan Bateman wrote: >> I have a memory of the following concerning JVM/TI versions: >> >> - if you asked for JVMTI_VERSION, then you got the highest version supported by the JVM. >> - if you asked for JVMTI_VERSION_1, then you got the highest compatible version to VERSION_1. >> - if you asked for JVMTI_VERSION_1_1, then you got JVMTI_VERSION_1_1, no more, no less if the JVM supports it. >> >> Here's where things get gnarly: >> - if you asked for JVMTI_VERSION_1, could you get back JVMTI_VERSION_1_2 or JVMTI_VERSION_9 or >> JVMTI_VERSION_11 if the JVM in question supported each of those versions (and no higher)? >> - the assumption that I've always made is that each of JVMTI_VERSION_1_N are all considered >> compatible so asked for JVMTI_VERSION_1, you would get the highest compatible version in >> the JVMTI_VERSION_1_N set that is supported by the JVM on which you ask the question. >> - if you ask for JVMTI_VERSION_1 on a JVM that supports JVMTI_VERSION_1_N and JVMTI_VERSION_9 >> then I would expect you to get back JVMTI_VERSION_1_2 and not JVMTI_VERSION_9. Why? >> - My assumption is that you only change major version numbers when you make incompatible >> changes. Adding a new API is a compatible change because the older agent doesn't know how >> to use the new API. Changing the semantics of an existing API is NOT a compatible change so >> you bump the major number. >> >> So I'm assuming that JVMTI_VERSION_9 has incompatible changes relative to JVMTI_VERSION_1_N. >> Similarly I'm assuming that JVMTI_VERSION_11 has incompatible changes relative to JVMTI_VERSION_9 >> and JVMTI_VERSION_1_N. > >> I have a memory of the following concerning JVM/TI versions: >> >> * if you asked for JVMTI_VERSION, then you got the highest version supported by the JVM. > > JVMTI_VERSION is defined in jvmti.h so its value depends on which JDK include directory was used when compiling the agent. If the JDK supports that version then it is required to return a JVMTI env that is compatible or fail with EVERSION. If the agent calls GetVersionNumber to see what version it got then it may be a newer (but compatible) version, which is what our implementation does. It may be that the agent was compiled with JVMTI_VERSION for a newer JDK release, in which case GetEnv must fail with EVERSION as an older JDK release doesn't know about new JVMTI versions. > > In any case, there should be no mix'ing and matching with the JDWP agent so GetEnv asking for JVMTI_VERSION should be okay. For a JDK build, the JVMTI version at build time will match run-time. A hash of the jdk.jdwp.agent module is generated at build/packaging time to prevent accidental linking with modules from different JDK builds. If someone does attempt to run jlink and use java.base from one build and jdk.jdwp.agent from another build then they will get an error that the hashes don't match. It is of course possible that someone does a slight of hand and copy a libjdwp/libdt_socket from one JDK build into a build from a different JDK release but I don't think we need to spend too much time on that as it's just not supported to do that. Also, as Chris says, the version compatibility check should catch it too. > > >> * if you asked for JVMTI_VERSION_1, then you got the highest compatible version to VERSION_1. >> * if you asked for JVMTI_VERSION_1_1, then you got JVMTI_VERSION_1_1, no more, no less if the JVM supports it. > > If you run on JDK 19 then you'll get a JVMTI_VERSION_19 in both cases. It might be in the future that we need to do some incompatible changes to JVMTI, like remove the deprecated heap functions, in which case it might have to return EVERSION for both cases. The is a bridge that we haven't got to yet but I expect it will require discussing JVMTI capabilities at the same time. > > In passing, I see that JvmtiExport::get_jvmti_interface doesn't reject 19.minor, I guess it should. @AlanBateman I agree with everything you say, but there is one advantage to using JVMTI_VERSION_1 instead of JVMTI_VERSION. With the former if you tried, for example, to drop the JDK 21 debug agent into a JDK 20 build, you will get: `ERROR: This jdwp native library will not work with this VM's version of JVMTI (20.0.0). It needs JVMTI 21.0[.0].` However, if you use JVMTI_VERSION, the error you will see is: `ERROR: JDWP unable to access JVMTI Version 21.0.0 (0x30150000). JNIEnv's GetEnv() returned -3.` This is because the first example passes the GetEnv() but then fails the version check, and the 2nd one fails the GetEnv(). Both are doing the right thing. It's just a matter of the preferable error message, and the 2nd seems better. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Mon Dec 12 01:09:43 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Dec 2022 01:09:43 GMT Subject: RFR: 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 23:18:23 GMT, Alex Menkov wrote: > The fix updates the test to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11620 From cjplummer at openjdk.org Mon Dec 12 01:12:06 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Dec 2022 01:12:06 GMT Subject: RFR: 8298514: vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 23:21:04 GMT, Alex Menkov wrote: > One more test fix to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint Marked as reviewed by cjplummer (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11621 From aturbanov at openjdk.org Mon Dec 12 07:39:07 2022 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 12 Dec 2022 07:39:07 GMT Subject: Integrated: 8298090: Use String.join() instead of manual loop in DescriptorSupport.toString In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 21:30:51 GMT, Andrey Turbanov wrote: > There is opportunity to use String.join in DescriptorSupport.toString implementation. Result code is much shorter and clearer. This pull request has now been integrated. Changeset: d646e32b Author: Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/d646e32b7a0f8e4a66f06e15e289d4ed70b8250e Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod 8298090: Use String.join() instead of manual loop in DescriptorSupport.toString Reviewed-by: stsypanov, sspitsyn, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/10960 From sspitsyn at openjdk.org Mon Dec 12 10:30:55 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Dec 2022 10:30:55 GMT Subject: RFR: 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 23:18:23 GMT, Alex Menkov wrote: > The fix updates the test to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11620 From sspitsyn at openjdk.org Mon Dec 12 10:38:56 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 12 Dec 2022 10:38:56 GMT Subject: RFR: 8298514: vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 23:21:04 GMT, Alex Menkov wrote: > One more test fix to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11621 From kevinw at openjdk.org Mon Dec 12 10:51:45 2022 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 12 Dec 2022 10:51:45 GMT Subject: RFR: 8298343: "Could not confirm if TargetJDK is hardened." warning for SA tests on macosx-aarch64-debug In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 22:16:44 GMT, Chris Plummer wrote: > In the log for most SA tests on macos-aarch64-debug, you will see something like: > > > STDOUT: Executable=/System/Volumes/Data/mesos/work_dir/jib-master/install/2022-12-07-2219530.chris.plummer.jdk/macosx-aarch64-debug.jdk/jdk-20/fastdebug/bin/java > ... > STDOUT: CodeDirectory v=20400 size=758 flags=0x2(adhoc) hashes=13+7 location=embedded > STDOUT: Signature=adhoc > ... > Could not confirm if TargetJDK is hardened. Assuming not hardened. > > > The message at the end shouldn't be happening. The problem is in `Platform.isHardenedOSX()`, which is searching for "flags=0x20002(adhoc,linker-signed)", but instead we are seeing "flags=0x2(adhoc)". This is due to [JDK-8293550](https://bugs.openjdk.org/browse/JDK-8293550), which is now explicitly adding adhoc signing. Previously we just allowed the linker to just do the default adhoc signing, which is why you would also see the "linker-signed" flag. Since we explicitly do adhoc signing now, "linker-signed" is missing. > > The fix is to just allow either form. Since it is possible to build without the explicit adhoc signing, we still need to support the old form that includes "linker-signed". > > There seems to be no adverse affects from this bug, other than seeing the above message, since the conclusion that the JDK is not hardened is the correct one. Marked as reviewed by kevinw (Committer). ------------- PR: https://git.openjdk.org/jdk/pull/11619 From rehn at openjdk.org Mon Dec 12 14:46:08 2022 From: rehn at openjdk.org (Robbin Ehn) Date: Mon, 12 Dec 2022 14:46:08 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 00:58:35 GMT, David Holmes wrote: > Also please do not force-push. FYI: I'm not sure it even was possible to fix the "full of unexpected changes" without force push. Even if it was, the effort required to fix it without force push would be pretty significant. So I'd say this one of those exceptions to the rule :) ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Mon Dec 12 14:53:05 2022 From: duke at openjdk.org (Afshin Zafari) Date: Mon, 12 Dec 2022 14:53:05 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 14:44:03 GMT, Robbin Ehn wrote: > > Also please do not force-push. > > FYI: I'm not sure it even was possible to fix the "full of unexpected changes" without force push. Even if it was, the effort required to fix it without force push would be pretty significant. So I'd say this one of those exceptions to the rule :) I did 2 mistakes: rebase my branch while a PR was in progress, and force-push my changes After getting help from colleagues, I had to do another force-push to get back my branch to its state before the mistakes. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From alanb at openjdk.org Mon Dec 12 16:31:02 2022 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Dec 2022 16:31:02 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Sat, 10 Dec 2022 10:29:43 GMT, Alan Bateman wrote: >> I have a memory of the following concerning JVM/TI versions: >> >> - if you asked for JVMTI_VERSION, then you got the highest version supported by the JVM. >> - if you asked for JVMTI_VERSION_1, then you got the highest compatible version to VERSION_1. >> - if you asked for JVMTI_VERSION_1_1, then you got JVMTI_VERSION_1_1, no more, no less if the JVM supports it. >> >> Here's where things get gnarly: >> - if you asked for JVMTI_VERSION_1, could you get back JVMTI_VERSION_1_2 or JVMTI_VERSION_9 or >> JVMTI_VERSION_11 if the JVM in question supported each of those versions (and no higher)? >> - the assumption that I've always made is that each of JVMTI_VERSION_1_N are all considered >> compatible so asked for JVMTI_VERSION_1, you would get the highest compatible version in >> the JVMTI_VERSION_1_N set that is supported by the JVM on which you ask the question. >> - if you ask for JVMTI_VERSION_1 on a JVM that supports JVMTI_VERSION_1_N and JVMTI_VERSION_9 >> then I would expect you to get back JVMTI_VERSION_1_2 and not JVMTI_VERSION_9. Why? >> - My assumption is that you only change major version numbers when you make incompatible >> changes. Adding a new API is a compatible change because the older agent doesn't know how >> to use the new API. Changing the semantics of an existing API is NOT a compatible change so >> you bump the major number. >> >> So I'm assuming that JVMTI_VERSION_9 has incompatible changes relative to JVMTI_VERSION_1_N. >> Similarly I'm assuming that JVMTI_VERSION_11 has incompatible changes relative to JVMTI_VERSION_9 >> and JVMTI_VERSION_1_N. > >> I have a memory of the following concerning JVM/TI versions: >> >> * if you asked for JVMTI_VERSION, then you got the highest version supported by the JVM. > > JVMTI_VERSION is defined in jvmti.h so its value depends on which JDK include directory was used when compiling the agent. If the JDK supports that version then it is required to return a JVMTI env that is compatible or fail with EVERSION. If the agent calls GetVersionNumber to see what version it got then it may be a newer (but compatible) version, which is what our implementation does. It may be that the agent was compiled with JVMTI_VERSION for a newer JDK release, in which case GetEnv must fail with EVERSION as an older JDK release doesn't know about new JVMTI versions. > > In any case, there should be no mix'ing and matching with the JDWP agent so GetEnv asking for JVMTI_VERSION should be okay. For a JDK build, the JVMTI version at build time will match run-time. A hash of the jdk.jdwp.agent module is generated at build/packaging time to prevent accidental linking with modules from different JDK builds. If someone does attempt to run jlink and use java.base from one build and jdk.jdwp.agent from another build then they will get an error that the hashes don't match. It is of course possible that someone does a slight of hand and copy a libjdwp/libdt_socket from one JDK build into a build from a different JDK release but I don't think we need to spend too much time on that as it's just not supported to do that. Also, as Chris says, the version compatibility check should catch it too. > > >> * if you asked for JVMTI_VERSION_1, then you got the highest compatible version to VERSION_1. >> * if you asked for JVMTI_VERSION_1_1, then you got JVMTI_VERSION_1_1, no more, no less if the JVM supports it. > > If you run on JDK 19 then you'll get a JVMTI_VERSION_19 in both cases. It might be in the future that we need to do some incompatible changes to JVMTI, like remove the deprecated heap functions, in which case it might have to return EVERSION for both cases. The is a bridge that we haven't got to yet but I expect it will require discussing JVMTI capabilities at the same time. > > In passing, I see that JvmtiExport::get_jvmti_interface doesn't reject 19.minor, I guess it should. > @AlanBateman I agree with everything you say, but there is one advantage to using JVMTI_VERSION_1 instead of JVMTI_VERSION. With the former if you tried, for example, to drop the JDK 21 debug agent into a JDK 20 build, you will get: > > `ERROR: This jdwp native library will not work with this VM's version of JVMTI (20.0.0). It needs JVMTI 21.0[.0].` > > However, if you use JVMTI_VERSION, the error you will see is: > > `ERROR: JDWP unable to access JVMTI Version 21.0.0 (0x30150000). JNIEnv's GetEnv() returned -3.` > > This is because the first example passes the GetEnv() but then fails the version check, and the 2nd one fails the GetEnv(). Both are doing the right thing. It's just a matter of the preferable error message, and the 2nd seems better. I don't have mind. For now (JDK 19 and 20), the case where it will only likely arise is -agentlib:jdwp --enable-preview on ports that don't have VM continuations. In that case, GetEnv will fail. If virtual threads become permanent in JDK 21 and JVMTI is not updated to work with the alternative implementation of virtual threads then we might have to expand the error message a bit. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From coleenp at openjdk.org Mon Dec 12 18:02:59 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 12 Dec 2022 18:02:59 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable I have a couple of minor comments but this looks good. This hashtable was more problematic to convert so good job! src/hotspot/share/prims/jvmtiTagMapTable.cpp line 117: > 115: JvmtiTagMapEntry* JvmtiTagMapTable::find(oop obj) { > 116: if (obj->fast_no_hash_check()) { > 117: // Objects in the table all have a hashcode. Can you keep this comment? src/hotspot/share/prims/jvmtiTagMapTable.hpp line 72: > 70: typedef > 71: ResizeableResourceHashtable 72: AnyObj::C_HEAP, mtInternal, This should be mtServiceability rather than mtInternal. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11288 From cjplummer at openjdk.org Mon Dec 12 18:22:54 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Dec 2022 18:22:54 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 16:28:27 GMT, Alan Bateman wrote: > I don't mind. For now (JDK 19 and 20), the case where it will only likely arise is -agentlib:jdwp --enable-preview on ports that don't have VM continuations. In that case, GetEnv will fail. If virtual threads become permanent in JDK 21 and JVMTI is not updated to work with the alternative implementation of virtual threads then we might have to expand the error message a bit. Seems like that is going to be an issue for any JVMTI agent, and I'm not too sure how we would determine the issue is a lack of JVMTI support on the platform. Is seems JVMTI is currently returning EVERSION when it is not supported, which isn't all the useful in determining the underlying reason. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Mon Dec 12 18:26:59 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Dec 2022 18:26:59 GMT Subject: RFR: 8298343: "Could not confirm if TargetJDK is hardened." warning for SA tests on macosx-aarch64-debug In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 22:16:44 GMT, Chris Plummer wrote: > In the log for most SA tests on macos-aarch64-debug, you will see something like: > > > STDOUT: Executable=/System/Volumes/Data/mesos/work_dir/jib-master/install/2022-12-07-2219530.chris.plummer.jdk/macosx-aarch64-debug.jdk/jdk-20/fastdebug/bin/java > ... > STDOUT: CodeDirectory v=20400 size=758 flags=0x2(adhoc) hashes=13+7 location=embedded > STDOUT: Signature=adhoc > ... > Could not confirm if TargetJDK is hardened. Assuming not hardened. > > > The message at the end shouldn't be happening. The problem is in `Platform.isHardenedOSX()`, which is searching for "flags=0x20002(adhoc,linker-signed)", but instead we are seeing "flags=0x2(adhoc)". This is due to [JDK-8293550](https://bugs.openjdk.org/browse/JDK-8293550), which is now explicitly adding adhoc signing. Previously we just allowed the linker to just do the default adhoc signing, which is why you would also see the "linker-signed" flag. Since we explicitly do adhoc signing now, "linker-signed" is missing. > > The fix is to just allow either form. Since it is possible to build without the explicit adhoc signing, we still need to support the old form that includes "linker-signed". > > There seems to be no adverse affects from this bug, other than seeing the above message, since the conclusion that the JDK is not hardened is the correct one. Thank you Alex and Serguei. ------------- PR: https://git.openjdk.org/jdk/pull/11619 From cjplummer at openjdk.org Mon Dec 12 18:34:05 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 12 Dec 2022 18:34:05 GMT Subject: Integrated: 8298343: "Could not confirm if TargetJDK is hardened." warning for SA tests on macosx-aarch64-debug In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 22:16:44 GMT, Chris Plummer wrote: > In the log for most SA tests on macos-aarch64-debug, you will see something like: > > > STDOUT: Executable=/System/Volumes/Data/mesos/work_dir/jib-master/install/2022-12-07-2219530.chris.plummer.jdk/macosx-aarch64-debug.jdk/jdk-20/fastdebug/bin/java > ... > STDOUT: CodeDirectory v=20400 size=758 flags=0x2(adhoc) hashes=13+7 location=embedded > STDOUT: Signature=adhoc > ... > Could not confirm if TargetJDK is hardened. Assuming not hardened. > > > The message at the end shouldn't be happening. The problem is in `Platform.isHardenedOSX()`, which is searching for "flags=0x20002(adhoc,linker-signed)", but instead we are seeing "flags=0x2(adhoc)". This is due to [JDK-8293550](https://bugs.openjdk.org/browse/JDK-8293550), which is now explicitly adding adhoc signing. Previously we just allowed the linker to just do the default adhoc signing, which is why you would also see the "linker-signed" flag. Since we explicitly do adhoc signing now, "linker-signed" is missing. > > The fix is to just allow either form. Since it is possible to build without the explicit adhoc signing, we still need to support the old form that includes "linker-signed". > > There seems to be no adverse affects from this bug, other than seeing the above message, since the conclusion that the JDK is not hardened is the correct one. This pull request has now been integrated. Changeset: 781a2e0b Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/781a2e0b2d7d0f36387837de6f50ff087502d317 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8298343: "Could not confirm if TargetJDK is hardened." warning for SA tests on macosx-aarch64-debug Reviewed-by: amenkov, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/11619 From lmesnik at openjdk.org Mon Dec 12 20:29:56 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 12 Dec 2022 20:29:56 GMT Subject: RFR: 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 23:18:23 GMT, Alex Menkov wrote: > The fix updates the test to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11620 From dholmes at openjdk.org Tue Dec 13 00:34:53 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 Dec 2022 00:34:53 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 16:56:40 GMT, Afshin Zafari wrote: >> test of tier1-5 passed. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > 8292741: Convert JvmtiTagMapTable to ResourceHashtable The alternative to force-push would have been just to create a new PR. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From coleenp at openjdk.org Tue Dec 13 18:37:30 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 13 Dec 2022 18:37:30 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS Message-ID: These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. Tested with tier1-4. ------------- Commit messages: - 8298475: Remove JVM_ACC_PROMOTED_FLAGS Changes: https://git.openjdk.org/jdk/pull/11655/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298475 Stats: 62 lines in 10 files changed: 21 ins; 22 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/11655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11655/head:pull/11655 PR: https://git.openjdk.org/jdk/pull/11655 From sspitsyn at openjdk.org Tue Dec 13 19:21:57 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Dec 2022 19:21:57 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore wrote: > These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. > Tested with tier1-4. I like this fix. It looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11655 From cjplummer at openjdk.org Tue Dec 13 19:24:01 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 13 Dec 2022 19:24:01 GMT Subject: RFR: 8298692: Fix typos in test/jdk/com/sun/jdi files Message-ID: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> These are the typos from #10029 that relate to test/jdk/com/sun/jdi. ------------- Commit messages: - Fix some jdi test typos in comments Changes: https://git.openjdk.org/jdk/pull/11656/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11656&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298692 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11656.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11656/head:pull/11656 PR: https://git.openjdk.org/jdk/pull/11656 From amenkov at openjdk.org Tue Dec 13 19:49:57 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 Dec 2022 19:49:57 GMT Subject: RFR: 8298692: Fix typos in test/jdk/com/sun/jdi files In-Reply-To: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> References: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> Message-ID: On Tue, 13 Dec 2022 19:16:41 GMT, Chris Plummer wrote: > These are the typos from #10029 that relate to test/jdk/com/sun/jdi. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11656 From amenkov at openjdk.org Tue Dec 13 19:52:05 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 Dec 2022 19:52:05 GMT Subject: Integrated: 8298514: vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 23:21:04 GMT, Alex Menkov wrote: > One more test fix to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint This pull request has now been integrated. Changeset: a120764c Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/a120764cc4636b3b0cd128d43de148bdc3f4513b Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8298514: vmTestbase/nsk/jdi/EventRequestManager/threadDeathRequests/thrdeathreq002/TestDescription.java fails with usage tracker Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11621 From amenkov at openjdk.org Tue Dec 13 19:53:00 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 Dec 2022 19:53:00 GMT Subject: Integrated: 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 23:18:23 GMT, Alex Menkov wrote: > The fix updates the test to ignore ThreadDeathEvent event from non-test threads waiting for breakpoint This pull request has now been integrated. Changeset: 220781fa Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/220781fa56a9c8d3b64c5c6578ffd76b9edb795c Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8298513: vmTestbase/nsk/jdi/EventSet/suspendPolicy/suspendpolicy009/TestDescription.java fails with usage tracker Reviewed-by: cjplummer, sspitsyn, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/11620 From sspitsyn at openjdk.org Tue Dec 13 20:05:07 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Dec 2022 20:05:07 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 19:44:34 GMT, Daniel D. Daugherty wrote: > Of course, it is possible that JVMTI_VERSION_9 is compatible with JVMTI_VERSION_1_N and JVMTI_VERSION_11 is compatible with both JVMTI_VERSION_9 and JVMTI_VERSION_1_N. We might have simply bumped the major number because we were in that train of thought back in the JDK9 days... > I have not checked the compatibility matrices for the various JVM/TI releases in a very, very long time. As I remember, it was decided in the JDK 9 time frame that we want the JVMTI version to match the JDK version (starting from JDK 9). So that, we always bump JVMTI version in new releases. ------------- PR: https://git.openjdk.org/jdk/pull/11602 From sspitsyn at openjdk.org Tue Dec 13 20:18:27 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Dec 2022 20:18:27 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer wrote: >> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of some structs and statics that are no longer needed. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11602 From sspitsyn at openjdk.org Tue Dec 13 20:20:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 13 Dec 2022 20:20:54 GMT Subject: RFR: 8298692: Fix typos in test/jdk/com/sun/jdi files In-Reply-To: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> References: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> Message-ID: <50Rp0D0zJit93CTzO8knVDxX567xO72hWlOCW6ihRSw=.bc7a3546-cafa-4f98-be59-c8b1768e42af@github.com> On Tue, 13 Dec 2022 19:16:41 GMT, Chris Plummer wrote: > These are the typos from #10029 that relate to test/jdk/com/sun/jdi. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11656 From coleenp at openjdk.org Tue Dec 13 20:23:10 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 13 Dec 2022 20:23:10 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore wrote: > These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. > Tested with tier1-4. Thank you Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/11655 From dcubed at openjdk.org Tue Dec 13 20:47:06 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Tue, 13 Dec 2022 20:47:06 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS In-Reply-To: References: Message-ID: <8KsIHXtchDelcarz7Pv4To9FmUNgN-soRt7qif3CgQk=.07cb2c0d-446a-485b-9c02-a3e4e59ece61@github.com> On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore wrote: > These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. > Tested with tier1-4. Thumbs up. I definitely like this cleanup/fix. Thanks for including the testing info. src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4376: > 4374: if (scratch_class->has_localvariable_table() != > 4375: the_class->has_localvariable_table()) { > 4376: the_class->set_has_localvariable_table(scratch_class->has_localvariable_table()); nit: need one more space for indent. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.org/jdk/pull/11655 From coleenp at openjdk.org Tue Dec 13 22:00:04 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 13 Dec 2022 22:00:04 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2] In-Reply-To: References: Message-ID: > These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add a space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11655/files - new: https://git.openjdk.org/jdk/pull/11655/files/6f80df95..90ec438a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11655/head:pull/11655 PR: https://git.openjdk.org/jdk/pull/11655 From coleenp at openjdk.org Tue Dec 13 22:00:05 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 13 Dec 2022 22:00:05 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore wrote: > These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. > Tested with tier1-4. Thanks Dan! ------------- PR: https://git.openjdk.org/jdk/pull/11655 From coleenp at openjdk.org Tue Dec 13 22:00:05 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 13 Dec 2022 22:00:05 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2] In-Reply-To: <8KsIHXtchDelcarz7Pv4To9FmUNgN-soRt7qif3CgQk=.07cb2c0d-446a-485b-9c02-a3e4e59ece61@github.com> References: <8KsIHXtchDelcarz7Pv4To9FmUNgN-soRt7qif3CgQk=.07cb2c0d-446a-485b-9c02-a3e4e59ece61@github.com> Message-ID: <5D0J_bzyAga5GUgiy3l-zbRno2_WZJY2iKC7aCkZEWo=.28e40165-fb46-4f5b-8476-f59991ff369b@github.com> On Tue, 13 Dec 2022 20:42:04 GMT, Daniel D. Daugherty wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a space > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 4376: > >> 4374: if (scratch_class->has_localvariable_table() != >> 4375: the_class->has_localvariable_table()) { >> 4376: the_class->set_has_localvariable_table(scratch_class->has_localvariable_table()); > > nit: need one more space for indent. Got it, thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11655 From dholmes at openjdk.org Wed Dec 14 00:56:39 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Dec 2022 00:56:39 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2] In-Reply-To: References: Message-ID: <8NCZpFiEVPPZuc3ceO4fIeZ-NUHD-y38tMVht9ddowo=.e11fb128-b21c-42c5-bdd2-e60065980123@github.com> On Tue, 13 Dec 2022 22:00:04 GMT, Coleen Phillimore wrote: >> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a space Changes looks good. One query below. Thanks. src/hotspot/share/oops/instanceKlassMiscStatus.cpp line 64: > 62: #ifdef ASSERT > 63: void InstanceKlassMiscStatus::assert_is_safe(bool set) { > 64: // Setting a flag is safe if it's set once or at a safepoint. RedefineClasses can set or Is this a generally true statement, or only true for specific flags? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11655 From mennen at openjdk.org Wed Dec 14 03:47:06 2022 From: mennen at openjdk.org (Michael Ennen) Date: Wed, 14 Dec 2022 03:47:06 GMT Subject: RFR: 8295044: Implementation of Foreign Function and Memory API (Second Preview) [v39] In-Reply-To: References: <-V_N0Cvh4J0vKNbBYdFcow9E8yFHRIjya8n69MpDSuY=.9626ee4d-95b6-41e4-b21e-395e79840388@github.com> Message-ID: <91WlM45Ykemls6D5vtXZMIIqjjECQTLVuJFhTLYXq-I=.4e670ac0-f1ff-480e-b18e-cea98d01bd6f@github.com> On Mon, 5 Dec 2022 13:46:09 GMT, Maurizio Cimadamore wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix Preview annotation for JEP 434 > > Note: there are 4 tests failing in x86: > * MemoryLayoutPrincipalTotalityTest > * MemoryLayoutTypeRetentionTest > * TestLargeSegmentCopy > * TestLinker > > These failures are addressed in the dependent PR: https://git.openjdk.org/jdk/pull/11019, which will be integrated immediately after these changes @mcimadamore This PR made my code in [java-vulkan](https://github.com/brcolow/java-vulkan/commit/171f167782eea538b19b60d5fa73e9f75a112f6d) much cleaner! Nice work! ------------- PR: https://git.openjdk.org/jdk/pull/10872 From stefank at openjdk.org Wed Dec 14 10:09:21 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 14 Dec 2022 10:09:21 GMT Subject: RFR: 8298264: Merge OffsetTableContigSpace into TenuredSpace In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 11:16:03 GMT, Albert Mingkun Yang wrote: > Small change of merging two classes to reduce inheritance chain length. > > Test: hotspot_gc Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11556 From tschatzl at openjdk.org Wed Dec 14 11:31:20 2022 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 14 Dec 2022 11:31:20 GMT Subject: RFR: 8298264: Merge OffsetTableContigSpace into TenuredSpace In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 11:16:03 GMT, Albert Mingkun Yang wrote: > Small change of merging two classes to reduce inheritance chain length. > > Test: hotspot_gc Marked as reviewed by tschatzl (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11556 From ayang at openjdk.org Wed Dec 14 12:45:49 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 14 Dec 2022 12:45:49 GMT Subject: RFR: 8298264: Merge OffsetTableContigSpace into TenuredSpace In-Reply-To: References: Message-ID: On Wed, 7 Dec 2022 11:16:03 GMT, Albert Mingkun Yang wrote: > Small change of merging two classes to reduce inheritance chain length. > > Test: hotspot_gc Thanks for the review. ------------- PR: https://git.openjdk.org/jdk/pull/11556 From coleenp at openjdk.org Wed Dec 14 12:49:08 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Dec 2022 12:49:08 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v3] In-Reply-To: References: Message-ID: > These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Missed a comment fix. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11655/files - new: https://git.openjdk.org/jdk/pull/11655/files/90ec438a..346317a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11655&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11655.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11655/head:pull/11655 PR: https://git.openjdk.org/jdk/pull/11655 From coleenp at openjdk.org Wed Dec 14 12:49:08 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Dec 2022 12:49:08 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2] In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 22:00:04 GMT, Coleen Phillimore wrote: >> These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add a space Thanks for the reviews, Serguei, Dan and David. I missed fixing a comment but it's trivial. ------------- PR: https://git.openjdk.org/jdk/pull/11655 From coleenp at openjdk.org Wed Dec 14 12:49:09 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Dec 2022 12:49:09 GMT Subject: RFR: 8298475: Remove JVM_ACC_PROMOTED_FLAGS [v2] In-Reply-To: <8NCZpFiEVPPZuc3ceO4fIeZ-NUHD-y38tMVht9ddowo=.e11fb128-b21c-42c5-bdd2-e60065980123@github.com> References: <8NCZpFiEVPPZuc3ceO4fIeZ-NUHD-y38tMVht9ddowo=.e11fb128-b21c-42c5-bdd2-e60065980123@github.com> Message-ID: On Wed, 14 Dec 2022 00:51:34 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a space > > src/hotspot/share/oops/instanceKlassMiscStatus.cpp line 64: > >> 62: #ifdef ASSERT >> 63: void InstanceKlassMiscStatus::assert_is_safe(bool set) { >> 64: // Setting a flag is safe if it's set once or at a safepoint. RedefineClasses can set or > > Is this a generally true statement, or only true for specific flags? For InstanceKlass, it's true. There are flags that are set at runtime outside a safepoint that require atomic bit set (is_being_redefined for example) that are in AccessFlags. They would fail this test. The flags in MiscStatus::_flags pass this test. ------------- PR: https://git.openjdk.org/jdk/pull/11655 From ayang at openjdk.org Wed Dec 14 12:49:47 2022 From: ayang at openjdk.org (Albert Mingkun Yang) Date: Wed, 14 Dec 2022 12:49:47 GMT Subject: Integrated: 8298264: Merge OffsetTableContigSpace into TenuredSpace In-Reply-To: References: Message-ID: <-irHGXZwf9Wm22PG5T7ILL7Zl76coCjNYsUTDTbuxes=.c224f784-2a0a-4b6d-91a4-50c6a6ffa609@github.com> On Wed, 7 Dec 2022 11:16:03 GMT, Albert Mingkun Yang wrote: > Small change of merging two classes to reduce inheritance chain length. > > Test: hotspot_gc This pull request has now been integrated. Changeset: ceca4fc9 Author: Albert Mingkun Yang URL: https://git.openjdk.org/jdk/commit/ceca4fc9ec33808873a6e4f5d13619db455ce214 Stats: 84 lines in 6 files changed: 7 ins; 56 del; 21 mod 8298264: Merge OffsetTableContigSpace into TenuredSpace Reviewed-by: stefank, tschatzl ------------- PR: https://git.openjdk.org/jdk/pull/11556 From coleenp at openjdk.org Wed Dec 14 12:53:13 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Dec 2022 12:53:13 GMT Subject: Integrated: 8298475: Remove JVM_ACC_PROMOTED_FLAGS In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 18:28:22 GMT, Coleen Phillimore wrote: > These access flags were implemented to enable passing access flag values from Method* to InstanceKlass*, but only covered one flag. Towards only have access flags represent read-only flags in the class file, remove this and pass has_localvariable_table up to InstanceKlass in classfile parsing, like we do with other flags. > Tested with tier1-4. This pull request has now been integrated. Changeset: 2e801e16 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/2e801e16ec40ce0e25d8679e21d7da347c52d7be Stats: 63 lines in 10 files changed: 21 ins; 22 del; 20 mod 8298475: Remove JVM_ACC_PROMOTED_FLAGS Reviewed-by: sspitsyn, dcubed, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/11655 From duke at openjdk.org Wed Dec 14 13:16:03 2022 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 14 Dec 2022 13:16:03 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 17:58:53 GMT, Coleen Phillimore wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8292741: Convert JvmtiTagMapTable to ResourceHashtable > > src/hotspot/share/prims/jvmtiTagMapTable.cpp line 117: > >> 115: JvmtiTagMapEntry* JvmtiTagMapTable::find(oop obj) { >> 116: if (obj->fast_no_hash_check()) { >> 117: // Objects in the table all have a hashcode. > > Can you keep this comment? Done > src/hotspot/share/prims/jvmtiTagMapTable.hpp line 72: > >> 70: typedef >> 71: ResizeableResourceHashtable > 72: AnyObj::C_HEAP, mtInternal, > > This should be mtServiceability rather than mtInternal. Done ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Wed Dec 14 13:30:10 2022 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 14 Dec 2022 13:30:10 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 00:40:14 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8292741: Convert JvmtiTagMapTable to ResourceHashtable > > src/hotspot/share/prims/jvmtiTagMap.cpp line 1262: > >> 1260: // and record the reference and tag value. >> 1261: // >> 1262: bool do_entry(JvmtiTagMapKey& key, jlong& value) { > > I still see no point in this method returning a bool when it only ever returns true. In the `iterate` method of ResourceHashTable, in respurceHash.hpp lines 227-240 copied here, requires a function that returns boolean. If returned false the iterate will break. template void iterate(Function function) const { // lambda enabled API Node* const* bucket = table(); const unsigned sz = table_size(); while (bucket < bucket_at(sz)) { Node* node = *bucket; while (node != NULL) { bool cont = function(node->_key, node->_value); // <--------------****** if (!cont) { return; } node = node->_next; } ++bucket; } } The other `iterate` methods are wrappers around this one. Always returning true means to continue iterating over all the existing items. The former base table for jvmtiTagMapTable needs the `do_entry` be `void`. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From duke at openjdk.org Wed Dec 14 15:13:56 2022 From: duke at openjdk.org (Afshin Zafari) Date: Wed, 14 Dec 2022 15:13:56 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Mon, 12 Dec 2022 00:50:27 GMT, David Holmes wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> 8292741: Convert JvmtiTagMapTable to ResourceHashtable > > src/hotspot/share/prims/jvmtiTagMapTable.cpp line 114: > >> 112: JvmtiTagMapKey new_entry(obj); >> 113: bool is_updated = _table.put(new_entry, tag) == false; >> 114: assert(is_updated, "should be updated and not added"); > > This API is confusing. You have `add` and `replace` but in product mode an `add` can `replace` and a `replace` can `add`. It isn't clear if these should be allowed rare conditions or fatal errors. I agree that this is ambigious. The `jvmtiTagMap` calls `add/update` methods of `jvmtiTagMapTable` which in turn calls `resourceHashTable` methods `put` and `put_if_absent`. `put` and `put_if_absent` can be used for both adding and updating and reporting it in returned values. `jvmtiTagMap` calls to `jvmtiTagMapTable` add/update DO NOT CARE about the returned values. For these calls, it doesn't mater if an add (update) method resulted in an update (add). So which one of the following cases would be correct? - Based on the `jvmtiTagMap` calls, let the add/update be void and ignore the differences of what really happens in the table. Or - Based on the `resourceHashTable` bool-valued `put` and `put_if_absent` methods, let the add/update be bool-values and leave the decision on "what really happened in the table" to the callers in `jvmtiTagMap`. (current implementation) ------------- PR: https://git.openjdk.org/jdk/pull/11288 From rkennke at openjdk.org Wed Dec 14 15:47:00 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 14 Dec 2022 15:47:00 GMT Subject: RFR: 8291555: Replace stack-locking with fast-locking [v8] In-Reply-To: References: Message-ID: On Fri, 28 Oct 2022 09:32:58 GMT, Roman Kennke wrote: >> This change replaces the current stack-locking implementation with a fast-locking scheme that retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation. And because of the very racy nature, this turns out to be very complex and involved a variant of the inflation protocol to ensure that the object header is stable. >> >> What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. >> >> This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations. The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. >> >> In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. >> >> One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. >> >> As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. >> >> This change enables to simplify (and speed-up!) a lot of code: >> >> - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. >> - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR >> >> ### Benchmarks >> >> All benchmarks are run on server-class metal machines. The JVM settings are always: `-Xmx20g -Xms20g -XX:+UseParallelGC`. All benchmarks are ms/ops, less is better. >> >> #### DaCapo/AArch64 >> >> Those measurements have been taken on a Graviton2 box with 64 CPU cores (an AWS m6g.metal instance). It is using DaCapo evaluation version, git hash 309e1fa (download file dacapo-evaluation-git+309e1fa.jar). I needed to exclude cassandra, h2o & kafka benchmarks because of incompatibility with JDK20. Benchmarks that showed results far off the baseline or showed high variance have been repeated and I am reporting results with the most bias *against* fast-locking. The sunflow benchmark is really far off the mark - the baseline run with stack-locking exhibited very high run-to-run variance and generally much worse performance, while with fast-locking the variance was very low and the results very stable between runs. I wouldn't trust that benchmark - I mean what is it actually doing that a change in locking shows >30% perf difference? >> >> benchmark | baseline | fast-locking | % | size >> -- | -- | -- | -- | -- >> avrora | 27859 | 27563 | 1.07% | large >> batik | 20786 | 20847 | -0.29% | large >> biojava | 27421 | 27334 | 0.32% | default >> eclipse | 59918 | 60522 | -1.00% | large >> fop | 3670 | 3678 | -0.22% | default >> graphchi | 2088 | 2060 | 1.36% | default >> h2 | 297391 | 291292 | 2.09% | huge >> jme | 8762 | 8877 | -1.30% | default >> jython | 18938 | 18878 | 0.32% | default >> luindex | 1339 | 1325 | 1.06% | default >> lusearch | 918 | 936 | -1.92% | default >> pmd | 58291 | 58423 | -0.23% | large >> sunflow | 32617 | 24961 | 30.67% | large >> tomcat | 25481 | 25992 | -1.97% | large >> tradebeans | 314640 | 311706 | 0.94% | huge >> tradesoap | 107473 | 110246 | -2.52% | huge >> xalan | 6047 | 5882 | 2.81% | default >> zxing | 970 | 926 | 4.75% | default >> >> #### DaCapo/x86_64 >> >> The following measurements have been taken on an Intel Xeon Scalable Processors (Cascade Lake 8252C) (an AWS m5zn.metal instance). All the same settings and considerations as in the measurements above. >> >> benchmark | baseline | fast-Locking | % | size >> -- | -- | -- | -- | -- >> avrora | 127690 | 126749 | 0.74% | large >> batik | 12736 | 12641 | 0.75% | large >> biojava | 15423 | 15404 | 0.12% | default >> eclipse | 41174 | 41498 | -0.78% | large >> fop | 2184 | 2172 | 0.55% | default >> graphchi | 1579 | 1560 | 1.22% | default >> h2 | 227614 | 230040 | -1.05% | huge >> jme | 8591 | 8398 | 2.30% | default >> jython | 13473 | 13356 | 0.88% | default >> luindex | 824 | 813 | 1.35% | default >> lusearch | 962 | 968 | -0.62% | default >> pmd | 40827 | 39654 | 2.96% | large >> sunflow | 53362 | 43475 | 22.74% | large >> tomcat | 27549 | 28029 | -1.71% | large >> tradebeans | 190757 | 190994 | -0.12% | huge >> tradesoap | 68099 | 67934 | 0.24% | huge >> xalan | 7969 | 8178 | -2.56% | default >> zxing | 1176 | 1148 | 2.44% | default >> >> #### Renaissance/AArch64 >> >> This tests Renaissance/JMH version 0.14.1 on same machines as DaCapo above, with same JVM settings. >> >> benchmark | baseline | fast-locking | % >> -- | -- | -- | -- >> AkkaUct | 2558.832 | 2513.594 | 1.80% >> Reactors | 14715.626 | 14311.246 | 2.83% >> Als | 1851.485 | 1869.622 | -0.97% >> ChiSquare | 1007.788 | 1003.165 | 0.46% >> GaussMix | 1157.491 | 1149.969 | 0.65% >> LogRegression | 717.772 | 733.576 | -2.15% >> MovieLens | 7916.181 | 8002.226 | -1.08% >> NaiveBayes | 395.296 | 386.611 | 2.25% >> PageRank | 4294.939 | 4346.333 | -1.18% >> FjKmeans | 496.076 | 493.873 | 0.45% >> FutureGenetic | 2578.504 | 2589.255 | -0.42% >> Mnemonics | 4898.886 | 4903.689 | -0.10% >> ParMnemonics | 4260.507 | 4210.121 | 1.20% >> Scrabble | 139.37 | 138.312 | 0.76% >> RxScrabble | 320.114 | 322.651 | -0.79% >> Dotty | 1056.543 | 1068.492 | -1.12% >> ScalaDoku | 3443.117 | 3449.477 | -0.18% >> ScalaKmeans | 259.384 | 258.648 | 0.28% >> Philosophers | 24333.311 | 23438.22 | 3.82% >> ScalaStmBench7 | 1102.43 | 1115.142 | -1.14% >> FinagleChirper | 6814.192 | 6853.38 | -0.57% >> FinagleHttp | 4762.902 | 4807.564 | -0.93% >> >> #### Renaissance/x86_64 >> >> benchmark | baseline | fast-locking | % >> -- | -- | -- | -- >> AkkaUct | 1117.185 | 1116.425 | 0.07% >> Reactors | 11561.354 | 11812.499 | -2.13% >> Als | 1580.838 | 1575.318 | 0.35% >> ChiSquare | 459.601 | 467.109 | -1.61% >> GaussMix | 705.944 | 685.595 | 2.97% >> LogRegression | 659.944 | 656.428 | 0.54% >> MovieLens | 7434.303 | 7592.271 | -2.08% >> NaiveBayes | 413.482 | 417.369 | -0.93% >> PageRank | 3259.233 | 3276.589 | -0.53% >> FjKmeans | 946.429 | 938.991 | 0.79% >> FutureGenetic | 1760.672 | 1815.272 | -3.01% >> ParMnemonics | 2016.917 | 2033.101 | -0.80% >> Scrabble | 147.996 | 150.084 | -1.39% >> RxScrabble | 177.755 | 177.956 | -0.11% >> Dotty | 673.754 | 683.919 | -1.49% >> ScalaDoku | 2193.562 | 1958.419 | 12.01% >> ScalaKmeans | 165.376 | 168.925 | -2.10% >> ScalaStmBench7 | 1080.187 | 1049.184 | 2.95% >> Philosophers | 14268.449 | 13308.87 | 7.21% >> FinagleChirper | 4722.13 | 4688.3 | 0.72% >> FinagleHttp | 3497.241 | 3605.118 | -2.99% >> >> Some renaissance benchmarks are missing: DecTree, DbShootout and Neo4jAnalytics are not compatible with JDK20. The remaining benchmarks show very high run-to-run variance, which I am investigating (and probably addressing with running them much more often. >> >> I have also run another benchmark, which is a popular Java JVM benchmark, with workloads wrapped in JMH and very slightly modified to run with newer JDKs, but I won't publish the results because I am not sure about the licensing terms. They look similar to the measurements above (i.e. +/- 2%, nothing very suspicious). >> >> Please let me know if you want me to run any other workloads, or, even better, run them yourself and report here. >> >> ### Testing >> - [x] tier1 (x86_64, aarch64, x86_32) >> - [x] tier2 (x86_64, aarch64) >> - [x] tier3 (x86_64, aarch64) >> - [x] tier4 (x86_64, aarch64) >> - [x] jcstress 3-days -t sync -af GLOBAL (x86_64, aarch64) > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge remote-tracking branch 'upstream/master' into fast-locking > - Merge remote-tracking branch 'upstream/master' into fast-locking > - Merge remote-tracking branch 'upstream/master' into fast-locking > - More RISC-V fixes > - Merge remote-tracking branch 'origin/fast-locking' into fast-locking > - RISC-V port > - Revert "Re-use r0 in call to unlock_object()" > > This reverts commit ebbcb615a788998596f403b47b72cf133cb9de46. > - Merge remote-tracking branch 'origin/fast-locking' into fast-locking > - Fix number of rt args to complete_monitor_locking_C, remove some comments > - Re-use r0 in call to unlock_object() > - ... and 27 more: https://git.openjdk.org/jdk/compare/4b89fce0...3f0acba4 Closing this in favour of #10907. ------------- PR: https://git.openjdk.org/jdk/pull/10590 From rkennke at openjdk.org Wed Dec 14 15:47:01 2022 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 14 Dec 2022 15:47:01 GMT Subject: Withdrawn: 8291555: Replace stack-locking with fast-locking In-Reply-To: References: Message-ID: On Thu, 6 Oct 2022 10:23:04 GMT, Roman Kennke wrote: > This change replaces the current stack-locking implementation with a fast-locking scheme that retains the advantages of stack-locking (namely fast locking in uncontended code-paths), while avoiding the overload of the mark word. That overloading causes massive problems with Lilliput, because it means we have to check and deal with this situation. And because of the very racy nature, this turns out to be very complex and involved a variant of the inflation protocol to ensure that the object header is stable. > > What the original stack-locking does is basically to push a stack-lock onto the stack which consists only of the displaced header, and CAS a pointer to this stack location into the object header (the lowest two header bits being 00 indicate 'stack-locked'). The pointer into the stack can then be used to identify which thread currently owns the lock. > > This change basically reverses stack-locking: It still CASes the lowest two header bits to 00 to indicate 'fast-locked' but does *not* overload the upper bits with a stack-pointer. Instead, it pushes the object-reference to a thread-local lock-stack. This is a new structure which is basically a small array of oops that is associated with each thread. Experience shows that this array typcially remains very small (3-5 elements). Using this lock stack, it is possible to query which threads own which locks. Most importantly, the most common question 'does the current thread own me?' is very quickly answered by doing a quick scan of the array. More complex queries like 'which thread owns X?' are not performed in very performance-critical paths (usually in code like JVMTI or deadlock detection) where it is ok to do more complex operations. The lock-stack is also a new set of GC roots, and would be scanned during thread scanning, possibly concurrently, via the normal protocols. > > In contrast to stack-locking, fast-locking does *not* support recursive locking (yet). When that happens, the fast-lock gets inflated to a full monitor. It is not clear if it is worth to add support for recursive fast-locking. > > One trouble is that when a contending thread arrives at a fast-locked object, it must inflate the fast-lock to a full monitor. Normally, we need to know the current owning thread, and record that in the monitor, so that the contending thread can wait for the current owner to properly exit the monitor. However, fast-locking doesn't have this information. What we do instead is to record a special marker ANONYMOUS_OWNER. When the thread that currently holds the lock arrives at monitorexit, and observes ANONYMOUS_OWNER, it knows it must be itself, fixes the owner to be itself, and then properly exits the monitor, and thus handing over to the contending thread. > > As an alternative, I considered to remove stack-locking altogether, and only use heavy monitors. In most workloads this did not show measurable regressions. However, in a few workloads, I have observed severe regressions. All of them have been using old synchronized Java collections (Vector, Stack), StringBuffer or similar code. The combination of two conditions leads to regressions without stack- or fast-locking: 1. The workload synchronizes on uncontended locks (e.g. single-threaded use of Vector or StringBuffer) and 2. The workload churns such locks. IOW, uncontended use of Vector, StringBuffer, etc as such is ok, but creating lots of such single-use, single-threaded-locked objects leads to massive ObjectMonitor churn, which can lead to a significant performance impact. But alas, such code exists, and we probably don't want to punish it if we can avoid it. > > This change enables to simplify (and speed-up!) a lot of code: > > - The inflation protocol is no longer necessary: we can directly CAS the (tagged) ObjectMonitor pointer to the object header. > - Accessing the hashcode could now be done in the fastpath always, if the hashcode has been installed. Fast-locked headers can be used directly, for monitor-locked objects we can easily reach-through to the displaced header. This is safe because Java threads participate in monitor deflation protocol. This would be implemented in a separate PR > > ### Benchmarks > > All benchmarks are run on server-class metal machines. The JVM settings are always: `-Xmx20g -Xms20g -XX:+UseParallelGC`. All benchmarks are ms/ops, less is better. > > #### DaCapo/AArch64 > > Those measurements have been taken on a Graviton2 box with 64 CPU cores (an AWS m6g.metal instance). It is using DaCapo evaluation version, git hash 309e1fa (download file dacapo-evaluation-git+309e1fa.jar). I needed to exclude cassandra, h2o & kafka benchmarks because of incompatibility with JDK20. Benchmarks that showed results far off the baseline or showed high variance have been repeated and I am reporting results with the most bias *against* fast-locking. The sunflow benchmark is really far off the mark - the baseline run with stack-locking exhibited very high run-to-run variance and generally much worse performance, while with fast-locking the variance was very low and the results very stable between runs. I wouldn't trust that benchmark - I mean what is it actually doing that a change in locking shows >30% perf difference? > > benchmark | baseline | fast-locking | % | size > -- | -- | -- | -- | -- > avrora | 27859 | 27563 | 1.07% | large > batik | 20786 | 20847 | -0.29% | large > biojava | 27421 | 27334 | 0.32% | default > eclipse | 59918 | 60522 | -1.00% | large > fop | 3670 | 3678 | -0.22% | default > graphchi | 2088 | 2060 | 1.36% | default > h2 | 297391 | 291292 | 2.09% | huge > jme | 8762 | 8877 | -1.30% | default > jython | 18938 | 18878 | 0.32% | default > luindex | 1339 | 1325 | 1.06% | default > lusearch | 918 | 936 | -1.92% | default > pmd | 58291 | 58423 | -0.23% | large > sunflow | 32617 | 24961 | 30.67% | large > tomcat | 25481 | 25992 | -1.97% | large > tradebeans | 314640 | 311706 | 0.94% | huge > tradesoap | 107473 | 110246 | -2.52% | huge > xalan | 6047 | 5882 | 2.81% | default > zxing | 970 | 926 | 4.75% | default > > #### DaCapo/x86_64 > > The following measurements have been taken on an Intel Xeon Scalable Processors (Cascade Lake 8252C) (an AWS m5zn.metal instance). All the same settings and considerations as in the measurements above. > > benchmark | baseline | fast-Locking | % | size > -- | -- | -- | -- | -- > avrora | 127690 | 126749 | 0.74% | large > batik | 12736 | 12641 | 0.75% | large > biojava | 15423 | 15404 | 0.12% | default > eclipse | 41174 | 41498 | -0.78% | large > fop | 2184 | 2172 | 0.55% | default > graphchi | 1579 | 1560 | 1.22% | default > h2 | 227614 | 230040 | -1.05% | huge > jme | 8591 | 8398 | 2.30% | default > jython | 13473 | 13356 | 0.88% | default > luindex | 824 | 813 | 1.35% | default > lusearch | 962 | 968 | -0.62% | default > pmd | 40827 | 39654 | 2.96% | large > sunflow | 53362 | 43475 | 22.74% | large > tomcat | 27549 | 28029 | -1.71% | large > tradebeans | 190757 | 190994 | -0.12% | huge > tradesoap | 68099 | 67934 | 0.24% | huge > xalan | 7969 | 8178 | -2.56% | default > zxing | 1176 | 1148 | 2.44% | default > > #### Renaissance/AArch64 > > This tests Renaissance/JMH version 0.14.1 on same machines as DaCapo above, with same JVM settings. > > benchmark | baseline | fast-locking | % > -- | -- | -- | -- > AkkaUct | 2558.832 | 2513.594 | 1.80% > Reactors | 14715.626 | 14311.246 | 2.83% > Als | 1851.485 | 1869.622 | -0.97% > ChiSquare | 1007.788 | 1003.165 | 0.46% > GaussMix | 1157.491 | 1149.969 | 0.65% > LogRegression | 717.772 | 733.576 | -2.15% > MovieLens | 7916.181 | 8002.226 | -1.08% > NaiveBayes | 395.296 | 386.611 | 2.25% > PageRank | 4294.939 | 4346.333 | -1.18% > FjKmeans | 496.076 | 493.873 | 0.45% > FutureGenetic | 2578.504 | 2589.255 | -0.42% > Mnemonics | 4898.886 | 4903.689 | -0.10% > ParMnemonics | 4260.507 | 4210.121 | 1.20% > Scrabble | 139.37 | 138.312 | 0.76% > RxScrabble | 320.114 | 322.651 | -0.79% > Dotty | 1056.543 | 1068.492 | -1.12% > ScalaDoku | 3443.117 | 3449.477 | -0.18% > ScalaKmeans | 259.384 | 258.648 | 0.28% > Philosophers | 24333.311 | 23438.22 | 3.82% > ScalaStmBench7 | 1102.43 | 1115.142 | -1.14% > FinagleChirper | 6814.192 | 6853.38 | -0.57% > FinagleHttp | 4762.902 | 4807.564 | -0.93% > > #### Renaissance/x86_64 > > benchmark | baseline | fast-locking | % > -- | -- | -- | -- > AkkaUct | 1117.185 | 1116.425 | 0.07% > Reactors | 11561.354 | 11812.499 | -2.13% > Als | 1580.838 | 1575.318 | 0.35% > ChiSquare | 459.601 | 467.109 | -1.61% > GaussMix | 705.944 | 685.595 | 2.97% > LogRegression | 659.944 | 656.428 | 0.54% > MovieLens | 7434.303 | 7592.271 | -2.08% > NaiveBayes | 413.482 | 417.369 | -0.93% > PageRank | 3259.233 | 3276.589 | -0.53% > FjKmeans | 946.429 | 938.991 | 0.79% > FutureGenetic | 1760.672 | 1815.272 | -3.01% > ParMnemonics | 2016.917 | 2033.101 | -0.80% > Scrabble | 147.996 | 150.084 | -1.39% > RxScrabble | 177.755 | 177.956 | -0.11% > Dotty | 673.754 | 683.919 | -1.49% > ScalaDoku | 2193.562 | 1958.419 | 12.01% > ScalaKmeans | 165.376 | 168.925 | -2.10% > ScalaStmBench7 | 1080.187 | 1049.184 | 2.95% > Philosophers | 14268.449 | 13308.87 | 7.21% > FinagleChirper | 4722.13 | 4688.3 | 0.72% > FinagleHttp | 3497.241 | 3605.118 | -2.99% > > Some renaissance benchmarks are missing: DecTree, DbShootout and Neo4jAnalytics are not compatible with JDK20. The remaining benchmarks show very high run-to-run variance, which I am investigating (and probably addressing with running them much more often. > > I have also run another benchmark, which is a popular Java JVM benchmark, with workloads wrapped in JMH and very slightly modified to run with newer JDKs, but I won't publish the results because I am not sure about the licensing terms. They look similar to the measurements above (i.e. +/- 2%, nothing very suspicious). > > Please let me know if you want me to run any other workloads, or, even better, run them yourself and report here. > > ### Testing > - [x] tier1 (x86_64, aarch64, x86_32) > - [x] tier2 (x86_64, aarch64) > - [x] tier3 (x86_64, aarch64) > - [x] tier4 (x86_64, aarch64) > - [x] jcstress 3-days -t sync -af GLOBAL (x86_64, aarch64) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/10590 From cjplummer at openjdk.org Wed Dec 14 17:56:09 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Dec 2022 17:56:09 GMT Subject: RFR: 8298692: Fix typos in test/jdk/com/sun/jdi files In-Reply-To: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> References: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> Message-ID: <2ucUetbbmo9z9ig2mpwX85nZXCnIbxMBSpPyn19HbjY=.6a4a346a-2941-4636-a543-4ef9530769dd@github.com> On Tue, 13 Dec 2022 19:16:41 GMT, Chris Plummer wrote: > These are the typos from #10029 that relate to test/jdk/com/sun/jdi. Thanks Alex and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/11656 From cjplummer at openjdk.org Wed Dec 14 17:56:09 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Dec 2022 17:56:09 GMT Subject: Integrated: 8298692: Fix typos in test/jdk/com/sun/jdi files In-Reply-To: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> References: <_OwnCJbSBKjhxsce2jbEagv7kStL9WH8G823w2QVFjQ=.9de759cd-9c92-45f8-a639-682517b66512@github.com> Message-ID: <7Us_5lewXos8pzy437GDeptahIxdjMJIh7STTxgL9Vc=.6f8aa102-63ae-4e87-8f0d-6b947896a7e6@github.com> On Tue, 13 Dec 2022 19:16:41 GMT, Chris Plummer wrote: > These are the typos from #10029 that relate to test/jdk/com/sun/jdi. This pull request has now been integrated. Changeset: 7241e358 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/7241e358bfbb004897b84da3c154d7bdd96cb560 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod 8298692: Fix typos in test/jdk/com/sun/jdi files Reviewed-by: amenkov, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11656 From cjplummer at openjdk.org Wed Dec 14 18:01:12 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Dec 2022 18:01:12 GMT Subject: RFR: 8298701: Cleanup SA entries in ProblemList-zgc.txt. Message-ID: The following ProblemList-zgc.txt entries need a lot of cleanup. serviceability/sa/ClhsdbCDSCore.java 8268722 macosx-x64 serviceability/sa/ClhsdbFindPC.java#xcomp-core 8268722,8284045 macosx-x64,generic-all serviceability/sa/ClhsdbFindPC.java#no-xcomp-core 8268722 macosx-x64 serviceability/sa/ClhsdbFindPC.java#xcomp-process 8276402 generic-all serviceability/sa/ClhsdbJstack.java#id0 8276402 generic-all serviceability/sa/ClhsdbPmap.java#core 8268722 macosx-x64 serviceability/sa/ClhsdbPstack.java#core 8268722 macosx-x64 serviceability/sa/TestJmapCore.java 8268722,8268283,8270202 macosx-x64,linux-aarch64,linux-x64 serviceability/sa/TestJmapCoreMetaspace.java 8268722,8268636 generic-all [JDK-8268722](https://bugs.openjdk.org/browse/JDK-8268722) entries can be removed. It was closed as WNF. It doesn't really impact macosx-aarch64 (core files are reasonably small there), and on macosx-x64 all these core file tests are (probably indefinitely) problem listed for other reasons in the main problem list, so no need to problem list them here with a closed CR. [JDK-8276402](https://bugs.openjdk.org/browse/JDK-8276402) has been closed as dup of a bug that is now fixed. Lastly, TestJmapCore.java does fail on macosx-aarch64 due to [JDK-8268283](https://bugs.openjdk.org/browse/JDK-8268283), so its problem list entry needs to be updated to reflect that. ------------- Commit messages: - Undo changes to TEST.groups - Cleanup SA entries in zgc problem list. Changes: https://git.openjdk.org/jdk/pull/11658/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11658&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298701 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/11658.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11658/head:pull/11658 PR: https://git.openjdk.org/jdk/pull/11658 From cjplummer at openjdk.org Wed Dec 14 19:38:07 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Dec 2022 19:38:07 GMT Subject: RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2] In-Reply-To: References: Message-ID: On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer wrote: >> 3 things to cleanup in this area: >> >> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: >> >> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` >> >> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. >> >> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. >> >> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of some structs and statics that are no longer needed. I'm going to stick with my change to use JVMTI_VERSION rather than JVMTI_VERSION_1. It seems that the agent really should be asking for the version it needs, not asking for a lesser version. Although the error message might not be as good if someone does placement of the debug agent into a different JDK build, no one should be doing this in the first place, and the resulting error message is still appropriate. Thanks for the reviews Alan, Serguei, and Alex! ------------- PR: https://git.openjdk.org/jdk/pull/11602 From cjplummer at openjdk.org Wed Dec 14 19:42:12 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 Dec 2022 19:42:12 GMT Subject: Integrated: 8287812: Cleanup JDWP agent GetEnv initialization In-Reply-To: References: Message-ID: On Thu, 8 Dec 2022 22:40:57 GMT, Chris Plummer wrote: > 3 things to cleanup in this area: > > (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this: > > `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3` > > The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now. > > (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version. > > (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed. This pull request has now been integrated. Changeset: ccb94acc Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/ccb94acc442767a7047756806c8dc7ecacd8bae9 Stats: 77 lines in 2 files changed: 11 ins; 61 del; 5 mod 8287812: Cleanup JDWP agent GetEnv initialization Reviewed-by: alanb, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11602 From dholmes at openjdk.org Wed Dec 14 22:31:55 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 Dec 2022 22:31:55 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast Message-ID: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. A couple of reinterpret_cast are needed when doing int/ptr conversion. static_cast is used for void* conversion. The other changes should be self explanatory. The changes in src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. I grep'd as best I could for the old C-style casts but can't be certain I got them all. Testing: - all builds in our tiers1-5 - local linux x64 product, slowdebug and fastdebug - GHA (TBD) - Sanity testing tiers 1-3 Thanks. ------------- Commit messages: - 8298241: Replace C-style casts with JavaThread::cast Changes: https://git.openjdk.org/jdk/pull/11682/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11682&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298241 Stats: 44 lines in 19 files changed: 0 ins; 11 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/11682.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11682/head:pull/11682 PR: https://git.openjdk.org/jdk/pull/11682 From coleenp at openjdk.org Wed Dec 14 23:16:04 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 14 Dec 2022 23:16:04 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes wrote: > This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. > > In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. > > A couple of reinterpret_cast are needed when doing int/ptr conversion. > > static_cast is used for void* conversion. > > The other changes should be self explanatory. > > The changes in > > src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp > src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp > > are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. > > I grep'd as best I could for the old C-style casts but can't be certain I got them all. > > Testing: > - all builds in our tiers1-5 > - local linux x64 product, slowdebug and fastdebug > - GHA (TBD) > - Sanity testing tiers 1-3 > Thanks. Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk/pull/11682 From dnguyen at openjdk.org Wed Dec 14 23:47:55 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 14 Dec 2022 23:47:55 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 Message-ID: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Open l10n drop All tests passed ------------- Commit messages: - open l10n drop Changes: https://git.openjdk.org/jdk20/pull/35/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298133 Stats: 1177 lines in 110 files changed: 783 ins; 207 del; 187 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From achung at openjdk.org Thu Dec 15 00:07:04 2022 From: achung at openjdk.org (Alisen Chung) Date: Thu, 15 Dec 2022 00:07:04 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed looks good ------------- Marked as reviewed by achung (Committer). PR: https://git.openjdk.org/jdk20/pull/35 From duke at openjdk.org Thu Dec 15 01:01:05 2022 From: duke at openjdk.org (Justin Lu) Date: Thu, 15 Dec 2022 01:01:05 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: > 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 > 187: > 188: main.plugin.category=\u7C7B\u522B As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From duke at openjdk.org Thu Dec 15 01:07:14 2022 From: duke at openjdk.org (Justin Lu) Date: Thu, 15 Dec 2022 01:07:14 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26: > 24: # > 25: > 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From duke at openjdk.org Thu Dec 15 01:16:13 2022 From: duke at openjdk.org (Justin Lu) Date: Thu, 15 Dec 2022 01:16:13 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 00:58:06 GMT, Justin Lu wrote: >> Open l10n drop >> All tests passed > > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: > >> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 >> 187: >> 188: main.plugin.category=\u7C7B\u522B > > As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes. Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dholmes at openjdk.org Thu Dec 15 01:41:04 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Dec 2022 01:41:04 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast In-Reply-To: References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Wed, 14 Dec 2022 23:13:30 GMT, Coleen Phillimore wrote: >> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. >> >> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. >> >> A couple of reinterpret_cast are needed when doing int/ptr conversion. >> >> static_cast is used for void* conversion. >> >> The other changes should be self explanatory. >> >> The changes in >> >> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp >> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp >> >> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. >> >> I grep'd as best I could for the old C-style casts but can't be certain I got them all. >> >> Testing: >> - all builds in our tiers1-5 >> - local linux x64 product, slowdebug and fastdebug >> - GHA >> - Sanity testing tiers 1-3 >> Thanks. > > Looks good! Thanks @coleenp ! ------------- PR: https://git.openjdk.org/jdk/pull/11682 From dholmes at openjdk.org Thu Dec 15 01:56:09 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Dec 2022 01:56:09 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: <31ZthS6SqGpb-qVWc9EOZFk0x2KYf16KDL5hecw8HmY=.b1ee5b8e-1be0-4c20-bb33-c68d7202d0b2@github.com> On Wed, 14 Dec 2022 13:28:02 GMT, Afshin Zafari wrote: >> src/hotspot/share/prims/jvmtiTagMap.cpp line 1262: >> >>> 1260: // and record the reference and tag value. >>> 1261: // >>> 1262: bool do_entry(JvmtiTagMapKey& key, jlong& value) { >> >> I still see no point in this method returning a bool when it only ever returns true. > > In the `iterate` method of ResourceHashTable, in respurceHash.hpp lines 227-240 copied here, requires a function that returns boolean. If returned false the iterate will break. > > template > void iterate(Function function) const { // lambda enabled API > Node* const* bucket = table(); > const unsigned sz = table_size(); > while (bucket < bucket_at(sz)) { > Node* node = *bucket; > while (node != NULL) { > bool cont = function(node->_key, node->_value); // <--------------****** > if (!cont) { return; } > node = node->_next; > } > ++bucket; > } > } > > The other `iterate` methods are wrappers around this one. > Always returning true means to continue iterating over all the existing items. > The former base table for jvmtiTagMapTable needs the `do_entry` be `void`. Okay in that case please add to the comment preceding this method: // Always return true so the iteration continues. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dholmes at openjdk.org Thu Dec 15 02:00:13 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Dec 2022 02:00:13 GMT Subject: RFR: 8292741: Convert JvmtiTagMapTable to ResourceHashtable [v7] In-Reply-To: References: Message-ID: On Wed, 14 Dec 2022 15:11:55 GMT, Afshin Zafari wrote: >> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 114: >> >>> 112: JvmtiTagMapKey new_entry(obj); >>> 113: bool is_updated = _table.put(new_entry, tag) == false; >>> 114: assert(is_updated, "should be updated and not added"); >> >> This API is confusing. You have `add` and `replace` but in product mode an `add` can `replace` and a `replace` can `add`. It isn't clear if these should be allowed rare conditions or fatal errors. > > I agree that this is ambigious. The `jvmtiTagMap` calls `add/update` methods of `jvmtiTagMapTable` which in turn calls `resourceHashTable` methods `put` and `put_if_absent`. > `put` and `put_if_absent` can be used for both adding and updating and reporting it in returned values. > `jvmtiTagMap` calls to `jvmtiTagMapTable` add/update DO NOT CARE about the returned values. For these calls, it doesn't mater if an add (update) method resulted in an update (add). > So which one of the following cases would be correct? > - Based on the `jvmtiTagMap` calls, let the add/update be void and ignore the differences of what really happens in the table. Or > - Based on the `resourceHashTable` bool-valued `put` and `put_if_absent` methods, let the add/update be bool-values and leave the decision on "what really happened in the table" to the callers in `jvmtiTagMap`. (current implementation) The issue is not the underlying RHT methods but the semantics of the `jvmtiTagMap` methods. If a call to add always expects to add then it should be a fatal error if it actually did an update as that indicates something is broken. Similarly if an update actually does an add. ------------- PR: https://git.openjdk.org/jdk/pull/11288 From dnguyen at openjdk.org Thu Dec 15 02:26:12 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 02:26:12 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 01:04:12 GMT, Justin Lu wrote: >> Open l10n drop >> All tests passed > > src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26: > >> 24: # >> 25: >> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten > > `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now? I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19. I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated. And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 02:45:48 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 02:45:48 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Removed trailing whitespace ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/39511b7a..54d2ec5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From stefank at openjdk.org Thu Dec 15 07:11:06 2022 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 15 Dec 2022 07:11:06 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes wrote: > This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. > > In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. > > A couple of reinterpret_cast are needed when doing int/ptr conversion. > > static_cast is used for void* conversion. > > The other changes should be self explanatory. > > The changes in > > src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp > src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp > > are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. > > I grep'd as best I could for the old C-style casts but can't be certain I got them all. > > Testing: > - all builds in our tiers1-5 > - local linux x64 product, slowdebug and fastdebug > - GHA > - Sanity testing tiers 1-3 > Thanks. Marked as reviewed by stefank (Reviewer). src/hotspot/share/runtime/frame.cpp line 1568: > 1566: } > 1567: } > 1568: // if (error) { tty->cr(); print_on(nullptr, tty); } This probably need the same cast as in print_frame_layout, to disambiguate the call. ------------- PR: https://git.openjdk.org/jdk/pull/11682 From sspitsyn at openjdk.org Thu Dec 15 08:51:05 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Dec 2022 08:51:05 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: <4SiC0hWeVuGEwNx0no014TsccBFSzbaX9KHmCCXyEb8=.00a0e52d-f928-4c78-a4d6-dab85428ea2f@github.com> On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes wrote: > This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. > > In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. > > A couple of reinterpret_cast are needed when doing int/ptr conversion. > > static_cast is used for void* conversion. > > The other changes should be self explanatory. > > The changes in > > src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp > src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp > > are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. > > I grep'd as best I could for the old C-style casts but can't be certain I got them all. > > Testing: > - all builds in our tiers1-5 > - local linux x64 product, slowdebug and fastdebug > - GHA > - Sanity testing tiers 1-3 > Thanks. Looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11682 From sspitsyn at openjdk.org Thu Dec 15 08:56:05 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Dec 2022 08:56:05 GMT Subject: RFR: 8298701: Cleanup SA entries in ProblemList-zgc.txt. In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 22:34:06 GMT, Chris Plummer wrote: > The following ProblemList-zgc.txt entries need a lot of cleanup. > > serviceability/sa/ClhsdbCDSCore.java 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-core 8268722,8284045 macosx-x64,generic-all > serviceability/sa/ClhsdbFindPC.java#no-xcomp-core 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-process 8276402 generic-all > serviceability/sa/ClhsdbJstack.java#id0 8276402 generic-all > serviceability/sa/ClhsdbPmap.java#core 8268722 macosx-x64 > serviceability/sa/ClhsdbPstack.java#core 8268722 macosx-x64 > serviceability/sa/TestJmapCore.java 8268722,8268283,8270202 macosx-x64,linux-aarch64,linux-x64 > serviceability/sa/TestJmapCoreMetaspace.java 8268722,8268636 generic-all > > [JDK-8268722](https://bugs.openjdk.org/browse/JDK-8268722) entries can be removed. It was closed as WNF. It doesn't really impact macosx-aarch64 (core files are reasonably small there), and on macosx-x64 all these core file tests are (probably indefinitely) problem listed for other reasons in the main problem list, so no need to problem list them here with a closed CR. > > [JDK-8276402](https://bugs.openjdk.org/browse/JDK-8276402) has been closed as dup of a bug that is now fixed. > > Lastly, TestJmapCore.java does fail on macosx-aarch64 due to [JDK-8268283](https://bugs.openjdk.org/browse/JDK-8268283), so its problem list entry needs to be updated to reflect that. Marked as reviewed by sspitsyn (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11658 From dnguyen at openjdk.org Thu Dec 15 12:06:10 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 12:06:10 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 01:13:32 GMT, Justin Lu wrote: >> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_zh_CN.properties line 188: >> >>> 186: main.plugin.module=\u63D2\u4EF6\u6A21\u5757 >>> 187: >>> 188: main.plugin.category=\u7C7B\u522B >> >> As Naoto pointed out, it looks like a trailing space was added by accident. This is also done in the ja version but for a different value. And no space was added for any value for the de version. It looks like the translation drop that Damon is receiving contains random changes. > > Additionally, there were changes made to plugins.properties in October that were not translated in the translation drop In our discussion, Kate mentioned that some languages are double byte, so this extra space may be correct but she hasn't looked in detail yet. I looked through all of the changes and these two instances of trailing whitespaces were the only two. I removed the extra spaces to reduce the changes as it seems useless due to the previous version not having the whitespace. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From sspitsyn at openjdk.org Thu Dec 15 12:09:09 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 Dec 2022 12:09:09 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions Message-ID: Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. Testing: mach5 jobs are TBD: - all JVMTI, JDWP, JDI and JDB tests have to be run - Kitchensink - tier5 ------------- Commit messages: - fix trailing white spaces in javaClasses.cpp and jvmtiThreadState.cpp - 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions Changes: https://git.openjdk.org/jdk/pull/11690/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298853 Stats: 161 lines in 7 files changed: 110 ins; 2 del; 49 mod Patch: https://git.openjdk.org/jdk/pull/11690.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690 PR: https://git.openjdk.org/jdk/pull/11690 From dnguyen at openjdk.org Thu Dec 15 18:54:09 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 18:54:09 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 02:23:34 GMT, Damon Nguyen wrote: >> src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_de.properties line 26: >> >>> 24: # >>> 25: >>> 26: jmod.description=JMOD-Dateien erstellen und den Inhalt vorhandener JMOD-Dateien auflisten >> >> `jlink.description` was added to `jmod.properties` in May 2022 (Which was before Alisen's drop for JDK19). Shouldn't this have been translated during the 19 drop in August, as opposed to showing up now? > > I see the date of [that PR](https://github.com/openjdk/jdk/pull/8772) as well. Looks like it was integrated on May 19. > > I'm contacting Kate Gavin to determine why some translations seem to sometimes be delayed. As you mentioned in the other comment, there are a few instances where text was added between the last drop & this drop, but weren't translated. > > And as you showed here, this should have been translated in the last drop rather than this one, but showed up here. I need a response from Kate to clarify when these translations are generated. I conversed with Kate and the problem seems to come from the extraction process. We went through the source files that were sent for translation as a zip, and some changes would be missing. We confirmed that everything in this zip was translated, so the issue was in the extraction to create the source files to send for translation. For example, the plugin.properties missing text didn't show in the source.zip but showed on my forked repo used in the extraction. I re-ran the extraction script but still did not see the new text in the generated zip. Kate thinks a similar issue occurred in the previous drop and this jmod.properties change wasn't captured in the extraction process. So now it is captured in this drop and translated here. It could be syncing or branch issues, but while working with Kate, I learned to better see what files are pulled from the extraction script. So for future drops, I can better check to make sure changes I expect to be translated will appear. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From naoto at openjdk.org Thu Dec 15 18:58:09 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Dec 2022 18:58:09 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 02:45:48 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Removed trailing whitespace Changes requested by naoto (Reviewer). src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 217: > 215: javac.msg.usage.nonstandard.footer=Diese zus\u00E4tzlichen Optionen k\u00F6nnen jederzeit ohne vorherige Ank\u00FCndigung ge\u00E4ndert werden. > 216: > 217: javac.msg.bug=Im Compiler ({0}) ist eine Ausnahme aufgetreten. Erstellen Sie auf der Java-Seite zum Melden von Bugs (http://bugreport.java.com) einen Bugbericht, nachdem Sie die Bugdatenbank (http://bugs.java.com) auf Duplikate gepr\u00FCft haben. Geben Sie in Ihrem Bericht Ihr Programm, die folgende Diagnose und die Parameter an, die Sie dem Java-Compiler \u00FCbergeben haben. Vielen Dank. How come `https` turned into `http`? I see these happening all over the places other than this location as well. src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134: > 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung > 133: artifact.not.found=nicht gefunden > 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 20:43:42 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 20:43:42 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Fix https and changed URL back ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/54d2ec5f..09140a05 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=01-02 Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Thu Dec 15 20:55:08 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 20:55:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 18:52:45 GMT, Naoto Sato wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed trailing whitespace > > src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdeps_de.properties line 134: > >> 132: public.api.replacement.column.header=Vorgeschlagene Ersetzung >> 133: artifact.not.found=nicht gefunden >> 134: jdeps.wiki.url=https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool > > This seems to change backward. `openjdk.java.net` has changed to `openjdk.org` Same issues are observed in other locales. This and the https->http differences seem to also be a part of the extraction issue. The resource generation files show "http" and "java.net", but I see differently on my local repo that I used for the extraction. I will run a new extraction job on a fresh repo/branch to see if this issue is reproducible and narrow down the source of the extraction issue. As discussed with Naoto, these are small edits, and they have been addressed in the latest PR. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From naoto at openjdk.org Thu Dec 15 21:16:07 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Dec 2022 21:16:07 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Fix https and changed URL back Thanks for the update, Damon. Looks good for this drop. ------------- Marked as reviewed by naoto (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From dholmes at openjdk.org Thu Dec 15 21:20:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Dec 2022 21:20:31 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2] In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: > This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. > > In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. > > A couple of reinterpret_cast are needed when doing int/ptr conversion. > > static_cast is used for void* conversion. > > The other changes should be self explanatory. > > The changes in > > src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp > src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp > > are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. > > I grep'd as best I could for the old C-style casts but can't be certain I got them all. > > Testing: > - all builds in our tiers1-5 > - local linux x64 product, slowdebug and fastdebug > - GHA > - Sanity testing tiers 1-3 > Thanks. David Holmes has updated the pull request incrementally with one additional commit since the last revision: Fixed commented examle. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11682/files - new: https://git.openjdk.org/jdk/pull/11682/files/5641507a..34f2745d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11682&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11682&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/11682.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11682/head:pull/11682 PR: https://git.openjdk.org/jdk/pull/11682 From dholmes at openjdk.org Thu Dec 15 21:20:31 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Dec 2022 21:20:31 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2] In-Reply-To: References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Thu, 15 Dec 2022 07:07:26 GMT, Stefan Karlsson wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed commented examle. > > Marked as reviewed by stefank (Reviewer). Thanks for the reviews @stefank and @sspitsyn ! > src/hotspot/share/runtime/frame.cpp line 1568: > >> 1566: } >> 1567: } >> 1568: // if (error) { tty->cr(); print_on(nullptr, tty); } > > This probably need the same cast as in print_frame_layout, to disambiguate the call. Fixed ------------- PR: https://git.openjdk.org/jdk/pull/11682 From dholmes at openjdk.org Thu Dec 15 21:20:32 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 Dec 2022 21:20:32 GMT Subject: Integrated: 8298241: Replace C-style casts with JavaThread::cast In-Reply-To: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Wed, 14 Dec 2022 22:22:48 GMT, David Holmes wrote: > This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. > > In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. > > A couple of reinterpret_cast are needed when doing int/ptr conversion. > > static_cast is used for void* conversion. > > The other changes should be self explanatory. > > The changes in > > src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp > src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp > > are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. > > I grep'd as best I could for the old C-style casts but can't be certain I got them all. > > Testing: > - all builds in our tiers1-5 > - local linux x64 product, slowdebug and fastdebug > - GHA > - Sanity testing tiers 1-3 > Thanks. This pull request has now been integrated. Changeset: 3cdbd878 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/3cdbd878e68dc1131093137a7357710ad303ae8c Stats: 44 lines in 19 files changed: 0 ins; 11 del; 33 mod 8298241: Replace C-style casts with JavaThread::cast Reviewed-by: coleenp, stefank, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/11682 From dnsimon at openjdk.org Thu Dec 15 22:24:09 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Thu, 15 Dec 2022 22:24:09 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2] In-Reply-To: References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Thu, 15 Dec 2022 21:20:31 GMT, David Holmes wrote: >> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. >> >> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. >> >> A couple of reinterpret_cast are needed when doing int/ptr conversion. >> >> static_cast is used for void* conversion. >> >> The other changes should be self explanatory. >> >> The changes in >> >> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp >> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp >> >> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. >> >> I grep'd as best I could for the old C-style casts but can't be certain I got them all. >> >> Testing: >> - all builds in our tiers1-5 >> - local linux x64 product, slowdebug and fastdebug >> - GHA >> - Sanity testing tiers 1-3 >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed commented examle. Is it possible to add a test based on grep to prevent re-introduction of the unwanted C-style casts? ------------- PR: https://git.openjdk.org/jdk/pull/11682 From dnguyen at openjdk.org Thu Dec 15 23:01:35 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Thu, 15 Dec 2022 23:01:35 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert double quote as well ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/09140a05..57c42206 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From naoto at openjdk.org Thu Dec 15 23:12:06 2022 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Dec 2022 23:12:06 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well Marked as reviewed by naoto (Reviewer). src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/resources/jdeprscan_de.properties line 26: > 24: # > 25: > 26: main.usage=Verwendung: jdeprscan [Optionen] '{dir|jar|class}' ...\n\nOptionen:\n --class-path PATH\n --for-removal\n --full-version\n -? -h --help\n -l --list\n --release {0}\n -v --verbose\n --version Good catch! ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Thu Dec 15 23:17:12 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Dec 2022 23:17:12 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 20:43:42 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Fix https and changed URL back src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82: > 80: > 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0}) > 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""? src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties line 82: > 80: > 81: error.foreign-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306B.jpackage.xml\u30D5\u30A1\u30A4\u30EB\u304C\u3042\u308A\u307E\u305B\u3093 > 82: error.invalid-app-image=\u30A8\u30E9\u30FC: app-image\u30C7\u30A3\u30EC\u30AF\u30C8\u30EA({0})\u306F\u5225\u306Ejpackage\u30D0\u30FC\u30B8\u30E7\u30F3\u307E\u305F\u306F\u4E0D\u6B63\u306A.jpackage.xml\u3067\u751F\u6210\u3055\u308C\u307E\u3057\u305F Same as "de" translation. src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 82: > 80: > 81: error.foreign-app-image=\u9519\u8BEF\uFF1Aapp-image \u76EE\u5F55 ({0}) \u4E2D\u7F3A\u5C11 .jpackage.xml \u6587\u4EF6 > 82: error.invalid-app-image=\u9519\u8BEF\uFF1A\u53E6\u4E00\u4E2A jpackage \u7248\u672C\u6216\u683C\u5F0F\u9519\u8BEF\u7684 .jpackage.xml \u751F\u6210\u4E86 app-image \u76EE\u5F55 ({0}) Same as "de" translation. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: > 1: > 2: Why "de-de" was changed to "de"? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 2: > 1: > 2: Why "ja-jp" to "ja"? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 37: > 35: resource.post-app-image-script=Auszuf\u00FChrendes Skript nach dem Auff\u00FCllen des Anwendungsimages > 36: resource.post-msi-script=Auszuf\u00FChrendes Skript nach dem Erstellen der MSI-Datei f\u00FCr das EXE-Installationsprogramm > 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl Why this was changed? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37: > 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 > 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 > 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl Why this was changed? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties line 37: > 35: resource.post-app-image-script=\u8981\u5728\u586B\u5145\u5E94\u7528\u7A0B\u5E8F\u6620\u50CF\u4E4B\u540E\u8FD0\u884C\u7684\u811A\u672C > 36: resource.post-msi-script=\u5728\u4E3A exe \u5B89\u88C5\u7A0B\u5E8F\u521B\u5EFA msi \u6587\u4EF6\u4E4B\u540E\u8981\u8FD0\u884C\u7684\u811A\u672C > 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl Same as above. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Thu Dec 15 23:17:15 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Dec 2022 23:17:15 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_ja.wxl line 15: > 13: ???????????????????? > 14: [ProductName]?????? > 15: Open with [ProductName] Why it was removed in all translations, except English? src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51: > 49: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen > 50: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden > 51: error.icon-swap=Failed to update icon for {0} Why this was removed? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dcubed at openjdk.org Thu Dec 15 23:29:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Dec 2022 23:29:45 GMT Subject: [jdk20] RFR: 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx Message-ID: A batch of trivial fixes to ProblemList tests: [JDK-8298888](https://bugs.openjdk.org/browse/JDK-8298888) ProblemList gc/g1/TestVerifyGCType.java on linux and macosx [JDK-8298889](https://bugs.openjdk.org/browse/JDK-8298889) ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux [JDK-8298891](https://bugs.openjdk.org/browse/JDK-8298891) ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC [JDK-8298892](https://bugs.openjdk.org/browse/JDK-8298892) ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC ------------- Commit messages: - 8298892: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC - 8298891: ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC - 8298889: ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux - 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx Changes: https://git.openjdk.org/jdk20/pull/42/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=42&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298888 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk20/pull/42.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/42/head:pull/42 PR: https://git.openjdk.org/jdk20/pull/42 From bpb at openjdk.org Thu Dec 15 23:29:45 2022 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 15 Dec 2022 23:29:45 GMT Subject: [jdk20] RFR: 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 23:13:30 GMT, Daniel D. Daugherty wrote: > A batch of trivial fixes to ProblemList tests: > > [JDK-8298888](https://bugs.openjdk.org/browse/JDK-8298888) ProblemList gc/g1/TestVerifyGCType.java on linux and macosx > [JDK-8298889](https://bugs.openjdk.org/browse/JDK-8298889) ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux > [JDK-8298891](https://bugs.openjdk.org/browse/JDK-8298891) ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC > [JDK-8298892](https://bugs.openjdk.org/browse/JDK-8298892) > ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC Marked as reviewed by bpb (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/42 From lmesnik at openjdk.org Thu Dec 15 23:29:45 2022 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Dec 2022 23:29:45 GMT Subject: [jdk20] RFR: 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 23:13:30 GMT, Daniel D. Daugherty wrote: > A batch of trivial fixes to ProblemList tests: > > [JDK-8298888](https://bugs.openjdk.org/browse/JDK-8298888) ProblemList gc/g1/TestVerifyGCType.java on linux and macosx > [JDK-8298889](https://bugs.openjdk.org/browse/JDK-8298889) ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux > [JDK-8298891](https://bugs.openjdk.org/browse/JDK-8298891) ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC > [JDK-8298892](https://bugs.openjdk.org/browse/JDK-8298892) > ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/42 From dcubed at openjdk.org Thu Dec 15 23:29:45 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Dec 2022 23:29:45 GMT Subject: [jdk20] RFR: 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 23:19:51 GMT, Brian Burkhalter wrote: >> A batch of trivial fixes to ProblemList tests: >> >> [JDK-8298888](https://bugs.openjdk.org/browse/JDK-8298888) ProblemList gc/g1/TestVerifyGCType.java on linux and macosx >> [JDK-8298889](https://bugs.openjdk.org/browse/JDK-8298889) ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux >> [JDK-8298891](https://bugs.openjdk.org/browse/JDK-8298891) ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC >> [JDK-8298892](https://bugs.openjdk.org/browse/JDK-8298892) >> ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC > > Marked as reviewed by bpb (Reviewer). @bplb - Thanks for the fast review! I'm now waiting for the bots to catch up... ------------- PR: https://git.openjdk.org/jdk20/pull/42 From weijun at openjdk.org Thu Dec 15 23:34:10 2022 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 15 Dec 2022 23:34:10 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75: > 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey > 74: {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, > 75: {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dcubed at openjdk.org Thu Dec 15 23:38:04 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 15 Dec 2022 23:38:04 GMT Subject: [jdk20] RFR: 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 23:22:15 GMT, Leonid Mesnik wrote: >> A batch of trivial fixes to ProblemList tests: >> >> [JDK-8298888](https://bugs.openjdk.org/browse/JDK-8298888) ProblemList gc/g1/TestVerifyGCType.java on linux and macosx >> [JDK-8298889](https://bugs.openjdk.org/browse/JDK-8298889) ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux >> [JDK-8298891](https://bugs.openjdk.org/browse/JDK-8298891) ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC >> [JDK-8298892](https://bugs.openjdk.org/browse/JDK-8298892) >> ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC > > Marked as reviewed by lmesnik (Reviewer). @lmesnik - Thanks for the fast review! ------------- PR: https://git.openjdk.org/jdk20/pull/42 From dcubed at openjdk.org Fri Dec 16 00:04:05 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 16 Dec 2022 00:04:05 GMT Subject: [jdk20] Integrated: 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 23:13:30 GMT, Daniel D. Daugherty wrote: > A batch of trivial fixes to ProblemList tests: > > [JDK-8298888](https://bugs.openjdk.org/browse/JDK-8298888) ProblemList gc/g1/TestVerifyGCType.java on linux and macosx > [JDK-8298889](https://bugs.openjdk.org/browse/JDK-8298889) ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux > [JDK-8298891](https://bugs.openjdk.org/browse/JDK-8298891) ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC > [JDK-8298892](https://bugs.openjdk.org/browse/JDK-8298892) > ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC This pull request has now been integrated. Changeset: c7d7e7e3 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk20/commit/c7d7e7e3be768b35447d65661ec328204aeb40e4 Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod 8298888: ProblemList gc/g1/TestVerifyGCType.java on linux and macosx 8298889: ProblemList runtime/StackGuardPages/TestStackGuardPages.java on linux 8298891: ProblemList vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java with ZGC 8298892: ProblemList vmTestbase/nsk/sysdict/vm/stress/chain/chain008/chain008.java with ZGC Reviewed-by: bpb, lmesnik ------------- PR: https://git.openjdk.org/jdk20/pull/42 From dnguyen at openjdk.org Fri Dec 16 00:20:09 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 00:20:09 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 22:57:31 GMT, Alexander Matveev wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix https and changed URL back > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82: > >> 80: >> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0}) >> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt > > error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""? I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted? > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: > >> 1: >> 2: > > Why "de-de" was changed to "de"? Also not sure why this was changed in the translation. I'm reverting all instances of these language codes. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 00:28:14 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 00:28:14 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:13:22 GMT, Alexander Matveev wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix https and changed URL back > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37: > >> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl > > Why this was changed? Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Fri Dec 16 00:55:07 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Dec 2022 00:55:07 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:15:51 GMT, Damon Nguyen wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_de.properties line 82: >> >>> 80: >>> 81: error.foreign-app-image=Fehler: .jpackage.xml-Datei fehlt in app-image-Verzeichnis ({0}) >>> 82: error.invalid-app-image=Fehler: app-image-Verzeichnis ({0}) wurde von einer anderen jpackage-Version generiert, oder .jpackage.xml ist nicht wohlgeformt >> >> error.invalid-app-image looks like old translation and missing "{1}". Also, why () is used instead of ""? > > I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted? Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Fri Dec 16 00:59:08 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Dec 2022 00:59:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:24:26 GMT, Damon Nguyen wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties line 37: >> >>> 35: resource.post-app-image-script=\u30A2\u30D7\u30EA\u30B1\u30FC\u30B7\u30E7\u30F3\u30FB\u30A4\u30E1\u30FC\u30B8\u3092\u79FB\u5165\u3057\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >>> 36: resource.post-msi-script=exe\u30A4\u30F3\u30B9\u30C8\u30FC\u30E9\u306Emsi\u30D5\u30A1\u30A4\u30EB\u304C\u4F5C\u6210\u3055\u308C\u305F\u5F8C\u306B\u5B9F\u884C\u3059\u308B\u30B9\u30AF\u30EA\u30D7\u30C8 >>> 37: resource.wxl-file-name=MsiInstallerStrings_en.wxl >> >> Why this was changed? > > Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file. Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 01:05:08 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 01:05:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:51:55 GMT, Alexander Matveev wrote: >> I'm not sure for the decisions of change in punctuation and for the missing {1} as I didn't do the translation myself. Would this be better to be reverted? > > Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old. I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then. >> Also not sure as it is what I received from the latest translation drop. If this is incorrect, I can manually correct this here and for the other locales for this file. > > Yes it needs to be correct. It was changed to _ja, etc with [commit](https://github.com/openjdk/jdk20/commit/543163a03b5f1af7a7e7af317a26eb8c5aa81c38#diff-afb8ea68d8b3e9be4bba1c417c82d2162eea9333a3157f05ef57c026af94eb3b). Which was done on Aug 10, 2022, so it seems message drop is based on old code. This drop had some issues with the extraction which will be resolved. Some of the changes are correct while some seem to be old. It seems these jpackage files were are older? I can revert these changes for jpackage then. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From joehw at openjdk.org Fri Dec 16 01:25:18 2022 From: joehw at openjdk.org (Joe Wang) Date: Fri, 16 Dec 2022 01:25:18 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:01:35 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert double quote as well The changes in the java.xml area look good to me. ------------- Marked as reviewed by joehw (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From dholmes at openjdk.org Fri Dec 16 02:24:07 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Dec 2022 02:24:07 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 11:51:10 GMT, Serguei Spitsyn wrote: > Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. > New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. > > Testing: > mach5 jobs are TBD (preliminary testing was completed): > - all JVMTI, JDWP, JDI and JDB tests have to be run > - Kitchensink > - tier5 Seems logical though I'm not familiar with the existing mechanisms. A few minor comments. Thanks. src/hotspot/share/classfile/javaClasses.cpp line 1745: > 1743: int val = VTMS_transition_disable_count(java_thread); > 1744: java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val - 1); > 1745: } These are not thread-safe functions. What constraints exist for using these methods safely? Update: looks like they must be called with the lock held so we should assert that. Should also assert the count never goes negative (which I assume would be an error?). src/hotspot/share/prims/jvmtiThreadState.cpp line 252: > 250: return; // JvmtiVTMSTransitionDisabler is no-op without virtual threads > 251: } > 252: if (Thread::current_or_null() == NULL) { Nit: please use `nullptr` in new code src/hotspot/share/prims/jvmtiThreadState.cpp line 273: > 271: } > 272: _is_SR = is_SR; > 273: _vthread = NULL; Nit: should initialize in init list src/hotspot/share/prims/jvmtiThreadState.cpp line 298: > 296: HandleMark hm(thread); > 297: Handle vth = Handle(thread, JNIHandles::resolve_external_guard(_vthread)); > 298: if (!java_lang_VirtualThread::is_instance(vth())) { How can this condition not be true? Should it be an assertion? src/hotspot/share/prims/jvmtiThreadState.cpp line 304: > 302: > 303: ThreadBlockInVM tbivm(thread); > 304: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); Aside: this pattern looks very odd. Why not just lock with the safepoint check? ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dnguyen at openjdk.org Fri Dec 16 03:38:54 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:38:54 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert old translation. Fix lang codes ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/57c42206..29880af9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=03-04 Stats: 18 lines in 9 files changed: 6 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:38:56 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:38:56 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <_Dir5hjsOpTXHLKfV6SM_6kUJfNcHSkgHjrRAHbGUfw=.db9fe398-4a22-4aab-90ef-72d67f5c708e@github.com> On Fri, 16 Dec 2022 01:02:03 GMT, Damon Nguyen wrote: >> Looks like translation is done on files before JDK-8293462 was integrated (before Sep 26). See [commit](https://github.com/openjdk/jdk20/commit/1e222bccd3807c1be0d1d824e0ff9745751d8375#diff-8bfeb61c827c2bc073c65cbf4137dbf8f7baa5f4f88e5d59785e985d9510577c) when I changed these two strings. For now it is better to revert them to original English version or figure out why translation is old. > > I'll revert it, investigate the cause for the extraction issue in this drop, and try to have it translated by the next drop then. The translated text here has been reverted to its original English. The same has been done for its locales. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:38:58 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:38:58 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v3] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 00:17:15 GMT, Damon Nguyen wrote: >> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/MsiInstallerStrings_de.wxl line 2: >> >>> 1: >>> 2: >> >> Why "de-de" was changed to "de"? > > Also not sure why this was changed in the translation. I'm reverting all instances of these language codes. This has been reverted as it was a regression for all locales of MsiInstallerStrings.wxl ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:39:01 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:39:01 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v2] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:12:58 GMT, Alexander Matveev wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Removed trailing whitespace > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_de.properties line 51: > >> 49: error.msi-product-version-build-out-of-range=Build-Teil der Version muss im Bereich [0, 65535] liegen >> 50: error.msi-product-version-minor-out-of-range=Nebenversion muss im Bereich [0, 255] liegen >> 51: error.version-swap=Versionsinformationen f\u00FCr {0} konnten nicht aktualisiert werden > > Why this was removed? This line was added back to all locales as it was a regression from the translation process. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:45:07 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:45:07 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Thu, 15 Dec 2022 23:30:52 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert double quote as well > > src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75: > >> 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey >> 74: {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, >> 75: {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, > > The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file. I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 03:58:08 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 03:58:08 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From cjplummer at openjdk.org Fri Dec 16 04:12:17 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Dec 2022 04:12:17 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes `src/jdk.jdi/share/classes/com/sun/tools` changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From almatvee at openjdk.org Fri Dec 16 05:17:11 2022 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Dec 2022 05:17:11 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes jpackage changes looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR: https://git.openjdk.org/jdk20/pull/35 From dfuchs at openjdk.org Fri Dec 16 09:22:29 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 Dec 2022 09:22:29 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34: > 32: # Translators please note do not translate the options themselves > 33: java.launcher.opt.footer = \ -cp \n -classpath \n --class-path \n Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n -p \n --module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist.\n --upgrade-module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n Module im Laufzeitimage ersetzen\n --add-modules [,...]\n Root-Module, die zus\u00E4tzlich zum anf\u00E4n glichen Modul aufgel\u00F6st werden sollen.\n kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n ALL-MODULE-PATH.\n --enable-native-access [,...]\n Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n kann auch ALL-UNNAMED lauten.\n --list-modules\n Listet beobachtbare Module auf und beendet den Vorgang\n -d \n --describe-module \n Beschreibt ein Modul und beendet den Vorgang\n --dry-run Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n --validate-modules\n Validiert alle Module und beendet den Vorgang\n Die Option "--vali date-modules" kann n\u00FCtzlich sein, um\n Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n -D=\n Legt eine Systemeigenschaft fest\n -verbose:[class|module|gc|jni]\n Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n -version Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n --version Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n -showversion Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n --show-version\n Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n --show-module-resolution\n Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n -? -h -help\n Gibt diese Hilfemeldung an den Fehlerstream aus\n --help Gibt diese Hilfemeldung an den Outputstream aus\n -X Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n --help-extra Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n -ea[:...|:]\n -enableassertions[:...|:]\n Aktiviert Assertions mit angegebener Granularit\u00E4t\n -da[:...|:]\n -disableassertions[:...|:]\n Deaktiviert Assertions mit angegebener Granularit\u00E4t\n -esa | -enablesystemassertions\n Aktiviert System-Assertions\n -dsa | -disablesystemassertions\n Deaktiviert System-Assertions\n -agentlib:[=]\n L\u00E4dt die native Agent Library . Beispiel: -agentlib:jdwp\n siehe auch -agentlib:jdwp=help\n -agentpath:[=]\n L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n -javaagent:[=]\n \ > 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n -splash:\n Zeigt den Startbildschirm mit einem angegebenen Bild an\n Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n Das am besten geeignete angegebene skalierte Bild wird\n automatisch ausgew\u00E4hlt.\n Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n @argument files\n Eine oder mehrere Argumentdateien mit Optionen\n -disable- at files\n Verhindert die weitere Erweiterung von Argumentdateien\n --enable-preview\n L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f \u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --= oder\n-- verwenden.\n This change seems wrong, unless I'm mistaken the option name is `--disable- at files`, not `-disable- at files` ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dfuchs at openjdk.org Fri Dec 16 09:48:59 2022 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 16 Dec 2022 09:48:59 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com> On Fri, 16 Dec 2022 09:20:07 GMT, Daniel Fuchs wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert old translation. Fix lang codes > > src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34: > >> 32: # Translators please note do not translate the options themselves >> 33: java.launcher.opt.footer = \ -cp \n -classpath \n --class-path \n Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n -p \n --module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist.\n --upgrade-module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n Module im Laufzeitimage ersetzen\n --add-modules [,...]\n Root-Module, die zus\u00E4tzlich zum anf\u00E4 nglichen Modul aufgel\u00F6st werden sollen.\n kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n ALL-MODULE-PATH.\n --enable-native-access [,...]\n Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n kann auch ALL-UNNAMED lauten.\n --list-modules\n Listet beobachtbare Module auf und beendet den Vorgang\n -d \n --describe-module \n Beschreibt ein Modul und beendet den Vorgang\n --dry-run Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n --validate-modules\n Validiert alle Module und beendet den Vorgang\n Die Option "--val idate-modules" kann n\u00FCtzlich sein, um\n Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n -D=\n Legt eine Systemeigenschaft fest\n -verbose:[class|module|gc|jni]\n Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n -version Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n --version Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n -showversion Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n --show-version\n Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n --show-module-resolution\n Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n -? -h -help\n Gibt diese Hilfemeldung an den Fehlerstream aus\n --help Gibt diese Hilfemeldung an den Outputstream aus\n -X Gibt Hilf e zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n --help-extra Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n -ea[:...|:]\n -enableassertions[:...|:]\n Aktiviert Assertions mit angegebener Granularit\u00E4t\n -da[:...|:]\n -disableassertions[:...|:]\n Deaktiviert Assertions mit angegebener Granularit\u00E4t\n -esa | -enablesystemassertions\n Aktiviert System-Assertions\n -dsa | -disablesystemassertions\n Deaktiviert System-Assertions\n -agentlib:[=]\n L\u00E4dt die native Agent Library . Beispiel: -agentlib:jdwp\n siehe auch -agentlib:jdwp=help\n -agentpath:[=]\n L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n -javaagent:[=]\ n \ >> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n -splash:\n Zeigt den Startbildschirm mit einem angegebenen Bild an\n Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n Das am besten geeignete angegebene skalierte Bild wird\n automatisch ausgew\u00E4hlt.\n Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n @argument files\n Eine oder mehrere Argumentdateien mit Optionen\n -disable- at files\n Verhindert die weitere Erweiterung von Argumentdateien\n --enable-preview\n L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --= oder\n-- verwenden.\n > > This change seems wrong, unless I'm mistaken the option name is still `--disable- at files`, not `-disable- at files` I'm unfortunately not familiar with any of these resources files, and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation. Find-in-files revealed that the source is still using --disable- at files. See: https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131 https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377 https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121 ------------- PR: https://git.openjdk.org/jdk20/pull/35 From alanb at openjdk.org Fri Dec 16 10:13:04 2022 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Dec 2022 10:13:04 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:55:29 GMT, Damon Nguyen wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert old translation. Fix lang codes > > @dfuch Could I get a review from you as well? I believe this translation covers some of the files for your team. @DamonGuy There seems to be several glitches in this refresh. It's also surprising that the translations appear to be done on several out of date files. On the positive front, it's good to see this update has caught the attention of Naoto, Weijun, and others. Once the identified issues have been fixed then it would be good to try to get a review from someone that is native in each of the languages. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From naoto at openjdk.org Fri Dec 16 13:46:02 2022 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Dec 2022 13:46:02 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes There is another translation drop scheduled in January, so our plan is to figure out why the source extraction in this drop mistakenly used old files till then, then address it in the January l10n drop. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From weijun at openjdk.org Fri Dec 16 15:05:55 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Dec 2022 15:05:55 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> On Fri, 16 Dec 2022 03:41:09 GMT, Damon Nguyen wrote: >> src/java.base/share/classes/sun/security/tools/keytool/Resources_zh_CN.java line 75: >> >>> 73: "\u5DF2\u751F\u6210 {0} \u4F4D{1}\u5BC6\u94A5"}, //-genseckey >>> 74: {"key.algorithm.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u7B97\u6CD5\u88AB\u89C6\u4E3A\u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, >>> 75: {"key.size.weak", "%1$s \u4F7F\u7528\u7684 %2$s \u5B58\u5728\u5B89\u5168\u98CE\u9669\u3002"}, >> >> The exact same "is considered a security risk" is sometimes translated into "?????????" and sometimes "??????". Either is OK for me but please be consistent. This is also shown in 5 other places in the same file. > > I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK? Yes, you can replace all "??????" (that is not after ""???") to "?????????". There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From sspitsyn at openjdk.org Fri Dec 16 14:17:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 16 Dec 2022 14:17:49 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 02:16:36 GMT, David Holmes wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > src/hotspot/share/prims/jvmtiThreadState.cpp line 304: > >> 302: >> 303: ThreadBlockInVM tbivm(thread); >> 304: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); > > Aside: this pattern looks very odd. Why not just lock with the safepoint check? @dholmes-ora Thank you for looking at this fix and for the comments. I will on replying and resolving them. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dnguyen at openjdk.org Fri Dec 16 16:53:59 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 16:53:59 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 03:38:54 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert old translation. Fix lang codes Right, Naoto's comment is correct. This time, the source extraction used some older files. To resolve this for this drop, I went through the files and reverted any changes that would be deemed as regressions or outdated files. Any other updates missed in this drop will be handled in the close upcoming drop in January. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:02:42 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:02:42 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v6] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Fix missing dash ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/29880af9..62a19a83 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=04-05 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:02:44 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:02:44 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> <_0KsmHnCRIMKjENGMD87WqQJUloO0LDLaQyHBkwGiw0=.b44b40b1-10b0-4be4-99cf-0d18750a6c19@github.com> Message-ID: On Fri, 16 Dec 2022 09:46:14 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher_de.properties line 34: >> >>> 32: # Translators please note do not translate the options themselves >>> 33: java.launcher.opt.footer = \ -cp \n -classpath \n --class-path \n Eine durch {0} getrennte Liste mit Verzeichnissen, JAR-Archiven\n und ZIP-Archiven, in denen nach Klassendateien gesucht wird.\n -p \n --module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist.\n --upgrade-module-path ...\n Eine durch {0} getrennte Liste mit Verzeichnissen, von denen jedes Verzeichnis\n ein Verzeichnis mit Modulen ist, die upgradef\u00E4hige\n Module im Laufzeitimage ersetzen\n --add-modules [,...]\n Root-Module, die zus\u00E4tzlich zum anf\u00E 4nglichen Modul aufgel\u00F6st werden sollen.\n kann auch wie folgt lauten: ALL-DEFAULT, ALL-SYSTEM,\n ALL-MODULE-PATH.\n --enable-native-access [,...]\n Module, die eingeschr\u00E4nkte native Vorg\u00E4nge ausf\u00FChren d\u00FCrfen.\n kann auch ALL-UNNAMED lauten.\n --list-modules\n Listet beobachtbare Module auf und beendet den Vorgang\n -d \n --describe-module \n Beschreibt ein Modul und beendet den Vorgang\n --dry-run Erstellt eine VM und l\u00E4dt die Hauptklasse, f\u00FChrt aber nicht die Hauptmethode aus.\n Die Option "--dry-run" kann n\u00FCtzlich sein, um die\n Befehlszeilenoptionen, wie die Modulsystemkonfiguration, zu validieren.\n --validate-modules\n Validiert alle Module und beendet den Vorgang\n Die Option "--va lidate-modules" kann n\u00FCtzlich sein, um\n Konflikte und andere Fehler mit Modulen auf dem Modulpfad zu ermitteln.\n -D=\n Legt eine Systemeigenschaft fest\n -verbose:[class|module|gc|jni]\n Aktiviert die Verbose-Ausgabe f\u00FCr das angegebene Subsystem\n -version Gibt die Produktversion an den Fehlerstream aus und beendet den Vorgang\n --version Gibt die Produktversion an den Outputstream aus und beendet den Vorgang\n -showversion Gibt die Produktversion an den Fehlerstream aus und setzt den Vorgang fort\n --show-version\n Gibt die Produktversion an den Outputstream aus und setzt den Vorgang fort\n --show-module-resolution\n Zeigt die Modulaufl\u00F6sungsausgabe beim Start an\n -? -h -help\n Gibt diese Hilfemeldung an den Fehlerstream aus\n --help Gibt diese Hilfemeldung an den Outputstream aus\n -X Gibt Hil fe zu zus\u00E4tzlichen Optionen an den Fehlerstream aus\n --help-extra Gibt Hilfe zu zus\u00E4tzlichen Optionen an den Outputstream aus\n -ea[:...|:]\n -enableassertions[:...|:]\n Aktiviert Assertions mit angegebener Granularit\u00E4t\n -da[:...|:]\n -disableassertions[:...|:]\n Deaktiviert Assertions mit angegebener Granularit\u00E4t\n -esa | -enablesystemassertions\n Aktiviert System-Assertions\n -dsa | -disablesystemassertions\n Deaktiviert System-Assertions\n -agentlib:[=]\n L\u00E4dt die native Agent Library . Beispiel: -agentlib:jdwp\n siehe auch -agentlib:jdwp=help\n -agentpath:[=]\n L\u00E4dt die native Agent Library mit dem vollst\u00E4ndigen Pfadnamen\n -javaagent:[=] \n \ >>> 34: L\u00E4dt den Java-Programmiersprachen-Agent, siehe java.lang.instrument\n -splash:\n Zeigt den Startbildschirm mit einem angegebenen Bild an\n Skalierte HiDPI-Bilder werden automatisch unterst\u00FCtzt und verwendet,\n falls verf\u00FCgbar. Der nicht skalierte Bilddateiname (Beispiel: image.ext)\n muss immer als Argument an die Option "-splash" \u00FCbergeben werden.\n Das am besten geeignete angegebene skalierte Bild wird\n automatisch ausgew\u00E4hlt.\n Weitere Informationen finden Sie in der Dokumentation zur SplashScreen-API\n @argument files\n Eine oder mehrere Argumentdateien mit Optionen\n -disable- at files\n Verhindert die weitere Erweiterung von Argumentdateien\n --enable-preview\n L\u00E4sst zu, das Klassen von Vorschaufeatures dieses Release abh\u00E4ngig sind\nUm ein Argument f\u00FCr eine lange Option anzugeben, k\u00F6nnen Sie --= oder\n-- verwenden.\n >> >> This change seems wrong, unless I'm mistaken the option name is still `--disable- at files`, not `-disable- at files` > > I'm unfortunately not familiar with any of these resources files, and can't neither comment on any of the translated languages. I still had a look and spotted the glitch above - which seems to be an error introduced in the translation. > Find-in-files revealed that the source is still using --disable- at files. See: > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/args.c#L131 > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L1377 > > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/launcher/resources/launcher.properties#L121 Thanks for taking a look. I fixed this removed dash from the translation in the latest PR. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From prr at openjdk.org Fri Dec 16 17:28:56 2022 From: prr at openjdk.org (Phil Race) Date: Fri, 16 Dec 2022 17:28:56 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v6] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 17:02:42 GMT, Damon Nguyen wrote: >> Open l10n drop >> All tests passed > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Fix missing dash src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430: > 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A > 429: > 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145, \u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6 I was asked to review SwingSet2 changes but this isn't code. But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:42:17 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:42:17 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v7] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert swingset. Consistency in CN ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/62a19a83..fe18e4ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=05-06 Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:45:05 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:45:05 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> Message-ID: On Fri, 16 Dec 2022 15:02:42 GMT, Weijun Wang wrote: >> I didn't do the translation myself so I'm not sure the best approach to resolve this. I can manually replace these translations with one or the other. However, it's determine which parts of the code translate to ?????????" or "??????". I converted the unicode you highlighted above to characters, and I see where each one is located. If I just replace all instances of "??????" and insert "?????????" in unicode in its place, will it be OK? > > Yes, you can replace all "??????" (that is not after ""???") to "?????????". > > There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. Could you re-review the current changes for this drop? ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:51:19 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:51:19 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v8] In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: > Open l10n drop > All tests passed Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Swingset newline ------------- Changes: - all: https://git.openjdk.org/jdk20/pull/35/files - new: https://git.openjdk.org/jdk20/pull/35/files/fe18e4ea..f058a1de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=35&range=06-07 Stats: 3 lines in 3 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk20/pull/35.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/35/head:pull/35 PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 17:51:20 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 17:51:20 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v5] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: On Fri, 16 Dec 2022 17:26:18 GMT, Phil Race wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert old translation. Fix lang codes > > src/demo/share/jfc/SwingSet2/resources/swingset_zh_CN.properties line 430: > >> 428: ProgressBarDemo.accessible_text_area_name=\u52A0\u8F7D\u7684\u6587\u672C\u6B63\u5728\u9010\u6E10\u589E\u591A >> 429: >> 430: ProgressBarDemo.accessible_text_area_description=\u8FD9\u4E2A JTextArea \u7531\u6765\u81EA\u7F13\u51B2\u533A\u7684\u6587\u672C\u9010\u4E2A\u5B57\u7B26\u5730\u586B\u5145\uFF0C\u540C\u65F6\u7A97\u53E3\u5E95\u90E8\u7684\u8FDB\u5EA6\u680F\u5C06\u663E\u793A\u52A0\u8F7D\u7684\u8FDB\u5EA6 > > I was asked to review SwingSet2 changes but this isn't code. > But apparently I am not the right person to review this since I cannot understand the changes (not a DE, CN, or JA language expert) nor the reason for them. If this is a change to a unicode comma (as implied in an off-review message), I have no idea why .. it seems to be just asking for trouble. Thanks. I removed the changes to swingset's translation to avoid causing any issues. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From weijun at openjdk.org Fri Dec 16 18:02:55 2022 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 16 Dec 2022 18:02:55 GMT Subject: [jdk20] RFR: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 [v4] In-Reply-To: References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> <2YOQE1QvnJ2ntEgk3PVI_IXfwyPyZN50WAiiEf0Nub0=.ba16fa2f-799d-42b5-a0b1-4e65d99fecb7@github.com> Message-ID: On Fri, 16 Dec 2022 17:41:42 GMT, Damon Nguyen wrote: >> Yes, you can replace all "??????" (that is not after ""???") to "?????????". >> >> There are also similar usages in `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. > > Hi @wangweij , I believe I fixed the occurrences of "??????" and replaced them with "?????????". This translation drop does not update `src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java`. So, this may be a separate request. If that file is selected for extraction in the next drop in January, then it could also be fixed then. > > Could you re-review the current changes for this drop? The updated file looks fine to me. Thanks. ------------- PR: https://git.openjdk.org/jdk20/pull/35 From dnguyen at openjdk.org Fri Dec 16 21:18:58 2022 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 16 Dec 2022 21:18:58 GMT Subject: [jdk20] Integrated: 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 In-Reply-To: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> References: <7MbSf4IJkTVP_hpoEeYHn56XkgndVt_iluBaKK5G_Bk=.04162f93-5cb3-47c2-aec7-173149054309@github.com> Message-ID: <3RA_5D04t20xCtp1jJI-KMZt7Ev8f7bJv2zlanOnE-E=.d82daa27-fd0d-4eca-88cd-61ace8ba0d4a@github.com> On Wed, 14 Dec 2022 23:40:52 GMT, Damon Nguyen wrote: > Open l10n drop > All tests passed This pull request has now been integrated. Changeset: c997b5bf Author: Damon Nguyen Committer: Naoto Sato URL: https://git.openjdk.org/jdk20/commit/c997b5bffd0ebbd6d68332572639c8cea05ccdb1 Stats: 1128 lines in 99 files changed: 783 ins; 198 del; 147 mod 8298133: JDK 20 RDP1 L10n resource files update - msgdrop 10 Reviewed-by: achung, naoto, joehw, cjplummer, almatvee ------------- PR: https://git.openjdk.org/jdk20/pull/35 From cjplummer at openjdk.org Fri Dec 16 22:14:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 16 Dec 2022 22:14:48 GMT Subject: RFR: 8298701: Cleanup SA entries in ProblemList-zgc.txt. In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 22:34:06 GMT, Chris Plummer wrote: > The following ProblemList-zgc.txt entries need a lot of cleanup. > > serviceability/sa/ClhsdbCDSCore.java 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-core 8268722,8284045 macosx-x64,generic-all > serviceability/sa/ClhsdbFindPC.java#no-xcomp-core 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-process 8276402 generic-all > serviceability/sa/ClhsdbJstack.java#id0 8276402 generic-all > serviceability/sa/ClhsdbPmap.java#core 8268722 macosx-x64 > serviceability/sa/ClhsdbPstack.java#core 8268722 macosx-x64 > serviceability/sa/TestJmapCore.java 8268722,8268283,8270202 macosx-x64,linux-aarch64,linux-x64 > serviceability/sa/TestJmapCoreMetaspace.java 8268722,8268636 generic-all > > [JDK-8268722](https://bugs.openjdk.org/browse/JDK-8268722) entries can be removed. It was closed as WNF. It doesn't really impact macosx-aarch64 (core files are reasonably small there), and on macosx-x64 all these core file tests are (probably indefinitely) problem listed for other reasons in the main problem list, so no need to problem list them here with a closed CR. > > [JDK-8276402](https://bugs.openjdk.org/browse/JDK-8276402) has been closed as dup of a bug that is now fixed. > > Lastly, TestJmapCore.java does fail on macosx-aarch64 due to [JDK-8268283](https://bugs.openjdk.org/browse/JDK-8268283), so its problem list entry needs to be updated to reflect that. Can I get a second review please? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11658 From amenkov at openjdk.org Fri Dec 16 23:09:51 2022 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 16 Dec 2022 23:09:51 GMT Subject: RFR: 8298701: Cleanup SA entries in ProblemList-zgc.txt. In-Reply-To: References: Message-ID: <4KBxdVrXgh2YzUZmHCw7cVgPl5OubfGZcZzO6FgsSTM=.7919a492-ab41-48a9-a405-c06a038e70ae@github.com> On Tue, 13 Dec 2022 22:34:06 GMT, Chris Plummer wrote: > The following ProblemList-zgc.txt entries need a lot of cleanup. > > serviceability/sa/ClhsdbCDSCore.java 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-core 8268722,8284045 macosx-x64,generic-all > serviceability/sa/ClhsdbFindPC.java#no-xcomp-core 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-process 8276402 generic-all > serviceability/sa/ClhsdbJstack.java#id0 8276402 generic-all > serviceability/sa/ClhsdbPmap.java#core 8268722 macosx-x64 > serviceability/sa/ClhsdbPstack.java#core 8268722 macosx-x64 > serviceability/sa/TestJmapCore.java 8268722,8268283,8270202 macosx-x64,linux-aarch64,linux-x64 > serviceability/sa/TestJmapCoreMetaspace.java 8268722,8268636 generic-all > > [JDK-8268722](https://bugs.openjdk.org/browse/JDK-8268722) entries can be removed. It was closed as WNF. It doesn't really impact macosx-aarch64 (core files are reasonably small there), and on macosx-x64 all these core file tests are (probably indefinitely) problem listed for other reasons in the main problem list, so no need to problem list them here with a closed CR. > > [JDK-8276402](https://bugs.openjdk.org/browse/JDK-8276402) has been closed as dup of a bug that is now fixed. > > Lastly, TestJmapCore.java does fail on macosx-aarch64 due to [JDK-8268283](https://bugs.openjdk.org/browse/JDK-8268283), so its problem list entry needs to be updated to reflect that. Marked as reviewed by amenkov (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11658 From dcubed at openjdk.org Sat Dec 17 16:16:35 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 17 Dec 2022 16:16:35 GMT Subject: [jdk20] Integrated: 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 Message-ID: A batch of trivial fixes to ProblemList tests: [JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 [JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 [JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC ------------- Commit messages: - 8298990: ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC - 8298989: ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 Changes: https://git.openjdk.org/jdk20/pull/51/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=51&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8298987 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk20/pull/51.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/51/head:pull/51 PR: https://git.openjdk.org/jdk20/pull/51 From azvegint at openjdk.org Sat Dec 17 16:16:36 2022 From: azvegint at openjdk.org (Alexander Zvegintsev) Date: Sat, 17 Dec 2022 16:16:36 GMT Subject: [jdk20] Integrated: 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 In-Reply-To: References: Message-ID: On Sat, 17 Dec 2022 16:00:32 GMT, Daniel D. Daugherty wrote: > A batch of trivial fixes to ProblemList tests: > [JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 > [JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 > [JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.org/jdk20/pull/51 From dcubed at openjdk.org Sat Dec 17 16:16:37 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 17 Dec 2022 16:16:37 GMT Subject: [jdk20] Integrated: 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 In-Reply-To: References: Message-ID: On Sat, 17 Dec 2022 16:05:24 GMT, Alexander Zvegintsev wrote: >> A batch of trivial fixes to ProblemList tests: >> [JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 >> [JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 >> [JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC > > Marked as reviewed by azvegint (Reviewer). @azvegint - Thanks for the lightning fast review! Especially for a Saturday AM! ------------- PR: https://git.openjdk.org/jdk20/pull/51 From dcubed at openjdk.org Sat Dec 17 16:16:37 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Sat, 17 Dec 2022 16:16:37 GMT Subject: [jdk20] Integrated: 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 In-Reply-To: References: Message-ID: On Sat, 17 Dec 2022 16:00:32 GMT, Daniel D. Daugherty wrote: > A batch of trivial fixes to ProblemList tests: > [JDK-8298987](https://bugs.openjdk.org/browse/JDK-8298987) ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 > [JDK-8298989](https://bugs.openjdk.org/browse/JDK-8298989) ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 > [JDK-8298990](https://bugs.openjdk.org/browse/JDK-8298990) ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC This pull request has now been integrated. Changeset: 34105556 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk20/commit/34105556d16774439195076f22f37f275d0d8873 Stats: 5 lines in 2 files changed: 5 ins; 0 del; 0 mod 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 8298989: ProblemList vmTestbase/nsk/jvmti/InterruptThread/intrpthrd003/TestDescription.java on macosx-x64 8298990: ProblemList java/lang/Thread/virtual/stress/Skynet.java subtests with ZGC Reviewed-by: azvegint ------------- PR: https://git.openjdk.org/jdk20/pull/51 From dholmes at openjdk.org Mon Dec 19 04:48:52 2022 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 Dec 2022 04:48:52 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2] In-Reply-To: References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Thu, 15 Dec 2022 22:21:35 GMT, Doug Simon wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed commented examle. > > Is it possible to add a test based on grep to prevent re-introduction of the unwanted C-style casts? Sorry @dougxc only found your comment by accident. AFAIK we don't have any such style of tests that would try to check the source code for an anti-pattern. Our test suites don't have access to the src tree when they run. ------------- PR: https://git.openjdk.org/jdk/pull/11682 From dnsimon at openjdk.org Mon Dec 19 09:03:52 2022 From: dnsimon at openjdk.org (Doug Simon) Date: Mon, 19 Dec 2022 09:03:52 GMT Subject: RFR: 8298241: Replace C-style casts with JavaThread::cast [v2] In-Reply-To: References: <6NksENBkkBRd2KR0c5kYlmruycaqoGx-Z_-h6lkb9ms=.a133b578-12a3-4ca6-9636-0159e305c5a5@github.com> Message-ID: On Thu, 15 Dec 2022 21:20:31 GMT, David Holmes wrote: >> This is a simple cleanup RFE to get rid of old-style C casts in relation to JavaThread. >> >> In many cases involving NULL/nullptr the cast could just be dropped. Sometimes a static cast is needed to disambiguate overloads. >> >> A couple of reinterpret_cast are needed when doing int/ptr conversion. >> >> static_cast is used for void* conversion. >> >> The other changes should be self explanatory. >> >> The changes in >> >> src/hotspot/os_cpu/bsd_aarch64/javaThread_bsd_aarch64.cpp >> src/hotspot/os_cpu/windows_aarch64/javaThread_windows_aarch64.cpp >> >> are a bit more extensive. That code was using an alias for `this` which is completely unnecessary (and the alias creation was using the cast). This could be factored out if thought necessary. >> >> I grep'd as best I could for the old C-style casts but can't be certain I got them all. >> >> Testing: >> - all builds in our tiers1-5 >> - local linux x64 product, slowdebug and fastdebug >> - GHA >> - Sanity testing tiers 1-3 >> Thanks. > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Fixed commented examle. Ok, thanks. That's a shame. It seems like being able to run style checkers and other linters would be useful in cases like this. ------------- PR: https://git.openjdk.org/jdk/pull/11682 From sspitsyn at openjdk.org Mon Dec 19 11:36:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Dec 2022 11:36:49 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 02:10:09 GMT, David Holmes wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > src/hotspot/share/classfile/javaClasses.cpp line 1745: > >> 1743: int val = VTMS_transition_disable_count(java_thread); >> 1744: java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val - 1); >> 1745: } > > These are not thread-safe functions. What constraints exist for using these methods safely? > Update: looks like they must be called with the lock held so we should assert that. > Should also assert the count never goes negative (which I assume would be an error?). Each of these two functions is called just once with the lock held. I feel that asserting this would be an overkill but I can add it if you still think it is important. I've added assert for negative count. > src/hotspot/share/prims/jvmtiThreadState.cpp line 252: > >> 250: return; // JvmtiVTMSTransitionDisabler is no-op without virtual threads >> 251: } >> 252: if (Thread::current_or_null() == NULL) { > > Nit: please use `nullptr` in new code Done. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Mon Dec 19 11:50:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Dec 2022 11:50:53 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 02:14:24 GMT, David Holmes wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > src/hotspot/share/prims/jvmtiThreadState.cpp line 273: > >> 271: } >> 272: _is_SR = is_SR; >> 273: _vthread = NULL; > > Nit: should initialize in init list Done. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Mon Dec 19 12:17:51 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Dec 2022 12:17:51 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions In-Reply-To: References: Message-ID: <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com> On Fri, 16 Dec 2022 02:15:38 GMT, David Holmes wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > src/hotspot/share/prims/jvmtiThreadState.cpp line 298: > >> 296: HandleMark hm(thread); >> 297: Handle vth = Handle(thread, JNIHandles::resolve_external_guard(_vthread)); >> 298: if (!java_lang_VirtualThread::is_instance(vth())) { > > How can this condition not be true? Should it be an assertion? The JvmtiVTMSTransitionDisabler has to be a no-op for a non-virtual thread. It is to avoid different branches for virtual and non-virtual cases and use this in `jvmtiEnv.cpp`: ` JvmtiVTMSTransitionDisabler disabler(thread);` I've added comments that mark no-op cases. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Mon Dec 19 12:29:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Dec 2022 12:29:49 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions In-Reply-To: References: Message-ID: On Fri, 16 Dec 2022 14:14:54 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 304: >> >>> 302: >>> 303: ThreadBlockInVM tbivm(thread); >>> 304: MonitorLocker ml(JvmtiVTMSTransition_lock, Mutex::_no_safepoint_check_flag); >> >> Aside: this pattern looks very odd. Why not just lock with the safepoint check? > > @dholmes-ora > Thank you for looking at this fix and for the comments. > I will on replying and resolving them. This update just follows the common pattern which was introduced about two years ago. At the moment I do not remember the exact reason. This code needs to wait for the counter to become zero and to use `ThreadBlockInVM` which can reach a safepoint in the destructor. Can we lock with a safepoint check in this case? Or we should get rid of the `ThreadBlockInVM` then? I'll check if this can be fixed. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Mon Dec 19 12:50:11 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 Dec 2022 12:50:11 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: References: Message-ID: > Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. > New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. > > Testing: > mach5 jobs are TBD (preliminary testing was completed): > - all JVMTI, JDWP, JDI and JDB tests have to be run > - Kitchensink > - tier5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: review comments are addressed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11690/files - new: https://git.openjdk.org/jdk/pull/11690/files/641f21f0..2603eebb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=00-01 Stats: 21 lines in 3 files changed: 6 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/11690.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690 PR: https://git.openjdk.org/jdk/pull/11690 From cjplummer at openjdk.org Mon Dec 19 18:05:58 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 19 Dec 2022 18:05:58 GMT Subject: RFR: 8298701: Cleanup SA entries in ProblemList-zgc.txt. In-Reply-To: References: Message-ID: On Tue, 13 Dec 2022 22:34:06 GMT, Chris Plummer wrote: > The following ProblemList-zgc.txt entries need a lot of cleanup. > > serviceability/sa/ClhsdbCDSCore.java 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-core 8268722,8284045 macosx-x64,generic-all > serviceability/sa/ClhsdbFindPC.java#no-xcomp-core 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-process 8276402 generic-all > serviceability/sa/ClhsdbJstack.java#id0 8276402 generic-all > serviceability/sa/ClhsdbPmap.java#core 8268722 macosx-x64 > serviceability/sa/ClhsdbPstack.java#core 8268722 macosx-x64 > serviceability/sa/TestJmapCore.java 8268722,8268283,8270202 macosx-x64,linux-aarch64,linux-x64 > serviceability/sa/TestJmapCoreMetaspace.java 8268722,8268636 generic-all > > [JDK-8268722](https://bugs.openjdk.org/browse/JDK-8268722) entries can be removed. It was closed as WNF. It doesn't really impact macosx-aarch64 (core files are reasonably small there), and on macosx-x64 all these core file tests are (probably indefinitely) problem listed for other reasons in the main problem list, so no need to problem list them here with a closed CR. > > [JDK-8276402](https://bugs.openjdk.org/browse/JDK-8276402) has been closed as dup of a bug that is now fixed. > > Lastly, TestJmapCore.java does fail on macosx-aarch64 due to [JDK-8268283](https://bugs.openjdk.org/browse/JDK-8268283), so its problem list entry needs to be updated to reflect that. Thanks for the reviews Alex and Serguei! ------------- PR: https://git.openjdk.org/jdk/pull/11658 From cjplummer at openjdk.org Mon Dec 19 18:05:58 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 19 Dec 2022 18:05:58 GMT Subject: Integrated: 8298701: Cleanup SA entries in ProblemList-zgc.txt. In-Reply-To: References: Message-ID: <9O-xplel6a7CCktmg3Q05JzruSGdMl4N_WE0Bweiua4=.6b472f15-f91a-4003-9f04-41dc19da87b7@github.com> On Tue, 13 Dec 2022 22:34:06 GMT, Chris Plummer wrote: > The following ProblemList-zgc.txt entries need a lot of cleanup. > > serviceability/sa/ClhsdbCDSCore.java 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-core 8268722,8284045 macosx-x64,generic-all > serviceability/sa/ClhsdbFindPC.java#no-xcomp-core 8268722 macosx-x64 > serviceability/sa/ClhsdbFindPC.java#xcomp-process 8276402 generic-all > serviceability/sa/ClhsdbJstack.java#id0 8276402 generic-all > serviceability/sa/ClhsdbPmap.java#core 8268722 macosx-x64 > serviceability/sa/ClhsdbPstack.java#core 8268722 macosx-x64 > serviceability/sa/TestJmapCore.java 8268722,8268283,8270202 macosx-x64,linux-aarch64,linux-x64 > serviceability/sa/TestJmapCoreMetaspace.java 8268722,8268636 generic-all > > [JDK-8268722](https://bugs.openjdk.org/browse/JDK-8268722) entries can be removed. It was closed as WNF. It doesn't really impact macosx-aarch64 (core files are reasonably small there), and on macosx-x64 all these core file tests are (probably indefinitely) problem listed for other reasons in the main problem list, so no need to problem list them here with a closed CR. > > [JDK-8276402](https://bugs.openjdk.org/browse/JDK-8276402) has been closed as dup of a bug that is now fixed. > > Lastly, TestJmapCore.java does fail on macosx-aarch64 due to [JDK-8268283](https://bugs.openjdk.org/browse/JDK-8268283), so its problem list entry needs to be updated to reflect that. This pull request has now been integrated. Changeset: 9194e915 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/9194e915495434c154ff4cf142d527b163026b3c Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod 8298701: Cleanup SA entries in ProblemList-zgc.txt. Reviewed-by: sspitsyn, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/11658 From cjplummer at openjdk.org Tue Dec 20 02:13:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Dec 2022 02:13:48 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads Message-ID: There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. ------------- Commit messages: - Update problem list for fixed tests. - Use -Djdk.virtualThreadScheduler.parallelism=15 so we always have enough carrier threads if the test pins a lot of threads. Changes: https://git.openjdk.org/jdk/pull/11735/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11735&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8285416 Stats: 25 lines in 3 files changed: 2 ins; 23 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11735.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11735/head:pull/11735 PR: https://git.openjdk.org/jdk/pull/11735 From cjplummer at openjdk.org Tue Dec 20 02:25:38 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Dec 2022 02:25:38 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: > There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. > > I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: Better comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11735/files - new: https://git.openjdk.org/jdk/pull/11735/files/4ea36acd..e079d3bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11735&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11735&range=00-01 Stats: 6 lines in 2 files changed: 4 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/11735.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11735/head:pull/11735 PR: https://git.openjdk.org/jdk/pull/11735 From dholmes at openjdk.org Tue Dec 20 02:25:39 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Dec 2022 02:25:39 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads In-Reply-To: References: Message-ID: <_pmenyyv71X6loqJZLlx1fnI2t8-sj084TwLjo3PNWI=.23687405-6dab-4620-898f-4555920fc7f7@github.com> On Tue, 20 Dec 2022 02:04:01 GMT, Chris Plummer wrote: > There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. > > I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. This sounds like a bug with the underlying executor. If the VT's pin their carrier threads then the executor should increase its parallelism level automatically to compensate for that. ------------- PR: https://git.openjdk.org/jdk/pull/11735 From cjplummer at openjdk.org Tue Dec 20 04:37:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 20 Dec 2022 04:37:48 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads In-Reply-To: <_pmenyyv71X6loqJZLlx1fnI2t8-sj084TwLjo3PNWI=.23687405-6dab-4620-898f-4555920fc7f7@github.com> References: <_pmenyyv71X6loqJZLlx1fnI2t8-sj084TwLjo3PNWI=.23687405-6dab-4620-898f-4555920fc7f7@github.com> Message-ID: On Tue, 20 Dec 2022 02:19:31 GMT, David Holmes wrote: > This sounds like a bug with the underlying executor. If the VT's pin their carrier threads then the executor should increase its parallelism level automatically to compensate for that. It's probably best if @AlanBateman explains this. In the meantime, you might find the following code in VirtualThread.createDefaultScheduler() useful: String parallelismValue = System.getProperty("jdk.virtualThreadScheduler.parallelism"); String maxPoolSizeValue = System.getProperty("jdk.virtualThreadScheduler.maxPoolSize"); String minRunnableValue = System.getProperty("jdk.virtualThreadScheduler.minRunnable"); if (parallelismValue != null) { parallelism = Integer.parseInt(parallelismValue); } else { parallelism = Runtime.getRuntime().availableProcessors(); } if (maxPoolSizeValue != null) { maxPoolSize = Integer.parseInt(maxPoolSizeValue); parallelism = Integer.min(parallelism, maxPoolSize); } else { maxPoolSize = Integer.max(parallelism, 256); } Also, Alan mentioned the following to me: "There are two configuration knobs. One is parallelism, the other is maxPoolSize. maxPoolSize is the maximum number of carrier threads. parallelism is really the target parallelism. It's value is the number of hardware threads but it might be increased temporarily during operations that pin threads. So if you are monitoring the number of carriers on an 8 core system then you might see 9 or 10 threads periodically, only to compensate for threads that are pinned." What's not clear of me is if the "pinning" that happens during synchronization is taken into account with this strategy. I think it might not actually be considered pinning (from an implementation point of view), but does have the same affect of occupying the carrier thread. ------------- PR: https://git.openjdk.org/jdk/pull/11735 From dholmes at openjdk.org Tue Dec 20 04:39:53 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Dec 2022 04:39:53 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com> References: <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com> Message-ID: On Mon, 19 Dec 2022 12:13:42 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 298: >> >>> 296: HandleMark hm(thread); >>> 297: Handle vth = Handle(thread, JNIHandles::resolve_external_guard(_vthread)); >>> 298: if (!java_lang_VirtualThread::is_instance(vth())) { >> >> How can this condition not be true? Should it be an assertion? > > The JvmtiVTMSTransitionDisabler has to be a no-op for a non-virtual thread. It is to avoid different branches where it is possible for virtual and non-virtual cases and use this in `jvmtiEnv.cpp`: > ` JvmtiVTMSTransitionDisabler disabler(thread);` > I've added comments that mark no-op cases. I see. I assumed the name `_vthread` implied it was actually known to be a vthread. Really the field and parameters should just be called `thread`. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dholmes at openjdk.org Tue Dec 20 04:54:51 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Dec 2022 04:54:51 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: References: Message-ID: On Mon, 19 Dec 2022 11:32:40 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1745: >> >>> 1743: int val = VTMS_transition_disable_count(java_thread); >>> 1744: java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val - 1); >>> 1745: } >> >> These are not thread-safe functions. What constraints exist for using these methods safely? >> Update: looks like they must be called with the lock held so we should assert that. >> Should also assert the count never goes negative (which I assume would be an error?). > > Each of these two functions is called just once with the lock held. > I feel that asserting this would be an overkill but I can add it if you still think it is important. > I've added assert for negative count. asserts would be good please else someone may use them somewhere else without locking. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dholmes at openjdk.org Tue Dec 20 04:54:52 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Dec 2022 04:54:52 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: References: Message-ID: <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com> On Mon, 19 Dec 2022 12:27:08 GMT, Serguei Spitsyn wrote: >> @dholmes-ora >> Thank you for looking at this fix and for the comments. >> I will on replying and resolving them. > > This update just follows the common pattern which was introduced about two years ago. At the moment I do not remember the exact reason. This code needs to wait for the counter to become zero and to use `ThreadBlockInVM` which can reach a safepoint in the destructor. Can we lock with a safepoint check in this case? Or we should get rid of the `ThreadBlockInVM` then? > I'll check if this can be fixed. This can be a separate RFE if the reason for it being a nosafepoint lock no longer holds. It would be cleaner to use a normal safepoint checking lock than to artificially make the thread safepoint-safe before using it. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dholmes at openjdk.org Tue Dec 20 04:54:54 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Dec 2022 04:54:54 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: References: Message-ID: On Mon, 19 Dec 2022 12:50:11 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > review comments are addressed src/hotspot/share/prims/jvmtiThreadState.hpp line 88: > 86: > 87: bool _is_SR; // is suspender or resumer > 88: jthread _vthread; // virtual thread to disable transitions for Please don't call this `_vthread` as it may or may not be a virtual thread. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dholmes at openjdk.org Tue Dec 20 05:23:50 2022 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 Dec 2022 05:23:50 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. The JEP defines pinning as expected: > There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier: > > When it executes code inside a synchronized block or method, or > When it executes a native method or a [foreign function](https://openjdk.java.net/jeps/424). > > Pinning does not make an application incorrect, but it might hinder its scalability. If a virtual thread performs a blocking operation such as I/O or BlockingQueue.take() while it is pinned, then its carrier and the underlying OS thread are blocked for the duration of the operation. Frequent pinning for long durations can harm the scalability of an application by capturing carriers. But then also says: > The scheduler does not compensate for pinning by expanding its parallelism. which contradicts what you quoted from Alan above - though I prefer that behaviour as the JEP's behaviour seems a design flaw to me. ------------- PR: https://git.openjdk.org/jdk/pull/11735 From sspitsyn at openjdk.org Tue Dec 20 10:12:51 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Dec 2022 10:12:51 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 04:51:52 GMT, David Holmes wrote: >> Each of these two functions is called just once with the lock held. >> I feel that asserting this would be an overkill but I can add it if you still think it is important. >> I've added assert for negative count. > > asserts would be good please else someone may use them somewhere else without locking. Done. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Tue Dec 20 10:20:51 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Dec 2022 10:20:51 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 04:50:49 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> review comments are addressed > > src/hotspot/share/prims/jvmtiThreadState.hpp line 88: > >> 86: >> 87: bool _is_SR; // is suspender or resumer >> 88: jthread _vthread; // virtual thread to disable transitions for > > Please don't call this `_vthread` as it may or may not be a virtual thread. Fixed now. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Tue Dec 20 10:20:49 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Dec 2022 10:20:49 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: References: <_NNiyosa79YVtmnwq_IXZzID3OBLP0IuSq4JgocZIEc=.be1e860e-71f3-4407-8251-eb074ad02c8d@github.com> Message-ID: On Tue, 20 Dec 2022 04:37:32 GMT, David Holmes wrote: >> The JvmtiVTMSTransitionDisabler has to be a no-op for a non-virtual thread. It is to avoid different branches where it is possible for virtual and non-virtual cases and use this in `jvmtiEnv.cpp`: >> ` JvmtiVTMSTransitionDisabler disabler(thread);` >> I've added comments that mark no-op cases. > > I see. I assumed the name `_vthread` implied it was actually known to be a vthread. Really the field and parameters should just be called `thread`. Okay, renamed now. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Tue Dec 20 10:24:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Dec 2022 10:24:53 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v2] In-Reply-To: <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com> References: <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com> Message-ID: <50W4OIGSyCQhBbg0qJ2Ie_9H-R0LSsWJqCT_E5FR7KI=.803c3631-2f33-41e7-b7fb-ef85ded74f03@github.com> On Tue, 20 Dec 2022 04:49:46 GMT, David Holmes wrote: >> This update just follows the common pattern which was introduced about two years ago. At the moment I do not remember the exact reason. This code needs to wait for the counter to become zero and to use `ThreadBlockInVM` which can reach a safepoint in the destructor. Can we lock with a safepoint check in this case? Or we should get rid of the `ThreadBlockInVM` then? >> I'll check if this can be fixed. > > This can be a separate RFE if the reason for it being a nosafepoint lock no longer holds. It would be cleaner to use a normal safepoint checking lock than to artificially make the thread safepoint-safe before using it. Agreed. I was thinking about a separate RFE. I started seeing some failures in the S/R related tests with the removed `ThreadBlockInVM` and `_no_safepoint_check_flag`. Need to investigated why. Otherwise, it seems to be working well. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From jwilhelm at openjdk.org Tue Dec 20 11:13:46 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 20 Dec 2022 11:13:46 GMT Subject: RFR: Merge jdk20 Message-ID: Forwardport JDK 20 -> JDK 21 ------------- Commit messages: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8298784: JFR: Test chunk integrity - 8298215: gc/g1/TestVerifyGCType.java failed with "Missing expected verification pattern Verifying After GC for: Pause Young (Prepare Mixed): expected true, was false" - 4958969: ObjectOutputStream example leads to non-working code - 8298699: java/lang/reflect/IllegalArgumentsTest.java times out with slowdebug bits - 4512626: Non-editable JTextArea provides no visual indication of keyboard focus - 8277074: Qualified exported types show up in JavaDoc - 8298894: java/lang/Thread/virtual/stress/Skynet.java timed out and threw OutOfMemoryError - 8298987: ProblemList jdk/internal/vm/Continuation/Fuzz.java#default with ZGC on X64 - 8298905: Test "java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java" fails because the frames of instruction does not display - ... and 6 more: https://git.openjdk.org/jdk/compare/36de61c4...d70f5831 The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.0 - jdk20: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=00.1 Changes: https://git.openjdk.org/jdk/pull/11739/files Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod Patch: https://git.openjdk.org/jdk/pull/11739.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739 PR: https://git.openjdk.org/jdk/pull/11739 From jwilhelm at openjdk.org Tue Dec 20 11:47:31 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 20 Dec 2022 11:47:31 GMT Subject: RFR: Merge jdk20 [v2] In-Reply-To: References: Message-ID: > Forwardport JDK 20 -> JDK 21 Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20 - 8298865: Excessive memory allocation in CipherOutputStream AEAD decryption Reviewed-by: valeriep, ascarpino - 8299043: test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java fails with java.lang.NullPointerException Reviewed-by: serb - 8298974: Add ftcolor.c to imported freetype sources Reviewed-by: serb - 8299044: test/jdk/javax/swing/JComboBox/JComboBoxBorderTest.java fails on non mac Reviewed-by: serb, honkar - 8299045: tools/doclint/BadPackageCommentTest.java fails after JDK-8298943 Reviewed-by: vromero - 8298943: Missing escapes for single quote marks in compiler.properties Reviewed-by: jjg - 8298701: Cleanup SA entries in ProblemList-zgc.txt. Reviewed-by: sspitsyn, amenkov - 8298470: Short cut java.lang.Object super class loading Reviewed-by: dholmes, iklam - 8299022: Linux ppc64le and s390x build issues after JDK-8160404 Reviewed-by: mdoerr, lucy - ... and 97 more: https://git.openjdk.org/jdk/compare/3dd2cfab...d70f5831 ------------- Changes: https://git.openjdk.org/jdk/pull/11739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11739&range=01 Stats: 13539 lines in 425 files changed: 8409 ins; 3097 del; 2033 mod Patch: https://git.openjdk.org/jdk/pull/11739.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11739/head:pull/11739 PR: https://git.openjdk.org/jdk/pull/11739 From jwilhelm at openjdk.org Tue Dec 20 11:47:33 2022 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Tue, 20 Dec 2022 11:47:33 GMT Subject: Integrated: Merge jdk20 In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 10:57:44 GMT, Jesper Wilhelmsson wrote: > Forwardport JDK 20 -> JDK 21 This pull request has now been integrated. Changeset: c5a4a7a6 Author: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/c5a4a7a679ec76cb08a999a198e5c73e9cd9d2f0 Stats: 2286 lines in 125 files changed: 1286 ins; 609 del; 391 mod Merge ------------- PR: https://git.openjdk.org/jdk/pull/11739 From sspitsyn at openjdk.org Tue Dec 20 20:52:10 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 Dec 2022 20:52:10 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v3] In-Reply-To: References: Message-ID: > Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. > New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. > > Testing: > mach5 jobs are TBD (preliminary testing was completed): > - all JVMTI, JDWP, JDI and JDB tests have to be run > - Kitchensink > - tier5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: address wqsecond round review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11690/files - new: https://git.openjdk.org/jdk/pull/11690/files/2603eebb..7783992f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=01-02 Stats: 15 lines in 3 files changed: 2 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/11690.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690 PR: https://git.openjdk.org/jdk/pull/11690 From dholmes at openjdk.org Wed Dec 21 09:36:52 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Dec 2022 09:36:52 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 20:52:10 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > address wqsecond round review comments One nit with the "is locked" asserts but otherwise looks good. Thanks for the updates! src/hotspot/share/classfile/javaClasses.cpp line 1739: > 1737: void java_lang_Thread::inc_VTMS_transition_disable_count(oop java_thread) { > 1738: int val = VTMS_transition_disable_count(java_thread); > 1739: assert(JvmtiVTMSTransition_lock->is_locked(), "Must be locked"); You want to use `owned_by_self()` for these assertions - thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11690 From abakhtin at openjdk.org Wed Dec 21 18:58:50 2022 From: abakhtin at openjdk.org (Alexey Bakhtin) Date: Wed, 21 Dec 2022 18:58:50 GMT Subject: RFR: 8299234: JMX Repository.query performance Message-ID: Please find a patch to improve JMX Repository.query performance Using ObjectName.apply() allows significantly decrease memory usage and the number of GC cycles: Before: $ java test 1000000 1000000 Test PASSED in 8943169791 ns. GC: G1 Young Generation getCollectionCount()=177 getCollectionTime()=118 After: $ java test 1000000 1000000 Test PASSED in 4808213917 ns. GC: G1 Young Generation getCollectionCount()=88 getCollectionTime()=53 Private ObjectName.matchDomains() method is also updated to minimize unnecessary memory allocation. All javax/management jtreg tests passed successfully. ------------- Commit messages: - 8299234: JMX Repository.query performance Changes: https://git.openjdk.org/jdk/pull/11758/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11758&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299234 Stats: 129 lines in 3 files changed: 2 ins; 115 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/11758.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11758/head:pull/11758 PR: https://git.openjdk.org/jdk/pull/11758 From sspitsyn at openjdk.org Wed Dec 21 21:14:51 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Dec 2022 21:14:51 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v3] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 20:52:10 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > address wqsecond round review comments David, thank you a lot for review! ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Wed Dec 21 21:14:53 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Dec 2022 21:14:53 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v3] In-Reply-To: References: Message-ID: On Wed, 21 Dec 2022 09:31:51 GMT, David Holmes wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> address wqsecond round review comments > > src/hotspot/share/classfile/javaClasses.cpp line 1739: > >> 1737: void java_lang_Thread::inc_VTMS_transition_disable_count(oop java_thread) { >> 1738: int val = VTMS_transition_disable_count(java_thread); >> 1739: assert(JvmtiVTMSTransition_lock->is_locked(), "Must be locked"); > > You want to use `owned_by_self()` for these assertions - thanks. You are right. Fixed now. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Wed Dec 21 21:14:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Dec 2022 21:14:54 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v3] In-Reply-To: <50W4OIGSyCQhBbg0qJ2Ie_9H-R0LSsWJqCT_E5FR7KI=.803c3631-2f33-41e7-b7fb-ef85ded74f03@github.com> References: <-fbjOn9Wsqar-pUqBT_qNslZvj7qBmTnWuTEkuZFt-M=.85e31c4e-0371-4aac-81f3-e37475abde10@github.com> <50W4OIGSyCQhBbg0qJ2Ie_9H-R0LSsWJqCT_E5FR7KI=.803c3631-2f33-41e7-b7fb-ef85ded74f03@github.com> Message-ID: On Tue, 20 Dec 2022 10:22:03 GMT, Serguei Spitsyn wrote: >> This can be a separate RFE if the reason for it being a nosafepoint lock no longer holds. It would be cleaner to use a normal safepoint checking lock than to artificially make the thread safepoint-safe before using it. > > Agreed. I was thinking about a separate RFE. I started seeing some failures in the S/R related tests with the removed `ThreadBlockInVM` and `_no_safepoint_check_flag`. Need to investigated why. Otherwise, it seems to be working well. As I see there can be some problems with the JVMTI Suspend/Resume but it is worth to investigate anyway. So, I've filed an RFE: [JDK-8299240](https://bugs.openjdk.org/browse/JDK-8299240): rank of JvmtiVTMSTransition_lock can be safepoint ------------- PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Wed Dec 21 21:33:28 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 21 Dec 2022 21:33:28 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: References: Message-ID: > Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. > New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. > > Testing: > mach5 jobs are TBD (preliminary testing was completed): > - all JVMTI, JDWP, JDI and JDB tests have to be run > - Kitchensink > - tier5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11690/files - new: https://git.openjdk.org/jdk/pull/11690/files/7783992f..3c73fae3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/11690.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690 PR: https://git.openjdk.org/jdk/pull/11690 From dholmes at openjdk.org Wed Dec 21 22:00:50 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Dec 2022 22:00:50 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. In terms of the actual changes what you have seems fine. I wonder whether the tests themselves should be checking the parallelism value is large enough? At the moment there is a disconnect between the number of vthreads a test may create versus the setting of the parallelism level in the launcher/binder code. ------------- PR: https://git.openjdk.org/jdk/pull/11735 From dholmes at openjdk.org Wed Dec 21 23:38:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Dec 2022 23:38:49 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: References: Message-ID: <8gjfuA4VUyyPnIy8p9AphoKnGkXGngZH8tUNtRKXrBY=.6b9c4e77-ea59-4c6e-96a2-040568a5d38f@github.com> On Wed, 21 Dec 2022 21:33:28 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11690 From kbarrett at openjdk.org Thu Dec 22 02:12:47 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 Dec 2022 02:12:47 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" Message-ID: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Please review this change to WhiteBox and some tests involving G1 concurrent GCs. Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a concurrent GC. Many of them follow it with a loop waiting for a concurrent cycle to not be in progress. A few also preceed that call with a similar loop, since that call does nothing and returns false if a concurrent cycle is already in progress. Those tests typically want to ensure there was a concurrent cycle that was started after some setup. The failing test calls that function, asserting that it returned true, e.g. a new concurrent cycle was started. There are various problems with this, due to races with concurrent cycles started automatically, and due to possibly aborted (by full GCs) concurrent cycles, making some of these tests unreliable in some configurations. For example, the test failure associated with this bug intermittently arises when running with `-Xcomp`, triggering a concurrent cycle before the explicit request by the test, causing the explicit request to fail (because there is already one in progress), failing the assert. Waiting for there not to be an in-progress cycle before the explicit request just narrows the race window. We have a different mechanism in WhiteBox for controlling concurrent cycles, the concurrent GC breakpoint mechanism. By adding a counter specifically for such cycles, we can use GC breakpoints to ensure only the concurrent cycles the test wants are occurring, and can verify they completed successfully. So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to avoid racing request problems and to detect aborted cycles. Since it is no longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer serves any purpose, having been purely a test of that removed function. Testing: mach5 tier1-7 - running the changed tests on a variety of platforms with a variety of configurations. ------------- Commit messages: - use gc breakpoints to perform conc gc Changes: https://git.openjdk.org/jdk20/pull/71/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=71&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8293824 Stats: 288 lines in 24 files changed: 98 ins; 131 del; 59 mod Patch: https://git.openjdk.org/jdk20/pull/71.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/71/head:pull/71 PR: https://git.openjdk.org/jdk20/pull/71 From david.holmes at oracle.com Thu Dec 22 06:03:07 2022 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Dec 2022 16:03:07 +1000 Subject: New candidate JEP: 435: Asynchronous Stack Trace VM API In-Reply-To: <20221102183638.81FCB54B4DD@eggemoggin.niobe.net> References: <20221102183638.81FCB54B4DD@eggemoggin.niobe.net> Message-ID: <50ec94a8-87d8-01a5-8234-6c71178382b8@oracle.com> On 3/11/2022 4:36 am, Mark Reinhold wrote: > https://openjdk.org/jeps/435 > > Summary: Define an efficient and reliable API to collect stack traces > asynchronously and include information on both Java and native stack > frames. There has been some commentary on this in the JBS issue and some previous discussion on the mailing list(s), which has left me a little unclear on some of the details. From the JEP: > Calling this API from a signal handler is safe, What is the definition of "safe" you are using in a signal handling context? The code is certainly executing a ton of stuff not known to be async-signal-safe. > and the new > implementation will be at least as stable as AsyncGetCallTrace or the > JFR stack walking code. If this is to be a supported API then it has to be more stable than the existing unsupported API. How is that stability achieved? What are the key differences with AGCT that make this more stable? Looking at the code I see in profile.h // This function must only be called when JVM/TI // CLASS_LOAD events have been enabled since agent startup. The enabled // event will cause the jmethodIDs to be allocated at class load time. // The jmethodIDs cannot be allocated in a signal handler because locks // cannot be grabbed in a signal handler safely. This relationship/dependency on JVM/TI is not mentioned in the JEP as far as I can see. Thanks, David From cjplummer at openjdk.org Thu Dec 22 06:03:48 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Dec 2022 06:03:48 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: <5thpMVnKb2Kz_wgP0zSW3DqQiRY24ZCgibk71QuQNhg=.9941d7a0-3044-403d-a189-3cd97cf6fcfe@github.com> On Tue, 20 Dec 2022 05:21:21 GMT, David Holmes wrote: >> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: >> >> Better comments. > > The JEP defines pinning as expected: >> There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier: >> >> When it executes code inside a synchronized block or method, or >> When it executes a native method or a [foreign function](https://openjdk.java.net/jeps/424). >> >> Pinning does not make an application incorrect, but it might hinder its scalability. If a virtual thread performs a blocking operation such as I/O or BlockingQueue.take() while it is pinned, then its carrier and the underlying OS thread are blocked for the duration of the operation. Frequent pinning for long durations can harm the scalability of an application by capturing carriers. > > But then also says: >> The scheduler does not compensate for pinning by expanding its parallelism. > > which contradicts what you quoted from Alan above - though I prefer that behaviour as the JEP's behaviour seems a design flaw to me. @dholmes-ora I initially took the approach of making sure each test that was ever running short of carrier threads explicitly requested the minimum it needed. It resulted in quite a few changes, and I still had one test that was occasionally failing. Possibly I just came up one short in the carrier thread calculation. I abandoned it for this PR because it's much simpler. Here's a PR I just created for those changes in case you want to have a look at what was involved: #11762. ------------- PR: https://git.openjdk.org/jdk/pull/11735 From dholmes at openjdk.org Thu Dec 22 06:25:48 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Dec 2022 06:25:48 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: <_8IySsNDNRcW-I_J1WW7ohoV8hSTHRme_KCdoVXNp_M=.d9402133-7ed8-429f-ac03-a3b6d33f7c9c@github.com> On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. > in case you want to have a look at what was involved: https://github.com/openjdk/jdk/pull/11762. Yeah that isn't nice. I was thinking a more simple check of the property value against the required number of threads. Though based on your comment "nthreads+1" is not always enough so the check would not be sufficient. ------------- PR: https://git.openjdk.org/jdk/pull/11735 From cjplummer at openjdk.org Thu Dec 22 06:45:07 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Dec 2022 06:45:07 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: <_8IySsNDNRcW-I_J1WW7ohoV8hSTHRme_KCdoVXNp_M=.d9402133-7ed8-429f-ac03-a3b6d33f7c9c@github.com> References: <_8IySsNDNRcW-I_J1WW7ohoV8hSTHRme_KCdoVXNp_M=.d9402133-7ed8-429f-ac03-a3b6d33f7c9c@github.com> Message-ID: On Thu, 22 Dec 2022 06:23:25 GMT, David Holmes wrote: > Yeah that isn't nice. I was thinking a more simple check of the property value against the required number of threads. Though based on your comment "nthreads+1" is not always enough so the check would not be sufficient. I think I can get past the nthreads + 1 issue. I believe in one test there is another vthread that I was not accounting for, so probably nthreads + 2 would work for that test. However, I don't quite understand your suggestion. Are you suggesting that after checking the property, if too small then I don't run the test and just have it pass? ------------- PR: https://git.openjdk.org/jdk/pull/11735 From johannes.bechberger at sap.com Thu Dec 22 08:24:05 2022 From: johannes.bechberger at sap.com (Bechberger, Johannes) Date: Thu, 22 Dec 2022 08:24:05 +0000 Subject: New candidate JEP: 435: Asynchronous Stack Trace VM API In-Reply-To: <50ec94a8-87d8-01a5-8234-6c71178382b8@oracle.com> References: <20221102183638.81FCB54B4DD@eggemoggin.niobe.net> <50ec94a8-87d8-01a5-8234-6c71178382b8@oracle.com> Message-ID: <2B233D2E-BDF7-46BC-815B-D14C0F060189@sap.com> > What is the definition of "safe" you are using in a signal handling context? The code is certainly executing a ton of stuff not known to be async-signal-safe. You're right, "safe" is the wrong word. I meant "stable" in the sense, that it is unlikely to crash your JVM. This is ensured by testing the implementation with fuzzing and stability tests. > If this is to be a supported API then it has to be more stable than the existing unsupported API. How is that stability achieved? What are the key differences with AGCT that make this more stable? Regarding the key differences: It is built with stability as a major concern, its implementation, therefore, contains more safety checks and is tested properly. Regards Johannes > This relationship/dependency on JVM/TI is not mentioned in the JEP as far as I can see. Good catch, I'll amend the JEP to mention the dependency: "You have to trigger the allocation of jmethodIDs outside the signal handler." ?On 22.12.22, 07:03, "serviceability-dev on behalf of David Holmes" wrote: On 3/11/2022 4:36 am, Mark Reinhold wrote: > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.org%2Fjeps%2F435&data=05%7C01%7Cjohannes.bechberger%40sap.com%7C0d2457dd80474937e97208dae3e239ab%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638072858015327140%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NIj3UlDXYvWFlrhypC1meAkB16FFbMtZPx%2BBOPOnjgs%3D&reserved=0 > > Summary: Define an efficient and reliable API to collect stack traces > asynchronously and include information on both Java and native stack > frames. There has been some commentary on this in the JBS issue and some previous discussion on the mailing list(s), which has left me a little unclear on some of the details. From the JEP: > Calling this API from a signal handler is safe, What is the definition of "safe" you are using in a signal handling context? The code is certainly executing a ton of stuff not known to be async-signal-safe. > and the new > implementation will be at least as stable as AsyncGetCallTrace or the > JFR stack walking code. If this is to be a supported API then it has to be more stable than the existing unsupported API. How is that stability achieved? What are the key differences with AGCT that make this more stable? Looking at the code I see in profile.h // This function must only be called when JVM/TI // CLASS_LOAD events have been enabled since agent startup. The enabled // event will cause the jmethodIDs to be allocated at class load time. // The jmethodIDs cannot be allocated in a signal handler because locks // cannot be grabbed in a signal handler safely. This relationship/dependency on JVM/TI is not mentioned in the JEP as far as I can see. Thanks, David From dholmes at openjdk.org Thu Dec 22 08:58:51 2022 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 Dec 2022 08:58:51 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. I'm suggesting the test reports failure if the parallelism level is too low - with a message to go and change the launcher/binder code. ------------- PR: https://git.openjdk.org/jdk/pull/11735 From johannes.bechberger at sap.com Thu Dec 22 12:49:14 2022 From: johannes.bechberger at sap.com (Bechberger, Johannes) Date: Thu, 22 Dec 2022 12:49:14 +0000 Subject: JEP Candidate 435: Asynchronous Stack Trace VM API Message-ID: <885612C5-75FA-4F88-8545-5D2556EFA6AA@sap.com> Hi all, I worked the last year on the JEP Candidate 435: It proposes essentially an official, extended, and better-tested version of AsyncGetCallTrace called AsyncGetStackTrace. The JEP Candidate can be found at https://openjdk.org/jeps/435, the code with several tests in the sandbox repository (branch asgst) and as a draft PR in https://github.com/openjdk/jdk/pull/11767. To see the proposed API in action, consider looking into the demo in the https://github.com/parttimenerd/asgct2-demo repository. I?m happy with all suggestions and opinions on my JEP and my implementation. Regards Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From iwalulya at openjdk.org Thu Dec 22 16:14:48 2022 From: iwalulya at openjdk.org (Ivan Walulya) Date: Thu, 22 Dec 2022 16:14:48 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett wrote: > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. Lgtm! ------------- Marked as reviewed by iwalulya (Reviewer). PR: https://git.openjdk.org/jdk20/pull/71 From cjplummer at openjdk.org Thu Dec 22 17:04:49 2022 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 22 Dec 2022 17:04:49 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Thu, 22 Dec 2022 08:55:40 GMT, David Holmes wrote: > I'm suggesting the test reports failure if the parallelism level is too low - with a message to go and change the launcher/binder code. Are saying that in addition to the changes in this PR I should also change each of the tests to add a check to make sure parallelism is set high enough? ------------- PR: https://git.openjdk.org/jdk/pull/11735 From sspitsyn at openjdk.org Thu Dec 22 20:01:52 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Dec 2022 20:01:52 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. This looks good besides what David is requesting. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.org/jdk/pull/11735 From sspitsyn at openjdk.org Thu Dec 22 20:18:59 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Dec 2022 20:18:59 GMT Subject: RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v2] In-Reply-To: References: Message-ID: <2z4gV3aDtKkV50pWAs-mLvlmITcV3v7rlg0WJ17Lajg=.2f7ef31e-42bf-48f6-bceb-e70c9136992c@github.com> On Wed, 23 Nov 2022 10:14:23 GMT, Serguei Spitsyn wrote: >> This problem has two sides. >> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value. >> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents` >> value has been set to `true` when an agent library is loaded into running VM. >> The fix is to get rid of this cashing. >> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization. >> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire. >> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync. >> >> Testing: >> The originally failed tests are passed now: >> >> runtime/vthread/RedefineClass.java >> runtime/vthread/TestObjectAllocationSampleEvent.java >> >> In progress: >> Run the tiers 1-6 to make sure there are no regression. > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > remove caching if notifyJvmtiEvents in yieldContinuation This is artificial comment to keep the PR alive. ------------- PR: https://git.openjdk.org/jdk/pull/11304 From pchilanomate at openjdk.org Thu Dec 22 22:08:52 2022 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Dec 2022 22:08:52 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: References: Message-ID: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com> On Wed, 21 Dec 2022 21:33:28 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts Hi Serguei, Some comments on the changes below. Thanks, Patricio src/hotspot/share/prims/jvmtiThreadState.cpp line 310: > 308: ml.wait(10); // wait while there is an active suspender or resumer > 309: } > 310: Atomic::inc(&_VTMS_transition_disable_for_one_count); I don't understand the purpose of this counter. We only seem to write to it and the only place where it is checked is to do a notify, but I don't see a corresponding check-and-wait on that counter somewhere else, as we do with _VTMS_transition_disable_for_all_count. src/hotspot/share/prims/jvmtiThreadState.cpp line 315: > 313: ml.wait(10); // wait while the virtual thread is in transition > 314: } > 315: java_lang_Thread::inc_VTMS_transition_disable_count(vth()); I think this sequence coupled with how start_VTMS_transition() works can have races. So the check vstate->is_in_VTMS_transition() could return false, but before we execute inc_VTMS_transition_disable_count() the target could have already called and returned from start_VTMS_transition(). Just to test this I added a nanosleep() call in between those two, and an assert before returning from JvmtiVTMSTransitionDisabler::JvmtiVTMSTransitionDisabler(jthread thread) that the target is not in the middle of a transition. Running the serviceability/jvmti/vthread/ tests gives me some crashes in that assert. Test patch: https://github.com/pchilano/jdk/commit/9bc22771bf324f69bc4f5a9786f1b21937aab3c7 If I compare with how the "disable all" case works, in there, the target transitioning sets a variable(_VTMS_transition_count) and then reads another one(_VTMS_transition_disable_for_all_count) set by the transition disabler. The transition disabler does the same but with the variables reversed, i.e. sets _VTMS_transition_disable_for_all_count and then reads _VTMS_transition_count. This correctly makes sure that if we read the value that allow us to return from the method then we have already written the flag that will stop the other thread. But in this "single" case I don't see the same pattern. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dcubed at openjdk.org Thu Dec 22 23:08:48 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Thu, 22 Dec 2022 23:08:48 GMT Subject: [jdk20] RFR: 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file Message-ID: <2SyCJO1JyxwwkVtJCUVTzWiyI8QxklnlJYm076bfEgI=.612b6e7a-f287-4d25-ba6c-3bc91663060e@github.com> A trivial fix to keep jdk/jfr/api/consumer/streaming/TestJVMCrash.java from generating an unnecessary core file. Ran TestJVMCrash.java on 10 configs in Mach5: linux-aarch64, linux-aarch64-debug, linux-x64, linux-x64-debug, macosx-aarch64, macosx-aarch64-debug, macosx-x64, macosx-x64-debug, windows-x64, and windows-x64-debug. All 10 .jtr files reported: CreateCoredumpOnCrash turned off, no core file dumped Also ran the open ":jdk_jfr" and closed JFR tests on all 10 platforms. No failures. ------------- Commit messages: - 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file Changes: https://git.openjdk.org/jdk20/pull/75/files Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=75&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8299241 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk20/pull/75.diff Fetch: git fetch https://git.openjdk.org/jdk20 pull/75/head:pull/75 PR: https://git.openjdk.org/jdk20/pull/75 From sspitsyn at openjdk.org Thu Dec 22 23:13:54 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 22 Dec 2022 23:13:54 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com> References: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com> Message-ID: On Thu, 22 Dec 2022 22:06:19 GMT, Patricio Chilano Mateo wrote: > Hi Serguei, > > Some comments on the changes below. > > Thanks, Patricio Thank you for reviewing it, Patricio! > src/hotspot/share/prims/jvmtiThreadState.cpp line 310: > >> 308: ml.wait(10); // wait while there is an active suspender or resumer >> 309: } >> 310: Atomic::inc(&_VTMS_transition_disable_for_one_count); > > I don't understand the purpose of this counter. We only seem to write to it and the only place where it is checked is to do a notify, but I don't see a corresponding check-and-wait on that counter somewhere else, as we do with _VTMS_transition_disable_for_all_count. Good catch. > Hi Serguei, > > Some comments on the changes below. > > Thanks, Patricio Thank you for reviewing it, Patricio! ------------- PR: https://git.openjdk.org/jdk/pull/11690 From coleenp at openjdk.org Fri Dec 23 00:16:57 2022 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 23 Dec 2022 00:16:57 GMT Subject: [jdk20] RFR: 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file In-Reply-To: <2SyCJO1JyxwwkVtJCUVTzWiyI8QxklnlJYm076bfEgI=.612b6e7a-f287-4d25-ba6c-3bc91663060e@github.com> References: <2SyCJO1JyxwwkVtJCUVTzWiyI8QxklnlJYm076bfEgI=.612b6e7a-f287-4d25-ba6c-3bc91663060e@github.com> Message-ID: On Thu, 22 Dec 2022 22:33:58 GMT, Daniel D. Daugherty wrote: > A trivial fix to keep jdk/jfr/api/consumer/streaming/TestJVMCrash.java from generating > an unnecessary core file. > > Ran TestJVMCrash.java on 10 configs in Mach5: linux-aarch64, linux-aarch64-debug, > linux-x64, linux-x64-debug, macosx-aarch64, macosx-aarch64-debug, macosx-x64, > macosx-x64-debug, windows-x64, and windows-x64-debug. All 10 .jtr files reported: > > CreateCoredumpOnCrash turned off, no core file dumped > > Also ran the open ":jdk_jfr" and closed JFR tests on all 10 platforms. No failures. Looks good + trivial. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.org/jdk20/pull/75 From sspitsyn at openjdk.org Fri Dec 23 00:28:52 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 23 Dec 2022 00:28:52 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com> References: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com> Message-ID: On Thu, 22 Dec 2022 21:55:02 GMT, Patricio Chilano Mateo wrote: >> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: >> >> use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts > > src/hotspot/share/prims/jvmtiThreadState.cpp line 315: > >> 313: ml.wait(10); // wait while the virtual thread is in transition >> 314: } >> 315: java_lang_Thread::inc_VTMS_transition_disable_count(vth()); > > I think this sequence coupled with how start_VTMS_transition() works can have races. So the check vstate->is_in_VTMS_transition() could return false, but before we execute inc_VTMS_transition_disable_count() the target could have already called and returned from start_VTMS_transition(). > Just to test this I added a nanosleep() call in between those two, and an assert before returning from JvmtiVTMSTransitionDisabler::JvmtiVTMSTransitionDisabler(jthread thread) that the target is not in the middle of a transition. Running the serviceability/jvmti/vthread/ tests gives me some crashes in that assert. Test patch: https://github.com/pchilano/jdk/commit/9bc22771bf324f69bc4f5a9786f1b21937aab3c7 > > If I compare with how the "disable all" case works, in there, the target transitioning sets a variable(_VTMS_transition_count) and then reads another one(_VTMS_transition_disable_for_all_count) set by the transition disabler. The transition disabler does the same but with the variables reversed, i.e. sets _VTMS_transition_disable_for_all_count and then reads _VTMS_transition_count. This correctly makes sure that if we read the value that allow us to return from the method then we have already written the flag that will stop the other thread. But in this "single" case I don't see the same pattern. I see the problem. Good catch, thanks! ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dcubed at openjdk.org Fri Dec 23 01:41:59 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 23 Dec 2022 01:41:59 GMT Subject: [jdk20] RFR: 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file In-Reply-To: References: <2SyCJO1JyxwwkVtJCUVTzWiyI8QxklnlJYm076bfEgI=.612b6e7a-f287-4d25-ba6c-3bc91663060e@github.com> Message-ID: On Fri, 23 Dec 2022 00:14:20 GMT, Coleen Phillimore wrote: >> A trivial fix to keep jdk/jfr/api/consumer/streaming/TestJVMCrash.java from generating >> an unnecessary core file. >> >> Ran TestJVMCrash.java on 10 configs in Mach5: linux-aarch64, linux-aarch64-debug, >> linux-x64, linux-x64-debug, macosx-aarch64, macosx-aarch64-debug, macosx-x64, >> macosx-x64-debug, windows-x64, and windows-x64-debug. All 10 .jtr files reported: >> >> CreateCoredumpOnCrash turned off, no core file dumped >> >> Also ran the open ":jdk_jfr" and closed JFR tests on all 10 platforms. No failures. > > Looks good + trivial. @coleenp - Thanks for the review! I'll likely integrate in the AM when I can better keep an eye on the CI... ------------- PR: https://git.openjdk.org/jdk20/pull/75 From dholmes at openjdk.org Fri Dec 23 03:29:49 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Dec 2022 03:29:49 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. > Are saying that in addition to the changes in this PR I should also change each of the tests to add a check to make sure parallelism is set high enough? I was, but now I see the tests involved and the fact this problem is just an artifact of running those tests in virtual threads, then I really don't want to see those tests polluted with VT specific code. I know more now about the issue with pinning on monitor entry and not being able to increase parallelism for that case - but ideally that would indeed by the fix and I'll look into that some more. But this fix is approved. Thanks. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/11735 From dholmes at openjdk.org Fri Dec 23 03:55:52 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Dec 2022 03:55:52 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: References: Message-ID: <1cusw61Gi5mniDMgMLWH0kQS3b02o5D--dUTcS9xTs8=.f633221e-d334-403f-93de-ebbfb81a8e13@github.com> On Wed, 21 Dec 2022 21:33:28 GMT, Serguei Spitsyn wrote: >> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. >> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. >> >> Testing: >> mach5 jobs are TBD (preliminary testing was completed): >> - all JVMTI, JDWP, JDI and JDB tests have to be run >> - Kitchensink >> - tier5 > > Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: > > use owned_by_self vs is_locked in JvmtiVTMSTransition_lock asserts Changes requested by dholmes (Reviewer). ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dholmes at openjdk.org Fri Dec 23 03:55:54 2022 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Dec 2022 03:55:54 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: References: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com> Message-ID: <6UL6R9_tf9tsHC-BfSryrSklaGzAWidbEoj3VvJ3Uaw=.371c4ade-e653-4623-aa1c-82b81df7901d@github.com> On Fri, 23 Dec 2022 00:26:02 GMT, Serguei Spitsyn wrote: >> src/hotspot/share/prims/jvmtiThreadState.cpp line 315: >> >>> 313: ml.wait(10); // wait while the virtual thread is in transition >>> 314: } >>> 315: java_lang_Thread::inc_VTMS_transition_disable_count(vth()); >> >> I think this sequence coupled with how start_VTMS_transition() works can have races. So the check vstate->is_in_VTMS_transition() could return false, but before we execute inc_VTMS_transition_disable_count() the target could have already called and returned from start_VTMS_transition(). >> Just to test this I added a nanosleep() call in between those two, and an assert before returning from JvmtiVTMSTransitionDisabler::JvmtiVTMSTransitionDisabler(jthread thread) that the target is not in the middle of a transition. Running the serviceability/jvmti/vthread/ tests gives me some crashes in that assert. Test patch: https://github.com/pchilano/jdk/commit/9bc22771bf324f69bc4f5a9786f1b21937aab3c7 >> >> If I compare with how the "disable all" case works, in there, the target transitioning sets a variable(_VTMS_transition_count) and then reads another one(_VTMS_transition_disable_for_all_count) set by the transition disabler. The transition disabler does the same but with the variables reversed, i.e. sets _VTMS_transition_disable_for_all_count and then reads _VTMS_transition_count. This correctly makes sure that if we read the value that allow us to return from the method then we have already written the flag that will stop the other thread. But in this "single" case I don't see the same pattern. > > I see the problem. Good catch, thanks! Yep my bad in earlier review. The one case needs the same synchronization/coordination as the all case. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From dcubed at openjdk.org Fri Dec 23 13:54:59 2022 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 23 Dec 2022 13:54:59 GMT Subject: [jdk20] Integrated: 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file In-Reply-To: <2SyCJO1JyxwwkVtJCUVTzWiyI8QxklnlJYm076bfEgI=.612b6e7a-f287-4d25-ba6c-3bc91663060e@github.com> References: <2SyCJO1JyxwwkVtJCUVTzWiyI8QxklnlJYm076bfEgI=.612b6e7a-f287-4d25-ba6c-3bc91663060e@github.com> Message-ID: <28ptT_xvl0ArVoi5bcyIioYXMv7pLwLZS1Ikqgw0tv4=.d64d5f3b-bbbd-447d-86c3-48906c9c55e3@github.com> On Thu, 22 Dec 2022 22:33:58 GMT, Daniel D. Daugherty wrote: > A trivial fix to keep jdk/jfr/api/consumer/streaming/TestJVMCrash.java from generating > an unnecessary core file. > > Ran TestJVMCrash.java on 10 configs in Mach5: linux-aarch64, linux-aarch64-debug, > linux-x64, linux-x64-debug, macosx-aarch64, macosx-aarch64-debug, macosx-x64, > macosx-x64-debug, windows-x64, and windows-x64-debug. All 10 .jtr files reported: > > CreateCoredumpOnCrash turned off, no core file dumped > > Also ran the open ":jdk_jfr" and closed JFR tests on all 10 platforms. No failures. This pull request has now been integrated. Changeset: 188911c9 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk20/commit/188911c925e4067c7f912c5ddb6f715bad7a3892 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod 8299241: jdk/jfr/api/consumer/streaming/TestJVMCrash.java generates unnecessary core file Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk20/pull/75 From sspitsyn at openjdk.org Sat Dec 24 04:14:07 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 24 Dec 2022 04:14:07 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v5] In-Reply-To: References: Message-ID: > Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different. > New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread. > > Testing: > mach5 jobs are TBD (preliminary testing was completed): > - all JVMTI, JDWP, JDI and JDB tests have to be run > - Kitchensink > - tier5 Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision: fix race between VTMS_transition_disable_for_one and start_VTMS_transition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/11690/files - new: https://git.openjdk.org/jdk/pull/11690/files/3c73fae3..3effc27d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11690&range=03-04 Stats: 38 lines in 7 files changed: 18 ins; 16 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/11690.diff Fetch: git fetch https://git.openjdk.org/jdk pull/11690/head:pull/11690 PR: https://git.openjdk.org/jdk/pull/11690 From sspitsyn at openjdk.org Sat Dec 24 04:45:48 2022 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 24 Dec 2022 04:45:48 GMT Subject: RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions [v4] In-Reply-To: <6UL6R9_tf9tsHC-BfSryrSklaGzAWidbEoj3VvJ3Uaw=.371c4ade-e653-4623-aa1c-82b81df7901d@github.com> References: <7s1CyW4SOVZDr43ozNlTD0sgG_qVkS60BcQrmSbCVd4=.50ea4b9d-91c4-41b0-9bc6-3f2b1d3cfeff@github.com> <6UL6R9_tf9tsHC-BfSryrSklaGzAWidbEoj3VvJ3Uaw=.371c4ade-e653-4623-aa1c-82b81df7901d@github.com> Message-ID: On Fri, 23 Dec 2022 03:53:19 GMT, David Holmes wrote: >> I see the problem. Good catch, thanks! > > Yep my bad in earlier review. The one case needs the same synchronization/coordination as the all case. I've moved the `is_in_VTMS_transition()` from `JvmtiThreadState` to `java_lang_Thread (in javaClasses.cpp)`. My initial implementation had this but at some point I decided to use `JvmtiThreadState::is_in_VTMS_transition()` for optimization purposes. It introduced a problem as the `JvmtiThreadState` can be absent at the point where it is needed for sync. I've also fixed race between `VTMS_transition_disable_for_one()` and `start_VTMS_transition()`. It was tested with the nanosleep delays and the assert from Patricio. Also, one assert has been removed from `jvmtiEnvThreadState.cpp` as it became not always correct. ------------- PR: https://git.openjdk.org/jdk/pull/11690 From kbarrett at openjdk.org Sat Dec 24 06:51:58 2022 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 24 Dec 2022 06:51:58 GMT Subject: [jdk20] RFR: 8293824: gc/whitebox/TestConcMarkCycleWB.java failed "RuntimeException: assertTrue: expected true, was false" In-Reply-To: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> References: <-LJBut4ETHYR8IDgKzvkumizSmDfB5uPUys0F282gfc=.152bea6b-1156-4280-a149-2cfe3a234a9c@github.com> Message-ID: On Thu, 22 Dec 2022 02:04:30 GMT, Kim Barrett wrote: > Please review this change to WhiteBox and some tests involving G1 concurrent GCs. > > Some tests currently use WhiteBox.g1StartConcMarkCycle() to trigger a > concurrent GC. Many of them follow it with a loop waiting for a concurrent > cycle to not be in progress. A few also preceed that call with a similar > loop, since that call does nothing and returns false if a concurrent cycle is > already in progress. Those tests typically want to ensure there was a > concurrent cycle that was started after some setup. > > The failing test calls that function, asserting that it returned true, e.g. a > new concurrent cycle was started. > > There are various problems with this, due to races with concurrent cycles > started automatically, and due to possibly aborted (by full GCs) concurrent cycles, > making some of these tests unreliable in some configurations. > > For example, the test failure associated with this bug intermittently arises > when running with `-Xcomp`, triggering a concurrent cycle before the explicit > request by the test, causing the explicit request to fail (because there is > already one in progress), failing the assert. Waiting for there not to be an > in-progress cycle before the explicit request just narrows the race window. > > We have a different mechanism in WhiteBox for controlling concurrent cycles, > the concurrent GC breakpoint mechanism. By adding a counter specifically for > such cycles, we can use GC breakpoints to ensure only the concurrent cycles > the test wants are occurring, and can verify they completed successfully. > > So we change tests using WhiteBox.g1StartConcMarkCycle() to instead use GC > breakpoints, along with the new WhiteBox.g1CompletedConcurrentMarkCycles() to > avoid racing request problems and to detect aborted cycles. Since it is no > longer used, WhiteBox.g1StartConcMarkCycle() is removed. The test that began > this adventure (TestConcMarkCycleWB.java) is also removed, since it no longer > serves any purpose, having been purely a test of that removed function. > > Testing: > mach5 tier1-7 - running the changed tests on a variety of platforms with a > variety of configurations. BTW, after this change `GCCause::_wb_conc_mark` appears to no longer ever be issued. I'm planning to remove it under the rubric of JDK-8235737. ------------- PR: https://git.openjdk.org/jdk20/pull/71 From mernst at openjdk.org Tue Dec 27 14:26:39 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Dec 2022 14:26:39 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v3] In-Reply-To: References: Message-ID: > 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni Michael Ernst has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge ../jdk-openjdk into typos-typos - Reinstate typos in Apache code that is copied into the JDK - Merge ../jdk-openjdk into typos-typos - Remove file that was removed upstream - Fix inconsistency in capitalization - Undo change in zlip - Fix typos ------------- Changes: https://git.openjdk.org/jdk/pull/10029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10029&range=02 Stats: 11 lines in 10 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/10029.diff Fetch: git fetch https://git.openjdk.org/jdk pull/10029/head:pull/10029 PR: https://git.openjdk.org/jdk/pull/10029 From mernst at openjdk.org Tue Dec 27 14:26:40 2022 From: mernst at openjdk.org (Michael Ernst) Date: Tue, 27 Dec 2022 14:26:40 GMT Subject: RFR: 8294321: Fix typos in files under test/jdk/java, test/jdk/jdk, test/jdk/jni [v2] In-Reply-To: References: Message-ID: On Mon, 28 Nov 2022 09:00:09 GMT, Jaikiran Pai wrote: >> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. > >> Could someone who knows the undocumented ins and outs of creating JDK pull requests could split this pull request up into multiple PRs? Then it can be merged, rather than wasting all the effort that went into it. > > I've raised https://github.com/openjdk/jdk/pull/11385 for one set of changes from this current PR. I'll pick up the other ones shortly in different PRs. Many thanks to those (especially @jaikiran) who helped to merge many of these typo fixes. I have pulled master and resolved merge conflicts. Only 11 typo fixes remain. Could someone shepherd those into the codebase? Thanks! ------------- PR: https://git.openjdk.org/jdk/pull/10029 From alanb at openjdk.org Thu Dec 29 08:45:48 2022 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Dec 2022 08:45:48 GMT Subject: RFR: 8285416: [LOOM] Some nsk/jdi tests fail due to needing too many virtual threads [v2] In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 02:25:38 GMT, Chris Plummer wrote: >> There are a few nsk debugger tests that pin multiple virtual threads to carrier threads when synchronizing. Sometime the default number of carrier threads (which equals the number of CPUs) is not enough, and the test deadlocks because virtual threads start to wait forever for an available carrier thread. This PR fixes this problem by using the `jdk.virtualThreadScheduler.parallelism` property to change the default number of carrier threads. I believe the largest number of carrier threads any test needs is 11, so I chose 15 just to be safe. >> >> I had initially tried to fix each individual test by using the test support in `VThreadRunner.setParallism()`. The advantage of this was limiting the scope of the change to just a few tests, and also being able to specify the exact number of needed carrier threads. The disadvantage was having to make quite a few changes to quite a few tests, plus I had one troublesome test that was still failing, I believe because I didn't fully understand how many carrier threads it needed. Just giving every test 15 carrier threads in the end was a lot easier. > > Chris Plummer has updated the pull request incrementally with one additional commit since the last revision: > > Better comments. Marked as reviewed by alanb (Reviewer). The proposed change looks okay and a lot more maintainable than adjusting specific tests. ------------- PR: https://git.openjdk.org/jdk/pull/11735