From magnus.ihse.bursie at oracle.com Tue Apr 1 11:23:32 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 1 Apr 2025 13:23:32 +0200 Subject: Reducing "unrelated" requests to jdk-dev In-Reply-To: References: Message-ID: On 2025-03-29 07:28, Eirik Bj?rsn?s wrote: > > Hi, > > A good?chunk of messages on this list are from newly signed up, > non-author/committers posting questions/feature requests which then > needs fielding to more appropriate lists. > > While there is nothing particularly harmful to this situation, it does > introduce a bit of overhead for the poster, for the people doing the > fielding and for all other subscribers to the list. > > Could something be done to help people find a more appropriate list > before posting? > > The Mailman about page [1] initial paragraph is very inclusive, seems > to invite any "technical" question and says nothing?about > process-related communications, like voting for new committers/reviewers. > > This list is for the discussion of general technical issues > related to the development of the current JDK main-line feature > release. > > > The second sentence is helpful, but maybe not super clear: > > Please use a more narrowly-focused list (e.g., core-libs-dev or > hotspot-dev) if appropriate. > > Maybe some tweaks to these sentences could make it more clear what > this list is about and how to find a better list to ask questions. > > Thoughts? That sounds like a good idea. The text should make it clear thatthis list discusses broad or project-wide technical issues for the JDK development, and that more specific lists should be used, if possible. It would not hurt to put in some extra wording about how this is not a general Java development list. It could perhaps also help if first-time posters were checked by a moderator, but repeated posters and long-term list members could be whitelisted to bypass moderation. I'm not sure if anyone is willing to take on such a job, though. /Magnus > > Eirik. > > [1] https://mail.openjdk.org/mailman/listinfo/jdk-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.castaneda.lozano at oracle.com Thu Apr 3 07:37:02 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Thu, 3 Apr 2025 07:37:02 +0000 Subject: CFV: New JDK Committer: Daniel Skantz Message-ID: I hereby nominate Daniel Skantz to JDK Committer. Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: https://github.com/openjdk/jdk/pull/24350 https://github.com/openjdk/jdk/pull/22482 https://github.com/openjdk/jdk/pull/22481 https://github.com/openjdk/jdk/pull/19646 https://github.com/openjdk/jdk/pull/19095 https://github.com/openjdk/jdk/pull/15938 https://github.com/openjdk/jdk/pull/14492 https://github.com/openjdk/jdk/pull/12683 https://github.com/openjdk/jdk/pull/22823 Votes are due by Thursday, 17 April 2025 at 09:00 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best Regards, Roberto Casta?eda Lozano [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote From roberto.castaneda.lozano at oracle.com Thu Apr 3 07:40:20 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Thu, 3 Apr 2025 07:40:20 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes ________________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Thursday, April 3, 2025 9:37 AM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Daniel Skantz I hereby nominate Daniel Skantz to JDK Committer. Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: https://github.com/openjdk/jdk/pull/24350 https://github.com/openjdk/jdk/pull/22482 https://github.com/openjdk/jdk/pull/22481 https://github.com/openjdk/jdk/pull/19646 https://github.com/openjdk/jdk/pull/19095 https://github.com/openjdk/jdk/pull/15938 https://github.com/openjdk/jdk/pull/14492 https://github.com/openjdk/jdk/pull/12683 https://github.com/openjdk/jdk/pull/22823 Votes are due by Thursday, 17 April 2025 at 09:00 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best Regards, Roberto Casta?eda Lozano [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote From daniel.lunden at oracle.com Thu Apr 3 07:47:00 2025 From: daniel.lunden at oracle.com (Daniel Lunden) Date: Thu, 3 Apr 2025 07:47:00 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes ________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Thursday, 3 April 2025 09:37 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Daniel Skantz I hereby nominate Daniel Skantz to JDK Committer. Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: https://github.com/openjdk/jdk/pull/24350 https://github.com/openjdk/jdk/pull/22482 https://github.com/openjdk/jdk/pull/22481 https://github.com/openjdk/jdk/pull/19646 https://github.com/openjdk/jdk/pull/19095 https://github.com/openjdk/jdk/pull/15938 https://github.com/openjdk/jdk/pull/14492 https://github.com/openjdk/jdk/pull/12683 https://github.com/openjdk/jdk/pull/22823 Votes are due by Thursday, 17 April 2025 at 09:00 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best Regards, Roberto Casta?eda Lozano [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Apr 3 08:58:54 2025 From: david.holmes at oracle.com (David Holmes) Date: Thu, 3 Apr 2025 18:58:54 +1000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <35644f70-7dfb-4dcb-99e7-3ba7474ff045@oracle.com> Vote: yes David On 3/04/2025 5:37 pm, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From adinn at redhat.com Thu Apr 3 09:48:49 2025 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 3 Apr 2025 10:48:49 +0100 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes On 03/04/2025 08:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From johan.sjolen at oracle.com Thu Apr 3 09:49:21 2025 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Thu, 3 Apr 2025 09:49:21 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes Johan ________________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Thursday, April 3, 2025 09:37 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Daniel Skantz I hereby nominate Daniel Skantz to JDK Committer. Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: https://github.com/openjdk/jdk/pull/24350 https://github.com/openjdk/jdk/pull/22482 https://github.com/openjdk/jdk/pull/22481 https://github.com/openjdk/jdk/pull/19646 https://github.com/openjdk/jdk/pull/19095 https://github.com/openjdk/jdk/pull/15938 https://github.com/openjdk/jdk/pull/14492 https://github.com/openjdk/jdk/pull/12683 https://github.com/openjdk/jdk/pull/22823 Votes are due by Thursday, 17 April 2025 at 09:00 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best Regards, Roberto Casta?eda Lozano [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote From rehn at rivosinc.com Thu Apr 3 10:18:12 2025 From: rehn at rivosinc.com (Robbin Ehn) Date: Thu, 3 Apr 2025 12:18:12 +0200 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes /Robbin On Thu, Apr 3, 2025 at 9:37?AM Roberto Castaneda Lozano wrote: > > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From aleksej.efimov at oracle.com Thu Apr 3 10:45:35 2025 From: aleksej.efimov at oracle.com (Aleksei Efimov) Date: Thu, 3 Apr 2025 10:45:35 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes - Aleksei ________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Thursday 3 April 2025 8:37 am To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Daniel Skantz I hereby nominate Daniel Skantz to JDK Committer. Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: https://github.com/openjdk/jdk/pull/24350 https://github.com/openjdk/jdk/pull/22482 https://github.com/openjdk/jdk/pull/22481 https://github.com/openjdk/jdk/pull/19646 https://github.com/openjdk/jdk/pull/19095 https://github.com/openjdk/jdk/pull/15938 https://github.com/openjdk/jdk/pull/14492 https://github.com/openjdk/jdk/pull/12683 https://github.com/openjdk/jdk/pull/22823 Votes are due by Thursday, 17 April 2025 at 09:00 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best Regards, Roberto Casta?eda Lozano [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From shipilev at amazon.de Thu Apr 3 11:01:46 2025 From: shipilev at amazon.de (Aleksey Shipilev) Date: Thu, 3 Apr 2025 13:01:46 +0200 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <9de51def-1cfc-40dd-a0ef-070fd68864bb@amazon.de> Vote: yes On 03.04.25 09:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. From sean.coffey at oracle.com Thu Apr 3 11:48:28 2025 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=C3=A1n_Coffey?=) Date: Thu, 3 Apr 2025 12:48:28 +0100 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes Sean. On 03/04/2025 08:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. From dmitry.markov at oracle.com Thu Apr 3 12:26:40 2025 From: dmitry.markov at oracle.com (Dmitrii Markov) Date: Thu, 3 Apr 2025 12:26:40 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes Regards, Dmitrii From: jdk-dev on behalf of Roberto Castaneda Lozano Date: Thursday, 3 April 2025 at 08:37 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Daniel Skantz I hereby nominate Daniel Skantz to JDK Committer. Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: https://github.com/openjdk/jdk/pull/24350 https://github.com/openjdk/jdk/pull/22482 https://github.com/openjdk/jdk/pull/22481 https://github.com/openjdk/jdk/pull/19646 https://github.com/openjdk/jdk/pull/19095 https://github.com/openjdk/jdk/pull/15938 https://github.com/openjdk/jdk/pull/14492 https://github.com/openjdk/jdk/pull/12683 https://github.com/openjdk/jdk/pull/22823 Votes are due by Thursday, 17 April 2025 at 09:00 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best Regards, Roberto Casta?eda Lozano [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From jesper.wilhelmsson at oracle.com Thu Apr 3 13:55:41 2025 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 3 Apr 2025 13:55:41 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: Yes /Jesper > On 3 Apr 2025, at 09:37, Roberto Castaneda Lozano wrote: > > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From mark.reinhold at oracle.com Thu Apr 3 17:29:13 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 3 Apr 2025 17:29:13 +0000 Subject: Proposed schedule for JDK 25 Message-ID: <20250403132912.2149689@eggemoggin.niobe.net> Here is the proposed schedule for JDK 25: 2025/06/05 Rampdown Phase One 2025/07/17 Rampdown Phase Two 2025/08/07 Initial Release Candidate 2025/08/21 Final Release Candidate 2025/09/16 General Availability The phases are defined in JEP 3 [1]. Comments on this proposal from JDK Committers and Reviewers [2] are welcome, as are reasoned objections. If no such objections are raised by 18:00 UTC next Thursday, 10 April, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [3] this will be the schedule for JDK 24. - Mark [1] https://openjdk.org/jeps/3 [2] https://openjdk.org/census#jdk [3] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From joe.darcy at oracle.com Thu Apr 3 19:26:56 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 3 Apr 2025 12:26:56 -0700 Subject: Reminder: file JDK 25 CSRs well ahead of rampdown 1 start Message-ID: <4de125c1-d88b-45a2-9212-14df06a69a3c@oracle.com> Hello, Per the proposed JDK 25 schedule (https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009870.html), the rampdown 1 of JDK 25 would start on June 5, 2025, nine weeks from today. An advanced reminder to factor in sufficient review time for any projects needing CSR review before getting pushed into JDK 25, which includes JEPs. Large projects, including JEPs, should often use the two-phase CSR process (https://wiki.openjdk.java.net/display/csr/Main) rather than the one-phase process. The nominal SLA for each CSR phase is one week. To accommodate the possibility of needing to respond to feedback from the CSR, I recommend a large project that has not already had CSR review budget at least four weeks of CSR review time ahead of an anticipated integration date. Particularly large or complex projects should factor in additional time. A JEP should have gone through the first phase of CSR review, getting to Provisional state, before being Proposed to Target for a release. Please plan accordingly. Cheers, -Joe CSR Lead From vladimir.kozlov at oracle.com Thu Apr 3 19:48:48 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Apr 2025 12:48:48 -0700 Subject: CFV: New JDK Reviewer: Eric Caspole Message-ID: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org From vladimir.kozlov at oracle.com Thu Apr 3 19:51:02 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Apr 2025 12:51:02 -0700 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes Thanks, Vladimir K On 4/3/25 12:37 AM, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From philip.race at oracle.com Thu Apr 3 19:51:15 2025 From: philip.race at oracle.com (Philip Race) Date: Thu, 3 Apr 2025 12:51:15 -0700 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <31a2022f-a59d-4c4e-80b9-3f726d3575f6@oracle.com> Vote: yes -phil. From vladimir.kozlov at oracle.com Thu Apr 3 19:52:05 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 3 Apr 2025 12:52:05 -0700 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes Thanks, Vladimir K On 4/3/25 12:48 PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't > have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From vladimir.x.ivanov at oracle.com Thu Apr 3 20:00:55 2025 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Apr 2025 13:00:55 -0700 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 4/3/25 12:48, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. From vladimir.x.ivanov at oracle.com Thu Apr 3 20:01:59 2025 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 3 Apr 2025 13:01:59 -0700 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes Best regards, Vladimir Ivanov On 4/3/25 00:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. From ysr at amazon.com Thu Apr 3 20:30:00 2025 From: ysr at amazon.com (Ramakrishna, Ramki) Date: Thu, 3 Apr 2025 20:30:00 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole Message-ID: <3E28EB7E-7822-4D4A-9258-DFE3D8F32E64@amazon.com> Vote: yes / Ramki (openjdk: ysr) ? ------------------------------ Message: 3 Date: Thu, 3 Apr 2025 12:48:48 -0700 From: Vladimir Kozlov > To: jdk-dev > Subject: CFV: New JDK Reviewer: Eric Caspole Message-ID: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4 at oracle.com > Content-Type: text/plain; charset=UTF-8; format=flowed I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org From dean.long at oracle.com Thu Apr 3 21:05:11 2025 From: dean.long at oracle.com (Dean Long) Date: Thu, 3 Apr 2025 14:05:11 -0700 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes From adinn at redhat.com Thu Apr 3 21:28:38 2025 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 3 Apr 2025 22:28:38 +0100 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <48a0b4ce-72ad-464a-9175-c6dbc0098c1c@redhat.com> Vote: yes On 03/04/2025 20:48, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the past > 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/? > author=ecaspole%40openjdk.org > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From mainframelucy at gmail.com Thu Apr 3 21:47:42 2025 From: mainframelucy at gmail.com (Lutz Schmidt) Date: Thu, 3 Apr 2025 23:47:42 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes /Lutz On 3. Apr 2025, at 21:48, Vladimir Kozlov wrote: I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org From roger.riggs at oracle.com Thu Apr 3 21:48:09 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 3 Apr 2025 17:48:09 -0400 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <8a3be531-90dd-4850-887a-c299758bb885@oracle.com> Vote: Yes On 4/3/25 3:48 PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. From mainframelucy at gmail.com Thu Apr 3 21:51:01 2025 From: mainframelucy at gmail.com (Lutz Schmidt) Date: Thu, 3 Apr 2025 23:51:01 +0200 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <0C11CA30-AFA4-44FC-A4CA-D26A9EDBB576@gmail.com> Vote: yes /Lutz On 3. Apr 2025, at 09:37, Roberto Castaneda Lozano wrote: I hereby nominate Daniel Skantz to JDK Committer. Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: https://github.com/openjdk/jdk/pull/24350 https://github.com/openjdk/jdk/pull/22482 https://github.com/openjdk/jdk/pull/22481 https://github.com/openjdk/jdk/pull/19646 https://github.com/openjdk/jdk/pull/19095 https://github.com/openjdk/jdk/pull/15938 https://github.com/openjdk/jdk/pull/14492 https://github.com/openjdk/jdk/pull/12683 https://github.com/openjdk/jdk/pull/22823 Votes are due by Thursday, 17 April 2025 at 09:00 UTC. Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Best Regards, Roberto Casta?eda Lozano [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated [2] https://openjdk.org/census [3] https://openjdk.org/projects/#committer-vote From jesper.wilhelmsson at oracle.com Thu Apr 3 23:35:28 2025 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 3 Apr 2025 23:35:28 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <0952B123-149E-41DF-8F72-45386FB5289F@oracle.com> Vote: Yes /Jesper > On 3 Apr 2025, at 21:48, Vladimir Kozlov wrote: > > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From brent.christian at oracle.com Fri Apr 4 02:01:10 2025 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 3 Apr 2025 19:01:10 -0700 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: Yes On 4/3/25 12:48 PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > From jayathirth.d.v at oracle.com Fri Apr 4 02:45:47 2025 From: jayathirth.d.v at oracle.com (Jayathirth Rao Daarapuram Venkatesh Murthy) Date: Fri, 4 Apr 2025 02:45:47 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote : Yes Thanks, Jay From: jdk-dev on behalf of Vladimir Kozlov Date: Friday, 4 April 2025 at 1:37?AM To: jdk-dev Subject: CFV: New JDK Reviewer: Eric Caspole I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From djelinski1 at gmail.com Fri Apr 4 04:23:05 2025 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Fri, 4 Apr 2025 06:23:05 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes czw., 3 kwi 2025, 21:49 u?ytkownik Vladimir Kozlov < vladimir.kozlov at oracle.com> napisa?: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't > have regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Fri Apr 4 06:09:10 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 4 Apr 2025 16:09:10 +1000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <6b75707f-1898-444e-9c58-c9a7370440f5@oracle.com> Vote: yes David On 4/04/2025 5:48 am, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From thomas.stuefe at gmail.com Fri Apr 4 07:16:29 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 4 Apr 2025 09:16:29 +0200 Subject: The future of 32-bit? Message-ID: Hi, Continuing our discussion at the last FOSDEM workshop, I would like to know what we think about the future of 32-bit support. Supporting 32-bit became a lot more cumbersome after the x86 port was removed. Before, one could easily build 32-bit on the ubiquitous x64 platforms with --target-bits=32; that is not an option anymore. We have two remaining 32-bit platforms, at least in theory: - arm32 - zero 32-bit Zero 32-bit has been broken for a long while now; see https://bugs.openjdk.org/browse/JDK-8353699. I try this occasionally and don't remember the last time it built successfully. Arm32 is the last bastion of serious 32-bit support, and the last option for testing 32-bit coding. So, one needs to build arm32 (best done via crossbuild), then spin up an arm32 system to test the changes. I do this with a slow-as-molasses Raspberry. It is not fun. Unfortunately, maintaining 32-bit is not as easy as "make sure it builds and fix smaller things". It requires real development, especially in the context of ongoing object header work. 32-bit also means we need to keep some form of uncompressed class pointers around, which makes the eventual removal of uncompressed class pointers (see [2]) more difficult. The current plan is to implement some sort of fake-compressed-class-pointer mode [3], which sounds easy in theory but is still tricky work I'd rather avoid. Keeping up 32-bit development in the face of dwindling options to build and test is a struggle. It has been a struggle for some time now. Even the comparatively well-maintained arm32 platform had periodic weeks of brokenness after heavy upstream changes. And this is not intended to diminish the effort put in by the arm32-maintainers. They are few, and they do good work. But I expect this periodic brokenness to worsen now after the removal of x86. This is not a good situation. Thank you, Thomas [1] https://bugs.openjdk.org/browse/JDK-8353699 [2] https://bugs.openjdk.org/browse/JDK-8350754 [3] https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tstuefe at redhat.com Fri Apr 4 08:27:24 2025 From: tstuefe at redhat.com (Thomas Stuefe) Date: Fri, 4 Apr 2025 10:27:24 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes On Thu, Apr 3, 2025 at 9:50?PM Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't > have regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johan.vos at gluonhq.com Fri Apr 4 09:17:15 2025 From: johan.vos at gluonhq.com (Johan Vos) Date: Fri, 4 Apr 2025 11:17:15 +0200 Subject: The future of 32-bit? In-Reply-To: References: Message-ID: Hi Thomas, all, At the OCW workshop, I expressed my worries about removing all 32-bit code, because I feared it would impact the ability to distribute Java apps to mobile devices (via the existing stores). As someone pointed out, at the very least 32-bit versions are not a requirement anymore. I did a bit of research, and while there are still 32-bit devices in the field, the 2 major stores are pushing for 64-bits, and discouraging 32 bits -- something we would call @Deprecated(forRemoval="true"). As a consequence, zero-32 code is no requirement for iOS, and arm-32 is no requirement for Android. There are still usecases for the Pi Zero (v1) and older Raspberry Pi devices (< 3). I have no idea about the installed base of those devices, but I believe it is possible that this would be the largest group that will suffer if 32-bit support was halted. Having said that, I fully agree there is lots of additional work required to keep 32-bit support (the (un)compressed classpointers are a good example indeed). Though situation. - Johan On Fri, Apr 4, 2025 at 9:17?AM Thomas St?fe wrote: > Hi, > > Continuing our discussion at the last FOSDEM workshop, I would like to > know what we think about the future of 32-bit support. > > Supporting 32-bit became a lot more cumbersome after the x86 port was > removed. Before, one could easily build 32-bit on the ubiquitous x64 > platforms with --target-bits=32; that is not an option anymore. > > We have two remaining 32-bit platforms, at least in theory: > > - arm32 > - zero 32-bit > > Zero 32-bit has been broken for a long while now; see > https://bugs.openjdk.org/browse/JDK-8353699. I try this occasionally and > don't remember the last time it built successfully. > > Arm32 is the last bastion of serious 32-bit support, and the last option > for testing 32-bit coding. So, one needs to build arm32 (best done via > crossbuild), then spin up an arm32 system to test the changes. I do this > with a slow-as-molasses Raspberry. It is not fun. > > Unfortunately, maintaining 32-bit is not as easy as "make sure it builds > and fix smaller things". It requires real development, especially in the > context of ongoing object header work. > > 32-bit also means we need to keep some form of uncompressed class pointers > around, which makes the eventual removal of uncompressed class pointers > (see [2]) more difficult. The current plan is to implement some sort of > fake-compressed-class-pointer mode [3], which sounds easy in theory but is > still tricky work I'd rather avoid. > > Keeping up 32-bit development in the face of dwindling options to build > and test is a struggle. It has been a struggle for some time now. Even the > comparatively well-maintained arm32 platform had periodic weeks of > brokenness after heavy upstream changes. And this is not intended to > diminish the effort put in by the arm32-maintainers. They are few, and they > do good work. > > But I expect this periodic brokenness to worsen now after the removal of > x86. This is not a good situation. > > Thank you, Thomas > > [1] https://bugs.openjdk.org/browse/JDK-8353699 > [2] https://bugs.openjdk.org/browse/JDK-8350754 > [3] > https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.johansson at oracle.com Fri Apr 4 09:35:41 2025 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 4 Apr 2025 11:35:41 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <128285d9-d2f5-4c8a-bc5d-1e5c5f8debff@oracle.com> Vote: yes /StefanJ On 2025-04-03 21:48, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefan.johansson at oracle.com Fri Apr 4 09:36:11 2025 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Fri, 4 Apr 2025 11:36:11 +0200 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <37fa53d1-172a-4a1f-afd5-fd33d474fc27@oracle.com> Vote: yes /StefanJ On 2025-04-03 09:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1]https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2]https://openjdk.org/census > [3]https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobias.hartmann at oracle.com Fri Apr 4 09:56:22 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 4 Apr 2025 11:56:22 +0200 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <2129e457-fb3f-4b26-adde-b2bf7253618d@oracle.com> Vote: yes Best regards, Tobias On 4/3/25 09:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From tobias.hartmann at oracle.com Fri Apr 4 09:57:37 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 4 Apr 2025 11:57:37 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <60f7b7ef-a233-4145-b4f9-c6231436d579@oracle.com> Vote: yes Best regards, Tobias On 4/3/25 21:48, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From damon.fenacci at oracle.com Fri Apr 4 10:17:17 2025 From: damon.fenacci at oracle.com (Damon Fenacci) Date: Fri, 4 Apr 2025 10:17:17 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes Damon > On 3 Apr 2025, at 09:37, Roberto Castaneda Lozano wrote: > > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From martin.doerr at sap.com Fri Apr 4 10:25:07 2025 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 4 Apr 2025 10:25:07 +0000 Subject: AW: The future of 32-bit? In-Reply-To: References: Message-ID: Hi all, even if we deprecate 32 bit now, arm32 will still be usable with JDK 25 LTS for quite some time. The big question is if there will still be a significant demand in 2 years. I also wonder when other projects will terminate arm32 support. Best regards, Martin Von: jdk-dev im Auftrag von Johan Vos Datum: Freitag, 4. April 2025 um 11:17 An: Thomas St?fe Cc: JDK Dev list Betreff: Re: The future of 32-bit? Hi Thomas, all, At the OCW workshop, I expressed my worries about removing all 32-bit code, because I feared it would impact the ability to distribute Java apps to mobile devices (via the existing stores). As someone pointed out, at the very least 32-bit versions are not a requirement anymore. I did a bit of research, and while there are still 32-bit devices in the field, the 2 major stores are pushing for 64-bits, and discouraging 32 bits -- something we would call @Deprecated(forRemoval="true"). As a consequence, zero-32 code is no requirement for iOS, and arm-32 is no requirement for Android. There are still usecases for the Pi Zero (v1) and older Raspberry Pi devices (< 3). I have no idea about the installed base of those devices, but I believe it is possible that this would be the largest group that will suffer if 32-bit support was halted. Having said that, I fully agree there is lots of additional work required to keep 32-bit support (the (un)compressed classpointers are a good example indeed). Though situation. - Johan On Fri, Apr 4, 2025 at 9:17?AM Thomas St?fe > wrote: Hi, Continuing our discussion at the last FOSDEM workshop, I would like to know what we think about the future of 32-bit support. Supporting 32-bit became a lot more cumbersome after the x86 port was removed. Before, one could easily build 32-bit on the ubiquitous x64 platforms with --target-bits=32; that is not an option anymore. We have two remaining 32-bit platforms, at least in theory: - arm32 - zero 32-bit Zero 32-bit has been broken for a long while now; see https://bugs.openjdk.org/browse/JDK-8353699. I try this occasionally and don't remember the last time it built successfully. Arm32 is the last bastion of serious 32-bit support, and the last option for testing 32-bit coding. So, one needs to build arm32 (best done via crossbuild), then spin up an arm32 system to test the changes. I do this with a slow-as-molasses Raspberry. It is not fun. Unfortunately, maintaining 32-bit is not as easy as "make sure it builds and fix smaller things". It requires real development, especially in the context of ongoing object header work. 32-bit also means we need to keep some form of uncompressed class pointers around, which makes the eventual removal of uncompressed class pointers (see [2]) more difficult. The current plan is to implement some sort of fake-compressed-class-pointer mode [3], which sounds easy in theory but is still tricky work I'd rather avoid. Keeping up 32-bit development in the face of dwindling options to build and test is a struggle. It has been a struggle for some time now. Even the comparatively well-maintained arm32 platform had periodic weeks of brokenness after heavy upstream changes. And this is not intended to diminish the effort put in by the arm32-maintainers. They are few, and they do good work. But I expect this periodic brokenness to worsen now after the removal of x86. This is not a good situation. Thank you, Thomas [1] https://bugs.openjdk.org/browse/JDK-8353699 [2] https://bugs.openjdk.org/browse/JDK-8350754 [3] https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zjx001202 at gmail.com Fri Apr 4 10:40:37 2025 From: zjx001202 at gmail.com (Glavo) Date: Fri, 4 Apr 2025 18:40:37 +0800 Subject: The future of 32-bit? In-Reply-To: References: Message-ID: Hi, I think 32-bit is not abandoned by everyone. As far as I know, new architectures like RISC-V and LoongArch still have 32-bit variants and do have users using them. Although these 32-bit variants are often used in resource-constrained scenarios such as embedded systems, and their users may not be very interested in Java, I still don't want to see OpenJDK completely abandon the possibility of supporting them. Glavo On Fri, Apr 4, 2025 at 3:16?PM Thomas St?fe wrote: > Hi, > > Continuing our discussion at the last FOSDEM workshop, I would like to > know what we think about the future of 32-bit support. > > Supporting 32-bit became a lot more cumbersome after the x86 port was > removed. Before, one could easily build 32-bit on the ubiquitous x64 > platforms with --target-bits=32; that is not an option anymore. > > We have two remaining 32-bit platforms, at least in theory: > > - arm32 > - zero 32-bit > > Zero 32-bit has been broken for a long while now; see > https://bugs.openjdk.org/browse/JDK-8353699. I try this occasionally and > don't remember the last time it built successfully. > > Arm32 is the last bastion of serious 32-bit support, and the last option > for testing 32-bit coding. So, one needs to build arm32 (best done via > crossbuild), then spin up an arm32 system to test the changes. I do this > with a slow-as-molasses Raspberry. It is not fun. > > Unfortunately, maintaining 32-bit is not as easy as "make sure it builds > and fix smaller things". It requires real development, especially in the > context of ongoing object header work. > > 32-bit also means we need to keep some form of uncompressed class pointers > around, which makes the eventual removal of uncompressed class pointers > (see [2]) more difficult. The current plan is to implement some sort of > fake-compressed-class-pointer mode [3], which sounds easy in theory but is > still tricky work I'd rather avoid. > > Keeping up 32-bit development in the face of dwindling options to build > and test is a struggle. It has been a struggle for some time now. Even the > comparatively well-maintained arm32 platform had periodic weeks of > brokenness after heavy upstream changes. And this is not intended to > diminish the effort put in by the arm32-maintainers. They are few, and they > do good work. > > But I expect this periodic brokenness to worsen now after the removal of > x86. This is not a good situation. > > Thank you, Thomas > > [1] https://bugs.openjdk.org/browse/JDK-8353699 > [2] https://bugs.openjdk.org/browse/JDK-8350754 > [3] > https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.castaneda.lozano at oracle.com Fri Apr 4 11:42:05 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Fri, 4 Apr 2025 11:42:05 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes ________________________________________ From: jdk-dev on behalf of Vladimir Kozlov Sent: Thursday, April 3, 2025 9:48 PM To: jdk-dev Subject: CFV: New JDK Reviewer: Eric Caspole I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org From ivan.walulya at oracle.com Fri Apr 4 11:45:11 2025 From: ivan.walulya at oracle.com (Ivan Walulya) Date: Fri, 4 Apr 2025 11:45:11 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <265A91E0-D148-4414-B73E-01E72A61EDF5@oracle.com> Vote: yes // Ivan > On 3 Apr 2025, at 21:48, Vladimir Kozlov wrote: > > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From johan.sjolen at oracle.com Fri Apr 4 11:44:58 2025 From: johan.sjolen at oracle.com (Johan Sjolen) Date: Fri, 4 Apr 2025 11:44:58 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes Johan ________________________________________ From: jdk-dev on behalf of Roberto Castaneda Lozano Sent: Friday, April 4, 2025 13:42 To: Vladimir Kozlov; jdk-dev Subject: Re: CFV: New JDK Reviewer: Eric Caspole Vote: yes ________________________________________ From: jdk-dev on behalf of Vladimir Kozlov Sent: Thursday, April 3, 2025 9:48 PM To: jdk-dev Subject: CFV: New JDK Reviewer: Eric Caspole I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org From lois.foltan at oracle.com Fri Apr 4 12:48:24 2025 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 4 Apr 2025 12:48:24 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes Lois From: jdk-dev on behalf of Vladimir Kozlov Date: Thursday, April 3, 2025 at 4:07?PM To: jdk-dev Subject: CFV: New JDK Reviewer: Eric Caspole I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Fri Apr 4 12:49:49 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 04 Apr 2025 08:49:49 -0400 Subject: Proposed schedule for JDK 25 In-Reply-To: <20250403132912.2149689@eggemoggin.niobe.net> References: <20250403132912.2149689@eggemoggin.niobe.net> Message-ID: <34488F72-3245-41F7-8BD2-86273C24D18A@oracle.com> > Here is the proposed schedule for JDK 25: > > 2025/06/05 Rampdown Phase One > 2025/07/17 Rampdown Phase Two > 2025/08/07 Initial Release Candidate > 2025/08/21 Final Release Candidate > 2025/09/16 General Availability > > The phases are defined in JEP 3 [1]. > > Comments on this proposal from JDK Committers and Reviewers [2] are > welcome, as are reasoned objections. If no such objections are raised > by 18:00 UTC next Thursday, 10 April, or if they?re raised and then > satisfactorily answered, then per the JEP 2.0 process proposal [3] > this will be the schedule for JDK 24. I meant, of course, that this will be the schedule for JDK 25. - Mark From coleen.phillimore at oracle.com Fri Apr 4 12:54:59 2025 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 4 Apr 2025 08:54:59 -0400 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes On 4/3/25 3:48 PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From mark.reinhold at oracle.com Fri Apr 4 13:37:11 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 4 Apr 2025 13:37:11 +0000 Subject: New candidate JEP: 504: Remove the Applet API Message-ID: <20250404133709.BCA6580E6E1@eggemoggin.niobe.net> https://openjdk.org/jeps/504 Summary: Remove the Applet API, which was deprecated for removal in JDK 17 (2021). It is obsolete because neither recent JDK releases nor current web browsers support applets. - Mark From thomas.stuefe at gmail.com Fri Apr 4 14:12:48 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 4 Apr 2025 16:12:48 +0200 Subject: The future of 32-bit? In-Reply-To: References: Message-ID: Thanks for all the good points brought so far. We will find plenty of reasons why it would be nice to have 32-bit. But there are costs that need to be weighted against the benefits. Pro: - Java promises "write once runs anywhere". That promise has a lot more punch when it, well, runs anywhere. That is an intangible benefit since while it is real and benefits the ecosystem, its positive effects cannot be measured. - 32-bit can be used, arguably, to get JVMs with a very low footprint. But with CompressedOops and CompactObjectHeaders that argument loses its bite somewhat. Con: - Development costs: A large part of the 32-bit effort is spent on making new developments 32-bit-ready. Things like Loom, Lilliput etc. This effort is mostly shouldered by those developers who are conscious enough not to break 32-bit when developing something new. Or those who stepped up and fixed arm32 or x86 after they had been broken for a while. - Opportunity costs: keeping 32-bit drags down development velocity. Development time is a finite resource. That time could be spent elsewhere: fixing bugs, improving the JVM. 32-bit also increases technical debt, therefore ongoing maintenance costs. The worsening build support exaggerates this problem. - Build and testing effort: testing pipelines must be maintained and issues triaged and fixed. I am not arguing for or against 32-bit. But I think we should either stay on the boat or go ashore. Arm32 as the only realistic test option is not a good solution. Cheers, Thomas On Fri, Apr 4, 2025 at 12:41?PM Glavo wrote: > Hi, > > I think 32-bit is not abandoned by everyone. > As far as I know, new architectures like RISC-V and LoongArch still have > 32-bit variants and do have users using them. > > Although these 32-bit variants are often used in resource-constrained > scenarios such as embedded systems, > and their users may not be very interested in Java, I still don't want to > see OpenJDK completely abandon the possibility of supporting them. > > Glavo > > On Fri, Apr 4, 2025 at 3:16?PM Thomas St?fe > wrote: > >> Hi, >> >> Continuing our discussion at the last FOSDEM workshop, I would like to >> know what we think about the future of 32-bit support. >> >> Supporting 32-bit became a lot more cumbersome after the x86 port was >> removed. Before, one could easily build 32-bit on the ubiquitous x64 >> platforms with --target-bits=32; that is not an option anymore. >> >> We have two remaining 32-bit platforms, at least in theory: >> >> - arm32 >> - zero 32-bit >> >> Zero 32-bit has been broken for a long while now; see >> https://bugs.openjdk.org/browse/JDK-8353699. I try this occasionally and >> don't remember the last time it built successfully. >> >> Arm32 is the last bastion of serious 32-bit support, and the last option >> for testing 32-bit coding. So, one needs to build arm32 (best done via >> crossbuild), then spin up an arm32 system to test the changes. I do this >> with a slow-as-molasses Raspberry. It is not fun. >> >> Unfortunately, maintaining 32-bit is not as easy as "make sure it builds >> and fix smaller things". It requires real development, especially in the >> context of ongoing object header work. >> >> 32-bit also means we need to keep some form of uncompressed class >> pointers around, which makes the eventual removal of uncompressed class >> pointers (see [2]) more difficult. The current plan is to implement some >> sort of fake-compressed-class-pointer mode [3], which sounds easy in theory >> but is still tricky work I'd rather avoid. >> >> Keeping up 32-bit development in the face of dwindling options to build >> and test is a struggle. It has been a struggle for some time now. Even the >> comparatively well-maintained arm32 platform had periodic weeks of >> brokenness after heavy upstream changes. And this is not intended to >> diminish the effort put in by the arm32-maintainers. They are few, and they >> do good work. >> >> But I expect this periodic brokenness to worsen now after the removal of >> x86. This is not a good situation. >> >> Thank you, Thomas >> >> [1] https://bugs.openjdk.org/browse/JDK-8353699 >> [2] https://bugs.openjdk.org/browse/JDK-8350754 >> [3] >> https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.mullan at oracle.com Fri Apr 4 14:27:31 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 4 Apr 2025 10:27:31 -0400 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <7d3a16b0-38ea-459c-b1e5-7994a0a8c27c@oracle.com> Vote: yes --Sean On 4/3/25 3:48 PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the past > 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/? > author=ecaspole%40openjdk.org > From patricio.chilano.mateo at oracle.com Fri Apr 4 14:32:42 2025 From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo) Date: Fri, 4 Apr 2025 10:32:42 -0400 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes On 4/3/25 3:48?PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From dalibor.topic at oracle.com Fri Apr 4 15:16:13 2025 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 4 Apr 2025 17:16:13 +0200 Subject: The future of 32-bit? In-Reply-To: References: Message-ID: <77bcced7-1850-4d62-8d61-f6465dd20ea4@oracle.com> On 04/04/2025 16:12, Thomas St?fe wrote: > I am not arguing for or against 32-bit. But I think we should either > stay on the boat or go ashore. Arm32 as the only realistic test option > is not a good solution. Fwiw, ARM announced a move to 64 bit only cores almost two years ago. [0] Without exciting new 32 bit "anywheres" to run on coming up in the future, the needs of existing 32 bit applications are probably already well served by (updates to) the JDK versions they are deployed with, rather then by offering new language and runtime capabilities in older environments for which a decreasing amount of new Java code is going to be written for. cheers, dalibor topic [0] https://newsroom.arm.com/blog/64-bit > > Cheers, Thomas > > > On Fri, Apr 4, 2025 at 12:41?PM Glavo > wrote: > > Hi, > > I think 32-bit is not abandoned by everyone. > As far as I know, new architectures like RISC-V and LoongArch still > have 32-bit variants and do have users using them. > > Although these 32-bit variants are often used in resource- > constrained scenarios such as embedded systems, > and their users may not be very interested in Java, I still don't > want to see OpenJDK completely abandon the possibility of supporting > them. > > Glavo > > On Fri, Apr 4, 2025 at 3:16?PM Thomas St?fe > wrote: > > Hi, > > Continuing our discussion at the last FOSDEM workshop, I would > like to know what we think about the future of 32-bit support. > > Supporting 32-bit became a lot more cumbersome after the x86 > port was removed. Before, one could easily build 32-bit on the > ubiquitous x64 platforms with --target-bits=32; that is not an > option anymore. > > We have two remaining 32-bit platforms, at least in theory: > > - arm32 > - zero 32-bit > > Zero 32-bit has been broken for a long while now; see https:// > bugs.openjdk.org/browse/JDK-8353699 browse/JDK-8353699>. I try this occasionally and don't remember > the last time it built successfully. > > Arm32 is the last bastion of serious 32-bit support, and the > last option for testing 32-bit coding. So, one needs to build > arm32 (best done via crossbuild), then spin up an arm32 system > to test the changes. I do this with a slow-as-molasses > Raspberry. It is not fun. > > Unfortunately, maintaining 32-bit is not as easy as "make sure > it builds and fix smaller things". It requires real development, > especially in the context of ongoing object header work. > > 32-bit also means we need to keep some form of uncompressed > class pointers around, which makes the eventual removal of > uncompressed class pointers (see [2]) more difficult. The > current plan is to implement some sort of fake-compressed-class- > pointer mode [3], which sounds easy in theory but is still > tricky work I'd rather avoid. > > Keeping up 32-bit development in the face of dwindling options > to build and test is a struggle. It has been a struggle for some > time now. Even the comparatively well-maintained arm32 platform > had periodic weeks of brokenness after heavy upstream changes. > And this is not intended to diminish the effort put in by the > arm32-maintainers. They are few, and they do good work. > > But I expect this periodic brokenness to worsen now after the > removal of x86. This is not a good situation. > > Thank you, Thomas > > [1] https://bugs.openjdk.org/browse/JDK-8353699 bugs.openjdk.org/browse/JDK-8353699> > [2] https://bugs.openjdk.org/browse/JDK-8350754 bugs.openjdk.org/browse/JDK-8350754> > [3] https://bugs.openjdk.org/browse/JDK-8350754? > focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From elmoussaoui.ayman01 at gmail.com Fri Apr 4 15:24:06 2025 From: elmoussaoui.ayman01 at gmail.com (Ayman) Date: Fri, 4 Apr 2025 17:24:06 +0200 Subject: Add "SHA-384" as a known attribute Message-ID: Hello, Starting from JDK 19, SHA-384 is replacing SHA-256 as the default digest algorithm in the jarsigner: https://bugs.openjdk.org/browse/JDK-8283475 This means that the string "SHA-384" is now written multiples times is the MANIFEST files, this has been tackled in the past by adding the string "SHA-256" as a KNOWN_NAME that shouldn't be duplicated in memory: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729 Is it possible to do the same with "SHA-384"? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Fri Apr 4 15:55:23 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Apr 2025 16:55:23 +0100 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <388bb506-466e-4163-9840-866cbee4ac3f@oracle.com> Vote: yes best regards, -- daniel On 03/04/2025 20:48, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > From daniel.fuchs at oracle.com Fri Apr 4 15:56:41 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 4 Apr 2025 16:56:41 +0100 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: Vote: yes best regards, -- daniel On 03/04/2025 08:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. From roger.riggs at oracle.com Fri Apr 4 16:53:39 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 4 Apr 2025 12:53:39 -0400 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <07337e7d-d6ed-4517-821b-b24a72a27642@oracle.com> Vote: Yes On 4/3/25 3:37 AM, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Fri Apr 4 16:55:04 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 4 Apr 2025 22:25:04 +0530 Subject: Add "SHA-384" as a known attribute In-Reply-To: References: Message-ID: <6b6c44dd-65ca-4f77-a204-bd2dd8dcbd61@gmail.com> Since this is about caching values in the java.util.jar.Attributes class, the discussion is more appropriate in the core-libs-dev mailing list. I've added it to the "To" now and "Bcc"ed the jdk-dev mailing list. Please subscribe to core-libs-dev https://mail.openjdk.org/mailman/listinfo/core-libs-dev if you haven't already and we can continue the discussion there. -Jaikiran On 04/04/25 8:54 pm, Ayman wrote: > Hello, > > Starting from JDK 19, SHA-384 is replacing SHA-256 as the default > digest algorithm in the jarsigner: > https://bugs.openjdk.org/browse/JDK-8283475 > > This means that the string "SHA-384" is now written multiples times is > the MANIFEST files, this has been tackled in the past by adding the > string "SHA-256" as a KNOWN_NAME that shouldn't be duplicated in > memory: > https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/jar/Attributes.java#L729 > > > Is it possible to do the same with "SHA-384"? > > Thanks, From serguei.spitsyn at oracle.com Fri Apr 4 17:05:27 2025 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Fri, 4 Apr 2025 17:05:27 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes On 3. Apr 2025, at 21:48, Vladimir Kozlov wrote: I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From jai.forums2013 at gmail.com Fri Apr 4 17:16:08 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Fri, 4 Apr 2025 22:46:08 +0530 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: vote: yes -Jaikiran On 03/04/25 1:07 pm, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From sangheon.kim at oracle.com Fri Apr 4 23:00:57 2025 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Fri, 4 Apr 2025 16:00:57 -0700 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <6942972e-219b-4ce0-a57c-9143b461302b@oracle.com> Vote: yes Thanks, Sangheon On 4/3/25 12:48 PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From jai.forums2013 at gmail.com Sat Apr 5 01:22:54 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Sat, 5 Apr 2025 06:52:54 +0530 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <43b42174-79eb-4141-bede-8f11a5224f04@gmail.com> vote: yes -Jaikiran On 04/04/25 1:18 am, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the > past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From kim.barrett at oracle.com Sat Apr 5 06:30:30 2025 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 5 Apr 2025 02:30:30 -0400 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <4dc8e4eb-b6eb-4c5f-8c6f-dcaa91251098@oracle.com> vote: yes On 4/3/25 3:48 PM, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From rehn at rivosinc.com Mon Apr 7 06:12:21 2025 From: rehn at rivosinc.com (Robbin Ehn) Date: Mon, 7 Apr 2025 08:12:21 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes /Robbin On Thu, Apr 3, 2025 at 9:49?PM Vladimir Kozlov wrote: > > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't > have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From thomas.schatzl at oracle.com Mon Apr 7 08:02:35 2025 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 7 Apr 2025 10:02:35 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes From raffaello.giulietti at oracle.com Mon Apr 7 09:45:33 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 7 Apr 2025 11:45:33 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <7a25a756-a1e7-48d9-9085-ab9f485d7bc4@oracle.com> Vote: yes On 2025-04-03 21:48, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He > concentrates on performance testing to make sure we don't have > regressions. He has contributed over 50 changes [3] to JDK over the past > 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/? > author=ecaspole%40openjdk.org > From shipilev at amazon.de Mon Apr 7 09:59:42 2025 From: shipilev at amazon.de (Aleksey Shipilev) Date: Mon, 7 Apr 2025 11:59:42 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <6942972e-219b-4ce0-a57c-9143b461302b@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> <6942972e-219b-4ce0-a57c-9143b461302b@oracle.com> Message-ID: <9706d22c-d169-4104-a669-26e9ecbd22f0@amazon.de> Vote: yes > On 4/3/25 12:48 PM, Vladimir Kozlov wrote: >> I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. From magnus.ihse.bursie at oracle.com Tue Apr 8 14:46:44 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 8 Apr 2025 16:46:44 +0200 Subject: AW: The future of 32-bit? In-Reply-To: References: Message-ID: <114dc201-1124-418c-8e84-d276ced1518a@oracle.com> On 2025-04-04 12:25, Doerr, Martin wrote: > Hi all, > > even if we deprecate 32 bit now, arm32 will still be usable with JDK > 25 LTS for quite some time. > > The big question is if there will still be a significant demand in 2 > years. > > I also wonder when other projects will terminate arm32 support. > This ^^^. The question is not *if* we should stop supporting 32-bit, but *when*. I don't see anyone arguing that 32-bit platforms have a long-term future. We can keep the 32-bit JDKs on life support, for a longer or a shorter time, but frankly, that is what it is. Dropping 32-bit completely somewhere between now and the next LTS release might perhaps be a good idea. As with any other platforms in the JDK, the remaining 32-bit support (arm-32 and zero) should have a sponsor, someone (organization or company) backing it up. That is the general requirement we have for adding a new platform, and we should have the same requirement for keeping old platforms in. If we have such a sponsor, then the onus is on them to keep the platform up to date with continuous development of the JDK. And if no-one is willing to step up and assume such a role, well, that is a clear indication that while it might be "nice to have" 32-bit support, no-one is willing to pay the price for it. And if so, it should go. /Magnus > > Best regards, > > Martin > > *Von: *jdk-dev im Auftrag von Johan Vos > > *Datum: *Freitag, 4. April 2025 um 11:17 > *An: *Thomas St?fe > *Cc: *JDK Dev list > *Betreff: *Re: The future of 32-bit? > > Hi Thomas, all, > > At the OCW workshop, I expressed my worries about removing all 32-bit > code, because I feared it would impact the ability to distribute Java > apps to mobile devices (via the existing stores). As someone pointed > out, at the very least 32-bit versions are not a requirement anymore. > I did a bit of research, and while there are still 32-bit devices in > the field, the 2 major stores are pushing for 64-bits, and > discouraging 32 bits -- something we would call > @Deprecated(forRemoval="true"). As a consequence, zero-32 code is no > requirement?for iOS, and arm-32 is no requirement for Android. > > There are still usecases for the Pi Zero (v1) and older Raspberry Pi > devices (< 3). I have no idea about the installed base of those > devices, but I believe it is possible that this would be the largest > group that will suffer if 32-bit support was halted. > > Having said that, I fully agree there?is lots of additional work > required to keep 32-bit support (the (un)compressed classpointers are > a good example indeed). Though situation. > > - Johan > > On Fri, Apr 4, 2025 at 9:17?AM Thomas St?fe > wrote: > > Hi, > > Continuing our discussion at the last FOSDEM workshop, I would > like to know what we think about the future of 32-bit support. > > Supporting 32-bit became a lot more cumbersome after the x86 port > was removed. Before, one could easily build 32-bit on the > ubiquitous x64 platforms with --target-bits=32; that is not an > option anymore. > > > We have two remaining 32-bit platforms, at least in theory: > > - arm32 > - zero 32-bit > > Zero 32-bit has been broken for a long while now; see > https://bugs.openjdk.org/browse/JDK-8353699. I try this > occasionally and don't remember the last time it built successfully. > > Arm32 is the last bastion of serious 32-bit support, and the last > option for testing 32-bit coding. So, one needs to build arm32 > (best done via crossbuild), then spin up an arm32 system to test > the changes. I do this with a slow-as-molasses Raspberry. It is > not fun. > > Unfortunately, maintaining 32-bit is not as easy as "make sure it > builds and fix smaller things". It requires real development, > especially in the context of ongoing object header work. > > 32-bit also means we need to keep some form of uncompressed class > pointers around, which makes the eventual removal of uncompressed > class pointers (see [2]) more difficult. The current plan is to > implement some sort of fake-compressed-class-pointer mode [3], > which sounds easy in theory but is still tricky work I'd rather avoid. > > Keeping up 32-bit development in the face of dwindling options to > build and test is a struggle. It has been a struggle for some time > now. Even the comparatively well-maintained arm32 platform had > periodic weeks of brokenness after heavy upstream changes. And > this is not intended to diminish the effort put in by the > arm32-maintainers. They are few, and they do good work. > > But I expect this periodic brokenness to worsen now after the > removal of x86. This is not a good situation. > > Thank you, Thomas > > [1] https://bugs.openjdk.org/browse/JDK-8353699 > [2] https://bugs.openjdk.org/browse/JDK-8350754 > [3] > https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Tue Apr 8 16:20:19 2025 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 8 Apr 2025 17:20:19 +0100 Subject: CFV: New JDK Reviewer: Martin Balao Message-ID: I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been a member of the OpenJDK Vulnerability Group since its inception, actively involved both in preparing & reviewing reproducers/fixes for undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles for mainline/LTS updates releases. He has also been an active contributor to mainline security development work and bears prime responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As well as reviewing multiple security patches in the VG, Martin has contributed 46 changes [4] to mainline JDK over the past 8 years. Votes are due by 24:00 UTC, April 22, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Andrew Dinn [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://openjdk.org/jeps/8325511 [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong 8203182: Release session if initialization of SunPKCS11 Signature fails 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider 8213154: Update copyright headers of files in src tree that are missing Classpath exception 8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) 8219011: Implement MacroAssembler::warn method on AArch64 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 8223482: Unsupported ciphersuites may be offered by a TLS client 8215032: Support Kerberos cross-realm referrals (RFC 6806) 8227437: S4U2proxy cannot continue because server's TGT cannot be found 8233404: System property to set the number of PBE iterations in JCEKS keystores 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field 8005819: Support cross-realm MSSFU 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup 8271566: DSA signature length value is not accurate in P11Signature 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked 8301553: Support Password-Based Cryptography in SunPKCS11 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 8323231: Improve array management 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 8319332: Security properties files inclusion 8332644: Improve graph optimizations 8345221: Replace legacy with new Provider APIs in SunNativeGSS 8330045: Enhance array handling 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactor From thomas.stuefe at gmail.com Tue Apr 8 16:27:06 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 8 Apr 2025 18:27:06 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes On Tue, Apr 8, 2025 at 6:21?PM Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security > expert, leading all Red Hat work related to OpenJDK security. He has > been a member of the OpenJDK Vulnerability Group since its inception, > actively involved both in preparing & reviewing reproducers/fixes for > undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles > for mainline/LTS updates releases. He has also been an active > contributor to mainline security development work and bears prime > responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. > As well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension > < > https://github.com/openjdk/jdk/commit/82bf0799c67f224ffb1875e630f5152e8410ad14 > > > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite > < > https://github.com/openjdk/jdk/commit/f1212e26c3126297268374142cf285ee66fe4e60 > > > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > < > https://github.com/openjdk/jdk/commit/a79484396d8753bfa677426945c6cfac536a9c8c > > > 8203182: Release session if initialization of SunPKCS11 Signature fails > < > https://github.com/openjdk/jdk/commit/62c97f695f1650963d4c1f68364c99f9315fbd76 > > > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with > "NSS initialization failed" on NSS 3.34.1 > < > https://github.com/openjdk/jdk/commit/b44c24d290362e4edf5b0bf18b1ecce1583daeff > > > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > < > https://github.com/openjdk/jdk/commit/aafb2b04740911742de1332a83d23eefe1e6804d > > > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception > < > https://github.com/openjdk/jdk/commit/7724fd6d9bf52bc3aa7d5940b829503dc57e5042 > > > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts > < > https://github.com/openjdk/jdk/commit/7c14ebfcd04b147cd6972e3a7242f4b97b1f97e5 > > > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit > process address space > < > https://github.com/openjdk/jdk/commit/dfcab1b85ae9ca39b95cf3b17cbfbaea1238aec7 > > > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) > < > https://github.com/openjdk/jdk/commit/6cfcdde523ed3875cbe31379e04a745891816fcb > > > 8219011: Implement MacroAssembler::warn method on AArch64 > < > https://github.com/openjdk/jdk/commit/d6bec9017ec205fe790aaed2e4721b2f85b674f3 > > > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth > < > https://github.com/openjdk/jdk/commit/ae9ee277b6eca4cbcd91948e7c518c4a797e6d84 > > > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 > crypto provider > < > https://github.com/openjdk/jdk/commit/0814229ebc94f6821789391df29c34610164b47f > > > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 > crypto provider > < > https://github.com/openjdk/jdk/commit/0d35ef38e6f11d4f5bafaefc3d97567c18b57857 > > > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > < > https://github.com/openjdk/jdk/commit/a8a29bbae66da112b6012a4d5c7cbf5270b1573a > > > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 > < > https://github.com/openjdk/jdk/commit/11bb97a71c805344c051e4fba75096a539528000 > > > 8223482: Unsupported ciphersuites may be offered by a TLS client > < > https://github.com/openjdk/jdk/commit/ebf8e1c0ac605a0613c343d37abece6d57cd9698 > > > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > < > https://github.com/openjdk/jdk/commit/5aae9ef0db20101c5a1473426e5dcd6f8a625c6a > > > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > < > https://github.com/openjdk/jdk/commit/3cd50f2666a382c4b85f923c02a5460d4bce515c > > > 8233404: System property to set the number of PBE iterations in JCEKS > keystores > < > https://github.com/openjdk/jdk/commit/0e5a288dfe0b90e0d2c8c6288334fb9847a4f403 > > > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE > field > < > https://github.com/openjdk/jdk/commit/171257ea1aa210d13e7604994e90ad334ed51875 > > > 8005819: Support cross-realm MSSFU > < > https://github.com/openjdk/jdk/commit/4fa827ec92665dae9c3cd6505d885ba5b7998df2 > > > 8238555: Allow Initialization of SunPKCS11 with NSS when there are > external FIPS modules in the NSSDB > < > https://github.com/openjdk/jdk/commit/84f3e86749be8b84b6f39262cfdd160e651d6dba > > > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in > AD > < > https://github.com/openjdk/jdk/commit/2883bccf48f7a63c3635a0792138c5481050966f > > > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one > < > https://github.com/openjdk/jdk/commit/1c651455a75ff21770bb3b112a440396fce402a5 > > > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets > < > https://github.com/openjdk/jdk/commit/31753ef9bf2508727021cb40fd0cf761502bd814 > > > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > < > https://github.com/openjdk/jdk/commit/4be2173478bd1e84946bd903b350ce466bddb36b > > > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > < > https://github.com/openjdk/jdk/commit/47c7dc7734677b64511ab1d4b3c30d3197d66ce9 > > > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding > < > https://github.com/openjdk/jdk/commit/1ee80e03adfae5f428519f7c134e78a0f277a0a5 > > > 8265462: Handle multiple slots in the NSS Internal Module from > SunPKCS11's Secmod > < > https://github.com/openjdk/jdk/commit/bdbe23b9cb6151c81a4de675e629b0a42f00640d > > > 8270137: Kerberos Credential Retrieval from Cache not Working in > Cross-Realm Setup > < > https://github.com/openjdk/jdk/commit/67869b491ae1eaf311dfb8c61a9e94329a822ffc > > > 8271566: DSA signature length value is not accurate in P11Signature > < > https://github.com/openjdk/jdk/commit/ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3 > > > 8275535: Retrying a failed authentication on multiple LDAP servers can > lead to users blocked > < > https://github.com/openjdk/jdk/commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e > > > 8301553: Support Password-Based Cryptography in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 > < > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > < > https://github.com/openjdk/jdk/commit/0f5f3c9b9718c610406088327401210486447462 > > > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software > Token > < > https://github.com/openjdk/jdk/commit/13cf0707f903609c9bda99a9bf7511f494f9feae > > > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > < > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > > 8323231: Improve array management > < > https://github.com/openjdk/jdk/commit/5f365d44be9c1f3413c9ccde970e2745090a516a > > > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > > 8319332: Security properties files inclusion > < > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > > 8332644: Improve graph optimizations > < > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > < > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > > 8330045: Enhance array handling > < > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor > < > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Tue Apr 8 16:31:17 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 8 Apr 2025 17:31:17 +0100 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes From sgehwolf at redhat.com Tue Apr 8 17:03:13 2025 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 08 Apr 2025 19:03:13 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: <47867b2160da853662a3bcef65e5633446323046.camel@redhat.com> Vote: yes On Tue, 2025-04-08 at 17:20 +0100, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. From goetz.lindenmaier at sap.com Tue Apr 8 17:32:21 2025 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Apr 2025 17:32:21 +0000 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes Best, G?tz ________________________________ From: jdk-dev on behalf of Andrew Dinn Sent: Tuesday, April 8, 2025 6:20:19 PM To: jdk-dev Subject: CFV: New JDK Reviewer: Martin Balao I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been a member of the OpenJDK Vulnerability Group since its inception, actively involved both in preparing & reviewing reproducers/fixes for undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles for mainline/LTS updates releases. He has also been an active contributor to mainline security development work and bears prime responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As well as reviewing multiple security patches in the VG, Martin has contributed 46 changes [4] to mainline JDK over the past 8 years. Votes are due by 24:00 UTC, April 22, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Andrew Dinn [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://openjdk.org/jeps/8325511 [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong 8203182: Release session if initialization of SunPKCS11 Signature fails 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider 8213154: Update copyright headers of files in src tree that are missing Classpath exception 8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) 8219011: Implement MacroAssembler::warn method on AArch64 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 8223482: Unsupported ciphersuites may be offered by a TLS client 8215032: Support Kerberos cross-realm referrals (RFC 6806) 8227437: S4U2proxy cannot continue because server's TGT cannot be found 8233404: System property to set the number of PBE iterations in JCEKS keystores 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field 8005819: Support cross-realm MSSFU 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup 8271566: DSA signature length value is not accurate in P11Signature 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked 8301553: Support Password-Based Cryptography in SunPKCS11 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 8323231: Improve array management 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 8319332: Security properties files inclusion 8332644: Improve graph optimizations 8345221: Replace legacy with new Provider APIs in SunNativeGSS 8330045: Enhance array handling 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactor -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Apr 8 17:33:41 2025 From: philip.race at oracle.com (Philip Race) Date: Tue, 8 Apr 2025 10:33:41 -0700 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: <4309bd58-5cc5-4596-8383-3c2c2806d40e@oracle.com> Vote: yes -phil. From serguei.spitsyn at oracle.com Tue Apr 8 19:00:23 2025 From: serguei.spitsyn at oracle.com (Serguei Spitsyn) Date: Tue, 8 Apr 2025 19:00:23 +0000 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From shipilev at amazon.de Tue Apr 8 19:01:43 2025 From: shipilev at amazon.de (Aleksey Shipilev) Date: Tue, 8 Apr 2025 21:01:43 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes On 08.04.25 18:20, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. From sean.mullan at oracle.com Tue Apr 8 19:40:10 2025 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 8 Apr 2025 15:40:10 -0400 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes --Sean On 4/8/25 12:20 PM, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security > expert, leading all Red Hat work related to OpenJDK security. He has > been a member of the OpenJDK Vulnerability Group since its inception, > actively involved both in preparing & reviewing reproducers/fixes for > undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles > for mainline/LTS updates releases. He has also been an active > contributor to mainline security development work and bears prime > responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As > well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension commit/82bf0799c67f224ffb1875e630f5152e8410ad14> > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite f1212e26c3126297268374142cf285ee66fe4e60> > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > a79484396d8753bfa677426945c6cfac536a9c8c> > 8203182: Release session if initialization of SunPKCS11 Signature fails > commit/62c97f695f1650963d4c1f68364c99f9315fbd76> > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with > "NSS initialization failed" on NSS 3.34.1 jdk/commit/b44c24d290362e4edf5b0bf18b1ecce1583daeff> > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider github.com/openjdk/jdk/commit/aafb2b04740911742de1332a83d23eefe1e6804d> > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception commit/7724fd6d9bf52bc3aa7d5940b829503dc57e5042> > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts commit/7c14ebfcd04b147cd6972e3a7242f4b97b1f97e5> > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit > process address space dfcab1b85ae9ca39b95cf3b17cbfbaea1238aec7> > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) openjdk/jdk/commit/6cfcdde523ed3875cbe31379e04a745891816fcb> > 8219011: Implement MacroAssembler::warn method on AArch64 github.com/openjdk/jdk/commit/d6bec9017ec205fe790aaed2e4721b2f85b674f3> > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth ae9ee277b6eca4cbcd91948e7c518c4a797e6d84> > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 > crypto provider commit/0814229ebc94f6821789391df29c34610164b47f> > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 > crypto provider commit/0d35ef38e6f11d4f5bafaefc3d97567c18b57857> > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > a8a29bbae66da112b6012a4d5c7cbf5270b1573a> > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 github.com/openjdk/jdk/commit/11bb97a71c805344c051e4fba75096a539528000> > 8223482: Unsupported ciphersuites may be offered by a TLS client > ebf8e1c0ac605a0613c343d37abece6d57cd9698> > 8215032: Support Kerberos cross-realm referrals (RFC 6806) github.com/openjdk/jdk/commit/5aae9ef0db20101c5a1473426e5dcd6f8a625c6a> > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > commit/3cd50f2666a382c4b85f923c02a5460d4bce515c> > 8233404: System property to set the number of PBE iterations in JCEKS > keystores commit/0e5a288dfe0b90e0d2c8c6288334fb9847a4f403> > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE > field commit/171257ea1aa210d13e7604994e90ad334ed51875> > 8005819: Support cross-realm MSSFU commit/4fa827ec92665dae9c3cd6505d885ba5b7998df2> > 8238555: Allow Initialization of SunPKCS11 with NSS when there are > external FIPS modules in the NSSDB commit/84f3e86749be8b84b6f39262cfdd160e651d6dba> > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in > AD commit/2883bccf48f7a63c3635a0792138c5481050966f> > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one commit/1c651455a75ff21770bb3b112a440396fce402a5> > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets commit/31753ef9bf2508727021cb40fd0cf761502bd814> > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > commit/4be2173478bd1e84946bd903b350ce466bddb36b> > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > commit/47c7dc7734677b64511ab1d4b3c30d3197d66ce9> > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding commit/1ee80e03adfae5f428519f7c134e78a0f277a0a5> > 8265462: Handle multiple slots in the NSS Internal Module from > SunPKCS11's Secmod bdbe23b9cb6151c81a4de675e629b0a42f00640d> > 8270137: Kerberos Credential Retrieval from Cache not Working in Cross- > Realm Setup commit/67869b491ae1eaf311dfb8c61a9e94329a822ffc> > 8271566: DSA signature length value is not accurate in P11Signature > ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3> > 8275535: Retrying a failed authentication on multiple LDAP servers can > lead to users blocked commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e> > 8301553: Support Password-Based Cryptography in SunPKCS11 github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444> > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 commit/760cb04a2e099a3af9199d77a234af75a18cce5d> > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > commit/0f5f3c9b9718c610406088327401210486447462> > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software > Token commit/13cf0707f903609c9bda99a9bf7511f494f9feae> > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) commit/8a8d9288980513db459f7d6b36554b65844951ca> > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e> > 8323231: Improve array management commit/5f365d44be9c1f3413c9ccde970e2745090a516a> > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > commit/3251eea1f4289a0505052be204407c02ca38b0ad> > 8319332: Security properties files inclusion openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab> > 8332644: Improve graph optimizations commit/c89f76c0b9ca085192775af9bd9368562b582dd6> > 8345221: Replace legacy with new Provider APIs in SunNativeGSS github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb> > 8330045: Enhance array handling commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7> > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa> > From hohensee at amazon.com Tue Apr 8 20:47:07 2025 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 8 Apr 2025 20:47:07 +0000 Subject: CFV: New JDK Reviewer: Martin Balao Message-ID: <1E075CBA-F60C-46FE-9B88-361B664EC0DB@amazon.com> Vote: yes ?On 4/8/25, 9:22 AM, "jdk-dev on behalf of Andrew Dinn" on behalf of adinn at redhat.com > wrote: I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been a member of the OpenJDK Vulnerability Group since its inception, actively involved both in preparing & reviewing reproducers/fixes for undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles for mainline/LTS updates releases. He has also been an active contributor to mainline security development work and bears prime responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As well as reviewing multiple security patches in the VG, Martin has contributed 46 changes [4] to mainline JDK over the past 8 years. Votes are due by 24:00 UTC, April 22, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Andrew Dinn [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://openjdk.org/jeps/8325511 [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong 8203182: Release session if initialization of SunPKCS11 Signature fails 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider 8213154: Update copyright headers of files in src tree that are missing Classpath exception 8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) 8219011: Implement MacroAssembler::warn method on AArch64 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 8223482: Unsupported ciphersuites may be offered by a TLS client 8215032: Support Kerberos cross-realm referrals (RFC 6806) 8227437: S4U2proxy cannot continue because server's TGT cannot be found 8233404: System property to set the number of PBE iterations in JCEKS keystores 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field 8005819: Support cross-realm MSSFU 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup 8271566: DSA signature length value is not accurate in P11Signature 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked 8301553: Support Password-Based Cryptography in SunPKCS11 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 8323231: Improve array management 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 8319332: Security properties files inclusion 8332644: Improve graph optimizations 8345221: Replace legacy with new Provider APIs in SunNativeGSS 8330045: Enhance array handling 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactor From hohensee at amazon.com Tue Apr 8 20:48:28 2025 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 8 Apr 2025 20:48:28 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole Message-ID: <4C349828-B100-433C-8516-D65A88E0B406@amazon.com> Vote: yes ?On 4/3/25, 12:49 PM, "jdk-dev on behalf of Vladimir Kozlov" on behalf of vladimir.kozlov at oracle.com > wrote: I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org From djelinski1 at gmail.com Wed Apr 9 04:38:59 2025 From: djelinski1 at gmail.com (=?UTF-8?Q?Daniel_Jeli=C5=84ski?=) Date: Wed, 9 Apr 2025 06:38:59 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes wt., 8 kwi 2025, 18:21 u?ytkownik Andrew Dinn napisa?: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security > expert, leading all Red Hat work related to OpenJDK security. He has > been a member of the OpenJDK Vulnerability Group since its inception, > actively involved both in preparing & reviewing reproducers/fixes for > undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles > for mainline/LTS updates releases. He has also been an active > contributor to mainline security development work and bears prime > responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. > As well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension > < > https://github.com/openjdk/jdk/commit/82bf0799c67f224ffb1875e630f5152e8410ad14 > > > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite > < > https://github.com/openjdk/jdk/commit/f1212e26c3126297268374142cf285ee66fe4e60 > > > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > < > https://github.com/openjdk/jdk/commit/a79484396d8753bfa677426945c6cfac536a9c8c > > > 8203182: Release session if initialization of SunPKCS11 Signature fails > < > https://github.com/openjdk/jdk/commit/62c97f695f1650963d4c1f68364c99f9315fbd76 > > > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with > "NSS initialization failed" on NSS 3.34.1 > < > https://github.com/openjdk/jdk/commit/b44c24d290362e4edf5b0bf18b1ecce1583daeff > > > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > < > https://github.com/openjdk/jdk/commit/aafb2b04740911742de1332a83d23eefe1e6804d > > > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception > < > https://github.com/openjdk/jdk/commit/7724fd6d9bf52bc3aa7d5940b829503dc57e5042 > > > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts > < > https://github.com/openjdk/jdk/commit/7c14ebfcd04b147cd6972e3a7242f4b97b1f97e5 > > > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit > process address space > < > https://github.com/openjdk/jdk/commit/dfcab1b85ae9ca39b95cf3b17cbfbaea1238aec7 > > > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) > < > https://github.com/openjdk/jdk/commit/6cfcdde523ed3875cbe31379e04a745891816fcb > > > 8219011: Implement MacroAssembler::warn method on AArch64 > < > https://github.com/openjdk/jdk/commit/d6bec9017ec205fe790aaed2e4721b2f85b674f3 > > > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth > < > https://github.com/openjdk/jdk/commit/ae9ee277b6eca4cbcd91948e7c518c4a797e6d84 > > > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 > crypto provider > < > https://github.com/openjdk/jdk/commit/0814229ebc94f6821789391df29c34610164b47f > > > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 > crypto provider > < > https://github.com/openjdk/jdk/commit/0d35ef38e6f11d4f5bafaefc3d97567c18b57857 > > > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > < > https://github.com/openjdk/jdk/commit/a8a29bbae66da112b6012a4d5c7cbf5270b1573a > > > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 > < > https://github.com/openjdk/jdk/commit/11bb97a71c805344c051e4fba75096a539528000 > > > 8223482: Unsupported ciphersuites may be offered by a TLS client > < > https://github.com/openjdk/jdk/commit/ebf8e1c0ac605a0613c343d37abece6d57cd9698 > > > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > < > https://github.com/openjdk/jdk/commit/5aae9ef0db20101c5a1473426e5dcd6f8a625c6a > > > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > < > https://github.com/openjdk/jdk/commit/3cd50f2666a382c4b85f923c02a5460d4bce515c > > > 8233404: System property to set the number of PBE iterations in JCEKS > keystores > < > https://github.com/openjdk/jdk/commit/0e5a288dfe0b90e0d2c8c6288334fb9847a4f403 > > > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE > field > < > https://github.com/openjdk/jdk/commit/171257ea1aa210d13e7604994e90ad334ed51875 > > > 8005819: Support cross-realm MSSFU > < > https://github.com/openjdk/jdk/commit/4fa827ec92665dae9c3cd6505d885ba5b7998df2 > > > 8238555: Allow Initialization of SunPKCS11 with NSS when there are > external FIPS modules in the NSSDB > < > https://github.com/openjdk/jdk/commit/84f3e86749be8b84b6f39262cfdd160e651d6dba > > > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in > AD > < > https://github.com/openjdk/jdk/commit/2883bccf48f7a63c3635a0792138c5481050966f > > > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one > < > https://github.com/openjdk/jdk/commit/1c651455a75ff21770bb3b112a440396fce402a5 > > > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets > < > https://github.com/openjdk/jdk/commit/31753ef9bf2508727021cb40fd0cf761502bd814 > > > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > < > https://github.com/openjdk/jdk/commit/4be2173478bd1e84946bd903b350ce466bddb36b > > > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > < > https://github.com/openjdk/jdk/commit/47c7dc7734677b64511ab1d4b3c30d3197d66ce9 > > > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding > < > https://github.com/openjdk/jdk/commit/1ee80e03adfae5f428519f7c134e78a0f277a0a5 > > > 8265462: Handle multiple slots in the NSS Internal Module from > SunPKCS11's Secmod > < > https://github.com/openjdk/jdk/commit/bdbe23b9cb6151c81a4de675e629b0a42f00640d > > > 8270137: Kerberos Credential Retrieval from Cache not Working in > Cross-Realm Setup > < > https://github.com/openjdk/jdk/commit/67869b491ae1eaf311dfb8c61a9e94329a822ffc > > > 8271566: DSA signature length value is not accurate in P11Signature > < > https://github.com/openjdk/jdk/commit/ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3 > > > 8275535: Retrying a failed authentication on multiple LDAP servers can > lead to users blocked > < > https://github.com/openjdk/jdk/commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e > > > 8301553: Support Password-Based Cryptography in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 > < > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > < > https://github.com/openjdk/jdk/commit/0f5f3c9b9718c610406088327401210486447462 > > > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software > Token > < > https://github.com/openjdk/jdk/commit/13cf0707f903609c9bda99a9bf7511f494f9feae > > > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > < > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > > 8323231: Improve array management > < > https://github.com/openjdk/jdk/commit/5f365d44be9c1f3413c9ccde970e2745090a516a > > > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > > 8319332: Security properties files inclusion > < > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > > 8332644: Improve graph optimizations > < > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > < > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > > 8330045: Enhance array handling > < > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor > < > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.hagedorn at oracle.com Wed Apr 9 05:55:42 2025 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 9 Apr 2025 07:55:42 +0200 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <3bbd0a11-8c17-454f-94e9-cc67adb32e42@oracle.com> Vote: yes Best regards, Christian On 03.04.25 21:48, Vladimir Kozlov wrote: > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on > performance testing to make sure we don't have regressions. He has contributed > over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination.? Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From christian.hagedorn at oracle.com Wed Apr 9 05:56:13 2025 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 9 Apr 2025 07:56:13 +0200 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <0d8409b4-5456-4de2-ad01-f6b0bd37203a@oracle.com> Vote: yes Best regards, Christian On 03.04.25 09:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From christian.hagedorn at oracle.com Wed Apr 9 05:56:54 2025 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 9 Apr 2025 07:56:54 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes Best regards, Christian On 08.04.25 18:20, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security expert, > leading all Red Hat work related to OpenJDK security. He has been a member of > the OpenJDK Vulnerability Group since its inception, actively involved both in > preparing & reviewing reproducers/fixes for undisclosed CVEs and in planning & > preparing 3-monthly CVE patch bundles for mainline/LTS updates releases. He has > also been an active contributor to mainline security development work and bears > prime responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As > well as reviewing multiple security patches in the VG, Martin has contributed 46 > changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended Master > Secret Extension commit/82bf0799c67f224ffb1875e630f5152e8410ad14> > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses > sqlite f1212e26c3126297268374142cf285ee66fe4e60> > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong github.com/openjdk/jdk/commit/a79484396d8753bfa677426945c6cfac536a9c8c> > 8203182: Release session if initialization of SunPKCS11 Signature fails > > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS > initialization failed" on NSS 3.34.1 b44c24d290362e4edf5b0bf18b1ecce1583daeff> > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider openjdk/jdk/commit/aafb2b04740911742de1332a83d23eefe1e6804d> > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception commit/7724fd6d9bf52bc3aa7d5940b829503dc57e5042> > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts commit/7c14ebfcd04b147cd6972e3a7242f4b97b1f97e5> > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process > address space dfcab1b85ae9ca39b95cf3b17cbfbaea1238aec7> > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 > (SIGBUS error in getNativeKeyInfo) commit/6cfcdde523ed3875cbe31379e04a745891816fcb> > 8219011: Implement MacroAssembler::warn method on AArch64 openjdk/jdk/commit/d6bec9017ec205fe790aaed2e4721b2f85b674f3> > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth ae9ee277b6eca4cbcd91948e7c518c4a797e6d84> > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto > provider commit/0814229ebc94f6821789391df29c34610164b47f> > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto > provider commit/0d35ef38e6f11d4f5bafaefc3d97567c18b57857> > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed github.com/openjdk/jdk/commit/a8a29bbae66da112b6012a4d5c7cbf5270b1573a> > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported > signature algorithm: rsa_pss_rsae_sha256 commit/11bb97a71c805344c051e4fba75096a539528000> > 8223482: Unsupported ciphersuites may be offered by a TLS client github.com/openjdk/jdk/commit/ebf8e1c0ac605a0613c343d37abece6d57cd9698> > 8215032: Support Kerberos cross-realm referrals (RFC 6806) openjdk/jdk/commit/5aae9ef0db20101c5a1473426e5dcd6f8a625c6a> > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > > 8233404: System property to set the number of PBE iterations in JCEKS keystores > > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field > > 8005819: Support cross-realm MSSFU commit/4fa827ec92665dae9c3cd6505d885ba5b7998df2> > 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS > modules in the NSSDB commit/84f3e86749be8b84b6f39262cfdd160e651d6dba> > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD > > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security > one commit/1c651455a75ff21770bb3b112a440396fce402a5> > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos > tickets commit/31753ef9bf2508727021cb40fd0cf761502bd814> > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > > 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying > mechanism has no padding commit/1ee80e03adfae5f428519f7c134e78a0f277a0a5> > 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's > Secmod bdbe23b9cb6151c81a4de675e629b0a42f00640d> > 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm > Setup commit/67869b491ae1eaf311dfb8c61a9e94329a822ffc> > 8271566: DSA signature length value is not accurate in P11Signature github.com/openjdk/jdk/commit/ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3> > 8275535: Retrying a failed authentication on multiple LDAP servers can lead to > users blocked commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e> > 8301553: Support Password-Based Cryptography in SunPKCS11 openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444> > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 commit/760cb04a2e099a3af9199d77a234af75a18cce5d> > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token > > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) > > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e> > 8323231: Improve array management commit/5f365d44be9c1f3413c9ccde970e2745090a516a> > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad> > 8319332: Security properties files inclusion commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab> > 8332644: Improve graph optimizations c89f76c0b9ca085192775af9bd9368562b582dd6> > 8345221: Replace legacy with new Provider APIs in SunNativeGSS github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb> > 8330045: Enhance array handling commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7> > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in > SunPKCS11 SecretKeyFactor commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa> > From matthias.baesken at sap.com Wed Apr 9 06:20:10 2025 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 9 Apr 2025 06:20:10 +0000 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: >I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. Vote: Yes From tobias.hartmann at oracle.com Wed Apr 9 06:57:36 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 9 Apr 2025 08:57:36 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes Best regards, Tobias On 4/8/25 18:20, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been a member of the OpenJDK Vulnerability Group since its inception, actively involved both in preparing & reviewing reproducers/fixes for undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles for mainline/LTS updates releases. He has also been an active contributor to mainline security development work and bears prime responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As well as reviewing multiple security patches in the VG, Martin has contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > 8203182: Release session if initialization of SunPKCS11 Signature fails > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1 > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > 8213154: Update copyright headers of files in src tree that are missing Classpath exception > 8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) > 8219011: Implement MacroAssembler::warn method on AArch64 > 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 > 8223482: Unsupported ciphersuites may be offered by a TLS client > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > 8233404: System property to set the number of PBE iterations in JCEKS keystores > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field > 8005819: Support cross-realm MSSFU > 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod > 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup > 8271566: DSA signature length value is not accurate in P11Signature > 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked > 8301553: Support Password-Based Cryptography in SunPKCS11 > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > 8323231: Improve array management > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > 8319332: Security properties files inclusion > 8332644: Improve graph optimizations > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > 8330045: Enhance array handling > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactor > From jai.forums2013 at gmail.com Wed Apr 9 09:04:29 2025 From: jai.forums2013 at gmail.com (Jaikiran Pai) Date: Wed, 9 Apr 2025 14:34:29 +0530 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: <25d7a3c2-2bb2-4c0b-abc4-9c2db2ec40b2@gmail.com> vote: yes -Jaikiran On 08/04/25 9:50 pm, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security > expert, leading all Red Hat work related to OpenJDK security. He has > been a member of the OpenJDK Vulnerability Group since its inception, > actively involved both in preparing & reviewing reproducers/fixes for > undisclosed CVEs and in planning & preparing 3-monthly CVE patch > bundles for mainline/LTS updates releases. He has also been an active > contributor to mainline security development work and bears prime > responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. > As well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension > > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite > > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > > > 8203182: Release session if initialization of SunPKCS11 Signature > fails > > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with > "NSS initialization failed" on NSS 3.34.1 > > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > > 8213154: Update copyright headers of files in src tree that are > missing Classpath exception > > 8204142: AWT hang occurs when sequenced events arrive out of sequence > in multiple AppContexts > > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 > bit process address space > > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) > > 8219011: Implement MacroAssembler::warn method on AArch64 > > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth > > 8220753: Re-introduce the test case for TLS 1.2 algorithms in > SunPKCS11 crypto provider > > 8220513: Wrapper Key may get deleted when closing sessions in > SunPKCS11 crypto provider > > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > > > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 > > 8223482: Unsupported ciphersuites may be offered by a TLS client > > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > > 8227437: S4U2proxy cannot continue because server's TGT cannot be > found > > 8233404: System property to set the number of PBE iterations in JCEKS > keystores > > 8233946: Add @since 13 annotation to > KerberosPrincipal.KRB_NT_ENTERPRISE field > > 8005819: Support cross-realm MSSFU > > 8238555: Allow Initialization of SunPKCS11 with NSS when there are > external FIPS modules in the NSSDB > > 8239385: KerberosTicket client name refers wrongly to sAMAccountName > in AD > > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one > > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets > > 8259319: Illegal package access when SunPKCS11 requires SunJCE's > classes > > 8258833: Cancel multi-part cipher operations in SunPKCS11 after > failures > > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding > > 8265462: Handle multiple slots in the NSS Internal Module from > SunPKCS11's Secmod > > 8270137: Kerberos Credential Retrieval from Cache not Working in > Cross-Realm Setup > > 8271566: DSA signature length value is not accurate in P11Signature > > 8275535: Retrying a failed authentication on multiple LDAP servers can > lead to users blocked > > 8301553: Support Password-Based Cryptography in SunPKCS11 > > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails > after JDK-8301553 > > 8325254: CKA_TOKEN private and secret keys are not necessarily > sensitive > > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS > Software Token > > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > > 8323231: Improve array management > > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > > 8319332: Security properties files inclusion > > 8332644: Improve graph optimizations > > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > > 8330045: Enhance array handling > > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor > > From weijun.wang at oracle.com Wed Apr 9 11:15:32 2025 From: weijun.wang at oracle.com (Wei-Jun Wang) Date: Wed, 9 Apr 2025 11:15:32 +0000 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes ?weijun > On Apr 8, 2025, at 12:20, Andrew Dinn wrote: > > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been a member of the OpenJDK Vulnerability Group since its inception, actively involved both in preparing & reviewing reproducers/fixes for undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles for mainline/LTS updates releases. He has also been an active contributor to mainline security development work and bears prime responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As well as reviewing multiple security patches in the VG, Martin has contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > 8203182: Release session if initialization of SunPKCS11 Signature fails > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1 > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > 8213154: Update copyright headers of files in src tree that are missing Classpath exception > 8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) > 8219011: Implement MacroAssembler::warn method on AArch64 > 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 > 8223482: Unsupported ciphersuites may be offered by a TLS client > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > 8233404: System property to set the number of PBE iterations in JCEKS keystores > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field > 8005819: Support cross-realm MSSFU > 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding > 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod > 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup > 8271566: DSA signature length value is not accurate in P11Signature > 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked > 8301553: Support Password-Based Cryptography in SunPKCS11 > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > 8323231: Improve array management > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > 8319332: Security properties files inclusion > 8332644: Improve graph optimizations > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > 8330045: Enhance array handling > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactor > From raffaello.giulietti at oracle.com Wed Apr 9 12:09:55 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Wed, 9 Apr 2025 14:09:55 +0200 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <48499f9b-4110-492a-ab0f-57456b30468e@oracle.com> Vote: yes On 2025-04-03 09:37, Roberto Castaneda Lozano wrote: > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From raffaello.giulietti at oracle.com Wed Apr 9 12:13:45 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Wed, 9 Apr 2025 14:13:45 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: <949d8347-f620-40fe-a106-00fdc4294393@oracle.com> Vote: yes On 2025-04-08 18:20, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security > expert, leading all Red Hat work related to OpenJDK security. He has > been a member of the OpenJDK Vulnerability Group since its inception, > actively involved both in preparing & reviewing reproducers/fixes for > undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles > for mainline/LTS updates releases. He has also been an active > contributor to mainline security development work and bears prime > responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As > well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension commit/82bf0799c67f224ffb1875e630f5152e8410ad14> > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite f1212e26c3126297268374142cf285ee66fe4e60> > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > a79484396d8753bfa677426945c6cfac536a9c8c> > 8203182: Release session if initialization of SunPKCS11 Signature fails > commit/62c97f695f1650963d4c1f68364c99f9315fbd76> > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with > "NSS initialization failed" on NSS 3.34.1 jdk/commit/b44c24d290362e4edf5b0bf18b1ecce1583daeff> > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider github.com/openjdk/jdk/commit/aafb2b04740911742de1332a83d23eefe1e6804d> > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception commit/7724fd6d9bf52bc3aa7d5940b829503dc57e5042> > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts commit/7c14ebfcd04b147cd6972e3a7242f4b97b1f97e5> > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit > process address space dfcab1b85ae9ca39b95cf3b17cbfbaea1238aec7> > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) openjdk/jdk/commit/6cfcdde523ed3875cbe31379e04a745891816fcb> > 8219011: Implement MacroAssembler::warn method on AArch64 github.com/openjdk/jdk/commit/d6bec9017ec205fe790aaed2e4721b2f85b674f3> > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth ae9ee277b6eca4cbcd91948e7c518c4a797e6d84> > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 > crypto provider commit/0814229ebc94f6821789391df29c34610164b47f> > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 > crypto provider commit/0d35ef38e6f11d4f5bafaefc3d97567c18b57857> > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > a8a29bbae66da112b6012a4d5c7cbf5270b1573a> > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 github.com/openjdk/jdk/commit/11bb97a71c805344c051e4fba75096a539528000> > 8223482: Unsupported ciphersuites may be offered by a TLS client > ebf8e1c0ac605a0613c343d37abece6d57cd9698> > 8215032: Support Kerberos cross-realm referrals (RFC 6806) github.com/openjdk/jdk/commit/5aae9ef0db20101c5a1473426e5dcd6f8a625c6a> > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > commit/3cd50f2666a382c4b85f923c02a5460d4bce515c> > 8233404: System property to set the number of PBE iterations in JCEKS > keystores commit/0e5a288dfe0b90e0d2c8c6288334fb9847a4f403> > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE > field commit/171257ea1aa210d13e7604994e90ad334ed51875> > 8005819: Support cross-realm MSSFU commit/4fa827ec92665dae9c3cd6505d885ba5b7998df2> > 8238555: Allow Initialization of SunPKCS11 with NSS when there are > external FIPS modules in the NSSDB commit/84f3e86749be8b84b6f39262cfdd160e651d6dba> > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in > AD commit/2883bccf48f7a63c3635a0792138c5481050966f> > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one commit/1c651455a75ff21770bb3b112a440396fce402a5> > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets commit/31753ef9bf2508727021cb40fd0cf761502bd814> > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > commit/4be2173478bd1e84946bd903b350ce466bddb36b> > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > commit/47c7dc7734677b64511ab1d4b3c30d3197d66ce9> > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding commit/1ee80e03adfae5f428519f7c134e78a0f277a0a5> > 8265462: Handle multiple slots in the NSS Internal Module from > SunPKCS11's Secmod bdbe23b9cb6151c81a4de675e629b0a42f00640d> > 8270137: Kerberos Credential Retrieval from Cache not Working in Cross- > Realm Setup commit/67869b491ae1eaf311dfb8c61a9e94329a822ffc> > 8271566: DSA signature length value is not accurate in P11Signature > ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3> > 8275535: Retrying a failed authentication on multiple LDAP servers can > lead to users blocked commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e> > 8301553: Support Password-Based Cryptography in SunPKCS11 github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444> > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 commit/760cb04a2e099a3af9199d77a234af75a18cce5d> > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > commit/0f5f3c9b9718c610406088327401210486447462> > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software > Token commit/13cf0707f903609c9bda99a9bf7511f494f9feae> > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) commit/8a8d9288980513db459f7d6b36554b65844951ca> > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e> > 8323231: Improve array management commit/5f365d44be9c1f3413c9ccde970e2745090a516a> > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > commit/3251eea1f4289a0505052be204407c02ca38b0ad> > 8319332: Security properties files inclusion openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab> > 8332644: Improve graph optimizations commit/c89f76c0b9ca085192775af9bd9368562b582dd6> > 8345221: Replace legacy with new Provider APIs in SunNativeGSS github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb> > 8330045: Enhance array handling commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7> > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa> > From rwestrel at redhat.com Wed Apr 9 12:22:41 2025 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 09 Apr 2025 08:22:41 -0400 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: <87ikndjzhq.fsf@redhat.com> Vote: yes Roland. From daniel.fuchs at oracle.com Wed Apr 9 17:09:25 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 9 Apr 2025 18:09:25 +0100 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: <51c0d269-b83f-44a5-8281-caff53dd3f6f@oracle.com> Vote: yes best regards, -- daniel On 08/04/2025 17:20, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. From mikael.vidstedt at oracle.com Wed Apr 9 22:08:04 2025 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 9 Apr 2025 22:08:04 +0000 Subject: CFV: New JDK Committer: Daniel Skantz In-Reply-To: References: Message-ID: <9E2BDFE1-9E29-4275-B087-F06F53F15EC0@oracle.com> Vote: yes Cheers, Mikael > On Apr 3, 2025, at 12:37?AM, Roberto Castaneda Lozano wrote: > > I hereby nominate Daniel Skantz to JDK Committer. > > Daniel is a member of the JVM Sustaining team at Oracle. Besides maintaining the HotSpot compilers and other JVM components in JDK Updates at Oracle, Daniel has made significant contributions to the reliability and diagnosability of mainline HotSpot, including significant improvements in compiler randomization, bailouts, IGV support, and test infrastructure, as well as complex C1 bug fixes. He has so far contributed 10 changes to HotSpot [1], of which at least the following 9 are significant: > > https://github.com/openjdk/jdk/pull/24350 > https://github.com/openjdk/jdk/pull/22482 > https://github.com/openjdk/jdk/pull/22481 > https://github.com/openjdk/jdk/pull/19646 > https://github.com/openjdk/jdk/pull/19095 > https://github.com/openjdk/jdk/pull/15938 > https://github.com/openjdk/jdk/pull/14492 > https://github.com/openjdk/jdk/pull/12683 > https://github.com/openjdk/jdk/pull/22823 > > Votes are due by Thursday, 17 April 2025 at 09:00 UTC. > > Only current JDK Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Best Regards, > > Roberto Casta?eda Lozano > > [1] https://github.com/openjdk/jdk/pulls?q=is%3Apr+author%3Adanielogh+label%3Aintegrated > [2] https://openjdk.org/census > [3] https://openjdk.org/projects/#committer-vote From mikael.vidstedt at oracle.com Wed Apr 9 22:09:35 2025 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 9 Apr 2025 22:09:35 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <907C4D53-4565-4512-8987-3D443C7FE664@oracle.com> Vote: yes Cheers, Mikael > On Apr 3, 2025, at 12:48?PM, Vladimir Kozlov wrote: > > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org > From rwestrel at redhat.com Thu Apr 10 08:48:39 2025 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 10 Apr 2025 04:48:39 -0400 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: <87a58ojtaw.fsf@redhat.com> Vote: yes Roland. From chen.l.liang at oracle.com Thu Apr 10 14:29:23 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 10 Apr 2025 14:29:23 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes (Seems a previous vote attempt went to jdk-dev-retn) ________________________________ From: jdk-dev on behalf of Vladimir Kozlov Sent: Thursday, April 3, 2025 2:49:09 PM To: jdk-dev Subject: CFV: New JDK Reviewer: Eric Caspole I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. Eric is a member of the HotSpot performance team at Oracle. He concentrates on performance testing to make sure we don't have regressions. He has contributed over 50 changes [3] to JDK over the past 10 years. Votes are due by 8:00 PM UTC, April 17, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Vladimir Kozlov [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40openjdk.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerard.ziemski at oracle.com Thu Apr 10 15:28:18 2025 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 10 Apr 2025 15:28:18 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at oracle.com Thu Apr 10 21:13:41 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 10 Apr 2025 17:13:41 -0400 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: Yes On 4/8/25 12:20 PM, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. From valerie.peng at oracle.com Fri Apr 11 22:39:23 2025 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 11 Apr 2025 22:39:23 +0000 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: Yes -----Original Message----- From: jdk-dev On Behalf Of Andrew Dinn Sent: Tuesday, April 8, 2025 9:20 AM To: jdk-dev Subject: CFV: New JDK Reviewer: Martin Balao I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. Martin joined the Red Hat Java Platform team in 2017 as its security expert, leading all Red Hat work related to OpenJDK security. He has been a member of the OpenJDK Vulnerability Group since its inception, actively involved both in preparing & reviewing reproducers/fixes for undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles for mainline/LTS updates releases. He has also been an active contributor to mainline security development work and bears prime responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. As well as reviewing multiple security patches in the VG, Martin has contributed 46 changes [4] to mainline JDK over the past 8 years. Votes are due by 24:00 UTC, April 22, 2025. Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Andrew Dinn [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://openjdk.org/jeps/8325511 [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS uses sqlite 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong 8203182: Release session if initialization of SunPKCS11 Signature fails 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS initialization failed" on NSS 3.34.1 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider 8213154: Update copyright headers of files in src tree that are missing Classpath exception 8204142: AWT hang occurs when sequenced events arrive out of sequence in multiple AppContexts 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit process address space 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after JDK-8216597 (SIGBUS error in getNativeKeyInfo) 8219011: Implement MacroAssembler::warn method on AArch64 8218854: FontMetrics.getMaxAdvance may be less than the maximum FontMetrics.charWidth 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 crypto provider 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 crypto provider 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256 8223482: Unsupported ciphersuites may be offered by a TLS client 8215032: Support Kerberos cross-realm referrals (RFC 6806) 8227437: S4U2proxy cannot continue because server's TGT cannot be found 8233404: System property to set the number of PBE iterations in JCEKS keystores 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE field 8005819: Support cross-realm MSSFU 8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS Kerberos tickets 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures 8261355: No data buffering in SunPKCS11 Cipher encryption when the underlying mechanism has no padding 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's Secmod 8270137: Kerberos Credential Retrieval from Cache not Working in Cross-Realm Setup 8271566: DSA signature length value is not accurate in P11Signature 8275535: Retrying a failed authentication on multiple LDAP servers can lead to users blocked 8301553: Support Password-Based Cryptography in SunPKCS11 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after JDK-8301553 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software Token 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, AVX-512) 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 8323231: Improve array management 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 8319332: Security properties files inclusion 8332644: Improve graph optimizations 8345221: Replace legacy with new Provider APIs in SunNativeGSS 8330045: Enhance array handling 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic keys in SunPKCS11 SecretKeyFactor From yan at azul.com Mon Apr 14 09:41:53 2025 From: yan at azul.com (Yuri Nesterenko) Date: Mon, 14 Apr 2025 13:41:53 +0400 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: <3211c186-f38d-47ca-9242-3c703a1a9d99@azul.com> Vote: yes --yan On 4/8/25 20:20, Andrew Dinn wrote: > > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > From volker.simonis at gmail.com Mon Apr 14 10:51:52 2025 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 14 Apr 2025 12:51:52 +0200 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes Andrew Dinn schrieb am Di., 8. Apr. 2025, 18:21: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security > expert, leading all Red Hat work related to OpenJDK security. He has > been a member of the OpenJDK Vulnerability Group since its inception, > actively involved both in preparing & reviewing reproducers/fixes for > undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles > for mainline/LTS updates releases. He has also been an active > contributor to mainline security development work and bears prime > responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. > As well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension > < > https://github.com/openjdk/jdk/commit/82bf0799c67f224ffb1875e630f5152e8410ad14 > > > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite > < > https://github.com/openjdk/jdk/commit/f1212e26c3126297268374142cf285ee66fe4e60 > > > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > < > https://github.com/openjdk/jdk/commit/a79484396d8753bfa677426945c6cfac536a9c8c > > > 8203182: Release session if initialization of SunPKCS11 Signature fails > < > https://github.com/openjdk/jdk/commit/62c97f695f1650963d4c1f68364c99f9315fbd76 > > > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with > "NSS initialization failed" on NSS 3.34.1 > < > https://github.com/openjdk/jdk/commit/b44c24d290362e4edf5b0bf18b1ecce1583daeff > > > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > < > https://github.com/openjdk/jdk/commit/aafb2b04740911742de1332a83d23eefe1e6804d > > > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception > < > https://github.com/openjdk/jdk/commit/7724fd6d9bf52bc3aa7d5940b829503dc57e5042 > > > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts > < > https://github.com/openjdk/jdk/commit/7c14ebfcd04b147cd6972e3a7242f4b97b1f97e5 > > > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit > process address space > < > https://github.com/openjdk/jdk/commit/dfcab1b85ae9ca39b95cf3b17cbfbaea1238aec7 > > > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) > < > https://github.com/openjdk/jdk/commit/6cfcdde523ed3875cbe31379e04a745891816fcb > > > 8219011: Implement MacroAssembler::warn method on AArch64 > < > https://github.com/openjdk/jdk/commit/d6bec9017ec205fe790aaed2e4721b2f85b674f3 > > > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth > < > https://github.com/openjdk/jdk/commit/ae9ee277b6eca4cbcd91948e7c518c4a797e6d84 > > > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 > crypto provider > < > https://github.com/openjdk/jdk/commit/0814229ebc94f6821789391df29c34610164b47f > > > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 > crypto provider > < > https://github.com/openjdk/jdk/commit/0d35ef38e6f11d4f5bafaefc3d97567c18b57857 > > > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > < > https://github.com/openjdk/jdk/commit/a8a29bbae66da112b6012a4d5c7cbf5270b1573a > > > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 > < > https://github.com/openjdk/jdk/commit/11bb97a71c805344c051e4fba75096a539528000 > > > 8223482: Unsupported ciphersuites may be offered by a TLS client > < > https://github.com/openjdk/jdk/commit/ebf8e1c0ac605a0613c343d37abece6d57cd9698 > > > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > < > https://github.com/openjdk/jdk/commit/5aae9ef0db20101c5a1473426e5dcd6f8a625c6a > > > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > < > https://github.com/openjdk/jdk/commit/3cd50f2666a382c4b85f923c02a5460d4bce515c > > > 8233404: System property to set the number of PBE iterations in JCEKS > keystores > < > https://github.com/openjdk/jdk/commit/0e5a288dfe0b90e0d2c8c6288334fb9847a4f403 > > > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE > field > < > https://github.com/openjdk/jdk/commit/171257ea1aa210d13e7604994e90ad334ed51875 > > > 8005819: Support cross-realm MSSFU > < > https://github.com/openjdk/jdk/commit/4fa827ec92665dae9c3cd6505d885ba5b7998df2 > > > 8238555: Allow Initialization of SunPKCS11 with NSS when there are > external FIPS modules in the NSSDB > < > https://github.com/openjdk/jdk/commit/84f3e86749be8b84b6f39262cfdd160e651d6dba > > > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in > AD > < > https://github.com/openjdk/jdk/commit/2883bccf48f7a63c3635a0792138c5481050966f > > > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one > < > https://github.com/openjdk/jdk/commit/1c651455a75ff21770bb3b112a440396fce402a5 > > > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets > < > https://github.com/openjdk/jdk/commit/31753ef9bf2508727021cb40fd0cf761502bd814 > > > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > < > https://github.com/openjdk/jdk/commit/4be2173478bd1e84946bd903b350ce466bddb36b > > > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > < > https://github.com/openjdk/jdk/commit/47c7dc7734677b64511ab1d4b3c30d3197d66ce9 > > > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding > < > https://github.com/openjdk/jdk/commit/1ee80e03adfae5f428519f7c134e78a0f277a0a5 > > > 8265462: Handle multiple slots in the NSS Internal Module from > SunPKCS11's Secmod > < > https://github.com/openjdk/jdk/commit/bdbe23b9cb6151c81a4de675e629b0a42f00640d > > > 8270137: Kerberos Credential Retrieval from Cache not Working in > Cross-Realm Setup > < > https://github.com/openjdk/jdk/commit/67869b491ae1eaf311dfb8c61a9e94329a822ffc > > > 8271566: DSA signature length value is not accurate in P11Signature > < > https://github.com/openjdk/jdk/commit/ea8d3c92c69c393cdbc6c62398f1e9c6adc708d3 > > > 8275535: Retrying a failed authentication on multiple LDAP servers can > lead to users blocked > < > https://github.com/openjdk/jdk/commit/3be394e1606dd17c2c14ce806c796f5eb2b1ad6e > > > 8301553: Support Password-Based Cryptography in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/4a75fd462c002a209201d8bfc8d6c9eb286a7444 > > > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 > < > https://github.com/openjdk/jdk/commit/760cb04a2e099a3af9199d77a234af75a18cce5d > > > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > < > https://github.com/openjdk/jdk/commit/0f5f3c9b9718c610406088327401210486447462 > > > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software > Token > < > https://github.com/openjdk/jdk/commit/13cf0707f903609c9bda99a9bf7511f494f9feae > > > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > < > https://github.com/openjdk/jdk/commit/8a8d9288980513db459f7d6b36554b65844951ca > > > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e > > > 8323231: Improve array management > < > https://github.com/openjdk/jdk/commit/5f365d44be9c1f3413c9ccde970e2745090a516a > > > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > < > https://github.com/openjdk/jdk/commit/3251eea1f4289a0505052be204407c02ca38b0ad > > > 8319332: Security properties files inclusion > < > https://github.com/openjdk/jdk/commit/c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab > > > 8332644: Improve graph optimizations > < > https://github.com/openjdk/jdk/commit/c89f76c0b9ca085192775af9bd9368562b582dd6 > > > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > < > https://github.com/openjdk/jdk/commit/a49f0776eb176129f558b6fab3f50e0453f8cbcb > > > 8330045: Enhance array handling > < > https://github.com/openjdk/jdk/commit/5f6c85420a19d5dd9ccaf0a0c6e8f6502fab2aa7 > > > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor > < > https://github.com/openjdk/jdk/commit/6ddbcc34c019d780fc12d8f636e3aa3de33ecaaa > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Mon Apr 14 19:17:18 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 14 Apr 2025 19:17:18 +0000 Subject: New candidate JEP: 505: Structured Concurrency (Fifth Preview) Message-ID: <20250414191718.4C950811867@eggemoggin.niobe.net> https://openjdk.org/jeps/505 Summary: Simplify concurrent programming by introducing an API for structured concurrency. Structured concurrency treats groups of related tasks running in different threads as single units of work, thereby streamlining error handling and cancellation, improving reliability, and enhancing observability. This is a preview API. - Mark From zjx001202 at gmail.com Mon Apr 14 19:34:57 2025 From: zjx001202 at gmail.com (Glavo) Date: Tue, 15 Apr 2025 03:34:57 +0800 Subject: New candidate JEP: 505: Structured Concurrency (Fifth Preview) In-Reply-To: <20250414191718.4C950811867@eggemoggin.niobe.net> References: <20250414191718.4C950811867@eggemoggin.niobe.net> Message-ID: Hi Mark, I noticed an error and a formatting issue in the document: 1. Missing closing bracket before the `throws`: List runConcurrently(Collection> tasks throws InterruptedException { > try (var scope = StructuredTaskScope.open(Joiner.allSuccessfulOrThrow())) { > tasks.forEach(scope::fork); > return scope.join().map(Subtask::get).toList(); > } > } > > 2. There is extra space after the `extends` in `Subtask`: class CollectingJoiner implements Joiner> { > > private final Queue results = new ConcurrentLinkedQueue<>(); > > public boolean onComplete(Subtask subtask) { > if (subtask.state() == Subtask.State.SUCCESS) { > results.add(subtask.get()); > } > return false; > } > > public Stream result() { > return results.stream(); > } > > } > > Glavo On Tue, Apr 15, 2025 at 3:17?AM Mark Reinhold wrote: > https://openjdk.org/jeps/505 > > Summary: Simplify concurrent programming by introducing an API for > structured concurrency. Structured concurrency treats groups of > related tasks running in different threads as single units of work, > thereby streamlining error handling and cancellation, improving > reliability, and enhancing observability. This is a preview API. > > - Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.reinhold at oracle.com Mon Apr 14 19:43:12 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 14 Apr 2025 19:43:12 +0000 Subject: New candidate JEP: 506: Scoped Values Message-ID: <20250414194312.2AA63811870@eggemoggin.niobe.net> https://openjdk.org/jeps/506 Summary: Introduce scoped values, which enable a method to share immutable data both with its callees within a thread, and with child threads. Scoped values are easier to reason about than thread-local variables. They also have lower space and time costs, especially when used together with virtual threads (JEP 444) and structured concurrency (JEP 505). - Mark From mark.reinhold at oracle.com Mon Apr 14 20:02:27 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 14 Apr 2025 20:02:27 +0000 Subject: New candidate JEP: 507: Primitive Types in Patterns, instanceof, and switch (Third Preview) Message-ID: <20250414200226.16F9A81187B@eggemoggin.niobe.net> https://openjdk.org/jeps/507 Summary: Enhance pattern matching by allowing primitive types in all pattern contexts, and extend instanceof and switch to work with all primitive types. This is a preview language feature. - Mark From mark.reinhold at oracle.com Mon Apr 14 20:19:35 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 14 Apr 2025 20:19:35 +0000 Subject: New candidate JEP: 508: Vector API (Tenth Incubator) Message-ID: <20250414201935.1B43F811883@eggemoggin.niobe.net> https://openjdk.org/jeps/508 Summary: Introduce an API to express vector computations that reliably compile at runtime to optimal vector instructions on supported CPU architectures, thus achieving performance superior to equivalent scalar computations. - Mark From mark.reinhold at oracle.com Mon Apr 14 20:37:35 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 14 Apr 2025 20:37:35 +0000 Subject: Proposed schedule for JDK 25 In-Reply-To: <20250403132912.2149689@eggemoggin.niobe.net> References: <20250403132912.2149689@eggemoggin.niobe.net> Message-ID: <20250414163734.987556893@eggemoggin.niobe.net> 2025/4/3 13:29:13 -0400, mark.reinhold at oracle.com: > Here is the proposed schedule for JDK 25: > > 2025/06/05 Rampdown Phase One > 2025/07/17 Rampdown Phase Two > 2025/08/07 Initial Release Candidate > 2025/08/21 Final Release Candidate > 2025/09/16 General Availability > > The phases are defined in JEP 3 [1]. > > Comments on this proposal from JDK Committers and Reviewers [2] are > welcome, as are reasoned objections. If no such objections are raised > by 18:00 UTC next Thursday, 10 April, or if they?re raised and then > satisfactorily answered, then per the JEP 2.0 process proposal [3] > this will be the schedule for JDK 25. Hearing no objections, this is now the schedule for JDK 25. - Mark From chen.l.liang at oracle.com Tue Apr 15 05:29:49 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 15 Apr 2025 05:29:49 +0000 Subject: Clarification on javap's -bootclasspath Behavior in JDK 24 In-Reply-To: References: Message-ID: Hi Babneet, sorry for a late reply, created https://bugs.openjdk.org/browse/JDK-8354563 to track this. Unfortunately JDK developers are busy with other areas and work may be slow, so feel free to contribute a patch if you want to. Also javap problems usually go to the compiler-dev list instead of the jdk-dev list, which is usually more about changes with all-jdk impact, such as governance. Thank you for asking the appropriate list. Regards, Chen Liang ________________________________ From: jdk-dev on behalf of Babneet Singh Sent: Monday, February 24, 2025 12:08 PM To: jdk-dev at openjdk.org Subject: Clarification on javap's -bootclasspath Behavior in JDK 24 One or more of the following files ( object_i.txt ) violates IBM policy and all attachment(s) have been removed from the message. ________________________________ Hi, I would like to inquire about changes to javap's -bootclasspath option in JDK 24. In previous versions, -bootclasspath allowed overriding classes in the java.base module. However, I have observed different behavior in JDK 24 when using javap -bootclasspath. I have attached object_i.jar (as object_i.txt; it should be renamed before use), which contains a modified version of the java.lang.Object class with an injected field: private int i. In JDK 23, using -bootclasspath successfully overrides the default java.lang.Object class with this modified version. However, in JDK 24, the override does not occur. The observed behaviour across JDK23 and JDK24 is shown below. Is this new behavior intentional (part of a new feature), or is it a bug? I couldn't find a mailing list specifically for javap. If this is not the appropriate mailing list for this inquiry, I would appreciate guidance on where to direct my question. Regards, Babneet Observed Behavior: ==== JDK 23 and Prior Versions ==== # jdk23/Contents/Home/bin/javap -p -bootclasspath object_i.jar java/lang/Object Compiled from "Object.java" public class java.lang.Object { // Injected field shows up private int i; public java.lang.Object(); protected java.lang.Object clone() throws java.lang.CloneNotSupportedException; public boolean equals(java.lang.Object); protected void finalize() throws java.lang.Throwable; public final native java.lang.Class getClass(); public int hashCode(); public final native void notify(); public final native void notifyAll(); public java.lang.String toString(); public final void wait() throws java.lang.InterruptedException; public final void wait(long) throws java.lang.InterruptedException; public final void wait(long, int) throws java.lang.InterruptedException; private final native void waitImpl(long, int) throws java.lang.InterruptedException; private java.lang.Object newInstancePrototype(java.lang.Class); } ==== JDK 24 ==== # jdk24/Contents/Home/bin/javap -p -bootclasspath object_i.jar java/lang/Object Compiled from "Object.java" public class java.lang.Object { // Injected field doesn't show up public java.lang.Object(); public final native java.lang.Class getClass(); public native int hashCode(); public boolean equals(java.lang.Object); protected native java.lang.Object clone() throws java.lang.CloneNotSupportedException; public java.lang.String toString(); public final native void notify(); public final native void notifyAll(); public final void wait() throws java.lang.InterruptedException; public final void wait(long) throws java.lang.InterruptedException; private final native void wait0(long) throws java.lang.InterruptedException; public final void wait(long, int) throws java.lang.InterruptedException; protected void finalize() throws java.lang.Throwable; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Tue Apr 15 07:42:29 2025 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Apr 2025 07:42:29 +0000 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Andrew Dinn > Sent: Dienstag, 8. April 2025 18:20 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Martin Balao > > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security expert, > leading all Red Hat work related to OpenJDK security. He has been a member > of the OpenJDK Vulnerability Group since its inception, actively involved both > in preparing & reviewing reproducers/fixes for undisclosed CVEs and in > planning & preparing 3-monthly CVE patch bundles for mainline/LTS updates > releases. He has also been an active contributor to mainline security > development work and bears prime responsibility for Draft JEP 8325511 > (Security Providers Filter) [3]. > As well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension > 152e8410ad14> > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite > 285ee66fe4e60> > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > c6cfac536a9c8c> > 8203182: Release session if initialization of SunPKCS11 Signature fails > c99f9315fbd76> > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with "NSS > initialization failed" on NSS 3.34.1 > ecce1583daeff> > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > d23eefe1e6804d> > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception > 9503dc57e5042> > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts > 2f4b97b1f97e5> > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit > process address space > fbaea1238aec7> > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) > a745891816fcb> > 8219011: Implement MacroAssembler::warn method on AArch64 > 21b2f85b674f3> > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth > 18c4a797e6d84> > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 > crypto provider > c34610164b47f> > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 > crypto provider > 567c18b57857> > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > 7cbf5270b1573a> > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 > 096a539528000> > 8223482: Unsupported ciphersuites may be offered by a TLS client > ece6d57cd9698> > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > dcd6f8a625c6a> > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > 5460d4bce515c> > 8233404: System property to set the number of PBE iterations in JCEKS > keystores > 4fb9847a4f403> > 8233946: Add @since 13 annotation to > KerberosPrincipal.KRB_NT_ENTERPRISE > field > 90ad334ed51875> > 8005819: Support cross-realm MSSFU > 85ba5b7998df2> > 8238555: Allow Initialization of SunPKCS11 with NSS when there are external > FIPS modules in the NSSDB > d160e651d6dba> > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in > AD > 8c5481050966f> > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one > 40396fce402a5> > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets > cf761502bd814> > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > 50ce466bddb36b> > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > c30d3197d66ce9> > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding > 78a0f277a0a5> > 8265462: Handle multiple slots in the NSS Internal Module from SunPKCS11's > Secmod > 29b0a42f00640d> > 8270137: Kerberos Credential Retrieval from Cache not Working in Cross- > Realm Setup > e94329a822ffc> > 8271566: DSA signature length value is not accurate in P11Signature > e9c6adc708d3> > 8275535: Retrying a failed authentication on multiple LDAP servers can lead to > users blocked > 96f5eb2b1ad6e> > 8301553: Support Password-Based Cryptography in SunPKCS11 > 6c9eb286a7444> > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 > 4af75a18cce5d> > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > 1210486447462> > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software > Token > 511f494f9feae> > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > 554b65844951ca> > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > 16820c906e70e> > 8323231: Improve array management > 2745090a516a> > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > 407c02ca38b0ad> > 8319332: Security properties files inclusion > dae0e8e28b4ab> > 8332644: Improve graph optimizations > 368562b582dd6> > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > 50e0453f8cbcb> > 8330045: Enhance array handling > f6502fab2aa7> > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor > 3aa3de33ecaaa> From christoph.langer at sap.com Tue Apr 15 07:44:09 2025 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 15 Apr 2025 07:44:09 +0000 Subject: CFV: New JDK Reviewer: Eric Caspole In-Reply-To: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> References: <0165f5c8-dcfc-49c9-8b79-8e4e5e4724d4@oracle.com> Message-ID: Vote:yes /Christoph > -----Original Message----- > From: jdk-dev On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 3. April 2025 21:49 > To: jdk-dev > Subject: CFV: New JDK Reviewer: Eric Caspole > > I hereby nominate Eric Caspole (ecaspole) to JDK Reviewer. > > Eric is a member of the HotSpot performance team at Oracle. He concentrates > on performance testing to make sure we don't have regressions. He has > contributed over 50 changes [3] to JDK over the past 10 years. > > Votes are due by 8:00 PM UTC, April 17, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Vladimir Kozlov > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] > https://github.com/openjdk/jdk/commits/master/?author=ecaspole%40ope > njdk.org From aph-open at littlepinkcloud.com Tue Apr 15 08:14:07 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 15 Apr 2025 09:14:07 +0100 Subject: CFV: New JDK Reviewer: Martin Balao In-Reply-To: References: Message-ID: Vote: yes On 08/04/2025 17:20, Andrew Dinn wrote: > I hereby nominate Martin Balao (mbalao) [1] to JDK Reviewer. > > Martin joined the Red Hat Java Platform team in 2017 as its security > expert, leading all Red Hat work related to OpenJDK security. He has > been a member of the OpenJDK Vulnerability Group since its inception, > actively involved both in preparing & reviewing reproducers/fixes for > undisclosed CVEs and in planning & preparing 3-monthly CVE patch bundles > for mainline/LTS updates releases. He has also been an active > contributor to mainline security development work and bears prime > responsibility for Draft JEP 8325511 (Security Providers Filter) [3]. > As well as reviewing multiple security patches in the VG, Martin has > contributed 46 changes [4] to mainline JDK over the past 8 years. > > Votes are due by 24:00 UTC, April 22, 2025. > > Only current JDK Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying > to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Andrew Dinn > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://openjdk.org/jeps/8325511 > [4] 8148421: Transport Layer Security (TLS) Session Hash and Extended > Master Secret Extension > > 8165996: PKCS11 using NSS throws an error regarding secmod.db when NSS > uses sqlite > > 8201509: Zero: S390 31bit atomic_copy64 inline assembler is wrong > > 8203182: Release session if initialization of SunPKCS11 Signature fails > > 8195607: sun/security/pkcs11/Secmod/TestNssDbSqlite.java failed with > "NSS initialization failed" on NSS 3.34.1 > > 8029661: Support TLS v1.2 algorithm in SunPKCS11 provider > > 8213154: Update copyright headers of files in src tree that are missing > Classpath exception > > 8204142: AWT hang occurs when sequenced events arrive out of sequence in > multiple AppContexts > > 6913047: Long term memory leak when using PKCS11 and JCE exceeds 32 bit > process address space > > 8217088: Disable JDK-6913047 fix (SunPKCS11 memory leak) after > JDK-8216597 (SIGBUS error in getNativeKeyInfo) > > 8219011: Implement MacroAssembler::warn method on AArch64 > > 8218854: FontMetrics.getMaxAdvance may be less than the maximum > FontMetrics.charWidth > > 8220753: Re-introduce the test case for TLS 1.2 algorithms in SunPKCS11 > crypto provider > > 8220513: Wrapper Key may get deleted when closing sessions in SunPKCS11 > crypto provider > > 8221271: sun/security/pkcs11/tls/tls12/TestTLS12.java test failed > > 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with > Unsupported signature algorithm: rsa_pss_rsae_sha256 > > 8223482: Unsupported ciphersuites may be offered by a TLS client > > 8215032: Support Kerberos cross-realm referrals (RFC 6806) > > 8227437: S4U2proxy cannot continue because server's TGT cannot be found > > 8233404: System property to set the number of PBE iterations in JCEKS > keystores > > 8233946: Add @since 13 annotation to KerberosPrincipal.KRB_NT_ENTERPRISE > field > > 8005819: Support cross-realm MSSFU > > 8238555: Allow Initialization of SunPKCS11 with NSS when there are > external FIPS modules in the NSSDB > > 8239385: KerberosTicket client name refers wrongly to sAMAccountName in > AD > > 8241888: Mirror jdk.security.allowNonCaAnchor system property with a > security one > > 8250582: Revert Principal Name type to NT-UNKNOWN when requesting TGS > Kerberos tickets > > 8259319: Illegal package access when SunPKCS11 requires SunJCE's classes > > 8258833: Cancel multi-part cipher operations in SunPKCS11 after failures > > 8261355: No data buffering in SunPKCS11 Cipher encryption when the > underlying mechanism has no padding > > 8265462: Handle multiple slots in the NSS Internal Module from > SunPKCS11's Secmod > > 8270137: Kerberos Credential Retrieval from Cache not Working in > Cross-Realm Setup > > 8271566: DSA signature length value is not accurate in P11Signature > > 8275535: Retrying a failed authentication on multiple LDAP servers can > lead to users blocked > > 8301553: Support Password-Based Cryptography in SunPKCS11 > > 8309569: sun/security/pkcs11/Signature/TestRSAKeyLength.java fails after > JDK-8301553 > > 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive > > 8328556: Do not extract large CKO_SECRET_KEY keys from the NSS Software > Token > > 8330611: AES-CTR vector intrinsic may read out of bounds (x86_64, > AVX-512) > > 8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11 > > 8323231: Improve array management > > 8336499: Failure when creating non-CRT RSA private keys in SunPKCS11 > > 8319332: Security properties files inclusion > > 8332644: Improve graph optimizations > > 8345221: Replace legacy with new Provider APIs in SunNativeGSS > > 8330045: Enhance array handling > > 8328119: Support HKDF in SunPKCS11 (Preview) 8346720: Support Generic > keys in SunPKCS11 SecretKeyFactor > > From mark.reinhold at oracle.com Tue Apr 15 20:34:40 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 15 Apr 2025 20:34:40 +0000 Subject: New candidate JEP: 509: JFR CPU-Time Profiling (Experimental) Message-ID: <20250415203439.A65C5811ACD@eggemoggin.niobe.net> https://openjdk.org/jeps/509 Summary: Enhance the JDK Flight Recorder (JFR) to capture CPU-time profiling information on Linux. This is an experimental feature. - Mark From mark.reinhold at oracle.com Tue Apr 15 20:54:24 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 15 Apr 2025 20:54:24 +0000 Subject: New candidate JEP: 510: Key Derivation Function API Message-ID: <20250415205424.3AC39811ADB@eggemoggin.niobe.net> https://openjdk.org/jeps/510 Summary: Introduce an API for Key Derivation Functions (KDFs), which are cryptographic algorithms for deriving additional keys from a secret key and other data. - Mark From roberto.castaneda.lozano at oracle.com Thu Apr 17 09:34:03 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Thu, 17 Apr 2025 09:34:03 +0000 Subject: Result: New JDK Committer: Daniel Skantz Message-ID: Voting for Daniel Skantz [1] is now closed. Yes: 23 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Best Regards, Roberto Casta?eda Lozano [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009858.html From mark.reinhold at oracle.com Thu Apr 17 12:07:20 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 17 Apr 2025 12:07:20 +0000 Subject: New candidate JEP: 511: Module Import Declarations Message-ID: <20250417120719.54FE3811E46@eggemoggin.niobe.net> https://openjdk.org/jeps/511 Summary: Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. - Mark From mark.reinhold at oracle.com Thu Apr 17 12:07:22 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Thu, 17 Apr 2025 12:07:22 +0000 Subject: New candidate JEP: 512: Compact Source Files and Instance Main Methods Message-ID: <20250417120722.47AF8811E48@eggemoggin.niobe.net> https://openjdk.org/jeps/512 Summary: Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. - Mark From vladimir.kozlov at oracle.com Thu Apr 17 16:06:57 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Apr 2025 09:06:57 -0700 Subject: Result: New JDK Reviewer: Eric Caspole Message-ID: Voting for Eric Caspole [1] is now closed. Yes: 39 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Vladimir Kozlov [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009872.html From mark.reinhold at oracle.com Mon Apr 21 18:51:05 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 21 Apr 2025 18:51:05 +0000 Subject: JEP proposed to target JDK 25: 511: Module Import Declarations Message-ID: <20250421185105.011B1812414@eggemoggin.niobe.net> The following JEP is proposed to target JDK 25: 511: Module Import Declarations https://openjdk.org/jeps/511 Summary: Enhance the Java programming language with the ability to succinctly import all of the packages exported by a module. This simplifies the reuse of modular libraries, but does not require the importing code to be in a module itself. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 20:00 UTC on Monday, 28 April, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 25. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Mon Apr 21 20:15:46 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 21 Apr 2025 20:15:46 +0000 Subject: JEP proposed to target JDK 25: 512: Compact Source Files and Instance Main Methods Message-ID: <20250421201543.3196B81241F@eggemoggin.niobe.net> The following JEP is proposed to target JDK 25: 512: Compact Source Files and Instance Main Methods https://openjdk.org/jeps/512 Summary: Evolve the Java programming language so that beginners can write their first programs without needing to understand language features designed for large programs. Far from using a separate dialect of the language, beginners can write streamlined declarations for single-class programs and then seamlessly expand their programs to use more advanced features as their skills grow. Experienced developers can likewise enjoy writing small programs succinctly, without the need for constructs intended for programming in the large. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 21:00 UTC on Monday, 28 April, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 25. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From aph-open at littlepinkcloud.com Tue Apr 22 09:31:19 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 22 Apr 2025 10:31:19 +0100 Subject: Where to put supplementary docs? Message-ID: Sometimes, when reviewing a PR, we have supporting documents to justify a change. These docs can include diagrams, etc. In the past some such documents were put on the webrev server, and sometimes they got lost. One example of such a file is "Fast Subtype Checking in the HotSpot JVM," which explained the (now obsolete) secondary subtype checking algorithm. Today, documents are sometimes uploaded to JIRA or attached to the PR itself. Sometimes they are stored in someone's personal web space, and linked from a PR, and that's when things get lost. It would be better for long-term retention if such documents were included in the JDK repository itself, and committed to the repo as part of the PR. I'm assuming that these files will be fairly small, so will not greatly increase the size of the repo. I propose to add a new subdirectory to jdk/doc, called "ref" or "reference". This is not for every possible reference document, but those that aid the maintainer and will be useful in the future. A comment in the source code should refer the reader to the appropriate reference document. Does anyone here object to this? Is there some other place than "doc/ref" that would be more appropriate? Thanks, Andrew. From mark.reinhold at oracle.com Tue Apr 22 12:02:27 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 22 Apr 2025 12:02:27 +0000 Subject: New candidate JEP: 513: Flexible Constructor Bodies Message-ID: <20250422120226.00091812497@eggemoggin.niobe.net> https://openjdk.org/jeps/513 Summary: In the body of a constructor, allow statements to appear before an explicit constructor invocation, i.e., super(...) or this(...). Such statements cannot reference the object under construction, but they can initialize its fields and perform other safe computations. This change allows many constructors to be expressed more naturally. It also allows fields to be initialized before they become visible to other code in the class, such as methods called from a superclass constructor, thereby improving safety. - Mark From tanksherman27 at gmail.com Tue Apr 22 12:46:34 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Tue, 22 Apr 2025 20:46:34 +0800 Subject: Windows/Zero Message-ID: Hi all, Zero currently cannot compile on Windows, and to my knowledge, has never been able to compile on Windows. This is largely due to Windows lacking crucial implementations for Zero under the os_cpu directory, where you will notice a distinct lack of a windows_zero directory. To remedy this, some time ago, I implemented Zero on Windows. The implementation, aside from adding critical code to windows_zero, also had to ifdef some code out of the Windows Structured Exception filter. It was surprisingly minimal, but the downside is that Windows/Zero then only compiled with gcc. VC had an additional hurdle to jump through: On Zero, since there are no registers, register arrays in certain classes became zero sized arrays, a GNU extension that VC will never accept under any circumstances. I started work again recently to get Zero working with VC. Just 2 days ago, this successfully compiled with VC, albeit with --disable-warnings-as-errors. The code is available at https://github.com/TheShermanTanker/jdk/commits/experimental for anyone curious, under "Windows/Zero Port". Disclaimer: I do not know whether the code is 100% correct, I may have implemented it wrongly. The remaining warnings left over can be seen below this mail. Note that only the release configuration was tested, fastdebug has not been compiled yet. I'd like to float the idea of supporting Windows/Zero properly. Ideally, Zero should run on any platform, so it not running on Windows would be surprising, but past that, the Java Zero VM is extremely small on Windows at just 5MB (Even smaller than the Python Interpreter!), so it could be useful on devices where a small Java VM is desired. More importantly, this could (Although I am not fully certain) open the door to running the latest Java on 32 bit Windows devices again, ever since all the x86 32 bit ports were removed, leaving Zero as the only way to execute Java on 32 bit x86. This may (or may not) help those who cannot get a 64 bit device or one that's running Linux, I haven't checked yet. I also crashed the VM on purpose to get a hserr file which contains VM information, this can be seen below. This was quite interesting, as I've never actually seen Zero crash before! Thoughts? best regards, Julian # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd1518139f, pid=335696, tid=337452 # # JRE version: Java Runtime Environment (25.0) (build 25-internal) # Java VM: Java HotSpot 64-Bit Zero VM (25-internal, interpreted mode, sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # C [Crash.dll+0x139f] # # No core dump will be written. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- S U M M A R Y ------------ Command Line: --enable-preview Crash Host: AMD Ryzen 9 7845HX with Radeon Graphics , 24 cores, 15G, Windows 11 , 64 bit Build 26100 (10.0.26100.3775) Time: Sun Apr 20 03:44:08 2025 Malay Peninsula Standard Time elapsed time: 0.291582 seconds (0d 0h 0m 0s) --------------- T H R E A D --------------- Current thread (0x00000268e57a3d20): JavaThread "main" [_thread_in_native, id=337452, stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] Stack: [0x000000ae07a00000,0x000000ae07b00000], sp=0x000000ae07a842a0, free space=528k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [Crash.dll+0x139f] (no source info available) C [libffi-8.dll+0x4cc1] (no source info available) C [libffi-8.dll+0x48df] (no source info available) C [libffi-8.dll+0x4aa2] (no source info available) V [jvm.dll+0x426645] ZeroInterpreter::native_entry+0x455 (zeroInterpreter_zero.cpp:444) V [jvm.dll+0x425f47] ZeroInterpreter::main_loop+0x127 (zeroInterpreter_zero.cpp:227) V [jvm.dll+0x425d96] ZeroInterpreter::normal_entry+0x36 (zeroInterpreter_zero.cpp:115) V [jvm.dll+0x3b156d] StubGenerator::call_stub+0x1bd (stubGenerator_zero.cpp:84) V [jvm.dll+0x1acbfd] JavaCalls::call_helper+0x48d (javaCalls.cpp:424) V [jvm.dll+0x2e4c80] os::os_exception_wrapper+0x20 (os_windows_zero.cpp:51) V [jvm.dll+0x1c472a] jni_invoke_nonstatic+0x32a (jni.cpp:950) V [jvm.dll+0x1c8ea2] jni_CallVoidMethod+0x142 (jni.cpp:1307) C [jli.dll+0x510f] JavaMain+0x7d3 (java.c:645) C [ucrtbase.dll+0x37b0] (no source info available) C [KERNEL32.DLL+0x2e8d7] (no source info available) C [ntdll.dll+0xb14fc] (no source info available) Java frames: 0x000000ae07aff8f0: unboxed parameter[1] = 0x000000ae07aff9a0 0x000000ae07aff8f8: parameter[0] (JNIEnv) = 0x000000ae07a84410 0x000000ae07aff900: parameter[1] (this) = 0x000000ae07aff8f0 0x000000ae07aff908: istate->_thread = 0x00000268e57a3d20 0x000000ae07aff910: istate->_bcp = 0x0000000000000000 0x000000ae07aff918: istate->_locals = 0x000000ae07aff9a0 0x000000ae07aff920: istate->_constants = 0x00000268c14003a8 0x000000ae07aff928: istate->_method = Crash.crash()V 0x000000ae07aff930: istate->_mirror = 0x000000071ba1cb90 0x000000ae07aff938: istate->_stack = 0x000000ae07aff900 0x000000ae07aff940: istate->_msg = 0x0000026800000002 0x000000ae07aff948: istate->_result = 0x0000000000000000 0x000000ae07aff950: (istate->_result) = 0x000000ae00000003 0x000000ae07aff958: (istate->_result) = 0x0000000000000000 0x000000ae07aff960: istate->_prev_link = 0x0000000000000000 0x000000ae07aff968: istate->_oop_temp = 0x0000000000000000 0x000000ae07aff970: istate->_stack_base = 0x000000ae07aff908 0x000000ae07aff978: istate->_stack_limit = 0x000000ae07aff900 0x000000ae07aff980: istate->_monitor_base = 0x000000ae07aff908 0x000000ae07aff988: istate->_self_link = 0x000000ae07aff908 0x000000ae07aff990: frame_type = INTERPRETER_FRAME 0x000000ae07aff998: next_frame = 0x000000ae07affa38 0x000000ae07aff9a0: local[0] = 0x000000071ba1d940 0x000000ae07aff9a8: istate->_thread = 0x00000268e57a3d20 0x000000ae07aff9b0: istate->_bcp = 0x00000268c14002de (bci 6) 0x000000ae07aff9b8: istate->_locals = 0x000000ae07affa40 0x000000ae07aff9c0: istate->_constants = 0x00000268c14003a8 0x000000ae07aff9c8: istate->_method = Crash.main()V 0x000000ae07aff9d0: istate->_mirror = 0x000000071ba1cb90 0x000000ae07aff9d8: istate->_stack = 0x000000ae07aff998 0x000000ae07aff9e0: istate->_msg = 0x0000026800000008 0x000000ae07aff9e8: istate->_result = 0x00000268c1400238 0x000000ae07aff9f0: (istate->_result) = 0x00000268f1e90458 0x000000ae07aff9f8: (istate->_result) = 0x0000000000000003 0x000000ae07affa00: istate->_prev_link = 0x0000000000000000 0x000000ae07affa08: istate->_oop_temp = 0x0000000000000000 0x000000ae07affa10: istate->_stack_base = 0x000000ae07aff9a8 0x000000ae07affa18: istate->_stack_limit = 0x000000ae07aff990 0x000000ae07affa20: istate->_monitor_base = 0x000000ae07aff9a8 0x000000ae07affa28: istate->_self_link = 0x000000ae07aff9a8 0x000000ae07affa30: frame_type = INTERPRETER_FRAME 0x000000ae07affa38: next_frame = 0x000000ae07affa58 0x000000ae07affa40: local[0] = 0x000000071ba1d940 0x000000ae07affa48: call_wrapper = 0x000000ae07affaf0 0x000000ae07affa50: frame_type = ENTRY_FRAME 0x000000ae07affa58: next_frame = 0x0000000000000000 siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000000 No context information. Register to memory mapping: No register info. Top of Stack: (sp=0x000000ae07a842a0) 0x000000ae07a842a0: 00000000000003d8 0000000000000000 ................ 0x000000ae07a842b0: 0000000000000000 00007ffd16d748df .........H...... 0x000000ae07a842c0: 000002688046f350 0000000000000000 P.F.h........... 0x000000ae07a842d0: 000000ae07a84300 00007ffd16d74cc1 .C.......L...... 0x000000ae07a842e0: 00000268e57a4028 000000ae07aff9a0 (@z.h........... 0x000000ae07a842f0: 0000000000000001 0000000000000050 ........P....... 0x000000ae07a84300: 000000ae07a84350 00007ffd16d748df PC.......H...... 0x000000ae07a84310: 00007ffd15181380 0000000000000000 ................ 0x000000ae07a84320: 000000ae07a84400 0000000000000000 .D.............. 0x000000ae07a84330: 0000000000000001 0000000000000000 ................ 0x000000ae07a84340: 00001664b4a8ce49 111f221225371f8f I...d.....7%.".. 0x000000ae07a84350: 00000268802416f0 00000268e57a3d20 ..$.h... =z.h... 0x000000ae07a84360: 00000268c1400238 000000ae07aff908 8. at .h........... 0x000000ae07a84370: 000000ae07aff9a0 000000ae07aff998 ................ 0x000000ae07a84380: 00000268f1e98710 0000000000000000 ....h........... 0x000000ae07a84390: 000000ae07a84440 00007ffd16d74aa2 @D.......J...... 0x000000ae07a843a0: 0000000000000000 0000000000000001 ................ 0x000000ae07a843b0: 0000000000000000 000000ae07aff998 ................ 0x000000ae07a843c0: 0000000000000000 0000000000000000 ................ 0x000000ae07a843d0: 000000ae07a84440 00007ffceb326645 @D......Ef2..... 0x000000ae07a843e0: 00007ffceb482058 00000268e57a3d20 X H..... =z.h... 0x000000ae07a843f0: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... 0x000000ae07a84400: 000000ae07aff990 000000ae07aff8f8 ................ 0x000000ae07a84410: 00000268e57a4028 0000000000000000 (@z.h........... 0x000000ae07a84420: 00007ffd15181380 0000000000000000 ................ 0x000000ae07a84430: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... 0x000000ae07a84440: 0000000000000001 0000000000000000 ................ 0x000000ae07a84450: 0000000000000000 0000000000000000 ................ 0x000000ae07a84460: 0000000000000000 000000ae07affa38 ........8....... 0x000000ae07a84470: 00000268c14002e8 00007ffceb325f47 .. at .h...G_2..... 0x000000ae07a84480: 00000268e57a3d20 00000268e57a3d20 =z.h... =z.h... 0x000000ae07a84490: 000000ae00084b70 0000000000000000 pK.............. Instructions: (pc=0x00007ffd1518139f) 0x00007ffd1518129f: 00 e8 bb 0e 00 00 41 89 c4 83 fb 03 75 86 e9 5a 0x00007ffd151812af: ff ff ff 66 0f 1f 44 00 00 83 fb 01 0f 85 6f ff 0x00007ffd151812bf: ff ff 49 89 f8 31 d2 48 89 f1 e8 42 fd ff ff e9 0x00007ffd151812cf: 5d ff ff ff 0f 1f 44 00 00 e8 93 01 00 00 49 89 0x00007ffd151812df: f8 ba 01 00 00 00 48 89 f1 e8 73 0e 00 00 41 89 0x00007ffd151812ef: c4 85 c0 0f 85 3b ff ff ff 49 89 f8 31 d2 48 89 0x00007ffd151812ff: f1 e8 5b 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 3e 0x00007ffd1518130f: 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 f1 fc ff ff 0x00007ffd1518131f: e9 0f ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0x00007ffd1518132f: 90 48 8b 05 b9 82 00 00 c7 00 00 00 00 00 e9 8e 0x00007ffd1518133f: fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 0x00007ffd1518134f: 00 48 89 ca 48 8d 0d a6 ac 00 00 e9 f9 62 00 00 0x00007ffd1518135f: 90 48 8d 0d 09 00 00 00 e9 e4 ff ff ff 0f 1f 40 0x00007ffd1518136f: 00 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0x00007ffd1518137f: 90 55 48 89 e5 48 83 ec 30 48 c7 45 f8 00 00 00 0x00007ffd1518138f: 00 48 8b 45 f8 48 8b 45 f8 48 8d 0d 61 7c 00 00 =>0x00007ffd1518139f: 8b 10 e8 ca 0d 00 00 48 8d 0d 56 7c 00 00 48 83 0x00007ffd151813af: c4 30 5d e9 59 63 00 00 90 90 90 90 90 90 90 90 0x00007ffd151813bf: 90 48 83 ec 28 48 8b 05 45 6c 00 00 48 8b 00 48 0x00007ffd151813cf: 85 c0 74 22 0f 1f 44 00 00 ff d0 48 8b 05 2f 6c 0x00007ffd151813df: 00 00 48 8d 50 08 48 8b 40 08 48 89 15 20 6c 00 0x00007ffd151813ef: 00 48 85 c0 75 e3 48 83 c4 28 c3 66 0f 1f 44 00 0x00007ffd151813ff: 00 56 53 48 83 ec 28 48 8b 15 83 81 00 00 48 8b 0x00007ffd1518140f: 02 89 c1 83 f8 ff 74 39 85 c9 74 20 89 c8 83 e9 0x00007ffd1518141f: 01 48 8d 1c c2 48 29 c8 48 8d 74 c2 f8 0f 1f 40 0x00007ffd1518142f: 00 ff 13 48 83 eb 08 48 39 f3 75 f5 48 8d 0d 7e 0x00007ffd1518143f: ff ff ff 48 83 c4 28 5b 5e e9 03 ff ff ff 0f 1f 0x00007ffd1518144f: 00 31 c0 66 0f 1f 44 00 00 44 8d 40 01 89 c1 4a 0x00007ffd1518145f: 83 3c c2 00 4c 89 c0 75 f0 eb ad 66 0f 1f 44 00 0x00007ffd1518146f: 00 8b 05 aa ab 00 00 85 c0 74 06 c3 0f 1f 44 00 0x00007ffd1518147f: 00 c7 05 96 ab 00 00 01 00 00 00 e9 71 ff ff ff 0x00007ffd1518148f: 90 83 fa 03 74 0b 85 d2 74 07 c3 66 0f 1f 44 00 Stack slot to memory mapping: stack at sp + 0 slots: 0x00000000000003d8 is an unknown value stack at sp + 1 slots: 0x0 is null stack at sp + 2 slots: 0x0 is null stack at sp + 3 slots: 0x00007ffd16d748df libffi-8.dll stack at sp + 4 slots: {method} {0x000002688046f358} 'loadLibrary' '(Ljava/lang/Class;Ljava/lang/String;)Ljdk/internal/loader/NativeLibrary;' in 'java/lang/ClassLoader' stack at sp + 5 slots: 0x0 is null stack at sp + 6 slots: 0x000000ae07a84300 is pointing into the stack for thread: 0x00000268e57a3d20 stack at sp + 7 slots: 0x00007ffd16d74cc1 libffi-8.dll Lock stack of current Java thread (top to bottom): --------------- P R O C E S S --------------- Threads class SMR info: _java_thread_list=0x00000268fc0d5850, length=9, elements={ 0x00000268e57a3d20, 0x00000268fc08cfc0, 0x00000268fc08d5f0, 0x00000268fc091710, 0x00000268fc092140, 0x00000268fc0936e0, 0x00000268fc09d2a0, 0x00000268fc0d8ec0, 0x00000268fc0de6e0 } Java Threads: ( => current thread ) =>0x00000268e57a3d20 JavaThread "main" [_thread_in_native, id=337452, stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] 0x00000268fc08cfc0 JavaThread "Reference Handler" daemon [_thread_blocked, id=337356, stack(0x000000ae08200000,0x000000ae08300000) (1024K)] 0x00000268fc08d5f0 JavaThread "Finalizer" daemon [_thread_blocked, id=338708, stack(0x000000ae08300000,0x000000ae08400000) (1024K)] 0x00000268fc091710 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=338204, stack(0x000000ae08400000,0x000000ae08500000) (1024K)] 0x00000268fc092140 JavaThread "Attach Listener" daemon [_thread_blocked, id=338748, stack(0x000000ae08500000,0x000000ae08600000) (1024K)] 0x00000268fc0936e0 JavaThread "Service Thread" daemon [_thread_blocked, id=337172, stack(0x000000ae08600000,0x000000ae08700000) (1024K)] 0x00000268fc09d2a0 JavaThread "Monitor Deflation Thread" daemon [_thread_blocked, id=337312, stack(0x000000ae08700000,0x000000ae08800000) (1024K)] 0x00000268fc0d8ec0 JavaThread "Notification Thread" daemon [_thread_blocked, id=337560, stack(0x000000ae08800000,0x000000ae08900000) (1024K)] 0x00000268fc0de6e0 JavaThread "Common-Cleaner" daemon [_thread_blocked, id=338324, stack(0x000000ae08900000,0x000000ae08a00000) (1024K)] Total: 9 Other Threads: 0x00000268fc07c960 VMThread "VM Thread" [id=337424, stack(0x000000ae08100000,0x000000ae08200000) (1024K)] 0x00000268fbf41360 WatcherThread "VM Periodic Task Thread" [id=333244, stack(0x000000ae08000000,0x000000ae08100000) (1024K)] 0x00000268e7d7d550 WorkerThread "GC Thread#0" [id=336784, stack(0x000000ae07b00000,0x000000ae07c00000) (1024K)] 0x00000268e7d951c0 ConcurrentGCThread "G1 Main Marker" [id=338660, stack(0x000000ae07c00000,0x000000ae07d00000) (1024K)] 0x00000268e7d96850 WorkerThread "G1 Conc#0" [id=19564, stack(0x000000ae07d00000,0x000000ae07e00000) (1024K)] 0x00000268fbf39000 ConcurrentGCThread "G1 Refine#0" [id=217884, stack(0x000000ae07e00000,0x000000ae07f00000) (1024K)] 0x00000268fbf39780 ConcurrentGCThread "G1 Service" [id=338408, stack(0x000000ae07f00000,0x000000ae08000000) (1024K)] Total: 7 Threads with active compile tasks: Total: 0 VM state: not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap address: 0x000000070c800000, size: 3896 MB, Compressed Oops mode: Zero based, Oop shift amount: 3 CDS archive(s) mapped at: [0x0000026880000000-0x0000026880d30000-0x0000026880d30000), size 13828096, SharedBaseAddress: 0x0000026880000000, ArchiveRelocationMode: 1. Compressed class space mapped at: 0x0000026881000000-0x00000268c1000000, reserved size: 1073741824 UseCompressedClassPointers 1, UseCompactObjectHeaders 0 Narrow klass pointer bits 32, Max shift 3 Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 bytes) Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 bytes) Klass ID Range: [65536 - 1090519033) (1090453497) Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) GC Precious Log: CardTable entry size: 512 Card Set container configuration: InlinePtr #cards 4 size 8 Array Of Cards #cards 16 size 48 Howl #buckets 8 coarsen threshold 3686 Howl Bitmap #cards 512 size 80 coarsen threshold 460 Card regions per heap region 1 cards per card region 4096 CPUs: 24 total, 24 available Memory: 15578M Large Page Support: Disabled NUMA Support: Disabled Compressed Oops: Enabled (Zero based) Heap Region Size: 2M Heap Min Capacity: 8M Heap Initial Capacity: 244M Heap Max Capacity: 3896M Pre-touch: Disabled Parallel Workers: 18 Concurrent Workers: 5 Concurrent Refinement Workers: 18 Periodic GC: Disabled Heap: garbage-first heap total reserved 3989504K, committed 251904K, used 1136K [0x000000070c800000, 0x0000000800000000) region size 2048K, 1 young (2048K), 0 survivors (0K) Metaspace used 21K, committed 256K, reserved 1114112K class space used 6K, committed 128K, reserved 1048576K Heap Regions: E=young(eden), S=young(survivor), O=old, HS=humongous(starts), HC=humongous(continues), CS=collection set, F=free, TAMS=top-at-mark-start, PB=parsable bottom | 0|0x000000070c800000, 0x000000070c800000, 0x000000070ca00000| 0%| F| |TAMS 0x000000070c800000| PB 0x000000070c800000| Untracked | 0 | 1|0x000000070ca00000, 0x000000070ca00000, 0x000000070cc00000| 0%| F| |TAMS 0x000000070ca00000| PB 0x000000070ca00000| Untracked | 0 | 2|0x000000070cc00000, 0x000000070cc00000, 0x000000070ce00000| 0%| F| |TAMS 0x000000070cc00000| PB 0x000000070cc00000| Untracked | 0 | 3|0x000000070ce00000, 0x000000070ce00000, 0x000000070d000000| 0%| F| |TAMS 0x000000070ce00000| PB 0x000000070ce00000| Untracked | 0 | 4|0x000000070d000000, 0x000000070d000000, 0x000000070d200000| 0%| F| |TAMS 0x000000070d000000| PB 0x000000070d000000| Untracked | 0 | 5|0x000000070d200000, 0x000000070d200000, 0x000000070d400000| 0%| F| |TAMS 0x000000070d200000| PB 0x000000070d200000| Untracked | 0 | 6|0x000000070d400000, 0x000000070d400000, 0x000000070d600000| 0%| F| |TAMS 0x000000070d400000| PB 0x000000070d400000| Untracked | 0 | 7|0x000000070d600000, 0x000000070d600000, 0x000000070d800000| 0%| F| |TAMS 0x000000070d600000| PB 0x000000070d600000| Untracked | 0 | 8|0x000000070d800000, 0x000000070d800000, 0x000000070da00000| 0%| F| |TAMS 0x000000070d800000| PB 0x000000070d800000| Untracked | 0 | 9|0x000000070da00000, 0x000000070da00000, 0x000000070dc00000| 0%| F| |TAMS 0x000000070da00000| PB 0x000000070da00000| Untracked | 0 | 10|0x000000070dc00000, 0x000000070dc00000, 0x000000070de00000| 0%| F| |TAMS 0x000000070dc00000| PB 0x000000070dc00000| Untracked | 0 | 11|0x000000070de00000, 0x000000070de00000, 0x000000070e000000| 0%| F| |TAMS 0x000000070de00000| PB 0x000000070de00000| Untracked | 0 | 12|0x000000070e000000, 0x000000070e000000, 0x000000070e200000| 0%| F| |TAMS 0x000000070e000000| PB 0x000000070e000000| Untracked | 0 | 13|0x000000070e200000, 0x000000070e200000, 0x000000070e400000| 0%| F| |TAMS 0x000000070e200000| PB 0x000000070e200000| Untracked | 0 | 14|0x000000070e400000, 0x000000070e400000, 0x000000070e600000| 0%| F| |TAMS 0x000000070e400000| PB 0x000000070e400000| Untracked | 0 | 15|0x000000070e600000, 0x000000070e600000, 0x000000070e800000| 0%| F| |TAMS 0x000000070e600000| PB 0x000000070e600000| Untracked | 0 | 16|0x000000070e800000, 0x000000070e800000, 0x000000070ea00000| 0%| F| |TAMS 0x000000070e800000| PB 0x000000070e800000| Untracked | 0 | 17|0x000000070ea00000, 0x000000070ea00000, 0x000000070ec00000| 0%| F| |TAMS 0x000000070ea00000| PB 0x000000070ea00000| Untracked | 0 | 18|0x000000070ec00000, 0x000000070ec00000, 0x000000070ee00000| 0%| F| |TAMS 0x000000070ec00000| PB 0x000000070ec00000| Untracked | 0 | 19|0x000000070ee00000, 0x000000070ee00000, 0x000000070f000000| 0%| F| |TAMS 0x000000070ee00000| PB 0x000000070ee00000| Untracked | 0 | 20|0x000000070f000000, 0x000000070f000000, 0x000000070f200000| 0%| F| |TAMS 0x000000070f000000| PB 0x000000070f000000| Untracked | 0 | 21|0x000000070f200000, 0x000000070f200000, 0x000000070f400000| 0%| F| |TAMS 0x000000070f200000| PB 0x000000070f200000| Untracked | 0 | 22|0x000000070f400000, 0x000000070f400000, 0x000000070f600000| 0%| F| |TAMS 0x000000070f400000| PB 0x000000070f400000| Untracked | 0 | 23|0x000000070f600000, 0x000000070f600000, 0x000000070f800000| 0%| F| |TAMS 0x000000070f600000| PB 0x000000070f600000| Untracked | 0 | 24|0x000000070f800000, 0x000000070f800000, 0x000000070fa00000| 0%| F| |TAMS 0x000000070f800000| PB 0x000000070f800000| Untracked | 0 | 25|0x000000070fa00000, 0x000000070fa00000, 0x000000070fc00000| 0%| F| |TAMS 0x000000070fa00000| PB 0x000000070fa00000| Untracked | 0 | 26|0x000000070fc00000, 0x000000070fc00000, 0x000000070fe00000| 0%| F| |TAMS 0x000000070fc00000| PB 0x000000070fc00000| Untracked | 0 | 27|0x000000070fe00000, 0x000000070fe00000, 0x0000000710000000| 0%| F| |TAMS 0x000000070fe00000| PB 0x000000070fe00000| Untracked | 0 | 28|0x0000000710000000, 0x0000000710000000, 0x0000000710200000| 0%| F| |TAMS 0x0000000710000000| PB 0x0000000710000000| Untracked | 0 | 29|0x0000000710200000, 0x0000000710200000, 0x0000000710400000| 0%| F| |TAMS 0x0000000710200000| PB 0x0000000710200000| Untracked | 0 | 30|0x0000000710400000, 0x0000000710400000, 0x0000000710600000| 0%| F| |TAMS 0x0000000710400000| PB 0x0000000710400000| Untracked | 0 | 31|0x0000000710600000, 0x0000000710600000, 0x0000000710800000| 0%| F| |TAMS 0x0000000710600000| PB 0x0000000710600000| Untracked | 0 | 32|0x0000000710800000, 0x0000000710800000, 0x0000000710a00000| 0%| F| |TAMS 0x0000000710800000| PB 0x0000000710800000| Untracked | 0 | 33|0x0000000710a00000, 0x0000000710a00000, 0x0000000710c00000| 0%| F| |TAMS 0x0000000710a00000| PB 0x0000000710a00000| Untracked | 0 | 34|0x0000000710c00000, 0x0000000710c00000, 0x0000000710e00000| 0%| F| |TAMS 0x0000000710c00000| PB 0x0000000710c00000| Untracked | 0 | 35|0x0000000710e00000, 0x0000000710e00000, 0x0000000711000000| 0%| F| |TAMS 0x0000000710e00000| PB 0x0000000710e00000| Untracked | 0 | 36|0x0000000711000000, 0x0000000711000000, 0x0000000711200000| 0%| F| |TAMS 0x0000000711000000| PB 0x0000000711000000| Untracked | 0 | 37|0x0000000711200000, 0x0000000711200000, 0x0000000711400000| 0%| F| |TAMS 0x0000000711200000| PB 0x0000000711200000| Untracked | 0 | 38|0x0000000711400000, 0x0000000711400000, 0x0000000711600000| 0%| F| |TAMS 0x0000000711400000| PB 0x0000000711400000| Untracked | 0 | 39|0x0000000711600000, 0x0000000711600000, 0x0000000711800000| 0%| F| |TAMS 0x0000000711600000| PB 0x0000000711600000| Untracked | 0 | 40|0x0000000711800000, 0x0000000711800000, 0x0000000711a00000| 0%| F| |TAMS 0x0000000711800000| PB 0x0000000711800000| Untracked | 0 | 41|0x0000000711a00000, 0x0000000711a00000, 0x0000000711c00000| 0%| F| |TAMS 0x0000000711a00000| PB 0x0000000711a00000| Untracked | 0 | 42|0x0000000711c00000, 0x0000000711c00000, 0x0000000711e00000| 0%| F| |TAMS 0x0000000711c00000| PB 0x0000000711c00000| Untracked | 0 | 43|0x0000000711e00000, 0x0000000711e00000, 0x0000000712000000| 0%| F| |TAMS 0x0000000711e00000| PB 0x0000000711e00000| Untracked | 0 | 44|0x0000000712000000, 0x0000000712000000, 0x0000000712200000| 0%| F| |TAMS 0x0000000712000000| PB 0x0000000712000000| Untracked | 0 | 45|0x0000000712200000, 0x0000000712200000, 0x0000000712400000| 0%| F| |TAMS 0x0000000712200000| PB 0x0000000712200000| Untracked | 0 | 46|0x0000000712400000, 0x0000000712400000, 0x0000000712600000| 0%| F| |TAMS 0x0000000712400000| PB 0x0000000712400000| Untracked | 0 | 47|0x0000000712600000, 0x0000000712600000, 0x0000000712800000| 0%| F| |TAMS 0x0000000712600000| PB 0x0000000712600000| Untracked | 0 | 48|0x0000000712800000, 0x0000000712800000, 0x0000000712a00000| 0%| F| |TAMS 0x0000000712800000| PB 0x0000000712800000| Untracked | 0 | 49|0x0000000712a00000, 0x0000000712a00000, 0x0000000712c00000| 0%| F| |TAMS 0x0000000712a00000| PB 0x0000000712a00000| Untracked | 0 | 50|0x0000000712c00000, 0x0000000712c00000, 0x0000000712e00000| 0%| F| |TAMS 0x0000000712c00000| PB 0x0000000712c00000| Untracked | 0 | 51|0x0000000712e00000, 0x0000000712e00000, 0x0000000713000000| 0%| F| |TAMS 0x0000000712e00000| PB 0x0000000712e00000| Untracked | 0 | 52|0x0000000713000000, 0x0000000713000000, 0x0000000713200000| 0%| F| |TAMS 0x0000000713000000| PB 0x0000000713000000| Untracked | 0 | 53|0x0000000713200000, 0x0000000713200000, 0x0000000713400000| 0%| F| |TAMS 0x0000000713200000| PB 0x0000000713200000| Untracked | 0 | 54|0x0000000713400000, 0x0000000713400000, 0x0000000713600000| 0%| F| |TAMS 0x0000000713400000| PB 0x0000000713400000| Untracked | 0 | 55|0x0000000713600000, 0x0000000713600000, 0x0000000713800000| 0%| F| |TAMS 0x0000000713600000| PB 0x0000000713600000| Untracked | 0 | 56|0x0000000713800000, 0x0000000713800000, 0x0000000713a00000| 0%| F| |TAMS 0x0000000713800000| PB 0x0000000713800000| Untracked | 0 | 57|0x0000000713a00000, 0x0000000713a00000, 0x0000000713c00000| 0%| F| |TAMS 0x0000000713a00000| PB 0x0000000713a00000| Untracked | 0 | 58|0x0000000713c00000, 0x0000000713c00000, 0x0000000713e00000| 0%| F| |TAMS 0x0000000713c00000| PB 0x0000000713c00000| Untracked | 0 | 59|0x0000000713e00000, 0x0000000713e00000, 0x0000000714000000| 0%| F| |TAMS 0x0000000713e00000| PB 0x0000000713e00000| Untracked | 0 | 60|0x0000000714000000, 0x0000000714000000, 0x0000000714200000| 0%| F| |TAMS 0x0000000714000000| PB 0x0000000714000000| Untracked | 0 | 61|0x0000000714200000, 0x0000000714200000, 0x0000000714400000| 0%| F| |TAMS 0x0000000714200000| PB 0x0000000714200000| Untracked | 0 | 62|0x0000000714400000, 0x0000000714400000, 0x0000000714600000| 0%| F| |TAMS 0x0000000714400000| PB 0x0000000714400000| Untracked | 0 | 63|0x0000000714600000, 0x0000000714600000, 0x0000000714800000| 0%| F| |TAMS 0x0000000714600000| PB 0x0000000714600000| Untracked | 0 | 64|0x0000000714800000, 0x0000000714800000, 0x0000000714a00000| 0%| F| |TAMS 0x0000000714800000| PB 0x0000000714800000| Untracked | 0 | 65|0x0000000714a00000, 0x0000000714a00000, 0x0000000714c00000| 0%| F| |TAMS 0x0000000714a00000| PB 0x0000000714a00000| Untracked | 0 | 66|0x0000000714c00000, 0x0000000714c00000, 0x0000000714e00000| 0%| F| |TAMS 0x0000000714c00000| PB 0x0000000714c00000| Untracked | 0 | 67|0x0000000714e00000, 0x0000000714e00000, 0x0000000715000000| 0%| F| |TAMS 0x0000000714e00000| PB 0x0000000714e00000| Untracked | 0 | 68|0x0000000715000000, 0x0000000715000000, 0x0000000715200000| 0%| F| |TAMS 0x0000000715000000| PB 0x0000000715000000| Untracked | 0 | 69|0x0000000715200000, 0x0000000715200000, 0x0000000715400000| 0%| F| |TAMS 0x0000000715200000| PB 0x0000000715200000| Untracked | 0 | 70|0x0000000715400000, 0x0000000715400000, 0x0000000715600000| 0%| F| |TAMS 0x0000000715400000| PB 0x0000000715400000| Untracked | 0 | 71|0x0000000715600000, 0x0000000715600000, 0x0000000715800000| 0%| F| |TAMS 0x0000000715600000| PB 0x0000000715600000| Untracked | 0 | 72|0x0000000715800000, 0x0000000715800000, 0x0000000715a00000| 0%| F| |TAMS 0x0000000715800000| PB 0x0000000715800000| Untracked | 0 | 73|0x0000000715a00000, 0x0000000715a00000, 0x0000000715c00000| 0%| F| |TAMS 0x0000000715a00000| PB 0x0000000715a00000| Untracked | 0 | 74|0x0000000715c00000, 0x0000000715c00000, 0x0000000715e00000| 0%| F| |TAMS 0x0000000715c00000| PB 0x0000000715c00000| Untracked | 0 | 75|0x0000000715e00000, 0x0000000715e00000, 0x0000000716000000| 0%| F| |TAMS 0x0000000715e00000| PB 0x0000000715e00000| Untracked | 0 | 76|0x0000000716000000, 0x0000000716000000, 0x0000000716200000| 0%| F| |TAMS 0x0000000716000000| PB 0x0000000716000000| Untracked | 0 | 77|0x0000000716200000, 0x0000000716200000, 0x0000000716400000| 0%| F| |TAMS 0x0000000716200000| PB 0x0000000716200000| Untracked | 0 | 78|0x0000000716400000, 0x0000000716400000, 0x0000000716600000| 0%| F| |TAMS 0x0000000716400000| PB 0x0000000716400000| Untracked | 0 | 79|0x0000000716600000, 0x0000000716600000, 0x0000000716800000| 0%| F| |TAMS 0x0000000716600000| PB 0x0000000716600000| Untracked | 0 | 80|0x0000000716800000, 0x0000000716800000, 0x0000000716a00000| 0%| F| |TAMS 0x0000000716800000| PB 0x0000000716800000| Untracked | 0 | 81|0x0000000716a00000, 0x0000000716a00000, 0x0000000716c00000| 0%| F| |TAMS 0x0000000716a00000| PB 0x0000000716a00000| Untracked | 0 | 82|0x0000000716c00000, 0x0000000716c00000, 0x0000000716e00000| 0%| F| |TAMS 0x0000000716c00000| PB 0x0000000716c00000| Untracked | 0 | 83|0x0000000716e00000, 0x0000000716e00000, 0x0000000717000000| 0%| F| |TAMS 0x0000000716e00000| PB 0x0000000716e00000| Untracked | 0 | 84|0x0000000717000000, 0x0000000717000000, 0x0000000717200000| 0%| F| |TAMS 0x0000000717000000| PB 0x0000000717000000| Untracked | 0 | 85|0x0000000717200000, 0x0000000717200000, 0x0000000717400000| 0%| F| |TAMS 0x0000000717200000| PB 0x0000000717200000| Untracked | 0 | 86|0x0000000717400000, 0x0000000717400000, 0x0000000717600000| 0%| F| |TAMS 0x0000000717400000| PB 0x0000000717400000| Untracked | 0 | 87|0x0000000717600000, 0x0000000717600000, 0x0000000717800000| 0%| F| |TAMS 0x0000000717600000| PB 0x0000000717600000| Untracked | 0 | 88|0x0000000717800000, 0x0000000717800000, 0x0000000717a00000| 0%| F| |TAMS 0x0000000717800000| PB 0x0000000717800000| Untracked | 0 | 89|0x0000000717a00000, 0x0000000717a00000, 0x0000000717c00000| 0%| F| |TAMS 0x0000000717a00000| PB 0x0000000717a00000| Untracked | 0 | 90|0x0000000717c00000, 0x0000000717c00000, 0x0000000717e00000| 0%| F| |TAMS 0x0000000717c00000| PB 0x0000000717c00000| Untracked | 0 | 91|0x0000000717e00000, 0x0000000717e00000, 0x0000000718000000| 0%| F| |TAMS 0x0000000717e00000| PB 0x0000000717e00000| Untracked | 0 | 92|0x0000000718000000, 0x0000000718000000, 0x0000000718200000| 0%| F| |TAMS 0x0000000718000000| PB 0x0000000718000000| Untracked | 0 | 93|0x0000000718200000, 0x0000000718200000, 0x0000000718400000| 0%| F| |TAMS 0x0000000718200000| PB 0x0000000718200000| Untracked | 0 | 94|0x0000000718400000, 0x0000000718400000, 0x0000000718600000| 0%| F| |TAMS 0x0000000718400000| PB 0x0000000718400000| Untracked | 0 | 95|0x0000000718600000, 0x0000000718600000, 0x0000000718800000| 0%| F| |TAMS 0x0000000718600000| PB 0x0000000718600000| Untracked | 0 | 96|0x0000000718800000, 0x0000000718800000, 0x0000000718a00000| 0%| F| |TAMS 0x0000000718800000| PB 0x0000000718800000| Untracked | 0 | 97|0x0000000718a00000, 0x0000000718a00000, 0x0000000718c00000| 0%| F| |TAMS 0x0000000718a00000| PB 0x0000000718a00000| Untracked | 0 | 98|0x0000000718c00000, 0x0000000718c00000, 0x0000000718e00000| 0%| F| |TAMS 0x0000000718c00000| PB 0x0000000718c00000| Untracked | 0 | 99|0x0000000718e00000, 0x0000000718e00000, 0x0000000719000000| 0%| F| |TAMS 0x0000000718e00000| PB 0x0000000718e00000| Untracked | 0 | 100|0x0000000719000000, 0x0000000719000000, 0x0000000719200000| 0%| F| |TAMS 0x0000000719000000| PB 0x0000000719000000| Untracked | 0 | 101|0x0000000719200000, 0x0000000719200000, 0x0000000719400000| 0%| F| |TAMS 0x0000000719200000| PB 0x0000000719200000| Untracked | 0 | 102|0x0000000719400000, 0x0000000719400000, 0x0000000719600000| 0%| F| |TAMS 0x0000000719400000| PB 0x0000000719400000| Untracked | 0 | 103|0x0000000719600000, 0x0000000719600000, 0x0000000719800000| 0%| F| |TAMS 0x0000000719600000| PB 0x0000000719600000| Untracked | 0 | 104|0x0000000719800000, 0x0000000719800000, 0x0000000719a00000| 0%| F| |TAMS 0x0000000719800000| PB 0x0000000719800000| Untracked | 0 | 105|0x0000000719a00000, 0x0000000719a00000, 0x0000000719c00000| 0%| F| |TAMS 0x0000000719a00000| PB 0x0000000719a00000| Untracked | 0 | 106|0x0000000719c00000, 0x0000000719c00000, 0x0000000719e00000| 0%| F| |TAMS 0x0000000719c00000| PB 0x0000000719c00000| Untracked | 0 | 107|0x0000000719e00000, 0x0000000719e00000, 0x000000071a000000| 0%| F| |TAMS 0x0000000719e00000| PB 0x0000000719e00000| Untracked | 0 | 108|0x000000071a000000, 0x000000071a000000, 0x000000071a200000| 0%| F| |TAMS 0x000000071a000000| PB 0x000000071a000000| Untracked | 0 | 109|0x000000071a200000, 0x000000071a200000, 0x000000071a400000| 0%| F| |TAMS 0x000000071a200000| PB 0x000000071a200000| Untracked | 0 | 110|0x000000071a400000, 0x000000071a400000, 0x000000071a600000| 0%| F| |TAMS 0x000000071a400000| PB 0x000000071a400000| Untracked | 0 | 111|0x000000071a600000, 0x000000071a600000, 0x000000071a800000| 0%| F| |TAMS 0x000000071a600000| PB 0x000000071a600000| Untracked | 0 | 112|0x000000071a800000, 0x000000071a800000, 0x000000071aa00000| 0%| F| |TAMS 0x000000071a800000| PB 0x000000071a800000| Untracked | 0 | 113|0x000000071aa00000, 0x000000071aa00000, 0x000000071ac00000| 0%| F| |TAMS 0x000000071aa00000| PB 0x000000071aa00000| Untracked | 0 | 114|0x000000071ac00000, 0x000000071ac00000, 0x000000071ae00000| 0%| F| |TAMS 0x000000071ac00000| PB 0x000000071ac00000| Untracked | 0 | 115|0x000000071ae00000, 0x000000071ae00000, 0x000000071b000000| 0%| F| |TAMS 0x000000071ae00000| PB 0x000000071ae00000| Untracked | 0 | 116|0x000000071b000000, 0x000000071b000000, 0x000000071b200000| 0%| F| |TAMS 0x000000071b000000| PB 0x000000071b000000| Untracked | 0 | 117|0x000000071b200000, 0x000000071b200000, 0x000000071b400000| 0%| F| |TAMS 0x000000071b200000| PB 0x000000071b200000| Untracked | 0 | 118|0x000000071b400000, 0x000000071b400000, 0x000000071b600000| 0%| F| |TAMS 0x000000071b400000| PB 0x000000071b400000| Untracked | 0 | 119|0x000000071b600000, 0x000000071b600000, 0x000000071b800000| 0%| F| |TAMS 0x000000071b600000| PB 0x000000071b600000| Untracked | 0 | 120|0x000000071b800000, 0x000000071b800000, 0x000000071ba00000| 0%| F| |TAMS 0x000000071b800000| PB 0x000000071b800000| Untracked | 0 | 121|0x000000071ba00000, 0x000000071bc00000, 0x000000071bc00000|100%| E| |TAMS 0x000000071ba00000| PB 0x000000071ba00000| Complete | 0 |1947|0x00000007ffe00000, 0x00000007fff1c148, 0x0000000800000000| 55%| O| |TAMS 0x00000007ffe00000| PB 0x00000007ffe00000| Untracked | 0 Card table byte_map: [0x00000268f51f0000,0x00000268f5990000] _byte_map_base: 0x00000268f198c000 Marking Bits: (CMBitMap*) 0x00000268e7d7dda0 Bits: [0x00000268f5990000, 0x00000268f9670000) Polling page: 0x00000268e5a80000 Metaspace: Usage: Non-class: 14.61 KB used. Class: 6.95 KB used. Both: 21.56 KB used. Virtual space: Non-class space: 64.00 MB reserved, 128.00 KB ( <1%) committed, 1 nodes. Class space: 1.00 GB reserved, 128.00 KB ( <1%) committed, 1 nodes. Both: 1.06 GB reserved, 256.00 KB ( <1%) committed. Chunk freelists: Non-Class: 12.00 MB Class: 15.75 MB Both: 27.74 MB MaxMetaspaceSize: unlimited CompressedClassSpaceSize: 1.00 GB Initial GC threshold: 21.00 MB Current GC threshold: 21.00 MB CDS: on - commit_granule_bytes: 65536. - commit_granule_words: 8192. - virtual_space_node_default_size: 8388608. - enlarge_chunks_in_place: 1. UseCompressedClassPointers 1, UseCompactObjectHeaders 0 Narrow klass pointer bits 32, Max shift 3 Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 bytes) Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 bytes) Klass ID Range: [65536 - 1090519033) (1090453497) Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) Internal statistics: num_allocs_failed_limit: 0. num_arena_births: 4. num_arena_deaths: 0. num_vsnodes_births: 2. num_vsnodes_deaths: 0. num_space_committed: 4. num_space_uncommitted: 0. num_chunks_returned_to_freelist: 0. num_chunks_taken_from_freelist: 4. num_chunk_merges: 0. num_chunk_splits: 4. num_chunks_enlarged: 0. num_inconsistent_stats: 0. CodeCache: size=32768Kb used=84Kb max_used=84Kb free=32683Kb bounds [0x00000268f1e90000, 0x00000268f1eb8000, 0x00000268f3e90000] total_blobs=225, nmethods=0, adapters=216, full_count=0 Compilation: disabled (interpreter mode), stopped_count=0, restarted_count=0 Compilation events (0 events): No events GC Heap History (0 events): No events Dll operation events (2 events): Event: 0.006 Loaded shared library C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll Event: 0.286 Loaded shared library C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll Deoptimization events (0 events): No events Classes loaded (16 events): Event: 0.023 Loading class sun/nio/cs/IBM437 Event: 0.023 Loading class sun/nio/cs/IBM437 done Event: 0.023 Loading class sun/nio/cs/IBM437$Holder Event: 0.023 Loading class sun/nio/cs/IBM437$Holder done Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook done Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader done Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 done Event: 0.027 Loading class java/lang/InterruptedException Event: 0.027 Loading class java/lang/InterruptedException done Event: 0.027 Loading class java/lang/CloneNotSupportedException Event: 0.027 Loading class java/lang/CloneNotSupportedException done Event: 0.028 Loading class java/util/Formatter$FixedString Event: 0.029 Loading class java/util/Formatter$FixedString done Classes unloaded (0 events): No events Classes redefined (0 events): No events Internal exceptions (0 events): No events VM Operations (0 events): No events Memory protections (0 events): No events Nmethod flushes (0 events): No events Events (9 events): Event: 0.017 Thread 0x00000268e57a3d20 Thread added: 0x00000268e57a3d20 Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08cfc0 Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08d5f0 Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc091710 Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc092140 Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0936e0 Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc09d2a0 Event: 0.026 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0d8ec0 Event: 0.027 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0de6e0 Dynamic libraries: 0x00007ff7bcd60000 - 0x00007ff7bcd70000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.exe 0x00007ffd45be0000 - 0x00007ffd45e40000 C:\WINDOWS\SYSTEM32\ntdll.dll 0x00007ffd44600000 - 0x00007ffd446c7000 C:\WINDOWS\System32\KERNEL32.DLL 0x00007ffd43490000 - 0x00007ffd4385a000 C:\WINDOWS\System32\KERNELBASE.dll 0x00007ffd42dc0000 - 0x00007ffd42f0b000 C:\WINDOWS\System32\ucrtbase.dll 0x00007ffd30100000 - 0x00007ffd3011d000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\VCRUNTIME140.dll 0x00007ffd2a470000 - 0x00007ffd2a487000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jli.dll 0x00007ffd450e0000 - 0x00007ffd452ac000 C:\WINDOWS\System32\USER32.dll 0x00007ffd41f90000 - 0x00007ffd42227000 C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24\COMCTL32.dll 0x00007ffd43040000 - 0x00007ffd43067000 C:\WINDOWS\System32\win32u.dll 0x00007ffd44a40000 - 0x00007ffd44ae9000 C:\WINDOWS\System32\msvcrt.dll 0x00007ffd44af0000 - 0x00007ffd44b1a000 C:\WINDOWS\System32\GDI32.dll 0x00007ffd43130000 - 0x00007ffd43261000 C:\WINDOWS\System32\gdi32full.dll 0x00007ffd433e0000 - 0x00007ffd43483000 C:\WINDOWS\System32\msvcp_win.dll 0x00007ffd44560000 - 0x00007ffd4458f000 C:\WINDOWS\System32\IMM32.DLL 0x00007ffd27710000 - 0x00007ffd2771c000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\vcruntime140_1.dll 0x00007ffd14e00000 - 0x00007ffd14e8d000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\msvcp140.dll 0x00007ffceaf00000 - 0x00007ffceb4cf000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero\jvm.dll 0x00007ffd452b0000 - 0x00007ffd45362000 C:\WINDOWS\System32\ADVAPI32.dll 0x00007ffd44780000 - 0x00007ffd44826000 C:\WINDOWS\System32\sechost.dll 0x00007ffd442d0000 - 0x00007ffd443e6000 C:\WINDOWS\System32\RPCRT4.dll 0x00007ffd446d0000 - 0x00007ffd44744000 C:\WINDOWS\System32\WS2_32.dll 0x00007ffd42c30000 - 0x00007ffd42c8e000 C:\WINDOWS\SYSTEM32\POWRPROF.dll 0x00007ffd332f0000 - 0x00007ffd33326000 C:\WINDOWS\SYSTEM32\WINMM.dll 0x00007ffd391c0000 - 0x00007ffd391cb000 C:\WINDOWS\SYSTEM32\VERSION.dll 0x00007ffd16d70000 - 0x00007ffd16d81000 C:\msys64\ucrt64\bin\libffi-8.dll 0x00007ffd42c10000 - 0x00007ffd42c24000 C:\WINDOWS\SYSTEM32\UMPDC.dll 0x00007ffd41a60000 - 0x00007ffd41a6c000 C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL 0x00007ffd42fa0000 - 0x00007ffd43039000 C:\WINDOWS\System32\bcryptPrimitives.dll 0x00007ffd41270000 - 0x00007ffd4128a000 C:\WINDOWS\SYSTEM32\kernel.appcore.dll 0x00007ffd27060000 - 0x00007ffd2706a000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jimage.dll 0x00007ffd42540000 - 0x00007ffd42781000 C:\WINDOWS\SYSTEM32\DBGHELP.DLL 0x00007ffd44d50000 - 0x00007ffd450d2000 C:\WINDOWS\System32\combase.dll 0x00007ffd439e0000 - 0x00007ffd43ab6000 C:\WINDOWS\System32\OLEAUT32.dll 0x00007ffd01660000 - 0x00007ffd01699000 C:\WINDOWS\SYSTEM32\dbgcore.DLL 0x00007ffd16d50000 - 0x00007ffd16d6d000 C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll 0x00007ffd44b20000 - 0x00007ffd44cb6000 C:\WINDOWS\System32\ole32.dll 0x00007ffd45370000 - 0x00007ffd45a99000 C:\WINDOWS\System32\SHELL32.dll 0x00007ffd43270000 - 0x00007ffd433d8000 C:\WINDOWS\System32\wintypes.dll 0x00007ffd3ff80000 - 0x00007ffd407d2000 C:\WINDOWS\SYSTEM32\windows.storage.dll 0x00007ffd44400000 - 0x00007ffd444ed000 C:\WINDOWS\System32\SHCORE.dll 0x00007ffd444f0000 - 0x00007ffd44554000 C:\WINDOWS\System32\shlwapi.dll 0x00007ffd42cd0000 - 0x00007ffd42cff000 C:\WINDOWS\SYSTEM32\profapi.dll 0x00007ffd15180000 - 0x00007ffd15192000 C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll JVMTI agents: none dbghelp: loaded successfully - version: 4.0.5 - missing functions: none symbol engine: initialized successfully - sym options: 0x614 - pdb path: .;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero;C:\msys64\ucrt64\bin;C:\Users\REDACTED\Downloads\LoadLibrary\Crash VM Arguments: jvm_args: --enable-preview java_command: Crash java_class_path (initial): C:/Users/REDACTED/Downloads/LoadLibrary/Crash Launcher Type: SUN_STANDARD [Global flags] uint ConcGCThreads = 5 {product} {ergonomic} uint G1ConcRefinementThreads = 18 {product} {ergonomic} size_t G1HeapRegionSize = 2097152 {product} {ergonomic} size_t InitialHeapSize = 255852544 {product} {ergonomic} size_t MarkStackSize = 4194304 {product} {ergonomic} size_t MarkStackSizeMax = 536870912 {product} {ergonomic} size_t MaxHeapSize = 4085252096 {product} {ergonomic} size_t MaxNewSize = 2449473536 {product} {ergonomic} size_t MinHeapDeltaBytes = 2097152 {product} {ergonomic} size_t MinHeapSize = 8388608 {product} {ergonomic} uintx NonNMethodCodeHeapSize = 4096 {pd product} {ergonomic} uintx NonProfiledCodeHeapSize = 0 {pd product} {ergonomic} uintx ProfiledCodeHeapSize = 0 {pd product} {ergonomic} size_t SoftMaxHeapSize = 4085252096 {manageable} {ergonomic} bool UseCompressedOops = true {product lp64_product} {ergonomic} bool UseG1GC = true {product} {ergonomic} bool UseLargePagesIndividualAllocation = false {pd product} {ergonomic} Logging: Log output configuration: #0: stdout all=warning uptime,level,tags foldmultilines=false #1: stderr all=off uptime,level,tags foldmultilines=false Release file: IMPLEMENTOR="N/A" JAVA_RUNTIME_VERSION="25-internal" JAVA_VERSION="25" JAVA_VERSION_DATE="2025-09-16" LIBC="default" MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets jdk.internal.opt jdk.zipfs jdk.compiler jdk.crypto.cryptoki jdk.crypto.ec jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.httpserver jdk.incubator.vector jdk.internal.le jdk.internal.md jdk.jartool jdk.javadoc jdk.jcmd jdk.management jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.nio.mapmode jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported jdk.unsupported.desktop jdk.xml.dom" OS_ARCH="x86_64" OS_NAME="Windows" SOURCE=".:git:8f7652d7a36b+" Environment Variables: PATH=C:\msys64\ucrt64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl USERNAME=REDACTED SHELL=C:\msys64\usr\bin\bash.exe LC_CTYPE=en_US.UTF-8 TERM=xterm OS=Windows_NT PROCESSOR_IDENTIFIER=AMD64 Family 25 Model 97 Stepping 2, AuthenticAMD TMP=C:\msys64\tmp TEMP=C:\msys64\tmp Compilation memory statistics disabled. Periodic native trim disabled --------------- S Y S T E M --------------- OS: Windows 11 , 64 bit Build 26100 (10.0.26100.3775) OS uptime: 0 days 1:47 hours CPU: total 24 (initial active 24) Processor Information for processor 0 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 1 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 2 Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 Processor Information for processor 3 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 4 Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 Processor Information for processor 5 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 6 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 7 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 8 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 9 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 10 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 11 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 12 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 13 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 14 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 15 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 16 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 17 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 18 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 19 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 20 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 21 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 22 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Processor Information for processor 23 Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 Memory: 4k page, system-wide physical 15578M (1690M free) TotalPageFile size 44250M (AvailPageFile size 20548M) current process WorkingSet (physical memory assigned to process): 64M, peak: 64M current process commit charge ("private bytes"): 373M, peak: 373M vm_info: Java HotSpot 64-Bit Zero VM (25-internal) for windows-amd64 JRE (25-internal), built on 2025-04-17T14:32:22Z with MS VC++ 17.8 (VS2022) END. /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-161-Note: including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:162:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): warning C5030: attribute [[gnu::packed]] is not recognized /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-320-Note: including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:321:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log-13-Note: including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:15:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:16:jdk\src\hotspot\cpu\zero\interpreterRT_zero.cpp(161): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-168-Note: including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:169:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): warning C5030: attribute [[gnu::packed]] is not recognized /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-307-Note: including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:308:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log-7-Note: including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:8:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:9:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:10:jdk\src\hotspot\cpu\zero\stack_zero.cpp(36): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log-12-Note: including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:13:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log-28-Note: including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:29:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:30:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): warning C4267: 'initializing': conversion from 'size_t' to 'int', possible loss of data Generating code Previous IPDB not found, fall back to full compilation. s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning C4723: potential divide by 0 s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning C4723: potential divide by 0 s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning C4723: potential divide by 0 All 52893 functions were compiled because no usable IPDB/IOBJ from previous compilation was found. Finished generating code From tobias.hartmann at oracle.com Tue Apr 22 12:58:03 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Apr 2025 14:58:03 +0200 Subject: CFV: New JDK Committer: Marc Chevalier Message-ID: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> I hereby nominate Marc Chevalier [1] to JDK Committer. Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. Votes are due by May 6, 2025, 13:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#mchevalier [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote From christian.hagedorn at oracle.com Tue Apr 22 13:16:51 2025 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 22 Apr 2025 15:16:51 +0200 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: <5fe0a648-f86d-45ef-b3fe-262da00f4d57@oracle.com> Vote: yes Best regards, Christian On 22.04.25 14:58, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From tobias.hartmann at oracle.com Tue Apr 22 13:20:38 2025 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Apr 2025 15:20:38 +0200 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes Best regards, Tobias On 4/22/25 14:58, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From thomas.stuefe at gmail.com Tue Apr 22 13:35:41 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 22 Apr 2025 15:35:41 +0200 Subject: Windows/Zero In-Reply-To: References: Message-ID: Hi Julian, I am curious, what would be the use case for Windows+Zero? Zero is typically used for bootstrapping new platforms/CPUs. The Windows CPU set is very stable, and Windows is not the platform anyone starts porting to if they start working on a new platform. Additionally, Microsoft usually takes care of porting in the once-a-decade-rare case that a new CPU is supported on Windows. Cheers, Thomas On Tue, Apr 22, 2025 at 2:47?PM Julian Waters wrote: > Hi all, > > Zero currently cannot compile on Windows, and to my knowledge, has > never been able to compile on Windows. This is largely due to Windows > lacking crucial implementations for Zero under the os_cpu directory, > where you will notice a distinct lack of a windows_zero directory. To > remedy this, some time ago, I implemented Zero on Windows. The > implementation, aside from adding critical code to windows_zero, also > had to ifdef some code out of the Windows Structured Exception filter. > It was surprisingly minimal, but the downside is that Windows/Zero > then only compiled with gcc. VC had an additional hurdle to jump > through: On Zero, since there are no registers, register arrays in > certain classes became zero sized arrays, a GNU extension that VC will > never accept under any circumstances. > > I started work again recently to get Zero working with VC. Just 2 days > ago, this successfully compiled with VC, albeit with > --disable-warnings-as-errors. The code is available at > https://github.com/TheShermanTanker/jdk/commits/experimental for > anyone curious, under "Windows/Zero Port". Disclaimer: I do not know > whether the code is 100% correct, I may have implemented it wrongly. > The remaining warnings left over can be seen below this mail. Note > that only the release configuration was tested, fastdebug has not been > compiled yet. > > I'd like to float the idea of supporting Windows/Zero properly. > Ideally, Zero should run on any platform, so it not running on Windows > would be surprising, but past that, the Java Zero VM is extremely > small on Windows at just 5MB (Even smaller than the Python > Interpreter!), so it could be useful on devices where a small Java VM > is desired. More importantly, this could (Although I am not fully > certain) open the door to running the latest Java on 32 bit Windows > devices again, ever since all the x86 32 bit ports were removed, > leaving Zero as the only way to execute Java on 32 bit x86. This may > (or may not) help those who cannot get a 64 bit device or one that's > running Linux, I haven't checked yet. > > I also crashed the VM on purpose to get a hserr file which contains VM > information, this can be seen below. This was quite interesting, as > I've never actually seen Zero crash before! > > Thoughts? > > best regards, > Julian > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd1518139f, > pid=335696, tid=337452 > # > # JRE version: Java Runtime Environment (25.0) (build 25-internal) > # Java VM: Java HotSpot 64-Bit Zero VM (25-internal, interpreted mode, > sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > # Problematic frame: > # C [Crash.dll+0x139f] > # > # No core dump will be written. Minidumps are not enabled by default > on client versions of Windows > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # The crash happened outside the Java Virtual Machine in native code. > # See problematic frame for where to report the bug. > # > > --------------- S U M M A R Y ------------ > > Command Line: --enable-preview Crash > > Host: AMD Ryzen 9 7845HX with Radeon Graphics , 24 cores, 15G, > Windows 11 , 64 bit Build 26100 (10.0.26100.3775) > Time: Sun Apr 20 03:44:08 2025 Malay Peninsula Standard Time elapsed > time: 0.291582 seconds (0d 0h 0m 0s) > > --------------- T H R E A D --------------- > > Current thread (0x00000268e57a3d20): JavaThread "main" > [_thread_in_native, id=337452, > stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] > > Stack: [0x000000ae07a00000,0x000000ae07b00000], > sp=0x000000ae07a842a0, free space=528k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native > code) > C [Crash.dll+0x139f] (no source info available) > C [libffi-8.dll+0x4cc1] (no source info available) > C [libffi-8.dll+0x48df] (no source info available) > C [libffi-8.dll+0x4aa2] (no source info available) > V [jvm.dll+0x426645] ZeroInterpreter::native_entry+0x455 > (zeroInterpreter_zero.cpp:444) > V [jvm.dll+0x425f47] ZeroInterpreter::main_loop+0x127 > (zeroInterpreter_zero.cpp:227) > V [jvm.dll+0x425d96] ZeroInterpreter::normal_entry+0x36 > (zeroInterpreter_zero.cpp:115) > V [jvm.dll+0x3b156d] StubGenerator::call_stub+0x1bd > (stubGenerator_zero.cpp:84) > V [jvm.dll+0x1acbfd] JavaCalls::call_helper+0x48d (javaCalls.cpp:424) > V [jvm.dll+0x2e4c80] os::os_exception_wrapper+0x20 > (os_windows_zero.cpp:51) > V [jvm.dll+0x1c472a] jni_invoke_nonstatic+0x32a (jni.cpp:950) > V [jvm.dll+0x1c8ea2] jni_CallVoidMethod+0x142 (jni.cpp:1307) > C [jli.dll+0x510f] JavaMain+0x7d3 (java.c:645) > C [ucrtbase.dll+0x37b0] (no source info available) > C [KERNEL32.DLL+0x2e8d7] (no source info available) > C [ntdll.dll+0xb14fc] (no source info available) > > Java frames: > 0x000000ae07aff8f0: unboxed parameter[1] = 0x000000ae07aff9a0 > 0x000000ae07aff8f8: parameter[0] (JNIEnv) = 0x000000ae07a84410 > 0x000000ae07aff900: parameter[1] (this) = 0x000000ae07aff8f0 > 0x000000ae07aff908: istate->_thread = 0x00000268e57a3d20 > 0x000000ae07aff910: istate->_bcp = 0x0000000000000000 > 0x000000ae07aff918: istate->_locals = 0x000000ae07aff9a0 > 0x000000ae07aff920: istate->_constants = 0x00000268c14003a8 > 0x000000ae07aff928: istate->_method = Crash.crash()V > 0x000000ae07aff930: istate->_mirror = 0x000000071ba1cb90 > 0x000000ae07aff938: istate->_stack = 0x000000ae07aff900 > 0x000000ae07aff940: istate->_msg = 0x0000026800000002 > 0x000000ae07aff948: istate->_result = 0x0000000000000000 > 0x000000ae07aff950: (istate->_result) = 0x000000ae00000003 > 0x000000ae07aff958: (istate->_result) = 0x0000000000000000 > 0x000000ae07aff960: istate->_prev_link = 0x0000000000000000 > 0x000000ae07aff968: istate->_oop_temp = 0x0000000000000000 > 0x000000ae07aff970: istate->_stack_base = 0x000000ae07aff908 > 0x000000ae07aff978: istate->_stack_limit = 0x000000ae07aff900 > 0x000000ae07aff980: istate->_monitor_base = 0x000000ae07aff908 > 0x000000ae07aff988: istate->_self_link = 0x000000ae07aff908 > 0x000000ae07aff990: frame_type = INTERPRETER_FRAME > 0x000000ae07aff998: next_frame = 0x000000ae07affa38 > > 0x000000ae07aff9a0: local[0] = 0x000000071ba1d940 > 0x000000ae07aff9a8: istate->_thread = 0x00000268e57a3d20 > 0x000000ae07aff9b0: istate->_bcp = 0x00000268c14002de (bci 6) > 0x000000ae07aff9b8: istate->_locals = 0x000000ae07affa40 > 0x000000ae07aff9c0: istate->_constants = 0x00000268c14003a8 > 0x000000ae07aff9c8: istate->_method = Crash.main()V > 0x000000ae07aff9d0: istate->_mirror = 0x000000071ba1cb90 > 0x000000ae07aff9d8: istate->_stack = 0x000000ae07aff998 > 0x000000ae07aff9e0: istate->_msg = 0x0000026800000008 > 0x000000ae07aff9e8: istate->_result = 0x00000268c1400238 > 0x000000ae07aff9f0: (istate->_result) = 0x00000268f1e90458 > 0x000000ae07aff9f8: (istate->_result) = 0x0000000000000003 > 0x000000ae07affa00: istate->_prev_link = 0x0000000000000000 > 0x000000ae07affa08: istate->_oop_temp = 0x0000000000000000 > 0x000000ae07affa10: istate->_stack_base = 0x000000ae07aff9a8 > 0x000000ae07affa18: istate->_stack_limit = 0x000000ae07aff990 > 0x000000ae07affa20: istate->_monitor_base = 0x000000ae07aff9a8 > 0x000000ae07affa28: istate->_self_link = 0x000000ae07aff9a8 > 0x000000ae07affa30: frame_type = INTERPRETER_FRAME > 0x000000ae07affa38: next_frame = 0x000000ae07affa58 > > 0x000000ae07affa40: local[0] = 0x000000071ba1d940 > 0x000000ae07affa48: call_wrapper = 0x000000ae07affaf0 > 0x000000ae07affa50: frame_type = ENTRY_FRAME > 0x000000ae07affa58: next_frame = 0x0000000000000000 > > > siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address > 0x0000000000000000 > > > No context information. > > Register to memory mapping: > > No register info. > > Top of Stack: (sp=0x000000ae07a842a0) > 0x000000ae07a842a0: 00000000000003d8 0000000000000000 ................ > 0x000000ae07a842b0: 0000000000000000 00007ffd16d748df .........H...... > 0x000000ae07a842c0: 000002688046f350 0000000000000000 P.F.h........... > 0x000000ae07a842d0: 000000ae07a84300 00007ffd16d74cc1 .C.......L...... > 0x000000ae07a842e0: 00000268e57a4028 000000ae07aff9a0 (@z.h........... > 0x000000ae07a842f0: 0000000000000001 0000000000000050 ........P....... > 0x000000ae07a84300: 000000ae07a84350 00007ffd16d748df PC.......H...... > 0x000000ae07a84310: 00007ffd15181380 0000000000000000 ................ > 0x000000ae07a84320: 000000ae07a84400 0000000000000000 .D.............. > 0x000000ae07a84330: 0000000000000001 0000000000000000 ................ > 0x000000ae07a84340: 00001664b4a8ce49 111f221225371f8f I...d.....7%.".. > 0x000000ae07a84350: 00000268802416f0 00000268e57a3d20 ..$.h... =z.h... > 0x000000ae07a84360: 00000268c1400238 000000ae07aff908 8. at .h........... > 0x000000ae07a84370: 000000ae07aff9a0 000000ae07aff998 ................ > 0x000000ae07a84380: 00000268f1e98710 0000000000000000 ....h........... > 0x000000ae07a84390: 000000ae07a84440 00007ffd16d74aa2 @D.......J...... > 0x000000ae07a843a0: 0000000000000000 0000000000000001 ................ > 0x000000ae07a843b0: 0000000000000000 000000ae07aff998 ................ > 0x000000ae07a843c0: 0000000000000000 0000000000000000 ................ > 0x000000ae07a843d0: 000000ae07a84440 00007ffceb326645 @D......Ef2..... > 0x000000ae07a843e0: 00007ffceb482058 00000268e57a3d20 X H..... =z.h... > 0x000000ae07a843f0: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... > 0x000000ae07a84400: 000000ae07aff990 000000ae07aff8f8 ................ > 0x000000ae07a84410: 00000268e57a4028 0000000000000000 (@z.h........... > 0x000000ae07a84420: 00007ffd15181380 0000000000000000 ................ > 0x000000ae07a84430: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... > 0x000000ae07a84440: 0000000000000001 0000000000000000 ................ > 0x000000ae07a84450: 0000000000000000 0000000000000000 ................ > 0x000000ae07a84460: 0000000000000000 000000ae07affa38 ........8....... > 0x000000ae07a84470: 00000268c14002e8 00007ffceb325f47 .. at .h...G_2..... > 0x000000ae07a84480: 00000268e57a3d20 00000268e57a3d20 =z.h... =z.h... > 0x000000ae07a84490: 000000ae00084b70 0000000000000000 pK.............. > > Instructions: (pc=0x00007ffd1518139f) > 0x00007ffd1518129f: 00 e8 bb 0e 00 00 41 89 c4 83 fb 03 75 86 e9 5a > 0x00007ffd151812af: ff ff ff 66 0f 1f 44 00 00 83 fb 01 0f 85 6f ff > 0x00007ffd151812bf: ff ff 49 89 f8 31 d2 48 89 f1 e8 42 fd ff ff e9 > 0x00007ffd151812cf: 5d ff ff ff 0f 1f 44 00 00 e8 93 01 00 00 49 89 > 0x00007ffd151812df: f8 ba 01 00 00 00 48 89 f1 e8 73 0e 00 00 41 89 > 0x00007ffd151812ef: c4 85 c0 0f 85 3b ff ff ff 49 89 f8 31 d2 48 89 > 0x00007ffd151812ff: f1 e8 5b 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 3e > 0x00007ffd1518130f: 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 f1 fc ff ff > 0x00007ffd1518131f: e9 0f ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 > 0x00007ffd1518132f: 90 48 8b 05 b9 82 00 00 c7 00 00 00 00 00 e9 8e > 0x00007ffd1518133f: fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f > 0x00007ffd1518134f: 00 48 89 ca 48 8d 0d a6 ac 00 00 e9 f9 62 00 00 > 0x00007ffd1518135f: 90 48 8d 0d 09 00 00 00 e9 e4 ff ff ff 0f 1f 40 > 0x00007ffd1518136f: 00 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 > 0x00007ffd1518137f: 90 55 48 89 e5 48 83 ec 30 48 c7 45 f8 00 00 00 > 0x00007ffd1518138f: 00 48 8b 45 f8 48 8b 45 f8 48 8d 0d 61 7c 00 00 > =>0x00007ffd1518139f: 8b 10 e8 ca 0d 00 00 48 8d 0d 56 7c 00 00 48 83 > 0x00007ffd151813af: c4 30 5d e9 59 63 00 00 90 90 90 90 90 90 90 90 > 0x00007ffd151813bf: 90 48 83 ec 28 48 8b 05 45 6c 00 00 48 8b 00 48 > 0x00007ffd151813cf: 85 c0 74 22 0f 1f 44 00 00 ff d0 48 8b 05 2f 6c > 0x00007ffd151813df: 00 00 48 8d 50 08 48 8b 40 08 48 89 15 20 6c 00 > 0x00007ffd151813ef: 00 48 85 c0 75 e3 48 83 c4 28 c3 66 0f 1f 44 00 > 0x00007ffd151813ff: 00 56 53 48 83 ec 28 48 8b 15 83 81 00 00 48 8b > 0x00007ffd1518140f: 02 89 c1 83 f8 ff 74 39 85 c9 74 20 89 c8 83 e9 > 0x00007ffd1518141f: 01 48 8d 1c c2 48 29 c8 48 8d 74 c2 f8 0f 1f 40 > 0x00007ffd1518142f: 00 ff 13 48 83 eb 08 48 39 f3 75 f5 48 8d 0d 7e > 0x00007ffd1518143f: ff ff ff 48 83 c4 28 5b 5e e9 03 ff ff ff 0f 1f > 0x00007ffd1518144f: 00 31 c0 66 0f 1f 44 00 00 44 8d 40 01 89 c1 4a > 0x00007ffd1518145f: 83 3c c2 00 4c 89 c0 75 f0 eb ad 66 0f 1f 44 00 > 0x00007ffd1518146f: 00 8b 05 aa ab 00 00 85 c0 74 06 c3 0f 1f 44 00 > 0x00007ffd1518147f: 00 c7 05 96 ab 00 00 01 00 00 00 e9 71 ff ff ff > 0x00007ffd1518148f: 90 83 fa 03 74 0b 85 d2 74 07 c3 66 0f 1f 44 00 > > > Stack slot to memory mapping: > > stack at sp + 0 slots: 0x00000000000003d8 is an unknown value > stack at sp + 1 slots: 0x0 is null > stack at sp + 2 slots: 0x0 is null > stack at sp + 3 slots: 0x00007ffd16d748df libffi-8.dll > stack at sp + 4 slots: {method} {0x000002688046f358} 'loadLibrary' > '(Ljava/lang/Class;Ljava/lang/String;)Ljdk/internal/loader/NativeLibrary;' > in 'java/lang/ClassLoader' > stack at sp + 5 slots: 0x0 is null > stack at sp + 6 slots: 0x000000ae07a84300 is pointing into the stack > for thread: 0x00000268e57a3d20 > stack at sp + 7 slots: 0x00007ffd16d74cc1 libffi-8.dll > > Lock stack of current Java thread (top to bottom): > > > --------------- P R O C E S S --------------- > > Threads class SMR info: > _java_thread_list=0x00000268fc0d5850, length=9, elements={ > 0x00000268e57a3d20, 0x00000268fc08cfc0, 0x00000268fc08d5f0, > 0x00000268fc091710, > 0x00000268fc092140, 0x00000268fc0936e0, 0x00000268fc09d2a0, > 0x00000268fc0d8ec0, > 0x00000268fc0de6e0 > } > > Java Threads: ( => current thread ) > =>0x00000268e57a3d20 JavaThread "main" > [_thread_in_native, id=337452, > stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] > 0x00000268fc08cfc0 JavaThread "Reference Handler" daemon > [_thread_blocked, id=337356, > stack(0x000000ae08200000,0x000000ae08300000) (1024K)] > 0x00000268fc08d5f0 JavaThread "Finalizer" daemon > [_thread_blocked, id=338708, > stack(0x000000ae08300000,0x000000ae08400000) (1024K)] > 0x00000268fc091710 JavaThread "Signal Dispatcher" daemon > [_thread_blocked, id=338204, > stack(0x000000ae08400000,0x000000ae08500000) (1024K)] > 0x00000268fc092140 JavaThread "Attach Listener" daemon > [_thread_blocked, id=338748, > stack(0x000000ae08500000,0x000000ae08600000) (1024K)] > 0x00000268fc0936e0 JavaThread "Service Thread" daemon > [_thread_blocked, id=337172, > stack(0x000000ae08600000,0x000000ae08700000) (1024K)] > 0x00000268fc09d2a0 JavaThread "Monitor Deflation Thread" daemon > [_thread_blocked, id=337312, > stack(0x000000ae08700000,0x000000ae08800000) (1024K)] > 0x00000268fc0d8ec0 JavaThread "Notification Thread" daemon > [_thread_blocked, id=337560, > stack(0x000000ae08800000,0x000000ae08900000) (1024K)] > 0x00000268fc0de6e0 JavaThread "Common-Cleaner" daemon > [_thread_blocked, id=338324, > stack(0x000000ae08900000,0x000000ae08a00000) (1024K)] > Total: 9 > > Other Threads: > 0x00000268fc07c960 VMThread "VM Thread" > [id=337424, stack(0x000000ae08100000,0x000000ae08200000) (1024K)] > 0x00000268fbf41360 WatcherThread "VM Periodic Task Thread" > [id=333244, stack(0x000000ae08000000,0x000000ae08100000) (1024K)] > 0x00000268e7d7d550 WorkerThread "GC Thread#0" > [id=336784, stack(0x000000ae07b00000,0x000000ae07c00000) (1024K)] > 0x00000268e7d951c0 ConcurrentGCThread "G1 Main Marker" > [id=338660, stack(0x000000ae07c00000,0x000000ae07d00000) (1024K)] > 0x00000268e7d96850 WorkerThread "G1 Conc#0" > [id=19564, stack(0x000000ae07d00000,0x000000ae07e00000) (1024K)] > 0x00000268fbf39000 ConcurrentGCThread "G1 Refine#0" > [id=217884, stack(0x000000ae07e00000,0x000000ae07f00000) (1024K)] > 0x00000268fbf39780 ConcurrentGCThread "G1 Service" > [id=338408, stack(0x000000ae07f00000,0x000000ae08000000) (1024K)] > Total: 7 > > Threads with active compile tasks: > Total: 0 > > VM state: not at safepoint (normal execution) > > VM Mutex/Monitor currently owned by a thread: None > > Heap address: 0x000000070c800000, size: 3896 MB, Compressed Oops mode: > Zero based, Oop shift amount: 3 > > CDS archive(s) mapped at: > [0x0000026880000000-0x0000026880d30000-0x0000026880d30000), size > 13828096, SharedBaseAddress: 0x0000026880000000, > ArchiveRelocationMode: 1. > Compressed class space mapped at: > 0x0000026881000000-0x00000268c1000000, reserved size: 1073741824 > UseCompressedClassPointers 1, UseCompactObjectHeaders 0 > Narrow klass pointer bits 32, Max shift 3 > Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 > Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 > bytes) > Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 > bytes) > Klass ID Range: [65536 - 1090519033) (1090453497) > Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) > > GC Precious Log: > CardTable entry size: 512 > Card Set container configuration: InlinePtr #cards 4 size 8 Array Of > Cards #cards 16 size 48 Howl #buckets 8 coarsen threshold 3686 Howl > Bitmap #cards 512 size 80 coarsen threshold 460 Card regions per heap > region 1 cards per card region 4096 > CPUs: 24 total, 24 available > Memory: 15578M > Large Page Support: Disabled > NUMA Support: Disabled > Compressed Oops: Enabled (Zero based) > Heap Region Size: 2M > Heap Min Capacity: 8M > Heap Initial Capacity: 244M > Heap Max Capacity: 3896M > Pre-touch: Disabled > Parallel Workers: 18 > Concurrent Workers: 5 > Concurrent Refinement Workers: 18 > Periodic GC: Disabled > > Heap: > garbage-first heap total reserved 3989504K, committed 251904K, used > 1136K [0x000000070c800000, 0x0000000800000000) > region size 2048K, 1 young (2048K), 0 survivors (0K) > Metaspace used 21K, committed 256K, reserved 1114112K > class space used 6K, committed 128K, reserved 1048576K > > Heap Regions: E=young(eden), S=young(survivor), O=old, > HS=humongous(starts), HC=humongous(continues), CS=collection set, > F=free, TAMS=top-at-mark-start, PB=parsable bottom > | 0|0x000000070c800000, 0x000000070c800000, 0x000000070ca00000| 0%| > F| |TAMS 0x000000070c800000| PB 0x000000070c800000| Untracked | 0 > | 1|0x000000070ca00000, 0x000000070ca00000, 0x000000070cc00000| 0%| > F| |TAMS 0x000000070ca00000| PB 0x000000070ca00000| Untracked | 0 > | 2|0x000000070cc00000, 0x000000070cc00000, 0x000000070ce00000| 0%| > F| |TAMS 0x000000070cc00000| PB 0x000000070cc00000| Untracked | 0 > | 3|0x000000070ce00000, 0x000000070ce00000, 0x000000070d000000| 0%| > F| |TAMS 0x000000070ce00000| PB 0x000000070ce00000| Untracked | 0 > | 4|0x000000070d000000, 0x000000070d000000, 0x000000070d200000| 0%| > F| |TAMS 0x000000070d000000| PB 0x000000070d000000| Untracked | 0 > | 5|0x000000070d200000, 0x000000070d200000, 0x000000070d400000| 0%| > F| |TAMS 0x000000070d200000| PB 0x000000070d200000| Untracked | 0 > | 6|0x000000070d400000, 0x000000070d400000, 0x000000070d600000| 0%| > F| |TAMS 0x000000070d400000| PB 0x000000070d400000| Untracked | 0 > | 7|0x000000070d600000, 0x000000070d600000, 0x000000070d800000| 0%| > F| |TAMS 0x000000070d600000| PB 0x000000070d600000| Untracked | 0 > | 8|0x000000070d800000, 0x000000070d800000, 0x000000070da00000| 0%| > F| |TAMS 0x000000070d800000| PB 0x000000070d800000| Untracked | 0 > | 9|0x000000070da00000, 0x000000070da00000, 0x000000070dc00000| 0%| > F| |TAMS 0x000000070da00000| PB 0x000000070da00000| Untracked | 0 > | 10|0x000000070dc00000, 0x000000070dc00000, 0x000000070de00000| 0%| > F| |TAMS 0x000000070dc00000| PB 0x000000070dc00000| Untracked | 0 > | 11|0x000000070de00000, 0x000000070de00000, 0x000000070e000000| 0%| > F| |TAMS 0x000000070de00000| PB 0x000000070de00000| Untracked | 0 > | 12|0x000000070e000000, 0x000000070e000000, 0x000000070e200000| 0%| > F| |TAMS 0x000000070e000000| PB 0x000000070e000000| Untracked | 0 > | 13|0x000000070e200000, 0x000000070e200000, 0x000000070e400000| 0%| > F| |TAMS 0x000000070e200000| PB 0x000000070e200000| Untracked | 0 > | 14|0x000000070e400000, 0x000000070e400000, 0x000000070e600000| 0%| > F| |TAMS 0x000000070e400000| PB 0x000000070e400000| Untracked | 0 > | 15|0x000000070e600000, 0x000000070e600000, 0x000000070e800000| 0%| > F| |TAMS 0x000000070e600000| PB 0x000000070e600000| Untracked | 0 > | 16|0x000000070e800000, 0x000000070e800000, 0x000000070ea00000| 0%| > F| |TAMS 0x000000070e800000| PB 0x000000070e800000| Untracked | 0 > | 17|0x000000070ea00000, 0x000000070ea00000, 0x000000070ec00000| 0%| > F| |TAMS 0x000000070ea00000| PB 0x000000070ea00000| Untracked | 0 > | 18|0x000000070ec00000, 0x000000070ec00000, 0x000000070ee00000| 0%| > F| |TAMS 0x000000070ec00000| PB 0x000000070ec00000| Untracked | 0 > | 19|0x000000070ee00000, 0x000000070ee00000, 0x000000070f000000| 0%| > F| |TAMS 0x000000070ee00000| PB 0x000000070ee00000| Untracked | 0 > | 20|0x000000070f000000, 0x000000070f000000, 0x000000070f200000| 0%| > F| |TAMS 0x000000070f000000| PB 0x000000070f000000| Untracked | 0 > | 21|0x000000070f200000, 0x000000070f200000, 0x000000070f400000| 0%| > F| |TAMS 0x000000070f200000| PB 0x000000070f200000| Untracked | 0 > | 22|0x000000070f400000, 0x000000070f400000, 0x000000070f600000| 0%| > F| |TAMS 0x000000070f400000| PB 0x000000070f400000| Untracked | 0 > | 23|0x000000070f600000, 0x000000070f600000, 0x000000070f800000| 0%| > F| |TAMS 0x000000070f600000| PB 0x000000070f600000| Untracked | 0 > | 24|0x000000070f800000, 0x000000070f800000, 0x000000070fa00000| 0%| > F| |TAMS 0x000000070f800000| PB 0x000000070f800000| Untracked | 0 > | 25|0x000000070fa00000, 0x000000070fa00000, 0x000000070fc00000| 0%| > F| |TAMS 0x000000070fa00000| PB 0x000000070fa00000| Untracked | 0 > | 26|0x000000070fc00000, 0x000000070fc00000, 0x000000070fe00000| 0%| > F| |TAMS 0x000000070fc00000| PB 0x000000070fc00000| Untracked | 0 > | 27|0x000000070fe00000, 0x000000070fe00000, 0x0000000710000000| 0%| > F| |TAMS 0x000000070fe00000| PB 0x000000070fe00000| Untracked | 0 > | 28|0x0000000710000000, 0x0000000710000000, 0x0000000710200000| 0%| > F| |TAMS 0x0000000710000000| PB 0x0000000710000000| Untracked | 0 > | 29|0x0000000710200000, 0x0000000710200000, 0x0000000710400000| 0%| > F| |TAMS 0x0000000710200000| PB 0x0000000710200000| Untracked | 0 > | 30|0x0000000710400000, 0x0000000710400000, 0x0000000710600000| 0%| > F| |TAMS 0x0000000710400000| PB 0x0000000710400000| Untracked | 0 > | 31|0x0000000710600000, 0x0000000710600000, 0x0000000710800000| 0%| > F| |TAMS 0x0000000710600000| PB 0x0000000710600000| Untracked | 0 > | 32|0x0000000710800000, 0x0000000710800000, 0x0000000710a00000| 0%| > F| |TAMS 0x0000000710800000| PB 0x0000000710800000| Untracked | 0 > | 33|0x0000000710a00000, 0x0000000710a00000, 0x0000000710c00000| 0%| > F| |TAMS 0x0000000710a00000| PB 0x0000000710a00000| Untracked | 0 > | 34|0x0000000710c00000, 0x0000000710c00000, 0x0000000710e00000| 0%| > F| |TAMS 0x0000000710c00000| PB 0x0000000710c00000| Untracked | 0 > | 35|0x0000000710e00000, 0x0000000710e00000, 0x0000000711000000| 0%| > F| |TAMS 0x0000000710e00000| PB 0x0000000710e00000| Untracked | 0 > | 36|0x0000000711000000, 0x0000000711000000, 0x0000000711200000| 0%| > F| |TAMS 0x0000000711000000| PB 0x0000000711000000| Untracked | 0 > | 37|0x0000000711200000, 0x0000000711200000, 0x0000000711400000| 0%| > F| |TAMS 0x0000000711200000| PB 0x0000000711200000| Untracked | 0 > | 38|0x0000000711400000, 0x0000000711400000, 0x0000000711600000| 0%| > F| |TAMS 0x0000000711400000| PB 0x0000000711400000| Untracked | 0 > | 39|0x0000000711600000, 0x0000000711600000, 0x0000000711800000| 0%| > F| |TAMS 0x0000000711600000| PB 0x0000000711600000| Untracked | 0 > | 40|0x0000000711800000, 0x0000000711800000, 0x0000000711a00000| 0%| > F| |TAMS 0x0000000711800000| PB 0x0000000711800000| Untracked | 0 > | 41|0x0000000711a00000, 0x0000000711a00000, 0x0000000711c00000| 0%| > F| |TAMS 0x0000000711a00000| PB 0x0000000711a00000| Untracked | 0 > | 42|0x0000000711c00000, 0x0000000711c00000, 0x0000000711e00000| 0%| > F| |TAMS 0x0000000711c00000| PB 0x0000000711c00000| Untracked | 0 > | 43|0x0000000711e00000, 0x0000000711e00000, 0x0000000712000000| 0%| > F| |TAMS 0x0000000711e00000| PB 0x0000000711e00000| Untracked | 0 > | 44|0x0000000712000000, 0x0000000712000000, 0x0000000712200000| 0%| > F| |TAMS 0x0000000712000000| PB 0x0000000712000000| Untracked | 0 > | 45|0x0000000712200000, 0x0000000712200000, 0x0000000712400000| 0%| > F| |TAMS 0x0000000712200000| PB 0x0000000712200000| Untracked | 0 > | 46|0x0000000712400000, 0x0000000712400000, 0x0000000712600000| 0%| > F| |TAMS 0x0000000712400000| PB 0x0000000712400000| Untracked | 0 > | 47|0x0000000712600000, 0x0000000712600000, 0x0000000712800000| 0%| > F| |TAMS 0x0000000712600000| PB 0x0000000712600000| Untracked | 0 > | 48|0x0000000712800000, 0x0000000712800000, 0x0000000712a00000| 0%| > F| |TAMS 0x0000000712800000| PB 0x0000000712800000| Untracked | 0 > | 49|0x0000000712a00000, 0x0000000712a00000, 0x0000000712c00000| 0%| > F| |TAMS 0x0000000712a00000| PB 0x0000000712a00000| Untracked | 0 > | 50|0x0000000712c00000, 0x0000000712c00000, 0x0000000712e00000| 0%| > F| |TAMS 0x0000000712c00000| PB 0x0000000712c00000| Untracked | 0 > | 51|0x0000000712e00000, 0x0000000712e00000, 0x0000000713000000| 0%| > F| |TAMS 0x0000000712e00000| PB 0x0000000712e00000| Untracked | 0 > | 52|0x0000000713000000, 0x0000000713000000, 0x0000000713200000| 0%| > F| |TAMS 0x0000000713000000| PB 0x0000000713000000| Untracked | 0 > | 53|0x0000000713200000, 0x0000000713200000, 0x0000000713400000| 0%| > F| |TAMS 0x0000000713200000| PB 0x0000000713200000| Untracked | 0 > | 54|0x0000000713400000, 0x0000000713400000, 0x0000000713600000| 0%| > F| |TAMS 0x0000000713400000| PB 0x0000000713400000| Untracked | 0 > | 55|0x0000000713600000, 0x0000000713600000, 0x0000000713800000| 0%| > F| |TAMS 0x0000000713600000| PB 0x0000000713600000| Untracked | 0 > | 56|0x0000000713800000, 0x0000000713800000, 0x0000000713a00000| 0%| > F| |TAMS 0x0000000713800000| PB 0x0000000713800000| Untracked | 0 > | 57|0x0000000713a00000, 0x0000000713a00000, 0x0000000713c00000| 0%| > F| |TAMS 0x0000000713a00000| PB 0x0000000713a00000| Untracked | 0 > | 58|0x0000000713c00000, 0x0000000713c00000, 0x0000000713e00000| 0%| > F| |TAMS 0x0000000713c00000| PB 0x0000000713c00000| Untracked | 0 > | 59|0x0000000713e00000, 0x0000000713e00000, 0x0000000714000000| 0%| > F| |TAMS 0x0000000713e00000| PB 0x0000000713e00000| Untracked | 0 > | 60|0x0000000714000000, 0x0000000714000000, 0x0000000714200000| 0%| > F| |TAMS 0x0000000714000000| PB 0x0000000714000000| Untracked | 0 > | 61|0x0000000714200000, 0x0000000714200000, 0x0000000714400000| 0%| > F| |TAMS 0x0000000714200000| PB 0x0000000714200000| Untracked | 0 > | 62|0x0000000714400000, 0x0000000714400000, 0x0000000714600000| 0%| > F| |TAMS 0x0000000714400000| PB 0x0000000714400000| Untracked | 0 > | 63|0x0000000714600000, 0x0000000714600000, 0x0000000714800000| 0%| > F| |TAMS 0x0000000714600000| PB 0x0000000714600000| Untracked | 0 > | 64|0x0000000714800000, 0x0000000714800000, 0x0000000714a00000| 0%| > F| |TAMS 0x0000000714800000| PB 0x0000000714800000| Untracked | 0 > | 65|0x0000000714a00000, 0x0000000714a00000, 0x0000000714c00000| 0%| > F| |TAMS 0x0000000714a00000| PB 0x0000000714a00000| Untracked | 0 > | 66|0x0000000714c00000, 0x0000000714c00000, 0x0000000714e00000| 0%| > F| |TAMS 0x0000000714c00000| PB 0x0000000714c00000| Untracked | 0 > | 67|0x0000000714e00000, 0x0000000714e00000, 0x0000000715000000| 0%| > F| |TAMS 0x0000000714e00000| PB 0x0000000714e00000| Untracked | 0 > | 68|0x0000000715000000, 0x0000000715000000, 0x0000000715200000| 0%| > F| |TAMS 0x0000000715000000| PB 0x0000000715000000| Untracked | 0 > | 69|0x0000000715200000, 0x0000000715200000, 0x0000000715400000| 0%| > F| |TAMS 0x0000000715200000| PB 0x0000000715200000| Untracked | 0 > | 70|0x0000000715400000, 0x0000000715400000, 0x0000000715600000| 0%| > F| |TAMS 0x0000000715400000| PB 0x0000000715400000| Untracked | 0 > | 71|0x0000000715600000, 0x0000000715600000, 0x0000000715800000| 0%| > F| |TAMS 0x0000000715600000| PB 0x0000000715600000| Untracked | 0 > | 72|0x0000000715800000, 0x0000000715800000, 0x0000000715a00000| 0%| > F| |TAMS 0x0000000715800000| PB 0x0000000715800000| Untracked | 0 > | 73|0x0000000715a00000, 0x0000000715a00000, 0x0000000715c00000| 0%| > F| |TAMS 0x0000000715a00000| PB 0x0000000715a00000| Untracked | 0 > | 74|0x0000000715c00000, 0x0000000715c00000, 0x0000000715e00000| 0%| > F| |TAMS 0x0000000715c00000| PB 0x0000000715c00000| Untracked | 0 > | 75|0x0000000715e00000, 0x0000000715e00000, 0x0000000716000000| 0%| > F| |TAMS 0x0000000715e00000| PB 0x0000000715e00000| Untracked | 0 > | 76|0x0000000716000000, 0x0000000716000000, 0x0000000716200000| 0%| > F| |TAMS 0x0000000716000000| PB 0x0000000716000000| Untracked | 0 > | 77|0x0000000716200000, 0x0000000716200000, 0x0000000716400000| 0%| > F| |TAMS 0x0000000716200000| PB 0x0000000716200000| Untracked | 0 > | 78|0x0000000716400000, 0x0000000716400000, 0x0000000716600000| 0%| > F| |TAMS 0x0000000716400000| PB 0x0000000716400000| Untracked | 0 > | 79|0x0000000716600000, 0x0000000716600000, 0x0000000716800000| 0%| > F| |TAMS 0x0000000716600000| PB 0x0000000716600000| Untracked | 0 > | 80|0x0000000716800000, 0x0000000716800000, 0x0000000716a00000| 0%| > F| |TAMS 0x0000000716800000| PB 0x0000000716800000| Untracked | 0 > | 81|0x0000000716a00000, 0x0000000716a00000, 0x0000000716c00000| 0%| > F| |TAMS 0x0000000716a00000| PB 0x0000000716a00000| Untracked | 0 > | 82|0x0000000716c00000, 0x0000000716c00000, 0x0000000716e00000| 0%| > F| |TAMS 0x0000000716c00000| PB 0x0000000716c00000| Untracked | 0 > | 83|0x0000000716e00000, 0x0000000716e00000, 0x0000000717000000| 0%| > F| |TAMS 0x0000000716e00000| PB 0x0000000716e00000| Untracked | 0 > | 84|0x0000000717000000, 0x0000000717000000, 0x0000000717200000| 0%| > F| |TAMS 0x0000000717000000| PB 0x0000000717000000| Untracked | 0 > | 85|0x0000000717200000, 0x0000000717200000, 0x0000000717400000| 0%| > F| |TAMS 0x0000000717200000| PB 0x0000000717200000| Untracked | 0 > | 86|0x0000000717400000, 0x0000000717400000, 0x0000000717600000| 0%| > F| |TAMS 0x0000000717400000| PB 0x0000000717400000| Untracked | 0 > | 87|0x0000000717600000, 0x0000000717600000, 0x0000000717800000| 0%| > F| |TAMS 0x0000000717600000| PB 0x0000000717600000| Untracked | 0 > | 88|0x0000000717800000, 0x0000000717800000, 0x0000000717a00000| 0%| > F| |TAMS 0x0000000717800000| PB 0x0000000717800000| Untracked | 0 > | 89|0x0000000717a00000, 0x0000000717a00000, 0x0000000717c00000| 0%| > F| |TAMS 0x0000000717a00000| PB 0x0000000717a00000| Untracked | 0 > | 90|0x0000000717c00000, 0x0000000717c00000, 0x0000000717e00000| 0%| > F| |TAMS 0x0000000717c00000| PB 0x0000000717c00000| Untracked | 0 > | 91|0x0000000717e00000, 0x0000000717e00000, 0x0000000718000000| 0%| > F| |TAMS 0x0000000717e00000| PB 0x0000000717e00000| Untracked | 0 > | 92|0x0000000718000000, 0x0000000718000000, 0x0000000718200000| 0%| > F| |TAMS 0x0000000718000000| PB 0x0000000718000000| Untracked | 0 > | 93|0x0000000718200000, 0x0000000718200000, 0x0000000718400000| 0%| > F| |TAMS 0x0000000718200000| PB 0x0000000718200000| Untracked | 0 > | 94|0x0000000718400000, 0x0000000718400000, 0x0000000718600000| 0%| > F| |TAMS 0x0000000718400000| PB 0x0000000718400000| Untracked | 0 > | 95|0x0000000718600000, 0x0000000718600000, 0x0000000718800000| 0%| > F| |TAMS 0x0000000718600000| PB 0x0000000718600000| Untracked | 0 > | 96|0x0000000718800000, 0x0000000718800000, 0x0000000718a00000| 0%| > F| |TAMS 0x0000000718800000| PB 0x0000000718800000| Untracked | 0 > | 97|0x0000000718a00000, 0x0000000718a00000, 0x0000000718c00000| 0%| > F| |TAMS 0x0000000718a00000| PB 0x0000000718a00000| Untracked | 0 > | 98|0x0000000718c00000, 0x0000000718c00000, 0x0000000718e00000| 0%| > F| |TAMS 0x0000000718c00000| PB 0x0000000718c00000| Untracked | 0 > | 99|0x0000000718e00000, 0x0000000718e00000, 0x0000000719000000| 0%| > F| |TAMS 0x0000000718e00000| PB 0x0000000718e00000| Untracked | 0 > | 100|0x0000000719000000, 0x0000000719000000, 0x0000000719200000| 0%| > F| |TAMS 0x0000000719000000| PB 0x0000000719000000| Untracked | 0 > | 101|0x0000000719200000, 0x0000000719200000, 0x0000000719400000| 0%| > F| |TAMS 0x0000000719200000| PB 0x0000000719200000| Untracked | 0 > | 102|0x0000000719400000, 0x0000000719400000, 0x0000000719600000| 0%| > F| |TAMS 0x0000000719400000| PB 0x0000000719400000| Untracked | 0 > | 103|0x0000000719600000, 0x0000000719600000, 0x0000000719800000| 0%| > F| |TAMS 0x0000000719600000| PB 0x0000000719600000| Untracked | 0 > | 104|0x0000000719800000, 0x0000000719800000, 0x0000000719a00000| 0%| > F| |TAMS 0x0000000719800000| PB 0x0000000719800000| Untracked | 0 > | 105|0x0000000719a00000, 0x0000000719a00000, 0x0000000719c00000| 0%| > F| |TAMS 0x0000000719a00000| PB 0x0000000719a00000| Untracked | 0 > | 106|0x0000000719c00000, 0x0000000719c00000, 0x0000000719e00000| 0%| > F| |TAMS 0x0000000719c00000| PB 0x0000000719c00000| Untracked | 0 > | 107|0x0000000719e00000, 0x0000000719e00000, 0x000000071a000000| 0%| > F| |TAMS 0x0000000719e00000| PB 0x0000000719e00000| Untracked | 0 > | 108|0x000000071a000000, 0x000000071a000000, 0x000000071a200000| 0%| > F| |TAMS 0x000000071a000000| PB 0x000000071a000000| Untracked | 0 > | 109|0x000000071a200000, 0x000000071a200000, 0x000000071a400000| 0%| > F| |TAMS 0x000000071a200000| PB 0x000000071a200000| Untracked | 0 > | 110|0x000000071a400000, 0x000000071a400000, 0x000000071a600000| 0%| > F| |TAMS 0x000000071a400000| PB 0x000000071a400000| Untracked | 0 > | 111|0x000000071a600000, 0x000000071a600000, 0x000000071a800000| 0%| > F| |TAMS 0x000000071a600000| PB 0x000000071a600000| Untracked | 0 > | 112|0x000000071a800000, 0x000000071a800000, 0x000000071aa00000| 0%| > F| |TAMS 0x000000071a800000| PB 0x000000071a800000| Untracked | 0 > | 113|0x000000071aa00000, 0x000000071aa00000, 0x000000071ac00000| 0%| > F| |TAMS 0x000000071aa00000| PB 0x000000071aa00000| Untracked | 0 > | 114|0x000000071ac00000, 0x000000071ac00000, 0x000000071ae00000| 0%| > F| |TAMS 0x000000071ac00000| PB 0x000000071ac00000| Untracked | 0 > | 115|0x000000071ae00000, 0x000000071ae00000, 0x000000071b000000| 0%| > F| |TAMS 0x000000071ae00000| PB 0x000000071ae00000| Untracked | 0 > | 116|0x000000071b000000, 0x000000071b000000, 0x000000071b200000| 0%| > F| |TAMS 0x000000071b000000| PB 0x000000071b000000| Untracked | 0 > | 117|0x000000071b200000, 0x000000071b200000, 0x000000071b400000| 0%| > F| |TAMS 0x000000071b200000| PB 0x000000071b200000| Untracked | 0 > | 118|0x000000071b400000, 0x000000071b400000, 0x000000071b600000| 0%| > F| |TAMS 0x000000071b400000| PB 0x000000071b400000| Untracked | 0 > | 119|0x000000071b600000, 0x000000071b600000, 0x000000071b800000| 0%| > F| |TAMS 0x000000071b600000| PB 0x000000071b600000| Untracked | 0 > | 120|0x000000071b800000, 0x000000071b800000, 0x000000071ba00000| 0%| > F| |TAMS 0x000000071b800000| PB 0x000000071b800000| Untracked | 0 > | 121|0x000000071ba00000, 0x000000071bc00000, 0x000000071bc00000|100%| > E| |TAMS 0x000000071ba00000| PB 0x000000071ba00000| Complete | 0 > |1947|0x00000007ffe00000, 0x00000007fff1c148, 0x0000000800000000| 55%| > O| |TAMS 0x00000007ffe00000| PB 0x00000007ffe00000| Untracked | 0 > > Card table byte_map: [0x00000268f51f0000,0x00000268f5990000] > _byte_map_base: 0x00000268f198c000 > > Marking Bits: (CMBitMap*) 0x00000268e7d7dda0 > Bits: [0x00000268f5990000, 0x00000268f9670000) > > Polling page: 0x00000268e5a80000 > > Metaspace: > > Usage: > Non-class: 14.61 KB used. > Class: 6.95 KB used. > Both: 21.56 KB used. > > Virtual space: > Non-class space: 64.00 MB reserved, 128.00 KB ( <1%) > committed, 1 nodes. > Class space: 1.00 GB reserved, 128.00 KB ( <1%) > committed, 1 nodes. > Both: 1.06 GB reserved, 256.00 KB ( <1%) committed. > > Chunk freelists: > Non-Class: 12.00 MB > Class: 15.75 MB > Both: 27.74 MB > > MaxMetaspaceSize: unlimited > CompressedClassSpaceSize: 1.00 GB > Initial GC threshold: 21.00 MB > Current GC threshold: 21.00 MB > CDS: on > - commit_granule_bytes: 65536. > - commit_granule_words: 8192. > - virtual_space_node_default_size: 8388608. > - enlarge_chunks_in_place: 1. > UseCompressedClassPointers 1, UseCompactObjectHeaders 0 > Narrow klass pointer bits 32, Max shift 3 > Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 > Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 > bytes) > Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 > bytes) > Klass ID Range: [65536 - 1090519033) (1090453497) > Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) > > > Internal statistics: > > num_allocs_failed_limit: 0. > num_arena_births: 4. > num_arena_deaths: 0. > num_vsnodes_births: 2. > num_vsnodes_deaths: 0. > num_space_committed: 4. > num_space_uncommitted: 0. > num_chunks_returned_to_freelist: 0. > num_chunks_taken_from_freelist: 4. > num_chunk_merges: 0. > num_chunk_splits: 4. > num_chunks_enlarged: 0. > num_inconsistent_stats: 0. > > CodeCache: size=32768Kb used=84Kb max_used=84Kb free=32683Kb > bounds [0x00000268f1e90000, 0x00000268f1eb8000, 0x00000268f3e90000] > total_blobs=225, nmethods=0, adapters=216, full_count=0 > Compilation: disabled (interpreter mode), stopped_count=0, > restarted_count=0 > > Compilation events (0 events): > No events > > GC Heap History (0 events): > No events > > Dll operation events (2 events): > Event: 0.006 Loaded shared library > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll > Event: 0.286 Loaded shared library > C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll > > Deoptimization events (0 events): > No events > > Classes loaded (16 events): > Event: 0.023 Loading class sun/nio/cs/IBM437 > Event: 0.023 Loading class sun/nio/cs/IBM437 done > Event: 0.023 Loading class sun/nio/cs/IBM437$Holder > Event: 0.023 Loading class sun/nio/cs/IBM437$Holder done > Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook > Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook done > Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader > Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader done > Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 > Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 > done > Event: 0.027 Loading class java/lang/InterruptedException > Event: 0.027 Loading class java/lang/InterruptedException done > Event: 0.027 Loading class java/lang/CloneNotSupportedException > Event: 0.027 Loading class java/lang/CloneNotSupportedException done > Event: 0.028 Loading class java/util/Formatter$FixedString > Event: 0.029 Loading class java/util/Formatter$FixedString done > > Classes unloaded (0 events): > No events > > Classes redefined (0 events): > No events > > Internal exceptions (0 events): > No events > > VM Operations (0 events): > No events > > Memory protections (0 events): > No events > > Nmethod flushes (0 events): > No events > > Events (9 events): > Event: 0.017 Thread 0x00000268e57a3d20 Thread added: 0x00000268e57a3d20 > Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08cfc0 > Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08d5f0 > Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc091710 > Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc092140 > Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0936e0 > Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc09d2a0 > Event: 0.026 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0d8ec0 > Event: 0.027 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0de6e0 > > > Dynamic libraries: > 0x00007ff7bcd60000 - 0x00007ff7bcd70000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.exe > 0x00007ffd45be0000 - 0x00007ffd45e40000 C:\WINDOWS\SYSTEM32\ntdll.dll > 0x00007ffd44600000 - 0x00007ffd446c7000 C:\WINDOWS\System32\KERNEL32.DLL > 0x00007ffd43490000 - 0x00007ffd4385a000 C:\WINDOWS\System32\KERNELBASE.dll > 0x00007ffd42dc0000 - 0x00007ffd42f0b000 C:\WINDOWS\System32\ucrtbase.dll > 0x00007ffd30100000 - 0x00007ffd3011d000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\VCRUNTIME140.dll > 0x00007ffd2a470000 - 0x00007ffd2a487000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jli.dll > 0x00007ffd450e0000 - 0x00007ffd452ac000 C:\WINDOWS\System32\USER32.dll > 0x00007ffd41f90000 - 0x00007ffd42227000 > > C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24\COMCTL32.dll > 0x00007ffd43040000 - 0x00007ffd43067000 C:\WINDOWS\System32\win32u.dll > 0x00007ffd44a40000 - 0x00007ffd44ae9000 C:\WINDOWS\System32\msvcrt.dll > 0x00007ffd44af0000 - 0x00007ffd44b1a000 C:\WINDOWS\System32\GDI32.dll > 0x00007ffd43130000 - 0x00007ffd43261000 C:\WINDOWS\System32\gdi32full.dll > 0x00007ffd433e0000 - 0x00007ffd43483000 C:\WINDOWS\System32\msvcp_win.dll > 0x00007ffd44560000 - 0x00007ffd4458f000 C:\WINDOWS\System32\IMM32.DLL > 0x00007ffd27710000 - 0x00007ffd2771c000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\vcruntime140_1.dll > 0x00007ffd14e00000 - 0x00007ffd14e8d000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\msvcp140.dll > 0x00007ffceaf00000 - 0x00007ffceb4cf000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero\jvm.dll > 0x00007ffd452b0000 - 0x00007ffd45362000 C:\WINDOWS\System32\ADVAPI32.dll > 0x00007ffd44780000 - 0x00007ffd44826000 C:\WINDOWS\System32\sechost.dll > 0x00007ffd442d0000 - 0x00007ffd443e6000 C:\WINDOWS\System32\RPCRT4.dll > 0x00007ffd446d0000 - 0x00007ffd44744000 C:\WINDOWS\System32\WS2_32.dll > 0x00007ffd42c30000 - 0x00007ffd42c8e000 C:\WINDOWS\SYSTEM32\POWRPROF.dll > 0x00007ffd332f0000 - 0x00007ffd33326000 C:\WINDOWS\SYSTEM32\WINMM.dll > 0x00007ffd391c0000 - 0x00007ffd391cb000 C:\WINDOWS\SYSTEM32\VERSION.dll > 0x00007ffd16d70000 - 0x00007ffd16d81000 C:\msys64\ucrt64\bin\libffi-8.dll > 0x00007ffd42c10000 - 0x00007ffd42c24000 C:\WINDOWS\SYSTEM32\UMPDC.dll > 0x00007ffd41a60000 - 0x00007ffd41a6c000 C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL > 0x00007ffd42fa0000 - 0x00007ffd43039000 > C:\WINDOWS\System32\bcryptPrimitives.dll > 0x00007ffd41270000 - 0x00007ffd4128a000 > C:\WINDOWS\SYSTEM32\kernel.appcore.dll > 0x00007ffd27060000 - 0x00007ffd2706a000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jimage.dll > 0x00007ffd42540000 - 0x00007ffd42781000 C:\WINDOWS\SYSTEM32\DBGHELP.DLL > 0x00007ffd44d50000 - 0x00007ffd450d2000 C:\WINDOWS\System32\combase.dll > 0x00007ffd439e0000 - 0x00007ffd43ab6000 C:\WINDOWS\System32\OLEAUT32.dll > 0x00007ffd01660000 - 0x00007ffd01699000 C:\WINDOWS\SYSTEM32\dbgcore.DLL > 0x00007ffd16d50000 - 0x00007ffd16d6d000 > > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll > 0x00007ffd44b20000 - 0x00007ffd44cb6000 C:\WINDOWS\System32\ole32.dll > 0x00007ffd45370000 - 0x00007ffd45a99000 C:\WINDOWS\System32\SHELL32.dll > 0x00007ffd43270000 - 0x00007ffd433d8000 C:\WINDOWS\System32\wintypes.dll > 0x00007ffd3ff80000 - 0x00007ffd407d2000 > C:\WINDOWS\SYSTEM32\windows.storage.dll > 0x00007ffd44400000 - 0x00007ffd444ed000 C:\WINDOWS\System32\SHCORE.dll > 0x00007ffd444f0000 - 0x00007ffd44554000 C:\WINDOWS\System32\shlwapi.dll > 0x00007ffd42cd0000 - 0x00007ffd42cff000 C:\WINDOWS\SYSTEM32\profapi.dll > 0x00007ffd15180000 - 0x00007ffd15192000 > C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll > > JVMTI agents: none > > dbghelp: loaded successfully - version: 4.0.5 - missing functions: none > symbol engine: initialized successfully - sym options: 0x614 - pdb > path: > .;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero;C:\msys64\ucrt64\bin;C:\Users\REDACTED\Downloads\LoadLibrary\Crash > > VM Arguments: > jvm_args: --enable-preview > java_command: Crash > java_class_path (initial): C:/Users/REDACTED/Downloads/LoadLibrary/Crash > Launcher Type: SUN_STANDARD > > [Global flags] > uint ConcGCThreads = 5 > {product} {ergonomic} > uint G1ConcRefinementThreads = 18 > {product} {ergonomic} > size_t G1HeapRegionSize = 2097152 > {product} {ergonomic} > size_t InitialHeapSize = 255852544 > {product} {ergonomic} > size_t MarkStackSize = 4194304 > {product} {ergonomic} > size_t MarkStackSizeMax = 536870912 > {product} {ergonomic} > size_t MaxHeapSize = 4085252096 > {product} {ergonomic} > size_t MaxNewSize = 2449473536 > {product} {ergonomic} > size_t MinHeapDeltaBytes = 2097152 > {product} {ergonomic} > size_t MinHeapSize = 8388608 > {product} {ergonomic} > uintx NonNMethodCodeHeapSize = 4096 > {pd product} {ergonomic} > uintx NonProfiledCodeHeapSize = 0 > {pd product} {ergonomic} > uintx ProfiledCodeHeapSize = 0 > {pd product} {ergonomic} > size_t SoftMaxHeapSize = 4085252096 > {manageable} {ergonomic} > bool UseCompressedOops = true > {product lp64_product} {ergonomic} > bool UseG1GC = true > {product} {ergonomic} > bool UseLargePagesIndividualAllocation = false > {pd product} {ergonomic} > > Logging: > Log output configuration: > #0: stdout all=warning uptime,level,tags foldmultilines=false > #1: stderr all=off uptime,level,tags foldmultilines=false > > Release file: > IMPLEMENTOR="N/A" > JAVA_RUNTIME_VERSION="25-internal" > JAVA_VERSION="25" > JAVA_VERSION_DATE="2025-09-16" > LIBC="default" > MODULES="java.base java.compiler java.datatransfer java.xml java.prefs > java.desktop java.instrument java.logging java.management > java.security.sasl java.naming java.rmi java.management.rmi > java.net.http java.scripting java.security.jgss java.transaction.xa > java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio > jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets > jdk.internal.opt jdk.zipfs jdk.compiler jdk.crypto.cryptoki > jdk.crypto.ec jdk.crypto.mscapi jdk.dynalink jdk.internal.ed > jdk.editpad jdk.httpserver jdk.incubator.vector jdk.internal.le > jdk.internal.md jdk.jartool jdk.javadoc jdk.jcmd jdk.management > jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi > jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd > jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi > jdk.net jdk.nio.mapmode jdk.sctp jdk.security.auth jdk.security.jgss > jdk.unsupported jdk.unsupported.desktop jdk.xml.dom" > OS_ARCH="x86_64" > OS_NAME="Windows" > SOURCE=".:git:8f7652d7a36b+" > > Environment Variables: > > PATH=C:\msys64\ucrt64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl > USERNAME=REDACTED > SHELL=C:\msys64\usr\bin\bash.exe > LC_CTYPE=en_US.UTF-8 > TERM=xterm > OS=Windows_NT > PROCESSOR_IDENTIFIER=AMD64 Family 25 Model 97 Stepping 2, AuthenticAMD > TMP=C:\msys64\tmp > TEMP=C:\msys64\tmp > > > > > Compilation memory statistics disabled. > > Periodic native trim disabled > > --------------- S Y S T E M --------------- > > OS: > Windows 11 , 64 bit Build 26100 (10.0.26100.3775) > OS uptime: 0 days 1:47 hours > > CPU: total 24 (initial active 24) > Processor Information for processor 0 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 1 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 2 > Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 > Processor Information for processor 3 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 4 > Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 > Processor Information for processor 5 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 6 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 7 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 8 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 9 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 10 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 11 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 12 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 13 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 14 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 15 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 16 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 17 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 18 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 19 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 20 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 21 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 22 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > Processor Information for processor 23 > Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > > Memory: 4k page, system-wide physical 15578M (1690M free) > TotalPageFile size 44250M (AvailPageFile size 20548M) > current process WorkingSet (physical memory assigned to process): 64M, > peak: 64M > current process commit charge ("private bytes"): 373M, peak: 373M > > vm_info: Java HotSpot 64-Bit Zero VM (25-internal) for windows-amd64 > JRE (25-internal), built on 2025-04-17T14:32:22Z with MS VC++ 17.8 > (VS2022) > > END. > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-161-Note: > including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:162:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): > warning C5030: attribute [[gnu::packed]] is not recognized > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-320-Note: > including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:321:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log-13-Note: > including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:15:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:16:jdk\src\hotspot\cpu\zero\interpreterRT_zero.cpp(161): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-168-Note: > including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:169:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): > warning C5030: attribute [[gnu::packed]] is not recognized > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-307-Note: > including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:308:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log-7-Note: > including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:8:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:9:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:10:jdk\src\hotspot\cpu\zero\stack_zero.cpp(36): > warning C4267: '=': conversion from 'size_t' to 'int', possible loss > of data > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log-12-Note: > including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:13:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log-28-Note: > including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:29:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:30:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > warning C4267: 'initializing': conversion from 'size_t' to 'int', > possible loss of data > > Generating code > Previous IPDB not found, fall back to full compilation. > s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning > C4723: potential divide by 0 > s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning > C4723: potential divide by 0 > s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning > C4723: potential divide by 0 > All 52893 functions were compiled because no usable IPDB/IOBJ from > previous compilation was found. > Finished generating code > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Tue Apr 22 13:37:31 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Tue, 22 Apr 2025 13:37:31 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes Regards, Chen Liang ________________________________ From: jdk-dev on behalf of Tobias Hartmann Sent: Tuesday, April 22, 2025 8:20:38 AM To: jdk-dev at openjdk.org Subject: Re: CFV: New JDK Committer: Marc Chevalier Vote: yes Best regards, Tobias On 4/22/25 14:58, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From damon.fenacci at oracle.com Tue Apr 22 13:53:37 2025 From: damon.fenacci at oracle.com (Damon Fenacci) Date: Tue, 22 Apr 2025 13:53:37 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes Damon > On 22 Apr 2025, at 14:58, Tobias Hartmann wrote: > > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From roger.riggs at oracle.com Tue Apr 22 14:16:12 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 22 Apr 2025 10:16:12 -0400 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: Yes On 4/22/25 8:58 AM, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. From archie.cobbs at gmail.com Tue Apr 22 14:34:12 2025 From: archie.cobbs at gmail.com (Archie Cobbs) Date: Tue, 22 Apr 2025 09:34:12 -0500 Subject: Where to put supplementary docs? In-Reply-To: References: Message-ID: On Tue, Apr 22, 2025 at 4:31?AM Andrew Haley wrote: > I propose to add a new subdirectory to jdk/doc, called "ref" or > "reference". This is not for every possible reference document, but > those that aid the maintainer and will be useful in the future. A > comment in the source code should refer the reader to the appropriate > reference document. I support this idea. I'm sure in lots of other places too, but in the compiler, there is often subtle or non-obvious logic happening that could benefit from a more proper explanation than what you get from inline comments, etc. The hard part is keeping this documentation up-to-date as the code evolves. If the docs are not sitting in the same directory as the code they document, then there probably needs to be some other trick to remind people to keep them in sync e.g., a big comment at the top of the file like /* REFERENCE DOCUMENTATION HERE: KEEP UP TO DATE */ or something. Even better, add a skara check that mechanically verifies, for any change to a source file, either (a) there is no corresponding reference documentation or (b) that documentation has been updated (perhaps with just a trivial date/counter bump if no real change was needed), etc. Then the documentation updates would be naturally included as part of PR reviews. -Archie -- Archie L. Cobbs -------------- next part -------------- An HTML attachment was scrubbed... URL: From emanuel.peter at oracle.com Tue Apr 22 14:47:45 2025 From: emanuel.peter at oracle.com (Emanuel Peter) Date: Tue, 22 Apr 2025 14:47:45 +0000 Subject: CFV: New JDK Committer: Marc Chevalier Message-ID: Vote: yes Best regards, Emanuel -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.caspole at oracle.com Tue Apr 22 15:00:07 2025 From: eric.caspole at oracle.com (Eric Caspole) Date: Tue, 22 Apr 2025 11:00:07 -0400 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: <3597cdcc-d891-4e5b-b705-36f4d548202b@oracle.com> Vote: yes Regards, Eric On 4/22/25 8:58 AM, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since > February 2025, he contributed 16 changes to the JDK project [2], > mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] > https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From vladimir.kozlov at oracle.com Tue Apr 22 15:26:24 2025 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 22 Apr 2025 08:26:24 -0700 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: <3991f626-57b9-4941-8525-eb57ff6f16cd@oracle.com> Vote: yes Thanks, Vladimir K On 4/22/25 5:58 AM, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK > project [2], mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From jesper.wilhelmsson at oracle.com Tue Apr 22 18:36:40 2025 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 22 Apr 2025 18:36:40 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: <6FAF0707-3B06-44CC-9FAF-29FC79662051@oracle.com> Vote: Yes /Jesper > On 22 Apr 2025, at 14:58, Tobias Hartmann wrote: > > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From dean.long at oracle.com Tue Apr 22 20:56:15 2025 From: dean.long at oracle.com (Dean Long) Date: Tue, 22 Apr 2025 13:56:15 -0700 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: <01c169e0-2670-4774-9575-ae5ebfa18803@oracle.com> Vote: yes From mikael.vidstedt at oracle.com Tue Apr 22 21:19:59 2025 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 22 Apr 2025 21:19:59 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes Cheers, Mikael > On Apr 22, 2025, at 5:58?AM, Tobias Hartmann wrote: > > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From adinn at redhat.com Wed Apr 23 07:23:07 2025 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 23 Apr 2025 08:23:07 +0100 Subject: Result: New JDK Reviewer: Martin Balao Message-ID: <59fb24c4-3f88-4580-a99d-57d0123c1bd7@redhat.com> Voting for Martin Balao (mbalao) [1] is now closed. Yes: 23 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Andrew Dinn [1] https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009925.html From adinn at redhat.com Wed Apr 23 07:27:03 2025 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 23 Apr 2025 08:27:03 +0100 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: <1cb84de7-f348-48b7-bb86-badd8dbf9677@redhat.com> Vote: yes On 22/04/2025 13:58, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February > 2025, he contributed 16 changes to the JDK project [2], mostly in the > area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc- > chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 From daniel.lunden at oracle.com Wed Apr 23 09:06:23 2025 From: daniel.lunden at oracle.com (Daniel Lunden) Date: Wed, 23 Apr 2025 09:06:23 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes Best, Daniel ________________________________ From: jdk-dev on behalf of Tobias Hartmann Sent: Tuesday, 22 April 2025 14:58 To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Marc Chevalier I hereby nominate Marc Chevalier [1] to JDK Committer. Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. Votes are due by May 6, 2025, 13:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#mchevalier [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From aleksej.efimov at oracle.com Wed Apr 23 09:58:07 2025 From: aleksej.efimov at oracle.com (Aleksei Efimov) Date: Wed, 23 Apr 2025 09:58:07 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes Best Regards, Aleksei ________________________________ From: jdk-dev on behalf of Tobias Hartmann Sent: Tuesday 22 April 2025 1:58 pm To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Marc Chevalier I hereby nominate Marc Chevalier [1] to JDK Committer. Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. Votes are due by May 6, 2025, 13:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#mchevalier [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.castaneda.lozano at oracle.com Thu Apr 24 08:09:56 2025 From: roberto.castaneda.lozano at oracle.com (Roberto Castaneda Lozano) Date: Thu, 24 Apr 2025 08:09:56 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes ________________________________________ From: jdk-dev on behalf of Tobias Hartmann Sent: Tuesday, April 22, 2025 2:58 PM To: jdk-dev at openjdk.org Subject: CFV: New JDK Committer: Marc Chevalier I hereby nominate Marc Chevalier [1] to JDK Committer. Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. Votes are due by May 6, 2025, 13:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#mchevalier [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 [3] https://openjdk.java.net/census [4] https://openjdk.org/projects/#committer-vote From aph-open at littlepinkcloud.com Thu Apr 24 09:10:04 2025 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Thu, 24 Apr 2025 10:10:04 +0100 Subject: Where to put supplementary docs? In-Reply-To: References: Message-ID: Anyone? On 4/22/25 10:31, Andrew Haley wrote: > Sometimes, when reviewing a PR, we have supporting documents to > justify a change. These docs can include diagrams, etc. In the past > some such documents were put on the webrev server, and sometimes they > got lost. One example of such a file is "Fast Subtype Checking in the > HotSpot JVM," which explained the (now obsolete) secondary subtype > checking algorithm. > > Today, documents are sometimes uploaded to JIRA or attached to the PR > itself. Sometimes they are stored in someone's personal web space, and > linked from a PR, and that's when things get lost. > > It would be better for long-term retention if such documents were > included in the JDK repository itself, and committed to the repo as > part of the PR. I'm assuming that these files will be fairly small, so > will not greatly increase the size of the repo. > > I propose to add a new subdirectory to jdk/doc, called "ref" or > "reference". This is not for every possible reference document, but > those that aid the maintainer and will be useful in the future. A > comment in the source code should refer the reader to the appropriate > reference document. > > Does anyone here object to this? Is there some other place than > "doc/ref" that would be more appropriate? > > Thanks, > > Andrew. > -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Thu Apr 24 09:36:02 2025 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Thu, 24 Apr 2025 11:36:02 +0200 Subject: Where to put supplementary docs? In-Reply-To: References: Message-ID: <96c0f5e1-53a4-43f0-bba2-a859d0850252@oracle.com> On 24/04/2025 11:10, Andrew Haley wrote: > Anyone? I assume that you've already selected against creating a 'supplementary documentation for individual changes' section on the wiki, right? I couldn't find it mentioned in the argument below. cheers, dalibor topic > On 4/22/25 10:31, Andrew Haley wrote: >> Sometimes, when reviewing a PR, we have supporting documents to >> justify a change. These docs can include diagrams, etc. In the past >> some such documents were put on the webrev server, and sometimes they >> got lost. One example of such a file is "Fast Subtype Checking in the >> HotSpot JVM," which explained the (now obsolete) secondary subtype >> checking algorithm. >> >> Today, documents are sometimes uploaded to JIRA or attached to the PR >> itself. Sometimes they are stored in someone's personal web space, and >> linked from a PR, and that's when things get lost. >> >> It would be better for long-term retention if such documents were >> included in the JDK repository itself, and committed to the repo as >> part of the PR. I'm assuming that these files will be fairly small, so >> will not greatly increase the size of the repo. >> >> I propose to add a new subdirectory to jdk/doc, called "ref" or >> "reference". This is not for every possible reference document, but >> those that aid the maintainer and will be useful in the future. A >> comment in the source code should refer the reader to the appropriate >> reference document. >> >> Does anyone here object to this? Is there some other place than >> "doc/ref" that would be more appropriate? >> >> Thanks, >> >> Andrew. >> > -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From thomas.stuefe at gmail.com Thu Apr 24 10:07:00 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Apr 2025 12:07:00 +0200 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes On Tue, Apr 22, 2025 at 3:02?PM Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February > 2025, he contributed 16 changes to the JDK project [2], mostly in the area > of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] > https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tanksherman27 at gmail.com Thu Apr 24 11:47:37 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 24 Apr 2025 19:47:37 +0800 Subject: Windows/Zero In-Reply-To: References: Message-ID: Hi Thomas, sorry for the late reply, Off the top of my head, the Zero JVM is extremely small and could be useful in environments where a small JVM is needed. More importantly, it may (Although I have not verified this yet) allow Java to run on 32 bit Windows again, at no additional cost to maintenance since Zero itself requires no extra 32 bit support, it's just compile and run. It can help if you're working on other parts of the JDK and don't care about the JVM, and just want it to compile and link quickly so you can get to testing out the changes in the non JVM area of the JDK you're working on at the moment, something that I do commonly. I guess the process of supporting Windows/Zero also helped eliminate non standard zero size arrays in HotSpot, though this may not be that big of a deal. Regardless, I'm just curious if there is interest in it from anyone at the moment. Have a great rest of the week ahead! best regards, Julian On Tue, Apr 22, 2025 at 9:35?PM Thomas St?fe wrote: > > Hi Julian, > > I am curious, what would be the use case for Windows+Zero? > > Zero is typically used for bootstrapping new platforms/CPUs. The Windows CPU set is very stable, and Windows is not the platform anyone starts porting to if they start working on a new platform. Additionally, Microsoft usually takes care of porting in the once-a-decade-rare case that a new CPU is supported on Windows. > > Cheers, Thomas > > > On Tue, Apr 22, 2025 at 2:47?PM Julian Waters wrote: >> >> Hi all, >> >> Zero currently cannot compile on Windows, and to my knowledge, has >> never been able to compile on Windows. This is largely due to Windows >> lacking crucial implementations for Zero under the os_cpu directory, >> where you will notice a distinct lack of a windows_zero directory. To >> remedy this, some time ago, I implemented Zero on Windows. The >> implementation, aside from adding critical code to windows_zero, also >> had to ifdef some code out of the Windows Structured Exception filter. >> It was surprisingly minimal, but the downside is that Windows/Zero >> then only compiled with gcc. VC had an additional hurdle to jump >> through: On Zero, since there are no registers, register arrays in >> certain classes became zero sized arrays, a GNU extension that VC will >> never accept under any circumstances. >> >> I started work again recently to get Zero working with VC. Just 2 days >> ago, this successfully compiled with VC, albeit with >> --disable-warnings-as-errors. The code is available at >> https://github.com/TheShermanTanker/jdk/commits/experimental for >> anyone curious, under "Windows/Zero Port". Disclaimer: I do not know >> whether the code is 100% correct, I may have implemented it wrongly. >> The remaining warnings left over can be seen below this mail. Note >> that only the release configuration was tested, fastdebug has not been >> compiled yet. >> >> I'd like to float the idea of supporting Windows/Zero properly. >> Ideally, Zero should run on any platform, so it not running on Windows >> would be surprising, but past that, the Java Zero VM is extremely >> small on Windows at just 5MB (Even smaller than the Python >> Interpreter!), so it could be useful on devices where a small Java VM >> is desired. More importantly, this could (Although I am not fully >> certain) open the door to running the latest Java on 32 bit Windows >> devices again, ever since all the x86 32 bit ports were removed, >> leaving Zero as the only way to execute Java on 32 bit x86. This may >> (or may not) help those who cannot get a 64 bit device or one that's >> running Linux, I haven't checked yet. >> >> I also crashed the VM on purpose to get a hserr file which contains VM >> information, this can be seen below. This was quite interesting, as >> I've never actually seen Zero crash before! >> >> Thoughts? >> >> best regards, >> Julian >> >> # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd1518139f, >> pid=335696, tid=337452 >> # >> # JRE version: Java Runtime Environment (25.0) (build 25-internal) >> # Java VM: Java HotSpot 64-Bit Zero VM (25-internal, interpreted mode, >> sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64) >> # Problematic frame: >> # C [Crash.dll+0x139f] >> # >> # No core dump will be written. Minidumps are not enabled by default >> on client versions of Windows >> # >> # If you would like to submit a bug report, please visit: >> # https://bugreport.java.com/bugreport/crash.jsp >> # The crash happened outside the Java Virtual Machine in native code. >> # See problematic frame for where to report the bug. >> # >> >> --------------- S U M M A R Y ------------ >> >> Command Line: --enable-preview Crash >> >> Host: AMD Ryzen 9 7845HX with Radeon Graphics , 24 cores, 15G, >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) >> Time: Sun Apr 20 03:44:08 2025 Malay Peninsula Standard Time elapsed >> time: 0.291582 seconds (0d 0h 0m 0s) >> >> --------------- T H R E A D --------------- >> >> Current thread (0x00000268e57a3d20): JavaThread "main" >> [_thread_in_native, id=337452, >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] >> >> Stack: [0x000000ae07a00000,0x000000ae07b00000], >> sp=0x000000ae07a842a0, free space=528k >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >> C [Crash.dll+0x139f] (no source info available) >> C [libffi-8.dll+0x4cc1] (no source info available) >> C [libffi-8.dll+0x48df] (no source info available) >> C [libffi-8.dll+0x4aa2] (no source info available) >> V [jvm.dll+0x426645] ZeroInterpreter::native_entry+0x455 >> (zeroInterpreter_zero.cpp:444) >> V [jvm.dll+0x425f47] ZeroInterpreter::main_loop+0x127 >> (zeroInterpreter_zero.cpp:227) >> V [jvm.dll+0x425d96] ZeroInterpreter::normal_entry+0x36 >> (zeroInterpreter_zero.cpp:115) >> V [jvm.dll+0x3b156d] StubGenerator::call_stub+0x1bd >> (stubGenerator_zero.cpp:84) >> V [jvm.dll+0x1acbfd] JavaCalls::call_helper+0x48d (javaCalls.cpp:424) >> V [jvm.dll+0x2e4c80] os::os_exception_wrapper+0x20 (os_windows_zero.cpp:51) >> V [jvm.dll+0x1c472a] jni_invoke_nonstatic+0x32a (jni.cpp:950) >> V [jvm.dll+0x1c8ea2] jni_CallVoidMethod+0x142 (jni.cpp:1307) >> C [jli.dll+0x510f] JavaMain+0x7d3 (java.c:645) >> C [ucrtbase.dll+0x37b0] (no source info available) >> C [KERNEL32.DLL+0x2e8d7] (no source info available) >> C [ntdll.dll+0xb14fc] (no source info available) >> >> Java frames: >> 0x000000ae07aff8f0: unboxed parameter[1] = 0x000000ae07aff9a0 >> 0x000000ae07aff8f8: parameter[0] (JNIEnv) = 0x000000ae07a84410 >> 0x000000ae07aff900: parameter[1] (this) = 0x000000ae07aff8f0 >> 0x000000ae07aff908: istate->_thread = 0x00000268e57a3d20 >> 0x000000ae07aff910: istate->_bcp = 0x0000000000000000 >> 0x000000ae07aff918: istate->_locals = 0x000000ae07aff9a0 >> 0x000000ae07aff920: istate->_constants = 0x00000268c14003a8 >> 0x000000ae07aff928: istate->_method = Crash.crash()V >> 0x000000ae07aff930: istate->_mirror = 0x000000071ba1cb90 >> 0x000000ae07aff938: istate->_stack = 0x000000ae07aff900 >> 0x000000ae07aff940: istate->_msg = 0x0000026800000002 >> 0x000000ae07aff948: istate->_result = 0x0000000000000000 >> 0x000000ae07aff950: (istate->_result) = 0x000000ae00000003 >> 0x000000ae07aff958: (istate->_result) = 0x0000000000000000 >> 0x000000ae07aff960: istate->_prev_link = 0x0000000000000000 >> 0x000000ae07aff968: istate->_oop_temp = 0x0000000000000000 >> 0x000000ae07aff970: istate->_stack_base = 0x000000ae07aff908 >> 0x000000ae07aff978: istate->_stack_limit = 0x000000ae07aff900 >> 0x000000ae07aff980: istate->_monitor_base = 0x000000ae07aff908 >> 0x000000ae07aff988: istate->_self_link = 0x000000ae07aff908 >> 0x000000ae07aff990: frame_type = INTERPRETER_FRAME >> 0x000000ae07aff998: next_frame = 0x000000ae07affa38 >> >> 0x000000ae07aff9a0: local[0] = 0x000000071ba1d940 >> 0x000000ae07aff9a8: istate->_thread = 0x00000268e57a3d20 >> 0x000000ae07aff9b0: istate->_bcp = 0x00000268c14002de (bci 6) >> 0x000000ae07aff9b8: istate->_locals = 0x000000ae07affa40 >> 0x000000ae07aff9c0: istate->_constants = 0x00000268c14003a8 >> 0x000000ae07aff9c8: istate->_method = Crash.main()V >> 0x000000ae07aff9d0: istate->_mirror = 0x000000071ba1cb90 >> 0x000000ae07aff9d8: istate->_stack = 0x000000ae07aff998 >> 0x000000ae07aff9e0: istate->_msg = 0x0000026800000008 >> 0x000000ae07aff9e8: istate->_result = 0x00000268c1400238 >> 0x000000ae07aff9f0: (istate->_result) = 0x00000268f1e90458 >> 0x000000ae07aff9f8: (istate->_result) = 0x0000000000000003 >> 0x000000ae07affa00: istate->_prev_link = 0x0000000000000000 >> 0x000000ae07affa08: istate->_oop_temp = 0x0000000000000000 >> 0x000000ae07affa10: istate->_stack_base = 0x000000ae07aff9a8 >> 0x000000ae07affa18: istate->_stack_limit = 0x000000ae07aff990 >> 0x000000ae07affa20: istate->_monitor_base = 0x000000ae07aff9a8 >> 0x000000ae07affa28: istate->_self_link = 0x000000ae07aff9a8 >> 0x000000ae07affa30: frame_type = INTERPRETER_FRAME >> 0x000000ae07affa38: next_frame = 0x000000ae07affa58 >> >> 0x000000ae07affa40: local[0] = 0x000000071ba1d940 >> 0x000000ae07affa48: call_wrapper = 0x000000ae07affaf0 >> 0x000000ae07affa50: frame_type = ENTRY_FRAME >> 0x000000ae07affa58: next_frame = 0x0000000000000000 >> >> >> siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address >> 0x0000000000000000 >> >> >> No context information. >> >> Register to memory mapping: >> >> No register info. >> >> Top of Stack: (sp=0x000000ae07a842a0) >> 0x000000ae07a842a0: 00000000000003d8 0000000000000000 ................ >> 0x000000ae07a842b0: 0000000000000000 00007ffd16d748df .........H...... >> 0x000000ae07a842c0: 000002688046f350 0000000000000000 P.F.h........... >> 0x000000ae07a842d0: 000000ae07a84300 00007ffd16d74cc1 .C.......L...... >> 0x000000ae07a842e0: 00000268e57a4028 000000ae07aff9a0 (@z.h........... >> 0x000000ae07a842f0: 0000000000000001 0000000000000050 ........P....... >> 0x000000ae07a84300: 000000ae07a84350 00007ffd16d748df PC.......H...... >> 0x000000ae07a84310: 00007ffd15181380 0000000000000000 ................ >> 0x000000ae07a84320: 000000ae07a84400 0000000000000000 .D.............. >> 0x000000ae07a84330: 0000000000000001 0000000000000000 ................ >> 0x000000ae07a84340: 00001664b4a8ce49 111f221225371f8f I...d.....7%.".. >> 0x000000ae07a84350: 00000268802416f0 00000268e57a3d20 ..$.h... =z.h... >> 0x000000ae07a84360: 00000268c1400238 000000ae07aff908 8. at .h........... >> 0x000000ae07a84370: 000000ae07aff9a0 000000ae07aff998 ................ >> 0x000000ae07a84380: 00000268f1e98710 0000000000000000 ....h........... >> 0x000000ae07a84390: 000000ae07a84440 00007ffd16d74aa2 @D.......J...... >> 0x000000ae07a843a0: 0000000000000000 0000000000000001 ................ >> 0x000000ae07a843b0: 0000000000000000 000000ae07aff998 ................ >> 0x000000ae07a843c0: 0000000000000000 0000000000000000 ................ >> 0x000000ae07a843d0: 000000ae07a84440 00007ffceb326645 @D......Ef2..... >> 0x000000ae07a843e0: 00007ffceb482058 00000268e57a3d20 X H..... =z.h... >> 0x000000ae07a843f0: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... >> 0x000000ae07a84400: 000000ae07aff990 000000ae07aff8f8 ................ >> 0x000000ae07a84410: 00000268e57a4028 0000000000000000 (@z.h........... >> 0x000000ae07a84420: 00007ffd15181380 0000000000000000 ................ >> 0x000000ae07a84430: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... >> 0x000000ae07a84440: 0000000000000001 0000000000000000 ................ >> 0x000000ae07a84450: 0000000000000000 0000000000000000 ................ >> 0x000000ae07a84460: 0000000000000000 000000ae07affa38 ........8....... >> 0x000000ae07a84470: 00000268c14002e8 00007ffceb325f47 .. at .h...G_2..... >> 0x000000ae07a84480: 00000268e57a3d20 00000268e57a3d20 =z.h... =z.h... >> 0x000000ae07a84490: 000000ae00084b70 0000000000000000 pK.............. >> >> Instructions: (pc=0x00007ffd1518139f) >> 0x00007ffd1518129f: 00 e8 bb 0e 00 00 41 89 c4 83 fb 03 75 86 e9 5a >> 0x00007ffd151812af: ff ff ff 66 0f 1f 44 00 00 83 fb 01 0f 85 6f ff >> 0x00007ffd151812bf: ff ff 49 89 f8 31 d2 48 89 f1 e8 42 fd ff ff e9 >> 0x00007ffd151812cf: 5d ff ff ff 0f 1f 44 00 00 e8 93 01 00 00 49 89 >> 0x00007ffd151812df: f8 ba 01 00 00 00 48 89 f1 e8 73 0e 00 00 41 89 >> 0x00007ffd151812ef: c4 85 c0 0f 85 3b ff ff ff 49 89 f8 31 d2 48 89 >> 0x00007ffd151812ff: f1 e8 5b 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 3e >> 0x00007ffd1518130f: 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 f1 fc ff ff >> 0x00007ffd1518131f: e9 0f ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 >> 0x00007ffd1518132f: 90 48 8b 05 b9 82 00 00 c7 00 00 00 00 00 e9 8e >> 0x00007ffd1518133f: fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f >> 0x00007ffd1518134f: 00 48 89 ca 48 8d 0d a6 ac 00 00 e9 f9 62 00 00 >> 0x00007ffd1518135f: 90 48 8d 0d 09 00 00 00 e9 e4 ff ff ff 0f 1f 40 >> 0x00007ffd1518136f: 00 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 >> 0x00007ffd1518137f: 90 55 48 89 e5 48 83 ec 30 48 c7 45 f8 00 00 00 >> 0x00007ffd1518138f: 00 48 8b 45 f8 48 8b 45 f8 48 8d 0d 61 7c 00 00 >> =>0x00007ffd1518139f: 8b 10 e8 ca 0d 00 00 48 8d 0d 56 7c 00 00 48 83 >> 0x00007ffd151813af: c4 30 5d e9 59 63 00 00 90 90 90 90 90 90 90 90 >> 0x00007ffd151813bf: 90 48 83 ec 28 48 8b 05 45 6c 00 00 48 8b 00 48 >> 0x00007ffd151813cf: 85 c0 74 22 0f 1f 44 00 00 ff d0 48 8b 05 2f 6c >> 0x00007ffd151813df: 00 00 48 8d 50 08 48 8b 40 08 48 89 15 20 6c 00 >> 0x00007ffd151813ef: 00 48 85 c0 75 e3 48 83 c4 28 c3 66 0f 1f 44 00 >> 0x00007ffd151813ff: 00 56 53 48 83 ec 28 48 8b 15 83 81 00 00 48 8b >> 0x00007ffd1518140f: 02 89 c1 83 f8 ff 74 39 85 c9 74 20 89 c8 83 e9 >> 0x00007ffd1518141f: 01 48 8d 1c c2 48 29 c8 48 8d 74 c2 f8 0f 1f 40 >> 0x00007ffd1518142f: 00 ff 13 48 83 eb 08 48 39 f3 75 f5 48 8d 0d 7e >> 0x00007ffd1518143f: ff ff ff 48 83 c4 28 5b 5e e9 03 ff ff ff 0f 1f >> 0x00007ffd1518144f: 00 31 c0 66 0f 1f 44 00 00 44 8d 40 01 89 c1 4a >> 0x00007ffd1518145f: 83 3c c2 00 4c 89 c0 75 f0 eb ad 66 0f 1f 44 00 >> 0x00007ffd1518146f: 00 8b 05 aa ab 00 00 85 c0 74 06 c3 0f 1f 44 00 >> 0x00007ffd1518147f: 00 c7 05 96 ab 00 00 01 00 00 00 e9 71 ff ff ff >> 0x00007ffd1518148f: 90 83 fa 03 74 0b 85 d2 74 07 c3 66 0f 1f 44 00 >> >> >> Stack slot to memory mapping: >> >> stack at sp + 0 slots: 0x00000000000003d8 is an unknown value >> stack at sp + 1 slots: 0x0 is null >> stack at sp + 2 slots: 0x0 is null >> stack at sp + 3 slots: 0x00007ffd16d748df libffi-8.dll >> stack at sp + 4 slots: {method} {0x000002688046f358} 'loadLibrary' >> '(Ljava/lang/Class;Ljava/lang/String;)Ljdk/internal/loader/NativeLibrary;' >> in 'java/lang/ClassLoader' >> stack at sp + 5 slots: 0x0 is null >> stack at sp + 6 slots: 0x000000ae07a84300 is pointing into the stack >> for thread: 0x00000268e57a3d20 >> stack at sp + 7 slots: 0x00007ffd16d74cc1 libffi-8.dll >> >> Lock stack of current Java thread (top to bottom): >> >> >> --------------- P R O C E S S --------------- >> >> Threads class SMR info: >> _java_thread_list=0x00000268fc0d5850, length=9, elements={ >> 0x00000268e57a3d20, 0x00000268fc08cfc0, 0x00000268fc08d5f0, 0x00000268fc091710, >> 0x00000268fc092140, 0x00000268fc0936e0, 0x00000268fc09d2a0, 0x00000268fc0d8ec0, >> 0x00000268fc0de6e0 >> } >> >> Java Threads: ( => current thread ) >> =>0x00000268e57a3d20 JavaThread "main" >> [_thread_in_native, id=337452, >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] >> 0x00000268fc08cfc0 JavaThread "Reference Handler" daemon >> [_thread_blocked, id=337356, >> stack(0x000000ae08200000,0x000000ae08300000) (1024K)] >> 0x00000268fc08d5f0 JavaThread "Finalizer" daemon >> [_thread_blocked, id=338708, >> stack(0x000000ae08300000,0x000000ae08400000) (1024K)] >> 0x00000268fc091710 JavaThread "Signal Dispatcher" daemon >> [_thread_blocked, id=338204, >> stack(0x000000ae08400000,0x000000ae08500000) (1024K)] >> 0x00000268fc092140 JavaThread "Attach Listener" daemon >> [_thread_blocked, id=338748, >> stack(0x000000ae08500000,0x000000ae08600000) (1024K)] >> 0x00000268fc0936e0 JavaThread "Service Thread" daemon >> [_thread_blocked, id=337172, >> stack(0x000000ae08600000,0x000000ae08700000) (1024K)] >> 0x00000268fc09d2a0 JavaThread "Monitor Deflation Thread" daemon >> [_thread_blocked, id=337312, >> stack(0x000000ae08700000,0x000000ae08800000) (1024K)] >> 0x00000268fc0d8ec0 JavaThread "Notification Thread" daemon >> [_thread_blocked, id=337560, >> stack(0x000000ae08800000,0x000000ae08900000) (1024K)] >> 0x00000268fc0de6e0 JavaThread "Common-Cleaner" daemon >> [_thread_blocked, id=338324, >> stack(0x000000ae08900000,0x000000ae08a00000) (1024K)] >> Total: 9 >> >> Other Threads: >> 0x00000268fc07c960 VMThread "VM Thread" >> [id=337424, stack(0x000000ae08100000,0x000000ae08200000) (1024K)] >> 0x00000268fbf41360 WatcherThread "VM Periodic Task Thread" >> [id=333244, stack(0x000000ae08000000,0x000000ae08100000) (1024K)] >> 0x00000268e7d7d550 WorkerThread "GC Thread#0" >> [id=336784, stack(0x000000ae07b00000,0x000000ae07c00000) (1024K)] >> 0x00000268e7d951c0 ConcurrentGCThread "G1 Main Marker" >> [id=338660, stack(0x000000ae07c00000,0x000000ae07d00000) (1024K)] >> 0x00000268e7d96850 WorkerThread "G1 Conc#0" >> [id=19564, stack(0x000000ae07d00000,0x000000ae07e00000) (1024K)] >> 0x00000268fbf39000 ConcurrentGCThread "G1 Refine#0" >> [id=217884, stack(0x000000ae07e00000,0x000000ae07f00000) (1024K)] >> 0x00000268fbf39780 ConcurrentGCThread "G1 Service" >> [id=338408, stack(0x000000ae07f00000,0x000000ae08000000) (1024K)] >> Total: 7 >> >> Threads with active compile tasks: >> Total: 0 >> >> VM state: not at safepoint (normal execution) >> >> VM Mutex/Monitor currently owned by a thread: None >> >> Heap address: 0x000000070c800000, size: 3896 MB, Compressed Oops mode: >> Zero based, Oop shift amount: 3 >> >> CDS archive(s) mapped at: >> [0x0000026880000000-0x0000026880d30000-0x0000026880d30000), size >> 13828096, SharedBaseAddress: 0x0000026880000000, >> ArchiveRelocationMode: 1. >> Compressed class space mapped at: >> 0x0000026881000000-0x00000268c1000000, reserved size: 1073741824 >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 >> Narrow klass pointer bits 32, Max shift 3 >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 bytes) >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 bytes) >> Klass ID Range: [65536 - 1090519033) (1090453497) >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) >> >> GC Precious Log: >> CardTable entry size: 512 >> Card Set container configuration: InlinePtr #cards 4 size 8 Array Of >> Cards #cards 16 size 48 Howl #buckets 8 coarsen threshold 3686 Howl >> Bitmap #cards 512 size 80 coarsen threshold 460 Card regions per heap >> region 1 cards per card region 4096 >> CPUs: 24 total, 24 available >> Memory: 15578M >> Large Page Support: Disabled >> NUMA Support: Disabled >> Compressed Oops: Enabled (Zero based) >> Heap Region Size: 2M >> Heap Min Capacity: 8M >> Heap Initial Capacity: 244M >> Heap Max Capacity: 3896M >> Pre-touch: Disabled >> Parallel Workers: 18 >> Concurrent Workers: 5 >> Concurrent Refinement Workers: 18 >> Periodic GC: Disabled >> >> Heap: >> garbage-first heap total reserved 3989504K, committed 251904K, used >> 1136K [0x000000070c800000, 0x0000000800000000) >> region size 2048K, 1 young (2048K), 0 survivors (0K) >> Metaspace used 21K, committed 256K, reserved 1114112K >> class space used 6K, committed 128K, reserved 1048576K >> >> Heap Regions: E=young(eden), S=young(survivor), O=old, >> HS=humongous(starts), HC=humongous(continues), CS=collection set, >> F=free, TAMS=top-at-mark-start, PB=parsable bottom >> | 0|0x000000070c800000, 0x000000070c800000, 0x000000070ca00000| 0%| >> F| |TAMS 0x000000070c800000| PB 0x000000070c800000| Untracked | 0 >> | 1|0x000000070ca00000, 0x000000070ca00000, 0x000000070cc00000| 0%| >> F| |TAMS 0x000000070ca00000| PB 0x000000070ca00000| Untracked | 0 >> | 2|0x000000070cc00000, 0x000000070cc00000, 0x000000070ce00000| 0%| >> F| |TAMS 0x000000070cc00000| PB 0x000000070cc00000| Untracked | 0 >> | 3|0x000000070ce00000, 0x000000070ce00000, 0x000000070d000000| 0%| >> F| |TAMS 0x000000070ce00000| PB 0x000000070ce00000| Untracked | 0 >> | 4|0x000000070d000000, 0x000000070d000000, 0x000000070d200000| 0%| >> F| |TAMS 0x000000070d000000| PB 0x000000070d000000| Untracked | 0 >> | 5|0x000000070d200000, 0x000000070d200000, 0x000000070d400000| 0%| >> F| |TAMS 0x000000070d200000| PB 0x000000070d200000| Untracked | 0 >> | 6|0x000000070d400000, 0x000000070d400000, 0x000000070d600000| 0%| >> F| |TAMS 0x000000070d400000| PB 0x000000070d400000| Untracked | 0 >> | 7|0x000000070d600000, 0x000000070d600000, 0x000000070d800000| 0%| >> F| |TAMS 0x000000070d600000| PB 0x000000070d600000| Untracked | 0 >> | 8|0x000000070d800000, 0x000000070d800000, 0x000000070da00000| 0%| >> F| |TAMS 0x000000070d800000| PB 0x000000070d800000| Untracked | 0 >> | 9|0x000000070da00000, 0x000000070da00000, 0x000000070dc00000| 0%| >> F| |TAMS 0x000000070da00000| PB 0x000000070da00000| Untracked | 0 >> | 10|0x000000070dc00000, 0x000000070dc00000, 0x000000070de00000| 0%| >> F| |TAMS 0x000000070dc00000| PB 0x000000070dc00000| Untracked | 0 >> | 11|0x000000070de00000, 0x000000070de00000, 0x000000070e000000| 0%| >> F| |TAMS 0x000000070de00000| PB 0x000000070de00000| Untracked | 0 >> | 12|0x000000070e000000, 0x000000070e000000, 0x000000070e200000| 0%| >> F| |TAMS 0x000000070e000000| PB 0x000000070e000000| Untracked | 0 >> | 13|0x000000070e200000, 0x000000070e200000, 0x000000070e400000| 0%| >> F| |TAMS 0x000000070e200000| PB 0x000000070e200000| Untracked | 0 >> | 14|0x000000070e400000, 0x000000070e400000, 0x000000070e600000| 0%| >> F| |TAMS 0x000000070e400000| PB 0x000000070e400000| Untracked | 0 >> | 15|0x000000070e600000, 0x000000070e600000, 0x000000070e800000| 0%| >> F| |TAMS 0x000000070e600000| PB 0x000000070e600000| Untracked | 0 >> | 16|0x000000070e800000, 0x000000070e800000, 0x000000070ea00000| 0%| >> F| |TAMS 0x000000070e800000| PB 0x000000070e800000| Untracked | 0 >> | 17|0x000000070ea00000, 0x000000070ea00000, 0x000000070ec00000| 0%| >> F| |TAMS 0x000000070ea00000| PB 0x000000070ea00000| Untracked | 0 >> | 18|0x000000070ec00000, 0x000000070ec00000, 0x000000070ee00000| 0%| >> F| |TAMS 0x000000070ec00000| PB 0x000000070ec00000| Untracked | 0 >> | 19|0x000000070ee00000, 0x000000070ee00000, 0x000000070f000000| 0%| >> F| |TAMS 0x000000070ee00000| PB 0x000000070ee00000| Untracked | 0 >> | 20|0x000000070f000000, 0x000000070f000000, 0x000000070f200000| 0%| >> F| |TAMS 0x000000070f000000| PB 0x000000070f000000| Untracked | 0 >> | 21|0x000000070f200000, 0x000000070f200000, 0x000000070f400000| 0%| >> F| |TAMS 0x000000070f200000| PB 0x000000070f200000| Untracked | 0 >> | 22|0x000000070f400000, 0x000000070f400000, 0x000000070f600000| 0%| >> F| |TAMS 0x000000070f400000| PB 0x000000070f400000| Untracked | 0 >> | 23|0x000000070f600000, 0x000000070f600000, 0x000000070f800000| 0%| >> F| |TAMS 0x000000070f600000| PB 0x000000070f600000| Untracked | 0 >> | 24|0x000000070f800000, 0x000000070f800000, 0x000000070fa00000| 0%| >> F| |TAMS 0x000000070f800000| PB 0x000000070f800000| Untracked | 0 >> | 25|0x000000070fa00000, 0x000000070fa00000, 0x000000070fc00000| 0%| >> F| |TAMS 0x000000070fa00000| PB 0x000000070fa00000| Untracked | 0 >> | 26|0x000000070fc00000, 0x000000070fc00000, 0x000000070fe00000| 0%| >> F| |TAMS 0x000000070fc00000| PB 0x000000070fc00000| Untracked | 0 >> | 27|0x000000070fe00000, 0x000000070fe00000, 0x0000000710000000| 0%| >> F| |TAMS 0x000000070fe00000| PB 0x000000070fe00000| Untracked | 0 >> | 28|0x0000000710000000, 0x0000000710000000, 0x0000000710200000| 0%| >> F| |TAMS 0x0000000710000000| PB 0x0000000710000000| Untracked | 0 >> | 29|0x0000000710200000, 0x0000000710200000, 0x0000000710400000| 0%| >> F| |TAMS 0x0000000710200000| PB 0x0000000710200000| Untracked | 0 >> | 30|0x0000000710400000, 0x0000000710400000, 0x0000000710600000| 0%| >> F| |TAMS 0x0000000710400000| PB 0x0000000710400000| Untracked | 0 >> | 31|0x0000000710600000, 0x0000000710600000, 0x0000000710800000| 0%| >> F| |TAMS 0x0000000710600000| PB 0x0000000710600000| Untracked | 0 >> | 32|0x0000000710800000, 0x0000000710800000, 0x0000000710a00000| 0%| >> F| |TAMS 0x0000000710800000| PB 0x0000000710800000| Untracked | 0 >> | 33|0x0000000710a00000, 0x0000000710a00000, 0x0000000710c00000| 0%| >> F| |TAMS 0x0000000710a00000| PB 0x0000000710a00000| Untracked | 0 >> | 34|0x0000000710c00000, 0x0000000710c00000, 0x0000000710e00000| 0%| >> F| |TAMS 0x0000000710c00000| PB 0x0000000710c00000| Untracked | 0 >> | 35|0x0000000710e00000, 0x0000000710e00000, 0x0000000711000000| 0%| >> F| |TAMS 0x0000000710e00000| PB 0x0000000710e00000| Untracked | 0 >> | 36|0x0000000711000000, 0x0000000711000000, 0x0000000711200000| 0%| >> F| |TAMS 0x0000000711000000| PB 0x0000000711000000| Untracked | 0 >> | 37|0x0000000711200000, 0x0000000711200000, 0x0000000711400000| 0%| >> F| |TAMS 0x0000000711200000| PB 0x0000000711200000| Untracked | 0 >> | 38|0x0000000711400000, 0x0000000711400000, 0x0000000711600000| 0%| >> F| |TAMS 0x0000000711400000| PB 0x0000000711400000| Untracked | 0 >> | 39|0x0000000711600000, 0x0000000711600000, 0x0000000711800000| 0%| >> F| |TAMS 0x0000000711600000| PB 0x0000000711600000| Untracked | 0 >> | 40|0x0000000711800000, 0x0000000711800000, 0x0000000711a00000| 0%| >> F| |TAMS 0x0000000711800000| PB 0x0000000711800000| Untracked | 0 >> | 41|0x0000000711a00000, 0x0000000711a00000, 0x0000000711c00000| 0%| >> F| |TAMS 0x0000000711a00000| PB 0x0000000711a00000| Untracked | 0 >> | 42|0x0000000711c00000, 0x0000000711c00000, 0x0000000711e00000| 0%| >> F| |TAMS 0x0000000711c00000| PB 0x0000000711c00000| Untracked | 0 >> | 43|0x0000000711e00000, 0x0000000711e00000, 0x0000000712000000| 0%| >> F| |TAMS 0x0000000711e00000| PB 0x0000000711e00000| Untracked | 0 >> | 44|0x0000000712000000, 0x0000000712000000, 0x0000000712200000| 0%| >> F| |TAMS 0x0000000712000000| PB 0x0000000712000000| Untracked | 0 >> | 45|0x0000000712200000, 0x0000000712200000, 0x0000000712400000| 0%| >> F| |TAMS 0x0000000712200000| PB 0x0000000712200000| Untracked | 0 >> | 46|0x0000000712400000, 0x0000000712400000, 0x0000000712600000| 0%| >> F| |TAMS 0x0000000712400000| PB 0x0000000712400000| Untracked | 0 >> | 47|0x0000000712600000, 0x0000000712600000, 0x0000000712800000| 0%| >> F| |TAMS 0x0000000712600000| PB 0x0000000712600000| Untracked | 0 >> | 48|0x0000000712800000, 0x0000000712800000, 0x0000000712a00000| 0%| >> F| |TAMS 0x0000000712800000| PB 0x0000000712800000| Untracked | 0 >> | 49|0x0000000712a00000, 0x0000000712a00000, 0x0000000712c00000| 0%| >> F| |TAMS 0x0000000712a00000| PB 0x0000000712a00000| Untracked | 0 >> | 50|0x0000000712c00000, 0x0000000712c00000, 0x0000000712e00000| 0%| >> F| |TAMS 0x0000000712c00000| PB 0x0000000712c00000| Untracked | 0 >> | 51|0x0000000712e00000, 0x0000000712e00000, 0x0000000713000000| 0%| >> F| |TAMS 0x0000000712e00000| PB 0x0000000712e00000| Untracked | 0 >> | 52|0x0000000713000000, 0x0000000713000000, 0x0000000713200000| 0%| >> F| |TAMS 0x0000000713000000| PB 0x0000000713000000| Untracked | 0 >> | 53|0x0000000713200000, 0x0000000713200000, 0x0000000713400000| 0%| >> F| |TAMS 0x0000000713200000| PB 0x0000000713200000| Untracked | 0 >> | 54|0x0000000713400000, 0x0000000713400000, 0x0000000713600000| 0%| >> F| |TAMS 0x0000000713400000| PB 0x0000000713400000| Untracked | 0 >> | 55|0x0000000713600000, 0x0000000713600000, 0x0000000713800000| 0%| >> F| |TAMS 0x0000000713600000| PB 0x0000000713600000| Untracked | 0 >> | 56|0x0000000713800000, 0x0000000713800000, 0x0000000713a00000| 0%| >> F| |TAMS 0x0000000713800000| PB 0x0000000713800000| Untracked | 0 >> | 57|0x0000000713a00000, 0x0000000713a00000, 0x0000000713c00000| 0%| >> F| |TAMS 0x0000000713a00000| PB 0x0000000713a00000| Untracked | 0 >> | 58|0x0000000713c00000, 0x0000000713c00000, 0x0000000713e00000| 0%| >> F| |TAMS 0x0000000713c00000| PB 0x0000000713c00000| Untracked | 0 >> | 59|0x0000000713e00000, 0x0000000713e00000, 0x0000000714000000| 0%| >> F| |TAMS 0x0000000713e00000| PB 0x0000000713e00000| Untracked | 0 >> | 60|0x0000000714000000, 0x0000000714000000, 0x0000000714200000| 0%| >> F| |TAMS 0x0000000714000000| PB 0x0000000714000000| Untracked | 0 >> | 61|0x0000000714200000, 0x0000000714200000, 0x0000000714400000| 0%| >> F| |TAMS 0x0000000714200000| PB 0x0000000714200000| Untracked | 0 >> | 62|0x0000000714400000, 0x0000000714400000, 0x0000000714600000| 0%| >> F| |TAMS 0x0000000714400000| PB 0x0000000714400000| Untracked | 0 >> | 63|0x0000000714600000, 0x0000000714600000, 0x0000000714800000| 0%| >> F| |TAMS 0x0000000714600000| PB 0x0000000714600000| Untracked | 0 >> | 64|0x0000000714800000, 0x0000000714800000, 0x0000000714a00000| 0%| >> F| |TAMS 0x0000000714800000| PB 0x0000000714800000| Untracked | 0 >> | 65|0x0000000714a00000, 0x0000000714a00000, 0x0000000714c00000| 0%| >> F| |TAMS 0x0000000714a00000| PB 0x0000000714a00000| Untracked | 0 >> | 66|0x0000000714c00000, 0x0000000714c00000, 0x0000000714e00000| 0%| >> F| |TAMS 0x0000000714c00000| PB 0x0000000714c00000| Untracked | 0 >> | 67|0x0000000714e00000, 0x0000000714e00000, 0x0000000715000000| 0%| >> F| |TAMS 0x0000000714e00000| PB 0x0000000714e00000| Untracked | 0 >> | 68|0x0000000715000000, 0x0000000715000000, 0x0000000715200000| 0%| >> F| |TAMS 0x0000000715000000| PB 0x0000000715000000| Untracked | 0 >> | 69|0x0000000715200000, 0x0000000715200000, 0x0000000715400000| 0%| >> F| |TAMS 0x0000000715200000| PB 0x0000000715200000| Untracked | 0 >> | 70|0x0000000715400000, 0x0000000715400000, 0x0000000715600000| 0%| >> F| |TAMS 0x0000000715400000| PB 0x0000000715400000| Untracked | 0 >> | 71|0x0000000715600000, 0x0000000715600000, 0x0000000715800000| 0%| >> F| |TAMS 0x0000000715600000| PB 0x0000000715600000| Untracked | 0 >> | 72|0x0000000715800000, 0x0000000715800000, 0x0000000715a00000| 0%| >> F| |TAMS 0x0000000715800000| PB 0x0000000715800000| Untracked | 0 >> | 73|0x0000000715a00000, 0x0000000715a00000, 0x0000000715c00000| 0%| >> F| |TAMS 0x0000000715a00000| PB 0x0000000715a00000| Untracked | 0 >> | 74|0x0000000715c00000, 0x0000000715c00000, 0x0000000715e00000| 0%| >> F| |TAMS 0x0000000715c00000| PB 0x0000000715c00000| Untracked | 0 >> | 75|0x0000000715e00000, 0x0000000715e00000, 0x0000000716000000| 0%| >> F| |TAMS 0x0000000715e00000| PB 0x0000000715e00000| Untracked | 0 >> | 76|0x0000000716000000, 0x0000000716000000, 0x0000000716200000| 0%| >> F| |TAMS 0x0000000716000000| PB 0x0000000716000000| Untracked | 0 >> | 77|0x0000000716200000, 0x0000000716200000, 0x0000000716400000| 0%| >> F| |TAMS 0x0000000716200000| PB 0x0000000716200000| Untracked | 0 >> | 78|0x0000000716400000, 0x0000000716400000, 0x0000000716600000| 0%| >> F| |TAMS 0x0000000716400000| PB 0x0000000716400000| Untracked | 0 >> | 79|0x0000000716600000, 0x0000000716600000, 0x0000000716800000| 0%| >> F| |TAMS 0x0000000716600000| PB 0x0000000716600000| Untracked | 0 >> | 80|0x0000000716800000, 0x0000000716800000, 0x0000000716a00000| 0%| >> F| |TAMS 0x0000000716800000| PB 0x0000000716800000| Untracked | 0 >> | 81|0x0000000716a00000, 0x0000000716a00000, 0x0000000716c00000| 0%| >> F| |TAMS 0x0000000716a00000| PB 0x0000000716a00000| Untracked | 0 >> | 82|0x0000000716c00000, 0x0000000716c00000, 0x0000000716e00000| 0%| >> F| |TAMS 0x0000000716c00000| PB 0x0000000716c00000| Untracked | 0 >> | 83|0x0000000716e00000, 0x0000000716e00000, 0x0000000717000000| 0%| >> F| |TAMS 0x0000000716e00000| PB 0x0000000716e00000| Untracked | 0 >> | 84|0x0000000717000000, 0x0000000717000000, 0x0000000717200000| 0%| >> F| |TAMS 0x0000000717000000| PB 0x0000000717000000| Untracked | 0 >> | 85|0x0000000717200000, 0x0000000717200000, 0x0000000717400000| 0%| >> F| |TAMS 0x0000000717200000| PB 0x0000000717200000| Untracked | 0 >> | 86|0x0000000717400000, 0x0000000717400000, 0x0000000717600000| 0%| >> F| |TAMS 0x0000000717400000| PB 0x0000000717400000| Untracked | 0 >> | 87|0x0000000717600000, 0x0000000717600000, 0x0000000717800000| 0%| >> F| |TAMS 0x0000000717600000| PB 0x0000000717600000| Untracked | 0 >> | 88|0x0000000717800000, 0x0000000717800000, 0x0000000717a00000| 0%| >> F| |TAMS 0x0000000717800000| PB 0x0000000717800000| Untracked | 0 >> | 89|0x0000000717a00000, 0x0000000717a00000, 0x0000000717c00000| 0%| >> F| |TAMS 0x0000000717a00000| PB 0x0000000717a00000| Untracked | 0 >> | 90|0x0000000717c00000, 0x0000000717c00000, 0x0000000717e00000| 0%| >> F| |TAMS 0x0000000717c00000| PB 0x0000000717c00000| Untracked | 0 >> | 91|0x0000000717e00000, 0x0000000717e00000, 0x0000000718000000| 0%| >> F| |TAMS 0x0000000717e00000| PB 0x0000000717e00000| Untracked | 0 >> | 92|0x0000000718000000, 0x0000000718000000, 0x0000000718200000| 0%| >> F| |TAMS 0x0000000718000000| PB 0x0000000718000000| Untracked | 0 >> | 93|0x0000000718200000, 0x0000000718200000, 0x0000000718400000| 0%| >> F| |TAMS 0x0000000718200000| PB 0x0000000718200000| Untracked | 0 >> | 94|0x0000000718400000, 0x0000000718400000, 0x0000000718600000| 0%| >> F| |TAMS 0x0000000718400000| PB 0x0000000718400000| Untracked | 0 >> | 95|0x0000000718600000, 0x0000000718600000, 0x0000000718800000| 0%| >> F| |TAMS 0x0000000718600000| PB 0x0000000718600000| Untracked | 0 >> | 96|0x0000000718800000, 0x0000000718800000, 0x0000000718a00000| 0%| >> F| |TAMS 0x0000000718800000| PB 0x0000000718800000| Untracked | 0 >> | 97|0x0000000718a00000, 0x0000000718a00000, 0x0000000718c00000| 0%| >> F| |TAMS 0x0000000718a00000| PB 0x0000000718a00000| Untracked | 0 >> | 98|0x0000000718c00000, 0x0000000718c00000, 0x0000000718e00000| 0%| >> F| |TAMS 0x0000000718c00000| PB 0x0000000718c00000| Untracked | 0 >> | 99|0x0000000718e00000, 0x0000000718e00000, 0x0000000719000000| 0%| >> F| |TAMS 0x0000000718e00000| PB 0x0000000718e00000| Untracked | 0 >> | 100|0x0000000719000000, 0x0000000719000000, 0x0000000719200000| 0%| >> F| |TAMS 0x0000000719000000| PB 0x0000000719000000| Untracked | 0 >> | 101|0x0000000719200000, 0x0000000719200000, 0x0000000719400000| 0%| >> F| |TAMS 0x0000000719200000| PB 0x0000000719200000| Untracked | 0 >> | 102|0x0000000719400000, 0x0000000719400000, 0x0000000719600000| 0%| >> F| |TAMS 0x0000000719400000| PB 0x0000000719400000| Untracked | 0 >> | 103|0x0000000719600000, 0x0000000719600000, 0x0000000719800000| 0%| >> F| |TAMS 0x0000000719600000| PB 0x0000000719600000| Untracked | 0 >> | 104|0x0000000719800000, 0x0000000719800000, 0x0000000719a00000| 0%| >> F| |TAMS 0x0000000719800000| PB 0x0000000719800000| Untracked | 0 >> | 105|0x0000000719a00000, 0x0000000719a00000, 0x0000000719c00000| 0%| >> F| |TAMS 0x0000000719a00000| PB 0x0000000719a00000| Untracked | 0 >> | 106|0x0000000719c00000, 0x0000000719c00000, 0x0000000719e00000| 0%| >> F| |TAMS 0x0000000719c00000| PB 0x0000000719c00000| Untracked | 0 >> | 107|0x0000000719e00000, 0x0000000719e00000, 0x000000071a000000| 0%| >> F| |TAMS 0x0000000719e00000| PB 0x0000000719e00000| Untracked | 0 >> | 108|0x000000071a000000, 0x000000071a000000, 0x000000071a200000| 0%| >> F| |TAMS 0x000000071a000000| PB 0x000000071a000000| Untracked | 0 >> | 109|0x000000071a200000, 0x000000071a200000, 0x000000071a400000| 0%| >> F| |TAMS 0x000000071a200000| PB 0x000000071a200000| Untracked | 0 >> | 110|0x000000071a400000, 0x000000071a400000, 0x000000071a600000| 0%| >> F| |TAMS 0x000000071a400000| PB 0x000000071a400000| Untracked | 0 >> | 111|0x000000071a600000, 0x000000071a600000, 0x000000071a800000| 0%| >> F| |TAMS 0x000000071a600000| PB 0x000000071a600000| Untracked | 0 >> | 112|0x000000071a800000, 0x000000071a800000, 0x000000071aa00000| 0%| >> F| |TAMS 0x000000071a800000| PB 0x000000071a800000| Untracked | 0 >> | 113|0x000000071aa00000, 0x000000071aa00000, 0x000000071ac00000| 0%| >> F| |TAMS 0x000000071aa00000| PB 0x000000071aa00000| Untracked | 0 >> | 114|0x000000071ac00000, 0x000000071ac00000, 0x000000071ae00000| 0%| >> F| |TAMS 0x000000071ac00000| PB 0x000000071ac00000| Untracked | 0 >> | 115|0x000000071ae00000, 0x000000071ae00000, 0x000000071b000000| 0%| >> F| |TAMS 0x000000071ae00000| PB 0x000000071ae00000| Untracked | 0 >> | 116|0x000000071b000000, 0x000000071b000000, 0x000000071b200000| 0%| >> F| |TAMS 0x000000071b000000| PB 0x000000071b000000| Untracked | 0 >> | 117|0x000000071b200000, 0x000000071b200000, 0x000000071b400000| 0%| >> F| |TAMS 0x000000071b200000| PB 0x000000071b200000| Untracked | 0 >> | 118|0x000000071b400000, 0x000000071b400000, 0x000000071b600000| 0%| >> F| |TAMS 0x000000071b400000| PB 0x000000071b400000| Untracked | 0 >> | 119|0x000000071b600000, 0x000000071b600000, 0x000000071b800000| 0%| >> F| |TAMS 0x000000071b600000| PB 0x000000071b600000| Untracked | 0 >> | 120|0x000000071b800000, 0x000000071b800000, 0x000000071ba00000| 0%| >> F| |TAMS 0x000000071b800000| PB 0x000000071b800000| Untracked | 0 >> | 121|0x000000071ba00000, 0x000000071bc00000, 0x000000071bc00000|100%| >> E| |TAMS 0x000000071ba00000| PB 0x000000071ba00000| Complete | 0 >> |1947|0x00000007ffe00000, 0x00000007fff1c148, 0x0000000800000000| 55%| >> O| |TAMS 0x00000007ffe00000| PB 0x00000007ffe00000| Untracked | 0 >> >> Card table byte_map: [0x00000268f51f0000,0x00000268f5990000] >> _byte_map_base: 0x00000268f198c000 >> >> Marking Bits: (CMBitMap*) 0x00000268e7d7dda0 >> Bits: [0x00000268f5990000, 0x00000268f9670000) >> >> Polling page: 0x00000268e5a80000 >> >> Metaspace: >> >> Usage: >> Non-class: 14.61 KB used. >> Class: 6.95 KB used. >> Both: 21.56 KB used. >> >> Virtual space: >> Non-class space: 64.00 MB reserved, 128.00 KB ( <1%) >> committed, 1 nodes. >> Class space: 1.00 GB reserved, 128.00 KB ( <1%) >> committed, 1 nodes. >> Both: 1.06 GB reserved, 256.00 KB ( <1%) committed. >> >> Chunk freelists: >> Non-Class: 12.00 MB >> Class: 15.75 MB >> Both: 27.74 MB >> >> MaxMetaspaceSize: unlimited >> CompressedClassSpaceSize: 1.00 GB >> Initial GC threshold: 21.00 MB >> Current GC threshold: 21.00 MB >> CDS: on >> - commit_granule_bytes: 65536. >> - commit_granule_words: 8192. >> - virtual_space_node_default_size: 8388608. >> - enlarge_chunks_in_place: 1. >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 >> Narrow klass pointer bits 32, Max shift 3 >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 bytes) >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 bytes) >> Klass ID Range: [65536 - 1090519033) (1090453497) >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) >> >> >> Internal statistics: >> >> num_allocs_failed_limit: 0. >> num_arena_births: 4. >> num_arena_deaths: 0. >> num_vsnodes_births: 2. >> num_vsnodes_deaths: 0. >> num_space_committed: 4. >> num_space_uncommitted: 0. >> num_chunks_returned_to_freelist: 0. >> num_chunks_taken_from_freelist: 4. >> num_chunk_merges: 0. >> num_chunk_splits: 4. >> num_chunks_enlarged: 0. >> num_inconsistent_stats: 0. >> >> CodeCache: size=32768Kb used=84Kb max_used=84Kb free=32683Kb >> bounds [0x00000268f1e90000, 0x00000268f1eb8000, 0x00000268f3e90000] >> total_blobs=225, nmethods=0, adapters=216, full_count=0 >> Compilation: disabled (interpreter mode), stopped_count=0, restarted_count=0 >> >> Compilation events (0 events): >> No events >> >> GC Heap History (0 events): >> No events >> >> Dll operation events (2 events): >> Event: 0.006 Loaded shared library >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll >> Event: 0.286 Loaded shared library >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll >> >> Deoptimization events (0 events): >> No events >> >> Classes loaded (16 events): >> Event: 0.023 Loading class sun/nio/cs/IBM437 >> Event: 0.023 Loading class sun/nio/cs/IBM437 done >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder done >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook done >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader done >> Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 >> Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 done >> Event: 0.027 Loading class java/lang/InterruptedException >> Event: 0.027 Loading class java/lang/InterruptedException done >> Event: 0.027 Loading class java/lang/CloneNotSupportedException >> Event: 0.027 Loading class java/lang/CloneNotSupportedException done >> Event: 0.028 Loading class java/util/Formatter$FixedString >> Event: 0.029 Loading class java/util/Formatter$FixedString done >> >> Classes unloaded (0 events): >> No events >> >> Classes redefined (0 events): >> No events >> >> Internal exceptions (0 events): >> No events >> >> VM Operations (0 events): >> No events >> >> Memory protections (0 events): >> No events >> >> Nmethod flushes (0 events): >> No events >> >> Events (9 events): >> Event: 0.017 Thread 0x00000268e57a3d20 Thread added: 0x00000268e57a3d20 >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08cfc0 >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08d5f0 >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc091710 >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc092140 >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0936e0 >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc09d2a0 >> Event: 0.026 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0d8ec0 >> Event: 0.027 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0de6e0 >> >> >> Dynamic libraries: >> 0x00007ff7bcd60000 - 0x00007ff7bcd70000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.exe >> 0x00007ffd45be0000 - 0x00007ffd45e40000 C:\WINDOWS\SYSTEM32\ntdll.dll >> 0x00007ffd44600000 - 0x00007ffd446c7000 C:\WINDOWS\System32\KERNEL32.DLL >> 0x00007ffd43490000 - 0x00007ffd4385a000 C:\WINDOWS\System32\KERNELBASE.dll >> 0x00007ffd42dc0000 - 0x00007ffd42f0b000 C:\WINDOWS\System32\ucrtbase.dll >> 0x00007ffd30100000 - 0x00007ffd3011d000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\VCRUNTIME140.dll >> 0x00007ffd2a470000 - 0x00007ffd2a487000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jli.dll >> 0x00007ffd450e0000 - 0x00007ffd452ac000 C:\WINDOWS\System32\USER32.dll >> 0x00007ffd41f90000 - 0x00007ffd42227000 >> C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24\COMCTL32.dll >> 0x00007ffd43040000 - 0x00007ffd43067000 C:\WINDOWS\System32\win32u.dll >> 0x00007ffd44a40000 - 0x00007ffd44ae9000 C:\WINDOWS\System32\msvcrt.dll >> 0x00007ffd44af0000 - 0x00007ffd44b1a000 C:\WINDOWS\System32\GDI32.dll >> 0x00007ffd43130000 - 0x00007ffd43261000 C:\WINDOWS\System32\gdi32full.dll >> 0x00007ffd433e0000 - 0x00007ffd43483000 C:\WINDOWS\System32\msvcp_win.dll >> 0x00007ffd44560000 - 0x00007ffd4458f000 C:\WINDOWS\System32\IMM32.DLL >> 0x00007ffd27710000 - 0x00007ffd2771c000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\vcruntime140_1.dll >> 0x00007ffd14e00000 - 0x00007ffd14e8d000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\msvcp140.dll >> 0x00007ffceaf00000 - 0x00007ffceb4cf000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero\jvm.dll >> 0x00007ffd452b0000 - 0x00007ffd45362000 C:\WINDOWS\System32\ADVAPI32.dll >> 0x00007ffd44780000 - 0x00007ffd44826000 C:\WINDOWS\System32\sechost.dll >> 0x00007ffd442d0000 - 0x00007ffd443e6000 C:\WINDOWS\System32\RPCRT4.dll >> 0x00007ffd446d0000 - 0x00007ffd44744000 C:\WINDOWS\System32\WS2_32.dll >> 0x00007ffd42c30000 - 0x00007ffd42c8e000 C:\WINDOWS\SYSTEM32\POWRPROF.dll >> 0x00007ffd332f0000 - 0x00007ffd33326000 C:\WINDOWS\SYSTEM32\WINMM.dll >> 0x00007ffd391c0000 - 0x00007ffd391cb000 C:\WINDOWS\SYSTEM32\VERSION.dll >> 0x00007ffd16d70000 - 0x00007ffd16d81000 C:\msys64\ucrt64\bin\libffi-8.dll >> 0x00007ffd42c10000 - 0x00007ffd42c24000 C:\WINDOWS\SYSTEM32\UMPDC.dll >> 0x00007ffd41a60000 - 0x00007ffd41a6c000 C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL >> 0x00007ffd42fa0000 - 0x00007ffd43039000 C:\WINDOWS\System32\bcryptPrimitives.dll >> 0x00007ffd41270000 - 0x00007ffd4128a000 C:\WINDOWS\SYSTEM32\kernel.appcore.dll >> 0x00007ffd27060000 - 0x00007ffd2706a000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jimage.dll >> 0x00007ffd42540000 - 0x00007ffd42781000 C:\WINDOWS\SYSTEM32\DBGHELP.DLL >> 0x00007ffd44d50000 - 0x00007ffd450d2000 C:\WINDOWS\System32\combase.dll >> 0x00007ffd439e0000 - 0x00007ffd43ab6000 C:\WINDOWS\System32\OLEAUT32.dll >> 0x00007ffd01660000 - 0x00007ffd01699000 C:\WINDOWS\SYSTEM32\dbgcore.DLL >> 0x00007ffd16d50000 - 0x00007ffd16d6d000 >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll >> 0x00007ffd44b20000 - 0x00007ffd44cb6000 C:\WINDOWS\System32\ole32.dll >> 0x00007ffd45370000 - 0x00007ffd45a99000 C:\WINDOWS\System32\SHELL32.dll >> 0x00007ffd43270000 - 0x00007ffd433d8000 C:\WINDOWS\System32\wintypes.dll >> 0x00007ffd3ff80000 - 0x00007ffd407d2000 C:\WINDOWS\SYSTEM32\windows.storage.dll >> 0x00007ffd44400000 - 0x00007ffd444ed000 C:\WINDOWS\System32\SHCORE.dll >> 0x00007ffd444f0000 - 0x00007ffd44554000 C:\WINDOWS\System32\shlwapi.dll >> 0x00007ffd42cd0000 - 0x00007ffd42cff000 C:\WINDOWS\SYSTEM32\profapi.dll >> 0x00007ffd15180000 - 0x00007ffd15192000 >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll >> >> JVMTI agents: none >> >> dbghelp: loaded successfully - version: 4.0.5 - missing functions: none >> symbol engine: initialized successfully - sym options: 0x614 - pdb >> path: .;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero;C:\msys64\ucrt64\bin;C:\Users\REDACTED\Downloads\LoadLibrary\Crash >> >> VM Arguments: >> jvm_args: --enable-preview >> java_command: Crash >> java_class_path (initial): C:/Users/REDACTED/Downloads/LoadLibrary/Crash >> Launcher Type: SUN_STANDARD >> >> [Global flags] >> uint ConcGCThreads = 5 >> {product} {ergonomic} >> uint G1ConcRefinementThreads = 18 >> {product} {ergonomic} >> size_t G1HeapRegionSize = 2097152 >> {product} {ergonomic} >> size_t InitialHeapSize = 255852544 >> {product} {ergonomic} >> size_t MarkStackSize = 4194304 >> {product} {ergonomic} >> size_t MarkStackSizeMax = 536870912 >> {product} {ergonomic} >> size_t MaxHeapSize = 4085252096 >> {product} {ergonomic} >> size_t MaxNewSize = 2449473536 >> {product} {ergonomic} >> size_t MinHeapDeltaBytes = 2097152 >> {product} {ergonomic} >> size_t MinHeapSize = 8388608 >> {product} {ergonomic} >> uintx NonNMethodCodeHeapSize = 4096 >> {pd product} {ergonomic} >> uintx NonProfiledCodeHeapSize = 0 >> {pd product} {ergonomic} >> uintx ProfiledCodeHeapSize = 0 >> {pd product} {ergonomic} >> size_t SoftMaxHeapSize = 4085252096 >> {manageable} {ergonomic} >> bool UseCompressedOops = true >> {product lp64_product} {ergonomic} >> bool UseG1GC = true >> {product} {ergonomic} >> bool UseLargePagesIndividualAllocation = false >> {pd product} {ergonomic} >> >> Logging: >> Log output configuration: >> #0: stdout all=warning uptime,level,tags foldmultilines=false >> #1: stderr all=off uptime,level,tags foldmultilines=false >> >> Release file: >> IMPLEMENTOR="N/A" >> JAVA_RUNTIME_VERSION="25-internal" >> JAVA_VERSION="25" >> JAVA_VERSION_DATE="2025-09-16" >> LIBC="default" >> MODULES="java.base java.compiler java.datatransfer java.xml java.prefs >> java.desktop java.instrument java.logging java.management >> java.security.sasl java.naming java.rmi java.management.rmi >> java.net.http java.scripting java.security.jgss java.transaction.xa >> java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio >> jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets >> jdk.internal.opt jdk.zipfs jdk.compiler jdk.crypto.cryptoki >> jdk.crypto.ec jdk.crypto.mscapi jdk.dynalink jdk.internal.ed >> jdk.editpad jdk.httpserver jdk.incubator.vector jdk.internal.le >> jdk.internal.md jdk.jartool jdk.javadoc jdk.jcmd jdk.management >> jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi >> jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd >> jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi >> jdk.net jdk.nio.mapmode jdk.sctp jdk.security.auth jdk.security.jgss >> jdk.unsupported jdk.unsupported.desktop jdk.xml.dom" >> OS_ARCH="x86_64" >> OS_NAME="Windows" >> SOURCE=".:git:8f7652d7a36b+" >> >> Environment Variables: >> PATH=C:\msys64\ucrt64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl >> USERNAME=REDACTED >> SHELL=C:\msys64\usr\bin\bash.exe >> LC_CTYPE=en_US.UTF-8 >> TERM=xterm >> OS=Windows_NT >> PROCESSOR_IDENTIFIER=AMD64 Family 25 Model 97 Stepping 2, AuthenticAMD >> TMP=C:\msys64\tmp >> TEMP=C:\msys64\tmp >> >> >> >> >> Compilation memory statistics disabled. >> >> Periodic native trim disabled >> >> --------------- S Y S T E M --------------- >> >> OS: >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) >> OS uptime: 0 days 1:47 hours >> >> CPU: total 24 (initial active 24) >> Processor Information for processor 0 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 1 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 2 >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 >> Processor Information for processor 3 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 4 >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 >> Processor Information for processor 5 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 6 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 7 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 8 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 9 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 10 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 11 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 12 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 13 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 14 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 15 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 16 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 17 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 18 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 19 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 20 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 21 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 22 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> Processor Information for processor 23 >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Memory: 4k page, system-wide physical 15578M (1690M free) >> TotalPageFile size 44250M (AvailPageFile size 20548M) >> current process WorkingSet (physical memory assigned to process): 64M, peak: 64M >> current process commit charge ("private bytes"): 373M, peak: 373M >> >> vm_info: Java HotSpot 64-Bit Zero VM (25-internal) for windows-amd64 >> JRE (25-internal), built on 2025-04-17T14:32:22Z with MS VC++ 17.8 >> (VS2022) >> >> END. >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-161-Note: >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:162:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): >> warning C5030: attribute [[gnu::packed]] is not recognized >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-320-Note: >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:321:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log-13-Note: >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:15:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:16:jdk\src\hotspot\cpu\zero\interpreterRT_zero.cpp(161): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-168-Note: >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:169:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): >> warning C5030: attribute [[gnu::packed]] is not recognized >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-307-Note: >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:308:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log-7-Note: >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:8:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:9:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:10:jdk\src\hotspot\cpu\zero\stack_zero.cpp(36): >> warning C4267: '=': conversion from 'size_t' to 'int', possible loss >> of data >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log-12-Note: >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:13:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log-28-Note: >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:29:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:30:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> possible loss of data >> >> Generating code >> Previous IPDB not found, fall back to full compilation. >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >> C4723: potential divide by 0 >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >> C4723: potential divide by 0 >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >> C4723: potential divide by 0 >> All 52893 functions were compiled because no usable IPDB/IOBJ from >> previous compilation was found. >> Finished generating code From jesper.wilhelmsson at oracle.com Thu Apr 24 12:31:38 2025 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 24 Apr 2025 12:31:38 +0000 Subject: Where to put supplementary docs? In-Reply-To: References: Message-ID: <4B094F68-914C-4B68-A0A7-6137909679FD@oracle.com> Hi Andrew, Documentation on individual changes should ideally be kept in JBS or in the PR. We can select one of them to promote as THE place to store stuff if that makes anything better, but both will in practice be used for discussions around changes regardless of what we promote. There is also a conceptual difference between what should be discussed where - the JBS issue discuss the problem, its cause, and potential solutions, while the PR discuss the particular solution implemented. If a PR is closed due to the implementation being rejected, only the part of the discussion related to that particular implementation should be lost. Anything generic that lead to the various choices made should still be there in JBS. This hints that JBS would be the better place for supporting documents unless they are extremely implementation specific. There might be arguments for other places but in my mind none strong enough to motivate a new solution in addition to what is already available. Dalibor mentioned the wiki, this is a good place to store more in-depth descriptions of how things work in the codebase. Some might argue that the wiki is out of date and no-one keeps it updated when changes are made. I would argue that this is a problem with developers not knowing that the documentation exists or not caring enough about the documentation to update it, rather than a problem with where or how the documentation is stored. Archie already made this argument, regardless of where the documentation exists, a comment in the source code or in the PR/JBS issue referring to it would be extremely useful and would serve the same purpose regardless of document location. If the JBS issue for the change and the wiki is not sufficient for some reason, we also have the concept of informational JEPs. An informational JEP can be created to host feature documentation or technical investigations. I would personally rather see this be an informational sub-task to the issue itself, but both are in JBS and can be easily linked from the issue. We also have the CR server; https://openjdk.org/groups/web/crServer.html This is storage supposed to be used for exactly this kind of documents and files. It was used a lot more in the past and I'm not sure if there are reasons to discourage its usage today, but it's still there for now at least. The only place that should be banned, and that we all need to help remind other community members to not use, is the rest of the internet. Many OpenJDK developers work in companies with some form of security policy. Often these policies forbids the employees to download random files from ramdom places on the internet. Placing supporting files in such places, be it some personal server, blogs, other company websites, the internet, means that many of us can't access those files without violating such policies. Whenever someone links to a file somewhere else, the default reply should always be: "Please use existing OpenJDK infrastructure to store this information. Ask your Sponsor to help if you don't have the necessary permissions to do so yourself." /Jesper On 22 Apr 2025, at 11:31, Andrew Haley wrote: Sometimes, when reviewing a PR, we have supporting documents to justify a change. These docs can include diagrams, etc. In the past some such documents were put on the webrev server, and sometimes they got lost. One example of such a file is "Fast Subtype Checking in the HotSpot JVM," which explained the (now obsolete) secondary subtype checking algorithm. Today, documents are sometimes uploaded to JIRA or attached to the PR itself. Sometimes they are stored in someone's personal web space, and linked from a PR, and that's when things get lost. It would be better for long-term retention if such documents were included in the JDK repository itself, and committed to the repo as part of the PR. I'm assuming that these files will be fairly small, so will not greatly increase the size of the repo. I propose to add a new subdirectory to jdk/doc, called "ref" or "reference". This is not for every possible reference document, but those that aid the maintainer and will be useful in the future. A comment in the source code should refer the reader to the appropriate reference document. Does anyone here object to this? Is there some other place than "doc/ref" that would be more appropriate? Thanks, Andrew. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Apr 24 14:37:15 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Apr 2025 16:37:15 +0200 Subject: AW: The future of 32-bit? In-Reply-To: <114dc201-1124-418c-8e84-d276ced1518a@oracle.com> References: <114dc201-1124-418c-8e84-d276ced1518a@oracle.com> Message-ID: On Tue, Apr 8, 2025 at 4:46?PM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2025-04-04 12:25, Doerr, Martin wrote: > > Hi all, > > > > even if we deprecate 32 bit now, arm32 will still be usable with JDK 25 > LTS for quite some time. > > > > The big question is if there will still be a significant demand in 2 years. > > I also wonder when other projects will terminate arm32 support. > > This ^^^. > > The question is not *if* we should stop supporting 32-bit, but *when*. I > don't see anyone arguing that 32-bit platforms have a long-term future. We > can keep the 32-bit JDKs on life support, for a longer or a shorter time, > but frankly, that is what it is. > > Dropping 32-bit completely somewhere between now and the next LTS release > might perhaps be a good idea. > > As with any other platforms in the JDK, the remaining 32-bit support > (arm-32 and zero) should have a sponsor, someone (organization or company) > backing it up. That is the general requirement we have for adding a new > platform, and we should have the same requirement for keeping old platforms > in. If we have such a sponsor, then the onus is on them to keep the > platform up to date with continuous development of the JDK. And if no-one > is willing to step up and assume such a role, well, that is a clear > indication that while it might be "nice to have" 32-bit support, no-one is > willing to pay the price for it. And if so, it should go. > > I 100% agree with this. Let's remove 32-bit support after JDK 25. For the record, this should also include removing zero 32-bit. /Thomas > > /Magnus > > > > > Best regards, > > Martin > > > > *Von: *jdk-dev im > Auftrag von Johan Vos > *Datum: *Freitag, 4. April 2025 um 11:17 > *An: *Thomas St?fe > *Cc: *JDK Dev list > *Betreff: *Re: The future of 32-bit? > > Hi Thomas, all, > > > > At the OCW workshop, I expressed my worries about removing all 32-bit > code, because I feared it would impact the ability to distribute Java apps > to mobile devices (via the existing stores). As someone pointed out, at the > very least 32-bit versions are not a requirement anymore. I did a bit of > research, and while there are still 32-bit devices in the field, the 2 > major stores are pushing for 64-bits, and discouraging 32 bits -- something > we would call @Deprecated(forRemoval="true"). As a consequence, zero-32 > code is no requirement for iOS, and arm-32 is no requirement for Android. > > > > There are still usecases for the Pi Zero (v1) and older Raspberry Pi > devices (< 3). I have no idea about the installed base of those devices, > but I believe it is possible that this would be the largest group that will > suffer if 32-bit support was halted. > > > > Having said that, I fully agree there is lots of additional work required > to keep 32-bit support (the (un)compressed classpointers are a good example > indeed). Though situation. > > > > - Johan > > > > > > On Fri, Apr 4, 2025 at 9:17?AM Thomas St?fe > wrote: > > Hi, > > > > Continuing our discussion at the last FOSDEM workshop, I would like to > know what we think about the future of 32-bit support. > > > > Supporting 32-bit became a lot more cumbersome after the x86 port was > removed. Before, one could easily build 32-bit on the ubiquitous x64 > platforms with --target-bits=32; that is not an option anymore. > > > We have two remaining 32-bit platforms, at least in theory: > > - arm32 > - zero 32-bit > > Zero 32-bit has been broken for a long while now; see > https://bugs.openjdk.org/browse/JDK-8353699. I try this occasionally and > don't remember the last time it built successfully. > > Arm32 is the last bastion of serious 32-bit support, and the last option > for testing 32-bit coding. So, one needs to build arm32 (best done via > crossbuild), then spin up an arm32 system to test the changes. I do this > with a slow-as-molasses Raspberry. It is not fun. > > Unfortunately, maintaining 32-bit is not as easy as "make sure it builds > and fix smaller things". It requires real development, especially in the > context of ongoing object header work. > > 32-bit also means we need to keep some form of uncompressed class pointers > around, which makes the eventual removal of uncompressed class pointers > (see [2]) more difficult. The current plan is to implement some sort of > fake-compressed-class-pointer mode [3], which sounds easy in theory but is > still tricky work I'd rather avoid. > > Keeping up 32-bit development in the face of dwindling options to build > and test is a struggle. It has been a struggle for some time now. Even the > comparatively well-maintained arm32 platform had periodic weeks of > brokenness after heavy upstream changes. And this is not intended to > diminish the effort put in by the arm32-maintainers. They are few, and they > do good work. > > But I expect this periodic brokenness to worsen now after the removal of > x86. This is not a good situation. > > > > Thank you, Thomas > > > > [1] https://bugs.openjdk.org/browse/JDK-8353699 > [2] https://bugs.openjdk.org/browse/JDK-8350754 > [3] > https://bugs.openjdk.org/browse/JDK-8350754?focusedId=14757275&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14757275 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Thu Apr 24 12:52:08 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 24 Apr 2025 08:52:08 -0400 Subject: Windows/Zero In-Reply-To: References: Message-ID: I'm in support of this. Now that 32-bit options just got removed, Zero is all we have for those of us on 32-bit hardware. So, having another option sounds just fine for me. On Thu, Apr 24, 2025, 7:49?AM Julian Waters wrote: > Hi Thomas, sorry for the late reply, > > Off the top of my head, the Zero JVM is extremely small and could be > useful in environments where a small JVM is needed. More importantly, > it may (Although I have not verified this yet) allow Java to run on 32 > bit Windows again, at no additional cost to maintenance since Zero > itself requires no extra 32 bit support, it's just compile and run. It > can help if you're working on other parts of the JDK and don't care > about the JVM, and just want it to compile and link quickly so you can > get to testing out the changes in the non JVM area of the JDK you're > working on at the moment, something that I do commonly. I guess the > process of supporting Windows/Zero also helped eliminate non standard > zero size arrays in HotSpot, though this may not be that big of a > deal. Regardless, I'm just curious if there is interest in it from > anyone at the moment. > > Have a great rest of the week ahead! > > best regards, > Julian > > On Tue, Apr 22, 2025 at 9:35?PM Thomas St?fe > wrote: > > > > Hi Julian, > > > > I am curious, what would be the use case for Windows+Zero? > > > > Zero is typically used for bootstrapping new platforms/CPUs. The Windows > CPU set is very stable, and Windows is not the platform anyone starts > porting to if they start working on a new platform. Additionally, Microsoft > usually takes care of porting in the once-a-decade-rare case that a new CPU > is supported on Windows. > > > > Cheers, Thomas > > > > > > On Tue, Apr 22, 2025 at 2:47?PM Julian Waters > wrote: > >> > >> Hi all, > >> > >> Zero currently cannot compile on Windows, and to my knowledge, has > >> never been able to compile on Windows. This is largely due to Windows > >> lacking crucial implementations for Zero under the os_cpu directory, > >> where you will notice a distinct lack of a windows_zero directory. To > >> remedy this, some time ago, I implemented Zero on Windows. The > >> implementation, aside from adding critical code to windows_zero, also > >> had to ifdef some code out of the Windows Structured Exception filter. > >> It was surprisingly minimal, but the downside is that Windows/Zero > >> then only compiled with gcc. VC had an additional hurdle to jump > >> through: On Zero, since there are no registers, register arrays in > >> certain classes became zero sized arrays, a GNU extension that VC will > >> never accept under any circumstances. > >> > >> I started work again recently to get Zero working with VC. Just 2 days > >> ago, this successfully compiled with VC, albeit with > >> --disable-warnings-as-errors. The code is available at > >> https://github.com/TheShermanTanker/jdk/commits/experimental for > >> anyone curious, under "Windows/Zero Port". Disclaimer: I do not know > >> whether the code is 100% correct, I may have implemented it wrongly. > >> The remaining warnings left over can be seen below this mail. Note > >> that only the release configuration was tested, fastdebug has not been > >> compiled yet. > >> > >> I'd like to float the idea of supporting Windows/Zero properly. > >> Ideally, Zero should run on any platform, so it not running on Windows > >> would be surprising, but past that, the Java Zero VM is extremely > >> small on Windows at just 5MB (Even smaller than the Python > >> Interpreter!), so it could be useful on devices where a small Java VM > >> is desired. More importantly, this could (Although I am not fully > >> certain) open the door to running the latest Java on 32 bit Windows > >> devices again, ever since all the x86 32 bit ports were removed, > >> leaving Zero as the only way to execute Java on 32 bit x86. This may > >> (or may not) help those who cannot get a 64 bit device or one that's > >> running Linux, I haven't checked yet. > >> > >> I also crashed the VM on purpose to get a hserr file which contains VM > >> information, this can be seen below. This was quite interesting, as > >> I've never actually seen Zero crash before! > >> > >> Thoughts? > >> > >> best regards, > >> Julian > >> > >> # > >> # A fatal error has been detected by the Java Runtime Environment: > >> # > >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd1518139f, > >> pid=335696, tid=337452 > >> # > >> # JRE version: Java Runtime Environment (25.0) (build 25-internal) > >> # Java VM: Java HotSpot 64-Bit Zero VM (25-internal, interpreted mode, > >> sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64) > >> # Problematic frame: > >> # C [Crash.dll+0x139f] > >> # > >> # No core dump will be written. Minidumps are not enabled by default > >> on client versions of Windows > >> # > >> # If you would like to submit a bug report, please visit: > >> # https://bugreport.java.com/bugreport/crash.jsp > >> # The crash happened outside the Java Virtual Machine in native code. > >> # See problematic frame for where to report the bug. > >> # > >> > >> --------------- S U M M A R Y ------------ > >> > >> Command Line: --enable-preview Crash > >> > >> Host: AMD Ryzen 9 7845HX with Radeon Graphics , 24 cores, 15G, > >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) > >> Time: Sun Apr 20 03:44:08 2025 Malay Peninsula Standard Time elapsed > >> time: 0.291582 seconds (0d 0h 0m 0s) > >> > >> --------------- T H R E A D --------------- > >> > >> Current thread (0x00000268e57a3d20): JavaThread "main" > >> [_thread_in_native, id=337452, > >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] > >> > >> Stack: [0x000000ae07a00000,0x000000ae07b00000], > >> sp=0x000000ae07a842a0, free space=528k > >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, > C=native code) > >> C [Crash.dll+0x139f] (no source info available) > >> C [libffi-8.dll+0x4cc1] (no source info available) > >> C [libffi-8.dll+0x48df] (no source info available) > >> C [libffi-8.dll+0x4aa2] (no source info available) > >> V [jvm.dll+0x426645] ZeroInterpreter::native_entry+0x455 > >> (zeroInterpreter_zero.cpp:444) > >> V [jvm.dll+0x425f47] ZeroInterpreter::main_loop+0x127 > >> (zeroInterpreter_zero.cpp:227) > >> V [jvm.dll+0x425d96] ZeroInterpreter::normal_entry+0x36 > >> (zeroInterpreter_zero.cpp:115) > >> V [jvm.dll+0x3b156d] StubGenerator::call_stub+0x1bd > >> (stubGenerator_zero.cpp:84) > >> V [jvm.dll+0x1acbfd] JavaCalls::call_helper+0x48d (javaCalls.cpp:424) > >> V [jvm.dll+0x2e4c80] os::os_exception_wrapper+0x20 > (os_windows_zero.cpp:51) > >> V [jvm.dll+0x1c472a] jni_invoke_nonstatic+0x32a (jni.cpp:950) > >> V [jvm.dll+0x1c8ea2] jni_CallVoidMethod+0x142 (jni.cpp:1307) > >> C [jli.dll+0x510f] JavaMain+0x7d3 (java.c:645) > >> C [ucrtbase.dll+0x37b0] (no source info available) > >> C [KERNEL32.DLL+0x2e8d7] (no source info available) > >> C [ntdll.dll+0xb14fc] (no source info available) > >> > >> Java frames: > >> 0x000000ae07aff8f0: unboxed parameter[1] = 0x000000ae07aff9a0 > >> 0x000000ae07aff8f8: parameter[0] (JNIEnv) = 0x000000ae07a84410 > >> 0x000000ae07aff900: parameter[1] (this) = 0x000000ae07aff8f0 > >> 0x000000ae07aff908: istate->_thread = 0x00000268e57a3d20 > >> 0x000000ae07aff910: istate->_bcp = 0x0000000000000000 > >> 0x000000ae07aff918: istate->_locals = 0x000000ae07aff9a0 > >> 0x000000ae07aff920: istate->_constants = 0x00000268c14003a8 > >> 0x000000ae07aff928: istate->_method = Crash.crash()V > >> 0x000000ae07aff930: istate->_mirror = 0x000000071ba1cb90 > >> 0x000000ae07aff938: istate->_stack = 0x000000ae07aff900 > >> 0x000000ae07aff940: istate->_msg = 0x0000026800000002 > >> 0x000000ae07aff948: istate->_result = 0x0000000000000000 > >> 0x000000ae07aff950: (istate->_result) = 0x000000ae00000003 > >> 0x000000ae07aff958: (istate->_result) = 0x0000000000000000 > >> 0x000000ae07aff960: istate->_prev_link = 0x0000000000000000 > >> 0x000000ae07aff968: istate->_oop_temp = 0x0000000000000000 > >> 0x000000ae07aff970: istate->_stack_base = 0x000000ae07aff908 > >> 0x000000ae07aff978: istate->_stack_limit = 0x000000ae07aff900 > >> 0x000000ae07aff980: istate->_monitor_base = 0x000000ae07aff908 > >> 0x000000ae07aff988: istate->_self_link = 0x000000ae07aff908 > >> 0x000000ae07aff990: frame_type = INTERPRETER_FRAME > >> 0x000000ae07aff998: next_frame = 0x000000ae07affa38 > >> > >> 0x000000ae07aff9a0: local[0] = 0x000000071ba1d940 > >> 0x000000ae07aff9a8: istate->_thread = 0x00000268e57a3d20 > >> 0x000000ae07aff9b0: istate->_bcp = 0x00000268c14002de (bci 6) > >> 0x000000ae07aff9b8: istate->_locals = 0x000000ae07affa40 > >> 0x000000ae07aff9c0: istate->_constants = 0x00000268c14003a8 > >> 0x000000ae07aff9c8: istate->_method = Crash.main()V > >> 0x000000ae07aff9d0: istate->_mirror = 0x000000071ba1cb90 > >> 0x000000ae07aff9d8: istate->_stack = 0x000000ae07aff998 > >> 0x000000ae07aff9e0: istate->_msg = 0x0000026800000008 > >> 0x000000ae07aff9e8: istate->_result = 0x00000268c1400238 > >> 0x000000ae07aff9f0: (istate->_result) = 0x00000268f1e90458 > >> 0x000000ae07aff9f8: (istate->_result) = 0x0000000000000003 > >> 0x000000ae07affa00: istate->_prev_link = 0x0000000000000000 > >> 0x000000ae07affa08: istate->_oop_temp = 0x0000000000000000 > >> 0x000000ae07affa10: istate->_stack_base = 0x000000ae07aff9a8 > >> 0x000000ae07affa18: istate->_stack_limit = 0x000000ae07aff990 > >> 0x000000ae07affa20: istate->_monitor_base = 0x000000ae07aff9a8 > >> 0x000000ae07affa28: istate->_self_link = 0x000000ae07aff9a8 > >> 0x000000ae07affa30: frame_type = INTERPRETER_FRAME > >> 0x000000ae07affa38: next_frame = 0x000000ae07affa58 > >> > >> 0x000000ae07affa40: local[0] = 0x000000071ba1d940 > >> 0x000000ae07affa48: call_wrapper = 0x000000ae07affaf0 > >> 0x000000ae07affa50: frame_type = ENTRY_FRAME > >> 0x000000ae07affa58: next_frame = 0x0000000000000000 > >> > >> > >> siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address > >> 0x0000000000000000 > >> > >> > >> No context information. > >> > >> Register to memory mapping: > >> > >> No register info. > >> > >> Top of Stack: (sp=0x000000ae07a842a0) > >> 0x000000ae07a842a0: 00000000000003d8 0000000000000000 > ................ > >> 0x000000ae07a842b0: 0000000000000000 00007ffd16d748df > .........H...... > >> 0x000000ae07a842c0: 000002688046f350 0000000000000000 > P.F.h........... > >> 0x000000ae07a842d0: 000000ae07a84300 00007ffd16d74cc1 > .C.......L...... > >> 0x000000ae07a842e0: 00000268e57a4028 000000ae07aff9a0 > (@z.h........... > >> 0x000000ae07a842f0: 0000000000000001 0000000000000050 > ........P....... > >> 0x000000ae07a84300: 000000ae07a84350 00007ffd16d748df > PC.......H...... > >> 0x000000ae07a84310: 00007ffd15181380 0000000000000000 > ................ > >> 0x000000ae07a84320: 000000ae07a84400 0000000000000000 > .D.............. > >> 0x000000ae07a84330: 0000000000000001 0000000000000000 > ................ > >> 0x000000ae07a84340: 00001664b4a8ce49 111f221225371f8f > I...d.....7%.".. > >> 0x000000ae07a84350: 00000268802416f0 00000268e57a3d20 ..$.h... > =z.h... > >> 0x000000ae07a84360: 00000268c1400238 000000ae07aff908 8.@ > .h........... > >> 0x000000ae07a84370: 000000ae07aff9a0 000000ae07aff998 > ................ > >> 0x000000ae07a84380: 00000268f1e98710 0000000000000000 > ....h........... > >> 0x000000ae07a84390: 000000ae07a84440 00007ffd16d74aa2 > @D.......J...... > >> 0x000000ae07a843a0: 0000000000000000 0000000000000001 > ................ > >> 0x000000ae07a843b0: 0000000000000000 000000ae07aff998 > ................ > >> 0x000000ae07a843c0: 0000000000000000 0000000000000000 > ................ > >> 0x000000ae07a843d0: 000000ae07a84440 00007ffceb326645 > @D......Ef2..... > >> 0x000000ae07a843e0: 00007ffceb482058 00000268e57a3d20 X H..... > =z.h... > >> 0x000000ae07a843f0: 00000268c1400238 00000268e57a3d20 8. at .h... > =z.h... > >> 0x000000ae07a84400: 000000ae07aff990 000000ae07aff8f8 > ................ > >> 0x000000ae07a84410: 00000268e57a4028 0000000000000000 > (@z.h........... > >> 0x000000ae07a84420: 00007ffd15181380 0000000000000000 > ................ > >> 0x000000ae07a84430: 00000268c1400238 00000268e57a3d20 8. at .h... > =z.h... > >> 0x000000ae07a84440: 0000000000000001 0000000000000000 > ................ > >> 0x000000ae07a84450: 0000000000000000 0000000000000000 > ................ > >> 0x000000ae07a84460: 0000000000000000 000000ae07affa38 > ........8....... > >> 0x000000ae07a84470: 00000268c14002e8 00007ffceb325f47 > .. at .h...G_2..... > >> 0x000000ae07a84480: 00000268e57a3d20 00000268e57a3d20 =z.h... > =z.h... > >> 0x000000ae07a84490: 000000ae00084b70 0000000000000000 > pK.............. > >> > >> Instructions: (pc=0x00007ffd1518139f) > >> 0x00007ffd1518129f: 00 e8 bb 0e 00 00 41 89 c4 83 fb 03 75 86 e9 5a > >> 0x00007ffd151812af: ff ff ff 66 0f 1f 44 00 00 83 fb 01 0f 85 6f ff > >> 0x00007ffd151812bf: ff ff 49 89 f8 31 d2 48 89 f1 e8 42 fd ff ff e9 > >> 0x00007ffd151812cf: 5d ff ff ff 0f 1f 44 00 00 e8 93 01 00 00 49 89 > >> 0x00007ffd151812df: f8 ba 01 00 00 00 48 89 f1 e8 73 0e 00 00 41 89 > >> 0x00007ffd151812ef: c4 85 c0 0f 85 3b ff ff ff 49 89 f8 31 d2 48 89 > >> 0x00007ffd151812ff: f1 e8 5b 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 3e > >> 0x00007ffd1518130f: 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 f1 fc ff ff > >> 0x00007ffd1518131f: e9 0f ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 > >> 0x00007ffd1518132f: 90 48 8b 05 b9 82 00 00 c7 00 00 00 00 00 e9 8e > >> 0x00007ffd1518133f: fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f > >> 0x00007ffd1518134f: 00 48 89 ca 48 8d 0d a6 ac 00 00 e9 f9 62 00 00 > >> 0x00007ffd1518135f: 90 48 8d 0d 09 00 00 00 e9 e4 ff ff ff 0f 1f 40 > >> 0x00007ffd1518136f: 00 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 > >> 0x00007ffd1518137f: 90 55 48 89 e5 48 83 ec 30 48 c7 45 f8 00 00 00 > >> 0x00007ffd1518138f: 00 48 8b 45 f8 48 8b 45 f8 48 8d 0d 61 7c 00 00 > >> =>0x00007ffd1518139f: 8b 10 e8 ca 0d 00 00 48 8d 0d 56 7c 00 00 48 83 > >> 0x00007ffd151813af: c4 30 5d e9 59 63 00 00 90 90 90 90 90 90 90 90 > >> 0x00007ffd151813bf: 90 48 83 ec 28 48 8b 05 45 6c 00 00 48 8b 00 48 > >> 0x00007ffd151813cf: 85 c0 74 22 0f 1f 44 00 00 ff d0 48 8b 05 2f 6c > >> 0x00007ffd151813df: 00 00 48 8d 50 08 48 8b 40 08 48 89 15 20 6c 00 > >> 0x00007ffd151813ef: 00 48 85 c0 75 e3 48 83 c4 28 c3 66 0f 1f 44 00 > >> 0x00007ffd151813ff: 00 56 53 48 83 ec 28 48 8b 15 83 81 00 00 48 8b > >> 0x00007ffd1518140f: 02 89 c1 83 f8 ff 74 39 85 c9 74 20 89 c8 83 e9 > >> 0x00007ffd1518141f: 01 48 8d 1c c2 48 29 c8 48 8d 74 c2 f8 0f 1f 40 > >> 0x00007ffd1518142f: 00 ff 13 48 83 eb 08 48 39 f3 75 f5 48 8d 0d 7e > >> 0x00007ffd1518143f: ff ff ff 48 83 c4 28 5b 5e e9 03 ff ff ff 0f 1f > >> 0x00007ffd1518144f: 00 31 c0 66 0f 1f 44 00 00 44 8d 40 01 89 c1 4a > >> 0x00007ffd1518145f: 83 3c c2 00 4c 89 c0 75 f0 eb ad 66 0f 1f 44 00 > >> 0x00007ffd1518146f: 00 8b 05 aa ab 00 00 85 c0 74 06 c3 0f 1f 44 00 > >> 0x00007ffd1518147f: 00 c7 05 96 ab 00 00 01 00 00 00 e9 71 ff ff ff > >> 0x00007ffd1518148f: 90 83 fa 03 74 0b 85 d2 74 07 c3 66 0f 1f 44 00 > >> > >> > >> Stack slot to memory mapping: > >> > >> stack at sp + 0 slots: 0x00000000000003d8 is an unknown value > >> stack at sp + 1 slots: 0x0 is null > >> stack at sp + 2 slots: 0x0 is null > >> stack at sp + 3 slots: 0x00007ffd16d748df libffi-8.dll > >> stack at sp + 4 slots: {method} {0x000002688046f358} 'loadLibrary' > >> > '(Ljava/lang/Class;Ljava/lang/String;)Ljdk/internal/loader/NativeLibrary;' > >> in 'java/lang/ClassLoader' > >> stack at sp + 5 slots: 0x0 is null > >> stack at sp + 6 slots: 0x000000ae07a84300 is pointing into the stack > >> for thread: 0x00000268e57a3d20 > >> stack at sp + 7 slots: 0x00007ffd16d74cc1 libffi-8.dll > >> > >> Lock stack of current Java thread (top to bottom): > >> > >> > >> --------------- P R O C E S S --------------- > >> > >> Threads class SMR info: > >> _java_thread_list=0x00000268fc0d5850, length=9, elements={ > >> 0x00000268e57a3d20, 0x00000268fc08cfc0, 0x00000268fc08d5f0, > 0x00000268fc091710, > >> 0x00000268fc092140, 0x00000268fc0936e0, 0x00000268fc09d2a0, > 0x00000268fc0d8ec0, > >> 0x00000268fc0de6e0 > >> } > >> > >> Java Threads: ( => current thread ) > >> =>0x00000268e57a3d20 JavaThread "main" > >> [_thread_in_native, id=337452, > >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] > >> 0x00000268fc08cfc0 JavaThread "Reference Handler" daemon > >> [_thread_blocked, id=337356, > >> stack(0x000000ae08200000,0x000000ae08300000) (1024K)] > >> 0x00000268fc08d5f0 JavaThread "Finalizer" daemon > >> [_thread_blocked, id=338708, > >> stack(0x000000ae08300000,0x000000ae08400000) (1024K)] > >> 0x00000268fc091710 JavaThread "Signal Dispatcher" daemon > >> [_thread_blocked, id=338204, > >> stack(0x000000ae08400000,0x000000ae08500000) (1024K)] > >> 0x00000268fc092140 JavaThread "Attach Listener" daemon > >> [_thread_blocked, id=338748, > >> stack(0x000000ae08500000,0x000000ae08600000) (1024K)] > >> 0x00000268fc0936e0 JavaThread "Service Thread" daemon > >> [_thread_blocked, id=337172, > >> stack(0x000000ae08600000,0x000000ae08700000) (1024K)] > >> 0x00000268fc09d2a0 JavaThread "Monitor Deflation Thread" daemon > >> [_thread_blocked, id=337312, > >> stack(0x000000ae08700000,0x000000ae08800000) (1024K)] > >> 0x00000268fc0d8ec0 JavaThread "Notification Thread" daemon > >> [_thread_blocked, id=337560, > >> stack(0x000000ae08800000,0x000000ae08900000) (1024K)] > >> 0x00000268fc0de6e0 JavaThread "Common-Cleaner" daemon > >> [_thread_blocked, id=338324, > >> stack(0x000000ae08900000,0x000000ae08a00000) (1024K)] > >> Total: 9 > >> > >> Other Threads: > >> 0x00000268fc07c960 VMThread "VM Thread" > >> [id=337424, stack(0x000000ae08100000,0x000000ae08200000) (1024K)] > >> 0x00000268fbf41360 WatcherThread "VM Periodic Task Thread" > >> [id=333244, stack(0x000000ae08000000,0x000000ae08100000) (1024K)] > >> 0x00000268e7d7d550 WorkerThread "GC Thread#0" > >> [id=336784, stack(0x000000ae07b00000,0x000000ae07c00000) (1024K)] > >> 0x00000268e7d951c0 ConcurrentGCThread "G1 Main Marker" > >> [id=338660, stack(0x000000ae07c00000,0x000000ae07d00000) (1024K)] > >> 0x00000268e7d96850 WorkerThread "G1 Conc#0" > >> [id=19564, stack(0x000000ae07d00000,0x000000ae07e00000) (1024K)] > >> 0x00000268fbf39000 ConcurrentGCThread "G1 Refine#0" > >> [id=217884, stack(0x000000ae07e00000,0x000000ae07f00000) (1024K)] > >> 0x00000268fbf39780 ConcurrentGCThread "G1 Service" > >> [id=338408, stack(0x000000ae07f00000,0x000000ae08000000) (1024K)] > >> Total: 7 > >> > >> Threads with active compile tasks: > >> Total: 0 > >> > >> VM state: not at safepoint (normal execution) > >> > >> VM Mutex/Monitor currently owned by a thread: None > >> > >> Heap address: 0x000000070c800000, size: 3896 MB, Compressed Oops mode: > >> Zero based, Oop shift amount: 3 > >> > >> CDS archive(s) mapped at: > >> [0x0000026880000000-0x0000026880d30000-0x0000026880d30000), size > >> 13828096, SharedBaseAddress: 0x0000026880000000, > >> ArchiveRelocationMode: 1. > >> Compressed class space mapped at: > >> 0x0000026881000000-0x00000268c1000000, reserved size: 1073741824 > >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 > >> Narrow klass pointer bits 32, Max shift 3 > >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 > >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 > bytes) > >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 > bytes) > >> Klass ID Range: [65536 - 1090519033) (1090453497) > >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 > bytes) > >> > >> GC Precious Log: > >> CardTable entry size: 512 > >> Card Set container configuration: InlinePtr #cards 4 size 8 Array Of > >> Cards #cards 16 size 48 Howl #buckets 8 coarsen threshold 3686 Howl > >> Bitmap #cards 512 size 80 coarsen threshold 460 Card regions per heap > >> region 1 cards per card region 4096 > >> CPUs: 24 total, 24 available > >> Memory: 15578M > >> Large Page Support: Disabled > >> NUMA Support: Disabled > >> Compressed Oops: Enabled (Zero based) > >> Heap Region Size: 2M > >> Heap Min Capacity: 8M > >> Heap Initial Capacity: 244M > >> Heap Max Capacity: 3896M > >> Pre-touch: Disabled > >> Parallel Workers: 18 > >> Concurrent Workers: 5 > >> Concurrent Refinement Workers: 18 > >> Periodic GC: Disabled > >> > >> Heap: > >> garbage-first heap total reserved 3989504K, committed 251904K, used > >> 1136K [0x000000070c800000, 0x0000000800000000) > >> region size 2048K, 1 young (2048K), 0 survivors (0K) > >> Metaspace used 21K, committed 256K, reserved 1114112K > >> class space used 6K, committed 128K, reserved 1048576K > >> > >> Heap Regions: E=young(eden), S=young(survivor), O=old, > >> HS=humongous(starts), HC=humongous(continues), CS=collection set, > >> F=free, TAMS=top-at-mark-start, PB=parsable bottom > >> | 0|0x000000070c800000, 0x000000070c800000, 0x000000070ca00000| 0%| > >> F| |TAMS 0x000000070c800000| PB 0x000000070c800000| Untracked | 0 > >> | 1|0x000000070ca00000, 0x000000070ca00000, 0x000000070cc00000| 0%| > >> F| |TAMS 0x000000070ca00000| PB 0x000000070ca00000| Untracked | 0 > >> | 2|0x000000070cc00000, 0x000000070cc00000, 0x000000070ce00000| 0%| > >> F| |TAMS 0x000000070cc00000| PB 0x000000070cc00000| Untracked | 0 > >> | 3|0x000000070ce00000, 0x000000070ce00000, 0x000000070d000000| 0%| > >> F| |TAMS 0x000000070ce00000| PB 0x000000070ce00000| Untracked | 0 > >> | 4|0x000000070d000000, 0x000000070d000000, 0x000000070d200000| 0%| > >> F| |TAMS 0x000000070d000000| PB 0x000000070d000000| Untracked | 0 > >> | 5|0x000000070d200000, 0x000000070d200000, 0x000000070d400000| 0%| > >> F| |TAMS 0x000000070d200000| PB 0x000000070d200000| Untracked | 0 > >> | 6|0x000000070d400000, 0x000000070d400000, 0x000000070d600000| 0%| > >> F| |TAMS 0x000000070d400000| PB 0x000000070d400000| Untracked | 0 > >> | 7|0x000000070d600000, 0x000000070d600000, 0x000000070d800000| 0%| > >> F| |TAMS 0x000000070d600000| PB 0x000000070d600000| Untracked | 0 > >> | 8|0x000000070d800000, 0x000000070d800000, 0x000000070da00000| 0%| > >> F| |TAMS 0x000000070d800000| PB 0x000000070d800000| Untracked | 0 > >> | 9|0x000000070da00000, 0x000000070da00000, 0x000000070dc00000| 0%| > >> F| |TAMS 0x000000070da00000| PB 0x000000070da00000| Untracked | 0 > >> | 10|0x000000070dc00000, 0x000000070dc00000, 0x000000070de00000| 0%| > >> F| |TAMS 0x000000070dc00000| PB 0x000000070dc00000| Untracked | 0 > >> | 11|0x000000070de00000, 0x000000070de00000, 0x000000070e000000| 0%| > >> F| |TAMS 0x000000070de00000| PB 0x000000070de00000| Untracked | 0 > >> | 12|0x000000070e000000, 0x000000070e000000, 0x000000070e200000| 0%| > >> F| |TAMS 0x000000070e000000| PB 0x000000070e000000| Untracked | 0 > >> | 13|0x000000070e200000, 0x000000070e200000, 0x000000070e400000| 0%| > >> F| |TAMS 0x000000070e200000| PB 0x000000070e200000| Untracked | 0 > >> | 14|0x000000070e400000, 0x000000070e400000, 0x000000070e600000| 0%| > >> F| |TAMS 0x000000070e400000| PB 0x000000070e400000| Untracked | 0 > >> | 15|0x000000070e600000, 0x000000070e600000, 0x000000070e800000| 0%| > >> F| |TAMS 0x000000070e600000| PB 0x000000070e600000| Untracked | 0 > >> | 16|0x000000070e800000, 0x000000070e800000, 0x000000070ea00000| 0%| > >> F| |TAMS 0x000000070e800000| PB 0x000000070e800000| Untracked | 0 > >> | 17|0x000000070ea00000, 0x000000070ea00000, 0x000000070ec00000| 0%| > >> F| |TAMS 0x000000070ea00000| PB 0x000000070ea00000| Untracked | 0 > >> | 18|0x000000070ec00000, 0x000000070ec00000, 0x000000070ee00000| 0%| > >> F| |TAMS 0x000000070ec00000| PB 0x000000070ec00000| Untracked | 0 > >> | 19|0x000000070ee00000, 0x000000070ee00000, 0x000000070f000000| 0%| > >> F| |TAMS 0x000000070ee00000| PB 0x000000070ee00000| Untracked | 0 > >> | 20|0x000000070f000000, 0x000000070f000000, 0x000000070f200000| 0%| > >> F| |TAMS 0x000000070f000000| PB 0x000000070f000000| Untracked | 0 > >> | 21|0x000000070f200000, 0x000000070f200000, 0x000000070f400000| 0%| > >> F| |TAMS 0x000000070f200000| PB 0x000000070f200000| Untracked | 0 > >> | 22|0x000000070f400000, 0x000000070f400000, 0x000000070f600000| 0%| > >> F| |TAMS 0x000000070f400000| PB 0x000000070f400000| Untracked | 0 > >> | 23|0x000000070f600000, 0x000000070f600000, 0x000000070f800000| 0%| > >> F| |TAMS 0x000000070f600000| PB 0x000000070f600000| Untracked | 0 > >> | 24|0x000000070f800000, 0x000000070f800000, 0x000000070fa00000| 0%| > >> F| |TAMS 0x000000070f800000| PB 0x000000070f800000| Untracked | 0 > >> | 25|0x000000070fa00000, 0x000000070fa00000, 0x000000070fc00000| 0%| > >> F| |TAMS 0x000000070fa00000| PB 0x000000070fa00000| Untracked | 0 > >> | 26|0x000000070fc00000, 0x000000070fc00000, 0x000000070fe00000| 0%| > >> F| |TAMS 0x000000070fc00000| PB 0x000000070fc00000| Untracked | 0 > >> | 27|0x000000070fe00000, 0x000000070fe00000, 0x0000000710000000| 0%| > >> F| |TAMS 0x000000070fe00000| PB 0x000000070fe00000| Untracked | 0 > >> | 28|0x0000000710000000, 0x0000000710000000, 0x0000000710200000| 0%| > >> F| |TAMS 0x0000000710000000| PB 0x0000000710000000| Untracked | 0 > >> | 29|0x0000000710200000, 0x0000000710200000, 0x0000000710400000| 0%| > >> F| |TAMS 0x0000000710200000| PB 0x0000000710200000| Untracked | 0 > >> | 30|0x0000000710400000, 0x0000000710400000, 0x0000000710600000| 0%| > >> F| |TAMS 0x0000000710400000| PB 0x0000000710400000| Untracked | 0 > >> | 31|0x0000000710600000, 0x0000000710600000, 0x0000000710800000| 0%| > >> F| |TAMS 0x0000000710600000| PB 0x0000000710600000| Untracked | 0 > >> | 32|0x0000000710800000, 0x0000000710800000, 0x0000000710a00000| 0%| > >> F| |TAMS 0x0000000710800000| PB 0x0000000710800000| Untracked | 0 > >> | 33|0x0000000710a00000, 0x0000000710a00000, 0x0000000710c00000| 0%| > >> F| |TAMS 0x0000000710a00000| PB 0x0000000710a00000| Untracked | 0 > >> | 34|0x0000000710c00000, 0x0000000710c00000, 0x0000000710e00000| 0%| > >> F| |TAMS 0x0000000710c00000| PB 0x0000000710c00000| Untracked | 0 > >> | 35|0x0000000710e00000, 0x0000000710e00000, 0x0000000711000000| 0%| > >> F| |TAMS 0x0000000710e00000| PB 0x0000000710e00000| Untracked | 0 > >> | 36|0x0000000711000000, 0x0000000711000000, 0x0000000711200000| 0%| > >> F| |TAMS 0x0000000711000000| PB 0x0000000711000000| Untracked | 0 > >> | 37|0x0000000711200000, 0x0000000711200000, 0x0000000711400000| 0%| > >> F| |TAMS 0x0000000711200000| PB 0x0000000711200000| Untracked | 0 > >> | 38|0x0000000711400000, 0x0000000711400000, 0x0000000711600000| 0%| > >> F| |TAMS 0x0000000711400000| PB 0x0000000711400000| Untracked | 0 > >> | 39|0x0000000711600000, 0x0000000711600000, 0x0000000711800000| 0%| > >> F| |TAMS 0x0000000711600000| PB 0x0000000711600000| Untracked | 0 > >> | 40|0x0000000711800000, 0x0000000711800000, 0x0000000711a00000| 0%| > >> F| |TAMS 0x0000000711800000| PB 0x0000000711800000| Untracked | 0 > >> | 41|0x0000000711a00000, 0x0000000711a00000, 0x0000000711c00000| 0%| > >> F| |TAMS 0x0000000711a00000| PB 0x0000000711a00000| Untracked | 0 > >> | 42|0x0000000711c00000, 0x0000000711c00000, 0x0000000711e00000| 0%| > >> F| |TAMS 0x0000000711c00000| PB 0x0000000711c00000| Untracked | 0 > >> | 43|0x0000000711e00000, 0x0000000711e00000, 0x0000000712000000| 0%| > >> F| |TAMS 0x0000000711e00000| PB 0x0000000711e00000| Untracked | 0 > >> | 44|0x0000000712000000, 0x0000000712000000, 0x0000000712200000| 0%| > >> F| |TAMS 0x0000000712000000| PB 0x0000000712000000| Untracked | 0 > >> | 45|0x0000000712200000, 0x0000000712200000, 0x0000000712400000| 0%| > >> F| |TAMS 0x0000000712200000| PB 0x0000000712200000| Untracked | 0 > >> | 46|0x0000000712400000, 0x0000000712400000, 0x0000000712600000| 0%| > >> F| |TAMS 0x0000000712400000| PB 0x0000000712400000| Untracked | 0 > >> | 47|0x0000000712600000, 0x0000000712600000, 0x0000000712800000| 0%| > >> F| |TAMS 0x0000000712600000| PB 0x0000000712600000| Untracked | 0 > >> | 48|0x0000000712800000, 0x0000000712800000, 0x0000000712a00000| 0%| > >> F| |TAMS 0x0000000712800000| PB 0x0000000712800000| Untracked | 0 > >> | 49|0x0000000712a00000, 0x0000000712a00000, 0x0000000712c00000| 0%| > >> F| |TAMS 0x0000000712a00000| PB 0x0000000712a00000| Untracked | 0 > >> | 50|0x0000000712c00000, 0x0000000712c00000, 0x0000000712e00000| 0%| > >> F| |TAMS 0x0000000712c00000| PB 0x0000000712c00000| Untracked | 0 > >> | 51|0x0000000712e00000, 0x0000000712e00000, 0x0000000713000000| 0%| > >> F| |TAMS 0x0000000712e00000| PB 0x0000000712e00000| Untracked | 0 > >> | 52|0x0000000713000000, 0x0000000713000000, 0x0000000713200000| 0%| > >> F| |TAMS 0x0000000713000000| PB 0x0000000713000000| Untracked | 0 > >> | 53|0x0000000713200000, 0x0000000713200000, 0x0000000713400000| 0%| > >> F| |TAMS 0x0000000713200000| PB 0x0000000713200000| Untracked | 0 > >> | 54|0x0000000713400000, 0x0000000713400000, 0x0000000713600000| 0%| > >> F| |TAMS 0x0000000713400000| PB 0x0000000713400000| Untracked | 0 > >> | 55|0x0000000713600000, 0x0000000713600000, 0x0000000713800000| 0%| > >> F| |TAMS 0x0000000713600000| PB 0x0000000713600000| Untracked | 0 > >> | 56|0x0000000713800000, 0x0000000713800000, 0x0000000713a00000| 0%| > >> F| |TAMS 0x0000000713800000| PB 0x0000000713800000| Untracked | 0 > >> | 57|0x0000000713a00000, 0x0000000713a00000, 0x0000000713c00000| 0%| > >> F| |TAMS 0x0000000713a00000| PB 0x0000000713a00000| Untracked | 0 > >> | 58|0x0000000713c00000, 0x0000000713c00000, 0x0000000713e00000| 0%| > >> F| |TAMS 0x0000000713c00000| PB 0x0000000713c00000| Untracked | 0 > >> | 59|0x0000000713e00000, 0x0000000713e00000, 0x0000000714000000| 0%| > >> F| |TAMS 0x0000000713e00000| PB 0x0000000713e00000| Untracked | 0 > >> | 60|0x0000000714000000, 0x0000000714000000, 0x0000000714200000| 0%| > >> F| |TAMS 0x0000000714000000| PB 0x0000000714000000| Untracked | 0 > >> | 61|0x0000000714200000, 0x0000000714200000, 0x0000000714400000| 0%| > >> F| |TAMS 0x0000000714200000| PB 0x0000000714200000| Untracked | 0 > >> | 62|0x0000000714400000, 0x0000000714400000, 0x0000000714600000| 0%| > >> F| |TAMS 0x0000000714400000| PB 0x0000000714400000| Untracked | 0 > >> | 63|0x0000000714600000, 0x0000000714600000, 0x0000000714800000| 0%| > >> F| |TAMS 0x0000000714600000| PB 0x0000000714600000| Untracked | 0 > >> | 64|0x0000000714800000, 0x0000000714800000, 0x0000000714a00000| 0%| > >> F| |TAMS 0x0000000714800000| PB 0x0000000714800000| Untracked | 0 > >> | 65|0x0000000714a00000, 0x0000000714a00000, 0x0000000714c00000| 0%| > >> F| |TAMS 0x0000000714a00000| PB 0x0000000714a00000| Untracked | 0 > >> | 66|0x0000000714c00000, 0x0000000714c00000, 0x0000000714e00000| 0%| > >> F| |TAMS 0x0000000714c00000| PB 0x0000000714c00000| Untracked | 0 > >> | 67|0x0000000714e00000, 0x0000000714e00000, 0x0000000715000000| 0%| > >> F| |TAMS 0x0000000714e00000| PB 0x0000000714e00000| Untracked | 0 > >> | 68|0x0000000715000000, 0x0000000715000000, 0x0000000715200000| 0%| > >> F| |TAMS 0x0000000715000000| PB 0x0000000715000000| Untracked | 0 > >> | 69|0x0000000715200000, 0x0000000715200000, 0x0000000715400000| 0%| > >> F| |TAMS 0x0000000715200000| PB 0x0000000715200000| Untracked | 0 > >> | 70|0x0000000715400000, 0x0000000715400000, 0x0000000715600000| 0%| > >> F| |TAMS 0x0000000715400000| PB 0x0000000715400000| Untracked | 0 > >> | 71|0x0000000715600000, 0x0000000715600000, 0x0000000715800000| 0%| > >> F| |TAMS 0x0000000715600000| PB 0x0000000715600000| Untracked | 0 > >> | 72|0x0000000715800000, 0x0000000715800000, 0x0000000715a00000| 0%| > >> F| |TAMS 0x0000000715800000| PB 0x0000000715800000| Untracked | 0 > >> | 73|0x0000000715a00000, 0x0000000715a00000, 0x0000000715c00000| 0%| > >> F| |TAMS 0x0000000715a00000| PB 0x0000000715a00000| Untracked | 0 > >> | 74|0x0000000715c00000, 0x0000000715c00000, 0x0000000715e00000| 0%| > >> F| |TAMS 0x0000000715c00000| PB 0x0000000715c00000| Untracked | 0 > >> | 75|0x0000000715e00000, 0x0000000715e00000, 0x0000000716000000| 0%| > >> F| |TAMS 0x0000000715e00000| PB 0x0000000715e00000| Untracked | 0 > >> | 76|0x0000000716000000, 0x0000000716000000, 0x0000000716200000| 0%| > >> F| |TAMS 0x0000000716000000| PB 0x0000000716000000| Untracked | 0 > >> | 77|0x0000000716200000, 0x0000000716200000, 0x0000000716400000| 0%| > >> F| |TAMS 0x0000000716200000| PB 0x0000000716200000| Untracked | 0 > >> | 78|0x0000000716400000, 0x0000000716400000, 0x0000000716600000| 0%| > >> F| |TAMS 0x0000000716400000| PB 0x0000000716400000| Untracked | 0 > >> | 79|0x0000000716600000, 0x0000000716600000, 0x0000000716800000| 0%| > >> F| |TAMS 0x0000000716600000| PB 0x0000000716600000| Untracked | 0 > >> | 80|0x0000000716800000, 0x0000000716800000, 0x0000000716a00000| 0%| > >> F| |TAMS 0x0000000716800000| PB 0x0000000716800000| Untracked | 0 > >> | 81|0x0000000716a00000, 0x0000000716a00000, 0x0000000716c00000| 0%| > >> F| |TAMS 0x0000000716a00000| PB 0x0000000716a00000| Untracked | 0 > >> | 82|0x0000000716c00000, 0x0000000716c00000, 0x0000000716e00000| 0%| > >> F| |TAMS 0x0000000716c00000| PB 0x0000000716c00000| Untracked | 0 > >> | 83|0x0000000716e00000, 0x0000000716e00000, 0x0000000717000000| 0%| > >> F| |TAMS 0x0000000716e00000| PB 0x0000000716e00000| Untracked | 0 > >> | 84|0x0000000717000000, 0x0000000717000000, 0x0000000717200000| 0%| > >> F| |TAMS 0x0000000717000000| PB 0x0000000717000000| Untracked | 0 > >> | 85|0x0000000717200000, 0x0000000717200000, 0x0000000717400000| 0%| > >> F| |TAMS 0x0000000717200000| PB 0x0000000717200000| Untracked | 0 > >> | 86|0x0000000717400000, 0x0000000717400000, 0x0000000717600000| 0%| > >> F| |TAMS 0x0000000717400000| PB 0x0000000717400000| Untracked | 0 > >> | 87|0x0000000717600000, 0x0000000717600000, 0x0000000717800000| 0%| > >> F| |TAMS 0x0000000717600000| PB 0x0000000717600000| Untracked | 0 > >> | 88|0x0000000717800000, 0x0000000717800000, 0x0000000717a00000| 0%| > >> F| |TAMS 0x0000000717800000| PB 0x0000000717800000| Untracked | 0 > >> | 89|0x0000000717a00000, 0x0000000717a00000, 0x0000000717c00000| 0%| > >> F| |TAMS 0x0000000717a00000| PB 0x0000000717a00000| Untracked | 0 > >> | 90|0x0000000717c00000, 0x0000000717c00000, 0x0000000717e00000| 0%| > >> F| |TAMS 0x0000000717c00000| PB 0x0000000717c00000| Untracked | 0 > >> | 91|0x0000000717e00000, 0x0000000717e00000, 0x0000000718000000| 0%| > >> F| |TAMS 0x0000000717e00000| PB 0x0000000717e00000| Untracked | 0 > >> | 92|0x0000000718000000, 0x0000000718000000, 0x0000000718200000| 0%| > >> F| |TAMS 0x0000000718000000| PB 0x0000000718000000| Untracked | 0 > >> | 93|0x0000000718200000, 0x0000000718200000, 0x0000000718400000| 0%| > >> F| |TAMS 0x0000000718200000| PB 0x0000000718200000| Untracked | 0 > >> | 94|0x0000000718400000, 0x0000000718400000, 0x0000000718600000| 0%| > >> F| |TAMS 0x0000000718400000| PB 0x0000000718400000| Untracked | 0 > >> | 95|0x0000000718600000, 0x0000000718600000, 0x0000000718800000| 0%| > >> F| |TAMS 0x0000000718600000| PB 0x0000000718600000| Untracked | 0 > >> | 96|0x0000000718800000, 0x0000000718800000, 0x0000000718a00000| 0%| > >> F| |TAMS 0x0000000718800000| PB 0x0000000718800000| Untracked | 0 > >> | 97|0x0000000718a00000, 0x0000000718a00000, 0x0000000718c00000| 0%| > >> F| |TAMS 0x0000000718a00000| PB 0x0000000718a00000| Untracked | 0 > >> | 98|0x0000000718c00000, 0x0000000718c00000, 0x0000000718e00000| 0%| > >> F| |TAMS 0x0000000718c00000| PB 0x0000000718c00000| Untracked | 0 > >> | 99|0x0000000718e00000, 0x0000000718e00000, 0x0000000719000000| 0%| > >> F| |TAMS 0x0000000718e00000| PB 0x0000000718e00000| Untracked | 0 > >> | 100|0x0000000719000000, 0x0000000719000000, 0x0000000719200000| 0%| > >> F| |TAMS 0x0000000719000000| PB 0x0000000719000000| Untracked | 0 > >> | 101|0x0000000719200000, 0x0000000719200000, 0x0000000719400000| 0%| > >> F| |TAMS 0x0000000719200000| PB 0x0000000719200000| Untracked | 0 > >> | 102|0x0000000719400000, 0x0000000719400000, 0x0000000719600000| 0%| > >> F| |TAMS 0x0000000719400000| PB 0x0000000719400000| Untracked | 0 > >> | 103|0x0000000719600000, 0x0000000719600000, 0x0000000719800000| 0%| > >> F| |TAMS 0x0000000719600000| PB 0x0000000719600000| Untracked | 0 > >> | 104|0x0000000719800000, 0x0000000719800000, 0x0000000719a00000| 0%| > >> F| |TAMS 0x0000000719800000| PB 0x0000000719800000| Untracked | 0 > >> | 105|0x0000000719a00000, 0x0000000719a00000, 0x0000000719c00000| 0%| > >> F| |TAMS 0x0000000719a00000| PB 0x0000000719a00000| Untracked | 0 > >> | 106|0x0000000719c00000, 0x0000000719c00000, 0x0000000719e00000| 0%| > >> F| |TAMS 0x0000000719c00000| PB 0x0000000719c00000| Untracked | 0 > >> | 107|0x0000000719e00000, 0x0000000719e00000, 0x000000071a000000| 0%| > >> F| |TAMS 0x0000000719e00000| PB 0x0000000719e00000| Untracked | 0 > >> | 108|0x000000071a000000, 0x000000071a000000, 0x000000071a200000| 0%| > >> F| |TAMS 0x000000071a000000| PB 0x000000071a000000| Untracked | 0 > >> | 109|0x000000071a200000, 0x000000071a200000, 0x000000071a400000| 0%| > >> F| |TAMS 0x000000071a200000| PB 0x000000071a200000| Untracked | 0 > >> | 110|0x000000071a400000, 0x000000071a400000, 0x000000071a600000| 0%| > >> F| |TAMS 0x000000071a400000| PB 0x000000071a400000| Untracked | 0 > >> | 111|0x000000071a600000, 0x000000071a600000, 0x000000071a800000| 0%| > >> F| |TAMS 0x000000071a600000| PB 0x000000071a600000| Untracked | 0 > >> | 112|0x000000071a800000, 0x000000071a800000, 0x000000071aa00000| 0%| > >> F| |TAMS 0x000000071a800000| PB 0x000000071a800000| Untracked | 0 > >> | 113|0x000000071aa00000, 0x000000071aa00000, 0x000000071ac00000| 0%| > >> F| |TAMS 0x000000071aa00000| PB 0x000000071aa00000| Untracked | 0 > >> | 114|0x000000071ac00000, 0x000000071ac00000, 0x000000071ae00000| 0%| > >> F| |TAMS 0x000000071ac00000| PB 0x000000071ac00000| Untracked | 0 > >> | 115|0x000000071ae00000, 0x000000071ae00000, 0x000000071b000000| 0%| > >> F| |TAMS 0x000000071ae00000| PB 0x000000071ae00000| Untracked | 0 > >> | 116|0x000000071b000000, 0x000000071b000000, 0x000000071b200000| 0%| > >> F| |TAMS 0x000000071b000000| PB 0x000000071b000000| Untracked | 0 > >> | 117|0x000000071b200000, 0x000000071b200000, 0x000000071b400000| 0%| > >> F| |TAMS 0x000000071b200000| PB 0x000000071b200000| Untracked | 0 > >> | 118|0x000000071b400000, 0x000000071b400000, 0x000000071b600000| 0%| > >> F| |TAMS 0x000000071b400000| PB 0x000000071b400000| Untracked | 0 > >> | 119|0x000000071b600000, 0x000000071b600000, 0x000000071b800000| 0%| > >> F| |TAMS 0x000000071b600000| PB 0x000000071b600000| Untracked | 0 > >> | 120|0x000000071b800000, 0x000000071b800000, 0x000000071ba00000| 0%| > >> F| |TAMS 0x000000071b800000| PB 0x000000071b800000| Untracked | 0 > >> | 121|0x000000071ba00000, 0x000000071bc00000, 0x000000071bc00000|100%| > >> E| |TAMS 0x000000071ba00000| PB 0x000000071ba00000| Complete | 0 > >> |1947|0x00000007ffe00000, 0x00000007fff1c148, 0x0000000800000000| 55%| > >> O| |TAMS 0x00000007ffe00000| PB 0x00000007ffe00000| Untracked | 0 > >> > >> Card table byte_map: [0x00000268f51f0000,0x00000268f5990000] > >> _byte_map_base: 0x00000268f198c000 > >> > >> Marking Bits: (CMBitMap*) 0x00000268e7d7dda0 > >> Bits: [0x00000268f5990000, 0x00000268f9670000) > >> > >> Polling page: 0x00000268e5a80000 > >> > >> Metaspace: > >> > >> Usage: > >> Non-class: 14.61 KB used. > >> Class: 6.95 KB used. > >> Both: 21.56 KB used. > >> > >> Virtual space: > >> Non-class space: 64.00 MB reserved, 128.00 KB ( <1%) > >> committed, 1 nodes. > >> Class space: 1.00 GB reserved, 128.00 KB ( <1%) > >> committed, 1 nodes. > >> Both: 1.06 GB reserved, 256.00 KB ( <1%) > committed. > >> > >> Chunk freelists: > >> Non-Class: 12.00 MB > >> Class: 15.75 MB > >> Both: 27.74 MB > >> > >> MaxMetaspaceSize: unlimited > >> CompressedClassSpaceSize: 1.00 GB > >> Initial GC threshold: 21.00 MB > >> Current GC threshold: 21.00 MB > >> CDS: on > >> - commit_granule_bytes: 65536. > >> - commit_granule_words: 8192. > >> - virtual_space_node_default_size: 8388608. > >> - enlarge_chunks_in_place: 1. > >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 > >> Narrow klass pointer bits 32, Max shift 3 > >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 > >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 > bytes) > >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 > bytes) > >> Klass ID Range: [65536 - 1090519033) (1090453497) > >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 > bytes) > >> > >> > >> Internal statistics: > >> > >> num_allocs_failed_limit: 0. > >> num_arena_births: 4. > >> num_arena_deaths: 0. > >> num_vsnodes_births: 2. > >> num_vsnodes_deaths: 0. > >> num_space_committed: 4. > >> num_space_uncommitted: 0. > >> num_chunks_returned_to_freelist: 0. > >> num_chunks_taken_from_freelist: 4. > >> num_chunk_merges: 0. > >> num_chunk_splits: 4. > >> num_chunks_enlarged: 0. > >> num_inconsistent_stats: 0. > >> > >> CodeCache: size=32768Kb used=84Kb max_used=84Kb free=32683Kb > >> bounds [0x00000268f1e90000, 0x00000268f1eb8000, 0x00000268f3e90000] > >> total_blobs=225, nmethods=0, adapters=216, full_count=0 > >> Compilation: disabled (interpreter mode), stopped_count=0, > restarted_count=0 > >> > >> Compilation events (0 events): > >> No events > >> > >> GC Heap History (0 events): > >> No events > >> > >> Dll operation events (2 events): > >> Event: 0.006 Loaded shared library > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll > >> Event: 0.286 Loaded shared library > >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll > >> > >> Deoptimization events (0 events): > >> No events > >> > >> Classes loaded (16 events): > >> Event: 0.023 Loading class sun/nio/cs/IBM437 > >> Event: 0.023 Loading class sun/nio/cs/IBM437 done > >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder > >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder done > >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook > >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook done > >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader > >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader > done > >> Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 > >> Event: 0.027 Loading class > jdk/internal/loader/URLClassPath$FileLoader$1 done > >> Event: 0.027 Loading class java/lang/InterruptedException > >> Event: 0.027 Loading class java/lang/InterruptedException done > >> Event: 0.027 Loading class java/lang/CloneNotSupportedException > >> Event: 0.027 Loading class java/lang/CloneNotSupportedException done > >> Event: 0.028 Loading class java/util/Formatter$FixedString > >> Event: 0.029 Loading class java/util/Formatter$FixedString done > >> > >> Classes unloaded (0 events): > >> No events > >> > >> Classes redefined (0 events): > >> No events > >> > >> Internal exceptions (0 events): > >> No events > >> > >> VM Operations (0 events): > >> No events > >> > >> Memory protections (0 events): > >> No events > >> > >> Nmethod flushes (0 events): > >> No events > >> > >> Events (9 events): > >> Event: 0.017 Thread 0x00000268e57a3d20 Thread added: 0x00000268e57a3d20 > >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08cfc0 > >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08d5f0 > >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc091710 > >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc092140 > >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0936e0 > >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc09d2a0 > >> Event: 0.026 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0d8ec0 > >> Event: 0.027 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0de6e0 > >> > >> > >> Dynamic libraries: > >> 0x00007ff7bcd60000 - 0x00007ff7bcd70000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.exe > >> 0x00007ffd45be0000 - 0x00007ffd45e40000 C:\WINDOWS\SYSTEM32\ntdll.dll > >> 0x00007ffd44600000 - 0x00007ffd446c7000 C:\WINDOWS\System32\KERNEL32.DLL > >> 0x00007ffd43490000 - 0x00007ffd4385a000 > C:\WINDOWS\System32\KERNELBASE.dll > >> 0x00007ffd42dc0000 - 0x00007ffd42f0b000 C:\WINDOWS\System32\ucrtbase.dll > >> 0x00007ffd30100000 - 0x00007ffd3011d000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\VCRUNTIME140.dll > >> 0x00007ffd2a470000 - 0x00007ffd2a487000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jli.dll > >> 0x00007ffd450e0000 - 0x00007ffd452ac000 C:\WINDOWS\System32\USER32.dll > >> 0x00007ffd41f90000 - 0x00007ffd42227000 > >> > C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24\COMCTL32.dll > >> 0x00007ffd43040000 - 0x00007ffd43067000 C:\WINDOWS\System32\win32u.dll > >> 0x00007ffd44a40000 - 0x00007ffd44ae9000 C:\WINDOWS\System32\msvcrt.dll > >> 0x00007ffd44af0000 - 0x00007ffd44b1a000 C:\WINDOWS\System32\GDI32.dll > >> 0x00007ffd43130000 - 0x00007ffd43261000 > C:\WINDOWS\System32\gdi32full.dll > >> 0x00007ffd433e0000 - 0x00007ffd43483000 > C:\WINDOWS\System32\msvcp_win.dll > >> 0x00007ffd44560000 - 0x00007ffd4458f000 C:\WINDOWS\System32\IMM32.DLL > >> 0x00007ffd27710000 - 0x00007ffd2771c000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\vcruntime140_1.dll > >> 0x00007ffd14e00000 - 0x00007ffd14e8d000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\msvcp140.dll > >> 0x00007ffceaf00000 - 0x00007ffceb4cf000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero\jvm.dll > >> 0x00007ffd452b0000 - 0x00007ffd45362000 C:\WINDOWS\System32\ADVAPI32.dll > >> 0x00007ffd44780000 - 0x00007ffd44826000 C:\WINDOWS\System32\sechost.dll > >> 0x00007ffd442d0000 - 0x00007ffd443e6000 C:\WINDOWS\System32\RPCRT4.dll > >> 0x00007ffd446d0000 - 0x00007ffd44744000 C:\WINDOWS\System32\WS2_32.dll > >> 0x00007ffd42c30000 - 0x00007ffd42c8e000 C:\WINDOWS\SYSTEM32\POWRPROF.dll > >> 0x00007ffd332f0000 - 0x00007ffd33326000 C:\WINDOWS\SYSTEM32\WINMM.dll > >> 0x00007ffd391c0000 - 0x00007ffd391cb000 C:\WINDOWS\SYSTEM32\VERSION.dll > >> 0x00007ffd16d70000 - 0x00007ffd16d81000 > C:\msys64\ucrt64\bin\libffi-8.dll > >> 0x00007ffd42c10000 - 0x00007ffd42c24000 C:\WINDOWS\SYSTEM32\UMPDC.dll > >> 0x00007ffd41a60000 - 0x00007ffd41a6c000 > C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL > >> 0x00007ffd42fa0000 - 0x00007ffd43039000 > C:\WINDOWS\System32\bcryptPrimitives.dll > >> 0x00007ffd41270000 - 0x00007ffd4128a000 > C:\WINDOWS\SYSTEM32\kernel.appcore.dll > >> 0x00007ffd27060000 - 0x00007ffd2706a000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jimage.dll > >> 0x00007ffd42540000 - 0x00007ffd42781000 C:\WINDOWS\SYSTEM32\DBGHELP.DLL > >> 0x00007ffd44d50000 - 0x00007ffd450d2000 C:\WINDOWS\System32\combase.dll > >> 0x00007ffd439e0000 - 0x00007ffd43ab6000 C:\WINDOWS\System32\OLEAUT32.dll > >> 0x00007ffd01660000 - 0x00007ffd01699000 C:\WINDOWS\SYSTEM32\dbgcore.DLL > >> 0x00007ffd16d50000 - 0x00007ffd16d6d000 > >> > C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll > >> 0x00007ffd44b20000 - 0x00007ffd44cb6000 C:\WINDOWS\System32\ole32.dll > >> 0x00007ffd45370000 - 0x00007ffd45a99000 C:\WINDOWS\System32\SHELL32.dll > >> 0x00007ffd43270000 - 0x00007ffd433d8000 C:\WINDOWS\System32\wintypes.dll > >> 0x00007ffd3ff80000 - 0x00007ffd407d2000 > C:\WINDOWS\SYSTEM32\windows.storage.dll > >> 0x00007ffd44400000 - 0x00007ffd444ed000 C:\WINDOWS\System32\SHCORE.dll > >> 0x00007ffd444f0000 - 0x00007ffd44554000 C:\WINDOWS\System32\shlwapi.dll > >> 0x00007ffd42cd0000 - 0x00007ffd42cff000 C:\WINDOWS\SYSTEM32\profapi.dll > >> 0x00007ffd15180000 - 0x00007ffd15192000 > >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll > >> > >> JVMTI agents: none > >> > >> dbghelp: loaded successfully - version: 4.0.5 - missing functions: none > >> symbol engine: initialized successfully - sym options: 0x614 - pdb > >> path: > .;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero;C:\msys64\ucrt64\bin;C:\Users\REDACTED\Downloads\LoadLibrary\Crash > >> > >> VM Arguments: > >> jvm_args: --enable-preview > >> java_command: Crash > >> java_class_path (initial): C:/Users/REDACTED/Downloads/LoadLibrary/Crash > >> Launcher Type: SUN_STANDARD > >> > >> [Global flags] > >> uint ConcGCThreads = 5 > >> {product} {ergonomic} > >> uint G1ConcRefinementThreads = 18 > >> {product} {ergonomic} > >> size_t G1HeapRegionSize = 2097152 > >> {product} {ergonomic} > >> size_t InitialHeapSize = 255852544 > >> {product} {ergonomic} > >> size_t MarkStackSize = 4194304 > >> {product} {ergonomic} > >> size_t MarkStackSizeMax = 536870912 > >> {product} {ergonomic} > >> size_t MaxHeapSize = 4085252096 > >> {product} {ergonomic} > >> size_t MaxNewSize = 2449473536 > >> {product} {ergonomic} > >> size_t MinHeapDeltaBytes = 2097152 > >> {product} {ergonomic} > >> size_t MinHeapSize = 8388608 > >> {product} {ergonomic} > >> uintx NonNMethodCodeHeapSize = 4096 > >> {pd product} {ergonomic} > >> uintx NonProfiledCodeHeapSize = 0 > >> {pd product} {ergonomic} > >> uintx ProfiledCodeHeapSize = 0 > >> {pd product} {ergonomic} > >> size_t SoftMaxHeapSize = 4085252096 > >> {manageable} {ergonomic} > >> bool UseCompressedOops = true > >> {product lp64_product} {ergonomic} > >> bool UseG1GC = true > >> {product} {ergonomic} > >> bool UseLargePagesIndividualAllocation = false > >> {pd product} {ergonomic} > >> > >> Logging: > >> Log output configuration: > >> #0: stdout all=warning uptime,level,tags foldmultilines=false > >> #1: stderr all=off uptime,level,tags foldmultilines=false > >> > >> Release file: > >> IMPLEMENTOR="N/A" > >> JAVA_RUNTIME_VERSION="25-internal" > >> JAVA_VERSION="25" > >> JAVA_VERSION_DATE="2025-09-16" > >> LIBC="default" > >> MODULES="java.base java.compiler java.datatransfer java.xml java.prefs > >> java.desktop java.instrument java.logging java.management > >> java.security.sasl java.naming java.rmi java.management.rmi > >> java.net.http java.scripting java.security.jgss java.transaction.xa > >> java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio > >> jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets > >> jdk.internal.opt jdk.zipfs jdk.compiler jdk.crypto.cryptoki > >> jdk.crypto.ec jdk.crypto.mscapi jdk.dynalink jdk.internal.ed > >> jdk.editpad jdk.httpserver jdk.incubator.vector jdk.internal.le > >> jdk.internal.md jdk.jartool jdk.javadoc jdk.jcmd jdk.management > >> jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi > >> jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd > >> jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi > >> jdk.net jdk.nio.mapmode jdk.sctp jdk.security.auth jdk.security.jgss > >> jdk.unsupported jdk.unsupported.desktop jdk.xml.dom" > >> OS_ARCH="x86_64" > >> OS_NAME="Windows" > >> SOURCE=".:git:8f7652d7a36b+" > >> > >> Environment Variables: > >> > PATH=C:\msys64\ucrt64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl > >> USERNAME=REDACTED > >> SHELL=C:\msys64\usr\bin\bash.exe > >> LC_CTYPE=en_US.UTF-8 > >> TERM=xterm > >> OS=Windows_NT > >> PROCESSOR_IDENTIFIER=AMD64 Family 25 Model 97 Stepping 2, AuthenticAMD > >> TMP=C:\msys64\tmp > >> TEMP=C:\msys64\tmp > >> > >> > >> > >> > >> Compilation memory statistics disabled. > >> > >> Periodic native trim disabled > >> > >> --------------- S Y S T E M --------------- > >> > >> OS: > >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) > >> OS uptime: 0 days 1:47 hours > >> > >> CPU: total 24 (initial active 24) > >> Processor Information for processor 0 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 1 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 2 > >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 > >> Processor Information for processor 3 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 4 > >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 > >> Processor Information for processor 5 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 6 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 7 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 8 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 9 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 10 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 11 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 12 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 13 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 14 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 15 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 16 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 17 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 18 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 19 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 20 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 21 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 22 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> Processor Information for processor 23 > >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 > >> > >> Memory: 4k page, system-wide physical 15578M (1690M free) > >> TotalPageFile size 44250M (AvailPageFile size 20548M) > >> current process WorkingSet (physical memory assigned to process): 64M, > peak: 64M > >> current process commit charge ("private bytes"): 373M, peak: 373M > >> > >> vm_info: Java HotSpot 64-Bit Zero VM (25-internal) for windows-amd64 > >> JRE (25-internal), built on 2025-04-17T14:32:22Z with MS VC++ 17.8 > >> (VS2022) > >> > >> END. > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-161-Note: > >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:162:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): > >> warning C5030: attribute [[gnu::packed]] is not recognized > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-320-Note: > >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:321:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log-13-Note: > >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:15:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:16:jdk\src\hotspot\cpu\zero\interpreterRT_zero.cpp(161): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-168-Note: > >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:169:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): > >> warning C5030: attribute [[gnu::packed]] is not recognized > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-307-Note: > >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:308:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log-7-Note: > >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:8:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:9:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:10:jdk\src\hotspot\cpu\zero\stack_zero.cpp(36): > >> warning C4267: '=': conversion from 'size_t' to 'int', possible loss > >> of data > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log-12-Note: > >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:13:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log-28-Note: > >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:29:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:30:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): > >> warning C4267: 'initializing': conversion from 'size_t' to 'int', > >> possible loss of data > >> > >> Generating code > >> Previous IPDB not found, fall back to full compilation. > >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning > >> C4723: potential divide by 0 > >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning > >> C4723: potential divide by 0 > >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning > >> C4723: potential divide by 0 > >> All 52893 functions were compiled because no usable IPDB/IOBJ from > >> previous compilation was found. > >> Finished generating code > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.barrett at oracle.com Thu Apr 24 14:59:08 2025 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 24 Apr 2025 10:59:08 -0400 Subject: Windows/Zero In-Reply-To: References: Message-ID: <946aaf6f-9920-4305-a395-b9ef74f14b9e@oracle.com> On 4/22/25 8:46 AM, Julian Waters wrote: > Hi all, > > Zero currently cannot compile on Windows, and to my knowledge, has > never been able to compile on Windows. [...] > > I started work again recently to get Zero working with VC. [...] > > I'd like to float the idea of supporting Windows/Zero properly. > [...] > > > Thoughts? Quoting from https://openjdk.org/jeps/479 "Remove the Windows 32-bit x86 Port": "Windows 10, the last Windows operating system to support 32-bit operation, will reach End of Life in October 2025." That suggests the community of 32-bit Windows users is very small, and will only get smaller. The delivery of that JEP and the fact that zero has never worked on Windows at all suggests the community of 32-bit Windows users with new development needs is essentially nonexistent. So providing a way to run new versions of Java on 32-bit Windows doesn't seem to me to be at all motivating. A port needs an active community to be considered alive and supported. I don't see that here. All I see is potential costs, with no demonstrated gain. I don't think "Ideally, Zero should run on any platform, so it not running on Windows would be surprising" is a good reason. I think the purpose of zero is to provide a stepping stone toward support for a new platform where none currently exists. That's not what we have here. The addition of zero-specific conditionalization in shared code in this work seems quite suspicious, given that zero currently works for non-Windows. Sorry to be raining on your parade, but this doesn't seem useful to me. From thomas.stuefe at gmail.com Thu Apr 24 14:50:43 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 24 Apr 2025 16:50:43 +0200 Subject: Windows/Zero In-Reply-To: References: Message-ID: 32-bit zero build is broken and has been broken for months at least, maybe a lot longer. Nobody seems to even notice. See also discussion about the future of 32-bit, started here: https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009889.html And without 32-bit, the argument for Windows Zero is getting thin. On Thu, Apr 24, 2025 at 2:52?PM David Alayachew wrote: > I'm in support of this. > > Now that 32-bit options just got removed, Zero is all we have for those of > us on 32-bit hardware. So, having another option sounds just fine for me. > > On Thu, Apr 24, 2025, 7:49?AM Julian Waters > wrote: > >> Hi Thomas, sorry for the late reply, >> >> Off the top of my head, the Zero JVM is extremely small and could be >> useful in environments where a small JVM is needed. More importantly, >> it may (Although I have not verified this yet) allow Java to run on 32 >> bit Windows again, at no additional cost to maintenance since Zero >> itself requires no extra 32 bit support, it's just compile and run. It >> can help if you're working on other parts of the JDK and don't care >> about the JVM, and just want it to compile and link quickly so you can >> get to testing out the changes in the non JVM area of the JDK you're >> working on at the moment, something that I do commonly. I guess the >> process of supporting Windows/Zero also helped eliminate non standard >> zero size arrays in HotSpot, though this may not be that big of a >> deal. Regardless, I'm just curious if there is interest in it from >> anyone at the moment. >> >> Have a great rest of the week ahead! >> >> best regards, >> Julian >> >> On Tue, Apr 22, 2025 at 9:35?PM Thomas St?fe >> wrote: >> > >> > Hi Julian, >> > >> > I am curious, what would be the use case for Windows+Zero? >> > >> > Zero is typically used for bootstrapping new platforms/CPUs. The >> Windows CPU set is very stable, and Windows is not the platform anyone >> starts porting to if they start working on a new platform. Additionally, >> Microsoft usually takes care of porting in the once-a-decade-rare case that >> a new CPU is supported on Windows. >> > >> > Cheers, Thomas >> > >> > >> > On Tue, Apr 22, 2025 at 2:47?PM Julian Waters >> wrote: >> >> >> >> Hi all, >> >> >> >> Zero currently cannot compile on Windows, and to my knowledge, has >> >> never been able to compile on Windows. This is largely due to Windows >> >> lacking crucial implementations for Zero under the os_cpu directory, >> >> where you will notice a distinct lack of a windows_zero directory. To >> >> remedy this, some time ago, I implemented Zero on Windows. The >> >> implementation, aside from adding critical code to windows_zero, also >> >> had to ifdef some code out of the Windows Structured Exception filter. >> >> It was surprisingly minimal, but the downside is that Windows/Zero >> >> then only compiled with gcc. VC had an additional hurdle to jump >> >> through: On Zero, since there are no registers, register arrays in >> >> certain classes became zero sized arrays, a GNU extension that VC will >> >> never accept under any circumstances. >> >> >> >> I started work again recently to get Zero working with VC. Just 2 days >> >> ago, this successfully compiled with VC, albeit with >> >> --disable-warnings-as-errors. The code is available at >> >> https://github.com/TheShermanTanker/jdk/commits/experimental for >> >> anyone curious, under "Windows/Zero Port". Disclaimer: I do not know >> >> whether the code is 100% correct, I may have implemented it wrongly. >> >> The remaining warnings left over can be seen below this mail. Note >> >> that only the release configuration was tested, fastdebug has not been >> >> compiled yet. >> >> >> >> I'd like to float the idea of supporting Windows/Zero properly. >> >> Ideally, Zero should run on any platform, so it not running on Windows >> >> would be surprising, but past that, the Java Zero VM is extremely >> >> small on Windows at just 5MB (Even smaller than the Python >> >> Interpreter!), so it could be useful on devices where a small Java VM >> >> is desired. More importantly, this could (Although I am not fully >> >> certain) open the door to running the latest Java on 32 bit Windows >> >> devices again, ever since all the x86 32 bit ports were removed, >> >> leaving Zero as the only way to execute Java on 32 bit x86. This may >> >> (or may not) help those who cannot get a 64 bit device or one that's >> >> running Linux, I haven't checked yet. >> >> >> >> I also crashed the VM on purpose to get a hserr file which contains VM >> >> information, this can be seen below. This was quite interesting, as >> >> I've never actually seen Zero crash before! >> >> >> >> Thoughts? >> >> >> >> best regards, >> >> Julian >> >> >> >> # >> >> # A fatal error has been detected by the Java Runtime Environment: >> >> # >> >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd1518139f, >> >> pid=335696, tid=337452 >> >> # >> >> # JRE version: Java Runtime Environment (25.0) (build 25-internal) >> >> # Java VM: Java HotSpot 64-Bit Zero VM (25-internal, interpreted mode, >> >> sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64) >> >> # Problematic frame: >> >> # C [Crash.dll+0x139f] >> >> # >> >> # No core dump will be written. Minidumps are not enabled by default >> >> on client versions of Windows >> >> # >> >> # If you would like to submit a bug report, please visit: >> >> # https://bugreport.java.com/bugreport/crash.jsp >> >> # The crash happened outside the Java Virtual Machine in native code. >> >> # See problematic frame for where to report the bug. >> >> # >> >> >> >> --------------- S U M M A R Y ------------ >> >> >> >> Command Line: --enable-preview Crash >> >> >> >> Host: AMD Ryzen 9 7845HX with Radeon Graphics , 24 cores, 15G, >> >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) >> >> Time: Sun Apr 20 03:44:08 2025 Malay Peninsula Standard Time elapsed >> >> time: 0.291582 seconds (0d 0h 0m 0s) >> >> >> >> --------------- T H R E A D --------------- >> >> >> >> Current thread (0x00000268e57a3d20): JavaThread "main" >> >> [_thread_in_native, id=337452, >> >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] >> >> >> >> Stack: [0x000000ae07a00000,0x000000ae07b00000], >> >> sp=0x000000ae07a842a0, free space=528k >> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, >> C=native code) >> >> C [Crash.dll+0x139f] (no source info available) >> >> C [libffi-8.dll+0x4cc1] (no source info available) >> >> C [libffi-8.dll+0x48df] (no source info available) >> >> C [libffi-8.dll+0x4aa2] (no source info available) >> >> V [jvm.dll+0x426645] ZeroInterpreter::native_entry+0x455 >> >> (zeroInterpreter_zero.cpp:444) >> >> V [jvm.dll+0x425f47] ZeroInterpreter::main_loop+0x127 >> >> (zeroInterpreter_zero.cpp:227) >> >> V [jvm.dll+0x425d96] ZeroInterpreter::normal_entry+0x36 >> >> (zeroInterpreter_zero.cpp:115) >> >> V [jvm.dll+0x3b156d] StubGenerator::call_stub+0x1bd >> >> (stubGenerator_zero.cpp:84) >> >> V [jvm.dll+0x1acbfd] JavaCalls::call_helper+0x48d >> (javaCalls.cpp:424) >> >> V [jvm.dll+0x2e4c80] os::os_exception_wrapper+0x20 >> (os_windows_zero.cpp:51) >> >> V [jvm.dll+0x1c472a] jni_invoke_nonstatic+0x32a (jni.cpp:950) >> >> V [jvm.dll+0x1c8ea2] jni_CallVoidMethod+0x142 (jni.cpp:1307) >> >> C [jli.dll+0x510f] JavaMain+0x7d3 (java.c:645) >> >> C [ucrtbase.dll+0x37b0] (no source info available) >> >> C [KERNEL32.DLL+0x2e8d7] (no source info available) >> >> C [ntdll.dll+0xb14fc] (no source info available) >> >> >> >> Java frames: >> >> 0x000000ae07aff8f0: unboxed parameter[1] = 0x000000ae07aff9a0 >> >> 0x000000ae07aff8f8: parameter[0] (JNIEnv) = 0x000000ae07a84410 >> >> 0x000000ae07aff900: parameter[1] (this) = 0x000000ae07aff8f0 >> >> 0x000000ae07aff908: istate->_thread = 0x00000268e57a3d20 >> >> 0x000000ae07aff910: istate->_bcp = 0x0000000000000000 >> >> 0x000000ae07aff918: istate->_locals = 0x000000ae07aff9a0 >> >> 0x000000ae07aff920: istate->_constants = 0x00000268c14003a8 >> >> 0x000000ae07aff928: istate->_method = Crash.crash()V >> >> 0x000000ae07aff930: istate->_mirror = 0x000000071ba1cb90 >> >> 0x000000ae07aff938: istate->_stack = 0x000000ae07aff900 >> >> 0x000000ae07aff940: istate->_msg = 0x0000026800000002 >> >> 0x000000ae07aff948: istate->_result = 0x0000000000000000 >> >> 0x000000ae07aff950: (istate->_result) = 0x000000ae00000003 >> >> 0x000000ae07aff958: (istate->_result) = 0x0000000000000000 >> >> 0x000000ae07aff960: istate->_prev_link = 0x0000000000000000 >> >> 0x000000ae07aff968: istate->_oop_temp = 0x0000000000000000 >> >> 0x000000ae07aff970: istate->_stack_base = 0x000000ae07aff908 >> >> 0x000000ae07aff978: istate->_stack_limit = 0x000000ae07aff900 >> >> 0x000000ae07aff980: istate->_monitor_base = 0x000000ae07aff908 >> >> 0x000000ae07aff988: istate->_self_link = 0x000000ae07aff908 >> >> 0x000000ae07aff990: frame_type = INTERPRETER_FRAME >> >> 0x000000ae07aff998: next_frame = 0x000000ae07affa38 >> >> >> >> 0x000000ae07aff9a0: local[0] = 0x000000071ba1d940 >> >> 0x000000ae07aff9a8: istate->_thread = 0x00000268e57a3d20 >> >> 0x000000ae07aff9b0: istate->_bcp = 0x00000268c14002de (bci 6) >> >> 0x000000ae07aff9b8: istate->_locals = 0x000000ae07affa40 >> >> 0x000000ae07aff9c0: istate->_constants = 0x00000268c14003a8 >> >> 0x000000ae07aff9c8: istate->_method = Crash.main()V >> >> 0x000000ae07aff9d0: istate->_mirror = 0x000000071ba1cb90 >> >> 0x000000ae07aff9d8: istate->_stack = 0x000000ae07aff998 >> >> 0x000000ae07aff9e0: istate->_msg = 0x0000026800000008 >> >> 0x000000ae07aff9e8: istate->_result = 0x00000268c1400238 >> >> 0x000000ae07aff9f0: (istate->_result) = 0x00000268f1e90458 >> >> 0x000000ae07aff9f8: (istate->_result) = 0x0000000000000003 >> >> 0x000000ae07affa00: istate->_prev_link = 0x0000000000000000 >> >> 0x000000ae07affa08: istate->_oop_temp = 0x0000000000000000 >> >> 0x000000ae07affa10: istate->_stack_base = 0x000000ae07aff9a8 >> >> 0x000000ae07affa18: istate->_stack_limit = 0x000000ae07aff990 >> >> 0x000000ae07affa20: istate->_monitor_base = 0x000000ae07aff9a8 >> >> 0x000000ae07affa28: istate->_self_link = 0x000000ae07aff9a8 >> >> 0x000000ae07affa30: frame_type = INTERPRETER_FRAME >> >> 0x000000ae07affa38: next_frame = 0x000000ae07affa58 >> >> >> >> 0x000000ae07affa40: local[0] = 0x000000071ba1d940 >> >> 0x000000ae07affa48: call_wrapper = 0x000000ae07affaf0 >> >> 0x000000ae07affa50: frame_type = ENTRY_FRAME >> >> 0x000000ae07affa58: next_frame = 0x0000000000000000 >> >> >> >> >> >> siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address >> >> 0x0000000000000000 >> >> >> >> >> >> No context information. >> >> >> >> Register to memory mapping: >> >> >> >> No register info. >> >> >> >> Top of Stack: (sp=0x000000ae07a842a0) >> >> 0x000000ae07a842a0: 00000000000003d8 0000000000000000 >> ................ >> >> 0x000000ae07a842b0: 0000000000000000 00007ffd16d748df >> .........H...... >> >> 0x000000ae07a842c0: 000002688046f350 0000000000000000 >> P.F.h........... >> >> 0x000000ae07a842d0: 000000ae07a84300 00007ffd16d74cc1 >> .C.......L...... >> >> 0x000000ae07a842e0: 00000268e57a4028 000000ae07aff9a0 >> (@z.h........... >> >> 0x000000ae07a842f0: 0000000000000001 0000000000000050 >> ........P....... >> >> 0x000000ae07a84300: 000000ae07a84350 00007ffd16d748df >> PC.......H...... >> >> 0x000000ae07a84310: 00007ffd15181380 0000000000000000 >> ................ >> >> 0x000000ae07a84320: 000000ae07a84400 0000000000000000 >> .D.............. >> >> 0x000000ae07a84330: 0000000000000001 0000000000000000 >> ................ >> >> 0x000000ae07a84340: 00001664b4a8ce49 111f221225371f8f >> I...d.....7%.".. >> >> 0x000000ae07a84350: 00000268802416f0 00000268e57a3d20 ..$.h... >> =z.h... >> >> 0x000000ae07a84360: 00000268c1400238 000000ae07aff908 8.@ >> .h........... >> >> 0x000000ae07a84370: 000000ae07aff9a0 000000ae07aff998 >> ................ >> >> 0x000000ae07a84380: 00000268f1e98710 0000000000000000 >> ....h........... >> >> 0x000000ae07a84390: 000000ae07a84440 00007ffd16d74aa2 >> @D.......J...... >> >> 0x000000ae07a843a0: 0000000000000000 0000000000000001 >> ................ >> >> 0x000000ae07a843b0: 0000000000000000 000000ae07aff998 >> ................ >> >> 0x000000ae07a843c0: 0000000000000000 0000000000000000 >> ................ >> >> 0x000000ae07a843d0: 000000ae07a84440 00007ffceb326645 >> @D......Ef2..... >> >> 0x000000ae07a843e0: 00007ffceb482058 00000268e57a3d20 X H..... >> =z.h... >> >> 0x000000ae07a843f0: 00000268c1400238 00000268e57a3d20 8. at .h... >> =z.h... >> >> 0x000000ae07a84400: 000000ae07aff990 000000ae07aff8f8 >> ................ >> >> 0x000000ae07a84410: 00000268e57a4028 0000000000000000 >> (@z.h........... >> >> 0x000000ae07a84420: 00007ffd15181380 0000000000000000 >> ................ >> >> 0x000000ae07a84430: 00000268c1400238 00000268e57a3d20 8. at .h... >> =z.h... >> >> 0x000000ae07a84440: 0000000000000001 0000000000000000 >> ................ >> >> 0x000000ae07a84450: 0000000000000000 0000000000000000 >> ................ >> >> 0x000000ae07a84460: 0000000000000000 000000ae07affa38 >> ........8....... >> >> 0x000000ae07a84470: 00000268c14002e8 00007ffceb325f47 >> .. at .h...G_2..... >> >> 0x000000ae07a84480: 00000268e57a3d20 00000268e57a3d20 =z.h... >> =z.h... >> >> 0x000000ae07a84490: 000000ae00084b70 0000000000000000 >> pK.............. >> >> >> >> Instructions: (pc=0x00007ffd1518139f) >> >> 0x00007ffd1518129f: 00 e8 bb 0e 00 00 41 89 c4 83 fb 03 75 86 e9 5a >> >> 0x00007ffd151812af: ff ff ff 66 0f 1f 44 00 00 83 fb 01 0f 85 6f ff >> >> 0x00007ffd151812bf: ff ff 49 89 f8 31 d2 48 89 f1 e8 42 fd ff ff e9 >> >> 0x00007ffd151812cf: 5d ff ff ff 0f 1f 44 00 00 e8 93 01 00 00 49 89 >> >> 0x00007ffd151812df: f8 ba 01 00 00 00 48 89 f1 e8 73 0e 00 00 41 89 >> >> 0x00007ffd151812ef: c4 85 c0 0f 85 3b ff ff ff 49 89 f8 31 d2 48 89 >> >> 0x00007ffd151812ff: f1 e8 5b 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 3e >> >> 0x00007ffd1518130f: 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 f1 fc ff ff >> >> 0x00007ffd1518131f: e9 0f ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 >> >> 0x00007ffd1518132f: 90 48 8b 05 b9 82 00 00 c7 00 00 00 00 00 e9 8e >> >> 0x00007ffd1518133f: fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f >> >> 0x00007ffd1518134f: 00 48 89 ca 48 8d 0d a6 ac 00 00 e9 f9 62 00 00 >> >> 0x00007ffd1518135f: 90 48 8d 0d 09 00 00 00 e9 e4 ff ff ff 0f 1f 40 >> >> 0x00007ffd1518136f: 00 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 >> >> 0x00007ffd1518137f: 90 55 48 89 e5 48 83 ec 30 48 c7 45 f8 00 00 00 >> >> 0x00007ffd1518138f: 00 48 8b 45 f8 48 8b 45 f8 48 8d 0d 61 7c 00 00 >> >> =>0x00007ffd1518139f: 8b 10 e8 ca 0d 00 00 48 8d 0d 56 7c 00 00 48 83 >> >> 0x00007ffd151813af: c4 30 5d e9 59 63 00 00 90 90 90 90 90 90 90 90 >> >> 0x00007ffd151813bf: 90 48 83 ec 28 48 8b 05 45 6c 00 00 48 8b 00 48 >> >> 0x00007ffd151813cf: 85 c0 74 22 0f 1f 44 00 00 ff d0 48 8b 05 2f 6c >> >> 0x00007ffd151813df: 00 00 48 8d 50 08 48 8b 40 08 48 89 15 20 6c 00 >> >> 0x00007ffd151813ef: 00 48 85 c0 75 e3 48 83 c4 28 c3 66 0f 1f 44 00 >> >> 0x00007ffd151813ff: 00 56 53 48 83 ec 28 48 8b 15 83 81 00 00 48 8b >> >> 0x00007ffd1518140f: 02 89 c1 83 f8 ff 74 39 85 c9 74 20 89 c8 83 e9 >> >> 0x00007ffd1518141f: 01 48 8d 1c c2 48 29 c8 48 8d 74 c2 f8 0f 1f 40 >> >> 0x00007ffd1518142f: 00 ff 13 48 83 eb 08 48 39 f3 75 f5 48 8d 0d 7e >> >> 0x00007ffd1518143f: ff ff ff 48 83 c4 28 5b 5e e9 03 ff ff ff 0f 1f >> >> 0x00007ffd1518144f: 00 31 c0 66 0f 1f 44 00 00 44 8d 40 01 89 c1 4a >> >> 0x00007ffd1518145f: 83 3c c2 00 4c 89 c0 75 f0 eb ad 66 0f 1f 44 00 >> >> 0x00007ffd1518146f: 00 8b 05 aa ab 00 00 85 c0 74 06 c3 0f 1f 44 00 >> >> 0x00007ffd1518147f: 00 c7 05 96 ab 00 00 01 00 00 00 e9 71 ff ff ff >> >> 0x00007ffd1518148f: 90 83 fa 03 74 0b 85 d2 74 07 c3 66 0f 1f 44 00 >> >> >> >> >> >> Stack slot to memory mapping: >> >> >> >> stack at sp + 0 slots: 0x00000000000003d8 is an unknown value >> >> stack at sp + 1 slots: 0x0 is null >> >> stack at sp + 2 slots: 0x0 is null >> >> stack at sp + 3 slots: 0x00007ffd16d748df libffi-8.dll >> >> stack at sp + 4 slots: {method} {0x000002688046f358} 'loadLibrary' >> >> >> '(Ljava/lang/Class;Ljava/lang/String;)Ljdk/internal/loader/NativeLibrary;' >> >> in 'java/lang/ClassLoader' >> >> stack at sp + 5 slots: 0x0 is null >> >> stack at sp + 6 slots: 0x000000ae07a84300 is pointing into the stack >> >> for thread: 0x00000268e57a3d20 >> >> stack at sp + 7 slots: 0x00007ffd16d74cc1 libffi-8.dll >> >> >> >> Lock stack of current Java thread (top to bottom): >> >> >> >> >> >> --------------- P R O C E S S --------------- >> >> >> >> Threads class SMR info: >> >> _java_thread_list=0x00000268fc0d5850, length=9, elements={ >> >> 0x00000268e57a3d20, 0x00000268fc08cfc0, 0x00000268fc08d5f0, >> 0x00000268fc091710, >> >> 0x00000268fc092140, 0x00000268fc0936e0, 0x00000268fc09d2a0, >> 0x00000268fc0d8ec0, >> >> 0x00000268fc0de6e0 >> >> } >> >> >> >> Java Threads: ( => current thread ) >> >> =>0x00000268e57a3d20 JavaThread "main" >> >> [_thread_in_native, id=337452, >> >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] >> >> 0x00000268fc08cfc0 JavaThread "Reference Handler" daemon >> >> [_thread_blocked, id=337356, >> >> stack(0x000000ae08200000,0x000000ae08300000) (1024K)] >> >> 0x00000268fc08d5f0 JavaThread "Finalizer" daemon >> >> [_thread_blocked, id=338708, >> >> stack(0x000000ae08300000,0x000000ae08400000) (1024K)] >> >> 0x00000268fc091710 JavaThread "Signal Dispatcher" daemon >> >> [_thread_blocked, id=338204, >> >> stack(0x000000ae08400000,0x000000ae08500000) (1024K)] >> >> 0x00000268fc092140 JavaThread "Attach Listener" daemon >> >> [_thread_blocked, id=338748, >> >> stack(0x000000ae08500000,0x000000ae08600000) (1024K)] >> >> 0x00000268fc0936e0 JavaThread "Service Thread" daemon >> >> [_thread_blocked, id=337172, >> >> stack(0x000000ae08600000,0x000000ae08700000) (1024K)] >> >> 0x00000268fc09d2a0 JavaThread "Monitor Deflation Thread" daemon >> >> [_thread_blocked, id=337312, >> >> stack(0x000000ae08700000,0x000000ae08800000) (1024K)] >> >> 0x00000268fc0d8ec0 JavaThread "Notification Thread" daemon >> >> [_thread_blocked, id=337560, >> >> stack(0x000000ae08800000,0x000000ae08900000) (1024K)] >> >> 0x00000268fc0de6e0 JavaThread "Common-Cleaner" daemon >> >> [_thread_blocked, id=338324, >> >> stack(0x000000ae08900000,0x000000ae08a00000) (1024K)] >> >> Total: 9 >> >> >> >> Other Threads: >> >> 0x00000268fc07c960 VMThread "VM Thread" >> >> [id=337424, stack(0x000000ae08100000,0x000000ae08200000) (1024K)] >> >> 0x00000268fbf41360 WatcherThread "VM Periodic Task Thread" >> >> [id=333244, stack(0x000000ae08000000,0x000000ae08100000) (1024K)] >> >> 0x00000268e7d7d550 WorkerThread "GC Thread#0" >> >> [id=336784, stack(0x000000ae07b00000,0x000000ae07c00000) (1024K)] >> >> 0x00000268e7d951c0 ConcurrentGCThread "G1 Main Marker" >> >> [id=338660, stack(0x000000ae07c00000,0x000000ae07d00000) (1024K)] >> >> 0x00000268e7d96850 WorkerThread "G1 Conc#0" >> >> [id=19564, stack(0x000000ae07d00000,0x000000ae07e00000) (1024K)] >> >> 0x00000268fbf39000 ConcurrentGCThread "G1 Refine#0" >> >> [id=217884, stack(0x000000ae07e00000,0x000000ae07f00000) (1024K)] >> >> 0x00000268fbf39780 ConcurrentGCThread "G1 Service" >> >> [id=338408, stack(0x000000ae07f00000,0x000000ae08000000) (1024K)] >> >> Total: 7 >> >> >> >> Threads with active compile tasks: >> >> Total: 0 >> >> >> >> VM state: not at safepoint (normal execution) >> >> >> >> VM Mutex/Monitor currently owned by a thread: None >> >> >> >> Heap address: 0x000000070c800000, size: 3896 MB, Compressed Oops mode: >> >> Zero based, Oop shift amount: 3 >> >> >> >> CDS archive(s) mapped at: >> >> [0x0000026880000000-0x0000026880d30000-0x0000026880d30000), size >> >> 13828096, SharedBaseAddress: 0x0000026880000000, >> >> ArchiveRelocationMode: 1. >> >> Compressed class space mapped at: >> >> 0x0000026881000000-0x00000268c1000000, reserved size: 1073741824 >> >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 >> >> Narrow klass pointer bits 32, Max shift 3 >> >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 >> >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 >> bytes) >> >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 >> bytes) >> >> Klass ID Range: [65536 - 1090519033) (1090453497) >> >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 >> bytes) >> >> >> >> GC Precious Log: >> >> CardTable entry size: 512 >> >> Card Set container configuration: InlinePtr #cards 4 size 8 Array Of >> >> Cards #cards 16 size 48 Howl #buckets 8 coarsen threshold 3686 Howl >> >> Bitmap #cards 512 size 80 coarsen threshold 460 Card regions per heap >> >> region 1 cards per card region 4096 >> >> CPUs: 24 total, 24 available >> >> Memory: 15578M >> >> Large Page Support: Disabled >> >> NUMA Support: Disabled >> >> Compressed Oops: Enabled (Zero based) >> >> Heap Region Size: 2M >> >> Heap Min Capacity: 8M >> >> Heap Initial Capacity: 244M >> >> Heap Max Capacity: 3896M >> >> Pre-touch: Disabled >> >> Parallel Workers: 18 >> >> Concurrent Workers: 5 >> >> Concurrent Refinement Workers: 18 >> >> Periodic GC: Disabled >> >> >> >> Heap: >> >> garbage-first heap total reserved 3989504K, committed 251904K, used >> >> 1136K [0x000000070c800000, 0x0000000800000000) >> >> region size 2048K, 1 young (2048K), 0 survivors (0K) >> >> Metaspace used 21K, committed 256K, reserved 1114112K >> >> class space used 6K, committed 128K, reserved 1048576K >> >> >> >> Heap Regions: E=young(eden), S=young(survivor), O=old, >> >> HS=humongous(starts), HC=humongous(continues), CS=collection set, >> >> F=free, TAMS=top-at-mark-start, PB=parsable bottom >> >> | 0|0x000000070c800000, 0x000000070c800000, 0x000000070ca00000| 0%| >> >> F| |TAMS 0x000000070c800000| PB 0x000000070c800000| Untracked | 0 >> >> | 1|0x000000070ca00000, 0x000000070ca00000, 0x000000070cc00000| 0%| >> >> F| |TAMS 0x000000070ca00000| PB 0x000000070ca00000| Untracked | 0 >> >> | 2|0x000000070cc00000, 0x000000070cc00000, 0x000000070ce00000| 0%| >> >> F| |TAMS 0x000000070cc00000| PB 0x000000070cc00000| Untracked | 0 >> >> | 3|0x000000070ce00000, 0x000000070ce00000, 0x000000070d000000| 0%| >> >> F| |TAMS 0x000000070ce00000| PB 0x000000070ce00000| Untracked | 0 >> >> | 4|0x000000070d000000, 0x000000070d000000, 0x000000070d200000| 0%| >> >> F| |TAMS 0x000000070d000000| PB 0x000000070d000000| Untracked | 0 >> >> | 5|0x000000070d200000, 0x000000070d200000, 0x000000070d400000| 0%| >> >> F| |TAMS 0x000000070d200000| PB 0x000000070d200000| Untracked | 0 >> >> | 6|0x000000070d400000, 0x000000070d400000, 0x000000070d600000| 0%| >> >> F| |TAMS 0x000000070d400000| PB 0x000000070d400000| Untracked | 0 >> >> | 7|0x000000070d600000, 0x000000070d600000, 0x000000070d800000| 0%| >> >> F| |TAMS 0x000000070d600000| PB 0x000000070d600000| Untracked | 0 >> >> | 8|0x000000070d800000, 0x000000070d800000, 0x000000070da00000| 0%| >> >> F| |TAMS 0x000000070d800000| PB 0x000000070d800000| Untracked | 0 >> >> | 9|0x000000070da00000, 0x000000070da00000, 0x000000070dc00000| 0%| >> >> F| |TAMS 0x000000070da00000| PB 0x000000070da00000| Untracked | 0 >> >> | 10|0x000000070dc00000, 0x000000070dc00000, 0x000000070de00000| 0%| >> >> F| |TAMS 0x000000070dc00000| PB 0x000000070dc00000| Untracked | 0 >> >> | 11|0x000000070de00000, 0x000000070de00000, 0x000000070e000000| 0%| >> >> F| |TAMS 0x000000070de00000| PB 0x000000070de00000| Untracked | 0 >> >> | 12|0x000000070e000000, 0x000000070e000000, 0x000000070e200000| 0%| >> >> F| |TAMS 0x000000070e000000| PB 0x000000070e000000| Untracked | 0 >> >> | 13|0x000000070e200000, 0x000000070e200000, 0x000000070e400000| 0%| >> >> F| |TAMS 0x000000070e200000| PB 0x000000070e200000| Untracked | 0 >> >> | 14|0x000000070e400000, 0x000000070e400000, 0x000000070e600000| 0%| >> >> F| |TAMS 0x000000070e400000| PB 0x000000070e400000| Untracked | 0 >> >> | 15|0x000000070e600000, 0x000000070e600000, 0x000000070e800000| 0%| >> >> F| |TAMS 0x000000070e600000| PB 0x000000070e600000| Untracked | 0 >> >> | 16|0x000000070e800000, 0x000000070e800000, 0x000000070ea00000| 0%| >> >> F| |TAMS 0x000000070e800000| PB 0x000000070e800000| Untracked | 0 >> >> | 17|0x000000070ea00000, 0x000000070ea00000, 0x000000070ec00000| 0%| >> >> F| |TAMS 0x000000070ea00000| PB 0x000000070ea00000| Untracked | 0 >> >> | 18|0x000000070ec00000, 0x000000070ec00000, 0x000000070ee00000| 0%| >> >> F| |TAMS 0x000000070ec00000| PB 0x000000070ec00000| Untracked | 0 >> >> | 19|0x000000070ee00000, 0x000000070ee00000, 0x000000070f000000| 0%| >> >> F| |TAMS 0x000000070ee00000| PB 0x000000070ee00000| Untracked | 0 >> >> | 20|0x000000070f000000, 0x000000070f000000, 0x000000070f200000| 0%| >> >> F| |TAMS 0x000000070f000000| PB 0x000000070f000000| Untracked | 0 >> >> | 21|0x000000070f200000, 0x000000070f200000, 0x000000070f400000| 0%| >> >> F| |TAMS 0x000000070f200000| PB 0x000000070f200000| Untracked | 0 >> >> | 22|0x000000070f400000, 0x000000070f400000, 0x000000070f600000| 0%| >> >> F| |TAMS 0x000000070f400000| PB 0x000000070f400000| Untracked | 0 >> >> | 23|0x000000070f600000, 0x000000070f600000, 0x000000070f800000| 0%| >> >> F| |TAMS 0x000000070f600000| PB 0x000000070f600000| Untracked | 0 >> >> | 24|0x000000070f800000, 0x000000070f800000, 0x000000070fa00000| 0%| >> >> F| |TAMS 0x000000070f800000| PB 0x000000070f800000| Untracked | 0 >> >> | 25|0x000000070fa00000, 0x000000070fa00000, 0x000000070fc00000| 0%| >> >> F| |TAMS 0x000000070fa00000| PB 0x000000070fa00000| Untracked | 0 >> >> | 26|0x000000070fc00000, 0x000000070fc00000, 0x000000070fe00000| 0%| >> >> F| |TAMS 0x000000070fc00000| PB 0x000000070fc00000| Untracked | 0 >> >> | 27|0x000000070fe00000, 0x000000070fe00000, 0x0000000710000000| 0%| >> >> F| |TAMS 0x000000070fe00000| PB 0x000000070fe00000| Untracked | 0 >> >> | 28|0x0000000710000000, 0x0000000710000000, 0x0000000710200000| 0%| >> >> F| |TAMS 0x0000000710000000| PB 0x0000000710000000| Untracked | 0 >> >> | 29|0x0000000710200000, 0x0000000710200000, 0x0000000710400000| 0%| >> >> F| |TAMS 0x0000000710200000| PB 0x0000000710200000| Untracked | 0 >> >> | 30|0x0000000710400000, 0x0000000710400000, 0x0000000710600000| 0%| >> >> F| |TAMS 0x0000000710400000| PB 0x0000000710400000| Untracked | 0 >> >> | 31|0x0000000710600000, 0x0000000710600000, 0x0000000710800000| 0%| >> >> F| |TAMS 0x0000000710600000| PB 0x0000000710600000| Untracked | 0 >> >> | 32|0x0000000710800000, 0x0000000710800000, 0x0000000710a00000| 0%| >> >> F| |TAMS 0x0000000710800000| PB 0x0000000710800000| Untracked | 0 >> >> | 33|0x0000000710a00000, 0x0000000710a00000, 0x0000000710c00000| 0%| >> >> F| |TAMS 0x0000000710a00000| PB 0x0000000710a00000| Untracked | 0 >> >> | 34|0x0000000710c00000, 0x0000000710c00000, 0x0000000710e00000| 0%| >> >> F| |TAMS 0x0000000710c00000| PB 0x0000000710c00000| Untracked | 0 >> >> | 35|0x0000000710e00000, 0x0000000710e00000, 0x0000000711000000| 0%| >> >> F| |TAMS 0x0000000710e00000| PB 0x0000000710e00000| Untracked | 0 >> >> | 36|0x0000000711000000, 0x0000000711000000, 0x0000000711200000| 0%| >> >> F| |TAMS 0x0000000711000000| PB 0x0000000711000000| Untracked | 0 >> >> | 37|0x0000000711200000, 0x0000000711200000, 0x0000000711400000| 0%| >> >> F| |TAMS 0x0000000711200000| PB 0x0000000711200000| Untracked | 0 >> >> | 38|0x0000000711400000, 0x0000000711400000, 0x0000000711600000| 0%| >> >> F| |TAMS 0x0000000711400000| PB 0x0000000711400000| Untracked | 0 >> >> | 39|0x0000000711600000, 0x0000000711600000, 0x0000000711800000| 0%| >> >> F| |TAMS 0x0000000711600000| PB 0x0000000711600000| Untracked | 0 >> >> | 40|0x0000000711800000, 0x0000000711800000, 0x0000000711a00000| 0%| >> >> F| |TAMS 0x0000000711800000| PB 0x0000000711800000| Untracked | 0 >> >> | 41|0x0000000711a00000, 0x0000000711a00000, 0x0000000711c00000| 0%| >> >> F| |TAMS 0x0000000711a00000| PB 0x0000000711a00000| Untracked | 0 >> >> | 42|0x0000000711c00000, 0x0000000711c00000, 0x0000000711e00000| 0%| >> >> F| |TAMS 0x0000000711c00000| PB 0x0000000711c00000| Untracked | 0 >> >> | 43|0x0000000711e00000, 0x0000000711e00000, 0x0000000712000000| 0%| >> >> F| |TAMS 0x0000000711e00000| PB 0x0000000711e00000| Untracked | 0 >> >> | 44|0x0000000712000000, 0x0000000712000000, 0x0000000712200000| 0%| >> >> F| |TAMS 0x0000000712000000| PB 0x0000000712000000| Untracked | 0 >> >> | 45|0x0000000712200000, 0x0000000712200000, 0x0000000712400000| 0%| >> >> F| |TAMS 0x0000000712200000| PB 0x0000000712200000| Untracked | 0 >> >> | 46|0x0000000712400000, 0x0000000712400000, 0x0000000712600000| 0%| >> >> F| |TAMS 0x0000000712400000| PB 0x0000000712400000| Untracked | 0 >> >> | 47|0x0000000712600000, 0x0000000712600000, 0x0000000712800000| 0%| >> >> F| |TAMS 0x0000000712600000| PB 0x0000000712600000| Untracked | 0 >> >> | 48|0x0000000712800000, 0x0000000712800000, 0x0000000712a00000| 0%| >> >> F| |TAMS 0x0000000712800000| PB 0x0000000712800000| Untracked | 0 >> >> | 49|0x0000000712a00000, 0x0000000712a00000, 0x0000000712c00000| 0%| >> >> F| |TAMS 0x0000000712a00000| PB 0x0000000712a00000| Untracked | 0 >> >> | 50|0x0000000712c00000, 0x0000000712c00000, 0x0000000712e00000| 0%| >> >> F| |TAMS 0x0000000712c00000| PB 0x0000000712c00000| Untracked | 0 >> >> | 51|0x0000000712e00000, 0x0000000712e00000, 0x0000000713000000| 0%| >> >> F| |TAMS 0x0000000712e00000| PB 0x0000000712e00000| Untracked | 0 >> >> | 52|0x0000000713000000, 0x0000000713000000, 0x0000000713200000| 0%| >> >> F| |TAMS 0x0000000713000000| PB 0x0000000713000000| Untracked | 0 >> >> | 53|0x0000000713200000, 0x0000000713200000, 0x0000000713400000| 0%| >> >> F| |TAMS 0x0000000713200000| PB 0x0000000713200000| Untracked | 0 >> >> | 54|0x0000000713400000, 0x0000000713400000, 0x0000000713600000| 0%| >> >> F| |TAMS 0x0000000713400000| PB 0x0000000713400000| Untracked | 0 >> >> | 55|0x0000000713600000, 0x0000000713600000, 0x0000000713800000| 0%| >> >> F| |TAMS 0x0000000713600000| PB 0x0000000713600000| Untracked | 0 >> >> | 56|0x0000000713800000, 0x0000000713800000, 0x0000000713a00000| 0%| >> >> F| |TAMS 0x0000000713800000| PB 0x0000000713800000| Untracked | 0 >> >> | 57|0x0000000713a00000, 0x0000000713a00000, 0x0000000713c00000| 0%| >> >> F| |TAMS 0x0000000713a00000| PB 0x0000000713a00000| Untracked | 0 >> >> | 58|0x0000000713c00000, 0x0000000713c00000, 0x0000000713e00000| 0%| >> >> F| |TAMS 0x0000000713c00000| PB 0x0000000713c00000| Untracked | 0 >> >> | 59|0x0000000713e00000, 0x0000000713e00000, 0x0000000714000000| 0%| >> >> F| |TAMS 0x0000000713e00000| PB 0x0000000713e00000| Untracked | 0 >> >> | 60|0x0000000714000000, 0x0000000714000000, 0x0000000714200000| 0%| >> >> F| |TAMS 0x0000000714000000| PB 0x0000000714000000| Untracked | 0 >> >> | 61|0x0000000714200000, 0x0000000714200000, 0x0000000714400000| 0%| >> >> F| |TAMS 0x0000000714200000| PB 0x0000000714200000| Untracked | 0 >> >> | 62|0x0000000714400000, 0x0000000714400000, 0x0000000714600000| 0%| >> >> F| |TAMS 0x0000000714400000| PB 0x0000000714400000| Untracked | 0 >> >> | 63|0x0000000714600000, 0x0000000714600000, 0x0000000714800000| 0%| >> >> F| |TAMS 0x0000000714600000| PB 0x0000000714600000| Untracked | 0 >> >> | 64|0x0000000714800000, 0x0000000714800000, 0x0000000714a00000| 0%| >> >> F| |TAMS 0x0000000714800000| PB 0x0000000714800000| Untracked | 0 >> >> | 65|0x0000000714a00000, 0x0000000714a00000, 0x0000000714c00000| 0%| >> >> F| |TAMS 0x0000000714a00000| PB 0x0000000714a00000| Untracked | 0 >> >> | 66|0x0000000714c00000, 0x0000000714c00000, 0x0000000714e00000| 0%| >> >> F| |TAMS 0x0000000714c00000| PB 0x0000000714c00000| Untracked | 0 >> >> | 67|0x0000000714e00000, 0x0000000714e00000, 0x0000000715000000| 0%| >> >> F| |TAMS 0x0000000714e00000| PB 0x0000000714e00000| Untracked | 0 >> >> | 68|0x0000000715000000, 0x0000000715000000, 0x0000000715200000| 0%| >> >> F| |TAMS 0x0000000715000000| PB 0x0000000715000000| Untracked | 0 >> >> | 69|0x0000000715200000, 0x0000000715200000, 0x0000000715400000| 0%| >> >> F| |TAMS 0x0000000715200000| PB 0x0000000715200000| Untracked | 0 >> >> | 70|0x0000000715400000, 0x0000000715400000, 0x0000000715600000| 0%| >> >> F| |TAMS 0x0000000715400000| PB 0x0000000715400000| Untracked | 0 >> >> | 71|0x0000000715600000, 0x0000000715600000, 0x0000000715800000| 0%| >> >> F| |TAMS 0x0000000715600000| PB 0x0000000715600000| Untracked | 0 >> >> | 72|0x0000000715800000, 0x0000000715800000, 0x0000000715a00000| 0%| >> >> F| |TAMS 0x0000000715800000| PB 0x0000000715800000| Untracked | 0 >> >> | 73|0x0000000715a00000, 0x0000000715a00000, 0x0000000715c00000| 0%| >> >> F| |TAMS 0x0000000715a00000| PB 0x0000000715a00000| Untracked | 0 >> >> | 74|0x0000000715c00000, 0x0000000715c00000, 0x0000000715e00000| 0%| >> >> F| |TAMS 0x0000000715c00000| PB 0x0000000715c00000| Untracked | 0 >> >> | 75|0x0000000715e00000, 0x0000000715e00000, 0x0000000716000000| 0%| >> >> F| |TAMS 0x0000000715e00000| PB 0x0000000715e00000| Untracked | 0 >> >> | 76|0x0000000716000000, 0x0000000716000000, 0x0000000716200000| 0%| >> >> F| |TAMS 0x0000000716000000| PB 0x0000000716000000| Untracked | 0 >> >> | 77|0x0000000716200000, 0x0000000716200000, 0x0000000716400000| 0%| >> >> F| |TAMS 0x0000000716200000| PB 0x0000000716200000| Untracked | 0 >> >> | 78|0x0000000716400000, 0x0000000716400000, 0x0000000716600000| 0%| >> >> F| |TAMS 0x0000000716400000| PB 0x0000000716400000| Untracked | 0 >> >> | 79|0x0000000716600000, 0x0000000716600000, 0x0000000716800000| 0%| >> >> F| |TAMS 0x0000000716600000| PB 0x0000000716600000| Untracked | 0 >> >> | 80|0x0000000716800000, 0x0000000716800000, 0x0000000716a00000| 0%| >> >> F| |TAMS 0x0000000716800000| PB 0x0000000716800000| Untracked | 0 >> >> | 81|0x0000000716a00000, 0x0000000716a00000, 0x0000000716c00000| 0%| >> >> F| |TAMS 0x0000000716a00000| PB 0x0000000716a00000| Untracked | 0 >> >> | 82|0x0000000716c00000, 0x0000000716c00000, 0x0000000716e00000| 0%| >> >> F| |TAMS 0x0000000716c00000| PB 0x0000000716c00000| Untracked | 0 >> >> | 83|0x0000000716e00000, 0x0000000716e00000, 0x0000000717000000| 0%| >> >> F| |TAMS 0x0000000716e00000| PB 0x0000000716e00000| Untracked | 0 >> >> | 84|0x0000000717000000, 0x0000000717000000, 0x0000000717200000| 0%| >> >> F| |TAMS 0x0000000717000000| PB 0x0000000717000000| Untracked | 0 >> >> | 85|0x0000000717200000, 0x0000000717200000, 0x0000000717400000| 0%| >> >> F| |TAMS 0x0000000717200000| PB 0x0000000717200000| Untracked | 0 >> >> | 86|0x0000000717400000, 0x0000000717400000, 0x0000000717600000| 0%| >> >> F| |TAMS 0x0000000717400000| PB 0x0000000717400000| Untracked | 0 >> >> | 87|0x0000000717600000, 0x0000000717600000, 0x0000000717800000| 0%| >> >> F| |TAMS 0x0000000717600000| PB 0x0000000717600000| Untracked | 0 >> >> | 88|0x0000000717800000, 0x0000000717800000, 0x0000000717a00000| 0%| >> >> F| |TAMS 0x0000000717800000| PB 0x0000000717800000| Untracked | 0 >> >> | 89|0x0000000717a00000, 0x0000000717a00000, 0x0000000717c00000| 0%| >> >> F| |TAMS 0x0000000717a00000| PB 0x0000000717a00000| Untracked | 0 >> >> | 90|0x0000000717c00000, 0x0000000717c00000, 0x0000000717e00000| 0%| >> >> F| |TAMS 0x0000000717c00000| PB 0x0000000717c00000| Untracked | 0 >> >> | 91|0x0000000717e00000, 0x0000000717e00000, 0x0000000718000000| 0%| >> >> F| |TAMS 0x0000000717e00000| PB 0x0000000717e00000| Untracked | 0 >> >> | 92|0x0000000718000000, 0x0000000718000000, 0x0000000718200000| 0%| >> >> F| |TAMS 0x0000000718000000| PB 0x0000000718000000| Untracked | 0 >> >> | 93|0x0000000718200000, 0x0000000718200000, 0x0000000718400000| 0%| >> >> F| |TAMS 0x0000000718200000| PB 0x0000000718200000| Untracked | 0 >> >> | 94|0x0000000718400000, 0x0000000718400000, 0x0000000718600000| 0%| >> >> F| |TAMS 0x0000000718400000| PB 0x0000000718400000| Untracked | 0 >> >> | 95|0x0000000718600000, 0x0000000718600000, 0x0000000718800000| 0%| >> >> F| |TAMS 0x0000000718600000| PB 0x0000000718600000| Untracked | 0 >> >> | 96|0x0000000718800000, 0x0000000718800000, 0x0000000718a00000| 0%| >> >> F| |TAMS 0x0000000718800000| PB 0x0000000718800000| Untracked | 0 >> >> | 97|0x0000000718a00000, 0x0000000718a00000, 0x0000000718c00000| 0%| >> >> F| |TAMS 0x0000000718a00000| PB 0x0000000718a00000| Untracked | 0 >> >> | 98|0x0000000718c00000, 0x0000000718c00000, 0x0000000718e00000| 0%| >> >> F| |TAMS 0x0000000718c00000| PB 0x0000000718c00000| Untracked | 0 >> >> | 99|0x0000000718e00000, 0x0000000718e00000, 0x0000000719000000| 0%| >> >> F| |TAMS 0x0000000718e00000| PB 0x0000000718e00000| Untracked | 0 >> >> | 100|0x0000000719000000, 0x0000000719000000, 0x0000000719200000| 0%| >> >> F| |TAMS 0x0000000719000000| PB 0x0000000719000000| Untracked | 0 >> >> | 101|0x0000000719200000, 0x0000000719200000, 0x0000000719400000| 0%| >> >> F| |TAMS 0x0000000719200000| PB 0x0000000719200000| Untracked | 0 >> >> | 102|0x0000000719400000, 0x0000000719400000, 0x0000000719600000| 0%| >> >> F| |TAMS 0x0000000719400000| PB 0x0000000719400000| Untracked | 0 >> >> | 103|0x0000000719600000, 0x0000000719600000, 0x0000000719800000| 0%| >> >> F| |TAMS 0x0000000719600000| PB 0x0000000719600000| Untracked | 0 >> >> | 104|0x0000000719800000, 0x0000000719800000, 0x0000000719a00000| 0%| >> >> F| |TAMS 0x0000000719800000| PB 0x0000000719800000| Untracked | 0 >> >> | 105|0x0000000719a00000, 0x0000000719a00000, 0x0000000719c00000| 0%| >> >> F| |TAMS 0x0000000719a00000| PB 0x0000000719a00000| Untracked | 0 >> >> | 106|0x0000000719c00000, 0x0000000719c00000, 0x0000000719e00000| 0%| >> >> F| |TAMS 0x0000000719c00000| PB 0x0000000719c00000| Untracked | 0 >> >> | 107|0x0000000719e00000, 0x0000000719e00000, 0x000000071a000000| 0%| >> >> F| |TAMS 0x0000000719e00000| PB 0x0000000719e00000| Untracked | 0 >> >> | 108|0x000000071a000000, 0x000000071a000000, 0x000000071a200000| 0%| >> >> F| |TAMS 0x000000071a000000| PB 0x000000071a000000| Untracked | 0 >> >> | 109|0x000000071a200000, 0x000000071a200000, 0x000000071a400000| 0%| >> >> F| |TAMS 0x000000071a200000| PB 0x000000071a200000| Untracked | 0 >> >> | 110|0x000000071a400000, 0x000000071a400000, 0x000000071a600000| 0%| >> >> F| |TAMS 0x000000071a400000| PB 0x000000071a400000| Untracked | 0 >> >> | 111|0x000000071a600000, 0x000000071a600000, 0x000000071a800000| 0%| >> >> F| |TAMS 0x000000071a600000| PB 0x000000071a600000| Untracked | 0 >> >> | 112|0x000000071a800000, 0x000000071a800000, 0x000000071aa00000| 0%| >> >> F| |TAMS 0x000000071a800000| PB 0x000000071a800000| Untracked | 0 >> >> | 113|0x000000071aa00000, 0x000000071aa00000, 0x000000071ac00000| 0%| >> >> F| |TAMS 0x000000071aa00000| PB 0x000000071aa00000| Untracked | 0 >> >> | 114|0x000000071ac00000, 0x000000071ac00000, 0x000000071ae00000| 0%| >> >> F| |TAMS 0x000000071ac00000| PB 0x000000071ac00000| Untracked | 0 >> >> | 115|0x000000071ae00000, 0x000000071ae00000, 0x000000071b000000| 0%| >> >> F| |TAMS 0x000000071ae00000| PB 0x000000071ae00000| Untracked | 0 >> >> | 116|0x000000071b000000, 0x000000071b000000, 0x000000071b200000| 0%| >> >> F| |TAMS 0x000000071b000000| PB 0x000000071b000000| Untracked | 0 >> >> | 117|0x000000071b200000, 0x000000071b200000, 0x000000071b400000| 0%| >> >> F| |TAMS 0x000000071b200000| PB 0x000000071b200000| Untracked | 0 >> >> | 118|0x000000071b400000, 0x000000071b400000, 0x000000071b600000| 0%| >> >> F| |TAMS 0x000000071b400000| PB 0x000000071b400000| Untracked | 0 >> >> | 119|0x000000071b600000, 0x000000071b600000, 0x000000071b800000| 0%| >> >> F| |TAMS 0x000000071b600000| PB 0x000000071b600000| Untracked | 0 >> >> | 120|0x000000071b800000, 0x000000071b800000, 0x000000071ba00000| 0%| >> >> F| |TAMS 0x000000071b800000| PB 0x000000071b800000| Untracked | 0 >> >> | 121|0x000000071ba00000, 0x000000071bc00000, 0x000000071bc00000|100%| >> >> E| |TAMS 0x000000071ba00000| PB 0x000000071ba00000| Complete | 0 >> >> |1947|0x00000007ffe00000, 0x00000007fff1c148, 0x0000000800000000| 55%| >> >> O| |TAMS 0x00000007ffe00000| PB 0x00000007ffe00000| Untracked | 0 >> >> >> >> Card table byte_map: [0x00000268f51f0000,0x00000268f5990000] >> >> _byte_map_base: 0x00000268f198c000 >> >> >> >> Marking Bits: (CMBitMap*) 0x00000268e7d7dda0 >> >> Bits: [0x00000268f5990000, 0x00000268f9670000) >> >> >> >> Polling page: 0x00000268e5a80000 >> >> >> >> Metaspace: >> >> >> >> Usage: >> >> Non-class: 14.61 KB used. >> >> Class: 6.95 KB used. >> >> Both: 21.56 KB used. >> >> >> >> Virtual space: >> >> Non-class space: 64.00 MB reserved, 128.00 KB ( <1%) >> >> committed, 1 nodes. >> >> Class space: 1.00 GB reserved, 128.00 KB ( <1%) >> >> committed, 1 nodes. >> >> Both: 1.06 GB reserved, 256.00 KB ( <1%) >> committed. >> >> >> >> Chunk freelists: >> >> Non-Class: 12.00 MB >> >> Class: 15.75 MB >> >> Both: 27.74 MB >> >> >> >> MaxMetaspaceSize: unlimited >> >> CompressedClassSpaceSize: 1.00 GB >> >> Initial GC threshold: 21.00 MB >> >> Current GC threshold: 21.00 MB >> >> CDS: on >> >> - commit_granule_bytes: 65536. >> >> - commit_granule_words: 8192. >> >> - virtual_space_node_default_size: 8388608. >> >> - enlarge_chunks_in_place: 1. >> >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 >> >> Narrow klass pointer bits 32, Max shift 3 >> >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 >> >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 >> bytes) >> >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 >> bytes) >> >> Klass ID Range: [65536 - 1090519033) (1090453497) >> >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 >> bytes) >> >> >> >> >> >> Internal statistics: >> >> >> >> num_allocs_failed_limit: 0. >> >> num_arena_births: 4. >> >> num_arena_deaths: 0. >> >> num_vsnodes_births: 2. >> >> num_vsnodes_deaths: 0. >> >> num_space_committed: 4. >> >> num_space_uncommitted: 0. >> >> num_chunks_returned_to_freelist: 0. >> >> num_chunks_taken_from_freelist: 4. >> >> num_chunk_merges: 0. >> >> num_chunk_splits: 4. >> >> num_chunks_enlarged: 0. >> >> num_inconsistent_stats: 0. >> >> >> >> CodeCache: size=32768Kb used=84Kb max_used=84Kb free=32683Kb >> >> bounds [0x00000268f1e90000, 0x00000268f1eb8000, 0x00000268f3e90000] >> >> total_blobs=225, nmethods=0, adapters=216, full_count=0 >> >> Compilation: disabled (interpreter mode), stopped_count=0, >> restarted_count=0 >> >> >> >> Compilation events (0 events): >> >> No events >> >> >> >> GC Heap History (0 events): >> >> No events >> >> >> >> Dll operation events (2 events): >> >> Event: 0.006 Loaded shared library >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll >> >> Event: 0.286 Loaded shared library >> >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll >> >> >> >> Deoptimization events (0 events): >> >> No events >> >> >> >> Classes loaded (16 events): >> >> Event: 0.023 Loading class sun/nio/cs/IBM437 >> >> Event: 0.023 Loading class sun/nio/cs/IBM437 done >> >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder >> >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder done >> >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook >> >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook done >> >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader >> >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader >> done >> >> Event: 0.027 Loading class >> jdk/internal/loader/URLClassPath$FileLoader$1 >> >> Event: 0.027 Loading class >> jdk/internal/loader/URLClassPath$FileLoader$1 done >> >> Event: 0.027 Loading class java/lang/InterruptedException >> >> Event: 0.027 Loading class java/lang/InterruptedException done >> >> Event: 0.027 Loading class java/lang/CloneNotSupportedException >> >> Event: 0.027 Loading class java/lang/CloneNotSupportedException done >> >> Event: 0.028 Loading class java/util/Formatter$FixedString >> >> Event: 0.029 Loading class java/util/Formatter$FixedString done >> >> >> >> Classes unloaded (0 events): >> >> No events >> >> >> >> Classes redefined (0 events): >> >> No events >> >> >> >> Internal exceptions (0 events): >> >> No events >> >> >> >> VM Operations (0 events): >> >> No events >> >> >> >> Memory protections (0 events): >> >> No events >> >> >> >> Nmethod flushes (0 events): >> >> No events >> >> >> >> Events (9 events): >> >> Event: 0.017 Thread 0x00000268e57a3d20 Thread added: 0x00000268e57a3d20 >> >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08cfc0 >> >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08d5f0 >> >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc091710 >> >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc092140 >> >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0936e0 >> >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc09d2a0 >> >> Event: 0.026 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0d8ec0 >> >> Event: 0.027 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0de6e0 >> >> >> >> >> >> Dynamic libraries: >> >> 0x00007ff7bcd60000 - 0x00007ff7bcd70000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.exe >> >> 0x00007ffd45be0000 - 0x00007ffd45e40000 C:\WINDOWS\SYSTEM32\ntdll.dll >> >> 0x00007ffd44600000 - 0x00007ffd446c7000 >> C:\WINDOWS\System32\KERNEL32.DLL >> >> 0x00007ffd43490000 - 0x00007ffd4385a000 >> C:\WINDOWS\System32\KERNELBASE.dll >> >> 0x00007ffd42dc0000 - 0x00007ffd42f0b000 >> C:\WINDOWS\System32\ucrtbase.dll >> >> 0x00007ffd30100000 - 0x00007ffd3011d000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\VCRUNTIME140.dll >> >> 0x00007ffd2a470000 - 0x00007ffd2a487000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jli.dll >> >> 0x00007ffd450e0000 - 0x00007ffd452ac000 C:\WINDOWS\System32\USER32.dll >> >> 0x00007ffd41f90000 - 0x00007ffd42227000 >> >> >> C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24\COMCTL32.dll >> >> 0x00007ffd43040000 - 0x00007ffd43067000 C:\WINDOWS\System32\win32u.dll >> >> 0x00007ffd44a40000 - 0x00007ffd44ae9000 C:\WINDOWS\System32\msvcrt.dll >> >> 0x00007ffd44af0000 - 0x00007ffd44b1a000 C:\WINDOWS\System32\GDI32.dll >> >> 0x00007ffd43130000 - 0x00007ffd43261000 >> C:\WINDOWS\System32\gdi32full.dll >> >> 0x00007ffd433e0000 - 0x00007ffd43483000 >> C:\WINDOWS\System32\msvcp_win.dll >> >> 0x00007ffd44560000 - 0x00007ffd4458f000 C:\WINDOWS\System32\IMM32.DLL >> >> 0x00007ffd27710000 - 0x00007ffd2771c000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\vcruntime140_1.dll >> >> 0x00007ffd14e00000 - 0x00007ffd14e8d000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\msvcp140.dll >> >> 0x00007ffceaf00000 - 0x00007ffceb4cf000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero\jvm.dll >> >> 0x00007ffd452b0000 - 0x00007ffd45362000 >> C:\WINDOWS\System32\ADVAPI32.dll >> >> 0x00007ffd44780000 - 0x00007ffd44826000 C:\WINDOWS\System32\sechost.dll >> >> 0x00007ffd442d0000 - 0x00007ffd443e6000 C:\WINDOWS\System32\RPCRT4.dll >> >> 0x00007ffd446d0000 - 0x00007ffd44744000 C:\WINDOWS\System32\WS2_32.dll >> >> 0x00007ffd42c30000 - 0x00007ffd42c8e000 >> C:\WINDOWS\SYSTEM32\POWRPROF.dll >> >> 0x00007ffd332f0000 - 0x00007ffd33326000 C:\WINDOWS\SYSTEM32\WINMM.dll >> >> 0x00007ffd391c0000 - 0x00007ffd391cb000 C:\WINDOWS\SYSTEM32\VERSION.dll >> >> 0x00007ffd16d70000 - 0x00007ffd16d81000 >> C:\msys64\ucrt64\bin\libffi-8.dll >> >> 0x00007ffd42c10000 - 0x00007ffd42c24000 C:\WINDOWS\SYSTEM32\UMPDC.dll >> >> 0x00007ffd41a60000 - 0x00007ffd41a6c000 >> C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL >> >> 0x00007ffd42fa0000 - 0x00007ffd43039000 >> C:\WINDOWS\System32\bcryptPrimitives.dll >> >> 0x00007ffd41270000 - 0x00007ffd4128a000 >> C:\WINDOWS\SYSTEM32\kernel.appcore.dll >> >> 0x00007ffd27060000 - 0x00007ffd2706a000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jimage.dll >> >> 0x00007ffd42540000 - 0x00007ffd42781000 C:\WINDOWS\SYSTEM32\DBGHELP.DLL >> >> 0x00007ffd44d50000 - 0x00007ffd450d2000 C:\WINDOWS\System32\combase.dll >> >> 0x00007ffd439e0000 - 0x00007ffd43ab6000 >> C:\WINDOWS\System32\OLEAUT32.dll >> >> 0x00007ffd01660000 - 0x00007ffd01699000 C:\WINDOWS\SYSTEM32\dbgcore.DLL >> >> 0x00007ffd16d50000 - 0x00007ffd16d6d000 >> >> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll >> >> 0x00007ffd44b20000 - 0x00007ffd44cb6000 C:\WINDOWS\System32\ole32.dll >> >> 0x00007ffd45370000 - 0x00007ffd45a99000 C:\WINDOWS\System32\SHELL32.dll >> >> 0x00007ffd43270000 - 0x00007ffd433d8000 >> C:\WINDOWS\System32\wintypes.dll >> >> 0x00007ffd3ff80000 - 0x00007ffd407d2000 >> C:\WINDOWS\SYSTEM32\windows.storage.dll >> >> 0x00007ffd44400000 - 0x00007ffd444ed000 C:\WINDOWS\System32\SHCORE.dll >> >> 0x00007ffd444f0000 - 0x00007ffd44554000 C:\WINDOWS\System32\shlwapi.dll >> >> 0x00007ffd42cd0000 - 0x00007ffd42cff000 C:\WINDOWS\SYSTEM32\profapi.dll >> >> 0x00007ffd15180000 - 0x00007ffd15192000 >> >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll >> >> >> >> JVMTI agents: none >> >> >> >> dbghelp: loaded successfully - version: 4.0.5 - missing functions: none >> >> symbol engine: initialized successfully - sym options: 0x614 - pdb >> >> path: >> .;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero;C:\msys64\ucrt64\bin;C:\Users\REDACTED\Downloads\LoadLibrary\Crash >> >> >> >> VM Arguments: >> >> jvm_args: --enable-preview >> >> java_command: Crash >> >> java_class_path (initial): >> C:/Users/REDACTED/Downloads/LoadLibrary/Crash >> >> Launcher Type: SUN_STANDARD >> >> >> >> [Global flags] >> >> uint ConcGCThreads = 5 >> >> {product} {ergonomic} >> >> uint G1ConcRefinementThreads = 18 >> >> {product} {ergonomic} >> >> size_t G1HeapRegionSize = 2097152 >> >> {product} {ergonomic} >> >> size_t InitialHeapSize = 255852544 >> >> {product} {ergonomic} >> >> size_t MarkStackSize = 4194304 >> >> {product} {ergonomic} >> >> size_t MarkStackSizeMax = 536870912 >> >> {product} {ergonomic} >> >> size_t MaxHeapSize = 4085252096 >> >> {product} {ergonomic} >> >> size_t MaxNewSize = 2449473536 >> >> {product} {ergonomic} >> >> size_t MinHeapDeltaBytes = 2097152 >> >> {product} {ergonomic} >> >> size_t MinHeapSize = 8388608 >> >> {product} {ergonomic} >> >> uintx NonNMethodCodeHeapSize = 4096 >> >> {pd product} {ergonomic} >> >> uintx NonProfiledCodeHeapSize = 0 >> >> {pd product} {ergonomic} >> >> uintx ProfiledCodeHeapSize = 0 >> >> {pd product} {ergonomic} >> >> size_t SoftMaxHeapSize = 4085252096 >> >> {manageable} {ergonomic} >> >> bool UseCompressedOops = true >> >> {product lp64_product} {ergonomic} >> >> bool UseG1GC = true >> >> {product} {ergonomic} >> >> bool UseLargePagesIndividualAllocation = false >> >> {pd product} {ergonomic} >> >> >> >> Logging: >> >> Log output configuration: >> >> #0: stdout all=warning uptime,level,tags foldmultilines=false >> >> #1: stderr all=off uptime,level,tags foldmultilines=false >> >> >> >> Release file: >> >> IMPLEMENTOR="N/A" >> >> JAVA_RUNTIME_VERSION="25-internal" >> >> JAVA_VERSION="25" >> >> JAVA_VERSION_DATE="2025-09-16" >> >> LIBC="default" >> >> MODULES="java.base java.compiler java.datatransfer java.xml java.prefs >> >> java.desktop java.instrument java.logging java.management >> >> java.security.sasl java.naming java.rmi java.management.rmi >> >> java.net.http java.scripting java.security.jgss java.transaction.xa >> >> java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio >> >> jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets >> >> jdk.internal.opt jdk.zipfs jdk.compiler jdk.crypto.cryptoki >> >> jdk.crypto.ec jdk.crypto.mscapi jdk.dynalink jdk.internal.ed >> >> jdk.editpad jdk.httpserver jdk.incubator.vector jdk.internal.le >> >> jdk.internal.md jdk.jartool jdk.javadoc jdk.jcmd jdk.management >> >> jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi >> >> jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd >> >> jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi >> >> jdk.net jdk.nio.mapmode jdk.sctp jdk.security.auth jdk.security.jgss >> >> jdk.unsupported jdk.unsupported.desktop jdk.xml.dom" >> >> OS_ARCH="x86_64" >> >> OS_NAME="Windows" >> >> SOURCE=".:git:8f7652d7a36b+" >> >> >> >> Environment Variables: >> >> >> PATH=C:\msys64\ucrt64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl >> >> USERNAME=REDACTED >> >> SHELL=C:\msys64\usr\bin\bash.exe >> >> LC_CTYPE=en_US.UTF-8 >> >> TERM=xterm >> >> OS=Windows_NT >> >> PROCESSOR_IDENTIFIER=AMD64 Family 25 Model 97 Stepping 2, AuthenticAMD >> >> TMP=C:\msys64\tmp >> >> TEMP=C:\msys64\tmp >> >> >> >> >> >> >> >> >> >> Compilation memory statistics disabled. >> >> >> >> Periodic native trim disabled >> >> >> >> --------------- S Y S T E M --------------- >> >> >> >> OS: >> >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) >> >> OS uptime: 0 days 1:47 hours >> >> >> >> CPU: total 24 (initial active 24) >> >> Processor Information for processor 0 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 1 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 2 >> >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 >> >> Processor Information for processor 3 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 4 >> >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 >> >> Processor Information for processor 5 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 6 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 7 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 8 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 9 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 10 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 11 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 12 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 13 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 14 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 15 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 16 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 17 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 18 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 19 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 20 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 21 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 22 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> Processor Information for processor 23 >> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >> >> >> >> Memory: 4k page, system-wide physical 15578M (1690M free) >> >> TotalPageFile size 44250M (AvailPageFile size 20548M) >> >> current process WorkingSet (physical memory assigned to process): 64M, >> peak: 64M >> >> current process commit charge ("private bytes"): 373M, peak: 373M >> >> >> >> vm_info: Java HotSpot 64-Bit Zero VM (25-internal) for windows-amd64 >> >> JRE (25-internal), built on 2025-04-17T14:32:22Z with MS VC++ 17.8 >> >> (VS2022) >> >> >> >> END. >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-161-Note: >> >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:162:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): >> >> warning C5030: attribute [[gnu::packed]] is not recognized >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-320-Note: >> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:321:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log-13-Note: >> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:15:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:16:jdk\src\hotspot\cpu\zero\interpreterRT_zero.cpp(161): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-168-Note: >> >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:169:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): >> >> warning C5030: attribute [[gnu::packed]] is not recognized >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-307-Note: >> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:308:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log-7-Note: >> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:8:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:9:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:10:jdk\src\hotspot\cpu\zero\stack_zero.cpp(36): >> >> warning C4267: '=': conversion from 'size_t' to 'int', possible loss >> >> of data >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log-12-Note: >> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:13:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log-28-Note: >> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:29:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:30:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >> >> possible loss of data >> >> >> >> Generating code >> >> Previous IPDB not found, fall back to full compilation. >> >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >> >> C4723: potential divide by 0 >> >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >> >> C4723: potential divide by 0 >> >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >> >> C4723: potential divide by 0 >> >> All 52893 functions were compiled because no usable IPDB/IOBJ from >> >> previous compilation was found. >> >> Finished generating code >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rehn at rivosinc.com Thu Apr 24 15:26:50 2025 From: rehn at rivosinc.com (Robbin Ehn) Date: Thu, 24 Apr 2025 17:26:50 +0200 Subject: Where to put supplementary docs? In-Reply-To: References: Message-ID: Hi, I agree. I suggested co-located docs in some less public forums in the past. One major challenge with the other places (CR, JBS, PR, wiki), is that they don't handle versioning. (naturally) This means the code can't safely refer to, e.g., a wiki page, as that page may describe a newer version. If a developer is working in JDK 11 or in the Loom project, they need the relevant documentation for that specific fork/branch. JBS/PR also have the issue that they primarily describe the original bug/patch. The code integrated can change significantly during the PR's lifetime, and one may need to read many comments in the PR/JBS to figure things out. Additionally, many developers 'grep' the code, which means co-located documentation is very easy to find (and thus easier to keep up-to-date or add new docs to). A concrete example: https://wiki.openjdk.org/display/HotSpot/Synchronization If you are hunting a bug in JDK 11, this page may be of value. If you want to know how locking works in JDK 25, you shouldn't be reading this page. Co-locating the docs with the code helps with these issues. /Robbin On Thu, Apr 24, 2025 at 11:11?AM Andrew Haley wrote: > > Anyone? > > On 4/22/25 10:31, Andrew Haley wrote: > > Sometimes, when reviewing a PR, we have supporting documents to > > justify a change. These docs can include diagrams, etc. In the past > > some such documents were put on the webrev server, and sometimes they > > got lost. One example of such a file is "Fast Subtype Checking in the > > HotSpot JVM," which explained the (now obsolete) secondary subtype > > checking algorithm. > > > > Today, documents are sometimes uploaded to JIRA or attached to the PR > > itself. Sometimes they are stored in someone's personal web space, and > > linked from a PR, and that's when things get lost. > > > > It would be better for long-term retention if such documents were > > included in the JDK repository itself, and committed to the repo as > > part of the PR. I'm assuming that these files will be fairly small, so > > will not greatly increase the size of the repo. > > > > I propose to add a new subdirectory to jdk/doc, called "ref" or > > "reference". This is not for every possible reference document, but > > those that aid the maintainer and will be useful in the future. A > > comment in the source code should refer the reader to the appropriate > > reference document. > > > > Does anyone here object to this? Is there some other place than > > "doc/ref" that would be more appropriate? > > > > Thanks, > > > > Andrew. > > > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From tanksherman27 at gmail.com Thu Apr 24 15:27:25 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 24 Apr 2025 23:27:25 +0800 Subject: Windows/Zero In-Reply-To: References: Message-ID: No worries, I am perfectly fine with maintaining Windows/Zero on my own, it was honestly just some side work when I first started implementing it. I just thought it may be helpful to someone out there when I first had the idea of floating it to the list. I read the situation about 32 bit, and agree that it's a tough situation considering how difficult it is to maintain such ports. What does surprise me is that 32 bit seems to be hard enough to maintain, even with Zero supposedly being easier to work with than a full blown port, that we're considering dropping Zero 32 bit as well though, but that's a discussion for another time. Regarding broken 32 bit, I was going to offer to fix the (existing) Linux Zero 32 bit x86 since it looks like an easy to fix compiler error, and it would be nice to not have build failures in any of the ports while they're still a part of the JDK at the very least, but in light of the current discussion I'm going to hold off from doing that for now, lest it be deemed as unnecessary effort to fix 32 bit before it is finally axed. I'll leave this open for more discussion but ultimately I'll take it that there's not much interest in Windows/Zero, at least not enough interest to warrant upstreaming it. I'm more than happy to keep this as a port I maintain myself. Thanks for your time! best regards, Julian On Thu, Apr 24, 2025 at 10:50?PM Thomas St?fe wrote: > > 32-bit zero build is broken and has been broken for months at least, maybe a lot longer. Nobody seems to even notice. > > See also discussion about the future of 32-bit, started here: https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009889.html > > And without 32-bit, the argument for Windows Zero is getting thin. > > > > > On Thu, Apr 24, 2025 at 2:52?PM David Alayachew wrote: >> >> I'm in support of this. >> >> Now that 32-bit options just got removed, Zero is all we have for those of us on 32-bit hardware. So, having another option sounds just fine for me. >> >> >> On Thu, Apr 24, 2025, 7:49?AM Julian Waters wrote: >>> >>> Hi Thomas, sorry for the late reply, >>> >>> Off the top of my head, the Zero JVM is extremely small and could be >>> useful in environments where a small JVM is needed. More importantly, >>> it may (Although I have not verified this yet) allow Java to run on 32 >>> bit Windows again, at no additional cost to maintenance since Zero >>> itself requires no extra 32 bit support, it's just compile and run. It >>> can help if you're working on other parts of the JDK and don't care >>> about the JVM, and just want it to compile and link quickly so you can >>> get to testing out the changes in the non JVM area of the JDK you're >>> working on at the moment, something that I do commonly. I guess the >>> process of supporting Windows/Zero also helped eliminate non standard >>> zero size arrays in HotSpot, though this may not be that big of a >>> deal. Regardless, I'm just curious if there is interest in it from >>> anyone at the moment. >>> >>> Have a great rest of the week ahead! >>> >>> best regards, >>> Julian >>> >>> On Tue, Apr 22, 2025 at 9:35?PM Thomas St?fe wrote: >>> > >>> > Hi Julian, >>> > >>> > I am curious, what would be the use case for Windows+Zero? >>> > >>> > Zero is typically used for bootstrapping new platforms/CPUs. The Windows CPU set is very stable, and Windows is not the platform anyone starts porting to if they start working on a new platform. Additionally, Microsoft usually takes care of porting in the once-a-decade-rare case that a new CPU is supported on Windows. >>> > >>> > Cheers, Thomas >>> > >>> > >>> > On Tue, Apr 22, 2025 at 2:47?PM Julian Waters wrote: >>> >> >>> >> Hi all, >>> >> >>> >> Zero currently cannot compile on Windows, and to my knowledge, has >>> >> never been able to compile on Windows. This is largely due to Windows >>> >> lacking crucial implementations for Zero under the os_cpu directory, >>> >> where you will notice a distinct lack of a windows_zero directory. To >>> >> remedy this, some time ago, I implemented Zero on Windows. The >>> >> implementation, aside from adding critical code to windows_zero, also >>> >> had to ifdef some code out of the Windows Structured Exception filter. >>> >> It was surprisingly minimal, but the downside is that Windows/Zero >>> >> then only compiled with gcc. VC had an additional hurdle to jump >>> >> through: On Zero, since there are no registers, register arrays in >>> >> certain classes became zero sized arrays, a GNU extension that VC will >>> >> never accept under any circumstances. >>> >> >>> >> I started work again recently to get Zero working with VC. Just 2 days >>> >> ago, this successfully compiled with VC, albeit with >>> >> --disable-warnings-as-errors. The code is available at >>> >> https://github.com/TheShermanTanker/jdk/commits/experimental for >>> >> anyone curious, under "Windows/Zero Port". Disclaimer: I do not know >>> >> whether the code is 100% correct, I may have implemented it wrongly. >>> >> The remaining warnings left over can be seen below this mail. Note >>> >> that only the release configuration was tested, fastdebug has not been >>> >> compiled yet. >>> >> >>> >> I'd like to float the idea of supporting Windows/Zero properly. >>> >> Ideally, Zero should run on any platform, so it not running on Windows >>> >> would be surprising, but past that, the Java Zero VM is extremely >>> >> small on Windows at just 5MB (Even smaller than the Python >>> >> Interpreter!), so it could be useful on devices where a small Java VM >>> >> is desired. More importantly, this could (Although I am not fully >>> >> certain) open the door to running the latest Java on 32 bit Windows >>> >> devices again, ever since all the x86 32 bit ports were removed, >>> >> leaving Zero as the only way to execute Java on 32 bit x86. This may >>> >> (or may not) help those who cannot get a 64 bit device or one that's >>> >> running Linux, I haven't checked yet. >>> >> >>> >> I also crashed the VM on purpose to get a hserr file which contains VM >>> >> information, this can be seen below. This was quite interesting, as >>> >> I've never actually seen Zero crash before! >>> >> >>> >> Thoughts? >>> >> >>> >> best regards, >>> >> Julian >>> >> >>> >> # >>> >> # A fatal error has been detected by the Java Runtime Environment: >>> >> # >>> >> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ffd1518139f, >>> >> pid=335696, tid=337452 >>> >> # >>> >> # JRE version: Java Runtime Environment (25.0) (build 25-internal) >>> >> # Java VM: Java HotSpot 64-Bit Zero VM (25-internal, interpreted mode, >>> >> sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64) >>> >> # Problematic frame: >>> >> # C [Crash.dll+0x139f] >>> >> # >>> >> # No core dump will be written. Minidumps are not enabled by default >>> >> on client versions of Windows >>> >> # >>> >> # If you would like to submit a bug report, please visit: >>> >> # https://bugreport.java.com/bugreport/crash.jsp >>> >> # The crash happened outside the Java Virtual Machine in native code. >>> >> # See problematic frame for where to report the bug. >>> >> # >>> >> >>> >> --------------- S U M M A R Y ------------ >>> >> >>> >> Command Line: --enable-preview Crash >>> >> >>> >> Host: AMD Ryzen 9 7845HX with Radeon Graphics , 24 cores, 15G, >>> >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) >>> >> Time: Sun Apr 20 03:44:08 2025 Malay Peninsula Standard Time elapsed >>> >> time: 0.291582 seconds (0d 0h 0m 0s) >>> >> >>> >> --------------- T H R E A D --------------- >>> >> >>> >> Current thread (0x00000268e57a3d20): JavaThread "main" >>> >> [_thread_in_native, id=337452, >>> >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] >>> >> >>> >> Stack: [0x000000ae07a00000,0x000000ae07b00000], >>> >> sp=0x000000ae07a842a0, free space=528k >>> >> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) >>> >> C [Crash.dll+0x139f] (no source info available) >>> >> C [libffi-8.dll+0x4cc1] (no source info available) >>> >> C [libffi-8.dll+0x48df] (no source info available) >>> >> C [libffi-8.dll+0x4aa2] (no source info available) >>> >> V [jvm.dll+0x426645] ZeroInterpreter::native_entry+0x455 >>> >> (zeroInterpreter_zero.cpp:444) >>> >> V [jvm.dll+0x425f47] ZeroInterpreter::main_loop+0x127 >>> >> (zeroInterpreter_zero.cpp:227) >>> >> V [jvm.dll+0x425d96] ZeroInterpreter::normal_entry+0x36 >>> >> (zeroInterpreter_zero.cpp:115) >>> >> V [jvm.dll+0x3b156d] StubGenerator::call_stub+0x1bd >>> >> (stubGenerator_zero.cpp:84) >>> >> V [jvm.dll+0x1acbfd] JavaCalls::call_helper+0x48d (javaCalls.cpp:424) >>> >> V [jvm.dll+0x2e4c80] os::os_exception_wrapper+0x20 (os_windows_zero.cpp:51) >>> >> V [jvm.dll+0x1c472a] jni_invoke_nonstatic+0x32a (jni.cpp:950) >>> >> V [jvm.dll+0x1c8ea2] jni_CallVoidMethod+0x142 (jni.cpp:1307) >>> >> C [jli.dll+0x510f] JavaMain+0x7d3 (java.c:645) >>> >> C [ucrtbase.dll+0x37b0] (no source info available) >>> >> C [KERNEL32.DLL+0x2e8d7] (no source info available) >>> >> C [ntdll.dll+0xb14fc] (no source info available) >>> >> >>> >> Java frames: >>> >> 0x000000ae07aff8f0: unboxed parameter[1] = 0x000000ae07aff9a0 >>> >> 0x000000ae07aff8f8: parameter[0] (JNIEnv) = 0x000000ae07a84410 >>> >> 0x000000ae07aff900: parameter[1] (this) = 0x000000ae07aff8f0 >>> >> 0x000000ae07aff908: istate->_thread = 0x00000268e57a3d20 >>> >> 0x000000ae07aff910: istate->_bcp = 0x0000000000000000 >>> >> 0x000000ae07aff918: istate->_locals = 0x000000ae07aff9a0 >>> >> 0x000000ae07aff920: istate->_constants = 0x00000268c14003a8 >>> >> 0x000000ae07aff928: istate->_method = Crash.crash()V >>> >> 0x000000ae07aff930: istate->_mirror = 0x000000071ba1cb90 >>> >> 0x000000ae07aff938: istate->_stack = 0x000000ae07aff900 >>> >> 0x000000ae07aff940: istate->_msg = 0x0000026800000002 >>> >> 0x000000ae07aff948: istate->_result = 0x0000000000000000 >>> >> 0x000000ae07aff950: (istate->_result) = 0x000000ae00000003 >>> >> 0x000000ae07aff958: (istate->_result) = 0x0000000000000000 >>> >> 0x000000ae07aff960: istate->_prev_link = 0x0000000000000000 >>> >> 0x000000ae07aff968: istate->_oop_temp = 0x0000000000000000 >>> >> 0x000000ae07aff970: istate->_stack_base = 0x000000ae07aff908 >>> >> 0x000000ae07aff978: istate->_stack_limit = 0x000000ae07aff900 >>> >> 0x000000ae07aff980: istate->_monitor_base = 0x000000ae07aff908 >>> >> 0x000000ae07aff988: istate->_self_link = 0x000000ae07aff908 >>> >> 0x000000ae07aff990: frame_type = INTERPRETER_FRAME >>> >> 0x000000ae07aff998: next_frame = 0x000000ae07affa38 >>> >> >>> >> 0x000000ae07aff9a0: local[0] = 0x000000071ba1d940 >>> >> 0x000000ae07aff9a8: istate->_thread = 0x00000268e57a3d20 >>> >> 0x000000ae07aff9b0: istate->_bcp = 0x00000268c14002de (bci 6) >>> >> 0x000000ae07aff9b8: istate->_locals = 0x000000ae07affa40 >>> >> 0x000000ae07aff9c0: istate->_constants = 0x00000268c14003a8 >>> >> 0x000000ae07aff9c8: istate->_method = Crash.main()V >>> >> 0x000000ae07aff9d0: istate->_mirror = 0x000000071ba1cb90 >>> >> 0x000000ae07aff9d8: istate->_stack = 0x000000ae07aff998 >>> >> 0x000000ae07aff9e0: istate->_msg = 0x0000026800000008 >>> >> 0x000000ae07aff9e8: istate->_result = 0x00000268c1400238 >>> >> 0x000000ae07aff9f0: (istate->_result) = 0x00000268f1e90458 >>> >> 0x000000ae07aff9f8: (istate->_result) = 0x0000000000000003 >>> >> 0x000000ae07affa00: istate->_prev_link = 0x0000000000000000 >>> >> 0x000000ae07affa08: istate->_oop_temp = 0x0000000000000000 >>> >> 0x000000ae07affa10: istate->_stack_base = 0x000000ae07aff9a8 >>> >> 0x000000ae07affa18: istate->_stack_limit = 0x000000ae07aff990 >>> >> 0x000000ae07affa20: istate->_monitor_base = 0x000000ae07aff9a8 >>> >> 0x000000ae07affa28: istate->_self_link = 0x000000ae07aff9a8 >>> >> 0x000000ae07affa30: frame_type = INTERPRETER_FRAME >>> >> 0x000000ae07affa38: next_frame = 0x000000ae07affa58 >>> >> >>> >> 0x000000ae07affa40: local[0] = 0x000000071ba1d940 >>> >> 0x000000ae07affa48: call_wrapper = 0x000000ae07affaf0 >>> >> 0x000000ae07affa50: frame_type = ENTRY_FRAME >>> >> 0x000000ae07affa58: next_frame = 0x0000000000000000 >>> >> >>> >> >>> >> siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address >>> >> 0x0000000000000000 >>> >> >>> >> >>> >> No context information. >>> >> >>> >> Register to memory mapping: >>> >> >>> >> No register info. >>> >> >>> >> Top of Stack: (sp=0x000000ae07a842a0) >>> >> 0x000000ae07a842a0: 00000000000003d8 0000000000000000 ................ >>> >> 0x000000ae07a842b0: 0000000000000000 00007ffd16d748df .........H...... >>> >> 0x000000ae07a842c0: 000002688046f350 0000000000000000 P.F.h........... >>> >> 0x000000ae07a842d0: 000000ae07a84300 00007ffd16d74cc1 .C.......L...... >>> >> 0x000000ae07a842e0: 00000268e57a4028 000000ae07aff9a0 (@z.h........... >>> >> 0x000000ae07a842f0: 0000000000000001 0000000000000050 ........P....... >>> >> 0x000000ae07a84300: 000000ae07a84350 00007ffd16d748df PC.......H...... >>> >> 0x000000ae07a84310: 00007ffd15181380 0000000000000000 ................ >>> >> 0x000000ae07a84320: 000000ae07a84400 0000000000000000 .D.............. >>> >> 0x000000ae07a84330: 0000000000000001 0000000000000000 ................ >>> >> 0x000000ae07a84340: 00001664b4a8ce49 111f221225371f8f I...d.....7%.".. >>> >> 0x000000ae07a84350: 00000268802416f0 00000268e57a3d20 ..$.h... =z.h... >>> >> 0x000000ae07a84360: 00000268c1400238 000000ae07aff908 8. at .h........... >>> >> 0x000000ae07a84370: 000000ae07aff9a0 000000ae07aff998 ................ >>> >> 0x000000ae07a84380: 00000268f1e98710 0000000000000000 ....h........... >>> >> 0x000000ae07a84390: 000000ae07a84440 00007ffd16d74aa2 @D.......J...... >>> >> 0x000000ae07a843a0: 0000000000000000 0000000000000001 ................ >>> >> 0x000000ae07a843b0: 0000000000000000 000000ae07aff998 ................ >>> >> 0x000000ae07a843c0: 0000000000000000 0000000000000000 ................ >>> >> 0x000000ae07a843d0: 000000ae07a84440 00007ffceb326645 @D......Ef2..... >>> >> 0x000000ae07a843e0: 00007ffceb482058 00000268e57a3d20 X H..... =z.h... >>> >> 0x000000ae07a843f0: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... >>> >> 0x000000ae07a84400: 000000ae07aff990 000000ae07aff8f8 ................ >>> >> 0x000000ae07a84410: 00000268e57a4028 0000000000000000 (@z.h........... >>> >> 0x000000ae07a84420: 00007ffd15181380 0000000000000000 ................ >>> >> 0x000000ae07a84430: 00000268c1400238 00000268e57a3d20 8. at .h... =z.h... >>> >> 0x000000ae07a84440: 0000000000000001 0000000000000000 ................ >>> >> 0x000000ae07a84450: 0000000000000000 0000000000000000 ................ >>> >> 0x000000ae07a84460: 0000000000000000 000000ae07affa38 ........8....... >>> >> 0x000000ae07a84470: 00000268c14002e8 00007ffceb325f47 .. at .h...G_2..... >>> >> 0x000000ae07a84480: 00000268e57a3d20 00000268e57a3d20 =z.h... =z.h... >>> >> 0x000000ae07a84490: 000000ae00084b70 0000000000000000 pK.............. >>> >> >>> >> Instructions: (pc=0x00007ffd1518139f) >>> >> 0x00007ffd1518129f: 00 e8 bb 0e 00 00 41 89 c4 83 fb 03 75 86 e9 5a >>> >> 0x00007ffd151812af: ff ff ff 66 0f 1f 44 00 00 83 fb 01 0f 85 6f ff >>> >> 0x00007ffd151812bf: ff ff 49 89 f8 31 d2 48 89 f1 e8 42 fd ff ff e9 >>> >> 0x00007ffd151812cf: 5d ff ff ff 0f 1f 44 00 00 e8 93 01 00 00 49 89 >>> >> 0x00007ffd151812df: f8 ba 01 00 00 00 48 89 f1 e8 73 0e 00 00 41 89 >>> >> 0x00007ffd151812ef: c4 85 c0 0f 85 3b ff ff ff 49 89 f8 31 d2 48 89 >>> >> 0x00007ffd151812ff: f1 e8 5b 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 3e >>> >> 0x00007ffd1518130f: 0e 00 00 49 89 f8 31 d2 48 89 f1 e8 f1 fc ff ff >>> >> 0x00007ffd1518131f: e9 0f ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 >>> >> 0x00007ffd1518132f: 90 48 8b 05 b9 82 00 00 c7 00 00 00 00 00 e9 8e >>> >> 0x00007ffd1518133f: fe ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f >>> >> 0x00007ffd1518134f: 00 48 89 ca 48 8d 0d a6 ac 00 00 e9 f9 62 00 00 >>> >> 0x00007ffd1518135f: 90 48 8d 0d 09 00 00 00 e9 e4 ff ff ff 0f 1f 40 >>> >> 0x00007ffd1518136f: 00 c3 90 90 90 90 90 90 90 90 90 90 90 90 90 90 >>> >> 0x00007ffd1518137f: 90 55 48 89 e5 48 83 ec 30 48 c7 45 f8 00 00 00 >>> >> 0x00007ffd1518138f: 00 48 8b 45 f8 48 8b 45 f8 48 8d 0d 61 7c 00 00 >>> >> =>0x00007ffd1518139f: 8b 10 e8 ca 0d 00 00 48 8d 0d 56 7c 00 00 48 83 >>> >> 0x00007ffd151813af: c4 30 5d e9 59 63 00 00 90 90 90 90 90 90 90 90 >>> >> 0x00007ffd151813bf: 90 48 83 ec 28 48 8b 05 45 6c 00 00 48 8b 00 48 >>> >> 0x00007ffd151813cf: 85 c0 74 22 0f 1f 44 00 00 ff d0 48 8b 05 2f 6c >>> >> 0x00007ffd151813df: 00 00 48 8d 50 08 48 8b 40 08 48 89 15 20 6c 00 >>> >> 0x00007ffd151813ef: 00 48 85 c0 75 e3 48 83 c4 28 c3 66 0f 1f 44 00 >>> >> 0x00007ffd151813ff: 00 56 53 48 83 ec 28 48 8b 15 83 81 00 00 48 8b >>> >> 0x00007ffd1518140f: 02 89 c1 83 f8 ff 74 39 85 c9 74 20 89 c8 83 e9 >>> >> 0x00007ffd1518141f: 01 48 8d 1c c2 48 29 c8 48 8d 74 c2 f8 0f 1f 40 >>> >> 0x00007ffd1518142f: 00 ff 13 48 83 eb 08 48 39 f3 75 f5 48 8d 0d 7e >>> >> 0x00007ffd1518143f: ff ff ff 48 83 c4 28 5b 5e e9 03 ff ff ff 0f 1f >>> >> 0x00007ffd1518144f: 00 31 c0 66 0f 1f 44 00 00 44 8d 40 01 89 c1 4a >>> >> 0x00007ffd1518145f: 83 3c c2 00 4c 89 c0 75 f0 eb ad 66 0f 1f 44 00 >>> >> 0x00007ffd1518146f: 00 8b 05 aa ab 00 00 85 c0 74 06 c3 0f 1f 44 00 >>> >> 0x00007ffd1518147f: 00 c7 05 96 ab 00 00 01 00 00 00 e9 71 ff ff ff >>> >> 0x00007ffd1518148f: 90 83 fa 03 74 0b 85 d2 74 07 c3 66 0f 1f 44 00 >>> >> >>> >> >>> >> Stack slot to memory mapping: >>> >> >>> >> stack at sp + 0 slots: 0x00000000000003d8 is an unknown value >>> >> stack at sp + 1 slots: 0x0 is null >>> >> stack at sp + 2 slots: 0x0 is null >>> >> stack at sp + 3 slots: 0x00007ffd16d748df libffi-8.dll >>> >> stack at sp + 4 slots: {method} {0x000002688046f358} 'loadLibrary' >>> >> '(Ljava/lang/Class;Ljava/lang/String;)Ljdk/internal/loader/NativeLibrary;' >>> >> in 'java/lang/ClassLoader' >>> >> stack at sp + 5 slots: 0x0 is null >>> >> stack at sp + 6 slots: 0x000000ae07a84300 is pointing into the stack >>> >> for thread: 0x00000268e57a3d20 >>> >> stack at sp + 7 slots: 0x00007ffd16d74cc1 libffi-8.dll >>> >> >>> >> Lock stack of current Java thread (top to bottom): >>> >> >>> >> >>> >> --------------- P R O C E S S --------------- >>> >> >>> >> Threads class SMR info: >>> >> _java_thread_list=0x00000268fc0d5850, length=9, elements={ >>> >> 0x00000268e57a3d20, 0x00000268fc08cfc0, 0x00000268fc08d5f0, 0x00000268fc091710, >>> >> 0x00000268fc092140, 0x00000268fc0936e0, 0x00000268fc09d2a0, 0x00000268fc0d8ec0, >>> >> 0x00000268fc0de6e0 >>> >> } >>> >> >>> >> Java Threads: ( => current thread ) >>> >> =>0x00000268e57a3d20 JavaThread "main" >>> >> [_thread_in_native, id=337452, >>> >> stack(0x000000ae07a00000,0x000000ae07b00000) (1024K)] >>> >> 0x00000268fc08cfc0 JavaThread "Reference Handler" daemon >>> >> [_thread_blocked, id=337356, >>> >> stack(0x000000ae08200000,0x000000ae08300000) (1024K)] >>> >> 0x00000268fc08d5f0 JavaThread "Finalizer" daemon >>> >> [_thread_blocked, id=338708, >>> >> stack(0x000000ae08300000,0x000000ae08400000) (1024K)] >>> >> 0x00000268fc091710 JavaThread "Signal Dispatcher" daemon >>> >> [_thread_blocked, id=338204, >>> >> stack(0x000000ae08400000,0x000000ae08500000) (1024K)] >>> >> 0x00000268fc092140 JavaThread "Attach Listener" daemon >>> >> [_thread_blocked, id=338748, >>> >> stack(0x000000ae08500000,0x000000ae08600000) (1024K)] >>> >> 0x00000268fc0936e0 JavaThread "Service Thread" daemon >>> >> [_thread_blocked, id=337172, >>> >> stack(0x000000ae08600000,0x000000ae08700000) (1024K)] >>> >> 0x00000268fc09d2a0 JavaThread "Monitor Deflation Thread" daemon >>> >> [_thread_blocked, id=337312, >>> >> stack(0x000000ae08700000,0x000000ae08800000) (1024K)] >>> >> 0x00000268fc0d8ec0 JavaThread "Notification Thread" daemon >>> >> [_thread_blocked, id=337560, >>> >> stack(0x000000ae08800000,0x000000ae08900000) (1024K)] >>> >> 0x00000268fc0de6e0 JavaThread "Common-Cleaner" daemon >>> >> [_thread_blocked, id=338324, >>> >> stack(0x000000ae08900000,0x000000ae08a00000) (1024K)] >>> >> Total: 9 >>> >> >>> >> Other Threads: >>> >> 0x00000268fc07c960 VMThread "VM Thread" >>> >> [id=337424, stack(0x000000ae08100000,0x000000ae08200000) (1024K)] >>> >> 0x00000268fbf41360 WatcherThread "VM Periodic Task Thread" >>> >> [id=333244, stack(0x000000ae08000000,0x000000ae08100000) (1024K)] >>> >> 0x00000268e7d7d550 WorkerThread "GC Thread#0" >>> >> [id=336784, stack(0x000000ae07b00000,0x000000ae07c00000) (1024K)] >>> >> 0x00000268e7d951c0 ConcurrentGCThread "G1 Main Marker" >>> >> [id=338660, stack(0x000000ae07c00000,0x000000ae07d00000) (1024K)] >>> >> 0x00000268e7d96850 WorkerThread "G1 Conc#0" >>> >> [id=19564, stack(0x000000ae07d00000,0x000000ae07e00000) (1024K)] >>> >> 0x00000268fbf39000 ConcurrentGCThread "G1 Refine#0" >>> >> [id=217884, stack(0x000000ae07e00000,0x000000ae07f00000) (1024K)] >>> >> 0x00000268fbf39780 ConcurrentGCThread "G1 Service" >>> >> [id=338408, stack(0x000000ae07f00000,0x000000ae08000000) (1024K)] >>> >> Total: 7 >>> >> >>> >> Threads with active compile tasks: >>> >> Total: 0 >>> >> >>> >> VM state: not at safepoint (normal execution) >>> >> >>> >> VM Mutex/Monitor currently owned by a thread: None >>> >> >>> >> Heap address: 0x000000070c800000, size: 3896 MB, Compressed Oops mode: >>> >> Zero based, Oop shift amount: 3 >>> >> >>> >> CDS archive(s) mapped at: >>> >> [0x0000026880000000-0x0000026880d30000-0x0000026880d30000), size >>> >> 13828096, SharedBaseAddress: 0x0000026880000000, >>> >> ArchiveRelocationMode: 1. >>> >> Compressed class space mapped at: >>> >> 0x0000026881000000-0x00000268c1000000, reserved size: 1073741824 >>> >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 >>> >> Narrow klass pointer bits 32, Max shift 3 >>> >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 >>> >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 bytes) >>> >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 bytes) >>> >> Klass ID Range: [65536 - 1090519033) (1090453497) >>> >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) >>> >> >>> >> GC Precious Log: >>> >> CardTable entry size: 512 >>> >> Card Set container configuration: InlinePtr #cards 4 size 8 Array Of >>> >> Cards #cards 16 size 48 Howl #buckets 8 coarsen threshold 3686 Howl >>> >> Bitmap #cards 512 size 80 coarsen threshold 460 Card regions per heap >>> >> region 1 cards per card region 4096 >>> >> CPUs: 24 total, 24 available >>> >> Memory: 15578M >>> >> Large Page Support: Disabled >>> >> NUMA Support: Disabled >>> >> Compressed Oops: Enabled (Zero based) >>> >> Heap Region Size: 2M >>> >> Heap Min Capacity: 8M >>> >> Heap Initial Capacity: 244M >>> >> Heap Max Capacity: 3896M >>> >> Pre-touch: Disabled >>> >> Parallel Workers: 18 >>> >> Concurrent Workers: 5 >>> >> Concurrent Refinement Workers: 18 >>> >> Periodic GC: Disabled >>> >> >>> >> Heap: >>> >> garbage-first heap total reserved 3989504K, committed 251904K, used >>> >> 1136K [0x000000070c800000, 0x0000000800000000) >>> >> region size 2048K, 1 young (2048K), 0 survivors (0K) >>> >> Metaspace used 21K, committed 256K, reserved 1114112K >>> >> class space used 6K, committed 128K, reserved 1048576K >>> >> >>> >> Heap Regions: E=young(eden), S=young(survivor), O=old, >>> >> HS=humongous(starts), HC=humongous(continues), CS=collection set, >>> >> F=free, TAMS=top-at-mark-start, PB=parsable bottom >>> >> | 0|0x000000070c800000, 0x000000070c800000, 0x000000070ca00000| 0%| >>> >> F| |TAMS 0x000000070c800000| PB 0x000000070c800000| Untracked | 0 >>> >> | 1|0x000000070ca00000, 0x000000070ca00000, 0x000000070cc00000| 0%| >>> >> F| |TAMS 0x000000070ca00000| PB 0x000000070ca00000| Untracked | 0 >>> >> | 2|0x000000070cc00000, 0x000000070cc00000, 0x000000070ce00000| 0%| >>> >> F| |TAMS 0x000000070cc00000| PB 0x000000070cc00000| Untracked | 0 >>> >> | 3|0x000000070ce00000, 0x000000070ce00000, 0x000000070d000000| 0%| >>> >> F| |TAMS 0x000000070ce00000| PB 0x000000070ce00000| Untracked | 0 >>> >> | 4|0x000000070d000000, 0x000000070d000000, 0x000000070d200000| 0%| >>> >> F| |TAMS 0x000000070d000000| PB 0x000000070d000000| Untracked | 0 >>> >> | 5|0x000000070d200000, 0x000000070d200000, 0x000000070d400000| 0%| >>> >> F| |TAMS 0x000000070d200000| PB 0x000000070d200000| Untracked | 0 >>> >> | 6|0x000000070d400000, 0x000000070d400000, 0x000000070d600000| 0%| >>> >> F| |TAMS 0x000000070d400000| PB 0x000000070d400000| Untracked | 0 >>> >> | 7|0x000000070d600000, 0x000000070d600000, 0x000000070d800000| 0%| >>> >> F| |TAMS 0x000000070d600000| PB 0x000000070d600000| Untracked | 0 >>> >> | 8|0x000000070d800000, 0x000000070d800000, 0x000000070da00000| 0%| >>> >> F| |TAMS 0x000000070d800000| PB 0x000000070d800000| Untracked | 0 >>> >> | 9|0x000000070da00000, 0x000000070da00000, 0x000000070dc00000| 0%| >>> >> F| |TAMS 0x000000070da00000| PB 0x000000070da00000| Untracked | 0 >>> >> | 10|0x000000070dc00000, 0x000000070dc00000, 0x000000070de00000| 0%| >>> >> F| |TAMS 0x000000070dc00000| PB 0x000000070dc00000| Untracked | 0 >>> >> | 11|0x000000070de00000, 0x000000070de00000, 0x000000070e000000| 0%| >>> >> F| |TAMS 0x000000070de00000| PB 0x000000070de00000| Untracked | 0 >>> >> | 12|0x000000070e000000, 0x000000070e000000, 0x000000070e200000| 0%| >>> >> F| |TAMS 0x000000070e000000| PB 0x000000070e000000| Untracked | 0 >>> >> | 13|0x000000070e200000, 0x000000070e200000, 0x000000070e400000| 0%| >>> >> F| |TAMS 0x000000070e200000| PB 0x000000070e200000| Untracked | 0 >>> >> | 14|0x000000070e400000, 0x000000070e400000, 0x000000070e600000| 0%| >>> >> F| |TAMS 0x000000070e400000| PB 0x000000070e400000| Untracked | 0 >>> >> | 15|0x000000070e600000, 0x000000070e600000, 0x000000070e800000| 0%| >>> >> F| |TAMS 0x000000070e600000| PB 0x000000070e600000| Untracked | 0 >>> >> | 16|0x000000070e800000, 0x000000070e800000, 0x000000070ea00000| 0%| >>> >> F| |TAMS 0x000000070e800000| PB 0x000000070e800000| Untracked | 0 >>> >> | 17|0x000000070ea00000, 0x000000070ea00000, 0x000000070ec00000| 0%| >>> >> F| |TAMS 0x000000070ea00000| PB 0x000000070ea00000| Untracked | 0 >>> >> | 18|0x000000070ec00000, 0x000000070ec00000, 0x000000070ee00000| 0%| >>> >> F| |TAMS 0x000000070ec00000| PB 0x000000070ec00000| Untracked | 0 >>> >> | 19|0x000000070ee00000, 0x000000070ee00000, 0x000000070f000000| 0%| >>> >> F| |TAMS 0x000000070ee00000| PB 0x000000070ee00000| Untracked | 0 >>> >> | 20|0x000000070f000000, 0x000000070f000000, 0x000000070f200000| 0%| >>> >> F| |TAMS 0x000000070f000000| PB 0x000000070f000000| Untracked | 0 >>> >> | 21|0x000000070f200000, 0x000000070f200000, 0x000000070f400000| 0%| >>> >> F| |TAMS 0x000000070f200000| PB 0x000000070f200000| Untracked | 0 >>> >> | 22|0x000000070f400000, 0x000000070f400000, 0x000000070f600000| 0%| >>> >> F| |TAMS 0x000000070f400000| PB 0x000000070f400000| Untracked | 0 >>> >> | 23|0x000000070f600000, 0x000000070f600000, 0x000000070f800000| 0%| >>> >> F| |TAMS 0x000000070f600000| PB 0x000000070f600000| Untracked | 0 >>> >> | 24|0x000000070f800000, 0x000000070f800000, 0x000000070fa00000| 0%| >>> >> F| |TAMS 0x000000070f800000| PB 0x000000070f800000| Untracked | 0 >>> >> | 25|0x000000070fa00000, 0x000000070fa00000, 0x000000070fc00000| 0%| >>> >> F| |TAMS 0x000000070fa00000| PB 0x000000070fa00000| Untracked | 0 >>> >> | 26|0x000000070fc00000, 0x000000070fc00000, 0x000000070fe00000| 0%| >>> >> F| |TAMS 0x000000070fc00000| PB 0x000000070fc00000| Untracked | 0 >>> >> | 27|0x000000070fe00000, 0x000000070fe00000, 0x0000000710000000| 0%| >>> >> F| |TAMS 0x000000070fe00000| PB 0x000000070fe00000| Untracked | 0 >>> >> | 28|0x0000000710000000, 0x0000000710000000, 0x0000000710200000| 0%| >>> >> F| |TAMS 0x0000000710000000| PB 0x0000000710000000| Untracked | 0 >>> >> | 29|0x0000000710200000, 0x0000000710200000, 0x0000000710400000| 0%| >>> >> F| |TAMS 0x0000000710200000| PB 0x0000000710200000| Untracked | 0 >>> >> | 30|0x0000000710400000, 0x0000000710400000, 0x0000000710600000| 0%| >>> >> F| |TAMS 0x0000000710400000| PB 0x0000000710400000| Untracked | 0 >>> >> | 31|0x0000000710600000, 0x0000000710600000, 0x0000000710800000| 0%| >>> >> F| |TAMS 0x0000000710600000| PB 0x0000000710600000| Untracked | 0 >>> >> | 32|0x0000000710800000, 0x0000000710800000, 0x0000000710a00000| 0%| >>> >> F| |TAMS 0x0000000710800000| PB 0x0000000710800000| Untracked | 0 >>> >> | 33|0x0000000710a00000, 0x0000000710a00000, 0x0000000710c00000| 0%| >>> >> F| |TAMS 0x0000000710a00000| PB 0x0000000710a00000| Untracked | 0 >>> >> | 34|0x0000000710c00000, 0x0000000710c00000, 0x0000000710e00000| 0%| >>> >> F| |TAMS 0x0000000710c00000| PB 0x0000000710c00000| Untracked | 0 >>> >> | 35|0x0000000710e00000, 0x0000000710e00000, 0x0000000711000000| 0%| >>> >> F| |TAMS 0x0000000710e00000| PB 0x0000000710e00000| Untracked | 0 >>> >> | 36|0x0000000711000000, 0x0000000711000000, 0x0000000711200000| 0%| >>> >> F| |TAMS 0x0000000711000000| PB 0x0000000711000000| Untracked | 0 >>> >> | 37|0x0000000711200000, 0x0000000711200000, 0x0000000711400000| 0%| >>> >> F| |TAMS 0x0000000711200000| PB 0x0000000711200000| Untracked | 0 >>> >> | 38|0x0000000711400000, 0x0000000711400000, 0x0000000711600000| 0%| >>> >> F| |TAMS 0x0000000711400000| PB 0x0000000711400000| Untracked | 0 >>> >> | 39|0x0000000711600000, 0x0000000711600000, 0x0000000711800000| 0%| >>> >> F| |TAMS 0x0000000711600000| PB 0x0000000711600000| Untracked | 0 >>> >> | 40|0x0000000711800000, 0x0000000711800000, 0x0000000711a00000| 0%| >>> >> F| |TAMS 0x0000000711800000| PB 0x0000000711800000| Untracked | 0 >>> >> | 41|0x0000000711a00000, 0x0000000711a00000, 0x0000000711c00000| 0%| >>> >> F| |TAMS 0x0000000711a00000| PB 0x0000000711a00000| Untracked | 0 >>> >> | 42|0x0000000711c00000, 0x0000000711c00000, 0x0000000711e00000| 0%| >>> >> F| |TAMS 0x0000000711c00000| PB 0x0000000711c00000| Untracked | 0 >>> >> | 43|0x0000000711e00000, 0x0000000711e00000, 0x0000000712000000| 0%| >>> >> F| |TAMS 0x0000000711e00000| PB 0x0000000711e00000| Untracked | 0 >>> >> | 44|0x0000000712000000, 0x0000000712000000, 0x0000000712200000| 0%| >>> >> F| |TAMS 0x0000000712000000| PB 0x0000000712000000| Untracked | 0 >>> >> | 45|0x0000000712200000, 0x0000000712200000, 0x0000000712400000| 0%| >>> >> F| |TAMS 0x0000000712200000| PB 0x0000000712200000| Untracked | 0 >>> >> | 46|0x0000000712400000, 0x0000000712400000, 0x0000000712600000| 0%| >>> >> F| |TAMS 0x0000000712400000| PB 0x0000000712400000| Untracked | 0 >>> >> | 47|0x0000000712600000, 0x0000000712600000, 0x0000000712800000| 0%| >>> >> F| |TAMS 0x0000000712600000| PB 0x0000000712600000| Untracked | 0 >>> >> | 48|0x0000000712800000, 0x0000000712800000, 0x0000000712a00000| 0%| >>> >> F| |TAMS 0x0000000712800000| PB 0x0000000712800000| Untracked | 0 >>> >> | 49|0x0000000712a00000, 0x0000000712a00000, 0x0000000712c00000| 0%| >>> >> F| |TAMS 0x0000000712a00000| PB 0x0000000712a00000| Untracked | 0 >>> >> | 50|0x0000000712c00000, 0x0000000712c00000, 0x0000000712e00000| 0%| >>> >> F| |TAMS 0x0000000712c00000| PB 0x0000000712c00000| Untracked | 0 >>> >> | 51|0x0000000712e00000, 0x0000000712e00000, 0x0000000713000000| 0%| >>> >> F| |TAMS 0x0000000712e00000| PB 0x0000000712e00000| Untracked | 0 >>> >> | 52|0x0000000713000000, 0x0000000713000000, 0x0000000713200000| 0%| >>> >> F| |TAMS 0x0000000713000000| PB 0x0000000713000000| Untracked | 0 >>> >> | 53|0x0000000713200000, 0x0000000713200000, 0x0000000713400000| 0%| >>> >> F| |TAMS 0x0000000713200000| PB 0x0000000713200000| Untracked | 0 >>> >> | 54|0x0000000713400000, 0x0000000713400000, 0x0000000713600000| 0%| >>> >> F| |TAMS 0x0000000713400000| PB 0x0000000713400000| Untracked | 0 >>> >> | 55|0x0000000713600000, 0x0000000713600000, 0x0000000713800000| 0%| >>> >> F| |TAMS 0x0000000713600000| PB 0x0000000713600000| Untracked | 0 >>> >> | 56|0x0000000713800000, 0x0000000713800000, 0x0000000713a00000| 0%| >>> >> F| |TAMS 0x0000000713800000| PB 0x0000000713800000| Untracked | 0 >>> >> | 57|0x0000000713a00000, 0x0000000713a00000, 0x0000000713c00000| 0%| >>> >> F| |TAMS 0x0000000713a00000| PB 0x0000000713a00000| Untracked | 0 >>> >> | 58|0x0000000713c00000, 0x0000000713c00000, 0x0000000713e00000| 0%| >>> >> F| |TAMS 0x0000000713c00000| PB 0x0000000713c00000| Untracked | 0 >>> >> | 59|0x0000000713e00000, 0x0000000713e00000, 0x0000000714000000| 0%| >>> >> F| |TAMS 0x0000000713e00000| PB 0x0000000713e00000| Untracked | 0 >>> >> | 60|0x0000000714000000, 0x0000000714000000, 0x0000000714200000| 0%| >>> >> F| |TAMS 0x0000000714000000| PB 0x0000000714000000| Untracked | 0 >>> >> | 61|0x0000000714200000, 0x0000000714200000, 0x0000000714400000| 0%| >>> >> F| |TAMS 0x0000000714200000| PB 0x0000000714200000| Untracked | 0 >>> >> | 62|0x0000000714400000, 0x0000000714400000, 0x0000000714600000| 0%| >>> >> F| |TAMS 0x0000000714400000| PB 0x0000000714400000| Untracked | 0 >>> >> | 63|0x0000000714600000, 0x0000000714600000, 0x0000000714800000| 0%| >>> >> F| |TAMS 0x0000000714600000| PB 0x0000000714600000| Untracked | 0 >>> >> | 64|0x0000000714800000, 0x0000000714800000, 0x0000000714a00000| 0%| >>> >> F| |TAMS 0x0000000714800000| PB 0x0000000714800000| Untracked | 0 >>> >> | 65|0x0000000714a00000, 0x0000000714a00000, 0x0000000714c00000| 0%| >>> >> F| |TAMS 0x0000000714a00000| PB 0x0000000714a00000| Untracked | 0 >>> >> | 66|0x0000000714c00000, 0x0000000714c00000, 0x0000000714e00000| 0%| >>> >> F| |TAMS 0x0000000714c00000| PB 0x0000000714c00000| Untracked | 0 >>> >> | 67|0x0000000714e00000, 0x0000000714e00000, 0x0000000715000000| 0%| >>> >> F| |TAMS 0x0000000714e00000| PB 0x0000000714e00000| Untracked | 0 >>> >> | 68|0x0000000715000000, 0x0000000715000000, 0x0000000715200000| 0%| >>> >> F| |TAMS 0x0000000715000000| PB 0x0000000715000000| Untracked | 0 >>> >> | 69|0x0000000715200000, 0x0000000715200000, 0x0000000715400000| 0%| >>> >> F| |TAMS 0x0000000715200000| PB 0x0000000715200000| Untracked | 0 >>> >> | 70|0x0000000715400000, 0x0000000715400000, 0x0000000715600000| 0%| >>> >> F| |TAMS 0x0000000715400000| PB 0x0000000715400000| Untracked | 0 >>> >> | 71|0x0000000715600000, 0x0000000715600000, 0x0000000715800000| 0%| >>> >> F| |TAMS 0x0000000715600000| PB 0x0000000715600000| Untracked | 0 >>> >> | 72|0x0000000715800000, 0x0000000715800000, 0x0000000715a00000| 0%| >>> >> F| |TAMS 0x0000000715800000| PB 0x0000000715800000| Untracked | 0 >>> >> | 73|0x0000000715a00000, 0x0000000715a00000, 0x0000000715c00000| 0%| >>> >> F| |TAMS 0x0000000715a00000| PB 0x0000000715a00000| Untracked | 0 >>> >> | 74|0x0000000715c00000, 0x0000000715c00000, 0x0000000715e00000| 0%| >>> >> F| |TAMS 0x0000000715c00000| PB 0x0000000715c00000| Untracked | 0 >>> >> | 75|0x0000000715e00000, 0x0000000715e00000, 0x0000000716000000| 0%| >>> >> F| |TAMS 0x0000000715e00000| PB 0x0000000715e00000| Untracked | 0 >>> >> | 76|0x0000000716000000, 0x0000000716000000, 0x0000000716200000| 0%| >>> >> F| |TAMS 0x0000000716000000| PB 0x0000000716000000| Untracked | 0 >>> >> | 77|0x0000000716200000, 0x0000000716200000, 0x0000000716400000| 0%| >>> >> F| |TAMS 0x0000000716200000| PB 0x0000000716200000| Untracked | 0 >>> >> | 78|0x0000000716400000, 0x0000000716400000, 0x0000000716600000| 0%| >>> >> F| |TAMS 0x0000000716400000| PB 0x0000000716400000| Untracked | 0 >>> >> | 79|0x0000000716600000, 0x0000000716600000, 0x0000000716800000| 0%| >>> >> F| |TAMS 0x0000000716600000| PB 0x0000000716600000| Untracked | 0 >>> >> | 80|0x0000000716800000, 0x0000000716800000, 0x0000000716a00000| 0%| >>> >> F| |TAMS 0x0000000716800000| PB 0x0000000716800000| Untracked | 0 >>> >> | 81|0x0000000716a00000, 0x0000000716a00000, 0x0000000716c00000| 0%| >>> >> F| |TAMS 0x0000000716a00000| PB 0x0000000716a00000| Untracked | 0 >>> >> | 82|0x0000000716c00000, 0x0000000716c00000, 0x0000000716e00000| 0%| >>> >> F| |TAMS 0x0000000716c00000| PB 0x0000000716c00000| Untracked | 0 >>> >> | 83|0x0000000716e00000, 0x0000000716e00000, 0x0000000717000000| 0%| >>> >> F| |TAMS 0x0000000716e00000| PB 0x0000000716e00000| Untracked | 0 >>> >> | 84|0x0000000717000000, 0x0000000717000000, 0x0000000717200000| 0%| >>> >> F| |TAMS 0x0000000717000000| PB 0x0000000717000000| Untracked | 0 >>> >> | 85|0x0000000717200000, 0x0000000717200000, 0x0000000717400000| 0%| >>> >> F| |TAMS 0x0000000717200000| PB 0x0000000717200000| Untracked | 0 >>> >> | 86|0x0000000717400000, 0x0000000717400000, 0x0000000717600000| 0%| >>> >> F| |TAMS 0x0000000717400000| PB 0x0000000717400000| Untracked | 0 >>> >> | 87|0x0000000717600000, 0x0000000717600000, 0x0000000717800000| 0%| >>> >> F| |TAMS 0x0000000717600000| PB 0x0000000717600000| Untracked | 0 >>> >> | 88|0x0000000717800000, 0x0000000717800000, 0x0000000717a00000| 0%| >>> >> F| |TAMS 0x0000000717800000| PB 0x0000000717800000| Untracked | 0 >>> >> | 89|0x0000000717a00000, 0x0000000717a00000, 0x0000000717c00000| 0%| >>> >> F| |TAMS 0x0000000717a00000| PB 0x0000000717a00000| Untracked | 0 >>> >> | 90|0x0000000717c00000, 0x0000000717c00000, 0x0000000717e00000| 0%| >>> >> F| |TAMS 0x0000000717c00000| PB 0x0000000717c00000| Untracked | 0 >>> >> | 91|0x0000000717e00000, 0x0000000717e00000, 0x0000000718000000| 0%| >>> >> F| |TAMS 0x0000000717e00000| PB 0x0000000717e00000| Untracked | 0 >>> >> | 92|0x0000000718000000, 0x0000000718000000, 0x0000000718200000| 0%| >>> >> F| |TAMS 0x0000000718000000| PB 0x0000000718000000| Untracked | 0 >>> >> | 93|0x0000000718200000, 0x0000000718200000, 0x0000000718400000| 0%| >>> >> F| |TAMS 0x0000000718200000| PB 0x0000000718200000| Untracked | 0 >>> >> | 94|0x0000000718400000, 0x0000000718400000, 0x0000000718600000| 0%| >>> >> F| |TAMS 0x0000000718400000| PB 0x0000000718400000| Untracked | 0 >>> >> | 95|0x0000000718600000, 0x0000000718600000, 0x0000000718800000| 0%| >>> >> F| |TAMS 0x0000000718600000| PB 0x0000000718600000| Untracked | 0 >>> >> | 96|0x0000000718800000, 0x0000000718800000, 0x0000000718a00000| 0%| >>> >> F| |TAMS 0x0000000718800000| PB 0x0000000718800000| Untracked | 0 >>> >> | 97|0x0000000718a00000, 0x0000000718a00000, 0x0000000718c00000| 0%| >>> >> F| |TAMS 0x0000000718a00000| PB 0x0000000718a00000| Untracked | 0 >>> >> | 98|0x0000000718c00000, 0x0000000718c00000, 0x0000000718e00000| 0%| >>> >> F| |TAMS 0x0000000718c00000| PB 0x0000000718c00000| Untracked | 0 >>> >> | 99|0x0000000718e00000, 0x0000000718e00000, 0x0000000719000000| 0%| >>> >> F| |TAMS 0x0000000718e00000| PB 0x0000000718e00000| Untracked | 0 >>> >> | 100|0x0000000719000000, 0x0000000719000000, 0x0000000719200000| 0%| >>> >> F| |TAMS 0x0000000719000000| PB 0x0000000719000000| Untracked | 0 >>> >> | 101|0x0000000719200000, 0x0000000719200000, 0x0000000719400000| 0%| >>> >> F| |TAMS 0x0000000719200000| PB 0x0000000719200000| Untracked | 0 >>> >> | 102|0x0000000719400000, 0x0000000719400000, 0x0000000719600000| 0%| >>> >> F| |TAMS 0x0000000719400000| PB 0x0000000719400000| Untracked | 0 >>> >> | 103|0x0000000719600000, 0x0000000719600000, 0x0000000719800000| 0%| >>> >> F| |TAMS 0x0000000719600000| PB 0x0000000719600000| Untracked | 0 >>> >> | 104|0x0000000719800000, 0x0000000719800000, 0x0000000719a00000| 0%| >>> >> F| |TAMS 0x0000000719800000| PB 0x0000000719800000| Untracked | 0 >>> >> | 105|0x0000000719a00000, 0x0000000719a00000, 0x0000000719c00000| 0%| >>> >> F| |TAMS 0x0000000719a00000| PB 0x0000000719a00000| Untracked | 0 >>> >> | 106|0x0000000719c00000, 0x0000000719c00000, 0x0000000719e00000| 0%| >>> >> F| |TAMS 0x0000000719c00000| PB 0x0000000719c00000| Untracked | 0 >>> >> | 107|0x0000000719e00000, 0x0000000719e00000, 0x000000071a000000| 0%| >>> >> F| |TAMS 0x0000000719e00000| PB 0x0000000719e00000| Untracked | 0 >>> >> | 108|0x000000071a000000, 0x000000071a000000, 0x000000071a200000| 0%| >>> >> F| |TAMS 0x000000071a000000| PB 0x000000071a000000| Untracked | 0 >>> >> | 109|0x000000071a200000, 0x000000071a200000, 0x000000071a400000| 0%| >>> >> F| |TAMS 0x000000071a200000| PB 0x000000071a200000| Untracked | 0 >>> >> | 110|0x000000071a400000, 0x000000071a400000, 0x000000071a600000| 0%| >>> >> F| |TAMS 0x000000071a400000| PB 0x000000071a400000| Untracked | 0 >>> >> | 111|0x000000071a600000, 0x000000071a600000, 0x000000071a800000| 0%| >>> >> F| |TAMS 0x000000071a600000| PB 0x000000071a600000| Untracked | 0 >>> >> | 112|0x000000071a800000, 0x000000071a800000, 0x000000071aa00000| 0%| >>> >> F| |TAMS 0x000000071a800000| PB 0x000000071a800000| Untracked | 0 >>> >> | 113|0x000000071aa00000, 0x000000071aa00000, 0x000000071ac00000| 0%| >>> >> F| |TAMS 0x000000071aa00000| PB 0x000000071aa00000| Untracked | 0 >>> >> | 114|0x000000071ac00000, 0x000000071ac00000, 0x000000071ae00000| 0%| >>> >> F| |TAMS 0x000000071ac00000| PB 0x000000071ac00000| Untracked | 0 >>> >> | 115|0x000000071ae00000, 0x000000071ae00000, 0x000000071b000000| 0%| >>> >> F| |TAMS 0x000000071ae00000| PB 0x000000071ae00000| Untracked | 0 >>> >> | 116|0x000000071b000000, 0x000000071b000000, 0x000000071b200000| 0%| >>> >> F| |TAMS 0x000000071b000000| PB 0x000000071b000000| Untracked | 0 >>> >> | 117|0x000000071b200000, 0x000000071b200000, 0x000000071b400000| 0%| >>> >> F| |TAMS 0x000000071b200000| PB 0x000000071b200000| Untracked | 0 >>> >> | 118|0x000000071b400000, 0x000000071b400000, 0x000000071b600000| 0%| >>> >> F| |TAMS 0x000000071b400000| PB 0x000000071b400000| Untracked | 0 >>> >> | 119|0x000000071b600000, 0x000000071b600000, 0x000000071b800000| 0%| >>> >> F| |TAMS 0x000000071b600000| PB 0x000000071b600000| Untracked | 0 >>> >> | 120|0x000000071b800000, 0x000000071b800000, 0x000000071ba00000| 0%| >>> >> F| |TAMS 0x000000071b800000| PB 0x000000071b800000| Untracked | 0 >>> >> | 121|0x000000071ba00000, 0x000000071bc00000, 0x000000071bc00000|100%| >>> >> E| |TAMS 0x000000071ba00000| PB 0x000000071ba00000| Complete | 0 >>> >> |1947|0x00000007ffe00000, 0x00000007fff1c148, 0x0000000800000000| 55%| >>> >> O| |TAMS 0x00000007ffe00000| PB 0x00000007ffe00000| Untracked | 0 >>> >> >>> >> Card table byte_map: [0x00000268f51f0000,0x00000268f5990000] >>> >> _byte_map_base: 0x00000268f198c000 >>> >> >>> >> Marking Bits: (CMBitMap*) 0x00000268e7d7dda0 >>> >> Bits: [0x00000268f5990000, 0x00000268f9670000) >>> >> >>> >> Polling page: 0x00000268e5a80000 >>> >> >>> >> Metaspace: >>> >> >>> >> Usage: >>> >> Non-class: 14.61 KB used. >>> >> Class: 6.95 KB used. >>> >> Both: 21.56 KB used. >>> >> >>> >> Virtual space: >>> >> Non-class space: 64.00 MB reserved, 128.00 KB ( <1%) >>> >> committed, 1 nodes. >>> >> Class space: 1.00 GB reserved, 128.00 KB ( <1%) >>> >> committed, 1 nodes. >>> >> Both: 1.06 GB reserved, 256.00 KB ( <1%) committed. >>> >> >>> >> Chunk freelists: >>> >> Non-Class: 12.00 MB >>> >> Class: 15.75 MB >>> >> Both: 27.74 MB >>> >> >>> >> MaxMetaspaceSize: unlimited >>> >> CompressedClassSpaceSize: 1.00 GB >>> >> Initial GC threshold: 21.00 MB >>> >> Current GC threshold: 21.00 MB >>> >> CDS: on >>> >> - commit_granule_bytes: 65536. >>> >> - commit_granule_words: 8192. >>> >> - virtual_space_node_default_size: 8388608. >>> >> - enlarge_chunks_in_place: 1. >>> >> UseCompressedClassPointers 1, UseCompactObjectHeaders 0 >>> >> Narrow klass pointer bits 32, Max shift 3 >>> >> Narrow klass base: 0x0000026880000000, Narrow klass shift: 0 >>> >> Encoding Range: [0x0000026880000000 - 0x0000026980000000), (4294967296 bytes) >>> >> Klass Range: [0x0000026880010000 - 0x00000268c1000000), (1090453504 bytes) >>> >> Klass ID Range: [65536 - 1090519033) (1090453497) >>> >> Protection zone: [0x0000026880000000 - 0x0000026880010000), (65536 bytes) >>> >> >>> >> >>> >> Internal statistics: >>> >> >>> >> num_allocs_failed_limit: 0. >>> >> num_arena_births: 4. >>> >> num_arena_deaths: 0. >>> >> num_vsnodes_births: 2. >>> >> num_vsnodes_deaths: 0. >>> >> num_space_committed: 4. >>> >> num_space_uncommitted: 0. >>> >> num_chunks_returned_to_freelist: 0. >>> >> num_chunks_taken_from_freelist: 4. >>> >> num_chunk_merges: 0. >>> >> num_chunk_splits: 4. >>> >> num_chunks_enlarged: 0. >>> >> num_inconsistent_stats: 0. >>> >> >>> >> CodeCache: size=32768Kb used=84Kb max_used=84Kb free=32683Kb >>> >> bounds [0x00000268f1e90000, 0x00000268f1eb8000, 0x00000268f3e90000] >>> >> total_blobs=225, nmethods=0, adapters=216, full_count=0 >>> >> Compilation: disabled (interpreter mode), stopped_count=0, restarted_count=0 >>> >> >>> >> Compilation events (0 events): >>> >> No events >>> >> >>> >> GC Heap History (0 events): >>> >> No events >>> >> >>> >> Dll operation events (2 events): >>> >> Event: 0.006 Loaded shared library >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll >>> >> Event: 0.286 Loaded shared library >>> >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll >>> >> >>> >> Deoptimization events (0 events): >>> >> No events >>> >> >>> >> Classes loaded (16 events): >>> >> Event: 0.023 Loading class sun/nio/cs/IBM437 >>> >> Event: 0.023 Loading class sun/nio/cs/IBM437 done >>> >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder >>> >> Event: 0.023 Loading class sun/nio/cs/IBM437$Holder done >>> >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook >>> >> Event: 0.026 Loading class jdk/internal/vm/PostVMInitHook done >>> >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader >>> >> Event: 0.026 Loading class jdk/internal/loader/URLClassPath$FileLoader done >>> >> Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 >>> >> Event: 0.027 Loading class jdk/internal/loader/URLClassPath$FileLoader$1 done >>> >> Event: 0.027 Loading class java/lang/InterruptedException >>> >> Event: 0.027 Loading class java/lang/InterruptedException done >>> >> Event: 0.027 Loading class java/lang/CloneNotSupportedException >>> >> Event: 0.027 Loading class java/lang/CloneNotSupportedException done >>> >> Event: 0.028 Loading class java/util/Formatter$FixedString >>> >> Event: 0.029 Loading class java/util/Formatter$FixedString done >>> >> >>> >> Classes unloaded (0 events): >>> >> No events >>> >> >>> >> Classes redefined (0 events): >>> >> No events >>> >> >>> >> Internal exceptions (0 events): >>> >> No events >>> >> >>> >> VM Operations (0 events): >>> >> No events >>> >> >>> >> Memory protections (0 events): >>> >> No events >>> >> >>> >> Nmethod flushes (0 events): >>> >> No events >>> >> >>> >> Events (9 events): >>> >> Event: 0.017 Thread 0x00000268e57a3d20 Thread added: 0x00000268e57a3d20 >>> >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08cfc0 >>> >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc08d5f0 >>> >> Event: 0.023 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc091710 >>> >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc092140 >>> >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0936e0 >>> >> Event: 0.024 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc09d2a0 >>> >> Event: 0.026 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0d8ec0 >>> >> Event: 0.027 Thread 0x00000268e57a3d20 Thread added: 0x00000268fc0de6e0 >>> >> >>> >> >>> >> Dynamic libraries: >>> >> 0x00007ff7bcd60000 - 0x00007ff7bcd70000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.exe >>> >> 0x00007ffd45be0000 - 0x00007ffd45e40000 C:\WINDOWS\SYSTEM32\ntdll.dll >>> >> 0x00007ffd44600000 - 0x00007ffd446c7000 C:\WINDOWS\System32\KERNEL32.DLL >>> >> 0x00007ffd43490000 - 0x00007ffd4385a000 C:\WINDOWS\System32\KERNELBASE.dll >>> >> 0x00007ffd42dc0000 - 0x00007ffd42f0b000 C:\WINDOWS\System32\ucrtbase.dll >>> >> 0x00007ffd30100000 - 0x00007ffd3011d000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\VCRUNTIME140.dll >>> >> 0x00007ffd2a470000 - 0x00007ffd2a487000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jli.dll >>> >> 0x00007ffd450e0000 - 0x00007ffd452ac000 C:\WINDOWS\System32\USER32.dll >>> >> 0x00007ffd41f90000 - 0x00007ffd42227000 >>> >> C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24\COMCTL32.dll >>> >> 0x00007ffd43040000 - 0x00007ffd43067000 C:\WINDOWS\System32\win32u.dll >>> >> 0x00007ffd44a40000 - 0x00007ffd44ae9000 C:\WINDOWS\System32\msvcrt.dll >>> >> 0x00007ffd44af0000 - 0x00007ffd44b1a000 C:\WINDOWS\System32\GDI32.dll >>> >> 0x00007ffd43130000 - 0x00007ffd43261000 C:\WINDOWS\System32\gdi32full.dll >>> >> 0x00007ffd433e0000 - 0x00007ffd43483000 C:\WINDOWS\System32\msvcp_win.dll >>> >> 0x00007ffd44560000 - 0x00007ffd4458f000 C:\WINDOWS\System32\IMM32.DLL >>> >> 0x00007ffd27710000 - 0x00007ffd2771c000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\vcruntime140_1.dll >>> >> 0x00007ffd14e00000 - 0x00007ffd14e8d000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\msvcp140.dll >>> >> 0x00007ffceaf00000 - 0x00007ffceb4cf000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero\jvm.dll >>> >> 0x00007ffd452b0000 - 0x00007ffd45362000 C:\WINDOWS\System32\ADVAPI32.dll >>> >> 0x00007ffd44780000 - 0x00007ffd44826000 C:\WINDOWS\System32\sechost.dll >>> >> 0x00007ffd442d0000 - 0x00007ffd443e6000 C:\WINDOWS\System32\RPCRT4.dll >>> >> 0x00007ffd446d0000 - 0x00007ffd44744000 C:\WINDOWS\System32\WS2_32.dll >>> >> 0x00007ffd42c30000 - 0x00007ffd42c8e000 C:\WINDOWS\SYSTEM32\POWRPROF.dll >>> >> 0x00007ffd332f0000 - 0x00007ffd33326000 C:\WINDOWS\SYSTEM32\WINMM.dll >>> >> 0x00007ffd391c0000 - 0x00007ffd391cb000 C:\WINDOWS\SYSTEM32\VERSION.dll >>> >> 0x00007ffd16d70000 - 0x00007ffd16d81000 C:\msys64\ucrt64\bin\libffi-8.dll >>> >> 0x00007ffd42c10000 - 0x00007ffd42c24000 C:\WINDOWS\SYSTEM32\UMPDC.dll >>> >> 0x00007ffd41a60000 - 0x00007ffd41a6c000 C:\WINDOWS\SYSTEM32\CRYPTBASE.DLL >>> >> 0x00007ffd42fa0000 - 0x00007ffd43039000 C:\WINDOWS\System32\bcryptPrimitives.dll >>> >> 0x00007ffd41270000 - 0x00007ffd4128a000 C:\WINDOWS\SYSTEM32\kernel.appcore.dll >>> >> 0x00007ffd27060000 - 0x00007ffd2706a000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\jimage.dll >>> >> 0x00007ffd42540000 - 0x00007ffd42781000 C:\WINDOWS\SYSTEM32\DBGHELP.DLL >>> >> 0x00007ffd44d50000 - 0x00007ffd450d2000 C:\WINDOWS\System32\combase.dll >>> >> 0x00007ffd439e0000 - 0x00007ffd43ab6000 C:\WINDOWS\System32\OLEAUT32.dll >>> >> 0x00007ffd01660000 - 0x00007ffd01699000 C:\WINDOWS\SYSTEM32\dbgcore.DLL >>> >> 0x00007ffd16d50000 - 0x00007ffd16d6d000 >>> >> C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\java.dll >>> >> 0x00007ffd44b20000 - 0x00007ffd44cb6000 C:\WINDOWS\System32\ole32.dll >>> >> 0x00007ffd45370000 - 0x00007ffd45a99000 C:\WINDOWS\System32\SHELL32.dll >>> >> 0x00007ffd43270000 - 0x00007ffd433d8000 C:\WINDOWS\System32\wintypes.dll >>> >> 0x00007ffd3ff80000 - 0x00007ffd407d2000 C:\WINDOWS\SYSTEM32\windows.storage.dll >>> >> 0x00007ffd44400000 - 0x00007ffd444ed000 C:\WINDOWS\System32\SHCORE.dll >>> >> 0x00007ffd444f0000 - 0x00007ffd44554000 C:\WINDOWS\System32\shlwapi.dll >>> >> 0x00007ffd42cd0000 - 0x00007ffd42cff000 C:\WINDOWS\SYSTEM32\profapi.dll >>> >> 0x00007ffd15180000 - 0x00007ffd15192000 >>> >> C:\Users\REDACTED\Downloads\LoadLibrary\Crash\Crash.dll >>> >> >>> >> JVMTI agents: none >>> >> >>> >> dbghelp: loaded successfully - version: 4.0.5 - missing functions: none >>> >> symbol engine: initialized successfully - sym options: 0x614 - pdb >>> >> path: .;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin;C:\WINDOWS\SYSTEM32;C:\WINDOWS\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3624_none_3e086962e3345f24;C:\Users\REDACTED\Downloads\eclipse-committers-2023-12-R-win32-x86_64\Workspace\jdk\build\windows-x86_64-zero-release\images\jdk\bin\zero;C:\msys64\ucrt64\bin;C:\Users\REDACTED\Downloads\LoadLibrary\Crash >>> >> >>> >> VM Arguments: >>> >> jvm_args: --enable-preview >>> >> java_command: Crash >>> >> java_class_path (initial): C:/Users/REDACTED/Downloads/LoadLibrary/Crash >>> >> Launcher Type: SUN_STANDARD >>> >> >>> >> [Global flags] >>> >> uint ConcGCThreads = 5 >>> >> {product} {ergonomic} >>> >> uint G1ConcRefinementThreads = 18 >>> >> {product} {ergonomic} >>> >> size_t G1HeapRegionSize = 2097152 >>> >> {product} {ergonomic} >>> >> size_t InitialHeapSize = 255852544 >>> >> {product} {ergonomic} >>> >> size_t MarkStackSize = 4194304 >>> >> {product} {ergonomic} >>> >> size_t MarkStackSizeMax = 536870912 >>> >> {product} {ergonomic} >>> >> size_t MaxHeapSize = 4085252096 >>> >> {product} {ergonomic} >>> >> size_t MaxNewSize = 2449473536 >>> >> {product} {ergonomic} >>> >> size_t MinHeapDeltaBytes = 2097152 >>> >> {product} {ergonomic} >>> >> size_t MinHeapSize = 8388608 >>> >> {product} {ergonomic} >>> >> uintx NonNMethodCodeHeapSize = 4096 >>> >> {pd product} {ergonomic} >>> >> uintx NonProfiledCodeHeapSize = 0 >>> >> {pd product} {ergonomic} >>> >> uintx ProfiledCodeHeapSize = 0 >>> >> {pd product} {ergonomic} >>> >> size_t SoftMaxHeapSize = 4085252096 >>> >> {manageable} {ergonomic} >>> >> bool UseCompressedOops = true >>> >> {product lp64_product} {ergonomic} >>> >> bool UseG1GC = true >>> >> {product} {ergonomic} >>> >> bool UseLargePagesIndividualAllocation = false >>> >> {pd product} {ergonomic} >>> >> >>> >> Logging: >>> >> Log output configuration: >>> >> #0: stdout all=warning uptime,level,tags foldmultilines=false >>> >> #1: stderr all=off uptime,level,tags foldmultilines=false >>> >> >>> >> Release file: >>> >> IMPLEMENTOR="N/A" >>> >> JAVA_RUNTIME_VERSION="25-internal" >>> >> JAVA_VERSION="25" >>> >> JAVA_VERSION_DATE="2025-09-16" >>> >> LIBC="default" >>> >> MODULES="java.base java.compiler java.datatransfer java.xml java.prefs >>> >> java.desktop java.instrument java.logging java.management >>> >> java.security.sasl java.naming java.rmi java.management.rmi >>> >> java.net.http java.scripting java.security.jgss java.transaction.xa >>> >> java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio >>> >> jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets >>> >> jdk.internal.opt jdk.zipfs jdk.compiler jdk.crypto.cryptoki >>> >> jdk.crypto.ec jdk.crypto.mscapi jdk.dynalink jdk.internal.ed >>> >> jdk.editpad jdk.httpserver jdk.incubator.vector jdk.internal.le >>> >> jdk.internal.md jdk.jartool jdk.javadoc jdk.jcmd jdk.management >>> >> jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi >>> >> jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd >>> >> jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi >>> >> jdk.net jdk.nio.mapmode jdk.sctp jdk.security.auth jdk.security.jgss >>> >> jdk.unsupported jdk.unsupported.desktop jdk.xml.dom" >>> >> OS_ARCH="x86_64" >>> >> OS_NAME="Windows" >>> >> SOURCE=".:git:8f7652d7a36b+" >>> >> >>> >> Environment Variables: >>> >> PATH=C:\msys64\ucrt64\bin;C:\msys64\usr\local\bin;C:\msys64\usr\bin;C:\msys64\usr\bin;C:\Windows\System32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin\site_perl;C:\msys64\usr\bin\vendor_perl;C:\msys64\usr\bin\core_perl >>> >> USERNAME=REDACTED >>> >> SHELL=C:\msys64\usr\bin\bash.exe >>> >> LC_CTYPE=en_US.UTF-8 >>> >> TERM=xterm >>> >> OS=Windows_NT >>> >> PROCESSOR_IDENTIFIER=AMD64 Family 25 Model 97 Stepping 2, AuthenticAMD >>> >> TMP=C:\msys64\tmp >>> >> TEMP=C:\msys64\tmp >>> >> >>> >> >>> >> >>> >> >>> >> Compilation memory statistics disabled. >>> >> >>> >> Periodic native trim disabled >>> >> >>> >> --------------- S Y S T E M --------------- >>> >> >>> >> OS: >>> >> Windows 11 , 64 bit Build 26100 (10.0.26100.3775) >>> >> OS uptime: 0 days 1:47 hours >>> >> >>> >> CPU: total 24 (initial active 24) >>> >> Processor Information for processor 0 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 1 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 2 >>> >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 >>> >> Processor Information for processor 3 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 4 >>> >> Max Mhz: 3001, Current Mhz: 3001, Mhz Limit: 3001 >>> >> Processor Information for processor 5 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 6 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 7 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 8 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 9 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 10 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 11 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 12 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 13 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 14 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 15 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 16 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 17 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 18 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 19 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 20 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 21 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 22 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> Processor Information for processor 23 >>> >> Max Mhz: 3001, Current Mhz: 2490, Mhz Limit: 3001 >>> >> >>> >> Memory: 4k page, system-wide physical 15578M (1690M free) >>> >> TotalPageFile size 44250M (AvailPageFile size 20548M) >>> >> current process WorkingSet (physical memory assigned to process): 64M, peak: 64M >>> >> current process commit charge ("private bytes"): 373M, peak: 373M >>> >> >>> >> vm_info: Java HotSpot 64-Bit Zero VM (25-internal) for windows-amd64 >>> >> JRE (25-internal), built on 2025-04-17T14:32:22Z with MS VC++ 17.8 >>> >> (VS2022) >>> >> >>> >> END. >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-161-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:162:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): >>> >> warning C5030: attribute [[gnu::packed]] is not recognized >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log-320-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/BUILD_LIBJVM_pch.o.log:321:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log-13-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:15:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/interpreterRT_zero.o.log:16:jdk\src\hotspot\cpu\zero\interpreterRT_zero.cpp(161): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-168-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\bytes_zero.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:169:jdk\src\hotspot\cpu\zero\bytes_zero.hpp(31): >>> >> warning C5030: attribute [[gnu::packed]] is not recognized >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log-307-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/os_windows.o.log:308:jdk\src\hotspot\cpu\zero\stack_zero.hpp(92): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log-7-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:8:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:9:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stack_zero.o.log:10:jdk\src\hotspot\cpu\zero\stack_zero.cpp(36): >>> >> warning C4267: '=': conversion from 'size_t' to 'int', possible loss >>> >> of data >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log-12-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:13:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/stubGenerator_zero.o.log:14:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log-28-Note: >>> >> including file: jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:29:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(51): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> /jdk/build/windows-x86_64-zero-release/hotspot/variant-zero/libjvm/objects/zeroInterpreter_zero.o.log:30:jdk\src\hotspot\cpu\zero\stack_zero.inline.hpp(53): >>> >> warning C4267: 'initializing': conversion from 'size_t' to 'int', >>> >> possible loss of data >>> >> >>> >> Generating code >>> >> Previous IPDB not found, fall back to full compilation. >>> >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >>> >> C4723: potential divide by 0 >>> >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >>> >> C4723: potential divide by 0 >>> >> s\src\hotspot\share\compiler\compilationPolicy.cpp(457) : warning >>> >> C4723: potential divide by 0 >>> >> All 52893 functions were compiled because no usable IPDB/IOBJ from >>> >> previous compilation was found. >>> >> Finished generating code From tanksherman27 at gmail.com Thu Apr 24 15:33:53 2025 From: tanksherman27 at gmail.com (Julian Waters) Date: Thu, 24 Apr 2025 23:33:53 +0800 Subject: Windows/Zero In-Reply-To: <946aaf6f-9920-4305-a395-b9ef74f14b9e@oracle.com> References: <946aaf6f-9920-4305-a395-b9ef74f14b9e@oracle.com> Message-ID: Hi Kim, See my reply to Thomas. I understand that there's not much interest in the work now. The only open question I have is how Zero on other platforms has been functioning with zero (Heh) sized register arrays with code that accesses the contents of those arrays also present as well, but I guess that's a discussion for later. Maybe it needs looking into, maybe it's fine. Thanks for your time. best regards, Julian On Thu, Apr 24, 2025 at 10:59?PM Kim Barrett wrote: > > On 4/22/25 8:46 AM, Julian Waters wrote: > > Hi all, > > > > Zero currently cannot compile on Windows, and to my knowledge, has > > never been able to compile on Windows. [...] > > > > I started work again recently to get Zero working with VC. [...] > > > > I'd like to float the idea of supporting Windows/Zero properly. > > [...] > > > > > > Thoughts? > > Quoting from https://openjdk.org/jeps/479 "Remove the Windows 32-bit x86 Port": > > "Windows 10, the last Windows operating system to support 32-bit operation, > will reach End of Life in October 2025." > > That suggests the community of 32-bit Windows users is very small, and will > only get smaller. The delivery of that JEP and the fact that zero has never > worked on Windows at all suggests the community of 32-bit Windows users with > new development needs is essentially nonexistent. > > So providing a way to run new versions of Java on 32-bit Windows doesn't seem > to me to be at all motivating. > > A port needs an active community to be considered alive and supported. I > don't see that here. All I see is potential costs, with no demonstrated gain. > > I don't think "Ideally, Zero should run on any platform, so it not running on > Windows would be surprising" is a good reason. I think the purpose of zero is > to provide a stepping stone toward support for a new platform where none > currently exists. That's not what we have here. > > The addition of zero-specific conditionalization in shared code in this work > seems quite suspicious, given that zero currently works for non-Windows. > > Sorry to be raining on your parade, but this doesn't seem useful to me. > From vladimir.x.ivanov at oracle.com Fri Apr 25 18:42:07 2025 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 25 Apr 2025 11:42:07 -0700 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: <087081f4-e96b-4645-968d-3d7541f2239e@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 4/22/25 05:58, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. From mark.reinhold at oracle.com Fri Apr 25 19:41:10 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Fri, 25 Apr 2025 19:41:10 +0000 Subject: Where to put supplementary docs? In-Reply-To: References: Message-ID: <20250425154110.11559658@eggemoggin.niobe.net> 2025/4/24 11:26:50 -0400, Robbin Ehn : > Hi, I agree. > > I suggested co-located docs in some less public forums in the past. > > One major challenge with the other places (CR, JBS, PR, wiki), is that > they don't handle versioning. (naturally) This means the code can't > safely refer to, e.g., a wiki page, as that page may describe a newer > version. If a developer is working in JDK 11 or in the Loom project, > they need the relevant documentation for that specific fork/branch. > > JBS/PR also have the issue that they primarily describe the original > bug/patch. The code integrated can change significantly during the > PR's lifetime, and one may need to read many comments in the PR/JBS to > figure things out. > > Additionally, many developers 'grep' the code, which means co-located > documentation is very easy to find (and thus easier to keep up-to-date > or add new docs to). > > A concrete example: https://wiki.openjdk.org/display/HotSpot/Synchronization > If you are hunting a bug in JDK 11, this page may be of value. > If you want to know how locking works in JDK 25, you shouldn't be > reading this page. > > Co-locating the docs with the code helps with these issues. My initial internal reaction to Andrew?s proposal was, ?meh, yet another place to search for documents?? But Robbin makes a good point: If what we?re talking about here is documentation of JDK internals then that?s inherently version-specific. Keeping such documentation anywhere else just invites it to get stale and out of date, in addition to making it harder to find. Jesper makes some good points, too, in his survey of the alternatives, though I don?t agree with all of them. Some commentary: - JBS doesn?t support markup in non-JEP/CSR issues, and we?re unlikely to change that. This makes it difficult to maintain longer documents there. A nice side benefit of placing them in the repo is that we can use Markdown, and GitHub will render them. - JBS issues (and GitHub PRs) can be hard to discover. To take Andrew?s example of the old HotSpot subtype-checking algorithm, if you wanted to know more about that then how would you find it in JBS? Yet a quick search of `doc/ref/hotspot` would turn it up quickly. - Wikis are where information goes to die. Sorry. (Plus, the markup language is worse than horrid.) - Informational JEPs are under-used, but given that these documents are version-tied, informational JEPs are not a great solution. - The trouble with cr.openjdk.org, as Andrew pointed out, is that a document posted there today is not guaranteed to be there tomorrow, or next month, or next year. People shuffle their personal content there all the time. - I totally agree that all OpenJDK-related documentation should be maintained and published in OpenJDK infrastructure. If we do go ahead with Andrew?s proposal then it will be critical to crisply define what this directory for, lest it become a dumping ground for documents that really belong elsewhere, or mistaken for a collection of documents meant for non-contributors. ?Reference documentation for JDK internals? seems like a good start, which also suggests that `doc/internals` might be a better name than `doc/ref`. - Mark From magnus.ihse.bursie at oracle.com Mon Apr 28 10:33:20 2025 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 28 Apr 2025 12:33:20 +0200 Subject: Where to put supplementary docs? In-Reply-To: <20250425154110.11559658@eggemoggin.niobe.net> References: <20250425154110.11559658@eggemoggin.niobe.net> Message-ID: <71e7e0b1-8061-4d2e-8f6b-b07119c66861@oracle.com> On 2025-04-25 21:41, Mark Reinhold wrote: > My initial internal reaction to Andrew?s proposal was, ?meh, yet another > place to search for documents?? But Robbin makes a good point: If what > we?re talking about here is documentation of JDK internals then that?s > inherently version-specific. Keeping such documentation anywhere else > just invites it to get stale and out of date, in addition to making it > harder to find. > > If we do go ahead with Andrew?s proposal then it will be critical to > crisply define what this directory for, lest it become a dumping ground > for documents that really belong elsewhere, or mistaken for a collection > of documents meant for non-contributors. > > ?Reference documentation for JDK internals? seems like a good start, > which also suggests that `doc/internals` might be a better name than > `doc/ref`. I like "doc/internals". I think it captures well what we are discussing here. I don't think we need to overthink this. Is there anything stopping anyone from starting to use this straight away? Any kind of additional structures/guidelines etc can be added later on, if this turns out to be so well-used it gets overcrowded. Maybe someone can volunteer to scour other places for existing documentation that is still relevant, and add it to doc/internals, to get a good starting point. /Magnus -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaello.giulietti at oracle.com Mon Apr 28 10:43:39 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 28 Apr 2025 12:43:39 +0200 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes On 2025-04-22 14:58, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > > Marc is a member of the HotSpot Compiler Team at Oracle. Since February > 2025, he contributed 16 changes to the JDK project [2], mostly in the > area of IGVN optimizations for the C2 compiler. > > Votes are due by May 6, 2025, 13:00 UTC. > > Only current JDK Committers [3] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [4]. > > Best regards, > Tobias > > [1] https://openjdk.org/census#mchevalier > [2] https://github.com/search?q=author%3Amarc- > chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 > [3] https://openjdk.java.net/census > [4] https://openjdk.org/projects/#committer-vote From mark.reinhold at oracle.com Mon Apr 28 15:28:18 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 28 Apr 2025 15:28:18 +0000 Subject: Where to put supplementary docs? In-Reply-To: <71e7e0b1-8061-4d2e-8f6b-b07119c66861@oracle.com> References: <20250425154110.11559658@eggemoggin.niobe.net> <71e7e0b1-8061-4d2e-8f6b-b07119c66861@oracle.com> Message-ID: <20250428112816.970201690@eggemoggin.niobe.net> 2025/4/28 6:33:20 -0400, magnus.ihse.bursie at oracle.com: > ... > > I don't think we need to overthink this. Is there anything stopping > anyone from starting to use this straight away? Any kind of additional > structures/guidelines etc can be added later on, if this turns out to be > so well-used it gets overcrowded. Do we need to overthink this? No. But any proposal for a new convention for all of JDK development, if it is to succeed, needs at least a rough consensus behind it. I don?t, so far, see such a consensus. - Mark From jesper.wilhelmsson at oracle.com Mon Apr 28 16:19:09 2025 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 28 Apr 2025 16:19:09 +0000 Subject: Where to put supplementary docs? In-Reply-To: <20250428112816.970201690@eggemoggin.niobe.net> References: <20250425154110.11559658@eggemoggin.niobe.net> <71e7e0b1-8061-4d2e-8f6b-b07119c66861@oracle.com> <20250428112816.970201690@eggemoggin.niobe.net> Message-ID: <3851B993-E1A4-472B-85EC-634674803D51@oracle.com> On 28 Apr 2025, at 17:28, Mark Reinhold wrote: 2025/4/28 6:33:20 -0400, magnus.ihse.bursie at oracle.com: ... I don't think we need to overthink this. Is there anything stopping anyone from starting to use this straight away? Any kind of additional structures/guidelines etc can be added later on, if this turns out to be so well-used it gets overcrowded. Do we need to overthink this? No. But any proposal for a new convention for all of JDK development, if it is to succeed, needs at least a rough consensus behind it. I don?t, so far, see such a consensus. This discussion seems to have taken a turn towards a different type of documentation than what I interpreted the initial question was about. When I read "supporting documents to justify a change", that's what I replied to. I still think these would be best off attached to the JBS issue. I would not like to see various spreadsheet files with benchmark data or images with graphs etc committed to the source code. If we talk about descriptions of how the code is implemented, documentation for developers who need to understand subsystems in order to work on the code, then yes, I think it's totally reasonable to have that in markdown files in the source tree. At least in my mind these are two different types of documents. Sorry if that's just me :-) /Jesper -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Mon Apr 28 17:18:32 2025 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 28 Apr 2025 18:18:32 +0100 Subject: Windows/Zero In-Reply-To: <946aaf6f-9920-4305-a395-b9ef74f14b9e@oracle.com> References: <946aaf6f-9920-4305-a395-b9ef74f14b9e@oracle.com> Message-ID: On 10:59 Thu 24 Apr , Kim Barrett wrote: > On 4/22/25 8:46 AM, Julian Waters wrote: > > Hi all, > > > > Zero currently cannot compile on Windows, and to my knowledge, has > > never been able to compile on Windows. [...] > > I don't recall anyone showing interest in having it compile on Windows in the best part of twenty years that Zero has existed. As Thomas & Kim have said, it is primarily used for supporting new architectures which don't yet have a JIT. The emphasis is on the architecture side of the platform, not the operating system. The only architectures Windows currently supports are x86 and aarch64. x86 has had a JIT since OpenJDK's inception and the aarch64 port was developed for Linux first, from which point it made more sense to add Windows support to the existing JIT than for Zero. I have seen Zero used to build on plenty of architectures (ppc, s390, mips, alpha) on the Linux side. But, performance wise, it really only makes sense to do this when there is no other option and you need to ship a build of some form. Zero was first developed at Red Hat because we had a problem to solve: we needed to ship OpenJDK on all the architectures that used to ship with gcj (x86, ppc, s390) but, at the time, OpenJDK only had x86 and SPARC ports. Zero was a way to provide an OpenJDK build on PPC & s390 in RHEL, even if most end users eventually went for another third party JDK that did have a JIT. OpenJDK has since gained PPC and s390 JITs and this is why Zero does not get as much testing as it once did. It's still useful to maintain it for bootstrapping new ports, but the only place we regularly ship builds using Zero is to support s390 on OpenJDK 8, where it doesn't have a JIT. It looks like Debian builds on mips [0], so they may have more experience with Zero on the newer JDKs. It's not clear to me what your aim is here. If you want a way to keep OpenJDK working on Windows x86-32, then I would suggest it makes more sense to revert the JIT removal than try to make Zero work. It's likely to be a battle either way, given 32-bit support is being removed across the board, but maintaining a JIT would be a more satisfying end result. Unless performance has improved dramatically since I last tried, I can't see anyone wanting to use Zero day to day to run Java programs. If you're interested in Zero on Windows from an academic perspective, then it might make more sense to target the update releases where 32-bit support is still maintained (and especially 8u where Zero is also being regularly built by us). I had a look over your patch and it seems to be trying to solve three problems at once: building Zero on Windows, building on x86-32 and building on Windows with gcc. Building an update release with the supported Visual Studio compiler may well remove some of the issues that are not down to Zero at all. I find it especially worrying to see huge chunks of Zero code outside the Windows area deleted and some return values replaced with null pointers. > > I started work again recently to get Zero working with VC. [...] > > > > I'd like to float the idea of supporting Windows/Zero properly. > > [...] > > > > > > Thoughts? > > Quoting from https://openjdk.org/jeps/479 "Remove the Windows 32-bit x86 Port": > > "Windows 10, the last Windows operating system to support 32-bit operation, > will reach End of Life in October 2025." > > That suggests the community of 32-bit Windows users is very small, and will > only get smaller. The delivery of that JEP and the fact that zero has never > worked on Windows at all suggests the community of 32-bit Windows users with > new development needs is essentially nonexistent. > Yes. I'd add to this that anyone who wants to still run the JDK on x86-32 Windows is unlikely to be satisfied with Zero as a replacement for a JIT build. It also implies a further niche of those who really want 24 and later, because 8, 11, 17 & 21 are still being actively maintained and support Windows on x86-32. My first question would be why vendors don't seem to even be offering x86-32 Windows builds of 21 [1] if there is a demand for a JDK there. > So providing a way to run new versions of Java on 32-bit Windows doesn't seem > to me to be at all motivating. > > A port needs an active community to be considered alive and supported. I > don't see that here. All I see is potential costs, with no demonstrated gain. > I agree. We've had our fair share of ports over the years that have been supported at one time and then become broken. Shark springs to mind [1]. Keeping a port working is a full time job. > I don't think "Ideally, Zero should run on any platform, so it not running on > Windows would be surprising" is a good reason. I think the purpose of zero is > to provide a stepping stone toward support for a new platform where none > currently exists. That's not what we have here. Yes, 'platform' here should really be 'architecture'. The primary OS for Zero was always Linux, and if it has worked on other POSIX systems, that's been more a side effect of their similarity leading to a lot of shared code. The only practical case I see for Zero on Windows is if it is someone's chosen platform to develop a port to a new architecture, as Thomas mentioned. Given the need for Windows to also support said architecture, I would only expect such an effort to come from Microsoft. > > The addition of zero-specific conditionalization in shared code in this work > seems quite suspicious, given that zero currently works for non-Windows. > I find this curious as well. I expect some of it is related to building on Windows with gcc, but I would certainly need a very strong reason to change code we've been using for nearly two decades to return null pointers. > Sorry to be raining on your parade, but this doesn't seem useful to me. > Likewise. We might be able to be more positive if we knew what your end goal was :) [0] https://packages.debian.org/search?keywords=openjdk-21&searchon=names&suite=testing§ion=all [1] https://adoptium.net/en-GB/marketplace/?os=windows&arch=x86&version=21 [2] https://bugs.openjdk.org/browse/JDK-8171853 Thanks, -- Andrew :) Pronouns: he / him or they / them Principal Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 Please contact via e-mail, not proprietary chat networks -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From brent.christian at oracle.com Mon Apr 28 19:53:45 2025 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 28 Apr 2025 12:53:45 -0700 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: Yes On 4/22/25 5:58 AM, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. > From mark.reinhold at oracle.com Mon Apr 28 20:33:05 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Mon, 28 Apr 2025 20:33:05 +0000 Subject: New candidate JEP: 470: PEM Encodings of Cryptographic Objects (Preview) Message-ID: <20250428203304.731918132ED@eggemoggin.niobe.net> https://openjdk.org/jeps/470 Summary: Introduce an API for encoding objects that represent cryptographic keys, certificates, and certificate revocation lists into the widely-used Privacy-Enhanced Mail (PEM) transport format, and for decoding from that format back into objects. This is a preview API. - Mark From mark.reinhold at oracle.com Tue Apr 29 13:01:04 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 29 Apr 2025 13:01:04 +0000 Subject: JEP proposed to target JDK 25: 511: Module Import Declarations In-Reply-To: <20250421185105.011B1812414@eggemoggin.niobe.net> References: <20250421185105.011B1812414@eggemoggin.niobe.net> Message-ID: <20250429090103.581666952@eggemoggin.niobe.net> 2025/4/21 14:51:05 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 25: > > 511: Module Import Declarations > https://openjdk.org/jeps/511 > > Summary: Enhance the Java programming language with the ability to > succinctly import all of the packages exported by a module. This > simplifies the reuse of modular libraries, but does not require the > importing code to be in a module itself. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 20:00 UTC on Monday, 28 April, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 25. Hearing no objections, I?ve targeted this JEP to JDK 25. - Mark From mark.reinhold at oracle.com Tue Apr 29 13:01:07 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 29 Apr 2025 13:01:07 +0000 Subject: JEP proposed to target JDK 25: 512: Compact Source Files and Instance Main Methods In-Reply-To: <20250421201543.3196B81241F@eggemoggin.niobe.net> References: <20250421201543.3196B81241F@eggemoggin.niobe.net> Message-ID: <20250429090107.160917576@eggemoggin.niobe.net> 2025/4/21 16:15:46 -0400, mark.reinhold at oracle.com: > The following JEP is proposed to target JDK 25: > > 512: Compact Source Files and Instance Main Methods > https://openjdk.org/jeps/512 > > Summary: Evolve the Java programming language so that beginners can > write their first programs without needing to understand language > features designed for large programs. Far from using a separate > dialect of the language, beginners can write streamlined declarations > for single-class programs and then seamlessly expand their programs > to use more advanced features as their skills grow. Experienced > developers can likewise enjoy writing small programs succinctly, > without the need for constructs intended for programming in the large. > > Feedback on this proposal from JDK Project Committers and Reviewers [1] > is more than welcome, as are reasoned objections. If no such objections > are raised by 21:00 UTC on Monday, 28 April, or if they?re raised and > then satisfactorily answered, then per the JEP 2.0 process proposal [2] > I?ll target this JEP to JDK 25. Hearing no objections, I?ve targeted this JEP to JDK 25. - Mark From mark.reinhold at oracle.com Tue Apr 29 13:19:27 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 29 Apr 2025 13:19:27 +0000 Subject: Where to put supplementary docs? In-Reply-To: <3851B993-E1A4-472B-85EC-634674803D51@oracle.com> References: <20250425154110.11559658@eggemoggin.niobe.net> <71e7e0b1-8061-4d2e-8f6b-b07119c66861@oracle.com> <20250428112816.970201690@eggemoggin.niobe.net> <3851B993-E1A4-472B-85EC-634674803D51@oracle.com> Message-ID: <20250429091926.561491589@eggemoggin.niobe.net> 2025/4/28 12:19:09 -0400, jesper.wilhelmsson at oracle.com: > This discussion seems to have taken a turn towards a different type of > documentation than what I interpreted the initial question was > about. When I read "supporting documents to justify a change", that's > what I replied to. I still think these would be best off attached to > the JBS issue. I would not like to see various spreadsheet files with > benchmark data or images with graphs etc committed to the source code. I agree that change-specific benchmark data would be inappropriate; it ages too quickly. Put that in JBS or in the PR (where, at least, it will be rendered nicely). > If we talk about descriptions of how the code is implemented, > documentation for developers who need to understand subsystems in > order to work on the code, then yes, I think it's totally reasonable > to have that in markdown files in the source tree. > > At least in my mind these are two different types of documents. Sorry > if that's just me :-) Nope. It?s at least me and you. Andrew -- Your initial message talked about ?supporting documents to justify a change,? which is broad and of concern. The example you gave, of the HotSpot subtype-checking algorithm, might have been created in support of a specific change but it clearly falls into the narrower category of ?reference documentation for JDK internals.? Are you content with using that narrower category for this new documentation directory? - Mark From mark.reinhold at oracle.com Tue Apr 29 20:41:35 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Tue, 29 Apr 2025 20:41:35 +0000 Subject: JEP proposed to target JDK 25: 513: Flexible Constructor Bodies Message-ID: <20250429204134.C4B1581337D@eggemoggin.niobe.net> The following JEP is proposed to target JDK 25: 513: Flexible Constructor Bodies https://openjdk.org/jeps/513 Summary: In the body of a constructor, allow statements to appear before an explicit constructor invocation, i.e., super(...) or this(...). Such statements cannot reference the object under construction, but they can initialize its fields and perform other safe computations. This change allows many constructors to be expressed more naturally. It also allows fields to be initialized before they become visible to other code in the class, such as methods called from a superclass constructor, thereby improving safety. Feedback on this proposal from JDK Project Committers and Reviewers [1] is more than welcome, as are reasoned objections. If no such objections are raised by 21:00 UTC on Tuesday, 6 May, or if they?re raised and then satisfactorily answered, then per the JEP 2.0 process proposal [2] I?ll target this JEP to JDK 25. - Mark [1] https://openjdk.org/census#jdk [2] https://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html From mark.reinhold at oracle.com Wed Apr 30 13:08:47 2025 From: mark.reinhold at oracle.com (Mark Reinhold) Date: Wed, 30 Apr 2025 13:08:47 +0000 Subject: New candidate JEP: 514: Ahead-of-Time Command-Line Ergonomics Message-ID: <20250430130846.8B46C81372B@eggemoggin.niobe.net> https://openjdk.org/jeps/514 Summary: Make it easier to create ahead-of-time caches, which accelerate the startup of Java applications, by simplifying the commands required for common use cases. - Mark From daniel.fuchs at oracle.com Wed Apr 30 13:57:16 2025 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 30 Apr 2025 14:57:16 +0100 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes best regards, -- daniel On 22/04/2025 13:58, Tobias Hartmann wrote: > I hereby nominate Marc Chevalier [1] to JDK Committer. From martin.doerr at sap.com Wed Apr 30 13:58:25 2025 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Apr 2025 13:58:25 +0000 Subject: CFV: New JDK Committer: Marc Chevalier In-Reply-To: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> References: <1bb08bc8-852c-4d38-a712-fece709bd5ad@oracle.com> Message-ID: Vote: yes Best regards, Martin Von: jdk-dev im Auftrag von Tobias Hartmann Datum: Dienstag, 22. April 2025 um 15:03 An: jdk-dev at openjdk.org Betreff: CFV: New JDK Committer: Marc Chevalier I hereby nominate Marc Chevalier [1] to JDK Committer. Marc is a member of the HotSpot Compiler Team at Oracle. Since February 2025, he contributed 16 changes to the JDK project [2], mostly in the area of IGVN optimizations for the C2 compiler. Votes are due by May 6, 2025, 13:00 UTC. Only current JDK Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Best regards, Tobias [1] https://openjdk.org/census#mchevalier [2] https://github.com/search?q=author%3Amarc-chevalier+repo%3Aopenjdk%2Fjdk&type=commits&p=1 [3] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fcensus&data=05%7C02%7Cmartin.doerr%40sap.com%7C80ee73fd80fe4b7399a408dd819e0b2a%7C42f7676cf455423c82f6dc2d99791af7%7C0%7C0%7C638809238006890865%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=jFK3dZj169TrCCuiKOO63l%2BjL3upfVyN3H%2F7e%2B98%2Beo%3D&reserved=0 [4] https://openjdk.org/projects/#committer-vote -------------- next part -------------- An HTML attachment was scrubbed... URL: From karan03945 at gmail.com Wed Apr 30 23:05:16 2025 From: karan03945 at gmail.com (Karan Sharma) Date: Thu, 1 May 2025 04:35:16 +0530 Subject: Clarification Regarding Java Program Entry Point and Static Block Execution Message-ID: Dear Oracle Java Documentation Team, I hope this message finds you well. I have been studying Java and came across the commonly stated guideline that the main(String[] args) method serves as the entry point for all Java applications. However, during experimentation and further reading, I observed that static blocks in a Java class are executed before the main() method, and in some cases, it is even possible to run logic using only static blocks without defining a main() method (such as in earlier versions of Java or with specific class loaders). This leads me to a conceptual query: If static blocks are executed prior to main(), and code within them can run independently, is it still fully accurate to say that the main method is the only entry point of a Java program? I understand that main() serves as the starting point for execution in standard standalone Java applications. However, since there are cases (e.g., static initialization, frameworks, reflection) where control can begin before or without main(), I believe it may be valuable to clarify this nuance in the official documentation ? especially for learners trying to deeply understand Java's execution model. I would greatly appreciate any insights or thoughts from your side on this topic. Thank you for maintaining such comprehensive resources for Java developers worldwide. Warm regards, Karan Kumar karan03945 at gmail.com B.Tech Student | Java Enthusiast -------------- next part -------------- An HTML attachment was scrubbed... URL: From chen.l.liang at oracle.com Wed Apr 30 23:55:14 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Wed, 30 Apr 2025 23:55:14 +0000 Subject: Clarification Regarding Java Program Entry Point and Static Block Execution In-Reply-To: References: Message-ID: Hello Karan, I believe the existing documentation and specification is correct in this aspect. In Java Language Specification, Section 12.1.2 [1], and Java Virtual Machine Specification, Section 5.2 [2], both state that the initial class is initialized before main is invoked. JLS: > After Test is loaded, it must be initialized before main can be invoked. JVMS: > The Java Virtual Machine then links the initial class or interface, initializes it, and invokes the public static method void main(String[]) In particular, JLS 12.1.3 describes the execution of initializers for the main class, including static initializers. JLS 12.1.4 then describes the execution of the main method, which happens after the execution of the class initializer. It might be the "guideline" that you found somewhere was unofficial and misrepresented the Java specifications. P.S. You are mailing to the OpenJDK organization instead of Oracle. This list jdk-dev is for development information relevant to all parts of the JDK project in the OpenJDK question. If you have any question, please reply to me privately without cc'ing to this list. Regards, Chen [1] https://docs.oracle.com/javase/specs/jls/se24/html/jls-12.html#jls-12.1.2 [2] https://docs.oracle.com/javase/specs/jvms/se24/html/jvms-5.html#jvms-5.2 ________________________________ From: jdk-dev on behalf of Karan Sharma Sent: Wednesday, April 30, 2025 6:05 PM To: jdk-dev at openjdk.org Subject: Clarification Regarding Java Program Entry Point and Static Block Execution Dear Oracle Java Documentation Team, I hope this message finds you well. I have been studying Java and came across the commonly stated guideline that the main(String[] args) method serves as the entry point for all Java applications. However, during experimentation and further reading, I observed that static blocks in a Java class are executed before the main() method, and in some cases, it is even possible to run logic using only static blocks without defining a main() method (such as in earlier versions of Java or with specific class loaders). This leads me to a conceptual query: If static blocks are executed prior to main(), and code within them can run independently, is it still fully accurate to say that the main method is the only entry point of a Java program? I understand that main() serves as the starting point for execution in standard standalone Java applications. However, since there are cases (e.g., static initialization, frameworks, reflection) where control can begin before or without main(), I believe it may be valuable to clarify this nuance in the official documentation ? especially for learners trying to deeply understand Java's execution model. I would greatly appreciate any insights or thoughts from your side on this topic. Thank you for maintaining such comprehensive resources for Java developers worldwide. Warm regards, Karan Kumar karan03945 at gmail.com B.Tech Student | Java Enthusiast -------------- next part -------------- An HTML attachment was scrubbed... URL: