From duke at openjdk.org  Mon Jul  1 23:29:53 2024
From: duke at openjdk.org (duke)
Date: Mon, 1 Jul 2024 23:29:53 GMT
Subject: git: openjdk/leyden: premain: 4 new changesets
Message-ID: <27d7e83c-3d78-4ed3-a5ee-b1ad7da31fff@openjdk.org>

Changeset: 2bb2fbc4
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-06-28 16:05:57 +0000
URL:       https://git.openjdk.org/leyden/commit/2bb2fbc4d07d1e39c7de43489145da2521c066f6

Always set TD::_holder.

! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/oops/trainingData.hpp

Changeset: 5ebf8d6c
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-07-01 10:20:59 +0000
URL:       https://git.openjdk.org/leyden/commit/5ebf8d6c88c54c03cfba58564ffbc663fb5118c5

Stabilize find() behavior during snapshot

! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/oops/trainingData.hpp

Changeset: 3726f1df
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-07-01 14:45:12 +0000
URL:       https://git.openjdk.org/leyden/commit/3726f1dfbecf0ba7a68371f3402f08c3aee5d5a0

Cleanup

! src/hotspot/share/compiler/compiler_globals.hpp
! src/hotspot/share/oops/trainingData.hpp

Changeset: 159c6693
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-07-01 16:28:11 +0000
URL:       https://git.openjdk.org/leyden/commit/159c6693db66bef83abf6fdcece7bcacb0f68689

Simplify KTD constructor

! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/oops/trainingData.hpp


From duke at openjdk.org  Tue Jul  2 04:22:29 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jul 2024 04:22:29 GMT
Subject: git: openjdk/leyden: premain: 4 new changesets
Message-ID: <6ea936f6-1437-4397-a729-21120e491832@openjdk.org>

Changeset: dc69d066
Author:    Vladimir Kozlov <kvn at openjdk.org>
Committer: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-06-25 16:04:03 +0000
URL:       https://git.openjdk.org/leyden/commit/dc69d066e922b7c18d8329ea3dd0c1a16abda640

8334421: assert(!oldbox->is_unbalanced()) failed: this should not be called for unbalanced region

Reviewed-by: vlivanov, thartmann

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/locknode.hpp
! src/hotspot/share/opto/macro.cpp
+ test/hotspot/jtreg/compiler/locks/TestCoarsenedAndNotEscapedLocksElimination.java

Changeset: 5b27856a
Author:    Vladimir Kozlov <kvn at openjdk.org>
Committer: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-06-27 16:06:35 +0000
URL:       https://git.openjdk.org/leyden/commit/5b27856a66d828105a69e0ca6551698fd1ead57e

8335220: C2: Missing check for Opaque4 node in EscapeAnalysis

Reviewed-by: chagedorn, cslucas

! src/hotspot/share/opto/escape.cpp

Changeset: c27385e3
Author:    Vladimir Kozlov <kvn at openjdk.org>
Committer: Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-06-28 19:36:00 +0000
URL:       https://git.openjdk.org/leyden/commit/c27385e3a9a150ec9650282d39275c4b532418c8

8335221: Some C2 intrinsics incorrectly assume that type argument is compile-time constant

Reviewed-by: roland, chagedorn

! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp

Changeset: 517e4b23
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-01 18:55:49 +0000
URL:       https://git.openjdk.org/leyden/commit/517e4b23d110b1fdb909756c8f8a7e8c10f121a7

Merge branch 'premain-ea' of https://github.com/openjdk/leyden into premain



From ioi.lam at oracle.com  Tue Jul  2 05:27:42 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Mon, 1 Jul 2024 22:27:42 -0700
Subject: Crash when dumping cds map file
In-Reply-To: <d7dc8954-8f10-475f-bb2a-7d996efe20cc@oracle.com>
References: <CAKt0pyR698qrOewyzmJmZHrfuzFfu=BwUMWtdO1XHKtHOPwzYw@mail.gmail.com>
 <d7dc8954-8f10-475f-bb2a-7d996efe20cc@oracle.com>
Message-ID: <e4a82923-bd03-4c34-801c-caaae278f540@oracle.com>

I filed a bug for this issue and pushed a fixed to the "premain" branch

https://bugs.openjdk.org/browse/JDK-8335492 "Some hidden classes are not 
archived for ArchiveInvokeDynamic"

Thanks

- Ioi


On 6/28/24 7:21 PM, ioi.lam at oracle.com wrote:
>
> FYI
>
> I am working on a related problem where some hidden classes are 
> incorrectly excluded. They have names that look like:
>
> io/vertx/core/impl/VertxImpl$$InjectedInvoker+0x8000000c6
> java/util/logging/Level$KnownLevel$$InjectedInvoker+0x800000028
>
> or
>
> org/openjdk/bench/java/lang/StringConcat$$StringConcat+0x800000022
>
> The root cause is different than what Ashutosh reported -- we have 
> resolved CP entries that transitively point to Method* of hidden 
> classes. So far this problem is not reproducible with existing test 
> cases in the premain branch. I am testing a fix now.
>
> Thanks
>
> - Ioi
>
>
> On 6/27/24 8:14 PM, Ashutosh Mehra wrote:
>> I encountered a crash when dumping the cds map with 1-step workflow.
>> The crash happens?in the forked JVM during the assembly phase of the 
>> training run.
>> To recreate the crash, execute the training run 
>> with?-Xlog:cds+map=trace:file=cds.map:none:filesize=0 option.
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> # ?SIGSEGV (0xb) at pc=0x00007f4e8a209cb6, pid=152509, tid=152510
>> #
>> # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build 
>> 23-internal-adhoc.asmehra.leyden)
>> # Java VM: OpenJDK 64-Bit Server VM (slowdebug 
>> 23-internal-adhoc.asmehra.leyden, mixed mode, sharing, tiered, 
>> compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V ?[libjvm.so+0x409cb6] ?Klass::is_instance_klass() const+0x10
>> #
>> # Core dump will be written. Default location: 
>> /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/core.152509
>> #
>> # An error report file with more information is saved as:
>> # 
>> /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/hs_err_pid152509.log
>> #
>> # If you would like to submit a bug report, please visit:
>> # https://bugreport.java.com/bugreport/crash.jsp
>> #
>> [75.250s][error ?][cds] Child process finished; status = 134
>>
>> Backtrace for the crashing thread:
>>
>> #11 0x00007f4e8a209cb6 in Klass::is_instance_klass (this=0x0) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.hpp:683
>> #12 0x00007f4e8afa8894 in Klass::external_name (this=0x0) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.cpp:905
>> #13 0x00007f4e8b126447 in Method::print_external_name 
>> (os=0x7f4e89dfd130, klass=0x0, method_name=0x8011e8588, 
>> signature=0x8011ab858) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:228
>> #14 0x00007f4e8b1263b6 in Method::external_name (klass=0x0, 
>> method_name=0x8011e8588, signature=0x8011ab858) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:222
>> #15 0x00007f4e8b1262e1 in Method::external_name (this=0x800fd1920) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:213
>> #16 0x00007f4e8a492b0d in ArchiveBuilder::CDSMapLogger::log_method 
>> (m=0x800fd1920, runtime_dest=0x801039cd8 "", type_name=0x7f4e8b7d40fc 
>> "Method", bytes=128, current=0x7f4e8401d900)
>> ? ? at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1194
>> #17 0x00007f4e8a492d66 in 
>> ArchiveBuilder::CDSMapLogger::log_metaspace_objects 
>> (region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1228
>> #18 0x00007f4e8a492a2b in 
>> ArchiveBuilder::CDSMapLogger::log_metaspace_region 
>> (name=0x7f4e8b7d8af0 "rw region", region=0x7f4e89dfe740, 
>> src_objs=0x7f4e89dfe860) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1182
>> #19 0x00007f4e8a4940f4 in ArchiveBuilder::CDSMapLogger::log 
>> (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, 
>> heap_info=0x7f4e89dfd4f0, bitmap=0x7f4e857bf850 
>> "\t\222\004I\222$\t\210\210\210\001\b\200", bitmap_size_in_bytes=655824)
>> ? ? at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1502
>> #20 0x00007f4e8a48f2a5 in ArchiveBuilder::write_archive 
>> (this=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, 
>> heap_info=0x7f4e89dfd4f0) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1560
>> #21 0x00007f4e8b11d249 in MetaspaceShared::write_static_archive 
>> (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0, 
>> heap_info=0x7f4e89dfd4f0) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:988
>> #22 0x00007f4e8b11d1ac in MetaspaceShared::preload_and_dump_impl 
>> (builder=..., __the_thread__=0x7f4e8401d900) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:976
>> #23 0x00007f4e8b11c5fd in MetaspaceShared::preload_and_dump () at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:767
>> #24 0x00007f4e8b53bca2 in Threads::create_vm (args=0x7f4e89dfedd0, 
>> canTryAgain=0x7f4e89dfecd3) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/threads.cpp:900
>> #25 0x00007f4e8ada2821 in JNI_CreateJavaVM_inner (vm=0x7f4e89dfee20, 
>> penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3581
>> #26 0x00007f4e8ada2c81 in JNI_CreateJavaVM (vm=0x7f4e89dfee20, 
>> penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3672
>> #27 0x00007f4e8ce0f84f in InitializeJVM (pvm=0x7f4e89dfee20, 
>> penv=0x7f4e89dfee28, ifn=0x7f4e89dfee70) at 
>> /home/asmehra/data/ashu-mehra/leyden/src/java.base/share/native/libjli/java.c:1550
>>
>> Checking up the CDS map generated for the cds preimage shows some 
>> methods for which their InstanceKlass is null.
>> This results in the?crash seen above when such methods are printed as 
>> part of the CDS map file during the assembly phase.
>>
>> These methods are of the form:
>>
>> java.lang.Object 
>> java.lang.invoke.LambdaForm$MH/0x800000090.invoke(java.lang.Object, 
>> java.lang.Object)
>>
>> Interestingly -Xlog:cds=info shows such classes are skipped when 
>> generating the preimage as they are hidden classes:
>>
>> Skipping java/lang/invoke/LambdaForm$MH+0x800000090: Hidden class
>>
>> In the CDS map file for the preimage I also noticed that such methods 
>> are only referenced through MethodTrainingData -> _final_profile -> 
>> _method.
>> So it looks like although we excluded such classes from the CDS 
>> archive, we don't exclude their training data.
>> There is code for cleaning up the training data [0] , but it doesn't 
>> remove the training data for classes that have been excluded, unless 
>> I misunderstood the code.
>> Not sure if it is intentional or a bug.
>> If we do need to keep the training data for such methods, then we 
>> would need to handle the case of null InstanceKlass in 
>> the?CDSMapLogger to avoid crashing.
>>
>> [0] 
>> https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573
>>
>> Thanks,
>> - Ashutosh Mehra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240701/2dea9df3/attachment.htm>

From duke at openjdk.org  Tue Jul  2 05:28:51 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jul 2024 05:28:51 GMT
Subject: git: openjdk/leyden: premain: 8335492: Some hidden classes are not
 archived for ArchiveInvokeDynamic
Message-ID: <9e4866c3-336c-4f9b-8acf-83e12ccedbcb@openjdk.org>

Changeset: 098c309d
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-01 18:52:38 +0000
URL:       https://git.openjdk.org/leyden/commit/098c309da5eaa3d9727b5207fe4ad74e9eed7b20

8335492: Some hidden classes are not archived for ArchiveInvokeDynamic

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/classPreloader.cpp
! src/hotspot/share/cds/dumpTimeClassInfo.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/oops/constantPool.cpp
! src/hotspot/share/oops/constantPool.hpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/cpCache.hpp
+ test/hotspot/jtreg/runtime/cds/appcds/indy/StringConcatStress2.java


From duke at openjdk.org  Tue Jul  2 22:13:41 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jul 2024 22:13:41 GMT
Subject: git: openjdk/leyden: premain: 8309634: Resolve CONSTANT_MethodRef at
 CDS dump time
Message-ID: <34656c85-a8bb-482b-b684-be37427e35a5@openjdk.org>

Changeset: bd601c50
Author:    Ioi Lam <iklam at openjdk.org>
Committer: iklam <ilam3388 at gmail.com>
Date:      2024-07-02 10:14:51 +0000
URL:       https://git.openjdk.org/leyden/commit/bd601c509a001217ff25ba308458b52e3ad3d612

8309634: Resolve CONSTANT_MethodRef at CDS dump time

Reviewed-by: matsaave, ccheung

! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/resolvedMethodEntry.hpp
! test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java


From duke at openjdk.org  Tue Jul  2 22:26:08 2024
From: duke at openjdk.org (duke)
Date: Tue, 2 Jul 2024 22:26:08 GMT
Subject: git: openjdk/leyden: premain: fixed windows build
Message-ID: <33dd7e75-2b5d-4ffb-b430-9552c8fc150b@openjdk.org>

Changeset: d2446866
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-02 15:25:22 +0000
URL:       https://git.openjdk.org/leyden/commit/d24468666c5aeb653caaf802c1af7ea4f487ca19

fixed windows build

! src/hotspot/share/cds/heapShared.hpp


From john.r.rose at oracle.com  Thu Jul  4 05:37:46 2024
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 03 Jul 2024 22:37:46 -0700
Subject: Draft JEP 8315737: AOT Linked Classes
Message-ID: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>

Dear colleagues,

Having recently delivered a Leyden EA Build of our ?premain? work, the Leyden team is very happy to post our first JEP for public review.

https://openjdk.org/jeps/8315737

Covering a subset of the functionality in the EA Build, this JEP describes our plans for introducing, to the JDK, the first course of startup and warmup enhancements which have been ?cooking? since last February.

Because CDS is a somewhat obscure technology, and because startup and warmup are very tricky (even refractory) problems in our ecosystem, we are striving to make the JEP as clear and informative as possible.  It covers the nature of the problem, and the past solutions in HotSpot, as well as the present proposal.  (Although there are many excellent and inspiring proposals for this problem beyond HotSpot, this JEP does not attempt to address them; that is for another paper.)  We hope you find it an interesting and useful mix of ?high level? and ?nitty gritty? details.

Though the actual proposal (the Description) section may seem surprisingly simple, the implications are pervasive and subtle.  As the JEP explains, the proposed changes will be felt all the more in the AOT technologies built on top, as can be seen in our EA Build.

The Non-Goals section gives guidance about where we expect to go after this JEP.
So if there seems to be a missing piece in this JEP, please look for it first among the non-goals!  We are working on more JEPs to come after this one.  Let?s get this one sorted so we can do more.

Like the EA Build, this work has not been possible without the participation of the Java community.  Special thanks to our Red Hat and Spring colleagues, and to everyone who is now sampling that EA Build.  Also, special thanks to our very demanding early reviewers, notably Alex Buckley, Brian Goetz, my co-authors Dan and Ioi, and the other members of the premain team.

Your comments on the JEP will surely improve it as well.

Best wishes,

? John Rose

From headius at headius.com  Thu Jul  4 20:06:03 2024
From: headius at headius.com (Charles Oliver Nutter)
Date: Thu, 4 Jul 2024 15:06:03 -0500
Subject: Hello from JRuby and here's another crash
Message-ID: <CAE-f1xSYcJudwYQUSZQxzU2nvqXnUSHLgQ69STYGMwJjsUKcsQ@mail.gmail.com>

Hello friends! Long time lurker, first time poster.

Like others I was excited to hear that the first EA of Leyden had dropped.
Sadly, I have another crash to report.

I see there are two other crashes reported, but mine appears different
(ClassPrelinker::is_indy_resolution_deterministic):

https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24

Perhaps unsurprisingly, the additional flags provided by Vladimir
Kozlov (-XX:+UnlockDiagnosticVMOptions
-XX:-ReduceAllocationMerges) did not appear to change the result.

This is with JRuby's minimally invokedynamic-based mode, which has given us
the shortest startup time in the past (second only to disabling tiers 2-4
and staying in C1).

I am on MacOS AArch64 Sonoma 14.5, testing against JRuby master, but
reproduction should be as easy as downloading the JRuby binary tarball,
unpacking, and running bin/jruby with the command line above.

https://www.jruby.org/download

I am eager to work with Leyden folks to investigate issues, and I am
planning to be at JVMLS this year to discuss collaborating more!

- Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240704/327e80ce/attachment.htm>

From john.r.rose at oracle.com  Thu Jul  4 21:48:40 2024
From: john.r.rose at oracle.com (John Rose)
Date: Thu, 04 Jul 2024 14:48:40 -0700
Subject: Hello from JRuby and here's another crash
In-Reply-To: <CAE-f1xSYcJudwYQUSZQxzU2nvqXnUSHLgQ69STYGMwJjsUKcsQ@mail.gmail.com>
References: <CAE-f1xSYcJudwYQUSZQxzU2nvqXnUSHLgQ69STYGMwJjsUKcsQ@mail.gmail.com>
Message-ID: <DA0F1301-FA4B-450E-AB38-124AAD1D3E06@oracle.com>

Great to hear from you, my old friend, and thanks for kicking the tires. 
  Sorry one of them blew out on you.  We?ll look at it with interest.

For the first time ever, I am unable to attend JVMLS, so I?m sorry I 
will miss seeing you there.

It is possible that our indy filters are set wrong; our optimizations 
work for indy BSMs defined by java.base, but perhaps not for yours.

On 4 Jul 2024, at 13:06, Charles Oliver Nutter wrote:

> Hello friends! Long time lurker, first time poster.
>
> Like others I was excited to hear that the first EA of Leyden had 
> dropped.
> Sadly, I have another crash to report.
>
> I see there are two other crashes reported, but mine appears different
> (ClassPrelinker::is_indy_resolution_deterministic):
>
> https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24
>
> Perhaps unsurprisingly, the additional flags provided by Vladimir
> Kozlov (-XX:+UnlockDiagnosticVMOptions
> -XX:-ReduceAllocationMerges) did not appear to change the result.
>
> This is with JRuby's minimally invokedynamic-based mode, which has 
> given us
> the shortest startup time in the past (second only to disabling tiers 
> 2-4
> and staying in C1).
>
> I am on MacOS AArch64 Sonoma 14.5, testing against JRuby master, but
> reproduction should be as easy as downloading the JRuby binary 
> tarball,
> unpacking, and running bin/jruby with the command line above.
>
> https://www.jruby.org/download
>
> I am eager to work with Leyden folks to investigate issues, and I am
> planning to be at JVMLS this year to discuss collaborating more!
>
> - Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240704/0df4cef8/attachment.htm>

From ioi.lam at oracle.com  Fri Jul  5 04:49:57 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Thu, 4 Jul 2024 21:49:57 -0700
Subject: Hello from JRuby and here's another crash
In-Reply-To: <CAE-f1xSYcJudwYQUSZQxzU2nvqXnUSHLgQ69STYGMwJjsUKcsQ@mail.gmail.com>
References: <CAE-f1xSYcJudwYQUSZQxzU2nvqXnUSHLgQ69STYGMwJjsUKcsQ@mail.gmail.com>
Message-ID: <9e008170-7348-410b-9ecb-753101367181@oracle.com>

Hi Charlie,

Thanks for the bug report.

It turns out some Leyden optimizations can't handle the module options 
specified by jruby, such as these:

 ??? --add-opens=java.base/java.nio.channels=org.jruby.dist
 ??? --module-path=/xxxx/jruby-9.4.8.0/lib/jruby.jar

I filed https://bugs.openjdk.org/browse/JDK-8335735

I'll work on a proper fix. Meanwhile, I have a work-around in this branch

https://github.com/iklam/jdk/tree/work-around-8335735-jruby-crash-due-to-lack-of-module-support

If you build a JDK from this source branch, you can see the following 
improvements:

# [1] No optimizations
$ time env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
 ??? -e '10.times { org.jruby.Ruby.newInstance }'
real?? 0m3.215s
user?? 0m14.868s
sys??? 0m0.373s


# [2] Leyden
$ time env JAVA_HOME=$TBP0 ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
 ??? -J-XX:CacheDataStore=jruby.cds \
 ??? -e '10.times { org.jruby.Ruby.newInstance }'
real?? 0m1.880s
user?? 0m9.001s
sys??? 0m0.268s


# [3] Compare with CDS in the JDK mainline
$ env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
 ???? -J-XX:DumpLoadedClassList=jruby.classlist \
 ???? -e '10.times { org.jruby.Ruby.newInstance }'
$ $MYJAVA/bin/java -Xshare:dump \
--module-path=/home/iklam/Downloads/ruby/jruby-9.4.8.0/lib/jruby.jar \
 ??? -XX:SharedClassListFile=jruby.classlist \
 ??? -XX:SharedArchiveFile=jruby.jsa -Xlog:cds
$ time env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
 ??? -J-XX:SharedArchiveFile=jruby.jsa \
 ??? -e '10.times { org.jruby.Ruby.newInstance }'
real?? 0m2.628s
user?? 0m13.007s
sys??? 0m0.428s

Please try it out and let us know if you run into other problems.

Thanks

- Ioi


On 7/4/24 1:06 PM, Charles Oliver Nutter wrote:
> Hello friends! Long time lurker, first time poster.
>
> Like others I was excited to hear that the first EA of Leyden had 
> dropped. Sadly, I have another crash to report.
>
> I see there are two other crashes reported, but mine appears different 
> (ClassPrelinker::is_indy_resolution_deterministic):
>
> https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24
>
> Perhaps unsurprisingly, the additional flags provided by Vladimir 
> Kozlov (-XX:+UnlockDiagnosticVMOptions -XX:-ReduceAllocationMerges) 
> did not appear to change the result.
>
> This is with JRuby's minimally invokedynamic-based mode, which has 
> given us the shortest startup time in the past (second only to 
> disabling tiers 2-4 and staying in C1).
>
> I am on MacOS AArch64 Sonoma 14.5, testing against JRuby master, but 
> reproduction should be as easy as downloading the JRuby binary 
> tarball, unpacking, and running bin/jruby with the command line above.
>
> https://www.jruby.org/download
>
> I am eager to work with Leyden folks to investigate issues, and I am 
> planning to be at JVMLS this year to discuss collaborating more!
>
> - Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240704/9c54a64c/attachment.htm>

From igor.veresov at oracle.com  Sat Jul  6 06:02:27 2024
From: igor.veresov at oracle.com (Igor Veresov)
Date: Sat, 6 Jul 2024 06:02:27 +0000
Subject: Crash when dumping cds map file
In-Reply-To: <03cbee2c-cd73-4dce-bb1e-7b8a0c4d7688@oracle.com>
References: <CAKt0pyR698qrOewyzmJmZHrfuzFfu=BwUMWtdO1XHKtHOPwzYw@mail.gmail.com>
 <ea6a93c6-dec9-4c53-9445-2c2aea8f5aec@oracle.com>
 <CAKt0pyQuRCX0GgA1qennunmHrztvznzF6LLGg0FF1vad46T3qg@mail.gmail.com>
 <03cbee2c-cd73-4dce-bb1e-7b8a0c4d7688@oracle.com>
Message-ID: <7C2BD497-0FAC-4196-B24C-F2D12B76ED94@oracle.com>

Yes, with the changes I?m working on there will be no symbolic refs, at least for now. We can re-add them later if necessary. 
For now if a quick fix is necessary we can zero these fields in MethodTrainingData::cleanup() at the same place we currently do ?_holder = nullptr?.

igor

> On Jun 28, 2024, at 4:19?PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> Probably, it's time to reconsider current behavior.
> 
> Igor is refactoring TrainingData to get rid of symbolic lookups. In such case, there's no reason to keep stale training data around and it's better to simply prune it.
> 
> Igor, what's your take on it?
> 
> Best regards,
> Vladimir Ivanov
> 
> On 6/28/24 15:54, Ashutosh Mehra wrote:
>>    What's the exact reason of the crash? Is it due to dereferencing invalid
>>    metadata pointer or simply encountering a nullptr?
>> It's nullptr. The klass pointer of the method is null.
>>    *TrainingData::cleanup() was intended to clear stale metadata pointers,
>>    but keep the training data around linked in symbolic form (holder ==
>>    null).
>> Okay, so if we do want to keep the training data but just prune the stale pointers,
>> then just setting the _holder to null is not enough, because the method belonging
>> to an excluded class can be reached through MethodTrainingData::_final_profile->method() or
>> MethodTrainingData::_final_counters->method().
>> So probably MethodTrainingData::cleanup() should be clearing the _method field in
>> MethodCounters and MethodData as well, and link them back in MethodTrainingData::refresh_from(),
>> just like it is done for MethodTrainingData.
>> Does that make sense?
>> Thanks,
>> - Ashutosh Mehra
>> On Fri, Jun 28, 2024 at 5:33?PM Vladimir Ivanov <vladimir.x.ivanov at oracle.com <mailto:vladimir.x.ivanov at oracle.com>> wrote:
>>    What's the exact reason of the crash? Is it due to dereferencing
>>    invalid
>>    metadata pointer or simply encountering a nullptr?
>>    *TrainingData::cleanup() was intended to clear stale metadata pointers,
>>    but keep the training data around linked in symbolic form (holder ==
>>    null).
>>    Best regards,
>>    Vladimir Ivanov
>>    On 6/27/24 20:14, Ashutosh Mehra wrote:
>>     > I encountered a crash when dumping the cds map with 1-step workflow.
>>     > The crash happens in the forked JVM during the assembly phase of the
>>     > training run.
>>     > To recreate the crash, execute the training run with
>>     > -Xlog:cds+map=trace:file=cds.map:none:filesize=0 option.
>>     >
>>     > #
>>     > # A fatal error has been detected by the Java Runtime Environment:
>>     > #
>>     > #  SIGSEGV (0xb) at pc=0x00007f4e8a209cb6, pid=152509, tid=152510
>>     > #
>>     > # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build
>>     > 23-internal-adhoc.asmehra.leyden)
>>     > # Java VM: OpenJDK 64-Bit Server VM (slowdebug
>>     > 23-internal-adhoc.asmehra.leyden, mixed mode, sharing, tiered,
>>     > compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>>     > # Problematic frame:
>>     > # V  [libjvm.so+0x409cb6]  Klass::is_instance_klass() const+0x10
>>     > #
>>     > # Core dump will be written. Default location:
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/core.152509
>>     > #
>>     > # An error report file with more information is saved as:
>>     > #
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/test/hotspot/jtreg/premain/quarkus-getting-started/hs_err_pid152509.log
>>     > #
>>     > # If you would like to submit a bug report, please visit:
>>     > # https://bugreport.java.com/bugreport/crash.jsp
>>    <https://urldefense.com/v3/__https://bugreport.java.com/bugreport/crash.jsp__;!!ACWV5N9M2RV99hQ!Ls5umFY3l179hejC6K3i6zCDc3tx5W5e9zPaHr8MAtxR4iimfU3JHwyaW8ap3Ojy2h1J5YGITxMuLboYhUL6USw$>
>>     > <https://bugreport.java.com/bugreport/crash.jsp
>>    <https://urldefense.com/v3/__https://bugreport.java.com/bugreport/crash.jsp__;!!ACWV5N9M2RV99hQ!Ls5umFY3l179hejC6K3i6zCDc3tx5W5e9zPaHr8MAtxR4iimfU3JHwyaW8ap3Ojy2h1J5YGITxMuLboYhUL6USw$>>
>>     > #
>>     > [75.250s][error  ][cds] Child process finished; status = 134
>>     >
>>     > Backtrace for the crashing thread:
>>     >
>>     > #11 0x00007f4e8a209cb6 in Klass::is_instance_klass (this=0x0) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.hpp:683
>>     > #12 0x00007f4e8afa8894 in Klass::external_name (this=0x0) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/klass.cpp:905
>>     > #13 0x00007f4e8b126447 in Method::print_external_name
>>     > (os=0x7f4e89dfd130, klass=0x0, method_name=0x8011e8588,
>>     > signature=0x8011ab858) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:228
>>     > #14 0x00007f4e8b1263b6 in Method::external_name (klass=0x0,
>>     > method_name=0x8011e8588, signature=0x8011ab858) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:222
>>     > #15 0x00007f4e8b1262e1 in Method::external_name
>>    (this=0x800fd1920) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/oops/method.cpp:213
>>     > #16 0x00007f4e8a492b0d in ArchiveBuilder::CDSMapLogger::log_method
>>     > (m=0x800fd1920, runtime_dest=0x801039cd8 "",
>>    type_name=0x7f4e8b7d40fc
>>     > "Method", bytes=128, current=0x7f4e8401d900)
>>     >      at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1194
>>     > #17 0x00007f4e8a492d66 in
>>     > ArchiveBuilder::CDSMapLogger::log_metaspace_objects
>>     > (region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1228
>>     > #18 0x00007f4e8a492a2b in
>>     > ArchiveBuilder::CDSMapLogger::log_metaspace_region
>>    (name=0x7f4e8b7d8af0
>>     > "rw region", region=0x7f4e89dfe740, src_objs=0x7f4e89dfe860) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1182
>>     > #19 0x00007f4e8a4940f4 in ArchiveBuilder::CDSMapLogger::log
>>     > (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0,
>>     > heap_info=0x7f4e89dfd4f0, bitmap=0x7f4e857bf850
>>     > "\t\222\004I\222$\t\210\210\210\001\b\200",
>>    bitmap_size_in_bytes=655824)
>>     >      at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1502
>>     > #20 0x00007f4e8a48f2a5 in ArchiveBuilder::write_archive
>>     > (this=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0,
>>    heap_info=0x7f4e89dfd4f0)
>>     > at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/archiveBuilder.cpp:1560
>>     > #21 0x00007f4e8b11d249 in MetaspaceShared::write_static_archive
>>     > (builder=0x7f4e89dfe630, mapinfo=0x7f4e85017bb0,
>>     > heap_info=0x7f4e89dfd4f0) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:988
>>     > #22 0x00007f4e8b11d1ac in MetaspaceShared::preload_and_dump_impl
>>     > (builder=..., __the_thread__=0x7f4e8401d900) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:976
>>     > #23 0x00007f4e8b11c5fd in MetaspaceShared::preload_and_dump () at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/cds/metaspaceShared.cpp:767
>>     > #24 0x00007f4e8b53bca2 in Threads::create_vm (args=0x7f4e89dfedd0,
>>     > canTryAgain=0x7f4e89dfecd3) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/threads.cpp:900
>>     > #25 0x00007f4e8ada2821 in JNI_CreateJavaVM_inner (vm=0x7f4e89dfee20,
>>     > penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3581
>>     > #26 0x00007f4e8ada2c81 in JNI_CreateJavaVM (vm=0x7f4e89dfee20,
>>     > penv=0x7f4e89dfee28, args=0x7f4e89dfedd0) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/prims/jni.cpp:3672
>>     > #27 0x00007f4e8ce0f84f in InitializeJVM (pvm=0x7f4e89dfee20,
>>     > penv=0x7f4e89dfee28, ifn=0x7f4e89dfee70) at
>>     >
>>    /home/asmehra/data/ashu-mehra/leyden/src/java.base/share/native/libjli/java.c:1550
>>     >
>>     > Checking up the CDS map generated for the cds preimage shows some
>>     > methods for which their InstanceKlass is null.
>>     > This results in the crash seen above when such methods are
>>    printed as
>>     > part of the CDS map file during the assembly phase.
>>     >
>>     > These methods are of the form:
>>     >
>>     > java.lang.Object
>>     > java.lang.invoke.LambdaForm$MH/0x800000090.invoke(java.lang.Object,
>>     > java.lang.Object)
>>     >
>>     > Interestingly -Xlog:cds=info shows such classes are skipped when
>>     > generating the preimage as they are hidden classes:
>>     >
>>     > Skipping java/lang/invoke/LambdaForm$MH+0x800000090: Hidden class
>>     >
>>     > In the CDS map file for the preimage I also noticed that such
>>    methods
>>     > are only referenced through MethodTrainingData -> _final_profile
>>    -> _method.
>>     > So it looks like although we excluded such classes from the CDS
>>    archive,
>>     > we don't exclude their training data.
>>     > There is code for cleaning up the training data [0] , but it doesn't
>>     > remove the training data for classes that have been excluded,
>>    unless I
>>     > misunderstood the code.
>>     > Not sure if it is intentional or a bug.
>>     > If we do need to keep the training data for such methods, then we
>>    would
>>     > need to handle the case of null InstanceKlass in the CDSMapLogger to
>>     > avoid crashing.
>>     >
>>     > [0]
>>     >
>>    https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp*L573__;Iw!!ACWV5N9M2RV99hQ!Ls5umFY3l179hejC6K3i6zCDc3tx5W5e9zPaHr8MAtxR4iimfU3JHwyaW8ap3Ojy2h1J5YGITxMuLboYP1sEOXU$> <https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp#L573 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/8716f47ef49c829e2384474577ff468a732b9c66/src/hotspot/share/oops/trainingData.cpp*L573__;Iw!!ACWV5N9M2RV99hQ!Ls5umFY3l179hejC6K3i6zCDc3tx5W5e9zPaHr8MAtxR4iimfU3JHwyaW8ap3Ojy2h1J5YGITxMuLboYP1sEOXU$>>
>>     >
>>     > Thanks,
>>     > - Ashutosh Mehra


From duke at openjdk.org  Sun Jul  7 00:13:53 2024
From: duke at openjdk.org (duke)
Date: Sun, 7 Jul 2024 00:13:53 GMT
Subject: git: openjdk/leyden: premain: 3 new changesets
Message-ID: <52a010a8-919d-433f-aa2d-5c42262f8f3f@openjdk.org>

Changeset: 43e77c8e
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-06 09:29:15 +0000
URL:       https://git.openjdk.org/leyden/commit/43e77c8e62631d94e44cb017707917b7e2d6aa7b

Added test case for 8328563: Store java.lang.ClassLoader::{packages, package2certs} into CDS archive

! src/java.base/share/classes/java/lang/ClassLoader.java
! test/hotspot/jtreg/premain/spring-petclinic/Makefile
! test/hotspot/jtreg/premain/spring-petclinic/WarmupMakefile
+ test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedPackages.java
= test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg3/Package3A.java
= test/hotspot/jtreg/runtime/cds/appcds/test-classes/pkg3/Package3B.java

Changeset: d9e3e5fe
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-06 09:36:41 +0000
URL:       https://git.openjdk.org/leyden/commit/d9e3e5fe69a430567c7ac4d91f2e064d594b4f0a

8335804: ArchiveInvokeDynamic causes BootstrapMethodError

! src/java.base/share/classes/java/lang/invoke/MethodType.java

Changeset: 77e9f24c
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-06 10:45:26 +0000
URL:       https://git.openjdk.org/leyden/commit/77e9f24c8fb60e5ad741482c58ba83d19a34cb15

Print more info about command-line to help debugging the dumping process

! src/hotspot/share/cds/metaspaceShared.cpp


From volker.simonis at gmail.com  Mon Jul  8 13:52:20 2024
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 8 Jul 2024 15:52:20 +0200
Subject: Draft JEP 8315737: AOT Linked Classes
In-Reply-To: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
References: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
Message-ID: <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>

Hi Jon,

Thanks for the update and great to see this moving forward.

After reading the full JEP it became evident that  "Cached Data
Storage" is actually an extension of the existing and well known
"Class Data Sharing" feature. However, the current description
introduces "CDS" (which is the well known acronym for "Class Data
Sharing" since JDK 5 times [1]) as "Cached Data Storage". This is
surprising and confusing for everybody already familiar with the
existing "CDS" feature. I'd therefore suggest to move the very last
sentence of the JEP to the very beginning. E.g. something like:

This JEP is an evolution of the existing CDS ("Class Data Sharing")
implementation. In the remainder of the document we will refer to CDS
as "Cached Data Storage" to emphasize its extended functionality
compared to the classic Class Data Sharing.

Another point I think the JEP should address in some more detail is
the effect of "Cached Data Storage" on the overall memory footprint of
the JVM process. The classic "Class Data Sharing" already slightly
increased the memory footprint of the JVM and only amortized if more
than one JVM used the same CDS archive at runtime. Please describe the
effects of the new "Cached Data Storage" on memory footprint.

Finally some minor text corrections:

> CDS is built into the HotSpot VM since JDK 6.

It's actually there since JDK 5, see [1] :)

> Using CDS

The way you describe the manual usage of CDS is "old" and quite
cumbersome. Why not use  the new -XX:+AutoCreateSharedArchive option
which automatically creates the archive if non is available. Or does
-XX:+AOTLoadedClasses not work together with
-XX:+AutoCreateSharedArchive and if so, why not?

> This is can be viewed as..

Remove redundant "is" in the sentence above.

> from CDS assets already present VM memory,

Should probably read "..present in VM memory.."

> such as method profiles and compiled code, can stored as new assets

Should probably read "..can be stored.."

> The implementation CDS already does enforce

Should probably read "The CDS implementation.."

> Therefore, we can use run existing CDS test cases with this option explicitly enabled.

Should probably read "we can use and run existing.."

Regards,
Volker

[1] https://web.archive.org/web/20040604034719/http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
[2] https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#creating-dynamic-cds-archive-file-with--xxautocreatesharedarchive

On Thu, Jul 4, 2024 at 7:38?AM John Rose <john.r.rose at oracle.com> wrote:
>
> Dear colleagues,
>
> Having recently delivered a Leyden EA Build of our ?premain? work, the Leyden team is very happy to post our first JEP for public review.
>
> https://openjdk.org/jeps/8315737
>
> Covering a subset of the functionality in the EA Build, this JEP describes our plans for introducing, to the JDK, the first course of startup and warmup enhancements which have been ?cooking? since last February.
>
> Because CDS is a somewhat obscure technology, and because startup and warmup are very tricky (even refractory) problems in our ecosystem, we are striving to make the JEP as clear and informative as possible.  It covers the nature of the problem, and the past solutions in HotSpot, as well as the present proposal.  (Although there are many excellent and inspiring proposals for this problem beyond HotSpot, this JEP does not attempt to address them; that is for another paper.)  We hope you find it an interesting and useful mix of ?high level? and ?nitty gritty? details.
>
> Though the actual proposal (the Description) section may seem surprisingly simple, the implications are pervasive and subtle.  As the JEP explains, the proposed changes will be felt all the more in the AOT technologies built on top, as can be seen in our EA Build.
>
> The Non-Goals section gives guidance about where we expect to go after this JEP.
> So if there seems to be a missing piece in this JEP, please look for it first among the non-goals!  We are working on more JEPs to come after this one.  Let?s get this one sorted so we can do more.
>
> Like the EA Build, this work has not been possible without the participation of the Java community.  Special thanks to our Red Hat and Spring colleagues, and to everyone who is now sampling that EA Build.  Also, special thanks to our very demanding early reviewers, notably Alex Buckley, Brian Goetz, my co-authors Dan and Ioi, and the other members of the premain team.
>
> Your comments on the JEP will surely improve it as well.
>
> Best wishes,
>
> ? John Rose

From sanne at redhat.com  Mon Jul  8 13:57:16 2024
From: sanne at redhat.com (Sanne Grinovero)
Date: Mon, 8 Jul 2024 14:57:16 +0100
Subject: Build fails when disabling jvmti
Message-ID: <CAA5_-WYNzw7zTGbQpUW8bQwPxvWsB7XLQnfqxNJvQgf9VE+c1A@mail.gmail.com>

Hello all,

I'm experimenting building Leyden locally with non-default configurations,
with the intent of comparing its potential as an alternative to GraalVM
native-images, and one of my goals would be to produce a minimal JVM build
which exclusively includes the components that our applications are going
to need at runtime.

This implies being very selective with the JVM features I choose at
configuration time; I've already opened some minor issues identified during
such experiments.

Today I noticed today that if I exclude the "jvmti" feature, the premain
branch of Leyden doesn't compile:


=== Output from failing command(s) repeated here ===
* For target hotspot_variant-custom_libjvm_objs_SCCache.o:
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp: In member
function ?void SCAddressTable::init_opto()?:
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3815:39:
error: ?notify_jvmti_vthread_start? is not a member of ?OptoRuntime?
 3815 |   SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_start());
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
note: in definition of macro ?SET_ADDRESS?
 3511 |     type##_addr[type##_length++] = (address) (addr);      \
      |                                               ^~~~
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3816:39:
error: ?notify_jvmti_vthread_end? is not a member of ?OptoRuntime?
 3816 |   SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_end());
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
note: in definition of macro ?SET_ADDRESS?
 3511 |     type##_addr[type##_length++] = (address) (addr);      \
      |                                               ^~~~
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3817:39:
error: ?notify_jvmti_vthread_mount? is not a member of ?OptoRuntime?
 3817 |   SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_mount());
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
note: in definition of macro ?SET_ADDRESS?
 3511 |     type##_addr[type##_length++] = (address) (addr);      \
      |                                               ^~~~
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3818:39:
error: ?notify_jvmti_vthread_unmount? is not a member of ?OptoRuntime?
 3818 |   SET_ADDRESS(_C2_blobs,
OptoRuntime::notify_jvmti_vthread_unmount());
      |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
note: in definition of macro ?SET_ADDRESS?
 3511 |     type##_addr[type##_length++] = (address) (addr);      \
      |                                               ^~~~
   ... (rest of output omitted)

I'm wondering if I should open an issue for this case? I appreciate it's
early days and that such aspects might not be a priority currently!

Thanks,
Sanne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240708/bb4abd7d/attachment.htm>

From asmehra at redhat.com  Mon Jul  8 15:17:58 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Mon, 8 Jul 2024 11:17:58 -0400
Subject: Build fails when disabling jvmti
In-Reply-To: <CAA5_-WYNzw7zTGbQpUW8bQwPxvWsB7XLQnfqxNJvQgf9VE+c1A@mail.gmail.com>
References: <CAA5_-WYNzw7zTGbQpUW8bQwPxvWsB7XLQnfqxNJvQgf9VE+c1A@mail.gmail.com>
Message-ID: <CAKt0pyS4d0aNje42SFqRrR0+VR0vr+i8bfyOhXG4W1zE_F335Q@mail.gmail.com>

Hi Sanne, thanks for reporting this. It looks like a bug. It can be fixed
by enclosing the relevant code under the "INCLUDE_JVMTI" macro.

- Ashutosh Mehra


On Mon, Jul 8, 2024 at 9:58?AM Sanne Grinovero <sanne at redhat.com> wrote:

> Hello all,
>
> I'm experimenting building Leyden locally with non-default configurations,
> with the intent of comparing its potential as an alternative to GraalVM
> native-images, and one of my goals would be to produce a minimal JVM build
> which exclusively includes the components that our applications are going
> to need at runtime.
>
> This implies being very selective with the JVM features I choose at
> configuration time; I've already opened some minor issues identified during
> such experiments.
>
> Today I noticed today that if I exclude the "jvmti" feature, the premain
> branch of Leyden doesn't compile:
>
>
> === Output from failing command(s) repeated here ===
> * For target hotspot_variant-custom_libjvm_objs_SCCache.o:
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp: In member
> function ?void SCAddressTable::init_opto()?:
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3815:39:
> error: ?notify_jvmti_vthread_start? is not a member of ?OptoRuntime?
>  3815 |   SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_start());
>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>       |                                               ^~~~
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3816:39:
> error: ?notify_jvmti_vthread_end? is not a member of ?OptoRuntime?
>  3816 |   SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_end());
>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>       |                                               ^~~~
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3817:39:
> error: ?notify_jvmti_vthread_mount? is not a member of ?OptoRuntime?
>  3817 |   SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_mount());
>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>       |                                               ^~~~
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3818:39:
> error: ?notify_jvmti_vthread_unmount? is not a member of ?OptoRuntime?
>  3818 |   SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_unmount());
>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>       |                                               ^~~~
>    ... (rest of output omitted)
>
> I'm wondering if I should open an issue for this case? I appreciate it's
> early days and that such aspects might not be a priority currently!
>
> Thanks,
> Sanne
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240708/f555dd63/attachment.htm>

From headius at headius.com  Mon Jul  8 16:04:01 2024
From: headius at headius.com (Charles Oliver Nutter)
Date: Mon, 8 Jul 2024 11:04:01 -0500
Subject: Hello from JRuby and here's another crash
In-Reply-To: <9e008170-7348-410b-9ecb-753101367181@oracle.com>
References: <CAE-f1xSYcJudwYQUSZQxzU2nvqXnUSHLgQ69STYGMwJjsUKcsQ@mail.gmail.com>
 <9e008170-7348-410b-9ecb-753101367181@oracle.com>
Message-ID: <CAE-f1xRn_Lh0=zRp5=fO0ek=xoV2iqNzyagTAD9nG43JuXaz=Q@mail.gmail.com>

The patched build does indeed work, and cuts JRuby's base startup time by
50%! Bravo!

$ time jruby -e 1
jruby -e 1  3.53s user 0.14s system 276% cpu 1.326 total
$ time jruby -J-XX:CacheDataStore=jruby.cds -e 1
jruby -J-XX:CacheDataStore=jruby.cds -e 1  2.38s user 0.19s system 385% cpu
0.667 total

This is a very promising start and the largest single improvement we have
seen. Comparison with our previous champion, C1:

$ time jruby --dev -e 1
jruby --dev -e 1  1.22s user 0.09s system 142% cpu 0.922 total

Interestingly, when I try to use the previously trained CDS dump (via
100.times { org.jruby.Ruby.newInstance }) with a command line that forces
C1 (--dev flag passes -XX:TieredStopAtLevel=1) I get a different crash:
https://gist.github.com/headius/d3138efa52eed9c678414c8cfe08af27

I'm wondering what else I can do to try to train the CDS dump better, so
that a larger command (jruby -S gem list) sees more improvement (this loads
a bunch more Ruby code into the interpreter):

$ time jruby -S gem list > /dev/null
jruby -S gem list > /dev/null  6.41s user 0.26s system 236% cpu 2.821 total
$ time jruby -J-XX:CacheDataStore=jruby.cds -S gem list > /dev/null
jruby -J-XX:CacheDataStore=jruby.cds -S gem list > /dev/null  5.84s user
0.32s system 294% cpu 2.089 total

- Charlie

On Thu, Jul 4, 2024 at 11:50?PM <ioi.lam at oracle.com> wrote:

> Hi Charlie,
>
> Thanks for the bug report.
>
> It turns out some Leyden optimizations can't handle the module options
> specified by jruby, such as these:
>
>     --add-opens=java.base/java.nio.channels=org.jruby.dist
>     --module-path=/xxxx/jruby-9.4.8.0/lib/jruby.jar
>
> I filed https://bugs.openjdk.org/browse/JDK-8335735
>
> I'll work on a proper fix. Meanwhile, I have a work-around in this branch
>
>
> https://github.com/iklam/jdk/tree/work-around-8335735-jruby-crash-due-to-lack-of-module-support
>
> If you build a JDK from this source branch, you can see the following
> improvements:
>
> # [1] No optimizations
> $ time env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>     -e '10.times { org.jruby.Ruby.newInstance }'
> real   0m3.215s
> user   0m14.868s
> sys    0m0.373s
>
>
> # [2] Leyden
> $ time env JAVA_HOME=$TBP0 ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>     -J-XX:CacheDataStore=jruby.cds \
>     -e '10.times { org.jruby.Ruby.newInstance }'
> real   0m1.880s
> user   0m9.001s
> sys    0m0.268s
>
>
> # [3] Compare with CDS in the JDK mainline
> $ env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>      -J-XX:DumpLoadedClassList=jruby.classlist \
>      -e '10.times { org.jruby.Ruby.newInstance }'
> $ $MYJAVA/bin/java -Xshare:dump \
>     --module-path=/home/iklam/Downloads/ruby/jruby-9.4.8.0/lib/jruby.jar \
>     -XX:SharedClassListFile=jruby.classlist \
>     -XX:SharedArchiveFile=jruby.jsa -Xlog:cds
> $ time env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>     -J-XX:SharedArchiveFile=jruby.jsa \
>     -e '10.times { org.jruby.Ruby.newInstance }'
> real   0m2.628s
> user   0m13.007s
> sys    0m0.428s
>
> Please try it out and let us know if you run into other problems.
>
> Thanks
>
> - Ioi
>
>
> On 7/4/24 1:06 PM, Charles Oliver Nutter wrote:
>
> Hello friends! Long time lurker, first time poster.
>
> Like others I was excited to hear that the first EA of Leyden had dropped.
> Sadly, I have another crash to report.
>
> I see there are two other crashes reported, but mine appears different
> (ClassPrelinker::is_indy_resolution_deterministic):
>
> https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24
>
> Perhaps unsurprisingly, the additional flags provided by Vladimir Kozlov (-XX:+UnlockDiagnosticVMOptions
> -XX:-ReduceAllocationMerges) did not appear to change the result.
>
> This is with JRuby's minimally invokedynamic-based mode, which has given
> us the shortest startup time in the past (second only to disabling tiers
> 2-4 and staying in C1).
>
> I am on MacOS AArch64 Sonoma 14.5, testing against JRuby master, but
> reproduction should be as easy as downloading the JRuby binary tarball,
> unpacking, and running bin/jruby with the command line above.
>
> https://www.jruby.org/download
>
> I am eager to work with Leyden folks to investigate issues, and I am
> planning to be at JVMLS this year to discuss collaborating more!
>
> - Charlie
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240708/01737d83/attachment.htm>

From asmehra at redhat.com  Mon Jul  8 16:43:26 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Mon, 8 Jul 2024 12:43:26 -0400
Subject: Build fails when disabling jvmti
In-Reply-To: <CAKt0pyS4d0aNje42SFqRrR0+VR0vr+i8bfyOhXG4W1zE_F335Q@mail.gmail.com>
References: <CAA5_-WYNzw7zTGbQpUW8bQwPxvWsB7XLQnfqxNJvQgf9VE+c1A@mail.gmail.com>
 <CAKt0pyS4d0aNje42SFqRrR0+VR0vr+i8bfyOhXG4W1zE_F335Q@mail.gmail.com>
Message-ID: <CAKt0pySY-w0AOJ-uU17T=zV5BkLuGdTVEAGKwEwtXzNmHeaFpQ@mail.gmail.com>

Hi Sanne,
For the record I am able to recreate this issue if I create a custom
variant and omit jvmti feature using the following configure command:

bash ./configure --with-conf-name=no-jvmti-release
--with-jvm-features=cds,compiler1,compiler2,g1gc,serialgc,jfr,jni-check,jvmci,management,services
--with-jvm-variants=custom

I tried to fix it by enclosing the code in SCCache.cpp with INCLUDE_JVMTI
but the build failed again in premain specific code with this error:

/home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1804:23:
error: ?_perf_InterpreterRuntime_member_name_arg_or_null_timer? was not
declared in this scope; did you mean
?_perf_InterpreterRuntime_prepare_native_call_timer??
 1804 |   NEWPERFTICKCOUNTERS(_perf_##sub##_##name##_timer, SUN_CI, #sub
"::" #name); \
      |                       ^~~~~~
/home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/perfData.hpp:854:4:
note: in definition of macro ?NEWPERFTICKCOUNTERS?
  854 |   {counter = PerfDataManager::create_tick_counters(counter_ns,
counter_name, counter_name "_elapsed_time", \
      |    ^~~~~~~
/home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1798:3:
note: in expansion of macro ?INIT_COUNTER?
 1798 |   macro(InterpreterRuntime, member_name_arg_or_null)
      |   ^~~~~
/home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1812:5:
note: in expansion of macro ?DO_JVMTI_COUNTERS?
 1812 |     DO_JVMTI_COUNTERS(INIT_COUNTER)
      |     ^~~~~~~~~~~~~~~~~

I worked around it and it next failed with following errors:

/usr/bin/ld:
/home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o:
in function `JvmtiUtil::error_name(int)':
make/hotspot/src/hotspot/share/prims/jvmtiUtil.hpp:51: undefined reference
to `JvmtiUtil::_error_names'
/usr/bin/ld:
/home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o:
in function `JvmtiEnvBase::get_phase()':
make/hotspot/src/hotspot/share/prims/jvmtiEnvBase.hpp:77: undefined
reference to `JvmtiEnvBase::_phase'
/usr/bin/ld:
/home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o:
in function `JfrPeriodicEventSet::requestJavaAgent()':
make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:294: undefined
reference to `JvmtiAgentList::java_agents()'
/usr/bin/ld:
/home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o:
in function `JfrPeriodicEventSet::requestNativeAgent()':
make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:314: undefined
reference to `JvmtiAgentList::native_agents()'
/usr/bin/ld:
make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:316: undefined
reference to `JvmtiAgentList::xrun_agents()'
/usr/bin/ld:
/home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jvmciCompilerToVMInit.o:
in function `CompilerToVM::Data::initialize(JVMCIEnv*)':
make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:212:
undefined reference to `JvmtiExport::_should_notify_object_alloc'
collect2: error: ld returned 1 exit status

This is not specific to premain, and I can reproduce it with mainline as
well. It doesn't look like it is straightforward to remove the jvmti
feature. Seems like there may be other components (like jfr) missing
INCLUDE_JVMTI macro.
My suggestion, if you are interested in pursuing it further, would be to
try and wrinkle out the problems with the mainline first.

Meanwhile I will push the changes to use INCLUDE_JVMTI in the premain
specific code.

- Ashutosh Mehra


On Mon, Jul 8, 2024 at 11:17?AM Ashutosh Mehra <asmehra at redhat.com> wrote:

> Hi Sanne, thanks for reporting this. It looks like a bug. It can be fixed
> by enclosing the relevant code under the "INCLUDE_JVMTI" macro.
>
> - Ashutosh Mehra
>
>
> On Mon, Jul 8, 2024 at 9:58?AM Sanne Grinovero <sanne at redhat.com> wrote:
>
>> Hello all,
>>
>> I'm experimenting building Leyden locally with non-default
>> configurations, with the intent of comparing its potential as an
>> alternative to GraalVM native-images, and one of my goals would be to
>> produce a minimal JVM build which exclusively includes the components that
>> our applications are going to need at runtime.
>>
>> This implies being very selective with the JVM features I choose at
>> configuration time; I've already opened some minor issues identified during
>> such experiments.
>>
>> Today I noticed today that if I exclude the "jvmti" feature, the premain
>> branch of Leyden doesn't compile:
>>
>>
>> === Output from failing command(s) repeated here ===
>> * For target hotspot_variant-custom_libjvm_objs_SCCache.o:
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp: In member
>> function ?void SCAddressTable::init_opto()?:
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3815:39:
>> error: ?notify_jvmti_vthread_start? is not a member of ?OptoRuntime?
>>  3815 |   SET_ADDRESS(_C2_blobs,
>> OptoRuntime::notify_jvmti_vthread_start());
>>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
>> note: in definition of macro ?SET_ADDRESS?
>>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>>       |                                               ^~~~
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3816:39:
>> error: ?notify_jvmti_vthread_end? is not a member of ?OptoRuntime?
>>  3816 |   SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_end());
>>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
>> note: in definition of macro ?SET_ADDRESS?
>>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>>       |                                               ^~~~
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3817:39:
>> error: ?notify_jvmti_vthread_mount? is not a member of ?OptoRuntime?
>>  3817 |   SET_ADDRESS(_C2_blobs,
>> OptoRuntime::notify_jvmti_vthread_mount());
>>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
>> note: in definition of macro ?SET_ADDRESS?
>>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>>       |                                               ^~~~
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3818:39:
>> error: ?notify_jvmti_vthread_unmount? is not a member of ?OptoRuntime?
>>  3818 |   SET_ADDRESS(_C2_blobs,
>> OptoRuntime::notify_jvmti_vthread_unmount());
>>       |                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
>> note: in definition of macro ?SET_ADDRESS?
>>  3511 |     type##_addr[type##_length++] = (address) (addr);      \
>>       |                                               ^~~~
>>    ... (rest of output omitted)
>>
>> I'm wondering if I should open an issue for this case? I appreciate it's
>> early days and that such aspects might not be a priority currently!
>>
>> Thanks,
>> Sanne
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240708/a24cf0e9/attachment.htm>

From vladimir.kozlov at oracle.com  Mon Jul  8 18:10:32 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 8 Jul 2024 11:10:32 -0700
Subject: Build fails when disabling jvmti
In-Reply-To: <CAKt0pySY-w0AOJ-uU17T=zV5BkLuGdTVEAGKwEwtXzNmHeaFpQ@mail.gmail.com>
References: <CAA5_-WYNzw7zTGbQpUW8bQwPxvWsB7XLQnfqxNJvQgf9VE+c1A@mail.gmail.com>
 <CAKt0pyS4d0aNje42SFqRrR0+VR0vr+i8bfyOhXG4W1zE_F335Q@mail.gmail.com>
 <CAKt0pySY-w0AOJ-uU17T=zV5BkLuGdTVEAGKwEwtXzNmHeaFpQ@mail.gmail.com>
Message-ID: <46b7af92-9dd4-409f-aaa5-4e1a782308f4@oracle.com>

Ashutosh, please file bug for mainline hotspot/jvmti component.

Thanks,
Vladimir K

On 7/8/24 9:43 AM, Ashutosh Mehra wrote:
> Hi Sanne,
> For the record I am able to recreate this issue if I create a custom variant and omit jvmti feature using the following 
> configure command:
> 
> bash ./configure --with-conf-name=no-jvmti-release 
> --with-jvm-features=cds,compiler1,compiler2,g1gc,serialgc,jfr,jni-check,jvmci,management,services --with-jvm-variants=custom
> 
> I tried to fix it by enclosing the code in SCCache.cpp with?INCLUDE_JVMTI but the build failed again in premain specific 
> code with this error:
> 
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1804:23: error: 
> ?_perf_InterpreterRuntime_member_name_arg_or_null_timer? was not declared in this scope; did you mean 
> ?_perf_InterpreterRuntime_prepare_native_call_timer??
>  ?1804 | ? NEWPERFTICKCOUNTERS(_perf_##sub##_##name##_timer, SUN_CI, #sub "::" #name); \
>  ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ^~~~~~
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/perfData.hpp:854:4: note: in definition of macro 
> ?NEWPERFTICKCOUNTERS?
>  ? 854 | ? {counter = PerfDataManager::create_tick_counters(counter_ns, counter_name, counter_name "_elapsed_time", \
>  ? ? ? | ? ?^~~~~~~
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1798:3: note: in expansion of 
> macro ?INIT_COUNTER?
>  ?1798 | ? macro(InterpreterRuntime, member_name_arg_or_null)
>  ? ? ? | ? ^~~~~
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1812:5: note: in expansion of 
> macro ?DO_JVMTI_COUNTERS?
>  ?1812 | ? ? DO_JVMTI_COUNTERS(INIT_COUNTER)
>  ? ? ? | ? ? ^~~~~~~~~~~~~~~~~
> 
> I worked around it and it next failed with following errors:
> 
> /usr/bin/ld: 
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o: in 
> function `JvmtiUtil::error_name(int)':
> make/hotspot/src/hotspot/share/prims/jvmtiUtil.hpp:51: undefined reference to `JvmtiUtil::_error_names'
> /usr/bin/ld: 
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o: in 
> function `JvmtiEnvBase::get_phase()':
> make/hotspot/src/hotspot/share/prims/jvmtiEnvBase.hpp:77: undefined reference to `JvmtiEnvBase::_phase'
> /usr/bin/ld: 
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o: in function 
> `JfrPeriodicEventSet::requestJavaAgent()':
> make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:294: undefined reference to `JvmtiAgentList::java_agents()'
> /usr/bin/ld: 
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o: in function 
> `JfrPeriodicEventSet::requestNativeAgent()':
> make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:314: undefined reference to `JvmtiAgentList::native_agents()'
> /usr/bin/ld: make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:316: undefined reference to 
> `JvmtiAgentList::xrun_agents()'
> /usr/bin/ld: 
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jvmciCompilerToVMInit.o: 
> in function `CompilerToVM::Data::initialize(JVMCIEnv*)':
> make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:212: undefined reference to 
> `JvmtiExport::_should_notify_object_alloc'
> collect2: error: ld returned 1 exit status
> 
> This is not specific to premain, and I can reproduce it with mainline as well. It doesn't look like it is 
> straightforward to remove the jvmti feature. Seems like there may be other components (like jfr) missing INCLUDE_JVMTI 
> macro.
> My suggestion, if you are interested in pursuing it further, would be to try and wrinkle out the problems with the 
> mainline first.
> 
> Meanwhile I will push the changes to use INCLUDE_JVMTI in the premain specific code.
> 
> - Ashutosh Mehra
> 
> 
> On Mon, Jul 8, 2024 at 11:17?AM Ashutosh Mehra <asmehra at redhat.com <mailto:asmehra at redhat.com>> wrote:
> 
>     Hi Sanne, thanks for reporting this. It looks like a bug. It can be fixed by enclosing the relevant code under the
>     "INCLUDE_JVMTI" macro.
> 
>     - Ashutosh Mehra
> 
> 
>     On Mon, Jul 8, 2024 at 9:58?AM Sanne Grinovero <sanne at redhat.com <mailto:sanne at redhat.com>> wrote:
> 
>         Hello all,
> 
>         I'm experimenting building Leyden locally with non-default configurations, with the intent of comparing its
>         potential as an alternative to GraalVM native-images, and one of my goals would be to produce a minimal JVM
>         build which exclusively includes the components that our applications are going to need at runtime.
> 
>         This implies being very selective with the JVM features I choose at configuration time; I've already opened some
>         minor issues identified during such experiments.
> 
>         Today I noticed today that if I exclude the "jvmti" feature, the premain branch of Leyden doesn't compile:
> 
> 
>         === Output from failing command(s) repeated here ===
>         * For target hotspot_variant-custom_libjvm_objs_SCCache.o:
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp: In member function ?void
>         SCAddressTable::init_opto()?:
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3815:39: error: ?notify_jvmti_vthread_start? is
>         not a member of ?OptoRuntime?
>          ?3815 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_start());
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro ?SET_ADDRESS?
>          ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3816:39: error: ?notify_jvmti_vthread_end? is not
>         a member of ?OptoRuntime?
>          ?3816 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_end());
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro ?SET_ADDRESS?
>          ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3817:39: error: ?notify_jvmti_vthread_mount? is
>         not a member of ?OptoRuntime?
>          ?3817 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_mount());
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro ?SET_ADDRESS?
>          ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3818:39: error: ?notify_jvmti_vthread_unmount? is
>         not a member of ?OptoRuntime?
>          ?3818 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_unmount());
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro ?SET_ADDRESS?
>          ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>          ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>          ? ?... (rest of output omitted)
> 
>         I'm wondering if I should open an issue for this case? I appreciate it's early days and that such aspects might
>         not be a priority currently!
> 
>         Thanks,
>         Sanne
> 

From asmehra at redhat.com  Mon Jul  8 18:57:02 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Mon, 8 Jul 2024 14:57:02 -0400
Subject: Build fails when disabling jvmti
In-Reply-To: <46b7af92-9dd4-409f-aaa5-4e1a782308f4@oracle.com>
References: <CAA5_-WYNzw7zTGbQpUW8bQwPxvWsB7XLQnfqxNJvQgf9VE+c1A@mail.gmail.com>
 <CAKt0pyS4d0aNje42SFqRrR0+VR0vr+i8bfyOhXG4W1zE_F335Q@mail.gmail.com>
 <CAKt0pySY-w0AOJ-uU17T=zV5BkLuGdTVEAGKwEwtXzNmHeaFpQ@mail.gmail.com>
 <46b7af92-9dd4-409f-aaa5-4e1a782308f4@oracle.com>
Message-ID: <CAKt0pyQqckvNhu5N+teJVN+4fW55H_5tWHup82GbC8RrkKGT5g@mail.gmail.com>

Here is the issue for mainline: https://bugs.openjdk.org/browse/JDK-8335921

- Ashutosh Mehra


On Mon, Jul 8, 2024 at 2:10?PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Ashutosh, please file bug for mainline hotspot/jvmti component.
>
> Thanks,
> Vladimir K
>
> On 7/8/24 9:43 AM, Ashutosh Mehra wrote:
> > Hi Sanne,
> > For the record I am able to recreate this issue if I create a custom
> variant and omit jvmti feature using the following
> > configure command:
> >
> > bash ./configure --with-conf-name=no-jvmti-release
> >
> --with-jvm-features=cds,compiler1,compiler2,g1gc,serialgc,jfr,jni-check,jvmci,management,services
> --with-jvm-variants=custom
> >
> > I tried to fix it by enclosing the code in SCCache.cpp
> with INCLUDE_JVMTI but the build failed again in premain specific
> > code with this error:
> >
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1804:23:
> error:
> > ?_perf_InterpreterRuntime_member_name_arg_or_null_timer? was not
> declared in this scope; did you mean
> > ?_perf_InterpreterRuntime_prepare_native_call_timer??
> >   1804 |   NEWPERFTICKCOUNTERS(_perf_##sub##_##name##_timer, SUN_CI,
> #sub "::" #name); \
> >        |                       ^~~~~~
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/perfData.hpp:854:4:
> note: in definition of macro
> > ?NEWPERFTICKCOUNTERS?
> >    854 |   {counter = PerfDataManager::create_tick_counters(counter_ns,
> counter_name, counter_name "_elapsed_time", \
> >        |    ^~~~~~~
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1798:3:
> note: in expansion of
> > macro ?INIT_COUNTER?
> >   1798 |   macro(InterpreterRuntime, member_name_arg_or_null)
> >        |   ^~~~~
> >
> /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1812:5:
> note: in expansion of
> > macro ?DO_JVMTI_COUNTERS?
> >   1812 |     DO_JVMTI_COUNTERS(INIT_COUNTER)
> >        |     ^~~~~~~~~~~~~~~~~
> >
> > I worked around it and it next failed with following errors:
> >
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o:
> in
> > function `JvmtiUtil::error_name(int)':
> > make/hotspot/src/hotspot/share/prims/jvmtiUtil.hpp:51: undefined
> reference to `JvmtiUtil::_error_names'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o:
> in
> > function `JvmtiEnvBase::get_phase()':
> > make/hotspot/src/hotspot/share/prims/jvmtiEnvBase.hpp:77: undefined
> reference to `JvmtiEnvBase::_phase'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o:
> in function
> > `JfrPeriodicEventSet::requestJavaAgent()':
> > make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:294:
> undefined reference to `JvmtiAgentList::java_agents()'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o:
> in function
> > `JfrPeriodicEventSet::requestNativeAgent()':
> > make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:314:
> undefined reference to `JvmtiAgentList::native_agents()'
> > /usr/bin/ld:
> make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:316: undefined
> reference to
> > `JvmtiAgentList::xrun_agents()'
> > /usr/bin/ld:
> >
> /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jvmciCompilerToVMInit.o:
>
> > in function `CompilerToVM::Data::initialize(JVMCIEnv*)':
> > make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:212:
> undefined reference to
> > `JvmtiExport::_should_notify_object_alloc'
> > collect2: error: ld returned 1 exit status
> >
> > This is not specific to premain, and I can reproduce it with mainline as
> well. It doesn't look like it is
> > straightforward to remove the jvmti feature. Seems like there may be
> other components (like jfr) missing INCLUDE_JVMTI
> > macro.
> > My suggestion, if you are interested in pursuing it further, would be to
> try and wrinkle out the problems with the
> > mainline first.
> >
> > Meanwhile I will push the changes to use INCLUDE_JVMTI in the premain
> specific code.
> >
> > - Ashutosh Mehra
> >
> >
> > On Mon, Jul 8, 2024 at 11:17?AM Ashutosh Mehra <asmehra at redhat.com
> <mailto:asmehra at redhat.com>> wrote:
> >
> >     Hi Sanne, thanks for reporting this. It looks like a bug. It can be
> fixed by enclosing the relevant code under the
> >     "INCLUDE_JVMTI" macro.
> >
> >     - Ashutosh Mehra
> >
> >
> >     On Mon, Jul 8, 2024 at 9:58?AM Sanne Grinovero <sanne at redhat.com
> <mailto:sanne at redhat.com>> wrote:
> >
> >         Hello all,
> >
> >         I'm experimenting building Leyden locally with non-default
> configurations, with the intent of comparing its
> >         potential as an alternative to GraalVM native-images, and one of
> my goals would be to produce a minimal JVM
> >         build which exclusively includes the components that our
> applications are going to need at runtime.
> >
> >         This implies being very selective with the JVM features I choose
> at configuration time; I've already opened some
> >         minor issues identified during such experiments.
> >
> >         Today I noticed today that if I exclude the "jvmti" feature, the
> premain branch of Leyden doesn't compile:
> >
> >
> >         === Output from failing command(s) repeated here ===
> >         * For target hotspot_variant-custom_libjvm_objs_SCCache.o:
> >         /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:
> In member function ?void
> >         SCAddressTable::init_opto()?:
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3815:39:
> error: ?notify_jvmti_vthread_start? is
> >         not a member of ?OptoRuntime?
> >           3815 |   SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_start());
> >                |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
> >           3511 |     type##_addr[type##_length++] = (address) (addr);
>    \
> >                |                                               ^~~~
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3816:39:
> error: ?notify_jvmti_vthread_end? is not
> >         a member of ?OptoRuntime?
> >           3816 |   SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_end());
> >                |
> ^~~~~~~~~~~~~~~~~~~~~~~~
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
> >           3511 |     type##_addr[type##_length++] = (address) (addr);
>    \
> >                |                                               ^~~~
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3817:39:
> error: ?notify_jvmti_vthread_mount? is
> >         not a member of ?OptoRuntime?
> >           3817 |   SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_mount());
> >                |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
> >           3511 |     type##_addr[type##_length++] = (address) (addr);
>    \
> >                |                                               ^~~~
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3818:39:
> error: ?notify_jvmti_vthread_unmount? is
> >         not a member of ?OptoRuntime?
> >           3818 |   SET_ADDRESS(_C2_blobs,
> OptoRuntime::notify_jvmti_vthread_unmount());
> >                |
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
>  /home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47:
> note: in definition of macro ?SET_ADDRESS?
> >           3511 |     type##_addr[type##_length++] = (address) (addr);
>    \
> >                |                                               ^~~~
> >             ... (rest of output omitted)
> >
> >         I'm wondering if I should open an issue for this case? I
> appreciate it's early days and that such aspects might
> >         not be a priority currently!
> >
> >         Thanks,
> >         Sanne
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240708/4096b7f9/attachment.htm>

From duke at openjdk.org  Mon Jul  8 19:09:13 2024
From: duke at openjdk.org (duke)
Date: Mon, 8 Jul 2024 19:09:13 GMT
Subject: git: openjdk/leyden: premain: Guard JVMTI related code with
 INCLUDE_JVMTI
Message-ID: <9a22a887-23cd-4cad-8184-f4fc9b135f3d@openjdk.org>

Changeset: c49bd56b
Author:    Ashutosh Mehra <asmehra at redhat.com>
Date:      2024-07-08 15:01:40 +0000
URL:       https://git.openjdk.org/leyden/commit/c49bd56b3599da6f1f9d5fffeea4d1887aa9237e

Guard JVMTI related code with INCLUDE_JVMTI

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp


From vladimir.kozlov at oracle.com  Mon Jul  8 19:13:34 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 8 Jul 2024 12:13:34 -0700
Subject: [External] : Re: Build fails when disabling jvmti
In-Reply-To: <CAKt0pyQqckvNhu5N+teJVN+4fW55H_5tWHup82GbC8RrkKGT5g@mail.gmail.com>
References: <CAA5_-WYNzw7zTGbQpUW8bQwPxvWsB7XLQnfqxNJvQgf9VE+c1A@mail.gmail.com>
 <CAKt0pyS4d0aNje42SFqRrR0+VR0vr+i8bfyOhXG4W1zE_F335Q@mail.gmail.com>
 <CAKt0pySY-w0AOJ-uU17T=zV5BkLuGdTVEAGKwEwtXzNmHeaFpQ@mail.gmail.com>
 <46b7af92-9dd4-409f-aaa5-4e1a782308f4@oracle.com>
 <CAKt0pyQqckvNhu5N+teJVN+4fW55H_5tWHup82GbC8RrkKGT5g@mail.gmail.com>
Message-ID: <2499e725-6c86-4ac5-80d8-c99f461123d5@oracle.com>

Thank you for filing bug and fixing premain code.

Thanks,
Vladimir K

On 7/8/24 11:57 AM, Ashutosh Mehra wrote:
> Here is the issue for mainline: https://bugs.openjdk.org/browse/JDK-8335921 <https://bugs.openjdk.org/browse/JDK-8335921>
> 
> - Ashutosh Mehra
> 
> 
> On Mon, Jul 8, 2024 at 2:10?PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Ashutosh, please file bug for mainline hotspot/jvmti component.
> 
>     Thanks,
>     Vladimir K
> 
>     On 7/8/24 9:43 AM, Ashutosh Mehra wrote:
>      > Hi Sanne,
>      > For the record I am able to recreate this issue if I create a custom variant and omit jvmti feature using the
>     following
>      > configure command:
>      >
>      > bash ./configure --with-conf-name=no-jvmti-release
>      > --with-jvm-features=cds,compiler1,compiler2,g1gc,serialgc,jfr,jni-check,jvmci,management,services
>     --with-jvm-variants=custom
>      >
>      > I tried to fix it by enclosing the code in SCCache.cpp with?INCLUDE_JVMTI but the build failed again in premain
>     specific
>      > code with this error:
>      >
>      > /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1804:23: error:
>      > ?_perf_InterpreterRuntime_member_name_arg_or_null_timer? was not declared in this scope; did you mean
>      > ?_perf_InterpreterRuntime_prepare_native_call_timer??
>      >? ?1804 | ? NEWPERFTICKCOUNTERS(_perf_##sub##_##name##_timer, SUN_CI, #sub "::" #name); \
>      >? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ^~~~~~
>      > /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/runtime/perfData.hpp:854:4: note: in definition of macro
>      > ?NEWPERFTICKCOUNTERS?
>      >? ? 854 | ? {counter = PerfDataManager::create_tick_counters(counter_ns, counter_name, counter_name "_elapsed_time", \
>      >? ? ? ? | ? ?^~~~~~~
>      > /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1798:3: note: in
>     expansion of
>      > macro ?INIT_COUNTER?
>      >? ?1798 | ? macro(InterpreterRuntime, member_name_arg_or_null)
>      >? ? ? ? | ? ^~~~~
>      > /home/asmehra/data/ashu-mehra/leyden/src/hotspot/share/interpreter/interpreterRuntime.cpp:1812:5: note: in
>     expansion of
>      > macro ?DO_JVMTI_COUNTERS?
>      >? ?1812 | ? ? DO_JVMTI_COUNTERS(INIT_COUNTER)
>      >? ? ? ? | ? ? ^~~~~~~~~~~~~~~~~
>      >
>      > I worked around it and it next failed with following errors:
>      >
>      > /usr/bin/ld:
>      > /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o: in
>      > function `JvmtiUtil::error_name(int)':
>      > make/hotspot/src/hotspot/share/prims/jvmtiUtil.hpp:51: undefined reference to `JvmtiUtil::_error_names'
>      > /usr/bin/ld:
>      > /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrJvmtiAgent.o: in
>      > function `JvmtiEnvBase::get_phase()':
>      > make/hotspot/src/hotspot/share/prims/jvmtiEnvBase.hpp:77: undefined reference to `JvmtiEnvBase::_phase'
>      > /usr/bin/ld:
>      > /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o: in
>     function
>      > `JfrPeriodicEventSet::requestJavaAgent()':
>      > make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:294: undefined reference to
>     `JvmtiAgentList::java_agents()'
>      > /usr/bin/ld:
>      > /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jfrPeriodic.o: in
>     function
>      > `JfrPeriodicEventSet::requestNativeAgent()':
>      > make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:314: undefined reference to
>     `JvmtiAgentList::native_agents()'
>      > /usr/bin/ld: make/hotspot/src/hotspot/share/jfr/periodic/jfrPeriodic.cpp:316: undefined reference to
>      > `JvmtiAgentList::xrun_agents()'
>      > /usr/bin/ld:
>      >
>     /home/asmehra/data/ashu-mehra/leyden/build/premain-release/hotspot/variant-custom/libjvm/objs/jvmciCompilerToVMInit.o:
>      > in function `CompilerToVM::Data::initialize(JVMCIEnv*)':
>      > make/hotspot/src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp:212: undefined reference to
>      > `JvmtiExport::_should_notify_object_alloc'
>      > collect2: error: ld returned 1 exit status
>      >
>      > This is not specific to premain, and I can reproduce it with mainline as well. It doesn't look like it is
>      > straightforward to remove the jvmti feature. Seems like there may be other components (like jfr) missing
>     INCLUDE_JVMTI
>      > macro.
>      > My suggestion, if you are interested in pursuing it further, would be to try and wrinkle out the problems with the
>      > mainline first.
>      >
>      > Meanwhile I will push the changes to use INCLUDE_JVMTI in the premain specific code.
>      >
>      > - Ashutosh Mehra
>      >
>      >
>      > On Mon, Jul 8, 2024 at 11:17?AM Ashutosh Mehra <asmehra at redhat.com <mailto:asmehra at redhat.com>
>     <mailto:asmehra at redhat.com <mailto:asmehra at redhat.com>>> wrote:
>      >
>      >? ? ?Hi Sanne, thanks for reporting this. It looks like a bug. It can be fixed by enclosing the relevant code
>     under the
>      >? ? ?"INCLUDE_JVMTI" macro.
>      >
>      >? ? ?- Ashutosh Mehra
>      >
>      >
>      >? ? ?On Mon, Jul 8, 2024 at 9:58?AM Sanne Grinovero <sanne at redhat.com <mailto:sanne at redhat.com>
>     <mailto:sanne at redhat.com <mailto:sanne at redhat.com>>> wrote:
>      >
>      >? ? ? ? ?Hello all,
>      >
>      >? ? ? ? ?I'm experimenting building Leyden locally with non-default configurations, with the intent of comparing its
>      >? ? ? ? ?potential as an alternative to GraalVM native-images, and one of my goals would be to produce a minimal JVM
>      >? ? ? ? ?build which exclusively includes the components that our applications are going to need at runtime.
>      >
>      >? ? ? ? ?This implies being very selective with the JVM features I choose at configuration time; I've already
>     opened some
>      >? ? ? ? ?minor issues identified during such experiments.
>      >
>      >? ? ? ? ?Today I noticed today that if I exclude the "jvmti" feature, the premain branch of Leyden doesn't compile:
>      >
>      >
>      >? ? ? ? ?=== Output from failing command(s) repeated here ===
>      >? ? ? ? ?* For target hotspot_variant-custom_libjvm_objs_SCCache.o:
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp: In member function ?void
>      >? ? ? ? ?SCAddressTable::init_opto()?:
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3815:39: error: ?notify_jvmti_vthread_start? is
>      >? ? ? ? ?not a member of ?OptoRuntime?
>      >? ? ? ? ? ?3815 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_start());
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro
>     ?SET_ADDRESS?
>      >? ? ? ? ? ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3816:39: error: ?notify_jvmti_vthread_end?
>     is not
>      >? ? ? ? ?a member of ?OptoRuntime?
>      >? ? ? ? ? ?3816 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_end());
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro
>     ?SET_ADDRESS?
>      >? ? ? ? ? ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3817:39: error: ?notify_jvmti_vthread_mount? is
>      >? ? ? ? ?not a member of ?OptoRuntime?
>      >? ? ? ? ? ?3817 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_mount());
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro
>     ?SET_ADDRESS?
>      >? ? ? ? ? ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3818:39: error:
>     ?notify_jvmti_vthread_unmount? is
>      >? ? ? ? ?not a member of ?OptoRuntime?
>      >? ? ? ? ? ?3818 | ? SET_ADDRESS(_C2_blobs, OptoRuntime::notify_jvmti_vthread_unmount());
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
>      >? ? ? ? ?/home/sanne/sources/leyden/src/hotspot/share/code/SCCache.cpp:3511:47: note: in definition of macro
>     ?SET_ADDRESS?
>      >? ? ? ? ? ?3511 | ? ? type##_addr[type##_length++] = (address) (addr); ? ? ?\
>      >? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^~~~
>      >? ? ? ? ? ? ?... (rest of output omitted)
>      >
>      >? ? ? ? ?I'm wondering if I should open an issue for this case? I appreciate it's early days and that such aspects
>     might
>      >? ? ? ? ?not be a priority currently!
>      >
>      >? ? ? ? ?Thanks,
>      >? ? ? ? ?Sanne
>      >
> 

From duke at openjdk.org  Mon Jul  8 20:26:17 2024
From: duke at openjdk.org (duke)
Date: Mon, 8 Jul 2024 20:26:17 GMT
Subject: git: openjdk/leyden: premain-ea: 2 new changesets
Message-ID: <444a28a9-f2f5-4e77-a0a1-3dcc1d83862a@openjdk.org>

Changeset: f519a8a9
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-06-24 12:23:47 +0000
URL:       https://git.openjdk.org/leyden/commit/f519a8a9a17c077a192dc16893e63d9a832a4bcd

Removed incorrect message "Cannot dump shared archive while using shared archive"

! src/hotspot/share/cds/cdsConfig.cpp

Changeset: c2a5c9ac
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-06 09:36:41 +0000
URL:       https://git.openjdk.org/leyden/commit/c2a5c9acf0b45f852ec885d2ace0247a2b62a759

8335804: ArchiveInvokeDynamic causes BootstrapMethodError

! src/java.base/share/classes/java/lang/invoke/MethodType.java


From ioi.lam at oracle.com  Tue Jul  9 05:32:08 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Mon, 8 Jul 2024 22:32:08 -0700
Subject: Draft JEP 8315737: AOT Linked Classes
In-Reply-To: <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
References: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
 <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
Message-ID: <9e396c07-0fe0-44e5-9b6e-ee0e4eba7eb2@oracle.com>

On 7/8/24 6:52 AM, Volker Simonis wrote:
> The way you describe the manual usage of CDS is "old" and quite
> cumbersome. Why not use the new -XX:+AutoCreateSharedArchive option
> which automatically creates the archive if non is available. Or does
> -XX:+AOTLoadedClasses not work together with
> -XX:+AutoCreateSharedArchive and if so, why not?

-XX:+AutoCreateSharedArchive is for creating dynamic CDS archives only. 
It cannot be used for creating static CDS archives.

-XX:+AOTLoadedClasses works for both dynamic and static CDS archives. 
However, as part of this JEP, to demonstrate its promises, we will also 
implement one significant optimization that relies on 
-XX:+AOTLoadedClasses:

 ??? JDK-8293336 Store LambdaForms in CDS archive heap

JDK-8293336 works only for the static CDS archive (it requires archiving 
Java heap objects, which is not supported by dynamic CDS archives).

Thanks

- Ioi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240708/9d8c7c20/attachment.htm>

From asmehra at redhat.com  Tue Jul  9 14:55:42 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Tue, 9 Jul 2024 10:55:42 -0400
Subject: Save/load StubRoutines
Message-ID: <CAKt0pyQEHXgJnWyE+vhYFejX18B9xdkKCKwuRi8D+U5NWpQS9w@mail.gmail.com>

Hi all,

We have been working for some time on storing and loading generated code
(stubs and blobs) in the hotspot as part of the "premain" project.
The code is now in a good enough shape to be shared with a wider audience
to get some feedback and comments.

So here is the link [0] [1] to the changes for storing and loading of stubs
which are declared in StubRoutines.
This patch covers both aarch64 and x86-64 architectures.
The code changes are done on top of AndrewD's patch for storing the blobs
[2].

---

A brief description of the approach for storing StubRoutines stubs is
warranted as it slightly differs from the technique used for storing other
runtime blobs.

In the mainline StubRoutines are divided into 4 categories depending on
when they are generated and their purpose - initial, continuation, compiler
and final
In comparison to a runtime blob which is stored in its own buffer, a
StubRoutine stub belongs to a category and all the stubs in a category are
stored in the same buffer.
This makes the code buffer storing StubRoutine to have multiple entry
points and these entry points are established as the stubs are generated
during the runtime.
Moreover, the generation of some stubs is dependent on the availability of
certain cpu features.

So when the buffer for a StubRoutine category is stored in the code cache,
some extra information needs to be store to be able to identify all the
entry points
and be able to associate them with the correct stubs when loading the
buffer.

To implement this each stub is given a unique static id irrespective of
whether its code is generated or not (refer to macro STUB_ROUTINES_STUBS_DO
in runtime/stubRoutines.hpp)
When the stubs are generated the entry point(s) of the stubs are stored in
an array (see StubArchiveData::_address_array in
runtime/stubCodeGenerator.hpp).
As the stubs are generated, the entry points are appended to the array.
Most of the stubs have only one entry point.
In addition to the entry point(s), the end address of the stub is also
recorded in the array.
The end address is used to create StubCodeDesc when the stubs are loaded
from the code cache.

To identify the addresses that belong to a stub, we store a tuple of 2
elements for each stub: first element is the index of the first entry point
of the stub in the _address_array
and second element is the number of addresses stored by this stub in the
_address_array (see StubAddrIndexInfo in runtime/stubCodeGenerator.hpp).
For stubs that are not generated, -1 is used for both the elements. These
tuples are stored in an array StubArchiveData::_index_table indexed by the
unique stub id.

It is easier to visualize this using a simple example:
Assume there are 3 stubs. Stub1 has 2 entry points (S1-1 and S1-2) and an
end address (E1). Stub2 is not generated. Stub3 has one entry point (S3-1)
and end address (E3).
For this case the _address_array and _index_table in the StubArchiveData
would have following entries:

_address_array:
index:          0          1      2       3       4
contents: | S1-1 | S1-2 | E1 | S3-1 | E3 |

_index_table:
index:          0        1        0
contents: | 0, 3 | -1, -1 | 3, 2 |

When all the stubs of a category are generated, the _address_array and
_index_table are stored in the code cache (in
SCCache::store_stubroutines_blob).
During load time the code along with the _address_array and _index_table is
read back from the code cache (in SCCReader::compile_stubroutines_blob).
The stubs entry points are set up in their respective routines that
generates the stub (such as generate_call_stub) using the _index_table.

As the stubs are generated, their entry points are also registered with the
SCAddressTable in SCCache.
To preserve the order of the SCAddressTable during load, the elements of
the _address_array are registered when the buffer is loaded (in
SCCReader::compile_stubroutines_blob).

In addition, StubArchiveData also stores the name of the stubs which is
used to verify the code located in the code cache is indeed for the stub
being loaded.

---

Apart from implementing the above approach, this patch also has changes to
move JFR stubs and throw_exception stubs to SharedRuntime and stores/loads
them as a RuntimeStub,
as they seem to be a better fit there.
There are also some minor improvements to logging to trace the stubs
generation and store/load times.

Lastly, the generated code (stubs and blobs) can be controlled using these
two options - StoreStubs and LoadStubs.

Please review the code and provide your feedback. Let us know if any
clarification is required.

There is still scope of improvement. Some of the things that can be done
are:
- In current scheme if a stub is not generated during training run, but
gets generated during the production run, the order of SCAddressTable can
vary resulting in crash/unexpected behavior
- Enum used to enumerate stubs can be improved. AndrewD has the idea of a
global enum that identifies all the stubs/blobs and that can address this
aspect of the patch and the limitation in the previous point as well.
- Exploring other ways to handle external constant data such as tables used
by trigonometric stubs which need to be registered in SCAddressTable very
early. See StubRoutines::stubs_SCAddressTable_init).
- Using InternalAddress (or something similar) relocation type for targets
that are in the same blob, so that they don't need to be fixed on load.


[0] change sets: https://github.com/adinn/leyden/compare/d808ea2..7738ed6
[1] branch: https://github.com/adinn/leyden/commits/premain-stub-routines/
[2] https://github.com/adinn/leyden/commits/premain-save-generated/

Thanks,
- Ashutosh Mehra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240709/d2c4cee6/attachment.htm>

From duke at openjdk.org  Tue Jul  9 20:39:59 2024
From: duke at openjdk.org (duke)
Date: Tue, 9 Jul 2024 20:39:59 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <1c42df19-2386-4807-b3bf-c7dad0128c8a@openjdk.org>

Changeset: 5fdfef1d
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-03 15:53:35 +0000
URL:       https://git.openjdk.org/leyden/commit/5fdfef1df3bbcded1001fd1f0be8cce46d3bb35e

Added more test case for JDK-8317269: Archive old classes in verified state when CDSLoadedClasses is enabled

! test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/PreloadedClassesVerification.java

Changeset: dbdccb37
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-09 11:05:44 +0000
URL:       https://git.openjdk.org/leyden/commit/dbdccb376f3b535736dc4054c36b2159dbdb54dc

8335790: Store protection domains into CDS archive

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveHeapWriter.cpp
! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/cdsProtectionDomain.cpp
! src/hotspot/share/cds/cdsProtectionDomain.hpp
! src/hotspot/share/cds/cds_globals.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/java.base/share/classes/java/security/SecureClassLoader.java
! src/java.base/share/classes/jdk/internal/misc/CDS.java
+ test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchivedProtectionDomains.java


From ioi.lam at oracle.com  Tue Jul  9 21:00:30 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 9 Jul 2024 14:00:30 -0700
Subject: [External] : Re: Hello from JRuby and here's another crash
In-Reply-To: <CAE-f1xRn_Lh0=zRp5=fO0ek=xoV2iqNzyagTAD9nG43JuXaz=Q@mail.gmail.com>
References: <CAE-f1xSYcJudwYQUSZQxzU2nvqXnUSHLgQ69STYGMwJjsUKcsQ@mail.gmail.com>
 <9e008170-7348-410b-9ecb-753101367181@oracle.com>
 <CAE-f1xRn_Lh0=zRp5=fO0ek=xoV2iqNzyagTAD9nG43JuXaz=Q@mail.gmail.com>
Message-ID: <6c4cb877-e702-4f28-a0ab-af0d709efa1f@oracle.com>


On 7/8/24 9:04 AM, Charles Oliver Nutter wrote:
> The patched build does indeed work, and cuts JRuby's base startup time 
> by 50%! Bravo!
>
> $ time jruby -e 1
> jruby -e 1 ?3.53s user 0.14s system 276% cpu 1.326 total
> $ time jruby -J-XX:CacheDataStore=jruby.cds -e 1
> jruby -J-XX:CacheDataStore=jruby.cds -e 1 ?2.38s user 0.19s system 
> 385% cpu 0.667 total
>
> This is a very promising start and the largest single improvement we 
> have seen. Comparison with our previous champion, C1:
>
> $ time jruby --dev -e 1
> jruby --dev -e 1 ?1.22s user 0.09s system 142% cpu 0.922 total
>
> Interestingly, when I try to use the previously trained CDS dump (via 
> 100.times { org.jruby.Ruby.newInstance }) with a command line that 
> forces C1 (--dev flag passes -XX:TieredStopAtLevel=1) I get a 
> different crash: 
> https://gist.github.com/headius/d3138efa52eed9c678414c8cfe08af27 
> <https://urldefense.com/v3/__https://gist.github.com/headius/d3138efa52eed9c678414c8cfe08af27__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTom1wRsn5A$>
>
I filed https://bugs.openjdk.org/browse/JDK-8336033 . It looks like a 
simple book keeping issue in the compiler code.


> I'm wondering what else I can do to try to train the CDS dump better, 
> so that a larger command (jruby -S gem list) sees more improvement 
> (this loads a bunch more Ruby code into the interpreter):
>
> $ time jruby -S gem list > /dev/null
> jruby -S gem list > /dev/null ?6.41s user 0.26s system 236% cpu 2.821 
> total
> $ time jruby -J-XX:CacheDataStore=jruby.cds -S gem list > /dev/null
> jruby -J-XX:CacheDataStore=jruby.cds -S gem list > /dev/null ?5.84s 
> user 0.32s system 294% cpu 2.089 total
>

Does this load a lot of dynamically generated classes? The current set 
of Leyden optimizations are mostly for classes loaded in the built-in 
loaders (boot/platform/app).

I wonder how much of the time is spend in one-time activity. If you run 
the above inside a loop (2x, 4x, 8x, 16x, etc), how does it scale?

I think if we see a big drop between 1x vs 2x, then perhaps the current 
set of Leyden optimizations can help (as long as most of the time is 
spent in the built-in loaders).

In any case, dynamic language runtimes like jruby probably have very 
different start-up characteristics than, say, your typical "micro 
service" Java app. More analysis is needed.

Thanks

- Ioi


> - Charlie
>
> On Thu, Jul 4, 2024 at 11:50?PM <ioi.lam at oracle.com> wrote:
>
>     Hi Charlie,
>
>     Thanks for the bug report.
>
>     It turns out some Leyden optimizations can't handle the module
>     options specified by jruby, such as these:
>
>     ??? --add-opens=java.base/java.nio.channels=org.jruby.dist
>     ??? --module-path=/xxxx/jruby-9.4.8.0/lib/jruby.jar
>
>     I filed https://bugs.openjdk.org/browse/JDK-8335735
>
>     I'll work on a proper fix. Meanwhile, I have a work-around in this
>     branch
>
>     https://github.com/iklam/jdk/tree/work-around-8335735-jruby-crash-due-to-lack-of-module-support
>     <https://urldefense.com/v3/__https://github.com/iklam/jdk/tree/work-around-8335735-jruby-crash-due-to-lack-of-module-support__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTomY2MJITU$>
>
>     If you build a JDK from this source branch, you can see the
>     following improvements:
>
>     # [1] No optimizations
>     $ time env JAVA_HOME=$MYJAVA
>     ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>     ??? -e '10.times { org.jruby.Ruby.newInstance }'
>     real?? 0m3.215s
>     user?? 0m14.868s
>     sys??? 0m0.373s
>
>
>     # [2] Leyden
>     $ time env JAVA_HOME=$TBP0 ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>     ??? -J-XX:CacheDataStore=jruby.cds \
>     ??? -e '10.times { org.jruby.Ruby.newInstance }'
>     real?? 0m1.880s
>     user?? 0m9.001s
>     sys??? 0m0.268s
>
>
>     # [3] Compare with CDS in the JDK mainline
>     $ env JAVA_HOME=$MYJAVA ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>     ???? -J-XX:DumpLoadedClassList=jruby.classlist \
>     ???? -e '10.times { org.jruby.Ruby.newInstance }'
>     $ $MYJAVA/bin/java -Xshare:dump \
>     --module-path=/home/iklam/Downloads/ruby/jruby-9.4.8.0/lib/jruby.jar \
>     ??? -XX:SharedClassListFile=jruby.classlist \
>     ??? -XX:SharedArchiveFile=jruby.jsa -Xlog:cds
>     $ time env JAVA_HOME=$MYJAVA
>     ~/Downloads/ruby/jruby-9.4.8.0/bin/jruby \
>     ??? -J-XX:SharedArchiveFile=jruby.jsa \
>     ??? -e '10.times { org.jruby.Ruby.newInstance }'
>     real?? 0m2.628s
>     user?? 0m13.007s
>     sys??? 0m0.428s
>
>     Please try it out and let us know if you run into other problems.
>
>     Thanks
>
>     - Ioi
>
>
>     On 7/4/24 1:06 PM, Charles Oliver Nutter wrote:
>>     Hello friends! Long time lurker, first time poster.
>>
>>     Like others I was excited to hear that the first EA of Leyden had
>>     dropped. Sadly, I have another crash to report.
>>
>>     I see there are two other crashes reported, but mine appears
>>     different (ClassPrelinker::is_indy_resolution_deterministic):
>>
>>     https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24
>>     <https://urldefense.com/v3/__https://gist.github.com/headius/79c6460ed55c1d80c82e1c0209897e24__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTomO4igb9c$>
>>
>>     Perhaps unsurprisingly, the additional flags provided by Vladimir
>>     Kozlov (-XX:+UnlockDiagnosticVMOptions
>>     -XX:-ReduceAllocationMerges) did not appear to change the result.
>>
>>     This is with JRuby's minimally invokedynamic-based mode, which
>>     has given us the shortest startup time in the past (second only
>>     to disabling tiers 2-4 and staying in C1).
>>
>>     I am on MacOS AArch64 Sonoma 14.5, testing against JRuby master,
>>     but reproduction should be as easy as downloading the JRuby
>>     binary tarball, unpacking, and running bin/jruby with the command
>>     line above.
>>
>>     https://www.jruby.org/download
>>     <https://urldefense.com/v3/__https://www.jruby.org/download__;!!ACWV5N9M2RV99hQ!O1UAeB7nD1zEm6bMPw7oDGNPEmvkkh6jK5YVmZJVKQP6Ugi5tSURjYzIpMvg0XmXhF6oaTom4BSxN20$>
>>
>>     I am eager to work with Leyden folks to investigate issues, and I
>>     am planning to be at JVMLS this year to discuss collaborating more!
>>
>>     - Charlie
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240709/bbba94d5/attachment.htm>

From john.r.rose at oracle.com  Tue Jul  9 22:01:33 2024
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 09 Jul 2024 15:01:33 -0700
Subject: Draft JEP 8315737: AOT Linked Classes
In-Reply-To: <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
References: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
 <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
Message-ID: <1B43ED68-F6B6-497E-B071-9F9E02EAE516@oracle.com>

On 8 Jul 2024, at 6:52, Volker Simonis wrote:

> Hi Jon,
>
> Thanks for the update and great to see this moving forward.

Wow, thank you for the excellent comments and suggestions.

> After reading the full JEP it became evident that  "Cached Data
> Storage" is actually an extension of the existing and well known
> "Class Data Sharing" feature. However, the current description
> introduces "CDS" (which is the well known acronym for "Class Data
> Sharing" since JDK 5 times [1]) as "Cached Data Storage". This is
> surprising and confusing for everybody already familiar with the
> existing "CDS" feature. I'd therefore suggest to move the very last
> sentence of the JEP to the very beginning.

The flow of the JEP is designed for the majority of folks, to whom CDS is a new thing.  So I won?t be adding extra detail up there.  But I did put some more explanation further down, and added a link from the first paragraph to that explanatory section.

> Another point I think the JEP should address in some more detail is
> the effect of "Cached Data Storage" on the overall memory footprint of
> the JVM process. The classic "Class Data Sharing" already slightly
> increased the memory footprint of the JVM and only amortized if more
> than one JVM used the same CDS archive at runtime. Please describe the
> effects of the new "Cached Data Storage" on memory footprint.

I wrote a paragraph on this but then decided it was too much information for this JEP.  There probably already too much in there.

Here?s what I wrote and then deleted:

>> Historically, CDS has a secondary goal of reducing footprint by sharing CDS file pages across VM processes.  The present work does not modify this goal.  It should be noticed, however, that modern CDS deployments often lose much of their sharing due to dynamic relocations, because mapping addresses are made unpredictable by current practices such as ASLR.  With any AOT technology like CDS, there is always a tension between either under-provisioning, which may force VM startup to consume more CPU as it repeats work, or else over-provisioning, which may cause unused resources to be consume memory.  Future work may further address these tradeoffs.

There?s only so many times you can say ?yeah, we know about that, and trust us, we want to get around to it?.  Note the Non-Goals section as well.  I don?t think footprint needs its own entry there either.

> Finally some minor text corrections:

Many thanks!

? John

From volker.simonis at gmail.com  Wed Jul 10 13:41:00 2024
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 10 Jul 2024 15:41:00 +0200
Subject: Draft JEP 8315737: AOT Linked Classes
In-Reply-To: <9e396c07-0fe0-44e5-9b6e-ee0e4eba7eb2@oracle.com>
References: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
 <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
 <9e396c07-0fe0-44e5-9b6e-ee0e4eba7eb2@oracle.com>
Message-ID: <CA+3eh119VHVKBNSrHYyYfuXMoSK9b9ysBUOx8MzHRLJAya5bYQ@mail.gmail.com>

Hi Ioi,

Thanks for the clarification. I wasn't aware of the fact, that only
static CDS archives can contain archived heap objects. The official
CDS documentation [1] is also not mentioning this. In contrary, it
states that:

> The names "static" and "dynamic" are used for historical reasons. The only significance is that the "static" archive is loaded first and the "dynamic" archive is loaded second.

So maybe that documentation should be updated to make it clear that
static CDS archives are more powerful?

Is there a conceptual reason for why dynamic archives can not contain
heap objects or is this just an implementation issue that could be
solved? Maybe because G1 can currently only map a single heap region
from file?

Thank you and best regards,
Volker

[1] https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing

On Tue, Jul 9, 2024 at 7:32?AM <ioi.lam at oracle.com> wrote:
>
> On 7/8/24 6:52 AM, Volker Simonis wrote:
>
> The way you describe the manual usage of CDS is "old" and quite
> cumbersome. Why not use the new -XX:+AutoCreateSharedArchive option
> which automatically creates the archive if non is available. Or does
> -XX:+AOTLoadedClasses not work together with
> -XX:+AutoCreateSharedArchive and if so, why not?
>
> -XX:+AutoCreateSharedArchive is for creating dynamic CDS archives only. It cannot be used for creating static CDS archives.
>
> -XX:+AOTLoadedClasses works for both dynamic and static CDS archives. However, as part of this JEP, to demonstrate its promises, we will also implement one significant optimization that relies on -XX:+AOTLoadedClasses:
>
>     JDK-8293336 Store LambdaForms in CDS archive heap
>
> JDK-8293336 works only for the static CDS archive (it requires archiving Java heap objects, which is not supported by dynamic CDS archives).
>
> Thanks
>
> - Ioi

From duke at openjdk.org  Wed Jul 10 17:32:54 2024
From: duke at openjdk.org (duke)
Date: Wed, 10 Jul 2024 17:32:54 GMT
Subject: git: openjdk/leyden: premain: 8336033: [premain] assert(comp !=
 nullptr) when using SCCache with -XX:TieredStopAtLevel=1
Message-ID: <a46fbfcc-48a4-4732-8970-b30051193d97@openjdk.org>

Changeset: f65cccf9
Branch: premain
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-07-10 10:30:09 +0000
URL:       https://git.openjdk.org/leyden/commit/f65cccf90853d2bfb7de533bab5a3b1fc1672101

8336033: [premain] assert(comp != nullptr) when using SCCache with -XX:TieredStopAtLevel=1

! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/compiler/compilationPolicy.cpp


From duke at openjdk.org  Wed Jul 10 18:25:01 2024
From: duke at openjdk.org (duke)
Date: Wed, 10 Jul 2024 18:25:01 GMT
Subject: git: openjdk/leyden: premain: Add option to omit archive heap
 verification
Message-ID: <e5b8214a-2f59-4516-bfcf-44e948de8613@openjdk.org>

Changeset: 5545aa0c
Branch: premain
Author:    Ashutosh Mehra <asmehra at redhat.com>
Date:      2024-07-10 14:21:46 +0000
URL:       https://git.openjdk.org/leyden/commit/5545aa0cb9669f46e5ae55086cc3e785b664baf0

Add option to omit archive heap verification

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

! src/hotspot/share/cds/cds_globals.hpp
! src/hotspot/share/cds/heapShared.cpp


From duke at openjdk.org  Wed Jul 10 19:25:30 2024
From: duke at openjdk.org (duke)
Date: Wed, 10 Jul 2024 19:25:30 GMT
Subject: git: openjdk/leyden: premain-ea: 8336033: [premain] assert(comp !=
 nullptr) when using SCCache with -XX:TieredStopAtLevel=1
Message-ID: <8caa9dda-98a8-40e9-a383-3a4ca8d9db61@openjdk.org>

Changeset: 4c385b55
Branch: premain-ea
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-07-10 12:24:44 +0000
URL:       https://git.openjdk.org/leyden/commit/4c385b55ad96e049182beda3a0ac78c2914b4e95

8336033: [premain] assert(comp != nullptr) when using SCCache with -XX:TieredStopAtLevel=1

! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/compiler/compilationPolicy.cpp


From duke at openjdk.org  Wed Jul 10 20:09:25 2024
From: duke at openjdk.org (duke)
Date: Wed, 10 Jul 2024 20:09:25 GMT
Subject: git: openjdk/leyden: premain-ea: Cache few stubs on aarch64 similar to
 x64 to avoid empty cached code
Message-ID: <ba636fc7-c446-4ef0-97bc-2a6d31cd6dde@openjdk.org>

Changeset: d47557ad
Branch: premain-ea
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-07-10 13:08:17 +0000
URL:       https://git.openjdk.org/leyden/commit/d47557adf843bea792ca45b45502ba8748e0c6ad

Cache few stubs on aarch64 similar to x64 to avoid empty cached code

! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp


From duke at openjdk.org  Wed Jul 10 22:29:33 2024
From: duke at openjdk.org (duke)
Date: Wed, 10 Jul 2024 22:29:33 GMT
Subject: git: openjdk/leyden: premain-ea: 8336144:
 assert(CDSConfig::is_dumping_invokedynamic()) when ZGC is used during archive
 creation
Message-ID: <30b89ebc-c05f-47a7-9812-819c5a04a493@openjdk.org>

Changeset: 1b665a99
Branch: premain-ea
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-10 15:28:16 +0000
URL:       https://git.openjdk.org/leyden/commit/1b665a998a9f15105fbf6b8e56868e895e8d373a

8336144: assert(CDSConfig::is_dumping_invokedynamic()) when ZGC is used during archive creation

! src/hotspot/share/cds/heapShared.cpp


From ioi.lam at oracle.com  Wed Jul 10 22:43:29 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Wed, 10 Jul 2024 15:43:29 -0700
Subject: [External] : Re: Draft JEP 8315737: AOT Linked Classes
In-Reply-To: <CA+3eh119VHVKBNSrHYyYfuXMoSK9b9ysBUOx8MzHRLJAya5bYQ@mail.gmail.com>
References: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
 <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
 <9e396c07-0fe0-44e5-9b6e-ee0e4eba7eb2@oracle.com>
 <CA+3eh119VHVKBNSrHYyYfuXMoSK9b9ysBUOx8MzHRLJAya5bYQ@mail.gmail.com>
Message-ID: <68e54b4e-5cb8-423c-a5ec-ea9ab4397ff9@oracle.com>


On 7/10/24 6:41 AM, Volker Simonis wrote:
> Hi Ioi,
>
> Thanks for the clarification. I wasn't aware of the fact, that only
> static CDS archives can contain archived heap objects. The official
> CDS documentation [1] is also not mentioning this. In contrary, it
> states that:
>
>> The names "static" and "dynamic" are used for historical reasons. The only significance is that the "static" archive is loaded first and the "dynamic" archive is loaded second.
> So maybe that documentation should be updated to make it clear that
> static CDS archives are more powerful?

I have filed https://bugs.openjdk.org/browse/JDK-8336147


> Is there a conceptual reason for why dynamic archives can not contain
> heap objects or is this just an implementation issue that could be
> solved? Maybe because G1 can currently only map a single heap region
> from file?

The reasons that heap objects cannot be stored in the dynamic archive:

- The dynamic dump happens at the end of program execution. GC might 
have moved the objects around. If there?s a reference from the 
achievable objects from the dynamic archive that points to the 
archivable objects in the static archive, keeping track of that is 
difficult.

- The dynamic run may mutate objects in the static archive. For example, 
for invokedynamic support, if we have a MethodType for a class in the 
dynamic archive, this MT needs to be entered into a global hashtable 
that?s rooted in the static archive 
(java.lang.invoke.MethodType::internTable).

Instead of just fixing the 2-level problem between static and dynamic 
archives, folks like John Rose and Dan Heidinga are working on general 
designs that would support multiple groups of archived heap objects that 
have cross references between these groups.

In the near future, Leyden optimization will be based on the static 
archive only, as many optimizations rely on snapshots of heap objects.


Thanks

- Ioi



>
> Thank you and best regards,
> Volker
>
> [1] https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing
>
> On Tue, Jul 9, 2024 at 7:32?AM <ioi.lam at oracle.com> wrote:
>> On 7/8/24 6:52 AM, Volker Simonis wrote:
>>
>> The way you describe the manual usage of CDS is "old" and quite
>> cumbersome. Why not use the new -XX:+AutoCreateSharedArchive option
>> which automatically creates the archive if non is available. Or does
>> -XX:+AOTLoadedClasses not work together with
>> -XX:+AutoCreateSharedArchive and if so, why not?
>>
>> -XX:+AutoCreateSharedArchive is for creating dynamic CDS archives only. It cannot be used for creating static CDS archives.
>>
>> -XX:+AOTLoadedClasses works for both dynamic and static CDS archives. However, as part of this JEP, to demonstrate its promises, we will also implement one significant optimization that relies on -XX:+AOTLoadedClasses:
>>
>>      JDK-8293336 Store LambdaForms in CDS archive heap
>>
>> JDK-8293336 works only for the static CDS archive (it requires archiving Java heap objects, which is not supported by dynamic CDS archives).
>>
>> Thanks
>>
>> - Ioi

From duke at openjdk.org  Thu Jul 11 06:31:34 2024
From: duke at openjdk.org (duke)
Date: Thu, 11 Jul 2024 06:31:34 GMT
Subject: git: openjdk/leyden: premain: 192 new changesets
Message-ID: <c3df7d7e-433f-4bcc-a3c8-4ba29cb1b599@openjdk.org>

Changeset: 31e8deba
Branch: premain
Author:    Liming Liu <limingliu at os.amperecomputing.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-17 06:16:26 +0000
URL:       https://git.openjdk.org/leyden/commit/31e8debae63e008da79e403bcb870a7be631af2c

8324781: runtime/Thread/TestAlwaysPreTouchStacks.java failed with Expected a higher ratio between stack committed and reserved
8325218: gc/parallel/TestAlwaysPreTouchBehavior.java fails

Reviewed-by: stefank, jsjolen, stuefe

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/gc/parallel/TestAlwaysPreTouchBehavior.java
! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java

Changeset: 29b63928
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-06-17 06:58:55 +0000
URL:       https://git.openjdk.org/leyden/commit/29b63928387a8b6ab387057cb3eac4771b1bfff1

8334228: C2 SuperWord: fix JDK-24 regression in VPointer::cmp_for_sort after JDK-8325155

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/vectorization.cpp
+ test/hotspot/jtreg/compiler/vectorization/TestOffsetSorting.java

Changeset: 7b38bfea
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-06-17 07:00:03 +0000
URL:       https://git.openjdk.org/leyden/commit/7b38bfea331437ad99277032de7fce939303abc8

8333729: C2 SuperWord: remove some @requires usages in test/hotspot/jtreg/compiler/loopopts/superword

Reviewed-by: chagedorn, kvn

! test/hotspot/jtreg/compiler/loopopts/superword/CoLocatePackMemoryState.java
! test/hotspot/jtreg/compiler/loopopts/superword/RedTest_long.java
! test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVector.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestAlignVectorFuzzer.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestCyclicDependency.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestDependencyOffsets.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestGeneralizedReductions.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestIndependentPacksWithCyclicDependency2.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestLargeCompilation.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestLargeScaleAndStride.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestMovingLoadBeforeStore.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestMulAddS2I.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestPeeledReductionNode.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestPickFirstMemoryState.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestPickLastMemoryState.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestScheduleReordersScalarMemops.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestSplitPacks.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReduction.java
! test/hotspot/jtreg/compiler/loopopts/superword/TestUnorderedReductionPartialVectorization.java
! test/hotspot/jtreg/compiler/loopopts/superword/Vec_MulAddS2I.java

Changeset: 5e09397b
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-17 08:06:20 +0000
URL:       https://git.openjdk.org/leyden/commit/5e09397bf6244c98204180f53a2891604d2843d1

8334222: exclude containers/cgroup/PlainRead.java

Reviewed-by: lucy

! test/hotspot/jtreg/ProblemList.txt

Changeset: d751441b
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-06-17 08:23:39 +0000
URL:       https://git.openjdk.org/leyden/commit/d751441b76ef41880c77b48372c491f9558f1c68

8330586: GHA: Drop additional gcc/glibc packages installation for x86_32

Reviewed-by: ihse

! .github/workflows/main.yml

Changeset: 113a2c02
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-17 08:57:57 +0000
URL:       https://git.openjdk.org/leyden/commit/113a2c028dc3b9abb6229d5f0b812b54a9b61011

8332903: ubsan: opto/output.cpp:1002:18: runtime error: load of value 171, which is not a valid value for type 'bool'

Reviewed-by: kvn, mdoerr

! src/hotspot/cpu/ppc/ppc.ad

Changeset: 0d1080d1
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-06-17 09:30:48 +0000
URL:       https://git.openjdk.org/leyden/commit/0d1080d194c596dc74dd8b173b18b14cc71e1b52

8331117: [PPC64] secondary_super_cache does not scale well

Reviewed-by: rrich, amitkumar

! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp
! src/hotspot/cpu/ppc/vm_version_ppc.cpp
! src/hotspot/cpu/ppc/vm_version_ppc.hpp

Changeset: ef7923e1
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-06-17 11:35:41 +0000
URL:       https://git.openjdk.org/leyden/commit/ef7923e1277ce86c6e5331871f1031c28bf82e31

8334078: RISC-V: TestIntVect.java fails after JDK-8332153 when running without RVV

Reviewed-by: fyang, mli

! src/hotspot/os_cpu/linux_riscv/vm_version_linux_riscv.cpp
! test/hotspot/jtreg/compiler/c2/cr7200264/TestIntVect.java
! test/hotspot/jtreg/compiler/c2/irTests/TestVectorizeURShiftSubword.java
! test/hotspot/jtreg/compiler/intrinsics/TestBitShuffleOpers.java
! test/hotspot/jtreg/compiler/intrinsics/chacha/TestChaCha20.java
! test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java
! test/hotspot/jtreg/compiler/vectorapi/reshape/TestVectorCastRVV.java
! test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java
! test/hotspot/jtreg/compiler/vectorization/runner/ArrayShiftOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicByteOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicCharOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicIntOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicLongOpTest.java
! test/hotspot/jtreg/compiler/vectorization/runner/BasicShortOpTest.java

Changeset: cdf22b13
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-06-17 12:57:09 +0000
URL:       https://git.openjdk.org/leyden/commit/cdf22b13204456b589349500bef0e9d48af44e83

8326715: ZGC: RunThese24H fails with ExitCode 139 during shutdown

Reviewed-by: egahlin

! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp
! src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp
+ src/hotspot/share/jfr/recorder/storage/jfrReferenceCountedStorage.cpp
+ src/hotspot/share/jfr/recorder/storage/jfrReferenceCountedStorage.hpp
! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.cpp
! src/hotspot/share/jfr/support/jfrDeprecationEventWriter.hpp
! src/hotspot/share/jfr/support/jfrDeprecationManager.cpp
! src/hotspot/share/jfr/support/jfrDeprecationManager.hpp

Changeset: c94af6f9
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-06-17 15:50:55 +0000
URL:       https://git.openjdk.org/leyden/commit/c94af6f943c179553d1827550847b93491d47506

8333962: Obsolete OldSize

Reviewed-by: dholmes, zgu

! src/hotspot/share/gc/serial/tenuredGeneration.cpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shared/genArguments.cpp
! src/hotspot/share/gc/shared/genArguments.hpp
! src/hotspot/share/runtime/arguments.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! test/hotspot/gtest/gc/shared/test_collectorPolicy.cpp
! test/hotspot/jtreg/gc/arguments/TestMaxHeapSizeTools.java
! test/hotspot/jtreg/gc/arguments/TestMaxNewSize.java
! test/hotspot/jtreg/gc/g1/TestInvalidateArrayCopy.java
! test/hotspot/jtreg/gc/g1/plab/lib/PLABUtils.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/hotspot/jtreg/vmTestbase/gc/huge/quicklook/largeheap/MemOptions/MemOptionsTest.java
! test/jdk/jdk/jfr/event/runtime/TestSizeTFlags.java
! test/jdk/sun/tools/jhsdb/heapconfig/JMapHeapConfigTest.java

Changeset: 801bf15f
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-17 17:27:01 +0000
URL:       https://git.openjdk.org/leyden/commit/801bf15f02ca47c3547eb677079d7d2f3af1de8c

8332105: Exploded JDK does not include CDS

Reviewed-by: dholmes, iklam

! src/hotspot/share/prims/whitebox.cpp
! test/hotspot/jtreg/runtime/CompressedOops/CompressedCPUSpecificClassSpaceReservation.java

Changeset: ba5a4670
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-06-17 19:37:32 +0000
URL:       https://git.openjdk.org/leyden/commit/ba5a4670b8ad86fefb41a939752754bf36aac9dc

8332854: Unable to build openjdk with --with-harfbuzz=system

Reviewed-by: jwaters, erikj, jdv, ihse

! make/modules/java.desktop/lib/ClientLibraries.gmk

Changeset: e95f0928
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-06-18 05:24:33 +0000
URL:       https://git.openjdk.org/leyden/commit/e95f092862307c248bbd93e7026cbd92053fb4c9

8333964: RISC-V: C2: Check "requires_strict_order" flag for floating-point add reduction

Reviewed-by: fyang

! src/hotspot/cpu/riscv/riscv_v.ad
! test/hotspot/jtreg/compiler/loopopts/superword/TestVectorFPReduction.java
! test/hotspot/jtreg/compiler/vectorapi/TestVectorAddMulReduction.java

Changeset: 0199fee4
Branch: premain
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2024-06-18 06:48:26 +0000
URL:       https://git.openjdk.org/leyden/commit/0199fee431e0dccdd570b38595ea29c760dbed44

8333639: ubsan: cppVtables.cpp:81:55: runtime error: index 14 out of bounds for type 'long int [1]'

Reviewed-by: aboldtch, mbaesken, kbarrett

! src/hotspot/share/cds/cppVtables.cpp

Changeset: 99fefec0
Branch: premain
Author:    Christian Stein <cstein at openjdk.org>
Date:      2024-06-18 07:25:17 +0000
URL:       https://git.openjdk.org/leyden/commit/99fefec092f49cd759f93aa75e008cfa06d2a183

8331431: Update to use jtreg 7.4

Reviewed-by: ihse, erikj, jpai

! make/autoconf/lib-tests.m4
! make/conf/github-actions.conf
! make/conf/jib-profiles.js
! test/hotspot/jtreg/TEST.ROOT
! test/jaxp/TEST.ROOT
! test/jdk/TEST.ROOT
! test/langtools/TEST.ROOT
! test/lib-test/TEST.ROOT

Changeset: 0665195e
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-06-18 08:27:26 +0000
URL:       https://git.openjdk.org/leyden/commit/0665195e59889c3f8dc5ade6521d6ca2eb4ca8b4

8334293: G1: Refactor G1ConcurrentMark::update_top_at_rebuild_start

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/g1/g1ConcurrentMark.inline.hpp
! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp
! src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.hpp

Changeset: b42fe86e
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-06-18 08:33:02 +0000
URL:       https://git.openjdk.org/leyden/commit/b42fe86e817ec6975c869f46922797f546734ee0

8334097: Parallel: Obsolete HeapFirstMaximumCompactionCount

Reviewed-by: tschatzl, dholmes

! src/hotspot/share/gc/parallel/parallel_globals.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/runtime/arguments.cpp

Changeset: d4c13737
Branch: premain
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-06-18 08:42:44 +0000
URL:       https://git.openjdk.org/leyden/commit/d4c13737171b7ab7a8a29a69fa9965f8363c5aee

8334043: VerifyError when inner class is accessed in prologue

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/langtools/tools/javac/SuperInit/EarlyAssignments.java
! test/langtools/tools/javac/SuperInit/EarlyAssignments.out

Changeset: 614b99a8
Branch: premain
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Date:      2024-06-18 09:48:31 +0000
URL:       https://git.openjdk.org/leyden/commit/614b99a8f8360dc0a6a018f06fb336c6883f0f4a

8334442: Temporarily disable return type assertion to reduce noise in testing

Reviewed-by: thartmann, chagedorn

! src/hotspot/share/opto/parse1.cpp

Changeset: 472b935b
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Pavel Rappo <prappo at openjdk.org>
Date:      2024-06-18 10:24:43 +0000
URL:       https://git.openjdk.org/leyden/commit/472b935b442f7f925b665c7de91eda77f3dcbe8b

8334332: TestIOException.java fails if run by root

Reviewed-by: prappo

! test/langtools/jdk/javadoc/doclet/testIOException/TestIOException.java

Changeset: fa401f37
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-06-18 12:08:57 +0000
URL:       https://git.openjdk.org/leyden/commit/fa401f37dffe7bde27e562065dfd24381d5237cc

8333805: Replaying compilation with null static final fields results in a crash

Reviewed-by: thartmann, dlong

! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciReplay.cpp
+ test/hotspot/jtreg/compiler/ciReplay/TestNullStaticField.java

Changeset: e681b4e9
Branch: premain
Author:    nibjen <jena.nibedita at oracle.com>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2024-06-18 13:28:37 +0000
URL:       https://git.openjdk.org/leyden/commit/e681b4e9b3ae24f45d8c6adab4105df39e6b8a92

8332524: Instead of printing "TLSv1.3," it is showing "TLS13"

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/ClientHello.java

Changeset: 91bd85d6
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-06-18 13:51:50 +0000
URL:       https://git.openjdk.org/leyden/commit/91bd85d65dff9cea91b88da7ef241be5c7b85f94

8333854: IllegalAccessError with proxies after JDK-8332457

Reviewed-by: redestad, asotona

! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
+ test/jdk/java/lang/reflect/Proxy/NonPublicMethodTypeTest.java

Changeset: 8bc2fbe5
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-18 14:05:11 +0000
URL:       https://git.openjdk.org/leyden/commit/8bc2fbe57893b110fdb5fd567df4615e7833e5ae

8333769: Pretouching tests dont test pretouching

Reviewed-by: stuefe, asmehra

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/os.hpp
+ test/hotspot/jtreg/gc/TestAlwaysPreTouchBehavior.java
- test/hotspot/jtreg/gc/parallel/TestAlwaysPreTouchBehavior.java
! test/lib/jdk/test/whitebox/WhiteBox.java

Changeset: 6f860f8f
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-06-18 14:48:46 +0000
URL:       https://git.openjdk.org/leyden/commit/6f860f8f6f69369130ed79e71255005b5beed45a

8334430: Clean up nativeInst_x86.*

Reviewed-by: jwaters, jiefu

! src/hotspot/cpu/x86/nativeInst_x86.cpp
! src/hotspot/cpu/x86/nativeInst_x86.hpp

Changeset: e965d70a
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-06-18 16:15:09 +0000
URL:       https://git.openjdk.org/leyden/commit/e965d70a7425bec78620a2ca8bfaca3c392edf6a

8333876: C2 SuperWord: regression after JDK-8325155: failed: internal connection

Reviewed-by: kvn, roland

! src/hotspot/share/opto/superword.cpp
+ test/hotspot/jtreg/compiler/loopopts/superword/TestParallelReduction.java

Changeset: 2ce85d96
Branch: premain
Author:    Alisen Chung <achung at openjdk.org>
Date:      2024-06-18 21:31:16 +0000
URL:       https://git.openjdk.org/leyden/commit/2ce85d96352cef4910cb6a5c2d9b174ca9d8a4e4

8291472: [macos] jawt 1.4 lock/unlock not supported

Reviewed-by: serb

! src/java.desktop/macosx/native/libjawt/jawt.m

Changeset: e227c7e3
Branch: premain
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-06-18 23:23:39 +0000
URL:       https://git.openjdk.org/leyden/commit/e227c7e37d4de0656f013f3a936b1acfa56cc2e0

8334258: Compiler erronousely allows access to instance variable in argument expression of a constructor invocation

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
+ test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview1.java
+ test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview1.out
+ test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview2.java
+ test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview2.out
+ test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview3.java
+ test/langtools/tools/javac/SuperInit/EarlyAssignmentNoPreview3.out

Changeset: 48621ae1
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-06-19 06:45:04 +0000
URL:       https://git.openjdk.org/leyden/commit/48621ae193ef70b2fae4dcb7ddc524f349beb131

8331168: Introduce PredicateEntryIterator to iterate through predicate entries

Reviewed-by: roland, kvn

! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/loopopts.cpp
! src/hotspot/share/opto/predicates.cpp
! src/hotspot/share/opto/predicates.hpp

Changeset: 2165a053
Branch: premain
Author:    Yudi Zheng <yzheng at openjdk.org>
Date:      2024-06-19 09:04:12 +0000
URL:       https://git.openjdk.org/leyden/commit/2165a053e8bf56220af8ef1ef50708364f555931

8334399: [JVMCI] Implement JVMCICompiler::is_intrinsic_supported

Reviewed-by: dnsimon

! src/hotspot/share/jvmci/jvmciCompiler.cpp
! src/hotspot/share/jvmci/jvmciCompiler.hpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/jvmci/jvmciEnv.hpp
! src/hotspot/share/jvmci/jvmciJavaClasses.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/jvmciRuntime.hpp
! src/hotspot/share/jvmci/vmSymbols_jvmci.hpp
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfigStore.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/runtime/JVMCICompiler.java

Changeset: 07ebda54
Branch: premain
Author:    Inigo Mediavilla Saiz <imediava at gmail.com>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-06-19 10:35:32 +0000
URL:       https://git.openjdk.org/leyden/commit/07ebda54f290cc17c6682abd26ceca2868488a63

8334215: serviceability/dcmd/thread/PrintMountedVirtualThread.java failing with JTREG_TEST_THREAD_FACTORY=Virtual

Reviewed-by: dholmes

! src/hotspot/share/runtime/threads.cpp
! test/hotspot/jtreg/serviceability/dcmd/thread/PrintMountedVirtualThread.java

Changeset: 7b3a96d5
Branch: premain
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-06-19 10:45:34 +0000
URL:       https://git.openjdk.org/leyden/commit/7b3a96d57023e8a7cf495e2d7c551976f0e5656b

8334488: Improve error for illegal early access from nested class

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Enter.java
! test/langtools/tools/javac/AnonymousClass/AnonymousInSuperCallNegTest.out
! test/langtools/tools/javac/LocalClassCtorPrologue.out
+ test/langtools/tools/javac/SuperInit/EarlyInnerAccessErrorMessageTest.java
+ test/langtools/tools/javac/SuperInit/EarlyInnerAccessErrorMessageTest.out
! test/langtools/tools/javac/SuperInit/EarlyLocalClass.out

Changeset: 50bed6c6
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-06-19 10:54:13 +0000
URL:       https://git.openjdk.org/leyden/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0

8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java should not depend on SecurityManager

Reviewed-by: alanb

! test/jdk/java/nio/channels/SocketChannel/OpenLeak.java

Changeset: 01ee4241
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-06-19 15:15:30 +0000
URL:       https://git.openjdk.org/leyden/commit/01ee4241b76e78ca67803c4b083fcedecef1c96c

8294960: Convert java.base/java.lang.invoke package to use the Classfile API to generate lambdas and method handles

Co-authored-by: Claes Redestad <redestad at openjdk.org>
Reviewed-by: redestad, liach

! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java
! src/java.base/share/classes/java/lang/invoke/GenerateJLIClassesHelper.java
! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java
! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! test/hotspot/jtreg/ProblemList.txt

Changeset: 856931d0
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-06-19 16:23:22 +0000
URL:       https://git.openjdk.org/leyden/commit/856931d01f14b1c665c04e05d5637b8237c56988

8304732: jdk/jfr/api/consumer/recordingstream/TestStop.java failed again with "Expected outer stream to have 3 events"

Reviewed-by: mgronlun

! src/hotspot/share/jfr/jni/jfrJniMethod.cpp
! src/hotspot/share/jfr/jni/jfrJniMethod.hpp
! src/hotspot/share/jfr/jni/jfrJniMethodRegistration.cpp
! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp
! src/hotspot/share/jfr/recorder/repository/jfrChunk.hpp
! src/hotspot/share/jfr/support/jfrIntrinsics.hpp
! src/hotspot/share/runtime/objectMonitor.cpp
+ src/jdk.jfr/share/classes/jdk/jfr/internal/HiddenWait.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/management/StreamBarrier.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java
! test/jdk/jdk/jfr/api/consumer/recordingstream/TestStop.java

Changeset: bcf4bb48
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-06-19 16:35:20 +0000
URL:       https://git.openjdk.org/leyden/commit/bcf4bb4882e06d8c52f6eb4e9c4e027ba0622c5f

8333344: JMX attaching of Subject does not work when security manager not allowed

Reviewed-by: weijun, dfuchs

! src/java.base/share/classes/module-info.java
! src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java
! src/java.management/share/classes/com/sun/jmx/remote/internal/ServerNotifForwarder.java
! src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerFileAccessController.java
! src/java.management/share/classes/javax/management/monitor/Monitor.java
! test/jdk/javax/management/monitor/StartStopTest.java
! test/jdk/javax/management/monitor/ThreadPoolAccTest.java
= test/jdk/javax/management/monitor/all.policy
! test/jdk/javax/management/remote/mandatory/notif/NotificationAccessControllerTest.java
! test/jdk/javax/management/remote/mandatory/notif/NotificationEmissionTest.java
! test/jdk/javax/management/remote/mandatory/passwordAccessFile/NonJMXPrincipalsTest.java
! test/jdk/javax/management/remote/mandatory/passwordAccessFile/PasswordAccessFileTest.java
! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIAltAuthTest.java
! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/RMIPasswdAuthTest.java
! test/jdk/javax/management/remote/mandatory/passwordAuthenticator/SimpleStandard.java
! test/jdk/javax/management/security/AuthorizationTest.java
! test/jdk/sun/management/jmxremote/bootstrap/RmiBootstrapTest.java

Changeset: 78682fe7
Branch: premain
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2024-06-19 19:12:31 +0000
URL:       https://git.openjdk.org/leyden/commit/78682fe78e18268b1857855c3595b4d118808c66

8329288: Update Visual Studio visibility support for POSIX functions

Reviewed-by: kbarrett

! make/autoconf/flags-cflags.m4

Changeset: 4e58d8c8
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-06-19 23:23:52 +0000
URL:       https://git.openjdk.org/leyden/commit/4e58d8c897d845cfa73780264481da174d46acb4

8309821: Link to hidden classes section in Class specification for Class::isHidden

Reviewed-by: iris, rriggs

! src/java.base/share/classes/java/lang/Class.java

Changeset: b211929e
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-06-20 01:36:05 +0000
URL:       https://git.openjdk.org/leyden/commit/b211929e05c0acdf7343c3edd025749d573c67b3

8334570: Problem list gc/TestAlwaysPreTouchBehavior.java

Reviewed-by: ayang, tschatzl

! test/hotspot/jtreg/ProblemList.txt

Changeset: fad6644e
Branch: premain
Author:    Sibabrata Sahoo <ssahoo at openjdk.org>
Date:      2024-06-20 04:18:39 +0000
URL:       https://git.openjdk.org/leyden/commit/fad6644eabbad6b6d3472206d9db946408aca612

8333754: Add a Test against ECDSA and ECDH NIST Test vector

Reviewed-by: ascarpino

+ test/jdk/sun/security/ec/ECDHPrimitive.java
+ test/jdk/sun/security/ec/ECDSAPrimitive.java
+ test/jdk/sun/security/ec/KAS_ECC_CDH_PrimitiveTest.txt
+ test/jdk/sun/security/ec/SigGen-1.txt

Changeset: 2d4185f4
Branch: premain
Author:    Erik ?sterlund <eosterlund at openjdk.org>
Date:      2024-06-20 05:23:08 +0000
URL:       https://git.openjdk.org/leyden/commit/2d4185f4f1def7c32d1a556521e26ec656234220

8332717: ZGC: Division by zero in heuristics

Reviewed-by: aboldtch, shade

! src/hotspot/share/gc/z/zDirector.cpp

Changeset: ff302409
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-20 06:15:19 +0000
URL:       https://git.openjdk.org/leyden/commit/ff30240926224b2f98e173bcd606c157af788919

8334239: Introduce macro for ubsan method/function exclusions

Reviewed-by: stefank, stuefe, kbarrett

! src/hotspot/share/cds/archiveHeapLoader.cpp
! src/hotspot/share/prims/unsafe.cpp
+ src/hotspot/share/sanitizers/ub.hpp
! src/hotspot/share/utilities/vmError.cpp

Changeset: d7dad50a
Branch: premain
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2024-06-20 07:14:01 +0000
URL:       https://git.openjdk.org/leyden/commit/d7dad50af5df356089101ca440fca5232fadb81e

8334544: C2: wrong control assigned in PhaseIdealLoop::clone_assertion_predicate_for_unswitched_loops()

Reviewed-by: chagedorn, thartmann

! src/hotspot/share/opto/loopPredicate.cpp

Changeset: cabd1046
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-06-20 08:28:06 +0000
URL:       https://git.openjdk.org/leyden/commit/cabd1046d08865f122663d18708d40e5c885c1c3

8334164: The fix for JDK-8322811 should use _filename.is_set() rather than strcmp()

Reviewed-by: dholmes, cjplummer

! src/hotspot/share/services/diagnosticCommand.cpp

Changeset: c6f3bf4b
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-20 08:30:52 +0000
URL:       https://git.openjdk.org/leyden/commit/c6f3bf4bd61405c2ed374b15ef82cc987f52cd52

8334026: Provide a diagnostic PrintMemoryMapAtExit switch on Linux

Reviewed-by: dholmes, mbaesken

! src/hotspot/os/linux/globals_linux.hpp
! src/hotspot/share/nmt/memMapPrinter.cpp
! src/hotspot/share/runtime/java.cpp
+ test/hotspot/jtreg/runtime/NMT/PrintMemoryMapAtExitTest.java

Changeset: 64208462
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-06-20 10:10:54 +0000
URL:       https://git.openjdk.org/leyden/commit/642084629a9a793a055cba8a950fdb61b7450093

8334396: RISC-V: verify perf of ReverseBytesI/L

Reviewed-by: fyang, rehn

! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/riscv_b.ad

Changeset: 5cad0b4d
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-06-20 11:53:02 +0000
URL:       https://git.openjdk.org/leyden/commit/5cad0b4df7f5ccb6d462dc948c2ea5ad5da6e2ed

8322708: Global HTML attributes are not allowed

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java
+ test/langtools/jdk/javadoc/doclet/TestGlobalHtml/TestGlobalHtml.java
+ test/langtools/jdk/javadoc/doclet/TestGlobalHtml/pkg1/C1.java

Changeset: 001d6860
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Hamlin Li <mli at openjdk.org>
Date:      2024-06-20 13:45:31 +0000
URL:       https://git.openjdk.org/leyden/commit/001d6860199436c5fb14bd681d640d462b472015

8332587: RISC-V: secondary_super_cache does not scale well

Reviewed-by: mli, fyang

! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.hpp

Changeset: 9ef86da5
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-06-20 15:42:17 +0000
URL:       https://git.openjdk.org/leyden/commit/9ef86da5f8e2579fa1fdf40b4a6f556882e1177d

8334170: bug6492108.java test failed with exception Image comparison failed at (0, 0) for image 4

Reviewed-by: aivanov, azvegint

! test/jdk/com/sun/java/swing/plaf/gtk/bug6492108.java

Changeset: 99e4d77a
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-06-20 15:43:44 +0000
URL:       https://git.openjdk.org/leyden/commit/99e4d77aac72cdddb4973805d28c225f17ea965f

8333117: Remove support of remote and manual debuggee launchers

Reviewed-by: cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Debuggee.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/ArgumentHandler.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Binder.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Binder.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/Debugee.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeArgumentHandler.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeBinder.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jpda/DebugeeProcess.java

Changeset: a81e1bf1
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-06-20 15:43:56 +0000
URL:       https://git.openjdk.org/leyden/commit/a81e1bf1e1a6f00280b9be987c03fe20915fd52c

8332252: Clean up vmTestbase/vm/share

Reviewed-by: cjplummer

! test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/LoadUnloadGC.java
= test/hotspot/jtreg/vmTestbase/gc/gctests/LoadUnloadGC/MemoryPoolFinder.java
! test/hotspot/jtreg/vmTestbase/metaspace/gc/HighWaterMarkTest.java
= test/hotspot/jtreg/vmTestbase/metaspace/share/HeapOOMEException.java
= test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingByFillingMetaspace.java
= test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingHelper.java
= test/hotspot/jtreg/vmTestbase/metaspace/share/TriggerUnloadingWithWhiteBox.java
! test/hotspot/jtreg/vmTestbase/metaspace/staticReferences/StaticReferences.java
! test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/PerformChecksHelper.java
! test/hotspot/jtreg/vmTestbase/metaspace/stressHierarchy/common/StressHierarchyBaseClass.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java
! test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/LogCompilationTest.java
= test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/ProcessExecutor.java
= test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamListener.java
= test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamLogger.java
= test/hotspot/jtreg/vmTestbase/vm/compiler/complog/share/StreamReader.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/func/findByName/Test.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/share/StressClassLoadingTest.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/byteMutation/Test.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/heap/Test.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/oome/metaspace/Test.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/hiddenloader/stress/parallelLoad/Test.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/indy/stress/gc/lotsOfCallSites/Test.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/CustomClassLoaders.java
= test/hotspot/jtreg/vmTestbase/vm/mlvm/share/FileUtils.java
! test/hotspot/jtreg/vmTestbase/vm/mlvm/share/MlvmTestExecutor.java
- test/hotspot/jtreg/vmTestbase/vm/share/CommentedFileReader.java
! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.cpp
! test/hotspot/jtreg/vmTestbase/vm/share/ProcessUtils.java
- test/hotspot/jtreg/vmTestbase/vm/share/RandomEx.java
- test/hotspot/jtreg/vmTestbase/vm/share/StringUtils.java
- test/hotspot/jtreg/vmTestbase/vm/share/UnsafeAccess.java
- test/hotspot/jtreg/vmTestbase/vm/share/VMRuntimeEnvUtils.java
- test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryManagerData.java
- test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryPoolData.java
- test/hotspot/jtreg/vmTestbase/vm/share/monitoring/data/MemoryUsageData.java
- test/hotspot/jtreg/vmTestbase/vm/share/process/CmdExecutor.java
- test/hotspot/jtreg/vmTestbase/vm/share/process/MessageInput.java
- test/hotspot/jtreg/vmTestbase/vm/share/process/MessageOutput.java
- test/hotspot/jtreg/vmTestbase/vm/share/process/ProcessHandler.java
- test/hotspot/jtreg/vmTestbase/vm/share/process/StreamMessageInput.java
- test/hotspot/jtreg/vmTestbase/vm/share/process/StreamMessageOutput.java
- test/hotspot/jtreg/vmTestbase/vm/share/transform/AbstractClassFileTransformer.java
- test/hotspot/jtreg/vmTestbase/vm/share/transform/AnnotationAppender.java
- test/hotspot/jtreg/vmTestbase/vm/share/transform/TransformingClassLoader.java

Changeset: 1b1dba80
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-06-20 16:28:48 +0000
URL:       https://git.openjdk.org/leyden/commit/1b1dba8082969244effa86ac03c6053b3b0ddc43

8333358: java/io/IO/IO.java test fails intermittently

Reviewed-by: naoto

! test/jdk/java/io/IO/IO.java
! test/jdk/java/io/IO/input.exp
! test/jdk/java/io/IO/output.exp

Changeset: 265a0f55
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-06-20 17:01:17 +0000
URL:       https://git.openjdk.org/leyden/commit/265a0f5547d0ddb220391aef679c122768f02a00

8334490: Normalize string with locale invariant `toLowerCase()`

Reviewed-by: jlu, dfuchs, lancea, rriggs

! test/lib/jdk/test/lib/Platform.java

Changeset: de8ee977
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
Date:      2024-06-20 18:04:58 +0000
URL:       https://git.openjdk.org/leyden/commit/de8ee97718d7e12b541b310cf5b67f3e10e91ad9

8334333: MissingResourceCauseTestRun.java fails if run by root

Reviewed-by: naoto, jlu

! test/jdk/java/util/ResourceBundle/Control/MissingResourceCauseTestRun.java

Changeset: 187710e1
Branch: premain
Author:    Tom Rodriguez <never at openjdk.org>
Date:      2024-06-20 18:46:36 +0000
URL:       https://git.openjdk.org/leyden/commit/187710e1c1714ba28c7802efd4f7bb32a366d79d

8333300: [JVMCI] add support for generational ZGC

Reviewed-by: dnsimon, kvn, eosterlund

! src/hotspot/cpu/aarch64/jvmciCodeInstaller_aarch64.cpp
! src/hotspot/cpu/riscv/jvmciCodeInstaller_riscv.cpp
! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/gc/z/zBarrier.hpp
! src/hotspot/share/gc/z/zBarrier.inline.hpp
! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp
! src/hotspot/share/gc/z/zBarrierSetRuntime.hpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/jvmci_globals.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 4b4a483b
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-06-20 19:03:50 +0000
URL:       https://git.openjdk.org/leyden/commit/4b4a483b6fe7a6fcfdfe6f68faac29099a64c982

8330699: Obsolete -XX:+UseEmptySlotsInSupers

Reviewed-by: shade, fparain, dholmes

! src/hotspot/share/classfile/fieldLayoutBuilder.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
- test/hotspot/jtreg/runtime/FieldLayout/OldLayoutCheck.java

Changeset: e5de26dd
Branch: premain
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-06-20 23:35:15 +0000
URL:       https://git.openjdk.org/leyden/commit/e5de26ddf0550da9e6d074d5b9ab4a943170adca

8329032: C2 compiler register allocation support for APX EGPRs

Reviewed-by: kvn, sviswanathan

! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c1_Defs_x86.hpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/gc/shared/barrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/x/xBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/globals_x86.hpp
! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/methodHandles_x86.cpp
! src/hotspot/cpu/x86/nativeInst_x86.cpp
! src/hotspot/cpu/x86/nativeInst_x86.hpp
! src/hotspot/cpu/x86/register_x86.cpp
! src/hotspot/cpu/x86/register_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/upcallLinker_x86_64.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.hpp
! src/hotspot/cpu/x86/vmreg_x86.hpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp
! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java

Changeset: 880e458a
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-06-21 00:24:55 +0000
URL:       https://git.openjdk.org/leyden/commit/880e458a1072589ae199cc9204dcce9eab0f4eaa

8333819: Move embedded external addresses from relocation info into separate global table

Reviewed-by: dlong

! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/code/oopRecorder.cpp
! src/hotspot/share/code/oopRecorder.hpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp

Changeset: 6a5cb0b2
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-21 07:04:26 +0000
URL:       https://git.openjdk.org/leyden/commit/6a5cb0b2c49cb390ce8b87fd977ee79572df90fc

8334567: [test] runtime/os/TestTracePageSizes move ppc handling

Reviewed-by: stuefe, lucy

! test/hotspot/jtreg/runtime/os/TestTracePageSizes.java

Changeset: bdd96604
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-06-21 07:36:02 +0000
URL:       https://git.openjdk.org/leyden/commit/bdd96604ae55ba0cd3cd3363e2ba44205d8aa3aa

8323196: jdk/jfr/api/consumer/filestream/TestOrdered.java failed with "Events are not ordered! Reuse = false"

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/api/consumer/filestream/TestOrdered.java

Changeset: ed149062
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-21 08:38:42 +0000
URL:       https://git.openjdk.org/leyden/commit/ed149062d0e8407710f083aa85d28d27c4a45ecc

8333361: ubsan,test : libHeapMonitorTest.cpp:518:9: runtime error: null pointer passed as argument 2, which is declared to never be null

Reviewed-by: asteiner, lucy, amenkov

! test/hotspot/jtreg/serviceability/jvmti/HeapMonitor/libHeapMonitorTest.cpp

Changeset: d2bebffb
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-06-21 09:43:49 +0000
URL:       https://git.openjdk.org/leyden/commit/d2bebffb1fd26fae4526afd33a818ee776b7102e

8327370: (ch) sun.nio.ch.Poller.register throws AssertionError

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb, jpai, djelinski

! src/java.base/share/classes/sun/nio/ch/Poller.java

Changeset: 711e7238
Branch: premain
Author:    Tejesh R <tr at openjdk.org>
Date:      2024-06-21 10:36:05 +0000
URL:       https://git.openjdk.org/leyden/commit/711e7238196a4ef9211ed4cca15c7c1d774df019

6967482: TAB-key does not work in JTables after selecting details-view in JFileChooser
8166352: FilePane.createDetailsView() removes JTable TAB, SHIFT-TAB functionality

Reviewed-by: achung, prr

! src/java.desktop/share/classes/sun/swing/FilePane.java
+ test/jdk/javax/swing/JFileChooser/TABTestONFCExit.java

Changeset: 08ace27d
Branch: premain
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-06-21 10:44:51 +0000
URL:       https://git.openjdk.org/leyden/commit/08ace27da1d9cd215c77471eabf41417ff6282d2

8332314: Add window size configuration option to JavaShellToolBuilder interface

Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellToolBuilder.java
! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java

Changeset: dbf5a9a4
Branch: premain
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-06-21 13:43:03 +0000
URL:       https://git.openjdk.org/leyden/commit/dbf5a9a4006020ddebcce89692ce8826b6b2db46

8334706: [JVMCI] APX registers incorrectly exposed on AMD64

Reviewed-by: yzheng, never

! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/Architecture.java

Changeset: 9f8de221
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-06-21 13:51:06 +0000
URL:       https://git.openjdk.org/leyden/commit/9f8de221d7f0186718411ab3f5217e3883237e84

8327793: Deprecate jstatd for removal

Reviewed-by: alanb, cjplummer

! src/jdk.jstatd/share/classes/module-info.java
! src/jdk.jstatd/share/classes/sun/tools/jstatd/Jstatd.java
! test/jdk/sun/tools/jstatd/JstatdTest.java

Changeset: 75bea280
Branch: premain
Author:    Ferenc Rakoczi <ferenc.r.rakoczi at oracle.com>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-06-21 14:16:23 +0000
URL:       https://git.openjdk.org/leyden/commit/75bea280b9adb6dac9fefafbb3f4b212f100fbb5

8333867: SHA3 performance can be improved

Reviewed-by: kvn, valeriep

! src/hotspot/share/opto/library_call.cpp
! src/java.base/share/classes/sun/security/provider/DigestBase.java
! src/java.base/share/classes/sun/security/provider/SHA3.java

Changeset: c41293a7
Branch: premain
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2024-06-21 14:23:38 +0000
URL:       https://git.openjdk.org/leyden/commit/c41293a70834a79c79e859ebcdb8869884ac87dc

8334695: Fix build failure without zgc after JDK-8333300

Reviewed-by: dnsimon, chagedorn

! src/hotspot/cpu/x86/jvmciCodeInstaller_x86.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 93d98027
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Amit Kumar <amitkumar at openjdk.org>
Date:      2024-06-21 15:48:38 +0000
URL:       https://git.openjdk.org/leyden/commit/93d98027649615afeeeb6a9510230d9655a74a8f

8334715: [riscv] Mixed use of tab and whitespace in riscv.ad

Reviewed-by: chagedorn, amitkumar

! src/hotspot/cpu/riscv/riscv.ad

Changeset: 8e1d2b09
Branch: premain
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2024-06-21 16:37:57 +0000
URL:       https://git.openjdk.org/leyden/commit/8e1d2b091c9a311d98a0b886a803fb18d4405d8a

8334441: Mark tests in jdk_security_infra group as manual

Reviewed-by: clanger, mullan

! test/jdk/ProblemList.txt
! test/jdk/TEST.groups
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CAInterop.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/CertignaCA.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/DTrustCA.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/DigicertCSRootG5.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/EmSignRootG2CA.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java
! test/jdk/security/infra/javax/net/ssl/HttpsURLConnectionTest.java

Changeset: 689cee3d
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-06-21 18:02:57 +0000
URL:       https://git.openjdk.org/leyden/commit/689cee3d0950e15e88a1f6738bfded00655dca9c

8334509: Cancelling PageDialog does not return the same PageFormat object

Reviewed-by: aivanov, prr

! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
+ test/jdk/java/awt/print/PrinterJob/PageDialogCancelTest.java

Changeset: 1ff5acda
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
Date:      2024-06-21 20:13:26 +0000
URL:       https://git.openjdk.org/leyden/commit/1ff5acdafff1ccd3e64c70eebbfbff75e0d783eb

8332099: since-checker - Add @ since to package-info in jdk.jsobject

Reviewed-by: prr

! src/jdk.jsobject/share/classes/netscape/javascript/package-info.java

Changeset: 7e55ed3b
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-06-21 22:38:38 +0000
URL:       https://git.openjdk.org/leyden/commit/7e55ed3b106ed08956d2d38b7c99fb81704667c9

8333748: javap crash - Fatal error: Unmatched bit position 0x2 for location CLASS

Reviewed-by: asotona

! src/jdk.jdeps/share/classes/com/sun/tools/javap/AttributeWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/BasicWriter.java
! src/jdk.jdeps/share/classes/com/sun/tools/javap/ClassWriter.java
+ test/langtools/tools/javap/UndefinedAccessFlagTest.java

Changeset: 72ca7baf
Branch: premain
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-06-22 12:16:50 +0000
URL:       https://git.openjdk.org/leyden/commit/72ca7bafcd49a98c1fe09da72e4e47683f052e9d

8334708: FFM: two javadoc problems

Reviewed-by: mcimadamore

! src/java.base/share/classes/java/lang/foreign/Linker.java
! src/java.base/share/classes/java/lang/foreign/MemoryLayout.java

Changeset: 652784c8
Branch: premain
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-06-23 08:19:28 +0000
URL:       https://git.openjdk.org/leyden/commit/652784c803863f40ee3d81695a19e705365cb800

8334392: Switch RNG in NMT's treap

Reviewed-by: stuefe, azafari, gziemski

! src/hotspot/share/nmt/nmtTreap.hpp
! test/hotspot/gtest/nmt/test_nmt_treap.cpp

Changeset: eb110bdc
Branch: premain
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-06-23 12:33:38 +0000
URL:       https://git.openjdk.org/leyden/commit/eb110bdc6e8bcb87b9b8b24ac66eb9b4c57106fd

8334180: NMT gtests introduced with 8312132 should be labeled as NMT

Reviewed-by: gziemski, stuefe

! src/hotspot/share/nmt/memoryFileTracker.hpp
! src/hotspot/share/nmt/nmtTreap.hpp
! src/hotspot/share/nmt/vmatree.hpp
! test/hotspot/gtest/nmt/test_nmt_memoryfiletracker.cpp
! test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp
! test/hotspot/gtest/nmt/test_nmt_treap.cpp
! test/hotspot/gtest/nmt/test_vmatree.cpp

Changeset: 7baddc20
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2024-06-23 18:00:28 +0000
URL:       https://git.openjdk.org/leyden/commit/7baddc202a9ab2b85401aa05f827678b514ebf55

8334339: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on alinux3

Reviewed-by: alanb

! test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java

Changeset: a4582a89
Branch: premain
Author:    Zhao Song <zsong at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
Date:      2024-06-24 05:15:32 +0000
URL:       https://git.openjdk.org/leyden/commit/a4582a8957d604b50249e1f59679393966456a14

8334166: Enable binary check

Reviewed-by: kcr, ihse, prr, erikj

! .jcheck/conf

Changeset: 863b2a99
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-06-24 06:06:45 +0000
URL:       https://git.openjdk.org/leyden/commit/863b2a991df9204560c4680fc10dd0f68b260217

8329994: Zap alignment padding bits for ArrayOops in non-release builds

Reviewed-by: ayang, sjohanss

! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/memAllocator.hpp
! src/hotspot/share/gc/z/zObjArrayAllocator.cpp

Changeset: 13dce296
Branch: premain
Author:    Richard Reingruber <rrich at openjdk.org>
Date:      2024-06-24 06:33:39 +0000
URL:       https://git.openjdk.org/leyden/commit/13dce296fc3924b269757ce1279c57afe18faeeb

8334560: [PPC64]: postalloc_expand_java_dynamic_call_sched does not copy all fields

Reviewed-by: mbaesken, mdoerr

! src/hotspot/cpu/ppc/ppc.ad
! test/jdk/com/sun/jdi/EATests.java

Changeset: edf7f055
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-06-24 07:14:57 +0000
URL:       https://git.openjdk.org/leyden/commit/edf7f055ee010a2c19bce26c15726d5b58e2e832

8334083: C2 SuperWord: TestCompatibleUseDefTypeSize.java fails with -XX:+AlignVector after JDK-8325155

Reviewed-by: chagedorn, kvn

! test/hotspot/jtreg/compiler/loopopts/superword/TestCompatibleUseDefTypeSize.java

Changeset: 05a63d80
Branch: premain
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-06-24 07:51:01 +0000
URL:       https://git.openjdk.org/leyden/commit/05a63d80b9c1e312512c707ccf6b255c16a9edf5

8334489: Add function os::used_memory

Reviewed-by: eosterlund, dholmes, stuefe

! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp

Changeset: 05ff3185
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-06-24 08:46:10 +0000
URL:       https://git.openjdk.org/leyden/commit/05ff3185edd25b381a97f6879f496e97b62dddc2

8334594: Generational ZGC: Deadlock after OopMap rewrites in 8331572

Reviewed-by: stefank, eosterlund, coleenp, zgu

! src/hotspot/share/gc/shared/gcVMOperations.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp
! src/hotspot/share/gc/x/xDriver.cpp
! src/hotspot/share/gc/z/zGeneration.cpp
! src/hotspot/share/interpreter/oopMapCache.cpp
! src/hotspot/share/interpreter/oopMapCache.hpp

Changeset: ca5a438e
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-06-24 08:58:02 +0000
URL:       https://git.openjdk.org/leyden/commit/ca5a438e5a4612c66f70c70a9d425eca0e49e84d

8334571: Extract control dependency rewiring out of PhaseIdealLoop::dominated_by() into separate method

Reviewed-by: roland, kvn

! src/hotspot/share/opto/loopPredicate.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/loopopts.cpp

Changeset: 9d4a4bd2
Branch: premain
Author:    Matthew Donovan <mdonovan at openjdk.org>
Date:      2024-06-24 11:15:33 +0000
URL:       https://git.openjdk.org/leyden/commit/9d4a4bd2c2a4bd16bbc80b602b15b448c52220f6

8324841: PKCS11 tests still skip execution

Reviewed-by: valeriep

! test/jdk/sun/security/pkcs11/PKCS11Test.java

Changeset: 2e64d151
Branch: premain
Author:    Lutz Schmidt <lucy at openjdk.org>
Date:      2024-06-24 11:27:18 +0000
URL:       https://git.openjdk.org/leyden/commit/2e64d15144be03388104c762816c1ba629da9639

8334564: VM startup: fatal error: FLAG_SET_ERGO cannot be used to set an invalid value for NonNMethodCodeHeapSize

Reviewed-by: mdoerr, kvn, stuefe

! src/hotspot/share/code/codeCache.cpp

Changeset: 5ac2149b
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-06-24 12:37:53 +0000
URL:       https://git.openjdk.org/leyden/commit/5ac2149b7bde947886533bf5996d977bb8ec66f1

8334299: Deprecate LockingMode option, along with LM_LEGACY and LM_MONITOR

Reviewed-by: stuefe, dholmes

! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/runtime/CommandLine/VMDeprecatedOptions.java

Changeset: e825ccfe
Branch: premain
Author:    Robert Toyonaga <rtoyonag at redhat.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-24 13:33:20 +0000
URL:       https://git.openjdk.org/leyden/commit/e825ccfe6652577e4e828e8e4dfe19be0ea77813

8332362: Implement os::committed_in_range for MacOS and AIX

Reviewed-by: stuefe

! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/share/runtime/os.cpp
! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp
! test/hotspot/jtreg/runtime/Thread/TestAlwaysPreTouchStacks.java

Changeset: b2930c5a
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-06-24 13:34:29 +0000
URL:       https://git.openjdk.org/leyden/commit/b2930c5aeedf911ec893734181c1af0573e222f4

8334040: jdk/classfile/CorpusTest.java timed out

Reviewed-by: alanb

! test/jdk/jdk/classfile/CorpusTest.java

Changeset: 55c79694
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-06-24 14:36:50 +0000
URL:       https://git.openjdk.org/leyden/commit/55c796946158aab1d019a57b77a33441d7b13065

8334765: JFR: Log chunk waste

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/filter/ChunkWriter.java
! test/jdk/jdk/jfr/jvm/TestWaste.java

Changeset: 71a692ab
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-06-24 18:05:50 +0000
URL:       https://git.openjdk.org/leyden/commit/71a692ab435fdeea4ce8f8db7a55dd735c7c5016

8321033: Avoid casting Array to GrowableArray

Reviewed-by: kbarrett, iklam, ccheung

! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/moduleEntry.hpp

Changeset: 4b153e5e
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-06-24 18:19:03 +0000
URL:       https://git.openjdk.org/leyden/commit/4b153e5e051c01ad8d0c3ff335352918c2970fe6

8306580: Propagate CDS dumping errors instead of directly exiting the VM

Reviewed-by: iklam, ccheung

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/archiveBuilder.hpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/cds/metaspaceShared.hpp
! src/hotspot/share/runtime/threads.cpp
+ test/hotspot/jtreg/runtime/cds/StaticWritingError.java

Changeset: 3a26bbce
Branch: premain
Author:    Alisen Chung <achung at openjdk.org>
Date:      2024-06-25 02:19:57 +0000
URL:       https://git.openjdk.org/leyden/commit/3a26bbcebc2f7d11b172f2b16192a3adefeb8111

8185429: [macos] After a modal dialog is closed, no window becomes active

Reviewed-by: tr, dnguyen, serb

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java
! test/jdk/ProblemList.txt

Changeset: e527e1c3
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-06-25 03:26:18 +0000
URL:       https://git.openjdk.org/leyden/commit/e527e1c32fcc7b2560cec540bcde930075ac284a

8334580: Deprecate no-arg constructor BasicSliderUI() for removal

Reviewed-by: kcr, aivanov, iris, prr

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java

Changeset: 974dca80
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-25 05:06:33 +0000
URL:       https://git.openjdk.org/leyden/commit/974dca80df71c5cbe492d1e8ca5cee76bcc79358

8334223: Make Arena MEMFLAGs immutable

Reviewed-by: jsjolen, azafari, gziemski

! src/hotspot/share/compiler/compilerThread.cpp
! src/hotspot/share/memory/arena.cpp
! src/hotspot/share/memory/arena.hpp
! src/hotspot/share/memory/resourceArea.cpp
! src/hotspot/share/memory/resourceArea.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/runtime/handles.hpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/javaThread.inline.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: c30e0403
Branch: premain
Author:    Neethu Prasad <neethp at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-06-25 07:08:07 +0000
URL:       https://git.openjdk.org/leyden/commit/c30e040342c69a213bdff321fdcb0d27ff740489

8331911: Reconsider locking for recently disarmed nmethods

Reviewed-by: shade, eosterlund

! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/gc/x/xBarrierSetNMethod.cpp
! src/hotspot/share/gc/z/zBarrierSetNMethod.cpp

Changeset: baafa662
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-06-25 09:12:09 +0000
URL:       https://git.openjdk.org/leyden/commit/baafa662a2f0706e4275a4fe0459ee6759369858

8334287: Man page update for jstatd deprecation

Reviewed-by: alanb

! src/jdk.jstatd/share/man/jstatd.1

Changeset: 75a2afac
Branch: premain
Author:    Sean Mullan <mullan at openjdk.org>
Date:      2024-06-25 12:21:46 +0000
URL:       https://git.openjdk.org/leyden/commit/75a2afacc8f5fdec53350b1cb66076cdfeae12f0

8248981: Specify list of standard message digest and mgf algorithms for RSASSA-PSS signature

Reviewed-by: valeriep

! src/java.base/share/classes/java/security/spec/ECGenParameterSpec.java
! src/java.base/share/classes/java/security/spec/NamedParameterSpec.java
! src/java.base/share/classes/java/security/spec/PSSParameterSpec.java

Changeset: cae94b26
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-06-25 14:06:03 +0000
URL:       https://git.openjdk.org/leyden/commit/cae94b268d633b0557a54e3b21eff60d7f0edc2d

8334397: RISC-V: verify perf of ReverseBytesS/US

Reviewed-by: fyang, luhenry

! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/riscv_b.ad
! test/micro/org/openjdk/bench/java/lang/Characters.java
+ test/micro/org/openjdk/bench/java/lang/Shorts.java

Changeset: 6c679330
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-06-25 14:07:32 +0000
URL:       https://git.openjdk.org/leyden/commit/6c6793307d4734409016943ae584726ac30d667e

8334899: Test runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java failed after JDK-8306580

Reviewed-by: iklam, dholmes

! test/hotspot/jtreg/runtime/cds/appcds/javaldr/ExceptionDuringDumpAtObjectsInitPhase.java

Changeset: 57f8b91e
Branch: premain
Author:    Johan Sj?len <jsjolen at openjdk.org>
Date:      2024-06-25 14:37:38 +0000
URL:       https://git.openjdk.org/leyden/commit/57f8b91e558e5b9ff9c2000b8f74e3a1988ead2b

8333658: NMT: Use an allocator with 4-byte pointers to save memory in NativeCallStackStorage

Reviewed-by: stuefe, azafari

+ src/hotspot/share/nmt/arrayWithFreeList.hpp
+ src/hotspot/share/nmt/nmtNativeCallStackStorage.cpp
! src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp
+ test/hotspot/gtest/nmt/test_arrayWithFreeList.cpp

Changeset: 9c89f086
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-06-25 16:04:03 +0000
URL:       https://git.openjdk.org/leyden/commit/9c89f0861c1b6d25e1a7c3ac1add9a168d807788

8334421: assert(!oldbox->is_unbalanced()) failed: this should not be called for unbalanced region

Reviewed-by: vlivanov, thartmann

! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/escape.cpp
! src/hotspot/share/opto/locknode.hpp
! src/hotspot/share/opto/macro.cpp
+ test/hotspot/jtreg/compiler/locks/TestCoarsenedAndNotEscapedLocksElimination.java

Changeset: 7429c37e
Branch: premain
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-06-25 16:44:41 +0000
URL:       https://git.openjdk.org/leyden/commit/7429c37e63ffd50884d91d8f583d409633bfb04d

8334598: Default classlist in JDK is not deterministic after JDK-8293980

Reviewed-by: ccheung, dholmes, stuefe, erikj

! make/GenerateLinkOptData.gmk

Changeset: 933eabab
Branch: premain
Author:    Quan Anh Mai <qamai at openjdk.org>
Date:      2024-06-25 17:10:20 +0000
URL:       https://git.openjdk.org/leyden/commit/933eababf2b79586a911082af36fdcc41763c7b9

8334629: [BACKOUT] PhaseIdealLoop::conditional_move is too conservative

Reviewed-by: epeter, thartmann, jkarthikeyan

! src/hotspot/share/opto/loopopts.cpp
! test/hotspot/jtreg/ProblemList.txt
- test/micro/org/openjdk/bench/vm/compiler/CMove.java

Changeset: f8bf470b
Branch: premain
Author:    Yude Lin <yude.lyd at alibaba-inc.com>
Committer: Naoto Sato <naoto at openjdk.org>
Date:      2024-06-25 18:19:42 +0000
URL:       https://git.openjdk.org/leyden/commit/f8bf470b773884911290fa6ce059f7cc13686186

8334810: Redo: Un-ProblemList LocaleProvidersRun and CalendarDataRegression
8268379: java/util/Locale/LocaleProvidersRun.java and sun/util/locale/provider/CalendarDataRegression.java timed out

Reviewed-by: naoto, jlu

! test/jdk/ProblemList.txt

Changeset: 861aefca
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-06-25 19:05:01 +0000
URL:       https://git.openjdk.org/leyden/commit/861aefcafacdc21459ef966307f52568e327fd49

8334418: Update IANA Language Subtag Registry to Version 2024-06-14

Reviewed-by: lancea, iris, srl, naoto

! src/java.base/share/data/lsrdata/language-subtag-registry.txt
! test/jdk/java/util/Locale/LanguageSubtagRegistryTest.java

Changeset: 86b0cf25
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-06-25 19:05:22 +0000
URL:       https://git.openjdk.org/leyden/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91

8334653: ISO 4217 Amendment 177 Update

Reviewed-by: naoto

! src/java.base/share/classes/sun/util/resources/CurrencyNames.properties
! src/java.base/share/data/currency/CurrencyData.properties
! test/jdk/java/util/Currency/CheckDataVersion.java
! test/jdk/java/util/Currency/CurrencyTest.java
= test/jdk/java/util/Currency/ISO4217-list-one.txt
! test/jdk/java/util/Currency/ValidateISO4217.java

Changeset: b3bf31a0
Branch: premain
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2024-06-25 19:50:58 +0000
URL:       https://git.openjdk.org/leyden/commit/b3bf31a0a08da679ec2fd21613243fb17b1135a9

8333542: Breakpoint in parallel code does not work

Co-authored-by: Chris Plummer <cjplummer at openjdk.org>
Reviewed-by: dholmes, vlivanov

! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp
! src/hotspot/share/runtime/vframe.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/heapDumper.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java
! test/hotspot/jtreg/runtime/Thread/TestThreadDumpClassInitMonitor.java
+ test/jdk/com/sun/jdi/BreakpointOnClassPrepare.java

Changeset: f101e153
Branch: premain
Author:    Volodymyr Paprotski <volodymyr.paprotski at intel.com>
Committer: Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2024-06-25 22:31:39 +0000
URL:       https://git.openjdk.org/leyden/commit/f101e153cee68750fcf1f12da10e29806875b522

8333583: Crypto-XDH.generateSecret regression after JDK-8329538

Reviewed-by: sviswanathan, kvn, ascarpino

! make/jdk/src/classes/build/tools/intpoly/FieldGen.java
! src/hotspot/cpu/x86/stubGenerator_x86_64_poly_mont.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/runtime.cpp
! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial.java
! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomial1305.java
! src/java.base/share/classes/sun/security/util/math/intpoly/IntegerPolynomialModBinP.java
! src/java.base/share/classes/sun/security/util/math/intpoly/MontgomeryIntegerPolynomialP256.java

Changeset: c66f785f
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-06-26 00:59:49 +0000
URL:       https://git.openjdk.org/leyden/commit/c66f785fb685d5c378fb4c4cdebdef29c01d321b

8334505: RISC-V: Several tests fail when MaxVectorSize does not match VM_Version::_initial_vector_length

Reviewed-by: fyang

! src/hotspot/cpu/riscv/vm_version_riscv.cpp

Changeset: 25c3845b
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-06-26 05:15:36 +0000
URL:       https://git.openjdk.org/leyden/commit/25c3845be270462388ee5e7330cc7315e5c738df

8333133: Simplify QuickSort::sort

Reviewed-by: shade, dholmes

! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/packageEntry.cpp
! src/hotspot/share/compiler/compilationMemoryStatistic.cpp
! src/hotspot/share/gc/g1/g1CollectionSet.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp
! src/hotspot/share/logging/logSelection.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/utilities/quickSort.hpp
! test/hotspot/gtest/gc/shared/test_oopStorage.cpp
! test/hotspot/gtest/utilities/test_quicksort.cpp

Changeset: a5f401f3
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-06-26 07:09:50 +0000
URL:       https://git.openjdk.org/leyden/commit/a5f401f3a8534a64cf3c27c2ef67f17860de6d6b

8334650: Add debug information about whether an Assertion Predicate is for the init or last value

Reviewed-by: roland, kvn

! src/hotspot/share/opto/cfgnode.hpp
! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/loopPredicate.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/predicates.hpp

Changeset: b88af942
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-06-26 07:40:35 +0000
URL:       https://git.openjdk.org/leyden/commit/b88af94269640a160fbacf25618f3a00756464aa

8269870: PS: Membar in PSPromotionManager::copy_unmarked_to_survivor_space could be relaxed

Co-authored-by: Hamlin Li <mli at openjdk.org>
Reviewed-by: mli, kbarrett, tschatzl

! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp

Changeset: e1390056
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-26 08:44:17 +0000
URL:       https://git.openjdk.org/leyden/commit/e1390056c9dbf0a02a131864ebee23435e997852

8333994: NMT: call stacks should show source information

Reviewed-by: jsjolen, gziemski

! src/hotspot/share/nmt/memReporter.cpp
! src/hotspot/share/nmt/memReporter.hpp
+ src/hotspot/share/nmt/nativeCallStackPrinter.cpp
+ src/hotspot/share/nmt/nativeCallStackPrinter.hpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/utilities/nativeCallStack.cpp
! src/hotspot/share/utilities/nativeCallStack.hpp
! test/hotspot/jtreg/runtime/NMT/CheckForProperDetailStackTrace.java

Changeset: 7f6804ce
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-06-26 09:09:13 +0000
URL:       https://git.openjdk.org/leyden/commit/7f6804ceb63568d72e825d45b02d08f314c9b0fc

8334872: BigEndian: java/lang/invoke/condy Tests failing since JDK-8294960

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/invoke/ClassSpecializer.java

Changeset: 4ce8822b
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-06-26 09:12:02 +0000
URL:       https://git.openjdk.org/leyden/commit/4ce8822b6c53b8bd72713f1bfaf6673b91aabea4

8334037: Local class creation in lambda in pre-construction context crashes javac
8333313: NullPointerException in lambda instantiating an inner local class in prologue
8333766: Stack overflow with anonymous class in super() parameter
8334679: Wrong bug number in regression test for JDK-8334252

Co-authored-by: Archie Cobbs <acobbs at openjdk.org>
Reviewed-by: jlahoda, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/CompileStates.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+ test/langtools/tools/javac/SuperInit/AnonSuperLambdaCrash.java
+ test/langtools/tools/javac/SuperInit/EarlyLocalTest1.java
+ test/langtools/tools/javac/SuperInit/EarlyLocalTest4.java
+ test/langtools/tools/javac/SuperInit/EarlyLocalTest5.java
+ test/langtools/tools/javac/SuperInit/EarlyLocalTest6.java
+ test/langtools/tools/javac/SuperInit/EarlyLocalTest7.java
+ test/langtools/tools/javac/SuperInit/LambdaLocalEarlyCrash.java
! test/langtools/tools/javac/SuperInit/LambdaOuterCapture.java
! test/langtools/tools/javac/lambda/T8129740/Universe.java.out

Changeset: 741a0f39
Branch: premain
Author:    Hannes Walln?fer <hannesw at openjdk.org>
Date:      2024-06-26 09:37:22 +0000
URL:       https://git.openjdk.org/leyden/commit/741a0f39dd1fffc1caaa8d69bfe3662dad830452

8334241: Adjust API docs side bar dimensions

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/stylesheet.css

Changeset: f23295ec
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-06-26 10:09:05 +0000
URL:       https://git.openjdk.org/leyden/commit/f23295ec1dde58d239a2625c9b1645534a2bb625

8334600: TEST java/net/MulticastSocket/IPMulticastIF.java fails on linux-aarch64

Reviewed-by: alanb

! test/jdk/java/net/MulticastSocket/IPMulticastIF.java

Changeset: b2ac7259
Branch: premain
Author:    Kangcheng Xu <kxu at openjdk.org>
Committer: Roland Westrelin <roland at openjdk.org>
Date:      2024-06-26 13:19:34 +0000
URL:       https://git.openjdk.org/leyden/commit/b2ac7259c96f154ba0ca54fd47b37caaa8c8647b

8327380: Add tests for Shenandoah barrier expansion optimization

Reviewed-by: roland, shade

+ test/hotspot/jtreg/compiler/gcbarriers/TestShenandoahBarrierExpansion.java

Changeset: efb905e5
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-26 13:37:58 +0000
URL:       https://git.openjdk.org/leyden/commit/efb905e57ab7a5299952419fa9961316541056c2

8334618: ubsan: support setting additional ubsan check options

Reviewed-by: stuefe, lucy

! make/autoconf/jdk-options.m4

Changeset: 4ffc5e60
Branch: premain
Author:    Anthony Scarpino <ascarpino at openjdk.org>
Date:      2024-06-26 13:58:22 +0000
URL:       https://git.openjdk.org/leyden/commit/4ffc5e60776353b03e9a557c39148e378b1690e2

8326705: Test CertMsgCheck.java fails to find alert certificate_required

Reviewed-by: ssahoo, rhalade

! test/jdk/ProblemList.txt
! test/jdk/javax/net/ssl/SSLSession/CertMsgCheck.java
! test/jdk/javax/net/ssl/templates/TLSBase.java

Changeset: 8374d165
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-06-26 14:12:44 +0000
URL:       https://git.openjdk.org/leyden/commit/8374d16504503c7441346c99045736b7ac72233f

8335006: C2 SuperWord: add JMH benchmark VectorLoadToStoreForwarding.java

Reviewed-by: shade, kvn, sviswanathan

+ test/micro/org/openjdk/bench/vm/compiler/VectorLoadToStoreForwarding.java

Changeset: 8591eff7
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-06-26 14:39:21 +0000
URL:       https://git.openjdk.org/leyden/commit/8591eff78dbc9770b8d0a16e05040ac35c99881a

8332103: since-checker - Add missing @ since tags to java.desktop

Reviewed-by: tr, aivanov

! src/java.desktop/share/classes/java/awt/geom/Path2D.java
! src/java.desktop/share/classes/java/beans/package-info.java
! src/java.desktop/share/classes/javax/swing/DefaultComboBoxModel.java
! src/java.desktop/share/classes/javax/swing/DefaultListModel.java
! src/java.desktop/share/classes/javax/swing/JSlider.java
! src/java.desktop/share/classes/javax/swing/package-info.java
! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/package-info.java
! src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java

Changeset: 5883a20b
Branch: premain
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2024-06-26 14:46:17 +0000
URL:       https://git.openjdk.org/leyden/commit/5883a20b822bb8acb719076e4f7abee8403061cb

8334437: De-duplicate ProxyMethod list creation

Reviewed-by: asotona, liach

! src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java

Changeset: b5d58962
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Julian Waters <jwaters at openjdk.org>
Date:      2024-06-26 16:20:15 +0000
URL:       https://git.openjdk.org/leyden/commit/b5d589623c174757e946011495f771718318f1cc

8335108: Build error after JDK-8333658 due to class templates

Reviewed-by: jwaters, jsjolen

! src/hotspot/share/nmt/arrayWithFreeList.hpp

Changeset: bffc8484
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-06-26 17:10:09 +0000
URL:       https://git.openjdk.org/leyden/commit/bffc8484c32ad6c3205f7cebe4e262a2dc9de57e

8333755: NumberFormat integer only parsing breaks when format has suffix

Reviewed-by: naoto

! src/java.base/share/classes/java/text/CompactNumberFormat.java
! src/java.base/share/classes/java/text/DecimalFormat.java
! src/java.base/share/classes/java/text/NumberFormat.java
! test/jdk/java/text/Format/NumberFormat/BigDecimalParse.java
! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java

Changeset: 817edcb6
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-06-26 19:25:37 +0000
URL:       https://git.openjdk.org/leyden/commit/817edcb697cbb8c608c9292cdc4b99db4f5844dc

8331411: Shenandoah: Reconsider spinning duration in ShenandoahLock

Reviewed-by: shade, kdnilsen, wkemper

! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp
! src/hotspot/share/gc/shenandoah/shenandoahLock.hpp

Changeset: 4ebb7712
Branch: premain
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-06-26 20:24:29 +0000
URL:       https://git.openjdk.org/leyden/commit/4ebb77120af5a4ccbfde63b24cb50e05a3161f16

8334769: Shenandoah: Move CodeCache_lock close to its use in ShenandoahConcurrentNMethodIterator

Reviewed-by: shade, wkemper, kdnilsen

! src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp

Changeset: 07bc523d
Branch: premain
Author:    Anthony Scarpino <ascarpino at openjdk.org>
Date:      2024-06-26 22:28:33 +0000
URL:       https://git.openjdk.org/leyden/commit/07bc523df85fde81bf736fedac62874d3cb11ee3

8334670: SSLSocketOutputRecord buffer miscalculation

Reviewed-by: djelinski, ssahoo

! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java

Changeset: 3796fdfc
Branch: premain
Author:    Hannes Greule <hgreule at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-06-26 23:17:32 +0000
URL:       https://git.openjdk.org/leyden/commit/3796fdfcedc2b2202b72cca062218f840960414c

8328536: javac - crash on unknown type referenced in yield statement

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/langtools/jdk/jshell/ToolSimpleTest.java
! test/langtools/tools/javac/generics/diamond/7188968/T7188968.out
! test/langtools/tools/javac/lambda/MethodReference23.out
! test/langtools/tools/javac/lambda/methodReference/MethodRefToInnerWithoutOuter.out
! test/langtools/tools/javac/recovery/AttrRecovery.java

Changeset: 6682305e
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-06-27 03:34:04 +0000
URL:       https://git.openjdk.org/leyden/commit/6682305ee21cf595ec953d95bea594734a2982a8

8334779: Test compiler/c1/CanonicalizeArrayLength.java is timing out

Reviewed-by: thartmann, dlong

! src/hotspot/cpu/x86/macroAssembler_x86.cpp

Changeset: 9bb675f8
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-06-27 04:38:32 +0000
URL:       https://git.openjdk.org/leyden/commit/9bb675f89dd1eeec423ca96cb3f96d29f5de477c

8334719: (se) Deferred close of SelectableChannel may result in a Selector doing the final close before concurrent I/O on channel has completed

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb, dfuchs

! src/java.base/share/classes/sun/nio/ch/DatagramChannelImpl.java
! src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java
! src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java
! src/java.base/unix/classes/sun/nio/ch/SinkChannelImpl.java
! src/java.base/unix/classes/sun/nio/ch/SourceChannelImpl.java
+ test/jdk/java/nio/channels/Selector/DeferredClose/DeferredCloseTest.java
+ test/jdk/java/nio/channels/Selector/DeferredClose/java.base/java/net/InetSocketAddress.java

Changeset: 9d20b58f
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-06-27 05:13:30 +0000
URL:       https://git.openjdk.org/leyden/commit/9d20b58f40275002afa0348d94d5592a26894e88

8334328: Reduce object allocation for FloatToDecimal and DoubleToDecimal

Reviewed-by: redestad, rgiulietti

! src/java.base/share/classes/java/lang/AbstractStringBuilder.java
! src/java.base/share/classes/jdk/internal/math/DoubleToDecimal.java
! src/java.base/share/classes/jdk/internal/math/FloatToDecimal.java
+ src/java.base/share/classes/jdk/internal/math/ToDecimal.java
! test/micro/org/openjdk/bench/java/lang/StringBuilders.java

Changeset: 0fc5b271
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-06-27 06:22:17 +0000
URL:       https://git.openjdk.org/leyden/commit/0fc5b2711fbdde972c40bfef2977dd9d70e09581

8332014: since-checker - Fix @ since tags in jdk.jshell

Reviewed-by: jlahoda

! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java
! src/jdk.jshell/share/classes/jdk/jshell/SourceCodeAnalysis.java
! src/jdk.jshell/share/classes/jdk/jshell/tool/JavaShellToolBuilder.java

Changeset: 46b817b7
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-27 06:53:03 +0000
URL:       https://git.openjdk.org/leyden/commit/46b817b7499e74ba8812d38bcce93147ebf93b25

8333363: ubsan: instanceKlass.cpp: runtime error: member call on null pointer of type 'struct AnnotationArray'

Reviewed-by: coleenp, stefank

! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/metadata.hpp

Changeset: f3b69da5
Branch: premain
Author:    Evemose <124714317+Evemose at users.noreply.github.com>
Committer: Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-06-27 07:45:18 +0000
URL:       https://git.openjdk.org/leyden/commit/f3b69da55a1ec4857fff1537a80ab1fefee93dac

8335136: Underscore as parameter name in one-parameter functional types fails to compile

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/langtools/tools/javac/switchexpr/ExpressionSwitchUnderscoreAfterYield.java

Changeset: 37e7698c
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-06-27 07:54:35 +0000
URL:       https://git.openjdk.org/leyden/commit/37e7698c29b8673b904945d397f0698ccd16d27b

8335154: jcmd VM.classes -verbose=false does not set verbose to false

Reviewed-by: dholmes, stuefe

! src/hotspot/share/services/diagnosticCommand.cpp

Changeset: 79a23017
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-06-27 10:23:55 +0000
URL:       https://git.openjdk.org/leyden/commit/79a23017fc7154738c375fbb12a997525c3bf9e7

8322859: Parallel: Move transform_stack_chunk

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp

Changeset: 50dd962b
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-27 12:56:26 +0000
URL:       https://git.openjdk.org/leyden/commit/50dd962b0d0fe36634d96dbbd9d94fbc34d9ff7f

8335007: Inline OopMapCache table

Reviewed-by: stefank, coleenp, shade

! src/hotspot/share/interpreter/oopMapCache.cpp
! src/hotspot/share/interpreter/oopMapCache.hpp

Changeset: 6b961acb
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-06-27 13:03:21 +0000
URL:       https://git.openjdk.org/leyden/commit/6b961acb87c29027f2158c6b7a764f1276a0bf52

8333786: Serial: Remove SerialHeap::_incremental_collection_failed

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/serial/serialHeap.hpp

Changeset: d5375c7d
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-06-27 13:22:04 +0000
URL:       https://git.openjdk.org/leyden/commit/d5375c7db658de491c1f5bad053040d21b82941e

8333308: javap --system handling doesn't work on internal class names

Reviewed-by: liach, stuefe

! src/jdk.jdeps/share/classes/com/sun/tools/javap/JavapTask.java

Changeset: 5909d541
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-06-27 14:21:34 +0000
URL:       https://git.openjdk.org/leyden/commit/5909d54147355dd7da5786ff39ead4c15816705c

8326820: Metadata artificially kept alive

Reviewed-by: eosterlund, stefank, coleenp

! src/hotspot/share/classfile/classLoaderDataGraph.cpp
! src/hotspot/share/classfile/classLoaderDataGraph.hpp
! src/hotspot/share/classfile/classLoaderStats.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiGetLoadedClasses.cpp

Changeset: 4ab7e98c
Branch: premain
Author:    Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Committer: Martin Balao <mbalao at openjdk.org>
Date:      2024-06-27 15:07:00 +0000
URL:       https://git.openjdk.org/leyden/commit/4ab7e98c79a1a0b7aba1ca74a8316820c906e70e

8330842: Support AES CBC with Ciphertext Stealing (CTS) in SunPKCS11

Co-authored-by: Francisco Ferrari Bihurriet <fferrari at openjdk.org>
Co-authored-by: Martin Balao <mbalao at openjdk.org>
Reviewed-by: valeriep

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Config.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/SunPKCS11.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/Token.java
+ test/jdk/sun/security/pkcs11/Cipher/TestCipherTextStealingMultipart.java
! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphers.java
! test/jdk/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java

Changeset: b6ffb442
Branch: premain
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
Date:      2024-06-27 15:14:36 +0000
URL:       https://git.openjdk.org/leyden/commit/b6ffb442acb4a222f017868433eff213d9b84ed8

8335135: HttpURLConnection#HttpInputStream does not throw IOException when response is truncated

Reviewed-by: dfuchs

! src/java.base/share/classes/sun/net/www/MeteredStream.java
! test/jdk/java/net/Authenticator/BasicTest4.java
+ test/jdk/java/net/URLConnection/TruncatedFixedResponse.java
! test/jdk/sun/net/www/http/KeepAliveStream/KeepAliveStreamCloseWithWrongContentLength.java

Changeset: 0e6b0cba
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-06-27 15:38:06 +0000
URL:       https://git.openjdk.org/leyden/commit/0e6b0cbaaa0d5272f60ee4fe09cf5e247e68c2a8

8334886: jdk/jfr/api/recording/time/TestTimeMultiple.java failed with RuntimeException: getStopTime() > afterStop

Reviewed-by: mgronlun

! src/hotspot/share/jfr/recorder/repository/jfrChunk.cpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java

Changeset: 9d986a01
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-06-27 16:06:35 +0000
URL:       https://git.openjdk.org/leyden/commit/9d986a013d01a5bcc0942bcc490258038291c22c

8335220: C2: Missing check for Opaque4 node in EscapeAnalysis

Reviewed-by: chagedorn, cslucas

! src/hotspot/share/opto/escape.cpp

Changeset: 243bae7d
Branch: premain
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
Date:      2024-06-27 18:25:16 +0000
URL:       https://git.openjdk.org/leyden/commit/243bae7dc0c3e71c02ffed9e1ee7d436af11d3b9

8304693: Remove -XX:-UseVtableBasedCHA

Reviewed-by: kvn, coleenp, dholmes

! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! test/hotspot/jtreg/compiler/cha/AbstractRootMethod.java
! test/hotspot/jtreg/compiler/cha/DefaultRootMethod.java
! test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java
- test/hotspot/jtreg/runtime/InvocationTests/invocationOldCHATests.java
! test/jtreg-ext/requires/VMProps.java

Changeset: c35e58a5
Branch: premain
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-06-27 20:10:13 +0000
URL:       https://git.openjdk.org/leyden/commit/c35e58a5adf06e25a3b482e2be384af95a84f11a

8309634: Resolve CONSTANT_MethodRef at CDS dump time

Reviewed-by: matsaave, ccheung

! src/hotspot/share/cds/classListParser.cpp
! src/hotspot/share/cds/classListWriter.cpp
! src/hotspot/share/cds/classPrelinker.cpp
! src/hotspot/share/cds/dumpAllocStats.cpp
! src/hotspot/share/cds/dumpAllocStats.hpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/interpreter/linkResolver.hpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/cpCache.hpp
! src/hotspot/share/oops/resolvedMethodEntry.hpp
! test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java

Changeset: 3b1ca986
Branch: premain
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Erik Joelsson <erikj at openjdk.org>
Date:      2024-06-27 20:27:51 +0000
URL:       https://git.openjdk.org/leyden/commit/3b1ca986427d3a69c9e167b9b4c07d1b83bc264d

8334895: OpenJDK fails to configure on linux aarch64 when CDS is disabled after JDK-8331942

Reviewed-by: erikj

! make/autoconf/jdk-options.m4

Changeset: 4e8cbf88
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-06-27 22:20:14 +0000
URL:       https://git.openjdk.org/leyden/commit/4e8cbf884ab1eee9c3110712ab62edc706e948ba

8335134: Test com/sun/jdi/BreakpointOnClassPrepare.java timeout

Reviewed-by: kevinw, coleenp

! test/jdk/com/sun/jdi/BreakpointOnClassPrepare.java

Changeset: cd46c87d
Branch: premain
Author:    Gui Cao <gcao at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-06-28 01:44:14 +0000
URL:       https://git.openjdk.org/leyden/commit/cd46c87dc916b2b74067accf80c62df1792f74cf

8334843: RISC-V: Fix wraparound checking for r_array_index in lookup_secondary_supers_table_slow_path

Reviewed-by: fyang

! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp

Changeset: b4df380f
Branch: premain
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Kim Barrett <kbarrett at openjdk.org>
Date:      2024-06-28 03:07:09 +0000
URL:       https://git.openjdk.org/leyden/commit/b4df380f1a4587247a843fe28ae041265f7cfc29

8334763: --enable-asan: assert(_thread->is_in_live_stack((address)this)) failed: not on stack?

Reviewed-by: kbarrett, stuefe, erikj

! make/autoconf/jdk-options.m4

Changeset: 308a8123
Branch: premain
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-06-28 04:42:33 +0000
URL:       https://git.openjdk.org/leyden/commit/308a81238362c39f5b18e2ae8444c96420ef297a

8334645: Un-problemlist vmTestbase/nsk/sysdict/vm/stress/chain/chain007/chain007.java

Reviewed-by: thartmann, lmesnik

! test/hotspot/jtreg/ProblemList-generational-zgc.txt
! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: c47a0e00
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
Date:      2024-06-28 06:19:37 +0000
URL:       https://git.openjdk.org/leyden/commit/c47a0e005e54551e42ee1ae33d7169417a5f86d4

8334147: Shenandoah: Avoid taking lock for disabled free set logging

Reviewed-by: shade, ysr

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp

Changeset: d457609f
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-06-28 06:43:32 +0000
URL:       https://git.openjdk.org/leyden/commit/d457609f700bbb1fed233f1a04501c995852e5ac

8319947: Recursive lightweight locking: s390x implementation

Reviewed-by: aboldtch, lucy

! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/c2_MacroAssembler_s390.hpp
! src/hotspot/cpu/s390/interp_masm_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.cpp
! src/hotspot/cpu/s390/macroAssembler_s390.hpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/s390/vm_version_s390.hpp

Changeset: 3b3a19e9
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-06-28 08:27:07 +0000
URL:       https://git.openjdk.org/leyden/commit/3b3a19e907c7267f03c0b07312b929b7b4b6d200

8335314: Problem list compiler/uncommontrap/DeoptReallocFailure.java

Reviewed-by: chagedorn

! test/hotspot/jtreg/ProblemList.txt

Changeset: 6f4ddc2f
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2024-06-28 09:23:48 +0000
URL:       https://git.openjdk.org/leyden/commit/6f4ddc2f6bf0dd9a626a76d0f5e56a54c6cf6b65

8335142: compiler/c1/TestTraceLinearScanLevel.java occasionally times out with -Xcomp

Reviewed-by: thartmann, kvn

! test/hotspot/jtreg/compiler/c1/TestTraceLinearScanLevel.java

Changeset: 99d2bbf7
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-06-28 09:31:14 +0000
URL:       https://git.openjdk.org/leyden/commit/99d2bbf767ac33e1a021c90ba12d95ef37ea4816

8334433: jshell.exe runs an executable test.exe on startup

Reviewed-by: jpai

! src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java
! src/jdk.jshell/share/classes/jdk/internal/jshell/tool/ConsoleIOContext.java
+ test/langtools/jdk/jshell/TerminalNoExecTest.java

Changeset: c798316b
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-06-28 09:38:18 +0000
URL:       https://git.openjdk.org/leyden/commit/c798316bc4cb33fd902f926030d8a0b6870d661a

8269657: Test java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message

Reviewed-by: dfuchs

! test/jdk/java/nio/channels/DatagramChannel/Loopback.java

Changeset: 8ec378a6
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-06-28 11:03:29 +0000
URL:       https://git.openjdk.org/leyden/commit/8ec378a6c8a460dd0727df800419b3cf45d3c57a

8277949: (dc) java/nio/channels/DatagramChannel/AdaptorBasic.java failed in timeout

Reviewed-by: jpai

! test/jdk/java/nio/channels/DatagramChannel/AdaptorBasic.java
! test/jdk/java/nio/channels/TestServers.java

Changeset: 49eb00da
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-06-28 11:13:11 +0000
URL:       https://git.openjdk.org/leyden/commit/49eb00da8dc66cff3ca430f06ab21357ee6180ef

8299813: java/nio/channels/DatagramChannel/Disconnect.java fails with jtreg test timeout due to lost datagram

Reviewed-by: aefimov

! test/jdk/java/nio/channels/DatagramChannel/Disconnect.java

Changeset: f4d8c005
Branch: premain
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-06-28 12:45:26 +0000
URL:       https://git.openjdk.org/leyden/commit/f4d8c005b35ce34c96027b7f3abb7a307bca3f4c

8334562: Automate com/sun/security/auth/callback/TextCallbackHandler/Default.java test

Reviewed-by: weijun

! test/jdk/ProblemList.txt
! test/jdk/TEST.groups
! test/jdk/com/sun/security/auth/callback/TextCallbackHandler/Default.java
+ test/jdk/java/security/testlibrary/HumanInputStream.java
! test/jdk/sun/security/tools/keytool/KeyToolTest.java

Changeset: 486aa11e
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-06-28 13:28:53 +0000
URL:       https://git.openjdk.org/leyden/commit/486aa11e74d0772ba84c2adc3c62fc1fcbf52604

8335237: ubsan: vtableStubs.hpp  is_vtable_stub exclude from ubsan checks

Reviewed-by: mdoerr, clanger

! src/hotspot/share/code/vtableStubs.hpp

Changeset: 45c4eaa5
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-06-28 16:26:34 +0000
URL:       https://git.openjdk.org/leyden/commit/45c4eaa5600016d3da5ca769b2519df53835e4f7

8335274: SwitchBootstraps.ResolvedEnumLabels.resolvedEnum should be final

Reviewed-by: liach, jlahoda

! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java

Changeset: 79a3554e
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-06-28 19:01:36 +0000
URL:       https://git.openjdk.org/leyden/commit/79a3554e1da604627b3a010dc269c1bd914c79d3

8335124: com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java failed with CPU time out of expected range

Reviewed-by: phh, cjplummer

! test/jdk/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java

Changeset: 3e23e9c5
Branch: premain
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2024-06-28 19:17:24 +0000
URL:       https://git.openjdk.org/leyden/commit/3e23e9c535e0ed1d7517a836d4703c7fb3e917e4

8335344: test/jdk/sun/security/tools/keytool/NssTest.java fails to compile

Reviewed-by: weijun

! test/jdk/sun/security/tools/keytool/NssTest.java

Changeset: 166f9d9a
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-06-28 19:36:00 +0000
URL:       https://git.openjdk.org/leyden/commit/166f9d9ac099fa971805511b32e1cae5c6c108e0

8335221: Some C2 intrinsics incorrectly assume that type argument is compile-time constant

Reviewed-by: roland, chagedorn

! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp

Changeset: 5d866bf1
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-06-28 22:27:34 +0000
URL:       https://git.openjdk.org/leyden/commit/5d866bf17d96bd0f0e4545d7eee5912eda2e3a94

8335252: Reduce size of j.u.Formatter.Conversion#isValid

Reviewed-by: redestad

! src/java.base/share/classes/java/util/Formatter.java

Changeset: 8350b1da
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-06-29 05:04:47 +0000
URL:       https://git.openjdk.org/leyden/commit/8350b1daedae8ef5785a7165e664b1d3149b18b7

8335294: Fix simple -Wzero-as-null-pointer-constant warnings in gc code

Reviewed-by: tschatzl, coleenp, jwaters

! src/hotspot/os/linux/gc/x/xPhysicalMemoryBacking_linux.cpp
! src/hotspot/os/linux/gc/z/zPhysicalMemoryBacking_linux.cpp
! src/hotspot/share/gc/parallel/parMarkBitMap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/z/zPage.inline.hpp
! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC01/libnativeGC01.cpp
! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC02/libnativeGC02.cpp
! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC03/libnativeGC03.cpp
! test/hotspot/jtreg/vmTestbase/gc/gctests/nativeGC05/libnativeGC05.cpp

Changeset: bb18498d
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-06-29 08:19:33 +0000
URL:       https://git.openjdk.org/leyden/commit/bb18498d71dddf49db9bdfac886aed9ae123651d

8335349: jcmd VM.classloaders "fold" option should be optional

Reviewed-by: cjplummer, stuefe

! src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp

Changeset: d9bcf061
Branch: premain
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-06-29 20:40:51 +0000
URL:       https://git.openjdk.org/leyden/commit/d9bcf061450ebfb7fe02b5a50c855db1d9178e5d

8335217: Fix memory ordering in ClassLoaderData::ChunkedHandleList

Reviewed-by: dholmes, stefank, eosterlund

! src/hotspot/share/classfile/classLoaderData.cpp

Changeset: 53242cdf
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-07-01 06:37:09 +0000
URL:       https://git.openjdk.org/leyden/commit/53242cdf9ef17c502ebd541e84370e7c158639c1

8335283: Build failure due to 'no_sanitize' attribute directive ignored

Reviewed-by: shade, tschatzl, kbarrett, jwaters

! src/hotspot/share/sanitizers/ub.hpp

Changeset: c7e9ebb4
Branch: premain
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Martin Doerr <mdoerr at openjdk.org>
Date:      2024-07-01 08:07:42 +0000
URL:       https://git.openjdk.org/leyden/commit/c7e9ebb4cfff56b7a977eb2942f563f96b3336bd

8331732: [PPC64] Unify and optimize code which converts != 0 to 1

Reviewed-by: mdoerr, amitkumar

! src/hotspot/cpu/ppc/assembler_ppc.hpp
! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.hpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp

Changeset: 71e3798b
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-01 08:12:20 +0000
URL:       https://git.openjdk.org/leyden/commit/71e3798bf67cddef37a8b4e377c4bf21dbd01567

8335308: compiler/uncommontrap/DeoptReallocFailure.java times out with SerialGC on Windows

Reviewed-by: kvn, thartmann, chagedorn

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/uncommontrap/DeoptReallocFailure.java

Changeset: 0a6ffa57
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-07-01 08:47:29 +0000
URL:       https://git.openjdk.org/leyden/commit/0a6ffa57954ddf4f92205205a5a1bada813d127a

8261242: [Linux] OSContainer::is_containerized() returns true when run outside a container

Reviewed-by: stuefe, iklam

! src/hotspot/os/linux/cgroupSubsystem_linux.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.hpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp
! src/hotspot/os/linux/osContainer_linux.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/prims/jvm.cpp
! src/java.base/linux/classes/jdk/internal/platform/CgroupMetrics.java
! src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystem.java
! src/java.base/linux/native/libjava/CgroupMetrics.c
! src/java.base/share/classes/jdk/internal/platform/Metrics.java
! src/java.base/share/classes/sun/launcher/LauncherHelper.java
! test/hotspot/gtest/runtime/test_cgroupSubsystem_linux.cpp
! test/hotspot/jtreg/ProblemList.txt
- test/hotspot/jtreg/containers/cgroup/PlainRead.java
+ test/hotspot/jtreg/containers/cgroup/TestContainerized.java
+ test/jdk/jdk/internal/platform/cgroup/TestSystemSettings.java
! test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java

Changeset: 747e1e47
Branch: premain
Author:    Evgeny Nikitin <enikitin at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-07-01 10:21:31 +0000
URL:       https://git.openjdk.org/leyden/commit/747e1e47f576b0ca3ac97d1deea87418e67ff2d1

8334295: CTW: update modules

Reviewed-by: shade, thartmann

! test/hotspot/jtreg/applications/ctw/modules/generate.bash
+ test/hotspot/jtreg/applications/ctw/modules/jdk_incubator_vector.java
+ test/hotspot/jtreg/applications/ctw/modules/jdk_internal_md.java
+ test/hotspot/jtreg/applications/ctw/modules/jdk_jpackage.java
+ test/hotspot/jtreg/applications/ctw/modules/jdk_nio_mapmode.java

Changeset: 3ca2bcd4
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-07-01 11:51:13 +0000
URL:       https://git.openjdk.org/leyden/commit/3ca2bcd402042791d7460dd79ee16a3f88436b3e

8335060: ClassCastException after JDK-8294960

Reviewed-by: liach, jpai

! src/java.base/share/classes/java/lang/invoke/TypeConvertingMethodAdapter.java
+ test/jdk/java/lang/invoke/TypeConvertingTest.java

Changeset: 2f4f6cc3
Branch: premain
Author:    Arseny Bochkarev <arseny.bochkarev at syntacore.com>
Committer: Ludovic Henry <luhenry at openjdk.org>
Date:      2024-07-01 12:19:49 +0000
URL:       https://git.openjdk.org/leyden/commit/2f4f6cc34c10c5519c74abbce8d1715013b50d5d

8317721: RISC-V: Implement CRC32 intrinsic

Reviewed-by: vkempik, rehn

! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRGenerator_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/stubRoutines_riscv.cpp
! src/hotspot/cpu/riscv/stubRoutines_riscv.hpp
! src/hotspot/cpu/riscv/vm_version_riscv.cpp

Changeset: ee4720a7
Branch: premain
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2024-07-01 20:38:55 +0000
URL:       https://git.openjdk.org/leyden/commit/ee4720a75d815c84039055902c88b360737a1f9c

8333306: gc/arguments/TestParallelGCErgo.java fails when largepage are enabled

Reviewed-by: ayang, zgu

! test/hotspot/jtreg/gc/arguments/TestParallelGCErgo.java

Changeset: 5fe07b36
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-07-02 03:39:43 +0000
URL:       https://git.openjdk.org/leyden/commit/5fe07b36d9eb296661692d903ed0b9b5afefba0f

5021949: JSplitPane setEnabled(false) shouldn't be partially functional

Reviewed-by: abhiscxk, achung, aivanov

! src/java.desktop/share/classes/javax/swing/JSplitPane.java
! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneDivider.java
+ test/jdk/javax/swing/JSplitPane/TestSplitPaneEnableTest.java

Changeset: 318d9aca
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-02 05:56:21 +0000
URL:       https://git.openjdk.org/leyden/commit/318d9acadf305f9d7d0cd8bb54b41506dd9914a8

8335369: Fix -Wzero-as-null-pointer-constant warnings in ImmutableOopMapBuilder

Reviewed-by: kvn, jwaters

! src/hotspot/share/compiler/oopMap.hpp

Changeset: 9046d7ae
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-07-02 08:20:26 +0000
URL:       https://git.openjdk.org/leyden/commit/9046d7aee3082b6cbf79876efc1c508cb893caad

8335390: C2 MergeStores: wrong result with Unsafe

Reviewed-by: thartmann, chagedorn, kvn

! src/hotspot/share/opto/memnode.cpp
! test/hotspot/jtreg/compiler/c2/TestMergeStores.java
+ test/hotspot/jtreg/compiler/c2/TestMergeStoresUnsafeArrayPointer.java

Changeset: 4060b35b
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-02 08:58:20 +0000
URL:       https://git.openjdk.org/leyden/commit/4060b35b1d00fccbec4b20353063f77c43ecc686

8335298: Fix -Wzero-as-null-pointer-constant warning in G1CardSetContainers

Reviewed-by: iwalulya, ayang

! src/hotspot/share/gc/g1/g1CardSetContainers.hpp

Changeset: a537e87d
Branch: premain
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2024-07-02 11:50:21 +0000
URL:       https://git.openjdk.org/leyden/commit/a537e87d2d2c6bff63f63bb436e3e919740221ce

8335530: Java file extension missing in AuthenticatorTest

Reviewed-by: cstein, jpai

- test/jdk/com/sun/net/httpserver/AuthenticatorTest
+ test/jdk/com/sun/net/httpserver/AuthenticatorTest.java

Changeset: dd74e7f8
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-02 12:15:02 +0000
URL:       https://git.openjdk.org/leyden/commit/dd74e7f8c1570ed34c89f4aca184f5668e4471db

8335147: Serial: Refactor TenuredGeneration::promote

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp

Changeset: 685e5878
Branch: premain
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2024-07-02 14:36:29 +0000
URL:       https://git.openjdk.org/leyden/commit/685e5878b823fa5e3ae88ffd76de6507d6057af2

8334816: compiler/c2/irTests/TestIfMinMax.java fails after 8334629

Reviewed-by: thartmann, chagedorn

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java

Changeset: 153b12b9
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-07-02 15:38:54 +0000
URL:       https://git.openjdk.org/leyden/commit/153b12b9df87fdf8122cae3bf7f13078f55f7101

8331560: Refactor Hotspot container detection code so that subsystem delegates to controllers

Reviewed-by: jsjolen, stuefe

! src/hotspot/os/linux/cgroupSubsystem_linux.cpp
! src/hotspot/os/linux/cgroupSubsystem_linux.hpp
+ src/hotspot/os/linux/cgroupUtil_linux.cpp
+ src/hotspot/os/linux/cgroupUtil_linux.hpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp
! src/hotspot/os/linux/cgroupV2Subsystem_linux.hpp

Changeset: a3479576
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-02 18:13:50 +0000
URL:       https://git.openjdk.org/leyden/commit/a3479576c9b3e557cdc04e0984da6350e985dcc9

8335291: Problem list all SA core file tests on macosx-aarch64 due to JDK-8318754

Reviewed-by: kevinw, amenkov

! test/hotspot/jtreg/ProblemList.txt

Changeset: 27982c8f
Branch: premain
Author:    Viktor Klang <vklang at openjdk.org>
Date:      2024-07-02 20:27:52 +0000
URL:       https://git.openjdk.org/leyden/commit/27982c8f5dad0e2d080846f803055c84bac9fddd

8327854: Test java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java failed with RuntimeException

Reviewed-by: psandoz

! test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpStatefulTest.java

Changeset: 1ef34c18
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-02 23:15:31 +0000
URL:       https://git.openjdk.org/leyden/commit/1ef34c183315b70ddc27c177a2867e30132609f5

8335475: ClassBuilder incorrectly calculates max_locals in some cases

Reviewed-by: asotona

! src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
! test/jdk/jdk/classfile/StackMapsTest.java

Changeset: 40373c0a
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-02 19:27:48 +0000
URL:       https://git.openjdk.org/leyden/commit/40373c0a253bf0e75ae57edf4e5637c3345ef3da

Merge branch 'master' of https://github.com/openjdk/leyden into premain

! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/nativeInst_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/cds/archiveHeapLoader.cpp
! src/hotspot/share/cds/classListWriter.cpp
! src/hotspot/share/cds/cppVtables.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/cds/metaspaceShared.hpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciReplay.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/moduleEntry.hpp
! src/hotspot/share/classfile/packageEntry.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/SCCache.hpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/compiler/oopMap.hpp
! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/jvmci/jvmciCompiler.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/javaThread.inline.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! test/hotspot/jtreg/ProblemList.txt
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/nativeInst_x86.hpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/cds/archiveHeapLoader.cpp
! src/hotspot/share/cds/classListWriter.cpp
! src/hotspot/share/cds/cppVtables.cpp
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/cds/metaspaceShared.hpp
! src/hotspot/share/ci/ciInstanceKlass.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciReplay.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/moduleEntry.cpp
! src/hotspot/share/classfile/moduleEntry.hpp
! src/hotspot/share/classfile/packageEntry.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
+ src/hotspot/share/code/SCCache.cpp
+ src/hotspot/share/code/SCCache.hpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/compiler/oopMap.hpp
! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/jvmci/jvmciCompiler.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/nmt/virtualMemoryTracker.cpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/instanceKlass.hpp
! src/hotspot/share/oops/method.cpp
+ src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/runtime.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/javaThread.cpp
! src/hotspot/share/runtime/javaThread.hpp
! src/hotspot/share/runtime/javaThread.inline.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/threads.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/invoke/LambdaForm.java
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! test/hotspot/jtreg/ProblemList.txt

Changeset: 79329d86
Branch: premain
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-07-10 23:29:19 +0000
URL:       https://git.openjdk.org/leyden/commit/79329d86d896eb552d269b566bfd0edd544118ea

Resolve merge conflicts

! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp
! src/java.base/share/classes/java/lang/invoke/MethodType.java
! src/hotspot/share/cds/filemap.cpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp
! src/java.base/share/classes/java/lang/invoke/MethodType.java


From sanne at redhat.com  Thu Jul 11 07:54:27 2024
From: sanne at redhat.com (Sanne Grinovero)
Date: Thu, 11 Jul 2024 08:54:27 +0100
Subject: [External] : Re: Draft JEP 8315737: AOT Linked Classes
In-Reply-To: <68e54b4e-5cb8-423c-a5ec-ea9ab4397ff9@oracle.com>
References: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
 <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
 <9e396c07-0fe0-44e5-9b6e-ee0e4eba7eb2@oracle.com>
 <CA+3eh119VHVKBNSrHYyYfuXMoSK9b9ysBUOx8MzHRLJAya5bYQ@mail.gmail.com>
 <68e54b4e-5cb8-423c-a5ec-ea9ab4397ff9@oracle.com>
Message-ID: <CAA5_-WZGAguPDrWP32JdK5oKZnZE8L93PuGb-z3OxcZd5vEr9w@mail.gmail.com>

Apologies for intervening with possibly very naive questions, as I'm new
here - but very curious about this:

On Wed, Jul 10, 2024 at 11:43?PM <ioi.lam at oracle.com> wrote:

>
> On 7/10/24 6:41 AM, Volker Simonis wrote:
> > Hi Ioi,
> >
> > Thanks for the clarification. I wasn't aware of the fact, that only
> > static CDS archives can contain archived heap objects. The official
> > CDS documentation [1] is also not mentioning this. In contrary, it
> > states that:
> >
> >> The names "static" and "dynamic" are used for historical reasons. The
> only significance is that the "static" archive is loaded first and the
> "dynamic" archive is loaded second.
> > So maybe that documentation should be updated to make it clear that
> > static CDS archives are more powerful?
>
> I have filed https://bugs.openjdk.org/browse/JDK-8336147
>
>
> > Is there a conceptual reason for why dynamic archives can not contain
> > heap objects or is this just an implementation issue that could be
> > solved? Maybe because G1 can currently only map a single heap region
> > from file?
>
> The reasons that heap objects cannot be stored in the dynamic archive:
>
> - The dynamic dump happens at the end of program execution. GC might
> have moved the objects around. If there?s a reference from the
> achievable objects from the dynamic archive that points to the
> archivable objects in the static archive, keeping track of that is
> difficult.
>

As someone who has no clue about how this is actually implemented, I find
this puzzling: since the program is being terminated, why would GC still be
allowed to actively move things around?
I would have expected at this point for the heap to be "frozen": GC is
terminated first, and only then the dump would be captured?

Is it the case that GC is a potentially necessary service to the process of
capturing the dump? I would have assumed some separation in the design, to
have the dumping process run in its own heap or its own process altogether.


- The dynamic run may mutate objects in the static archive. For example,
> for invokedynamic support, if we have a MethodType for a class in the
> dynamic archive, this MT needs to be entered into a global hashtable
> that?s rooted in the static archive
> (java.lang.invoke.MethodType::internTable).
>
> Instead of just fixing the 2-level problem between static and dynamic
> archives, folks like John Rose and Dan Heidinga are working on general
> designs that would support multiple groups of archived heap objects that
> have cross references between these groups.
>
> In the near future, Leyden optimization will be based on the static
> archive only, as many optimizations rely on snapshots of heap objects.
>

With that, do you mean that many more optimizations are reserved for after
the new design is implemented?

Many thanks
 -- Sanne



>
>
> Thanks
>
> - Ioi
>
>
>
> >
> > Thank you and best regards,
> > Volker
> >
> > [1]
> https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing
> >
> > On Tue, Jul 9, 2024 at 7:32?AM <ioi.lam at oracle.com> wrote:
> >> On 7/8/24 6:52 AM, Volker Simonis wrote:
> >>
> >> The way you describe the manual usage of CDS is "old" and quite
> >> cumbersome. Why not use the new -XX:+AutoCreateSharedArchive option
> >> which automatically creates the archive if non is available. Or does
> >> -XX:+AOTLoadedClasses not work together with
> >> -XX:+AutoCreateSharedArchive and if so, why not?
> >>
> >> -XX:+AutoCreateSharedArchive is for creating dynamic CDS archives only.
> It cannot be used for creating static CDS archives.
> >>
> >> -XX:+AOTLoadedClasses works for both dynamic and static CDS archives.
> However, as part of this JEP, to demonstrate its promises, we will also
> implement one significant optimization that relies on -XX:+AOTLoadedClasses:
> >>
> >>      JDK-8293336 Store LambdaForms in CDS archive heap
> >>
> >> JDK-8293336 works only for the static CDS archive (it requires
> archiving Java heap objects, which is not supported by dynamic CDS
> archives).
> >>
> >> Thanks
> >>
> >> - Ioi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240711/5f315eb8/attachment.htm>

From vladimir.kozlov at oracle.com  Thu Jul 11 17:05:40 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Jul 2024 10:05:40 -0700
Subject: Save/load StubRoutines
In-Reply-To: <CAKt0pyQEHXgJnWyE+vhYFejX18B9xdkKCKwuRi8D+U5NWpQS9w@mail.gmail.com>
References: <CAKt0pyQEHXgJnWyE+vhYFejX18B9xdkKCKwuRi8D+U5NWpQS9w@mail.gmail.com>
Message-ID: <8cc4f0da-266c-44b0-933f-49ec9b6b6b60@oracle.com>

Great work, Ashutosh

One issue I found recently is that we need to always generate cached code file even if there are no cached nmethods.
I use saved stubs code for that. May be we should select one stub or blob which is not under LoadStubs/StoreStubs.
May be temporary until we start caching adapter.

LoadStubs should also depends on presence of cached code archive.

 > Apart from implementing the above approach, this patch also has changes to move JFR stubs and throw_exception stubs to
 > SharedRuntime and stores/loads them as a RuntimeStub, as they seem to be a better fit there.

This should go into mainline (first RFE). I see that it takes majority of changed lines in changeset.

There are changes to use InternalAddress instead of ExternalAddress. This should go into mainline too (second RFE).

Moved SHA and BASE64 tables in stubGenerator_aarch64.cpp into mainline (third RFE).

Can you explain next change in arraycopy stubs on aarch64?:
     __ b(RuntimeAddress(byte_copy_entry));
     __ b(byte_copy_entry);

And why is this?:
#if 0
     // This block of code is moved to StubRoutines::x86::init_SCAddressTable()
     StubRoutines::x86::generate_CRC32C_table(supports_clmul);
#endif


Thanks,
Vladimir K


On 7/9/24 7:55 AM, Ashutosh Mehra wrote:
> Hi all,
> 
> We have been working for some time on storing and loading generated code (stubs and blobs) in the hotspot as part of the 
> "premain" project.
> The code is now in a good enough shape to be shared with a wider audience to get some feedback and comments.
> 
> So here is the link [0] [1] to the changes for storing and loading of stubs which are declared in StubRoutines.
> This patch covers both aarch64 and x86-64 architectures.
> The code changes are done on top of AndrewD's patch for storing the blobs [2].
> 
> ---
> 
> A brief description of the approach for storing StubRoutines stubs is warranted as it slightly differs from the 
> technique used for storing other runtime blobs.
> 
> In the mainline StubRoutines are divided into 4 categories depending on when they are generated and their purpose - 
> initial, continuation, compiler and final
> In comparison to a runtime blob which is stored in its own buffer, a StubRoutine stub belongs to a category and all the 
> stubs in a category are stored in the same buffer.
> This makes the code buffer storing StubRoutine to have multiple entry points and these entry points are established as 
> the stubs are generated during the runtime.
> Moreover, the generation of some stubs is dependent on the availability of certain cpu features.
> 
> So when the buffer for a StubRoutine category is stored in the code cache, some extra information needs to be store to 
> be able to identify all the entry points
> and be able to associate them with the correct stubs when loading the buffer.
> 
> To implement this each stub is given a unique static id irrespective of whether its code is generated or not (refer to 
> macro STUB_ROUTINES_STUBS_DO in runtime/stubRoutines.hpp)
> When the stubs are generated the entry point(s) of the stubs are stored in an array (see StubArchiveData::_address_array 
> in runtime/stubCodeGenerator.hpp).
> As the stubs are generated, the entry points are appended to the array. Most of the stubs have only one entry point.
> In addition to the entry point(s), the end address of the stub is also recorded in the array.
> The end address is used to create StubCodeDesc when the stubs are loaded from the code cache.
> 
> To identify the addresses that belong to a stub, we store a tuple of 2 elements for each stub: first element is the 
> index of the first entry point of the stub in the _address_array
> and second element is the number of addresses stored by this stub in the _address_array (see StubAddrIndexInfo in 
> runtime/stubCodeGenerator.hpp).
> For stubs that are not generated, -1 is used for both the elements. These tuples are stored in an array 
> StubArchiveData::_index_table indexed by the unique stub id.
> 
> It is easier to visualize this using a simple example:
> Assume there are 3 stubs. Stub1 has 2 entry points (S1-1 and S1-2) and an end address (E1). Stub2 is not generated. 
> Stub3 has one entry point (S3-1) and end address (E3).
> For this case the _address_array and _index_table in the StubArchiveData would have following entries:
> 
> _address_array:
> index:? ? ? ? ? 0? ? ? ? ? 1 ? ? ?2? ? ? ?3? ? ? ?4
> contents: | S1-1 | S1-2 | E1 | S3-1 | E3 |
> 
> _index_table:
> index:? ? ? ? ? 0? ? ? ? 1 ? ? ? ?0
> contents: | 0, 3 | -1, -1 | 3, 2 |
> 
> When all the stubs of a category are generated, the _address_array and _index_table are stored in the code cache (in 
> SCCache::store_stubroutines_blob).
> During load time the code?along with the _address_array and _index_table is read back from the code cache (in 
> SCCReader::compile_stubroutines_blob).
> The stubs entry points are set up in their respective routines that generates the stub (such as generate_call_stub) 
> using the _index_table.
> 
> As the stubs are generated, their entry points are also registered with the SCAddressTable in SCCache.
> To preserve the order of the SCAddressTable during load, the elements of the _address_array are registered when the 
> buffer is loaded (in SCCReader::compile_stubroutines_blob).
> 
> In addition, StubArchiveData also stores the name of the stubs which is used to verify the code located in the code 
> cache is indeed for the stub being loaded.
> 
> ---
> 
> Apart from implementing the above approach, this patch also has changes to move JFR stubs and throw_exception stubs to 
> SharedRuntime and stores/loads them as a RuntimeStub,
> as they seem to be a better fit there.
> There are also some minor improvements to logging to trace the stubs generation and store/load times.
> 
> Lastly, the generated code (stubs and blobs) can be controlled using these two options - StoreStubs and LoadStubs.
> 
> Please review the code and provide your feedback. Let us know if any clarification is required.
> 
> There is still scope of improvement. Some of the things that can be done are:
> - In current scheme if a stub is not generated during training run, but gets generated during the production run, the 
> order of SCAddressTable can vary resulting in crash/unexpected behavior
> - Enum used to enumerate stubs can be improved. AndrewD has the idea of a global enum that identifies all the 
> stubs/blobs and that can address this aspect of the patch and the limitation in the previous point as well.
> - Exploring other ways to handle external constant data such as tables used by trigonometric stubs which need to be 
> registered in SCAddressTable very early. See StubRoutines::stubs_SCAddressTable_init).
> - Using InternalAddress (or something similar) relocation type for targets that are in the same blob, so that they don't 
> need to be fixed on load.

> 
> 
> [0] change sets: https://github.com/adinn/leyden/compare/d808ea2..7738ed6 
> <https://github.com/adinn/leyden/compare/d808ea2..7738ed6>
> [1] branch: https://github.com/adinn/leyden/commits/premain-stub-routines/ 
> <https://github.com/adinn/leyden/commits/premain-stub-routines/>
> [2] https://github.com/adinn/leyden/commits/premain-save-generated/ 
> <https://github.com/adinn/leyden/commits/premain-save-generated/>
> 
> Thanks,
> - Ashutosh Mehra

From asmehra at redhat.com  Fri Jul 12 02:37:49 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Thu, 11 Jul 2024 22:37:49 -0400
Subject: Save/load StubRoutines
In-Reply-To: <8cc4f0da-266c-44b0-933f-49ec9b6b6b60@oracle.com>
References: <CAKt0pyQEHXgJnWyE+vhYFejX18B9xdkKCKwuRi8D+U5NWpQS9w@mail.gmail.com>
 <8cc4f0da-266c-44b0-933f-49ec9b6b6b60@oracle.com>
Message-ID: <CAKt0pyRQTwYrDF4tRUVnAk2920-HwqPLhjiznqUHKQsr-s4PLg@mail.gmail.com>

>
> LoadStubs should also depends on presence of cached code archive.


I am not sure I get this. I already have this check
in  CDSConfig::check_vm_args_consistency():

  if (!LoadCachedCode && LoadStubs) {
    warning("LoadStubs will be ignored without LoadCachedCode");
    LoadStubs = false;
  }

and SCCache::load_XXX() routines have this check:

  SCCache* cache = open_for_read();
  if (cache == nullptr) {
    return false;
  }

Wouldn't these checks be sufficient?

Can you explain next change in arraycopy stubs on aarch64?:
>      __ b(RuntimeAddress(byte_copy_entry));
>      __ b(byte_copy_entry);


Andrew Dinn can explain this change. I am guessing because byte_copy_entry
is in the same CodeBuffer, we don't need to emit any relocation?

And why is this?:
> #if 0
>      // This block of code is moved to
> StubRoutines::x86::init_SCAddressTable()
>      StubRoutines::x86::generate_CRC32C_table(supports_clmul);
> #endif
>

I moved the call that generates StubRoutines::x86::_crc32c_table to
init_SCAddressTable so as to club its registration together with all other
constants.
I forgot to remove this block of code. I will clean it up.

Another thing worth pointing out (which may have got overlooked in the
large patch) is this change in StubGenerator::array_overlap_test
(in stubGenerator_x86_64_arraycopy.cpp)

   if (NOLp == nullptr) {
-    ExternalAddress no_overlap(no_overlap_target);
+    RuntimeAddress no_overlap(no_overlap_target);
     __ jump_cc(Assembler::belowEqual, no_overlap);
     __ cmpptr(to, end_from);
     __ jump_cc(Assembler::aboveEqual, no_overlap);

It seems like a bug to have ExternalAddress relocation for jump targets. If
this change is reverted then debug build fails with following assertion
failure:

#  Internal Error
(/home/asmehra/data/ashu-mehra/leyden/src/hotspot/cpu/x86/assembler_x86.cpp:1009),
pid=1392250, tid=1392251
#  assert(which == call32_operand) failed: jcc has no disp32 or imm

Same is the case in StubGenerator::generate_cont_thaw():

-  __ jump(ExternalAddress(StubRoutines::throw_StackOverflowError_entry()));
+  __ jump(RuntimeAddress(StubRoutines::throw_StackOverflowError_entry()));

In this case assertion failure is:

#  Internal Error
(/home/asmehra/data/ashu-mehra/leyden/src/hotspot/cpu/x86/assembler_x86.cpp:1171),
pid=1398423, tid=1398424
#  assert(which == call32_operand) failed: call has no disp32 or imm

Mainline is oblivious to this as the relocations are not emitted for
StubRoutines.

Thanks,
- Ashutosh Mehra


On Thu, Jul 11, 2024 at 1:06?PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Great work, Ashutosh
>
> One issue I found recently is that we need to always generate cached code
> file even if there are no cached nmethods.
> I use saved stubs code for that. May be we should select one stub or blob
> which is not under LoadStubs/StoreStubs.
> May be temporary until we start caching adapter.
>
> LoadStubs should also depends on presence of cached code archive.
>
>  > Apart from implementing the above approach, this patch also has changes
> to move JFR stubs and throw_exception stubs to
>  > SharedRuntime and stores/loads them as a RuntimeStub, as they seem to
> be a better fit there.
>
> This should go into mainline (first RFE). I see that it takes majority of
> changed lines in changeset.
>
> There are changes to use InternalAddress instead of ExternalAddress. This
> should go into mainline too (second RFE).
>
> Moved SHA and BASE64 tables in stubGenerator_aarch64.cpp into mainline
> (third RFE).
>
> Can you explain next change in arraycopy stubs on aarch64?:
>      __ b(RuntimeAddress(byte_copy_entry));
>      __ b(byte_copy_entry);
>
> And why is this?:
> #if 0
>      // This block of code is moved to
> StubRoutines::x86::init_SCAddressTable()
>      StubRoutines::x86::generate_CRC32C_table(supports_clmul);
> #endif
>
>
> Thanks,
> Vladimir K
>
>
> On 7/9/24 7:55 AM, Ashutosh Mehra wrote:
> > Hi all,
> >
> > We have been working for some time on storing and loading generated code
> (stubs and blobs) in the hotspot as part of the
> > "premain" project.
> > The code is now in a good enough shape to be shared with a wider
> audience to get some feedback and comments.
> >
> > So here is the link [0] [1] to the changes for storing and loading of
> stubs which are declared in StubRoutines.
> > This patch covers both aarch64 and x86-64 architectures.
> > The code changes are done on top of AndrewD's patch for storing the
> blobs [2].
> >
> > ---
> >
> > A brief description of the approach for storing StubRoutines stubs is
> warranted as it slightly differs from the
> > technique used for storing other runtime blobs.
> >
> > In the mainline StubRoutines are divided into 4 categories depending on
> when they are generated and their purpose -
> > initial, continuation, compiler and final
> > In comparison to a runtime blob which is stored in its own buffer, a
> StubRoutine stub belongs to a category and all the
> > stubs in a category are stored in the same buffer.
> > This makes the code buffer storing StubRoutine to have multiple entry
> points and these entry points are established as
> > the stubs are generated during the runtime.
> > Moreover, the generation of some stubs is dependent on the availability
> of certain cpu features.
> >
> > So when the buffer for a StubRoutine category is stored in the code
> cache, some extra information needs to be store to
> > be able to identify all the entry points
> > and be able to associate them with the correct stubs when loading the
> buffer.
> >
> > To implement this each stub is given a unique static id irrespective of
> whether its code is generated or not (refer to
> > macro STUB_ROUTINES_STUBS_DO in runtime/stubRoutines.hpp)
> > When the stubs are generated the entry point(s) of the stubs are stored
> in an array (see StubArchiveData::_address_array
> > in runtime/stubCodeGenerator.hpp).
> > As the stubs are generated, the entry points are appended to the array.
> Most of the stubs have only one entry point.
> > In addition to the entry point(s), the end address of the stub is also
> recorded in the array.
> > The end address is used to create StubCodeDesc when the stubs are loaded
> from the code cache.
> >
> > To identify the addresses that belong to a stub, we store a tuple of 2
> elements for each stub: first element is the
> > index of the first entry point of the stub in the _address_array
> > and second element is the number of addresses stored by this stub in the
> _address_array (see StubAddrIndexInfo in
> > runtime/stubCodeGenerator.hpp).
> > For stubs that are not generated, -1 is used for both the elements.
> These tuples are stored in an array
> > StubArchiveData::_index_table indexed by the unique stub id.
> >
> > It is easier to visualize this using a simple example:
> > Assume there are 3 stubs. Stub1 has 2 entry points (S1-1 and S1-2) and
> an end address (E1). Stub2 is not generated.
> > Stub3 has one entry point (S3-1) and end address (E3).
> > For this case the _address_array and _index_table in the StubArchiveData
> would have following entries:
> >
> > _address_array:
> > index:          0          1      2       3       4
> > contents: | S1-1 | S1-2 | E1 | S3-1 | E3 |
> >
> > _index_table:
> > index:          0        1        0
> > contents: | 0, 3 | -1, -1 | 3, 2 |
> >
> > When all the stubs of a category are generated, the _address_array and
> _index_table are stored in the code cache (in
> > SCCache::store_stubroutines_blob).
> > During load time the code along with the _address_array and _index_table
> is read back from the code cache (in
> > SCCReader::compile_stubroutines_blob).
> > The stubs entry points are set up in their respective routines that
> generates the stub (such as generate_call_stub)
> > using the _index_table.
> >
> > As the stubs are generated, their entry points are also registered with
> the SCAddressTable in SCCache.
> > To preserve the order of the SCAddressTable during load, the elements of
> the _address_array are registered when the
> > buffer is loaded (in SCCReader::compile_stubroutines_blob).
> >
> > In addition, StubArchiveData also stores the name of the stubs which is
> used to verify the code located in the code
> > cache is indeed for the stub being loaded.
> >
> > ---
> >
> > Apart from implementing the above approach, this patch also has changes
> to move JFR stubs and throw_exception stubs to
> > SharedRuntime and stores/loads them as a RuntimeStub,
> > as they seem to be a better fit there.
> > There are also some minor improvements to logging to trace the stubs
> generation and store/load times.
> >
> > Lastly, the generated code (stubs and blobs) can be controlled using
> these two options - StoreStubs and LoadStubs.
> >
> > Please review the code and provide your feedback. Let us know if any
> clarification is required.
> >
> > There is still scope of improvement. Some of the things that can be done
> are:
> > - In current scheme if a stub is not generated during training run, but
> gets generated during the production run, the
> > order of SCAddressTable can vary resulting in crash/unexpected behavior
> > - Enum used to enumerate stubs can be improved. AndrewD has the idea of
> a global enum that identifies all the
> > stubs/blobs and that can address this aspect of the patch and the
> limitation in the previous point as well.
> > - Exploring other ways to handle external constant data such as tables
> used by trigonometric stubs which need to be
> > registered in SCAddressTable very early. See
> StubRoutines::stubs_SCAddressTable_init).
> > - Using InternalAddress (or something similar) relocation type for
> targets that are in the same blob, so that they don't
> > need to be fixed on load.
>
> >
> >
> > [0] change sets:
> https://github.com/adinn/leyden/compare/d808ea2..7738ed6
> > <https://github.com/adinn/leyden/compare/d808ea2..7738ed6>
> > [1] branch:
> https://github.com/adinn/leyden/commits/premain-stub-routines/
> > <https://github.com/adinn/leyden/commits/premain-stub-routines/>
> > [2] https://github.com/adinn/leyden/commits/premain-save-generated/
> > <https://github.com/adinn/leyden/commits/premain-save-generated/>
> >
> > Thanks,
> > - Ashutosh Mehra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240711/da2701b2/attachment.htm>

From vladimir.kozlov at oracle.com  Fri Jul 12 04:02:11 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 11 Jul 2024 21:02:11 -0700
Subject: [External] : Re: Save/load StubRoutines
In-Reply-To: <CAKt0pyRQTwYrDF4tRUVnAk2920-HwqPLhjiznqUHKQsr-s4PLg@mail.gmail.com>
References: <CAKt0pyQEHXgJnWyE+vhYFejX18B9xdkKCKwuRi8D+U5NWpQS9w@mail.gmail.com>
 <8cc4f0da-266c-44b0-933f-49ec9b6b6b60@oracle.com>
 <CAKt0pyRQTwYrDF4tRUVnAk2920-HwqPLhjiznqUHKQsr-s4PLg@mail.gmail.com>
Message-ID: <d4455cc0-501e-4728-934b-2d094b401070@oracle.com>


On 7/11/24 7:37 PM, Ashutosh Mehra wrote:
>     LoadStubs should also depends on presence of cached code archive.
> 
> 
> I am not sure I get this. I already have this check in??CDSConfig::check_vm_args_consistency():
> 
>  ? if (!LoadCachedCode && LoadStubs) {
>  ? ? warning("LoadStubs will be ignored without LoadCachedCode");
>  ? ? LoadStubs = false;
>  ? }

You are doing it in check_vm_args_consistency() before we try to open cached code file.
My concern is you may miss open_for_read()/open_for_write() checks on some paths.

Can you check that by -Xshare:auto (to not treat warnings as error) and return `false` from `SCConfig::verify()`?

> 
> and SCCache::load_XXX() routines have this check:
> 
>  ? SCCache* cache = open_for_read();
>  ? if (cache == nullptr) {
>  ? ? return false;
>  ? }
> 
> Wouldn't these checks be sufficient?

Yes, but we need to make sure they exists in all places where needed.

> 
>     Can you explain next change in arraycopy stubs on aarch64?:
>      ? ? ?__ b(RuntimeAddress(byte_copy_entry));
>      ? ? ?__ b(byte_copy_entry);
> 
> 
> Andrew Dinn can explain this change. I am guessing because?byte_copy_entry is in the same CodeBuffer, we don't need to 
> emit any relocation?

Make sense if it is the same CodeBlob.

> 
>     And why is this?:
>     #if 0
>      ? ? ?// This block of code is moved to StubRoutines::x86::init_SCAddressTable()
>      ? ? ?StubRoutines::x86::generate_CRC32C_table(supports_clmul);
>     #endif
> 
> I moved the call that generates?StubRoutines::x86::_crc32c_table to init_SCAddressTable so as to club its registration 
> together with all other constants.
> I forgot to remove this block of code. I will clean it up.

My concern is you move general code into SCC specific code.
If we have to remove SCC code we will lose _crc32c_table initialization.

> 
> Another thing worth pointing out (which may have got overlooked in the large patch) is this change 
> in?StubGenerator::array_overlap_test (in?stubGenerator_x86_64_arraycopy.cpp)
> 
>  ? ?if (NOLp == nullptr) {
> - ? ?ExternalAddress no_overlap(no_overlap_target);
> + ? ?RuntimeAddress no_overlap(no_overlap_target);
>  ? ? ?__ jump_cc(Assembler::belowEqual, no_overlap);
>  ? ? ?__ cmpptr(to, end_from);
>  ? ? ?__ jump_cc(Assembler::aboveEqual, no_overlap);
> 
> It seems like a bug to have ExternalAddress relocation for jump targets. If this change is reverted then debug build 
> fails with following assertion failure:

 From what I see no_overlap_target is `entry` address of previously generated arraycopy stub:

   StubRoutines::_jbyte_disjoint_arraycopy  = generate_disjoint_byte_copy(false, &entry,
                                                                          "jbyte_disjoint_arraycopy");
   StubRoutines::_jbyte_arraycopy           = generate_conjoint_byte_copy(false, entry, &entry_jbyte_arraycopy,
                                                                          "jbyte_arraycopy");

Using RuntimeAddress is correct (I don't like this name and corresponding relocation class - it should be StubAddress or 
something to indicate the address of code in CodeCache and not in VM's runtime). ExternalAddress are used for outside 
CodeCache addresses.

It is an other change we need to push into mainline.

> 
> # ?Internal Error (/home/asmehra/data/ashu-mehra/leyden/src/hotspot/cpu/x86/assembler_x86.cpp:1009), pid=1392250, 
> tid=1392251
> # ?assert(which == call32_operand) failed: jcc has no disp32 or imm
> 
> Same is the case in?StubGenerator::generate_cont_thaw():
> 
> - ?__ jump(ExternalAddress(StubRoutines::throw_StackOverflowError_entry()));
> + ?__ jump(RuntimeAddress(StubRoutines::throw_StackOverflowError_entry()));

Good.

> 
> In this case assertion failure is:
> 
> # ?Internal Error (/home/asmehra/data/ashu-mehra/leyden/src/hotspot/cpu/x86/assembler_x86.cpp:1171), pid=1398423, 
> tid=1398424
> # ?assert(which == call32_operand) failed: call has no disp32 or imm
> 
> Mainline is oblivious to this as the relocations are not emitted for StubRoutines.
> 
> Thanks,
> - Ashutosh Mehra

Thanks,
Vladimir K

> 
> 
> On Thu, Jul 11, 2024 at 1:06?PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Great work, Ashutosh
> 
>     One issue I found recently is that we need to always generate cached code file even if there are no cached nmethods.
>     I use saved stubs code for that. May be we should select one stub or blob which is not under LoadStubs/StoreStubs.
>     May be temporary until we start caching adapter.
> 
>     LoadStubs should also depends on presence of cached code archive.
> 
>      ?> Apart from implementing the above approach, this patch also has changes to move JFR stubs and throw_exception
>     stubs to
>      ?> SharedRuntime and stores/loads them as a RuntimeStub, as they seem to be a better fit there.
> 
>     This should go into mainline (first RFE). I see that it takes majority of changed lines in changeset.
> 
>     There are changes to use InternalAddress instead of ExternalAddress. This should go into mainline too (second RFE).
> 
>     Moved SHA and BASE64 tables in stubGenerator_aarch64.cpp into mainline (third RFE).
> 
>     Can you explain next change in arraycopy stubs on aarch64?:
>      ? ? ?__ b(RuntimeAddress(byte_copy_entry));
>      ? ? ?__ b(byte_copy_entry);
> 
>     And why is this?:
>     #if 0
>      ? ? ?// This block of code is moved to StubRoutines::x86::init_SCAddressTable()
>      ? ? ?StubRoutines::x86::generate_CRC32C_table(supports_clmul);
>     #endif
> 
> 
>     Thanks,
>     Vladimir K
> 
> 
>     On 7/9/24 7:55 AM, Ashutosh Mehra wrote:
>      > Hi all,
>      >
>      > We have been working for some time on storing and loading generated code (stubs and blobs) in the hotspot as part
>     of the
>      > "premain" project.
>      > The code is now in a good enough shape to be shared with a wider audience to get some feedback and comments.
>      >
>      > So here is the link [0] [1] to the changes for storing and loading of stubs which are declared in StubRoutines.
>      > This patch covers both aarch64 and x86-64 architectures.
>      > The code changes are done on top of AndrewD's patch for storing the blobs [2].
>      >
>      > ---
>      >
>      > A brief description of the approach for storing StubRoutines stubs is warranted as it slightly differs from the
>      > technique used for storing other runtime blobs.
>      >
>      > In the mainline StubRoutines are divided into 4 categories depending on when they are generated and their purpose -
>      > initial, continuation, compiler and final
>      > In comparison to a runtime blob which is stored in its own buffer, a StubRoutine stub belongs to a category and
>     all the
>      > stubs in a category are stored in the same buffer.
>      > This makes the code buffer storing StubRoutine to have multiple entry points and these entry points are
>     established as
>      > the stubs are generated during the runtime.
>      > Moreover, the generation of some stubs is dependent on the availability of certain cpu features.
>      >
>      > So when the buffer for a StubRoutine category is stored in the code cache, some extra information needs to be
>     store to
>      > be able to identify all the entry points
>      > and be able to associate them with the correct stubs when loading the buffer.
>      >
>      > To implement this each stub is given a unique static id irrespective of whether its code is generated or not
>     (refer to
>      > macro STUB_ROUTINES_STUBS_DO in runtime/stubRoutines.hpp)
>      > When the stubs are generated the entry point(s) of the stubs are stored in an array (see
>     StubArchiveData::_address_array
>      > in runtime/stubCodeGenerator.hpp).
>      > As the stubs are generated, the entry points are appended to the array. Most of the stubs have only one entry point.
>      > In addition to the entry point(s), the end address of the stub is also recorded in the array.
>      > The end address is used to create StubCodeDesc when the stubs are loaded from the code cache.
>      >
>      > To identify the addresses that belong to a stub, we store a tuple of 2 elements for each stub: first element is the
>      > index of the first entry point of the stub in the _address_array
>      > and second element is the number of addresses stored by this stub in the _address_array (see StubAddrIndexInfo in
>      > runtime/stubCodeGenerator.hpp).
>      > For stubs that are not generated, -1 is used for both the elements. These tuples are stored in an array
>      > StubArchiveData::_index_table indexed by the unique stub id.
>      >
>      > It is easier to visualize this using a simple example:
>      > Assume there are 3 stubs. Stub1 has 2 entry points (S1-1 and S1-2) and an end address (E1). Stub2 is not generated.
>      > Stub3 has one entry point (S3-1) and end address (E3).
>      > For this case the _address_array and _index_table in the StubArchiveData would have following entries:
>      >
>      > _address_array:
>      > index:? ? ? ? ? 0? ? ? ? ? 1 ? ? ?2? ? ? ?3? ? ? ?4
>      > contents: | S1-1 | S1-2 | E1 | S3-1 | E3 |
>      >
>      > _index_table:
>      > index:? ? ? ? ? 0? ? ? ? 1 ? ? ? ?0
>      > contents: | 0, 3 | -1, -1 | 3, 2 |
>      >
>      > When all the stubs of a category are generated, the _address_array and _index_table are stored in the code cache (in
>      > SCCache::store_stubroutines_blob).
>      > During load time the code?along with the _address_array and _index_table is read back from the code cache (in
>      > SCCReader::compile_stubroutines_blob).
>      > The stubs entry points are set up in their respective routines that generates the stub (such as generate_call_stub)
>      > using the _index_table.
>      >
>      > As the stubs are generated, their entry points are also registered with the SCAddressTable in SCCache.
>      > To preserve the order of the SCAddressTable during load, the elements of the _address_array are registered when the
>      > buffer is loaded (in SCCReader::compile_stubroutines_blob).
>      >
>      > In addition, StubArchiveData also stores the name of the stubs which is used to verify the code located in the code
>      > cache is indeed for the stub being loaded.
>      >
>      > ---
>      >
>      > Apart from implementing the above approach, this patch also has changes to move JFR stubs and throw_exception
>     stubs to
>      > SharedRuntime and stores/loads them as a RuntimeStub,
>      > as they seem to be a better fit there.
>      > There are also some minor improvements to logging to trace the stubs generation and store/load times.
>      >
>      > Lastly, the generated code (stubs and blobs) can be controlled using these two options - StoreStubs and LoadStubs.
>      >
>      > Please review the code and provide your feedback. Let us know if any clarification is required.
>      >
>      > There is still scope of improvement. Some of the things that can be done are:
>      > - In current scheme if a stub is not generated during training run, but gets generated during the production run,
>     the
>      > order of SCAddressTable can vary resulting in crash/unexpected behavior
>      > - Enum used to enumerate stubs can be improved. AndrewD has the idea of a global enum that identifies all the
>      > stubs/blobs and that can address this aspect of the patch and the limitation in the previous point as well.
>      > - Exploring other ways to handle external constant data such as tables used by trigonometric stubs which need to be
>      > registered in SCAddressTable very early. See StubRoutines::stubs_SCAddressTable_init).
>      > - Using InternalAddress (or something similar) relocation type for targets that are in the same blob, so that
>     they don't
>      > need to be fixed on load.
> 
>      >
>      >
>      > [0] change sets: https://github.com/adinn/leyden/compare/d808ea2..7738ed6
>     <https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/d808ea2..7738ed6__;!!ACWV5N9M2RV99hQ!MEDDLwSXR4Xh2A7ZEycnLEL-7bhuOuUi-lQY8eotK5pXXPsqLHRDSMnniudrn07KAL0J4iVbU6XZoQWUGMDsMA$>
>      > <https://github.com/adinn/leyden/compare/d808ea2..7738ed6
>     <https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/d808ea2..7738ed6__;!!ACWV5N9M2RV99hQ!MEDDLwSXR4Xh2A7ZEycnLEL-7bhuOuUi-lQY8eotK5pXXPsqLHRDSMnniudrn07KAL0J4iVbU6XZoQWUGMDsMA$>>
>      > [1] branch: https://github.com/adinn/leyden/commits/premain-stub-routines/
>     <https://urldefense.com/v3/__https://github.com/adinn/leyden/commits/premain-stub-routines/__;!!ACWV5N9M2RV99hQ!MEDDLwSXR4Xh2A7ZEycnLEL-7bhuOuUi-lQY8eotK5pXXPsqLHRDSMnniudrn07KAL0J4iVbU6XZoQXDMIPmIw$>
>      > <https://github.com/adinn/leyden/commits/premain-stub-routines/
>     <https://urldefense.com/v3/__https://github.com/adinn/leyden/commits/premain-stub-routines/__;!!ACWV5N9M2RV99hQ!MEDDLwSXR4Xh2A7ZEycnLEL-7bhuOuUi-lQY8eotK5pXXPsqLHRDSMnniudrn07KAL0J4iVbU6XZoQXDMIPmIw$>>
>      > [2] https://github.com/adinn/leyden/commits/premain-save-generated/
>     <https://urldefense.com/v3/__https://github.com/adinn/leyden/commits/premain-save-generated/__;!!ACWV5N9M2RV99hQ!MEDDLwSXR4Xh2A7ZEycnLEL-7bhuOuUi-lQY8eotK5pXXPsqLHRDSMnniudrn07KAL0J4iVbU6XZoQWotIgI3A$>
>      > <https://github.com/adinn/leyden/commits/premain-save-generated/
>     <https://urldefense.com/v3/__https://github.com/adinn/leyden/commits/premain-save-generated/__;!!ACWV5N9M2RV99hQ!MEDDLwSXR4Xh2A7ZEycnLEL-7bhuOuUi-lQY8eotK5pXXPsqLHRDSMnniudrn07KAL0J4iVbU6XZoQWotIgI3A$>>
>      >
>      > Thanks,
>      > - Ashutosh Mehra
> 

From ioi.lam at oracle.com  Fri Jul 12 06:36:10 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Thu, 11 Jul 2024 23:36:10 -0700
Subject: [External] : Re: Draft JEP 8315737: AOT Linked Classes
In-Reply-To: <CAA5_-WZGAguPDrWP32JdK5oKZnZE8L93PuGb-z3OxcZd5vEr9w@mail.gmail.com>
References: <637E6D7A-576B-495D-A626-C7EE4ACF6E92@oracle.com>
 <CA+3eh12x4rj4kLF4isopG9q8BVzjOeH52w+ULV0hsFCHA41zog@mail.gmail.com>
 <9e396c07-0fe0-44e5-9b6e-ee0e4eba7eb2@oracle.com>
 <CA+3eh119VHVKBNSrHYyYfuXMoSK9b9ysBUOx8MzHRLJAya5bYQ@mail.gmail.com>
 <68e54b4e-5cb8-423c-a5ec-ea9ab4397ff9@oracle.com>
 <CAA5_-WZGAguPDrWP32JdK5oKZnZE8L93PuGb-z3OxcZd5vEr9w@mail.gmail.com>
Message-ID: <c7cd1640-c056-429c-aa4e-85090d504502@oracle.com>


On 7/11/24 12:54 AM, Sanne Grinovero wrote:
>
> Apologies for intervening with possibly very?naive questions, as I'm 
> new here - but very curious about this:
>
> On Wed, Jul 10, 2024 at 11:43?PM <ioi.lam at oracle.com> wrote:
>
>
>     On 7/10/24 6:41 AM, Volker Simonis wrote:
>     > Hi Ioi,
>     >
>     > Thanks for the clarification. I wasn't aware of the fact, that only
>     > static CDS archives can contain archived heap objects. The official
>     > CDS documentation [1] is also not mentioning this. In contrary, it
>     > states that:
>     >
>     >> The names "static" and "dynamic" are used for historical
>     reasons. The only significance is that the "static" archive is
>     loaded first and the "dynamic" archive is loaded second.
>     > So maybe that documentation should be updated to make it clear that
>     > static CDS archives are more powerful?
>
>     I have filed https://bugs.openjdk.org/browse/JDK-8336147
>
>
>     > Is there a conceptual reason for why dynamic archives can not
>     contain
>     > heap objects or is this just an implementation issue that could be
>     > solved? Maybe because G1 can currently only map a single heap region
>     > from file?
>
>     The reasons that heap objects cannot be stored in the dynamic archive:
>
>     - The dynamic dump happens at the end of program execution. GC might
>     have moved the objects around. If there?s a reference from the
>     achievable objects from the dynamic archive that points to the
>     archivable objects in the static archive, keeping track of that is
>     difficult.
>
>
> As someone who has no clue about how this is actually implemented, I 
> find this puzzling: since the program is being terminated, why would 
> GC still be allowed to actively move things around?
> I would have expected at this point for the heap to be "frozen": GC is 
> terminated first, and only then the dump would be captured?
>

Hi Sanne,

The dynamic dump happens after (1) the static archive is loaded, and (2) 
the application executes and exits the VM. The archived heap objects in 
the static archive are loaded at (1). Between (1) and (2), multiple GC 
could have happened and moved the archived objects around.

At (2), if we have an object A we want to archive, and A has a pointer 
that points to location 0x1234, we will have no idea whether 0x1234 came 
from the archived objects from the static archive, or something that was 
created between (1) and (2).


> Is it the case that GC is a potentially necessary service to the 
> process of capturing the dump? I would have assumed some separation in 
> the design, to have the dumping process run in its own heap or its own 
> process altogether.
>
>     - The dynamic run may mutate objects in the static archive. For
>     example,
>     for invokedynamic support, if we have a MethodType for a class in the
>     dynamic archive, this MT needs to be entered into a global hashtable
>     that?s rooted in the static archive
>     (java.lang.invoke.MethodType::internTable).
>
>     Instead of just fixing the 2-level problem between static and dynamic
>     archives, folks like John Rose and Dan Heidinga are working on
>     general
>     designs that would support multiple groups of archived heap
>     objects that
>     have cross references between these groups.
>
>     In the near future, Leyden optimization will be based on the static
>     archive only, as many optimizations rely on snapshots of heap objects.
>
>
> With that, do you mean that many more optimizations are reserved for 
> after the?new design is implemented?
>

Not exactly.

We are implementing many new?optimizations, but these new optimizations 
can be used only with the static archive. In fact, most new 
optimizations are tied to the new -XX:CacheDataStore flag, which 
specifies the location of a static archive.

We expect that the caching of "system" states can be done without the 
"Egg" API, which is our internal name for resolving the references 
between multiple groups of archived Java objects. However, for user code 
to cache their own objects (e.g., ahead-of-time generation of an 
application-specific hashtable) may need to wait for the Egg API.


Thanks

- Ioi


> Many thanks
> ?-- Sanne
>
>
>
>     Thanks
>
>     - Ioi
>
>
>
>     >
>     > Thank you and best regards,
>     > Volker
>     >
>     > [1]
>     https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing
>     >
>     > On Tue, Jul 9, 2024 at 7:32?AM <ioi.lam at oracle.com> wrote:
>     >> On 7/8/24 6:52 AM, Volker Simonis wrote:
>     >>
>     >> The way you describe the manual usage of CDS is "old" and quite
>     >> cumbersome. Why not use the new -XX:+AutoCreateSharedArchive option
>     >> which automatically creates the archive if non is available. Or
>     does
>     >> -XX:+AOTLoadedClasses not work together with
>     >> -XX:+AutoCreateSharedArchive and if so, why not?
>     >>
>     >> -XX:+AutoCreateSharedArchive is for creating dynamic CDS
>     archives only. It cannot be used for creating static CDS archives.
>     >>
>     >> -XX:+AOTLoadedClasses works for both dynamic and static CDS
>     archives. However, as part of this JEP, to demonstrate its
>     promises, we will also implement one significant optimization that
>     relies on -XX:+AOTLoadedClasses:
>     >>
>     >>? ? ? JDK-8293336 Store LambdaForms in CDS archive heap
>     >>
>     >> JDK-8293336 works only for the static CDS archive (it requires
>     archiving Java heap objects, which is not supported by dynamic CDS
>     archives).
>     >>
>     >> Thanks
>     >>
>     >> - Ioi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240711/8fd7d10c/attachment.htm>

From adinn at redhat.com  Mon Jul 15 15:34:29 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 15 Jul 2024 16:34:29 +0100
Subject: Save/load StubRoutines
In-Reply-To: <8cc4f0da-266c-44b0-933f-49ec9b6b6b60@oracle.com>
References: <CAKt0pyQEHXgJnWyE+vhYFejX18B9xdkKCKwuRi8D+U5NWpQS9w@mail.gmail.com>
 <8cc4f0da-266c-44b0-933f-49ec9b6b6b60@oracle.com>
Message-ID: <e6f5caef-e69b-46f0-ace5-1a89723c8039@redhat.com>

On 11/07/2024 18:05, Vladimir Kozlov wrote:
> One issue I found recently is that we need to always generate cached
>  code file even if there are no cached nmethods. I use saved stubs
> code for that. May be we should select one stub or blob which is not
> under LoadStubs/StoreStubs. May be temporary until we start caching
> adapter.

I think the original x86 code that saved and restored generated routines
was saving multiplyToLen, squareToLen and mulAdd, each in their own
blob. There are now equivalent save/restore points for aarch64. We could
always save one of them irrespective of the setting of StoreStubs.

> LoadStubs should also depends on presence of cached code archive.
> 
>> Apart from implementing the above approach, this patch also has
> changes to move JFR stubs and throw_exception stubs to
>> SharedRuntime and stores/loads them as a RuntimeStub, as they seem
>> to
> be a better fit there.
> 
> This should go into mainline (first RFE). I see that it takes
> majority of changed lines in changeset.

I'll link A JIRA for this as a subtask when I raise an over-arching
cleanup JIRA for mainline. Likewise for the next two comments

> There are changes to use InternalAddress instead of ExternalAddress.
>  This should go into mainline too (second RFE).

As above.

> Moved SHA and BASE64 tables in stubGenerator_aarch64.cpp into
> mainline (third RFE).

As above.

> Can you explain next change in arraycopy stubs on aarch64?: __
> b(RuntimeAddress(byte_copy_entry)); __ b(byte_copy_entry);

The branch here is internal to the blob containing the arraycopy entries
and sub-entries. So, we don't actually need to use a relocation here. A
branch to a raw address within the blob can and will always be encoded 
using a PC-relative jump.

I wanted to do this for all internal branches. It allows us accumulate
entries for all routines in a given blob and publish them to the address
table at the end of generation. Likewise, we can accumulate entry
addresses while loading routines from a blob and publish at the end. The
basic advantage is that it simplifies the publication process since
publications happens all at once rather than routine by routine.
However, it also makes error handling easier. If we encounter a
read/store error or configuration mismatch when saving or loading a
specific runtime blob we can regenerate the routines without referencing
the cache and publish the addresses for use by later blobs without
having to back entries out of the address table.

Unfortunately, we are still using a RuntimeAddress to branch within
the same code buffer on both x86 and aarch64. This only happens for one 
published entry on AArch64 (zero_blocks). This entry gets called from
copy routines within its own blob and also from the compilers. In both
cases the call must be preceded by some extra logic so both the
generator and compiler rely on the macro assembler to plant the preamble
and call. If we tweak the macro assembler to export a variant of the
API method that allows the call to be planted with a direct address
rather than a RuntimeAddress then this can be fixed.

On x86 I think Ashu faced the problem that there was that there was no 
way to plant a call to a raw address. There is the option of using an 
InternalAddress but that only works for loads and stores of data addresses.

I think the above problem was also what led Ashu to use RuntimeAddress 
(rather than ExternalAddress) to identify the no_overlap target for the 
array copy stubs. That works, but only because we publish entries for 
each routine to the address table immediately after generating the 
routine. I agree that we probably need t fix this with something like a 
StubAddress class as a way of identifying a call target within the 
current stub that does not require a relocation. It should be easy to 
verify that the target is actually in the current code buffer and 
reachable using a local jump. Perhaps we need to add a similar Address 
subtype to AArch64? As you say this can be introduced as a mainline cleanup.

> And why is this?: #if 0 // This block of code is moved to 
> StubRoutines::x86::init_SCAddressTable() 
> StubRoutines::x86::generate_CRC32C_table(supports_clmul); #endif

As Ashu said, this is to unify the process of initializing stub routine 
data so that it can be published at init time. I think we need to add 
some explicit initialization process to mainline as part of the stub 
generation cleanup which we can then extend in Leyden to also do address 
table publication.

I'll start raising JIRA issues for these problems against mainline  as 
soon as possible.

regards,


Andrew Dinn
-----------


From adinn at redhat.com  Mon Jul 15 16:23:36 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 15 Jul 2024 17:23:36 +0100
Subject: premain: Possible solutions to use runtime G1 region grain size in
 AOT code (JDK-8335440)
Message-ID: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>

I have prototyped two (aarch64-specific) solutions for JDK-8335440 both 
of which fix the G1 write barrier in AOT code to use the runtime region 
grain size. Both solutions make AOT code resilient to any change in max 
heap between assembly and production runs.

The problem arises because ergonomics uses the heap size to derive a G1 
region size and the latter size determines what shift is needed to 
convert a store address to a card table index. In currently generated 
nmethod and *stub* code) the shift count is installed as an immediate 
operand of a generated shift instruction. In AOT code the shift counts 
needs to be appropriate to the current runtime region size. AOT code can 
resolve this requirement in two ways. It can load the shift from a well 
known location and supply the shift count as a register operand. 
Alternatively, it can employ load-time rewriting of the instruction 
stream to update the immediate operand.

Both current solutions rely on loading rather than instruction 
rewriting. The first solution installs the shift count in a (byte) field 
added to every Java thread. It modifies barrier generation when the 
SCCache is open for writing to load the shift count from the thread 
field. This solution requires no relocation when the AOT stub/nmethod is 
loaded from the cache since the load is always at a fixed offset from 
the thread register. If the SCCache is not open for writing the count is 
generated as normal i.e. as an immediate operand.

 
https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-thread

The second solution modifies barrier generation when the SCCache is open 
for writing to load the shift count from a runtime field, 
G1HeapRegion::LogHRGrainSize i.e. the same field that determines the 
immediate count used for normal generation. In order to make this 
visible to the compilers and SCC address table the address of this field 
is exported via the card table. This solution requires the AOT code to 
reference the target address using a runtime address relocation. Once 
again, if the SCCache is not open for writing the count is generated as 
normal i.e. as an immediate operand.

 
https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-memory

I ran the javac benchmark with each of these solutions compared against 
the equivalent premain build. Neither indicated any noticeable change in 
execution time -- at least not within the margins of error of the test 
runs (which, on my M2 machine were +/- 5 msecs in a 95 msec run). A 
better test might be to take a long running app and see if the change to 
the AOT barrier code introduced any change in overall execution time.

I implemented these two solutions first because neither of them requires 
implementing any new relocations. There are two alternatives which would 
require new relocations that may still be worth investigating. Option 
three is to mark the shift instruction with a new relocation. Patching 
of the relocation address would simply require regenerating it with an 
immediate that matches (log2 of the) current region size.

The fourth option is to load the shift count from a data area associated 
with the current blob. In the case of an nmethod this would be the 
nmethod constants section. In the case of a generated stub this would 
have to be a dedicated memory address in its associated blob. Either way 
the data location would need to be marked with a new relocation. 
Patching of the relocation address would simply require copying the 
(log2 of the) current region size ito the data area.

I'll hold off on adding these solutions (also on implementing the x86 
versions -- well, more likely, letting Ashu provide them ;-) until I get 
some feedback on these first two. I'll also see if I can get any better 
indication of whether the performance of the first two solutions is an 
issue. I think solution one is by far the simplest, resolving the 
immediate issue with least fuss (note that I poked the necessary data 
byte into a hole in the thread record so it has no space implications). 
However, if we end up having to tweak generated code to deal with other 
config changes the alternatives may be worth investing in as they might 
scale better.

regards,


Andrew Dinn
-----------


From duke at openjdk.org  Mon Jul 15 18:36:43 2024
From: duke at openjdk.org (duke)
Date: Mon, 15 Jul 2024 18:36:43 GMT
Subject: git: openjdk/leyden: premain: 2 new changesets
Message-ID: <933bc0e0-29b9-44a3-b088-b9bc9d959166@openjdk.org>

Changeset: 77eff765
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-15 09:30:06 +0000
URL:       https://git.openjdk.org/leyden/commit/77eff76508160bc5acedc0fdc5aef7d9d5c885c2

Added Pet Clinic benchmark to track performance of JEP-8315737

! test/hotspot/jtreg/premain/spring-petclinic/Makefile

Changeset: ded7dae0
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-15 11:34:16 +0000
URL:       https://git.openjdk.org/leyden/commit/ded7dae0246df3b6dfec6702a3aad54974b3a67e

Work-around JDK-8336414 which causes failure in ResolvedConstants.java

! test/hotspot/jtreg/runtime/cds/appcds/resolvedConstants/ResolvedConstants.java


From duke at openjdk.org  Mon Jul 15 20:55:11 2024
From: duke at openjdk.org (duke)
Date: Mon, 15 Jul 2024 20:55:11 GMT
Subject: git: openjdk/leyden: premain: 6 new changesets
Message-ID: <5eee14dc-4440-4d3e-b8fb-6c88308b9c9c@openjdk.org>

Changeset: f519a8a9
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-06-24 12:23:47 +0000
URL:       https://git.openjdk.org/leyden/commit/f519a8a9a17c077a192dc16893e63d9a832a4bcd

Removed incorrect message "Cannot dump shared archive while using shared archive"

! src/hotspot/share/cds/cdsConfig.cpp

Changeset: c2a5c9ac
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-06 09:36:41 +0000
URL:       https://git.openjdk.org/leyden/commit/c2a5c9acf0b45f852ec885d2ace0247a2b62a759

8335804: ArchiveInvokeDynamic causes BootstrapMethodError

! src/java.base/share/classes/java/lang/invoke/MethodType.java

Changeset: 4c385b55
Branch: premain
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-07-10 12:24:44 +0000
URL:       https://git.openjdk.org/leyden/commit/4c385b55ad96e049182beda3a0ac78c2914b4e95

8336033: [premain] assert(comp != nullptr) when using SCCache with -XX:TieredStopAtLevel=1

! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/compiler/compilationPolicy.cpp

Changeset: d47557ad
Branch: premain
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-07-10 13:08:17 +0000
URL:       https://git.openjdk.org/leyden/commit/d47557adf843bea792ca45b45502ba8748e0c6ad

Cache few stubs on aarch64 similar to x64 to avoid empty cached code

! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

Changeset: 1b665a99
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-10 15:28:16 +0000
URL:       https://git.openjdk.org/leyden/commit/1b665a998a9f15105fbf6b8e56868e895e8d373a

8336144: assert(CDSConfig::is_dumping_invokedynamic()) when ZGC is used during archive creation

! src/hotspot/share/cds/heapShared.cpp

Changeset: 7ae716cf
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-15 11:53:50 +0000
URL:       https://git.openjdk.org/leyden/commit/7ae716cf9302db84304d825b2474e81a5d825abf

Merge branch 'premain-ea' of https://github.com/openjdk/leyden into premain

! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.cpp


From vladimir.kozlov at oracle.com  Mon Jul 15 21:35:15 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 15 Jul 2024 14:35:15 -0700
Subject: [External] : Re: Save/load StubRoutines
In-Reply-To: <e6f5caef-e69b-46f0-ace5-1a89723c8039@redhat.com>
References: <CAKt0pyQEHXgJnWyE+vhYFejX18B9xdkKCKwuRi8D+U5NWpQS9w@mail.gmail.com>
 <8cc4f0da-266c-44b0-933f-49ec9b6b6b60@oracle.com>
 <e6f5caef-e69b-46f0-ace5-1a89723c8039@redhat.com>
Message-ID: <2875d712-8b72-41c3-b520-4cb1b4f69df6@oracle.com>

On 7/15/24 8:34 AM, Andrew Dinn wrote:
> On 11/07/2024 18:05, Vladimir Kozlov wrote:
>> One issue I found recently is that we need to always generate cached
>> ?code file even if there are no cached nmethods. I use saved stubs
>> code for that. May be we should select one stub or blob which is not
>> under LoadStubs/StoreStubs. May be temporary until we start caching
>> adapter.
> 
> I think the original x86 code that saved and restored generated routines
> was saving multiplyToLen, squareToLen and mulAdd, each in their own
> blob. There are now equivalent save/restore points for aarch64. We could
> always save one of them irrespective of the setting of StoreStubs.

Yes, that is what I already did:

https://github.com/openjdk/leyden/commit/d47557adf843bea792ca45b45502ba8748e0c6ad

But they are used for C2 only. We need something general.
How about `generate_forward_exception()`? It is first general stub generated on both platforms.

> 
>> LoadStubs should also depends on presence of cached code archive.
>>
>>> Apart from implementing the above approach, this patch also has
>> changes to move JFR stubs and throw_exception stubs to
>>> SharedRuntime and stores/loads them as a RuntimeStub, as they seem
>>> to
>> be a better fit there.
>>
>> This should go into mainline (first RFE). I see that it takes
>> majority of changed lines in changeset.
> 
> I'll link A JIRA for this as a subtask when I raise an over-arching
> cleanup JIRA for mainline. Likewise for the next two comments

Thank you.

> 
>> There are changes to use InternalAddress instead of ExternalAddress.
>> ?This should go into mainline too (second RFE).
> 
> As above.
> 
>> Moved SHA and BASE64 tables in stubGenerator_aarch64.cpp into
>> mainline (third RFE).
> 
> As above.
> 
>> Can you explain next change in arraycopy stubs on aarch64?: __
>> b(RuntimeAddress(byte_copy_entry)); __ b(byte_copy_entry);
> 
> The branch here is internal to the blob containing the arraycopy entries
> and sub-entries. So, we don't actually need to use a relocation here. A
> branch to a raw address within the blob can and will always be encoded using a PC-relative jump.
> 
> I wanted to do this for all internal branches. It allows us accumulate
> entries for all routines in a given blob and publish them to the address
> table at the end of generation. Likewise, we can accumulate entry
> addresses while loading routines from a blob and publish at the end. The
> basic advantage is that it simplifies the publication process since
> publications happens all at once rather than routine by routine.
> However, it also makes error handling easier. If we encounter a
> read/store error or configuration mismatch when saving or loading a
> specific runtime blob we can regenerate the routines without referencing
> the cache and publish the addresses for use by later blobs without
> having to back entries out of the address table.

This sounds good.

> 
> Unfortunately, we are still using a RuntimeAddress to branch within
> the same code buffer on both x86 and aarch64. This only happens for one published entry on AArch64 (zero_blocks). This 
> entry gets called from
> copy routines within its own blob and also from the compilers. In both
> cases the call must be preceded by some extra logic so both the
> generator and compiler rely on the macro assembler to plant the preamble
> and call. If we tweak the macro assembler to export a variant of the
> API method that allows the call to be planted with a direct address
> rather than a RuntimeAddress then this can be fixed.

Can we have some kind of wrapper for case when we need RuntimeAddress?
May be have it in separate blob to not affect your implementation.

> 
> On x86 I think Ashu faced the problem that there was that there was no way to plant a call to a raw address. There is 
> the option of using an InternalAddress but that only works for loads and stores of data addresses.
> 
> I think the above problem was also what led Ashu to use RuntimeAddress (rather than ExternalAddress) to identify the 
> no_overlap target for the array copy stubs. That works, but only because we publish entries for each routine to the 
> address table immediately after generating the routine. I agree that we probably need t fix this with something like a 
> StubAddress class as a way of identifying a call target within the current stub that does not require a relocation. It 
> should be easy to verify that the target is actually in the current code buffer and reachable using a local jump. 
> Perhaps we need to add a similar Address subtype to AArch64? As you say this can be introduced as a mainline cleanup.

Yes, please do.

> 
>> And why is this?: #if 0 // This block of code is moved to StubRoutines::x86::init_SCAddressTable() 
>> StubRoutines::x86::generate_CRC32C_table(supports_clmul); #endif
> 
> As Ashu said, this is to unify the process of initializing stub routine data so that it can be published at init time. I 
> think we need to add some explicit initialization process to mainline as part of the stub generation cleanup which we 
> can then extend in Leyden to also do address table publication.
> 
> I'll start raising JIRA issues for these problems against mainline? as soon as possible.

Thank you, Andrew

Vladimir K

> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From vladimir.kozlov at oracle.com  Mon Jul 15 21:54:21 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 15 Jul 2024 14:54:21 -0700
Subject: premain: Possible solutions to use runtime G1 region grain size
 in AOT code (JDK-8335440)
In-Reply-To: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
Message-ID: <77b754dd-cc5e-4da1-94bb-6620075fed59@oracle.com>

On 7/15/24 9:23 AM, Andrew Dinn wrote:
> I have prototyped two (aarch64-specific) solutions for JDK-8335440 both of which fix the G1 write barrier in AOT code to 
> use the runtime region grain size. Both solutions make AOT code resilient to any change in max heap between assembly and 
> production runs.
> 
> The problem arises because ergonomics uses the heap size to derive a G1 region size and the latter size determines what 
> shift is needed to convert a store address to a card table index. In currently generated nmethod and *stub* code) the 
> shift count is installed as an immediate operand of a generated shift instruction. In AOT code the shift counts needs to 
> be appropriate to the current runtime region size. AOT code can resolve this requirement in two ways. It can load the 
> shift from a well known location and supply the shift count as a register operand. Alternatively, it can employ 
> load-time rewriting of the instruction stream to update the immediate operand.
> 
> Both current solutions rely on loading rather than instruction rewriting. The first solution installs the shift count in 
> a (byte) field added to every Java thread. It modifies barrier generation when the SCCache is open for writing to load 
> the shift count from the thread field. This solution requires no relocation when the AOT stub/nmethod is loaded from the 
> cache since the load is always at a fixed offset from the thread register. If the SCCache is not open for writing the 
> count is generated as normal i.e. as an immediate operand.
> 
> 
> https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-thread

My main concern with first solution is that we add a field to `Thread` class which will be used only at the start by AOT 
code. This is also load which may miss CPU's cache.

On other hand it is "straight-forward" simple change.

> 
> The second solution modifies barrier generation when the SCCache is open for writing to load the shift count from a 
> runtime field, G1HeapRegion::LogHRGrainSize i.e. the same field that determines the immediate count used for normal 
> generation. In order to make this visible to the compilers and SCC address table the address of this field is exported 
> via the card table. This solution requires the AOT code to reference the target address using a runtime address 
> relocation. Once again, if the SCCache is not open for writing the count is generated as normal i.e. as an immediate 
> operand.
> 
> 
> https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-memory

This is more complicated change which looks like half-step to direction to have separate relocation for it.


> 
> I ran the javac benchmark with each of these solutions compared against the equivalent premain build. Neither indicated 
> any noticeable change in execution time -- at least not within the margins of error of the test runs (which, on my M2 
> machine were +/- 5 msecs in a 95 msec run). A better test might be to take a long running app and see if the change to 
> the AOT barrier code introduced any change in overall execution time.
> 
> I implemented these two solutions first because neither of them requires implementing any new relocations. There are two 
> alternatives which would require new relocations that may still be worth investigating. Option three is to mark the 
> shift instruction with a new relocation. Patching of the relocation address would simply require regenerating it with an 
> immediate that matches (log2 of the) current region size.

Please, try this approach (new relocation).

Thanks,
Vladimir K

> 
> The fourth option is to load the shift count from a data area associated with the current blob. In the case of an 
> nmethod this would be the nmethod constants section. In the case of a generated stub this would have to be a dedicated 
> memory address in its associated blob. Either way the data location would need to be marked with a new relocation. 
> Patching of the relocation address would simply require copying the (log2 of the) current region size ito the data area.
> 
> I'll hold off on adding these solutions (also on implementing the x86 versions -- well, more likely, letting Ashu 
> provide them ;-) until I get some feedback on these first two. I'll also see if I can get any better indication of 
> whether the performance of the first two solutions is an issue. I think solution one is by far the simplest, resolving 
> the immediate issue with least fuss (note that I poked the necessary data byte into a hole in the thread record so it 
> has no space implications). However, if we end up having to tweak generated code to deal with other config changes the 
> alternatives may be worth investing in as they might scale better.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From duke at openjdk.org  Mon Jul 15 22:11:28 2024
From: duke at openjdk.org (duke)
Date: Mon, 15 Jul 2024 22:11:28 GMT
Subject: git: openjdk/leyden: premain: Add missing far branch checks on aarch64
 to generate trampolines
Message-ID: <7edd68c1-78c1-4ef1-ab38-25e23c89c8d3@openjdk.org>

Changeset: b949235f
Branch: premain
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-07-15 15:09:51 +0000
URL:       https://git.openjdk.org/leyden/commit/b949235f5d05e51ddde79e51585f07fe1ba66d9d

Add missing far branch checks on aarch64 to generate trampolines

! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp


From duke at openjdk.org  Tue Jul 16 03:39:51 2024
From: duke at openjdk.org (duke)
Date: Tue, 16 Jul 2024 03:39:51 GMT
Subject: git: openjdk/leyden: premain: Fixed CDS failures in tier3
 (-XX:+UseSerialGC, -XX:+UseZGC, etc)
Message-ID: <5dc38f55-3a8c-4fe3-bb71-14a9530a1f0e@openjdk.org>

Changeset: 34484563
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-15 20:38:42 +0000
URL:       https://git.openjdk.org/leyden/commit/3448456351f213f745280b4be46af920913925a4

Fixed CDS failures in tier3 (-XX:+UseSerialGC, -XX:+UseZGC, etc)

! test/hotspot/jtreg/runtime/cds/DeterministicDump.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/HelidonQuickStartSE.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/MicronautFirstApp.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeyden.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeydenOldWF.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InvalidFileFormat.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java


From duke at openjdk.org  Tue Jul 16 06:19:12 2024
From: duke at openjdk.org (duke)
Date: Tue, 16 Jul 2024 06:19:12 GMT
Subject: git: openjdk/leyden: premain: More fixes for CDS failures in tier3
 (-XX:+UseZGC, etc)
Message-ID: <3fda59bf-19fb-4fa1-bcc8-04764c182e71@openjdk.org>

Changeset: f1c370f9
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-15 23:17:41 +0000
URL:       https://git.openjdk.org/leyden/commit/f1c370f9b6996e4ec3a31ef1fe761c9ee88a6668

More fixes for CDS failures in tier3 (-XX:+UseZGC, etc)

! test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/PreloadedClassesVerification.java


From ioi.lam at oracle.com  Tue Jul 16 16:33:56 2024
From: ioi.lam at oracle.com (ioi.lam at oracle.com)
Date: Tue, 16 Jul 2024 09:33:56 -0700
Subject: premain: Possible solutions to use runtime G1 region grain size
 in AOT code (JDK-8335440)
In-Reply-To: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
Message-ID: <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>


On 7/15/24 9:23 AM, Andrew Dinn wrote:
> I have prototyped two (aarch64-specific) solutions for JDK-8335440 
> both of which fix the G1 write barrier in AOT code to use the runtime 
> region grain size. Both solutions make AOT code resilient to any 
> change in max heap between assembly and production runs.
>
> The problem arises because ergonomics uses the heap size to derive a 
> G1 region size and the latter size determines what shift is needed to 
> convert a store address to a card table index. In currently generated 
> nmethod and *stub* code) the shift count is installed as an immediate 
> operand of a generated shift instruction. In AOT code the shift counts 
> needs to be appropriate to the current runtime region size. AOT code 
> can resolve this requirement in two ways. It can load the shift from a 
> well known location and supply the shift count as a register operand. 
> Alternatively, it can employ load-time rewriting of the instruction 
> stream to update the immediate operand.
>
> Both current solutions rely on loading rather than instruction 
> rewriting. The first solution installs the shift count in a (byte) 
> field added to every Java thread. It modifies barrier generation when 
> the SCCache is open for writing to load the shift count from the 
> thread field. This solution requires no relocation when the AOT 
> stub/nmethod is loaded from the cache since the load is always at a 
> fixed offset from the thread register. If the SCCache is not open for 
> writing the count is generated as normal i.e. as an immediate operand.
>
>
> https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-thread 
>
>
> The second solution modifies barrier generation when the SCCache is 
> open for writing to load the shift count from a runtime field, 
> G1HeapRegion::LogHRGrainSize i.e. the same field that determines the 
> immediate count used for normal generation. In order to make this 
> visible to the compilers and SCC address table the address of this 
> field is exported via the card table. This solution requires the AOT 
> code to reference the target address using a runtime address 
> relocation. Once again, if the SCCache is not open for writing the 
> count is generated as normal i.e. as an immediate operand.
>
>
Is the G1HeapRegion::LogHRGrainSize loaded with PC offset?

 ??? ldr grain, [pc, #5678]

I suppose this require us to put multiple copies of 
G1HeapRegion::LogHRGrainSize inside the AOT code, as there's a limit for 
the offset. But we will be patching fewer places than every sites that 
needs to know the grain size.

Thanks

- Ioi

> https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-memory 
>
>
> I ran the javac benchmark with each of these solutions compared 
> against the equivalent premain build. Neither indicated any noticeable 
> change in execution time -- at least not within the margins of error 
> of the test runs (which, on my M2 machine were +/- 5 msecs in a 95 
> msec run). A better test might be to take a long running app and see 
> if the change to the AOT barrier code introduced any change in overall 
> execution time.
>
> I implemented these two solutions first because neither of them 
> requires implementing any new relocations. There are two alternatives 
> which would require new relocations that may still be worth 
> investigating. Option three is to mark the shift instruction with a 
> new relocation. Patching of the relocation address would simply 
> require regenerating it with an immediate that matches (log2 of the) 
> current region size.
>
> The fourth option is to load the shift count from a data area 
> associated with the current blob. In the case of an nmethod this would 
> be the nmethod constants section. In the case of a generated stub this 
> would have to be a dedicated memory address in its associated blob. 
> Either way the data location would need to be marked with a new 
> relocation. Patching of the relocation address would simply require 
> copying the (log2 of the) current region size ito the data area.
>
> I'll hold off on adding these solutions (also on implementing the x86 
> versions -- well, more likely, letting Ashu provide them ;-) until I 
> get some feedback on these first two. I'll also see if I can get any 
> better indication of whether the performance of the first two 
> solutions is an issue. I think solution one is by far the simplest, 
> resolving the immediate issue with least fuss (note that I poked the 
> necessary data byte into a hole in the thread record so it has no 
> space implications). However, if we end up having to tweak generated 
> code to deal with other config changes the alternatives may be worth 
> investing in as they might scale better.
>
> regards,
>
>
> Andrew Dinn
> -----------
>

From duke at openjdk.org  Tue Jul 16 22:21:41 2024
From: duke at openjdk.org (duke)
Date: Tue, 16 Jul 2024 22:21:41 GMT
Subject: git: openjdk/leyden: premain: 8336562: Quit CacheDataStore creation
 when incompatible module options are specified
Message-ID: <e88d9595-6f95-4e5c-ae29-9287483d6360@openjdk.org>

Changeset: baad503c
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-16 15:18:22 +0000
URL:       https://git.openjdk.org/leyden/commit/baad503cdfe485e0031032dfdb33b42674e08868

8336562: Quit CacheDataStore creation when incompatible module options are specified

! src/hotspot/share/cds/cdsConfig.cpp


From duke at openjdk.org  Wed Jul 17 05:48:34 2024
From: duke at openjdk.org (duke)
Date: Wed, 17 Jul 2024 05:48:34 GMT
Subject: git: openjdk/leyden: premain-ea: 3 new changesets
Message-ID: <401a9c0a-099a-42bb-8ad9-18b3b3e3a6a5@openjdk.org>

Changeset: 4bac5115
Branch: premain-ea
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-15 20:38:42 +0000
URL:       https://git.openjdk.org/leyden/commit/4bac5115243e23f7ddad4986493a012ea689f39a

Fixed CDS failures in tier3 (-XX:+UseSerialGC, -XX:+UseZGC, etc)

! test/hotspot/jtreg/runtime/cds/DeterministicDump.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/HelidonQuickStartSE.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/JavacBench.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/MicronautFirstApp.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/QuarkusGettingStarted.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeyden.java
! test/hotspot/jtreg/runtime/cds/appcds/applications/spring-petclinic/SpringPetClinicLeydenOldWF.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/InvalidFileFormat.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/SharedStringsHumongous.java

Changeset: 16ee1712
Branch: premain-ea
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-15 23:17:41 +0000
URL:       https://git.openjdk.org/leyden/commit/16ee1712c667df7c9603ba8271d7c2e3dd465204

More fixes for CDS failures in tier3 (-XX:+UseZGC, etc)

! test/hotspot/jtreg/runtime/cds/appcds/preloadedClasses/PreloadedClassesVerification.java

Changeset: 6a824667
Branch: premain-ea
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-16 15:18:22 +0000
URL:       https://git.openjdk.org/leyden/commit/6a8246673272886021b6897b56d454c6f30ce42b

8336562: Quit CacheDataStore creation when incompatible module options are specified

! src/hotspot/share/cds/cdsConfig.cpp


From adinn at redhat.com  Wed Jul 17 10:15:04 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 17 Jul 2024 11:15:04 +0100
Subject: premain: Possible solutions to use runtime G1 region grain size
 in AOT code (JDK-8335440)
In-Reply-To: <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
Message-ID: <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>

Hi Ioi,

On 16/07/2024 17:33, ioi.lam at oracle.com wrote:
> 
> On 7/15/24 9:23 AM, Andrew Dinn wrote:
>> . . .
>> The second solution modifies barrier generation when the SCCache is 
>> open for writing to load the shift count from a runtime field, 
>> G1HeapRegion::LogHRGrainSize i.e. the same field that determines the 
>> immediate count used for normal generation. In order to make this 
>> visible to the compilers and SCC address table the address of this 
>> field is exported via the card table. This solution requires the AOT 
>> code to reference the target address using a runtime address 
>> relocation. Once again, if the SCCache is not open for writing the 
>> count is generated as normal i.e. as an immediate operand.
>>
>>
> Is the G1HeapRegion::LogHRGrainSize loaded with PC offset?
> 
>  ??? ldr grain, [pc, #5678]

That's not what this option does. The barroer loads the grain size 
indirectly via a constant static field address, i.e. via address 
&G1HeapRegion::LogHRGrainSize (well, actually, the constant is 
determined by whatever address is reported by the barrier card table but 
effectively it is &G1HeapRegion::LogHRGrainSize). So the barrier 
includes uses a sequence like this

   movz reg #<16bit>
   movk reg #<16bit>, #16
   movk reg #<16bit>, #32
   ldrb reg, reg
   . . .
   lsr reg2, reg, reg2

The 16 bit quantities compose to the address of the field. The 3 x mov 
sequence is marked with a runtime relocation which ensures that it is 
updated when generated code is restored from the SCCache. That requires 
the field address to be inserted in the SCC address table's list of 
external addresses.

This scheme requires repeating that series of 3 x mov + ldrb 
instructions at every object field store in a given compiled method. 
That also implies a runtime relocation for each such sequence when the 
code is restored from the SCCache.

With C2 the barrier manifests as a (Set dst con) for a special ConP 
value (operand con has type immRegionGrainShift) feeding a LoadB. I 
guess C2 might conceivably be able to optimize away some of the repeat 
movz/k and ldrb sequences if it is able to keep the address or byte 
value in a register or spill slot but I would not expect that to be likely.

> I suppose this require us to put multiple copies of 
> G1HeapRegion::LogHRGrainSize inside the AOT code, as there's a limit for 
> the offset. But we will be patching fewer places than every sites that 
> needs to know the grain size.
I think what you are suggesting here is what I described as option 4. 
i.e. we put the grain size in the nmethod const section (or in a 
dedicated data location for a non-nmethod blob) and insert a pc-relative 
load in the barrier to feed the lsr.

With AOT code this would require a special relocation to mark the 
constants area slot (or the non-method blob data slot), lets call it 
reloc_grain_shift_const. It would patch the constant to whatever value 
field G1HeapRegion::LogHRGrainSize has in the current runtime (or rather 
to whatever grain size is reported by the barrier card table). We don't 
have such a reloc at present.. We do have an existing reloc for a 
runtime data address which is why I implemented option 2 first (to work 
out where I would need to tweak the compilers and barrier set assemblers 
plus auxiliary classes).

With option 4 I believe we will only need one occurrence of the 
constant. On AArch64 we would use either adr or adrp + add to install a 
pc-relative address into a register and then an ldrb via that register.

   adr reg, #<21bits>
   ldrb reg, reg
   ...
   lsr reg2, reg, reg2

or

   adrp reg, #<21bits> # selects 12 bit-aligned page
   add  reg, #<12bits>
   ldrb reg, reg
   ...
   lsr reg2, reg, reg2

The adr/adrp instructions do not need relocating which is why scheme 4 
would only require 1 relocation per nmethod (or non-nmethod blob).

Option 3 involves generating the normal barrier

     lsr, reg, #imm, reg

The difference is that for AOT code we would mark the instruction with a 
new relocation, let's call it reloc_grain_shift_immediate. Patching for 
this reloc would assert that the corresponding instruction is an shift 
and that the current GC barrier set is using a card table. It would 
update the immediate operand with whatever grain size shift was reported 
by the card table.

Like scheme 2 this would require a reloc for every object field write in 
an nmethod (or non-nmethod blob).

regards,


Andrew Dinn
-----------


From vladimir.kozlov at oracle.com  Wed Jul 17 17:27:00 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 17 Jul 2024 10:27:00 -0700
Subject: premain: Possible solutions to use runtime G1 region grain size
 in AOT code (JDK-8335440)
In-Reply-To: <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
Message-ID: <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>

 > We don't have such a reloc at present..

What about section_word_Relocation so we can put grain value into constants section?

Thanks,
Vladimir K

On 7/17/24 3:15 AM, Andrew Dinn wrote:
> Hi Ioi,
> 
> On 16/07/2024 17:33, ioi.lam at oracle.com wrote:
>>
>> On 7/15/24 9:23 AM, Andrew Dinn wrote:
>>> . . .
>>> The second solution modifies barrier generation when the SCCache is open for writing to load the shift count from a 
>>> runtime field, G1HeapRegion::LogHRGrainSize i.e. the same field that determines the immediate count used for normal 
>>> generation. In order to make this visible to the compilers and SCC address table the address of this field is 
>>> exported via the card table. This solution requires the AOT code to reference the target address using a runtime 
>>> address relocation. Once again, if the SCCache is not open for writing the count is generated as normal i.e. as an 
>>> immediate operand.
>>>
>>>
>> Is the G1HeapRegion::LogHRGrainSize loaded with PC offset?
>>
>> ???? ldr grain, [pc, #5678]
> 
> That's not what this option does. The barroer loads the grain size indirectly via a constant static field address, i.e. 
> via address &G1HeapRegion::LogHRGrainSize (well, actually, the constant is determined by whatever address is reported by 
> the barrier card table but effectively it is &G1HeapRegion::LogHRGrainSize). So the barrier includes uses a sequence 
> like this
> 
>  ? movz reg #<16bit>
>  ? movk reg #<16bit>, #16
>  ? movk reg #<16bit>, #32
>  ? ldrb reg, reg
>  ? . . .
>  ? lsr reg2, reg, reg2
> 
> The 16 bit quantities compose to the address of the field. The 3 x mov sequence is marked with a runtime relocation 
> which ensures that it is updated when generated code is restored from the SCCache. That requires the field address to be 
> inserted in the SCC address table's list of external addresses.
> 
> This scheme requires repeating that series of 3 x mov + ldrb instructions at every object field store in a given 
> compiled method. That also implies a runtime relocation for each such sequence when the code is restored from the SCCache.
> 
> With C2 the barrier manifests as a (Set dst con) for a special ConP value (operand con has type immRegionGrainShift) 
> feeding a LoadB. I guess C2 might conceivably be able to optimize away some of the repeat movz/k and ldrb sequences if 
> it is able to keep the address or byte value in a register or spill slot but I would not expect that to be likely.
> 
>> I suppose this require us to put multiple copies of G1HeapRegion::LogHRGrainSize inside the AOT code, as there's a 
>> limit for the offset. But we will be patching fewer places than every sites that needs to know the grain size.
> I think what you are suggesting here is what I described as option 4. i.e. we put the grain size in the nmethod const 
> section (or in a dedicated data location for a non-nmethod blob) and insert a pc-relative load in the barrier to feed 
> the lsr.
> 
> With AOT code this would require a special relocation to mark the constants area slot (or the non-method blob data 
> slot), lets call it reloc_grain_shift_const. It would patch the constant to whatever value field 
> G1HeapRegion::LogHRGrainSize has in the current runtime (or rather to whatever grain size is reported by the barrier 
> card table). We don't have such a reloc at present.. We do have an existing reloc for a runtime data address which is 
> why I implemented option 2 first (to work out where I would need to tweak the compilers and barrier set assemblers plus 
> auxiliary classes).
> 
> With option 4 I believe we will only need one occurrence of the constant. On AArch64 we would use either adr or adrp + 
> add to install a pc-relative address into a register and then an ldrb via that register.
> 
>  ? adr reg, #<21bits>
>  ? ldrb reg, reg
>  ? ...
>  ? lsr reg2, reg, reg2
> 
> or
> 
>  ? adrp reg, #<21bits> # selects 12 bit-aligned page
>  ? add? reg, #<12bits>
>  ? ldrb reg, reg
>  ? ...
>  ? lsr reg2, reg, reg2
> 
> The adr/adrp instructions do not need relocating which is why scheme 4 would only require 1 relocation per nmethod (or 
> non-nmethod blob).
> 
> Option 3 involves generating the normal barrier
> 
>  ??? lsr, reg, #imm, reg
> 
> The difference is that for AOT code we would mark the instruction with a new relocation, let's call it 
> reloc_grain_shift_immediate. Patching for this reloc would assert that the corresponding instruction is an shift and 
> that the current GC barrier set is using a card table. It would update the immediate operand with whatever grain size 
> shift was reported by the card table.
> 
> Like scheme 2 this would require a reloc for every object field write in an nmethod (or non-nmethod blob).
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From adinn at redhat.com  Thu Jul 18 11:00:26 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Thu, 18 Jul 2024 12:00:26 +0100
Subject: premain: Possible solutions to use runtime G1 region grain size
 in AOT code (JDK-8335440)
In-Reply-To: <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
Message-ID: <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>

On 17/07/2024 18:27, Vladimir Kozlov wrote:
>  > We don't have such a reloc at present..
> 
> What about section_word_Relocation so we can put grain value into 
> constants section?

I agree that when compiling an nmethod we would need to use a 
section_word_type reloc to mark the adrp that accesses the constant. 
That would ensure that the offset used by the adrp is kept consistent 
across buffer resizes and at install when the displacement may change.

However, what I was talking about was a new reloc, needed only when the 
SCCache restores code, which would mark the constant itself. When AOT 
code is restored we need to ensure any such constant is rewritten using 
the runtime grain size.

We could attempt to do the rewrite of the constant as a side-effect of 
processing the section_word_type reloc during code restore. However, we 
would need to know for sure that the constant being accessed by the adrp 
was definitely the grain size. Is that what you were thinking of, Vladimir?

Of course that would not work for stubs which need to include a barrier 
and a reference to the barrier shift (I believe this only applies for 
some of the memory copy stubs). In this case we would have to load the 
constant from a data slot allocated in amongst the instructions. So, we 
I think would not be able to identify the location of the constant with 
a section_word_type reloc.

regards,


Andrew Dinn
-----------

> On 7/17/24 3:15 AM, Andrew Dinn wrote:
>> Hi Ioi,
>>
>> On 16/07/2024 17:33, ioi.lam at oracle.com wrote:
>>>
>>> On 7/15/24 9:23 AM, Andrew Dinn wrote:
>>>> . . .
>>>> The second solution modifies barrier generation when the SCCache is 
>>>> open for writing to load the shift count from a runtime field, 
>>>> G1HeapRegion::LogHRGrainSize i.e. the same field that determines the 
>>>> immediate count used for normal generation. In order to make this 
>>>> visible to the compilers and SCC address table the address of this 
>>>> field is exported via the card table. This solution requires the AOT 
>>>> code to reference the target address using a runtime address 
>>>> relocation. Once again, if the SCCache is not open for writing the 
>>>> count is generated as normal i.e. as an immediate operand.
>>>>
>>>>
>>> Is the G1HeapRegion::LogHRGrainSize loaded with PC offset?
>>>
>>> ???? ldr grain, [pc, #5678]
>>
>> That's not what this option does. The barroer loads the grain size 
>> indirectly via a constant static field address, i.e. via address 
>> &G1HeapRegion::LogHRGrainSize (well, actually, the constant is 
>> determined by whatever address is reported by the barrier card table 
>> but effectively it is &G1HeapRegion::LogHRGrainSize). So the barrier 
>> includes uses a sequence like this
>>
>> ?? movz reg #<16bit>
>> ?? movk reg #<16bit>, #16
>> ?? movk reg #<16bit>, #32
>> ?? ldrb reg, reg
>> ?? . . .
>> ?? lsr reg2, reg, reg2
>>
>> The 16 bit quantities compose to the address of the field. The 3 x mov 
>> sequence is marked with a runtime relocation which ensures that it is 
>> updated when generated code is restored from the SCCache. That 
>> requires the field address to be inserted in the SCC address table's 
>> list of external addresses.
>>
>> This scheme requires repeating that series of 3 x mov + ldrb 
>> instructions at every object field store in a given compiled method. 
>> That also implies a runtime relocation for each such sequence when the 
>> code is restored from the SCCache.
>>
>> With C2 the barrier manifests as a (Set dst con) for a special ConP 
>> value (operand con has type immRegionGrainShift) feeding a LoadB. I 
>> guess C2 might conceivably be able to optimize away some of the repeat 
>> movz/k and ldrb sequences if it is able to keep the address or byte 
>> value in a register or spill slot but I would not expect that to be 
>> likely.
>>
>>> I suppose this require us to put multiple copies of 
>>> G1HeapRegion::LogHRGrainSize inside the AOT code, as there's a limit 
>>> for the offset. But we will be patching fewer places than every sites 
>>> that needs to know the grain size.
>> I think what you are suggesting here is what I described as option 4. 
>> i.e. we put the grain size in the nmethod const section (or in a 
>> dedicated data location for a non-nmethod blob) and insert a 
>> pc-relative load in the barrier to feed the lsr.
>>
>> With AOT code this would require a special relocation to mark the 
>> constants area slot (or the non-method blob data slot), lets call it 
>> reloc_grain_shift_const. It would patch the constant to whatever value 
>> field G1HeapRegion::LogHRGrainSize has in the current runtime (or 
>> rather to whatever grain size is reported by the barrier card table). 
>> We don't have such a reloc at present.. We do have an existing reloc 
>> for a runtime data address which is why I implemented option 2 first 
>> (to work out where I would need to tweak the compilers and barrier set 
>> assemblers plus auxiliary classes).
>>
>> With option 4 I believe we will only need one occurrence of the 
>> constant. On AArch64 we would use either adr or adrp + add to install 
>> a pc-relative address into a register and then an ldrb via that register.
>>
>> ?? adr reg, #<21bits>
>> ?? ldrb reg, reg
>> ?? ...
>> ?? lsr reg2, reg, reg2
>>
>> or
>>
>> ?? adrp reg, #<21bits> # selects 12 bit-aligned page
>> ?? add? reg, #<12bits>
>> ?? ldrb reg, reg
>> ?? ...
>> ?? lsr reg2, reg, reg2
>>
>> The adr/adrp instructions do not need relocating which is why scheme 4 
>> would only require 1 relocation per nmethod (or non-nmethod blob).
>>
>> Option 3 involves generating the normal barrier
>>
>> ???? lsr, reg, #imm, reg
>>
>> The difference is that for AOT code we would mark the instruction with 
>> a new relocation, let's call it reloc_grain_shift_immediate. Patching 
>> for this reloc would assert that the corresponding instruction is an 
>> shift and that the current GC barrier set is using a card table. It 
>> would update the immediate operand with whatever grain size shift was 
>> reported by the card table.
>>
>> Like scheme 2 this would require a reloc for every object field write 
>> in an nmethod (or non-nmethod blob).
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>
> 

-- 
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 vladimir.kozlov at oracle.com  Thu Jul 18 16:15:51 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 18 Jul 2024 09:15:51 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
Message-ID: <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>


On 7/18/24 4:00 AM, Andrew Dinn wrote:
> On 17/07/2024 18:27, Vladimir Kozlov wrote:
>> ?> We don't have such a reloc at present..
>>
>> What about section_word_Relocation so we can put grain value into constants section?
> 
> I agree that when compiling an nmethod we would need to use a section_word_type reloc to mark the adrp that accesses the 
> constant. That would ensure that the offset used by the adrp is kept consistent across buffer resizes and at install 
> when the displacement may change.
> 
> However, what I was talking about was a new reloc, needed only when the SCCache restores code, which would mark the 
> constant itself. When AOT code is restored we need to ensure any such constant is rewritten using the runtime grain size.
> 
> We could attempt to do the rewrite of the constant as a side-effect of processing the section_word_type reloc during 
> code restore. However, we would need to know for sure that the constant being accessed by the adrp was definitely the 
> grain size. Is that what you were thinking of, Vladimir?
> 
> Of course that would not work for stubs which need to include a barrier and a reference to the barrier shift (I believe 
> this only applies for some of the memory copy stubs). In this case we would have to load the constant from a data slot 
> allocated in amongst the instructions. So, we I think would not be able to identify the location of the constant with a 
> section_word_type reloc.

Yes, you are right, section_word_type will not work.

What about allocating word in CodeCache as we do for some intrinsics stubs tables? You will need to generate it only 
once and can use runtime_type relocation to access it.

It is all about loading with existing relocation vs specialized relocation for immediate value (Option three).
I would like to see how complex option three is.

Thanks,
Vladimir K

> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 
>> On 7/17/24 3:15 AM, Andrew Dinn wrote:
>>> Hi Ioi,
>>>
>>> On 16/07/2024 17:33, ioi.lam at oracle.com wrote:
>>>>
>>>> On 7/15/24 9:23 AM, Andrew Dinn wrote:
>>>>> . . .
>>>>> The second solution modifies barrier generation when the SCCache is open for writing to load the shift count from a 
>>>>> runtime field, G1HeapRegion::LogHRGrainSize i.e. the same field that determines the immediate count used for normal 
>>>>> generation. In order to make this visible to the compilers and SCC address table the address of this field is 
>>>>> exported via the card table. This solution requires the AOT code to reference the target address using a runtime 
>>>>> address relocation. Once again, if the SCCache is not open for writing the count is generated as normal i.e. as an 
>>>>> immediate operand.
>>>>>
>>>>>
>>>> Is the G1HeapRegion::LogHRGrainSize loaded with PC offset?
>>>>
>>>> ???? ldr grain, [pc, #5678]
>>>
>>> That's not what this option does. The barroer loads the grain size indirectly via a constant static field address, 
>>> i.e. via address &G1HeapRegion::LogHRGrainSize (well, actually, the constant is determined by whatever address is 
>>> reported by the barrier card table but effectively it is &G1HeapRegion::LogHRGrainSize). So the barrier includes uses 
>>> a sequence like this
>>>
>>> ?? movz reg #<16bit>
>>> ?? movk reg #<16bit>, #16
>>> ?? movk reg #<16bit>, #32
>>> ?? ldrb reg, reg
>>> ?? . . .
>>> ?? lsr reg2, reg, reg2
>>>
>>> The 16 bit quantities compose to the address of the field. The 3 x mov sequence is marked with a runtime relocation 
>>> which ensures that it is updated when generated code is restored from the SCCache. That requires the field address to 
>>> be inserted in the SCC address table's list of external addresses.
>>>
>>> This scheme requires repeating that series of 3 x mov + ldrb instructions at every object field store in a given 
>>> compiled method. That also implies a runtime relocation for each such sequence when the code is restored from the 
>>> SCCache.
>>>
>>> With C2 the barrier manifests as a (Set dst con) for a special ConP value (operand con has type immRegionGrainShift) 
>>> feeding a LoadB. I guess C2 might conceivably be able to optimize away some of the repeat movz/k and ldrb sequences 
>>> if it is able to keep the address or byte value in a register or spill slot but I would not expect that to be likely.
>>>
>>>> I suppose this require us to put multiple copies of G1HeapRegion::LogHRGrainSize inside the AOT code, as there's a 
>>>> limit for the offset. But we will be patching fewer places than every sites that needs to know the grain size.
>>> I think what you are suggesting here is what I described as option 4. i.e. we put the grain size in the nmethod const 
>>> section (or in a dedicated data location for a non-nmethod blob) and insert a pc-relative load in the barrier to feed 
>>> the lsr.
>>>
>>> With AOT code this would require a special relocation to mark the constants area slot (or the non-method blob data 
>>> slot), lets call it reloc_grain_shift_const. It would patch the constant to whatever value field 
>>> G1HeapRegion::LogHRGrainSize has in the current runtime (or rather to whatever grain size is reported by the barrier 
>>> card table). We don't have such a reloc at present.. We do have an existing reloc for a runtime data address which is 
>>> why I implemented option 2 first (to work out where I would need to tweak the compilers and barrier set assemblers 
>>> plus auxiliary classes).
>>>
>>> With option 4 I believe we will only need one occurrence of the constant. On AArch64 we would use either adr or adrp 
>>> + add to install a pc-relative address into a register and then an ldrb via that register.
>>>
>>> ?? adr reg, #<21bits>
>>> ?? ldrb reg, reg
>>> ?? ...
>>> ?? lsr reg2, reg, reg2
>>>
>>> or
>>>
>>> ?? adrp reg, #<21bits> # selects 12 bit-aligned page
>>> ?? add? reg, #<12bits>
>>> ?? ldrb reg, reg
>>> ?? ...
>>> ?? lsr reg2, reg, reg2
>>>
>>> The adr/adrp instructions do not need relocating which is why scheme 4 would only require 1 relocation per nmethod 
>>> (or non-nmethod blob).
>>>
>>> Option 3 involves generating the normal barrier
>>>
>>> ???? lsr, reg, #imm, reg
>>>
>>> The difference is that for AOT code we would mark the instruction with a new relocation, let's call it 
>>> reloc_grain_shift_immediate. Patching for this reloc would assert that the corresponding instruction is an shift and 
>>> that the current GC barrier set is using a card table. It would update the immediate operand with whatever grain size 
>>> shift was reported by the card table.
>>>
>>> Like scheme 2 this would require a reloc for every object field write in an nmethod (or non-nmethod blob).
>>>
>>> regards,
>>>
>>>
>>> Andrew Dinn
>>> -----------
>>>
>>
> 

From duke at openjdk.org  Thu Jul 18 21:21:49 2024
From: duke at openjdk.org (duke)
Date: Thu, 18 Jul 2024 21:21:49 GMT
Subject: git: openjdk/leyden: premain: SCC: Handle ConstantDynamic CP entries
Message-ID: <9394b530-917c-4501-afa0-3ffaa40b4b21@openjdk.org>

Changeset: 974f53b6
Branch: premain
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-07-18 14:18:30 +0000
URL:       https://git.openjdk.org/leyden/commit/974f53b6a7fa7a0601b1af4a20a7f97a89b2461f

SCC: Handle ConstantDynamic CP entries

! src/hotspot/share/ci/ciConstant.cpp
! src/hotspot/share/ci/ciConstant.hpp
! src/hotspot/share/ci/ciEnv.cpp


From duke at openjdk.org  Thu Jul 18 22:37:03 2024
From: duke at openjdk.org (duke)
Date: Thu, 18 Jul 2024 22:37:03 GMT
Subject: git: openjdk/leyden: premain: C2: Fix upcall into compiler runtime w/
 -XX:ClassInitBarrierMode=2
Message-ID: <680bcb0d-4bd0-4463-9a2f-13fa3082ff21@openjdk.org>

Changeset: ed32488c
Branch: premain
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-07-18 14:21:35 +0000
URL:       https://git.openjdk.org/leyden/commit/ed32488c0d94f03bf9d43bf387cf59b1e7143292

C2: Fix upcall into compiler runtime w/ -XX:ClassInitBarrierMode=2

! src/hotspot/share/opto/graphKit.cpp


From duke at openjdk.org  Thu Jul 18 22:39:31 2024
From: duke at openjdk.org (duke)
Date: Thu, 18 Jul 2024 22:39:31 GMT
Subject: git: openjdk/leyden: premain-ea: 2 new changesets
Message-ID: <ffc726b9-3c48-46f9-b672-d900a06a9bdb@openjdk.org>

Changeset: c0c8248d
Branch: premain-ea
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-07-18 14:18:30 +0000
URL:       https://git.openjdk.org/leyden/commit/c0c8248dfb3c7d0a53c04f7429b72f5f48b36299

SCC: Handle ConstantDynamic CP entries

! src/hotspot/share/ci/ciConstant.cpp
! src/hotspot/share/ci/ciConstant.hpp
! src/hotspot/share/ci/ciEnv.cpp

Changeset: 1b098411
Branch: premain-ea
Author:    Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
Date:      2024-07-18 14:21:35 +0000
URL:       https://git.openjdk.org/leyden/commit/1b09841196dbc407d10c3d1c989eca40321238c7

C2: Fix upcall into compiler runtime w/ -XX:ClassInitBarrierMode=2

! src/hotspot/share/opto/graphKit.cpp


From duke at openjdk.org  Fri Jul 19 02:59:58 2024
From: duke at openjdk.org (duke)
Date: Fri, 19 Jul 2024 02:59:58 GMT
Subject: git: openjdk/leyden: premain: 185 new changesets
Message-ID: <80988863-b646-4f7a-b27e-790b0fba293e@openjdk.org>

Changeset: f187c92b
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-03 02:19:54 +0000
URL:       https://git.openjdk.org/leyden/commit/f187c92befbe63e23b11eb0401e5095c44c24389

8335370: Fix -Wzero-as-null-pointer-constant warning in jvmti_common.hpp

Reviewed-by: jwaters, amenkov, sspitsyn

! test/lib/jdk/test/lib/jvmti/jvmti_common.hpp

Changeset: 3a2d4264
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-03 02:42:06 +0000
URL:       https://git.openjdk.org/leyden/commit/3a2d426489ead9672512e0c5a6862284a54734ba

8334726: Remove accidentally exposed individual methods from Class-File API

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java
! src/java.base/share/classes/java/lang/classfile/components/CodeRelabeler.java
! src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeRelabelerImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ModuleAttributeBuilderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java
! src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java

Changeset: 8a664a4c
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-03 02:43:41 +0000
URL:       https://git.openjdk.org/leyden/commit/8a664a4c359deefd7237f3672b62d7d8c1ffb453

8334734: Remove specialized readXxxEntry methods from ClassReader

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/ClassReader.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AnnotationReader.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundRecordComponentInfo.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassReaderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java

Changeset: f7af4504
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-03 02:49:43 +0000
URL:       https://git.openjdk.org/leyden/commit/f7af4504a804711d93208b763b3e41eafcf61735

8335110: Fix instruction name and API spec inconsistencies in CodeBuilder

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/attribute/CodeAttribute.java
! src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java
! src/java.base/share/classes/jdk/internal/classfile/impl/LabelImpl.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java

Changeset: f9b4ea13
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-07-03 02:56:17 +0000
URL:       https://git.openjdk.org/leyden/commit/f9b4ea13e693da268c9aee27dee49f9c7f798bb1

8334220: Optimize Klass layout after JDK-8180450

Reviewed-by: coleenp, stuefe, dholmes

! src/hotspot/share/oops/klass.hpp

Changeset: fac74b11
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-07-03 03:01:06 +0000
URL:       https://git.openjdk.org/leyden/commit/fac74b118f5fda4ec297e46238d34ce5b9be1e21

8334229: Optimize InterpreterOopMap layout

Reviewed-by: coleenp, dholmes

! src/hotspot/share/interpreter/oopMapCache.hpp

Changeset: d51141e5
Branch: premain
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-03 04:36:32 +0000
URL:       https://git.openjdk.org/leyden/commit/d51141e5fc84f9f933e78d0eb25af86e41798ad5

8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes

Reviewed-by: lancea, jpai

! src/java.base/share/classes/java/util/zip/ZipEntry.java
! src/java.base/share/classes/java/util/zip/ZipFile.java
! src/java.base/share/classes/java/util/zip/ZipOutputStream.java
! src/java.base/share/classes/jdk/internal/access/JavaUtilZipFileAccess.java
! src/jdk.jartool/share/classes/jdk/security/jarsigner/JarSigner.java
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_de.java
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
! src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java
! test/jdk/sun/security/tools/jarsigner/SymLinkTest.java

Changeset: 0db9bc57
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-03 05:03:56 +0000
URL:       https://git.openjdk.org/leyden/commit/0db9bc57de07f8f1d0bf657621cb1b8fd7b01211

8335290: Rename ClassFile::transform to ClassFile::transformClass

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/Module.java
! src/java.base/share/classes/java/lang/classfile/ClassFile.java
! src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
! src/java.base/share/classes/java/lang/classfile/components/ClassRemapper.java
! src/java.base/share/classes/java/lang/classfile/components/snippet-files/PackageSnippets.java
! src/java.base/share/classes/java/lang/classfile/snippet-files/PackageSnippets.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassFileImpl.java
! src/java.base/share/classes/jdk/internal/module/ModuleInfoExtender.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/StripJavaDebugAttributesPlugin.java
! src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VersionPropsPlugin.java
! src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControl.java
! test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
! test/jdk/java/io/Serializable/records/ProhibitedMethods.java
! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
! test/jdk/java/lang/ModuleTests/AnnotationsTest.java
! test/jdk/java/lang/instrument/asmlib/Instrumentor.java
! test/jdk/java/lang/invoke/8022701/BogoLoader.java
! test/jdk/java/lang/invoke/accessProtectedSuper/BogoLoader.java
! test/jdk/jdk/classfile/AdaptCodeTest.java
! test/jdk/jdk/classfile/AdvancedTransformationsTest.java
! test/jdk/jdk/classfile/BSMTest.java
! test/jdk/jdk/classfile/ClassBuildingTest.java
! test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
! test/jdk/jdk/classfile/CorpusTest.java
! test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
! test/jdk/jdk/classfile/LvtTest.java
! test/jdk/jdk/classfile/MassAdaptCopyCodeTest.java
! test/jdk/jdk/classfile/MassAdaptCopyPrimitiveMatchCodeTest.java
! test/jdk/jdk/classfile/OptionsTest.java
! test/jdk/jdk/classfile/ShortJumpsFixTest.java
! test/jdk/jdk/classfile/StackMapsTest.java
! test/jdk/jdk/classfile/TestRecordComponent.java
! test/jdk/jdk/classfile/TransformTests.java
! test/jdk/jdk/classfile/VerifierSelfTest.java
! test/jdk/jdk/classfile/examples/AnnotationsExamples.java
! test/jdk/jdk/classfile/examples/ExampleGallery.java
! test/jdk/jdk/classfile/examples/ExperimentalTransformExamples.java
! test/jdk/jdk/classfile/examples/TransformExamples.java
! test/jdk/jdk/classfile/helpers/Transforms.java
! test/jdk/jdk/jfr/event/io/TestInstrumentation.java
! test/jdk/jdk/jfr/javaagent/TestEventInstrumentation.java
! test/jdk/jdk/lambda/separate/ClassToInterfaceConverter.java
! test/langtools/tools/javac/MethodParametersTest.java
! test/langtools/tools/javac/classreader/8171132/BadConstantValue.java
! test/langtools/tools/javac/classreader/BadMethodParameter.java
! test/langtools/tools/javac/defaultMethods/BadClassfile.java
! test/langtools/tools/javac/launcher/SourceLauncherTest.java
! test/langtools/tools/javac/modules/IncubatingTest.java
! test/langtools/tools/javac/modules/JavaBaseTest.java
! test/langtools/tools/javac/modules/OpenModulesTest.java
! test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java
! test/langtools/tools/javac/processing/model/element/TestOrigin.java
! test/langtools/tools/javap/UndefinedAccessFlagTest.java
! test/micro/org/openjdk/bench/jdk/classfile/AdHocAdapt.java
! test/micro/org/openjdk/bench/jdk/classfile/ClassfileBenchmark.java
! test/micro/org/openjdk/bench/jdk/classfile/ParseOptions.java
! test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java
! test/micro/org/openjdk/bench/jdk/classfile/Transforms.java

Changeset: 7bc8f9c1
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-03 05:55:28 +0000
URL:       https://git.openjdk.org/leyden/commit/7bc8f9c150cbf457edf6144adba734ecd5ca5a0f

8335589: Fix -Wzero-as-null-pointer-constant warnings in IdealLoopTree ctor

Reviewed-by: thartmann

! src/hotspot/share/opto/loopnode.hpp

Changeset: f3f90dc1
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-03 05:57:49 +0000
URL:       https://git.openjdk.org/leyden/commit/f3f90dc11a5cbc146a5ef8a73eadf4168373838d

8335592: Fix -Wzero-as-null-pointer-constant warnings in RootNode ctor

Reviewed-by: thartmann

! src/hotspot/share/opto/rootnode.hpp

Changeset: 77a7078b
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-03 06:00:20 +0000
URL:       https://git.openjdk.org/leyden/commit/77a7078b82fd0cb3cfa13685072f04fdef33758b

8335593: Fix -Wzero-as-null-pointer-constant warning in Type_Array ctor

Reviewed-by: thartmann

! src/hotspot/share/opto/phaseX.hpp

Changeset: 4d2f7376
Branch: premain
Author:    Gerg? Barany <gbarany at openjdk.org>
Committer: Doug Simon <dnsimon at openjdk.org>
Date:      2024-07-03 08:08:22 +0000
URL:       https://git.openjdk.org/leyden/commit/4d2f73764bcd5ff62fbdb9d406d4180ae09613ff

8335357: Delete HotSpotJDKReflection.oopSizeOffset

Reviewed-by: dnsimon

! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotJDKReflection.java

Changeset: 6c84e9c8
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-03 08:42:43 +0000
URL:       https://git.openjdk.org/leyden/commit/6c84e9c8cb71aac103901c0d92fe6ae51aabff15

8335544: Serial: Remove unused _should_allocate_from_space

Reviewed-by: iwalulya

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp

Changeset: c06b75ff
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-03 11:12:08 +0000
URL:       https://git.openjdk.org/leyden/commit/c06b75ff88babf57bdcd0919ea177ff363fd858b

8335591: Fix -Wzero-as-null-pointer-constant warnings in ConcurrentHashTable

Reviewed-by: chagedorn

! src/hotspot/share/utilities/concurrentHashTable.inline.hpp

Changeset: 350f9c19
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-03 11:36:14 +0000
URL:       https://git.openjdk.org/leyden/commit/350f9c1947b0eab3ee233516ceefca1e25de9583

8322812: Manpage for jcmd is missing JFR.view command

Reviewed-by: kevinw, mgronlun

! src/jdk.jcmd/share/man/jcmd.1

Changeset: 6db4c6a7
Branch: premain
Author:    Qizheng Xing <qxing at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-07-03 12:12:00 +0000
URL:       https://git.openjdk.org/leyden/commit/6db4c6a772df856fc3099c32a5b2c102a30d360c

8335536: Fix assertion failure in IdealGraphPrinter when append is true

Reviewed-by: thartmann, chagedorn, tholenstein

! src/hotspot/share/opto/idealGraphPrinter.cpp
! src/hotspot/share/opto/idealGraphPrinter.hpp

Changeset: 5866b16d
Branch: premain
Author:    Feilong Jiang <fjiang at openjdk.org>
Date:      2024-07-03 12:12:12 +0000
URL:       https://git.openjdk.org/leyden/commit/5866b16dbca3f63770c8792d204dabdf49b59839

8335411: RISC-V: Optimize encode_heap_oop when oop is not null

Reviewed-by: fyang, rehn

! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv.ad

Changeset: 6923a511
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-03 12:57:26 +0000
URL:       https://git.openjdk.org/leyden/commit/6923a5114b2a9f02f0d6f0fefc21141ac3b9322a

8335607: Serial: Remove unused collection_attempt_is_safe

Reviewed-by: tschatzl

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp

Changeset: 5a8af2b8
Branch: premain
Author:    Arseny Bochkarev <arseny.bochkarev at syntacore.com>
Committer: Vladimir Kempik <vkempik at openjdk.org>
Date:      2024-07-03 14:09:59 +0000
URL:       https://git.openjdk.org/leyden/commit/5a8af2b8b93672de9b3a3e73e6984506980da932

8335615: Clean up left-overs from 8317721

Reviewed-by: fyang

! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp

Changeset: cf4f2b53
Branch: premain
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2024-07-03 15:12:40 +0000
URL:       https://git.openjdk.org/leyden/commit/cf4f2b53d6174a808f8b45f0bb848efd5bd91c3c

8332517: G1: Refactor G1AllocRegion

Reviewed-by: tschatzl, ayang

! src/hotspot/share/gc/g1/g1AllocRegion.cpp
! src/hotspot/share/gc/g1/g1AllocRegion.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.inline.hpp
! src/hotspot/share/gc/g1/g1Allocator.cpp
! src/hotspot/share/gc/g1/g1HeapRegion.hpp
! src/hotspot/share/gc/g1/g1HeapRegion.inline.hpp

Changeset: 19a8a2ba
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-03 15:42:47 +0000
URL:       https://git.openjdk.org/leyden/commit/19a8a2baa9e749c7527ff526b2794826f0cdebb3

8335618: Serial: Remove unused definitions in SerialHeap

Reviewed-by: iwalulya

! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/serialHeap.hpp

Changeset: 8aaec37a
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-07-03 16:08:34 +0000
URL:       https://git.openjdk.org/leyden/commit/8aaec37ace102b55ee1387cfd1967ec3ab662083

8322475: Extend printing for System.map

Reviewed-by: sgehwolf, jsjolen

! src/hotspot/os/linux/memMapPrinter_linux.cpp
+ src/hotspot/os/linux/procMapsParser.cpp
+ src/hotspot/os/linux/procMapsParser.hpp
! src/hotspot/share/nmt/memMapPrinter.cpp
! src/hotspot/share/nmt/memMapPrinter.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/services/attachListener.cpp
! src/hotspot/share/services/diagnosticCommand.cpp
! src/hotspot/share/services/diagnosticCommand.hpp
! src/hotspot/share/utilities/ostream.cpp
! src/hotspot/share/utilities/ostream.hpp
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemDumpMapTest.java
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java
+ test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java

Changeset: 13b782c3
Branch: premain
Author:    Hamlin Li <mli at openjdk.org>
Date:      2024-07-03 16:10:22 +0000
URL:       https://git.openjdk.org/leyden/commit/13b782c3de9a470a7cf1db9d5111ce19faf28729

8334554: RISC-V: verify & fix perf of string comparison

Reviewed-by: rehn, luhenry, fyang

! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/riscv_v.ad

Changeset: 9a91865f
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-07-03 16:29:52 +0000
URL:       https://git.openjdk.org/leyden/commit/9a91865ff38f6fbb48b9aba5028e0b529d9bce76

8335395: G1: Verification does not detect references into Free regions

Reviewed-by: ayang, iwalulya

! src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp
! src/hotspot/share/gc/g1/g1HeapRegion.cpp

Changeset: 68ffec98
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-03 20:43:08 +0000
URL:       https://git.openjdk.org/leyden/commit/68ffec9800b798927a050900a2d47000aa18ef30

8335479: JFR: Missing documentation for -XX:StartFlightRecording

Reviewed-by: mgronlun

! src/java.base/share/man/java.1

Changeset: 587535c5
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-07-03 21:42:08 +0000
URL:       https://git.openjdk.org/leyden/commit/587535c5b9bb258836b47c3a8c41ffb91bbfc131

8334545: runtime/ClassInitErrors/TestStackOverflowDuringInit.java fails after JDK-8294960

Reviewed-by: iklam, stuefe

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java

Changeset: 3efa93ba
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-03 22:03:23 +0000
URL:       https://git.openjdk.org/leyden/commit/3efa93ba1307cedf05609c0c04b2ba986a515f6e

8335588: Fix -Wzero-as-null-pointer-constant warnings in calls to Node ctor

Reviewed-by: thartmann, chagedorn

! src/hotspot/share/opto/addnode.hpp
! src/hotspot/share/opto/convertnode.hpp
! src/hotspot/share/opto/countbitsnode.hpp
! src/hotspot/share/opto/intrinsicnode.hpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/memnode.hpp
! src/hotspot/share/opto/movenode.hpp
! src/hotspot/share/opto/mulnode.hpp
! src/hotspot/share/opto/opaquenode.hpp
! src/hotspot/share/opto/subnode.hpp

Changeset: e01626cf
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Date:      2024-07-04 04:18:31 +0000
URL:       https://git.openjdk.org/leyden/commit/e01626cf09850f7b0af33cdb905ca8992266fe5b

8335655: ProblemList serviceability/dcmd/vm tests failing after JDK-8322475

Reviewed-by: mikael

! test/hotspot/jtreg/ProblemList-generational-zgc.txt
! test/hotspot/jtreg/ProblemList-zgc.txt

Changeset: 7b894bc4
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-07-04 05:44:44 +0000
URL:       https://git.openjdk.org/leyden/commit/7b894bc4afa96bc04f0d58042f69becadb573e20

8332786: When dumping static CDS archives, explicitly assert that we don't use a CDS archive

Reviewed-by: iklam, dholmes

! src/hotspot/share/cds/metaspaceShared.cpp

Changeset: 38a578d5
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-07-04 06:20:03 +0000
URL:       https://git.openjdk.org/leyden/commit/38a578d547f39c3637d97f5e0242f4a69f3bbb31

8334738: os::print_hex_dump should optionally print ASCII

Reviewed-by: dholmes, sgehwolf

! src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/ostream.hpp
! test/hotspot/gtest/runtime/test_os.cpp

Changeset: b20e8c8e
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-07-04 08:21:18 +0000
URL:       https://git.openjdk.org/leyden/commit/b20e8c8e85e0a0e96ae648f42ff803f1c83f6291

8335397: Improve reliability of TestRecursiveMonitorChurn.java

Reviewed-by: coleenp, rkennke, dholmes

! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/prims/whitebox.hpp
! src/hotspot/share/runtime/synchronizer.hpp
! test/hotspot/jtreg/runtime/locking/TestRecursiveMonitorChurn.java
! test/lib/jdk/test/whitebox/WhiteBox.java

Changeset: 3e3f83f6
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-07-04 08:36:56 +0000
URL:       https://git.openjdk.org/leyden/commit/3e3f83f62c67caf960ca031439b022f915e1102a

8335385: javac crash on unattributed piece of AST

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! test/langtools/tools/javac/importscope/BadClassFileDuringImport.java
+ test/langtools/tools/javac/tree/ASTAttributesFilledForReferencesOnMissingTypes.java

Changeset: 0bb9c762
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-04 10:03:39 +0000
URL:       https://git.openjdk.org/leyden/commit/0bb9c76288b5f63fe965c3276bb566cef5f51c50

8324089: Fix typo in the manual page for "jcmd" (man jcmd)

Reviewed-by: mgronlun, kevinw

! src/jdk.jcmd/share/man/jcmd.1

Changeset: cf1be872
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-04 10:04:52 +0000
URL:       https://git.openjdk.org/leyden/commit/cf1be87279ddfb2a9fd272e0b245fccd7ec10972

8335663: Fix simple -Wzero-as-null-pointer-constant warnings in C2 code

Reviewed-by: jwaters, chagedorn

! src/hotspot/share/opto/block.hpp
! src/hotspot/share/opto/cfgnode.hpp
! src/hotspot/share/opto/constantTable.hpp
! src/hotspot/share/opto/machnode.hpp

Changeset: c0604fb8
Branch: premain
Author:    Erik ?sterlund <eosterlund at openjdk.org>
Date:      2024-07-04 10:06:09 +0000
URL:       https://git.openjdk.org/leyden/commit/c0604fb823d9f3b2e347a9857b11606b223ad8ec

8334890: Missing unconditional cross modifying fence in nmethod entry barriers

Reviewed-by: aboldtch, kbarrett

! src/hotspot/share/gc/shared/barrierSetNMethod.cpp

Changeset: 916db07e
Branch: premain
Author:    Yudi Zheng <yzheng at openjdk.org>
Date:      2024-07-04 10:34:56 +0000
URL:       https://git.openjdk.org/leyden/commit/916db07e533cdc0fca2010751f7ebe54e6ada7b9

8335532: [JVMCI] Export VM_Version::L1_line_size in JVMCI

Reviewed-by: dnsimon

! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: ced99066
Branch: premain
Author:    Joachim Kern <jkern at openjdk.org>
Date:      2024-07-04 11:20:57 +0000
URL:       https://git.openjdk.org/leyden/commit/ced99066354fc6a32c587b9e3c35b07e26d3452e

8334371: [AIX] Beginning with AIX 7.3 TL1 mmap() supports 64K memory pages

Reviewed-by: stuefe, mbaesken, mdoerr

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/aix/os_aix.hpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/runtime/os.cpp
! test/hotspot/gtest/runtime/test_os.cpp
+ test/hotspot/gtest/runtime/test_os_aix.cpp

Changeset: 7e378fcc
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-04 12:16:54 +0000
URL:       https://git.openjdk.org/leyden/commit/7e378fccd8a4601c8b8e86aa2862c61e469c3a04

8335667: Fix simple -Wzero-as-null-pointer-constant warnings in compiler code

Reviewed-by: chagedorn

! src/hotspot/share/ci/ciStreams.hpp
! src/hotspot/share/code/exceptionHandlerTable.hpp

Changeset: 6a472797
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Aleksei Efimov <aefimov at openjdk.org>
Date:      2024-07-04 12:29:32 +0000
URL:       https://git.openjdk.org/leyden/commit/6a472797a410a6fa27f50371b255054af0cd3c99

8332072: Convert package.html files in `java.naming` to package-info.java
8335213: Code snippet in javax.naming.ldap package summary does not compile

Reviewed-by: aefimov

+ src/java.naming/share/classes/javax/naming/directory/package-info.java
- src/java.naming/share/classes/javax/naming/directory/package.html
+ src/java.naming/share/classes/javax/naming/event/package-info.java
- src/java.naming/share/classes/javax/naming/event/package.html
+ src/java.naming/share/classes/javax/naming/ldap/package-info.java
- src/java.naming/share/classes/javax/naming/ldap/package.html
+ src/java.naming/share/classes/javax/naming/ldap/spi/package-info.java
+ src/java.naming/share/classes/javax/naming/package-info.java
- src/java.naming/share/classes/javax/naming/package.html
+ src/java.naming/share/classes/javax/naming/spi/package-info.java
- src/java.naming/share/classes/javax/naming/spi/package.html

Changeset: b0efd774
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-07-04 12:42:47 +0000
URL:       https://git.openjdk.org/leyden/commit/b0efd7740243916ba22178524ab2ede9e5436d94

8314653: Metaspace: remove allocation guard feature

Reviewed-by: azafari, dholmes

! src/hotspot/share/memory/metaspace/metaspaceArena.cpp
! src/hotspot/share/memory/metaspace/metaspaceArena.hpp
! src/hotspot/share/memory/metaspace/metaspaceSettings.cpp
! src/hotspot/share/memory/metaspace/metaspaceSettings.hpp
! src/hotspot/share/runtime/globals.hpp
- test/hotspot/gtest/metaspace/test_allocationGuard.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena.cpp
! test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp
! test/hotspot/jtreg/gtest/MetaspaceGtests.java
! test/hotspot/jtreg/runtime/Metaspace/PrintMetaspaceDcmd.java
! test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java
! test/hotspot/jtreg/runtime/Metaspace/elastic/Settings.java
! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java
! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java
! test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT2.java

Changeset: da0ffa8b
Branch: premain
Author:    Robert Toyonaga <rtoyonag at redhat.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-07-04 13:35:24 +0000
URL:       https://git.openjdk.org/leyden/commit/da0ffa8b7ff04eb5cbc0fcbe4b858f20d7e46405

8334031: Generated JfrNativeSettings seems off

Reviewed-by: egahlin

! make/src/classes/build/tools/jfr/GenerateJfrFiles.java

Changeset: 3050ba01
Branch: premain
Author:    Jasmine Karthikeyan <jkarthikeyan at openjdk.org>
Date:      2024-07-04 14:09:45 +0000
URL:       https://git.openjdk.org/leyden/commit/3050ba017687ac13e1bbccdd1544d25f8eb2a747

8335654: Remove stale hyperlink in divnode.cpp

Reviewed-by: chagedorn, thartmann

! src/hotspot/share/opto/divnode.cpp

Changeset: f4fa35e2
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-04 15:44:57 +0000
URL:       https://git.openjdk.org/leyden/commit/f4fa35e28b9881729ac47c8518e758bba676fdec

8330954: since-checker - Fix remaining @ since tags in java.base

Reviewed-by: liach, naoto

! src/java.base/share/classes/java/io/FileInputStream.java
! src/java.base/share/classes/java/lang/classfile/ClassSignature.java
! src/java.base/share/classes/java/lang/constant/ClassDesc.java
! src/java.base/share/classes/java/lang/constant/MethodHandleDesc.java
! src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java
! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/java/lang/ref/Reference.java
! src/java.base/share/classes/java/text/ChoiceFormat.java
! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/DelayQueue.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
! src/java.base/share/classes/java/util/concurrent/FutureTask.java

Changeset: cff9e246
Branch: premain
Author:    Liang Mao <lmao at openjdk.org>
Committer: Denghui Dong <ddong at openjdk.org>
Date:      2024-07-05 02:29:07 +0000
URL:       https://git.openjdk.org/leyden/commit/cff9e246cc2fbd3914f40bb71daa85dcf7731396

8335493: check_gc_overhead_limit should reset SoftRefPolicy::_should_clear_all_soft_refs

Reviewed-by: ayang

! src/hotspot/share/gc/shared/gcOverheadChecker.cpp

Changeset: b9d8056d
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-07-05 04:49:01 +0000
URL:       https://git.openjdk.org/leyden/commit/b9d8056d5c1528198ad373f9b4a09547e2fcabd6

8332124: Jcmd should recognise options that look like requests for help

Reviewed-by: kevinw, stuefe

! src/hotspot/share/services/diagnosticFramework.cpp
! src/hotspot/share/services/diagnosticFramework.hpp
+ test/jdk/sun/tools/jcmd/TestJcmdSubcommandHelp.java

Changeset: 4ec1ae10
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-07-05 07:18:34 +0000
URL:       https://git.openjdk.org/leyden/commit/4ec1ae109710aa150e27acf5706475d335c4655c

8331385: G1: Prefix HeapRegion helper classes with G1

Reviewed-by: ayang, dholmes

! src/hotspot/share/gc/g1/g1Arguments.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.hpp
! src/hotspot/share/gc/g1/g1CollectionSet.cpp
! src/hotspot/share/gc/g1/g1CollectionSet.hpp
! src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp
! src/hotspot/share/gc/g1/g1CollectionSetChooser.cpp
! src/hotspot/share/gc/g1/g1CommittedRegionMap.cpp
! src/hotspot/share/gc/g1/g1CommittedRegionMap.hpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.hpp
! src/hotspot/share/gc/g1/g1ConcurrentRebuildAndScrub.cpp
! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp
! src/hotspot/share/gc/g1/g1EvacFailureRegions.cpp
! src/hotspot/share/gc/g1/g1EvacFailureRegions.hpp
! src/hotspot/share/gc/g1/g1FullCollector.cpp
! src/hotspot/share/gc/g1/g1FullGCAdjustTask.cpp
! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp
! src/hotspot/share/gc/g1/g1FullGCCompactTask.hpp
! src/hotspot/share/gc/g1/g1FullGCHeapRegionAttr.hpp
! src/hotspot/share/gc/g1/g1FullGCPrepareTask.hpp
! src/hotspot/share/gc/g1/g1FullGCResetMetadataTask.hpp
! src/hotspot/share/gc/g1/g1HeapRegion.cpp
! src/hotspot/share/gc/g1/g1HeapRegion.hpp
! src/hotspot/share/gc/g1/g1HeapRegionBounds.hpp
! src/hotspot/share/gc/g1/g1HeapRegionBounds.inline.hpp
! src/hotspot/share/gc/g1/g1HeapRegionEventSender.cpp
! src/hotspot/share/gc/g1/g1HeapRegionManager.cpp
! src/hotspot/share/gc/g1/g1HeapRegionManager.hpp
! src/hotspot/share/gc/g1/g1HeapRegionManager.inline.hpp
! src/hotspot/share/gc/g1/g1HeapRegionPrinter.hpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.cpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.hpp
! src/hotspot/share/gc/g1/g1HeapRegionRemSet.inline.hpp
! src/hotspot/share/gc/g1/g1HeapRegionSet.cpp
! src/hotspot/share/gc/g1/g1HeapRegionSet.hpp
! src/hotspot/share/gc/g1/g1HeapRegionSet.inline.hpp
! src/hotspot/share/gc/g1/g1HeapRegionTracer.cpp
! src/hotspot/share/gc/g1/g1HeapRegionTracer.hpp
! src/hotspot/share/gc/g1/g1HeapRegionType.cpp
! src/hotspot/share/gc/g1/g1HeapRegionType.hpp
! src/hotspot/share/gc/g1/g1HeapTransition.cpp
! src/hotspot/share/gc/g1/g1HeapVerifier.cpp
! src/hotspot/share/gc/g1/g1NUMA.cpp
! src/hotspot/share/gc/g1/g1NUMA.hpp
! src/hotspot/share/gc/g1/g1OopClosures.inline.hpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/g1RemSet.hpp
! src/hotspot/share/gc/g1/g1RemSetSummary.cpp
! src/hotspot/share/gc/g1/g1YoungCollector.cpp
! src/hotspot/share/gc/g1/g1YoungGCAllocationFailureInjector.cpp
! src/hotspot/share/gc/g1/g1YoungGCPostEvacuateTasks.cpp
! src/hotspot/share/gc/g1/jvmFlagConstraintsG1.cpp
! src/hotspot/share/gc/g1/vmStructs_g1.hpp
! src/hotspot/share/prims/whitebox.cpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegion.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionClosure.java
= src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionManager.java
= src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionSetBase.java
+ src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1HeapRegionType.java
= src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1PrintRegionClosure.java
- src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionClosure.java
- src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/HeapRegionType.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java
! test/hotspot/gtest/gc/g1/test_freeRegionList.cpp
! test/hotspot/gtest/gc/g1/test_g1CardSetContainers.cpp
! test/hotspot/gtest/gc/g1/test_g1RegionMap.cpp

Changeset: 6409ec33
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-05 08:43:27 +0000
URL:       https://git.openjdk.org/leyden/commit/6409ec336af647044d0746c219496ad070de5e9d

8335711: G1: Remove unused bot_updates argument in G1AllocRegion constructor

Reviewed-by: iwalulya, tschatzl

! src/hotspot/share/gc/g1/g1AllocRegion.cpp
! src/hotspot/share/gc/g1/g1AllocRegion.hpp

Changeset: bdf470b3
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-07-05 09:06:37 +0000
URL:       https://git.openjdk.org/leyden/commit/bdf470b3b8f8814cb29f2877490d5bc1e79bdecb

8335742: Problemlist gc/g1/TestMixedGCLiveThreshold.java#25percent with virtual threads

Reviewed-by: aboldtch, kbarrett

! test/hotspot/jtreg/ProblemList-Virtual.txt

Changeset: c8acea87
Branch: premain
Author:    Ivan Walulya <iwalulya at openjdk.org>
Date:      2024-07-05 09:10:30 +0000
URL:       https://git.openjdk.org/leyden/commit/c8acea87e2c5ba6672c011ec4e57a53c55fee74b

8335706: G1: Remove unused G1ConcurrentRefine::RemSetSamplingClosure::_cset

Reviewed-by: ayang, tschatzl

! src/hotspot/share/gc/g1/g1ConcurrentRefine.cpp

Changeset: 194425d7
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-05 12:50:09 +0000
URL:       https://git.openjdk.org/leyden/commit/194425d7875ef42fce52516ed59c81ee97720399

8335645: j.u.Formatter#trailingZeros improved with String repeat

Reviewed-by: liach, jlu, naoto

! src/java.base/share/classes/java/util/Formatter.java

Changeset: ff49f677
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-07-05 13:44:35 +0000
URL:       https://git.openjdk.org/leyden/commit/ff49f677ee5017019c90823bc412ceb90068ffbd

8335775: Remove extraneous 's' in comment of rawmonitor.cpp test file

Reviewed-by: gdams, stuefe

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/rawmonitor/rawmonitor.cpp

Changeset: 7efe1603
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-05 16:44:41 +0000
URL:       https://git.openjdk.org/leyden/commit/7efe16038e5df9894a265ea1214068060f595c4e

8335730: JFR: Clean up jdk.jfr

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedClass.java
! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedFrame.java
! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedMethod.java
! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedObject.java
! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordedThread.java
! src/jdk.jfr/share/classes/jdk/jfr/events/AbstractBufferStatisticsEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveRecordingEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ActiveSettingEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/events/ExceptionStatisticsEvent.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventControl.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/RepositoryChunk.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/ShutdownHook.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/QueryRecording.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/model/XmlSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/Row.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/query/TableSorter.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/settings/LevelSetting.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Disassemble.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/PrettyWriter.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/View.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/ValueParser.java

Changeset: b83766e5
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-05 17:07:22 +0000
URL:       https://git.openjdk.org/leyden/commit/b83766e59063a41ea8801ac9e7c15dce67727c62

8335632: jdk/jfr/api/consumer/streaming/TestJVMExit.java failed with "Process [...] is no longer alive"

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/api/consumer/streaming/TestJVMExit.java

Changeset: 6f7f0f1d
Branch: premain
Author:    Per Minborg <pminborg at openjdk.org>
Date:      2024-07-06 15:05:26 +0000
URL:       https://git.openjdk.org/leyden/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef

8333884: MemorySegment::reinterpret removes read-only property

Reviewed-by: jvernee, mcimadamore

! src/java.base/share/classes/java/lang/foreign/MemorySegment.java
! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
! src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java
! test/jdk/java/foreign/TestSegments.java

Changeset: 3f37c571
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2024-07-08 01:19:36 +0000
URL:       https://git.openjdk.org/leyden/commit/3f37c5718d676b7001e6a084aed3ba645745a144

8335806: RISC-V: Corrected typos Bizarrely

Reviewed-by: aph, amitkumar

! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp

Changeset: 02956ab6
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Date:      2024-07-08 06:23:03 +0000
URL:       https://git.openjdk.org/leyden/commit/02956ab6e161ca8556a73f328f79bcbfba997cbc

8332163: C2 SuperWord: refactor PacksetGraph and SuperWord::output into VTransformGraph

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/superword.hpp
+ src/hotspot/share/opto/superwordVTransformBuilder.cpp
+ src/hotspot/share/opto/superwordVTransformBuilder.hpp
! src/hotspot/share/opto/traceAutoVectorizationTag.hpp
! src/hotspot/share/opto/vectorization.cpp
! src/hotspot/share/opto/vectorization.hpp
+ src/hotspot/share/opto/vtransform.cpp
+ src/hotspot/share/opto/vtransform.hpp

Changeset: 55fd1ed2
Branch: premain
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-07-08 06:42:46 +0000
URL:       https://git.openjdk.org/leyden/commit/55fd1ed228ea3c42aaf92579e5dcb818fe14351d

8333890: Fatal error in auto-vectorizer with float16 kernel.

Reviewed-by: kvn

! src/hotspot/share/opto/superword.cpp
+ test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java

Changeset: 3cce31ad
Branch: premain
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-07-08 08:06:56 +0000
URL:       https://git.openjdk.org/leyden/commit/3cce31ad8877ec62429981871bcb0067770f9ccb

8335643: serviceability/dcmd/vm tests fail for ZGC after JDK-8322475

Reviewed-by: sgehwolf, dholmes

! test/hotspot/jtreg/ProblemList-generational-zgc.txt
! test/hotspot/jtreg/ProblemList-zgc.txt
! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java

Changeset: 540188fd
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-08 10:03:39 +0000
URL:       https://git.openjdk.org/leyden/commit/540188fdebd089d4145eca18c0f95bf338cbcefc

8334445: Parallel: Decouple maximum compaction from SoftReference clearing

Reviewed-by: zgu, lmao

! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.hpp
! src/hotspot/share/gc/parallel/psScavenge.cpp

Changeset: c5a668bb
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-08 10:33:08 +0000
URL:       https://git.openjdk.org/leyden/commit/c5a668bb653feb3408a9efa3274ceabf9f01a2c7

8334231: Optimize MethodData layout

Reviewed-by: dholmes, chagedorn, shade

! src/hotspot/share/oops/methodData.hpp

Changeset: c34a1b70
Branch: premain
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2024-07-08 10:53:03 +0000
URL:       https://git.openjdk.org/leyden/commit/c34a1b7013b27a8a214f63387bd528a90342a416

8335861: Problem list compiler/vectorization/TestFloat16VectorConvChain.java

Reviewed-by: epeter

! test/hotspot/jtreg/ProblemList.txt

Changeset: 953c35eb
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-07-08 11:44:04 +0000
URL:       https://git.openjdk.org/leyden/commit/953c35eb5bff49ec5f7dbb25edd8a324b94318eb

8335824: Test gc/arguments/TestMinInitialErgonomics.java is timing out

Reviewed-by: ayang, kbarrett

! test/hotspot/jtreg/gc/arguments/TestMinInitialErgonomics.java

Changeset: cec222e4
Branch: premain
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2024-07-08 12:39:33 +0000
URL:       https://git.openjdk.org/leyden/commit/cec222e46065fc15db3f2eb241d3607d605ab580

8317611: Add a tool like jdeprscan to find usage of restricted methods

Reviewed-by: alanb, ihse, mcimadamore, jlahoda, jwaters

! make/modules/jdk.jdeps/Launcher.gmk
! src/jdk.compiler/share/classes/com/sun/tools/javac/platform/JDKPlatformProvider.java
! src/jdk.internal.opt/share/classes/module-info.java
! src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/Main.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassFileSource.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanFatalError.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/JNativeScanTask.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/MethodRef.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/NativeMethodFinder.java
+ src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedUse.java
! src/jdk.jdeps/share/classes/module-info.java
+ src/jdk.jdeps/share/man/jnativescan.1
! test/jdk/tools/launcher/HelpFlagsTest.java
! test/langtools/TEST.groups
+ test/langtools/tools/jnativescan/JNativeScanTestBase.java
+ test/langtools/tools/jnativescan/TestArrayTypeRefs.java
+ test/langtools/tools/jnativescan/TestJNativeScan.java
+ test/langtools/tools/jnativescan/TestMissingSystemClass.java
+ test/langtools/tools/jnativescan/TestSubclassRefs.java
+ test/langtools/tools/jnativescan/cases/classpath/app/App.java
+ test/langtools/tools/jnativescan/cases/classpath/arrayref/App.java
+ test/langtools/tools/jnativescan/cases/classpath/lib/Lib.java
+ test/langtools/tools/jnativescan/cases/classpath/missingsystem/App.java
+ test/langtools/tools/jnativescan/cases/classpath/singlejar/main/Main.java
+ test/langtools/tools/jnativescan/cases/classpath/subclassref/App.java
+ test/langtools/tools/jnativescan/cases/classpath/unnamed_package/UnnamedPackage.java
+ test/langtools/tools/jnativescan/cases/modules/org.lib/module-info.java
+ test/langtools/tools/jnativescan/cases/modules/org.lib/org/lib/Lib.java
+ test/langtools/tools/jnativescan/cases/modules/org.lib/org/lib/Service.java
+ test/langtools/tools/jnativescan/cases/modules/org.myapp/module-info.java
+ test/langtools/tools/jnativescan/cases/modules/org.myapp/org/myapp/main/Main.java
+ test/langtools/tools/jnativescan/cases/modules/org.service/module-info.java
+ test/langtools/tools/jnativescan/cases/modules/org.service/org/service/ServiceImpl.java
+ test/langtools/tools/jnativescan/cases/modules/org.singlejar/module-info.java
+ test/langtools/tools/jnativescan/cases/modules/org.singlejar/org/singlejar/main/Main.java

Changeset: be3676f6
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Date:      2024-07-08 14:04:32 +0000
URL:       https://git.openjdk.org/leyden/commit/be3676f6bbc2d8041e43cf7bcfaee7fb9d864378

8304484: CDS dynamic dumping incorrectly leads to "Error occurred during initialization of VM"

Reviewed-by: ccheung, iklam

! src/hotspot/share/classfile/classLoader.cpp

Changeset: d8c1c6ab
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-08 15:45:26 +0000
URL:       https://git.openjdk.org/leyden/commit/d8c1c6ab0543c986280dcfa1c6c79e010a7b35fb

8335604: Serial: Inline Generation::contiguous_available

Reviewed-by: tschatzl

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/generation.hpp
! src/hotspot/share/gc/serial/tenuredGeneration.cpp
! src/hotspot/share/gc/serial/tenuredGeneration.hpp

Changeset: a9b7f42f
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-07-08 16:20:01 +0000
URL:       https://git.openjdk.org/leyden/commit/a9b7f42f29120a3cca0d341350ff03cae485e68b

8333826: Update --release 23 symbol information for JDK 23 build 29

Reviewed-by: iris, jlahoda

! src/jdk.compiler/share/data/symbols/java.desktop-N.sym.txt

Changeset: 284671a1
Branch: premain
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2024-07-08 16:44:22 +0000
URL:       https://git.openjdk.org/leyden/commit/284671a1e4fb5bfe15b20b7f41fc24415b1235ed

8335449: runtime/cds/DeterministicDump.java fails with File content different at byte ...

Reviewed-by: matsaave, iklam

! test/hotspot/jtreg/runtime/cds/DeterministicDump.java

Changeset: 3a87eb5c
Branch: premain
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Date:      2024-07-08 18:03:19 +0000
URL:       https://git.openjdk.org/leyden/commit/3a87eb5c4606ce39970962895315567e8606eba7

8335126: Shenandoah: Improve OOM handling

Reviewed-by: shade, ysr, wkemper, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp

Changeset: 3733fe3a
Branch: premain
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2024-07-08 19:14:33 +0000
URL:       https://git.openjdk.org/leyden/commit/3733fe3a207078b585421cd2a098e808fafaa817

8335789: [TESTBUG] XparColor.java test fails with Error. Parse Exception: Invalid or unrecognized bugid: @

Reviewed-by: aivanov

! test/jdk/java/awt/print/PrinterJob/XparColor.java

Changeset: babf6df7
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-07-08 20:09:07 +0000
URL:       https://git.openjdk.org/leyden/commit/babf6df7d97e4beedb25e689634d999412c1e950

8334757: AssertionError: Missing type variable in where clause

Reviewed-by: jlahoda, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java
+ test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateClassWithTypeVariable.java
+ test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateClassWithTypeVariable.out

Changeset: bb1f8a16
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-08 20:10:27 +0000
URL:       https://git.openjdk.org/leyden/commit/bb1f8a1698553d5962569ac8912edd0d7ef010dd

8335904: Fix invalid comment in ShenandoahLock

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahLock.cpp

Changeset: 9c7a6eab
Branch: premain
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2024-07-08 20:14:26 +0000
URL:       https://git.openjdk.org/leyden/commit/9c7a6eabb93c570fdb74076edc931576ed6be3e0

8312125: Refactor CDS enum class handling

Reviewed-by: matsaave, ccheung

+ src/hotspot/share/cds/cdsEnumKlass.cpp
+ src/hotspot/share/cds/cdsEnumKlass.hpp
! src/hotspot/share/cds/heapShared.cpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/oops/instanceKlass.cpp

Changeset: 564a72e1
Branch: premain
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2024-07-09 08:10:55 +0000
URL:       https://git.openjdk.org/leyden/commit/564a72e1dba0f145600c8e7eff66992fbf294df0

8335955: JDK-8335742 wrongly used a "JDK-" prefix in the problemlist bug number

Reviewed-by: iwalulya

! test/hotspot/jtreg/ProblemList-Virtual.txt

Changeset: 2a296475
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-07-09 08:25:00 +0000
URL:       https://git.openjdk.org/leyden/commit/2a2964759c73b3b9ab6afaad109383c89952977b

8334777: Test javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java failed with NullPointerException

Reviewed-by: cjplummer, dholmes

! test/jdk/javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java

Changeset: 8f62f31d
Branch: premain
Author:    Amit Kumar <amitkumar at openjdk.org>
Date:      2024-07-09 08:26:25 +0000
URL:       https://git.openjdk.org/leyden/commit/8f62f31dff564289a2422d58e8ecd5062d443b81

8335906: [s390x] Test Failure: GTestWrapper.java

Reviewed-by: stuefe

! src/hotspot/share/runtime/os.cpp

Changeset: f3ff4f74
Branch: premain
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2024-07-09 10:21:47 +0000
URL:       https://git.openjdk.org/leyden/commit/f3ff4f7427c3c3f5cb2a115a61462bb9d28de1cd

8335882: platform/cgroup/TestSystemSettings.java fails on Alpine Linux

Reviewed-by: stuefe, mbaesken

! test/jdk/jdk/internal/platform/cgroup/TestSystemSettings.java

Changeset: 0e0dfca2
Branch: premain
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Dmitry Samersoff <dsamersoff at openjdk.org>
Date:      2024-07-09 10:27:44 +0000
URL:       https://git.openjdk.org/leyden/commit/0e0dfca21f64ecfcb3e5ed7cdc2a173834faa509

8330806: test/hotspot/jtreg/compiler/c1/TestLargeMonitorOffset.java fails on ARM32

Reviewed-by: snazarki, dsamersoff

! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp

Changeset: 531a6d85
Branch: premain
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2024-07-09 13:11:07 +0000
URL:       https://git.openjdk.org/leyden/commit/531a6d85b00b88688668ab1ced0db6ce0214a5f1

8335911: Document ccls indexer in doc/ide.md

Reviewed-by: erikj

! doc/ide.html
! doc/ide.md

Changeset: 7e11fb70
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-09 13:11:20 +0000
URL:       https://git.openjdk.org/leyden/commit/7e11fb702696df733ca89d325200f2e9414402d9

8335688: Fix -Wzero-as-null-pointer-constant warnings from fflush calls in jvmti tests

Reviewed-by: jwaters, coleenp

! test/hotspot/jtreg/serviceability/jvmti/AddModuleUsesAndProvides/libAddModuleUsesAndProvidesTest.c
! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents1.cpp
! test/hotspot/jtreg/serviceability/jvmti/GenerateEvents/libGenerateEvents2.cpp
! test/hotspot/jtreg/serviceability/jvmti/GetClassFields/FilteredFields/libFilteredFieldsTest.cpp
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/MissedStackMapFrames/libMissedStackMapFrames.cpp
! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineRetransform/libRedefineRetransform.cpp
! test/hotspot/jtreg/serviceability/jvmti/events/FramePop/framepop02/libframepop02.cpp
! test/hotspot/jtreg/serviceability/jvmti/thread/GetStackTrace/get_stack_trace.hpp
! test/hotspot/jtreg/serviceability/jvmti/vthread/SuspendResume1/libSuspendResume1.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassFields/getclfld007/getclfld007.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref001/followref001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref002/followref002.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref003/followref003.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref004/followref004.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref005/followref005.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/FollowReferences/followref006/followref006.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretbase/earlyretbase.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretfp/earlyretfp.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretint/earlyretint.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretlong/earlyretlong.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretobj/earlyretobj.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretstr/earlyretstr.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/ForceEarlyReturn/earlyretvoid/earlyretvoid.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetAllStackTraces/getallstktr001/getallstktr001.cpp
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/GetConstantPool/getcpool001/getcpool001.cpp

Changeset: 14721244
Branch: premain
Author:    Mark Powers <mpowers at openjdk.org>
Date:      2024-07-09 20:38:09 +0000
URL:       https://git.openjdk.org/leyden/commit/1472124489c841642996ae984e21c533ffec8091

8333364: Minor cleanup could be done in com.sun.crypto.provider

Reviewed-by: mullan, valeriep

! src/java.base/share/classes/com/sun/crypto/provider/AESKeyGenerator.java
! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrap.java
! src/java.base/share/classes/com/sun/crypto/provider/AESKeyWrapPadded.java
! src/java.base/share/classes/com/sun/crypto/provider/ARCFOURCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Cipher.java
! src/java.base/share/classes/com/sun/crypto/provider/ChaCha20Poly1305Parameters.java
! src/java.base/share/classes/com/sun/crypto/provider/CipherBlockChaining.java
! src/java.base/share/classes/com/sun/crypto/provider/CipherCore.java
! src/java.base/share/classes/com/sun/crypto/provider/CipherTextStealing.java
! src/java.base/share/classes/com/sun/crypto/provider/ConstructKeys.java
! src/java.base/share/classes/com/sun/crypto/provider/DESCrypt.java
! src/java.base/share/classes/com/sun/crypto/provider/DESKeyFactory.java
! src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyFactory.java
! src/java.base/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java
! src/java.base/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/DHKEM.java
! src/java.base/share/classes/com/sun/crypto/provider/DHKeyAgreement.java
! src/java.base/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java
! src/java.base/share/classes/com/sun/crypto/provider/ElectronicCodeBook.java
! src/java.base/share/classes/com/sun/crypto/provider/FeedbackCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/GCTR.java
! src/java.base/share/classes/com/sun/crypto/provider/GHASH.java
! src/java.base/share/classes/com/sun/crypto/provider/GaloisCounterMode.java
! src/java.base/share/classes/com/sun/crypto/provider/HmacCore.java
! src/java.base/share/classes/com/sun/crypto/provider/HmacMD5.java
! src/java.base/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java
! src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1.java
! src/java.base/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java
! src/java.base/share/classes/com/sun/crypto/provider/ISO10126Padding.java
! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java
! src/java.base/share/classes/com/sun/crypto/provider/KWUtil.java
! src/java.base/share/classes/com/sun/crypto/provider/KeyProtector.java
! src/java.base/share/classes/com/sun/crypto/provider/KeyWrapCipher.java
! src/java.base/share/classes/com/sun/crypto/provider/OAEPParameters.java
! src/java.base/share/classes/com/sun/crypto/provider/OutputFeedback.java
! src/java.base/share/classes/com/sun/crypto/provider/PBEKeyFactory.java
! src/java.base/share/classes/com/sun/crypto/provider/PBES1Core.java
! src/java.base/share/classes/com/sun/crypto/provider/PBES2Parameters.java
! src/java.base/share/classes/com/sun/crypto/provider/PBKDF2KeyImpl.java
! src/java.base/share/classes/com/sun/crypto/provider/PBMAC1Core.java
! src/java.base/share/classes/com/sun/crypto/provider/PKCS5Padding.java
! src/java.base/share/classes/com/sun/crypto/provider/Poly1305.java
! src/java.base/share/classes/com/sun/crypto/provider/RC2Crypt.java
! src/java.base/share/classes/com/sun/crypto/provider/RSACipher.java
! src/java.base/share/classes/com/sun/crypto/provider/SslMacCore.java
! src/java.base/share/classes/com/sun/crypto/provider/TlsKeyMaterialGenerator.java
! src/java.base/share/classes/com/sun/crypto/provider/TlsPrfGenerator.java

Changeset: dcf4e0d5
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-10 03:30:19 +0000
URL:       https://git.openjdk.org/leyden/commit/dcf4e0d51f392afe2711223484e932e3826e8864

8335966: Remove incorrect problem listing of java/lang/instrument/NativeMethodPrefixAgent.java in ProblemList-Virtual.txt

Reviewed-by: kevinw, amenkov

! test/jdk/ProblemList-Virtual.txt

Changeset: b5909cab
Branch: premain
Author:    Koichi Sakata <ksakata at openjdk.org>
Date:      2024-07-10 05:57:11 +0000
URL:       https://git.openjdk.org/leyden/commit/b5909cabeef22954f4d9c642b1cbf288b3454562

8323242: Remove vestigial DONT_USE_REGISTER_DEFINES

Reviewed-by: gli, kvn

! src/hotspot/cpu/zero/register_zero.hpp

Changeset: a44b60c8
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-07-10 07:53:52 +0000
URL:       https://git.openjdk.org/leyden/commit/a44b60c8c14ad998e51239f48e64779304aaac50

8335778: runtime/ClassInitErrors/TestStackOverflowDuringInit.java fails on ppc64 platforms after JDK-8334545

Reviewed-by: dholmes, asteiner

! test/hotspot/jtreg/runtime/ClassInitErrors/TestStackOverflowDuringInit.java

Changeset: 537d20af
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-07-10 09:55:56 +0000
URL:       https://git.openjdk.org/leyden/commit/537d20afbff255489a7b1bdb0410b9d1aba715b7

8335766: Switch case with pattern matching and guard clause compiles inconsistently

Reviewed-by: abimpoudis

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/langtools/tools/javac/patterns/DisambiguatePatterns.java

Changeset: e0fb9494
Branch: premain
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2024-07-10 14:28:20 +0000
URL:       https://git.openjdk.org/leyden/commit/e0fb949460d0c7e2ab1697a6466e7d4831a20a33

8335779: JFR: Hide sleep events

Reviewed-by: mgronlun

! src/hotspot/share/jfr/support/jfrIntrinsics.hpp
! src/hotspot/share/runtime/objectMonitor.cpp
- src/jdk.jfr/share/classes/jdk/jfr/internal/HiddenWait.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/JVM.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/JVMSupport.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/MetadataRepository.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/OngoingStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RecordingInput.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/RepositoryFiles.java
+ src/jdk.jfr/share/classes/jdk/jfr/internal/management/HiddenWait.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/management/StreamBarrier.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/util/Utils.java
! src/jdk.management.jfr/share/classes/jdk/management/jfr/DownLoadThread.java
! src/jdk.management.jfr/share/classes/jdk/management/jfr/FileDump.java
+ test/jdk/jdk/jfr/jvm/TestHiddenWait.java

Changeset: e6c5aa7a
Branch: premain
Author:    Christian Stein <cstein at openjdk.org>
Date:      2024-07-10 15:12:49 +0000
URL:       https://git.openjdk.org/leyden/commit/e6c5aa7a6cb54c647d261facdcffa6a410849627

8336012: Fix usages of jtreg-reserved properties

Reviewed-by: jjg

! test/jdk/java/lang/invoke/PrivateInvokeTest.java

Changeset: fb9a227e
Branch: premain
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-07-10 15:34:27 +0000
URL:       https://git.openjdk.org/leyden/commit/fb9a227e02ebf826edb762283e15dd7e402f8433

8313909: [JVMCI] assert(cp->tag_at(index).is_unresolved_klass()) in lookupKlassInPool

Reviewed-by: yzheng, never

! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp

Changeset: fb66716a
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-07-10 16:12:40 +0000
URL:       https://git.openjdk.org/leyden/commit/fb66716a1bc914db194c5b0b833cc2317704f166

8331725: ubsan: pc may not always be the entry point for a VtableStub

Reviewed-by: kvn, mbaesken

! src/hotspot/share/code/vtableStubs.cpp
! src/hotspot/share/code/vtableStubs.hpp

Changeset: 7ab96c74
Branch: premain
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2024-07-10 16:26:16 +0000
URL:       https://git.openjdk.org/leyden/commit/7ab96c74e2c39f430a5c2f65a981da7314a2385b

8335409: Can't allocate and retain memory from resource area in frame::oops_interpreted_do oop closure after 8329665

Reviewed-by: dholmes, stuefe, coleenp, shade

! src/hotspot/share/interpreter/oopMapCache.cpp
! src/hotspot/share/interpreter/oopMapCache.hpp
! src/hotspot/share/runtime/frame.cpp

Changeset: 66db7156
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-07-10 16:36:39 +0000
URL:       https://git.openjdk.org/leyden/commit/66db71563c3ebd715a1192a9b399b618d7bdb8d0

8335637: Add explicit non-null return value expectations to Object.toString()

Reviewed-by: jpai, alanb, smarks, prappo

! src/java.base/share/classes/java/lang/Object.java

Changeset: 242f1133
Branch: premain
Author:    Yudi Zheng <yzheng at openjdk.org>
Date:      2024-07-10 19:42:23 +0000
URL:       https://git.openjdk.org/leyden/commit/242f1133f8e1b373de3714cefc7f6701c39707fe

8334481: [JVMCI] add LINK_TO_NATIVE to MethodHandleAccessProvider.IntrinsicMethod

Reviewed-by: dnsimon

! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMethodHandleAccessProvider.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/meta/MethodHandleAccessProvider.java

Changeset: cad68e06
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-10 21:06:39 +0000
URL:       https://git.openjdk.org/leyden/commit/cad68e06ecad1e19091d1af9c0f9b8145d6842fb

8335935: Chained builders not sending transformed models to next transforms

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BlockCodeBuilderImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedClassBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ChainedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/LabelContext.java
! src/java.base/share/classes/jdk/internal/classfile/impl/TerminalCodeBuilder.java
- src/java.base/share/classes/jdk/internal/classfile/impl/TransformingCodeBuilder.java
! test/jdk/jdk/classfile/TransformTests.java

Changeset: d6c6847e
Branch: premain
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-07-11 02:44:12 +0000
URL:       https://git.openjdk.org/leyden/commit/d6c6847e32673d36a1958cefd1851ec9f3b1e2ad

8335743: jhsdb jstack cannot print some information on the waiting thread

Reviewed-by: dholmes, cjplummer, kevinw

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/JavaVFrame.java
! test/hotspot/jtreg/serviceability/sa/LingeredAppWithLock.java
! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java

Changeset: b363de8c
Branch: premain
Author:    Kuai Wei <kuaiwei.kw at alibaba-inc.com>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2024-07-11 02:44:25 +0000
URL:       https://git.openjdk.org/leyden/commit/b363de8c9fbf7d9e4aade41a2e883cc83ced320b

8335946: DTrace code snippets should be generated when DTrace flags are enabled

Reviewed-by: coleenp, dholmes

! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/riscv/interp_masm_riscv.cpp
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp
! src/hotspot/cpu/riscv/templateTable_riscv.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp

Changeset: cf940e13
Branch: premain
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2024-07-11 07:03:44 +0000
URL:       https://git.openjdk.org/leyden/commit/cf940e139a76e5aabd52379b8a87065d82b2284c

8335553: [Graal] Compiler thread calls into jdk.internal.vm.VMSupport.decodeAndThrowThrowable and crashes in OOM situation

Reviewed-by: yzheng, never, dholmes

! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/utilities/exceptions.cpp
! src/java.base/share/classes/jdk/internal/vm/TranslatedException.java
! src/java.base/share/classes/jdk/internal/vm/VMSupport.java
! test/jdk/jdk/internal/vm/TestTranslatedException.java

Changeset: b7d0eff5
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-07-11 07:29:37 +0000
URL:       https://git.openjdk.org/leyden/commit/b7d0eff5ad77e338b237773d2fc047eea3d2ac12

8207908: JMXStatusTest.java fails assertion intermittently

Reviewed-by: cjplummer, amenkov

! test/jdk/sun/management/jmxremote/startstop/JMXStatusTest.java
! test/jdk/sun/management/jmxremote/startstop/ManagementAgentJcmd.java

Changeset: 1772a929
Branch: premain
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2024-07-11 07:35:48 +0000
URL:       https://git.openjdk.org/leyden/commit/1772a929af0c31bf22153cc19c5d11b00273453b

8334457: Test javax/swing/JTabbedPane/bug4666224.java fail on macOS with because pressing the ?C? key does not switch the layout to WRAP_TAB_LAYOUT

Reviewed-by: achung, abhiscxk, tr

! test/jdk/javax/swing/JTabbedPane/bug4666224.java

Changeset: 2928753b
Branch: premain
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Date:      2024-07-11 08:18:46 +0000
URL:       https://git.openjdk.org/leyden/commit/2928753bd95356467e4fe42ee391e45d1cb6e89c

8324966: Allow selecting jtreg test case by ID from make

Reviewed-by: erikj

! make/InitSupport.gmk

Changeset: 62cbf703
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-11 08:28:25 +0000
URL:       https://git.openjdk.org/leyden/commit/62cbf70346e78ca94ce6ea4ba5a308ea0a2bbfa8

8336085: Fix simple -Wzero-as-null-pointer-constant warnings in CDS code

Reviewed-by: dholmes, jwaters

! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/filemap.hpp

Changeset: b32e4a68
Branch: premain
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-11 08:47:15 +0000
URL:       https://git.openjdk.org/leyden/commit/b32e4a68bca588d908bd81a398eb3171a6876dc5

8335356: Shenandoah: Improve concurrent cleanup locking

Reviewed-by: ysr, shade

! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp

Changeset: 6fcd49f9
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-07-11 10:08:54 +0000
URL:       https://git.openjdk.org/leyden/commit/6fcd49f9431cc3507f96ef2acdca43fc6a394a14

8336239: Fix javadoc markup in java.lang.Process

Reviewed-by: jpai

! src/java.base/share/classes/java/lang/Process.java

Changeset: 5c612c23
Branch: premain
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2024-07-11 10:24:00 +0000
URL:       https://git.openjdk.org/leyden/commit/5c612c230b0a852aed5fd36e58b82ebf2e1838af

8332689: RISC-V: Use load instead of trampolines

Reviewed-by: fyang, mli, luhenry

! src/hotspot/cpu/riscv/c1_CodeStubs_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.cpp
! src/hotspot/cpu/riscv/c1_LIRAssembler_riscv.hpp
! src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/codeBuffer_riscv.cpp
! src/hotspot/cpu/riscv/codeBuffer_riscv.hpp
! src/hotspot/cpu/riscv/compiledIC_riscv.cpp
! src/hotspot/cpu/riscv/globals_riscv.hpp
! src/hotspot/cpu/riscv/jvmciCodeInstaller_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.cpp
! src/hotspot/cpu/riscv/macroAssembler_riscv.hpp
! src/hotspot/cpu/riscv/nativeInst_riscv.cpp
! src/hotspot/cpu/riscv/nativeInst_riscv.hpp
! src/hotspot/cpu/riscv/relocInfo_riscv.cpp
! src/hotspot/cpu/riscv/riscv.ad
! src/hotspot/cpu/riscv/sharedRuntime_riscv.cpp

Changeset: dea92742
Branch: premain
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
Date:      2024-07-11 14:12:13 +0000
URL:       https://git.openjdk.org/leyden/commit/dea92742c2b5889717f2183dc29b5772daff5340

8332125: [nmt] Totals in diff report should print out total malloc and mmap diffs

Reviewed-by: stuefe, jsjolen

! src/hotspot/share/nmt/memReporter.cpp
+ test/hotspot/jtreg/runtime/NMT/TotalMallocMmapDiffTest.java

Changeset: d06d79c8
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-11 16:07:03 +0000
URL:       https://git.openjdk.org/leyden/commit/d06d79c80980644df511cded0eb8bc0309d878d3

8325369: @sealedGraph: Bad link to image for tag on nested classes

Reviewed-by: jjg

! make/jdk/src/classes/build/tools/taglet/SealedGraph.java

Changeset: 58c98420
Branch: premain
Author:    Joe Wang <joehw at openjdk.org>
Date:      2024-07-11 18:38:32 +0000
URL:       https://git.openjdk.org/leyden/commit/58c98420b65bcea08f37982fdfba747005c03553

8336021: Doccheck: valign not allowed for HTML5 in java.xml

Reviewed-by: lancea

! src/java.xml/share/classes/org/w3c/dom/Attr.java

Changeset: 5100303c
Branch: premain
Author:    Justin Lu <jlu at openjdk.org>
Date:      2024-07-11 18:40:40 +0000
URL:       https://git.openjdk.org/leyden/commit/5100303c6c5e4224d2c41f90719139bb5f4e236e

8335668: NumberFormat integer only parsing should throw exception for edge case

Reviewed-by: naoto

! src/java.base/share/classes/java/text/DecimalFormat.java
! test/jdk/java/text/Format/NumberFormat/LenientParseTest.java
! test/jdk/java/text/Format/NumberFormat/StrictParseTest.java

Changeset: 9eb611e7
Branch: premain
Author:    Liam Miller-Cushon <cushon at openjdk.org>
Date:      2024-07-11 19:53:52 +0000
URL:       https://git.openjdk.org/leyden/commit/9eb611e7f07ebb6eb0cbcca32d644abf8352c991

8334055: Unhelpful 'required: reference' diagnostics after JDK-8043226

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateMissingSymbol.java
+ test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateMissingSymbol.out
! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.java
! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotatePackages.out
! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.java
! test/langtools/tools/javac/annotations/typeAnnotations/failures/CantAnnotateScoping.out

Changeset: 73e3e0ed
Branch: premain
Author:    Dean Long <dlong at openjdk.org>
Date:      2024-07-11 20:18:16 +0000
URL:       https://git.openjdk.org/leyden/commit/73e3e0edeb20c6f701b213423476f92fb05dd262

8321509: False positive in get_trampoline fast path causes crash

Reviewed-by: kvn, adinn, thartmann

! src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp
! src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp
! src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp
! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp

Changeset: 88905571
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-11 20:44:21 +0000
URL:       https://git.openjdk.org/leyden/commit/889055713ea83f899ebd7bf640dcf3c3e1a82ebe

8335623: Clean up HtmlTag.HtmlTag and make the ARIA role attribute global

Reviewed-by: liach

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java

Changeset: 687601eb
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-07-11 20:45:34 +0000
URL:       https://git.openjdk.org/leyden/commit/687601ebcaedf133fd4d5cecc42c5aadf9c73f3c

8336257: Additional tests in jmxremote/startstop to match on PID not app name

Reviewed-by: cjplummer, alanb, amenkov, dcubed

! test/jdk/sun/management/jmxremote/startstop/JMXStartStopTest.java
! test/jdk/sun/management/jmxremote/startstop/JMXStatusPerfCountersTest.java

Changeset: b3ef2a60
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-11 20:51:27 +0000
URL:       https://git.openjdk.org/leyden/commit/b3ef2a600cfec31723dc78fe552e9cf9976b0337

8336036: Synthetic documentation for a record's equals is incorrect for floating-point types

Reviewed-by: prappo

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java

Changeset: 81a0d1ba
Branch: premain
Author:    Vanitha B P <vanitha.b.p at oracle.com>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
Date:      2024-07-11 21:27:30 +0000
URL:       https://git.openjdk.org/leyden/commit/81a0d1ba03bbdbe718302b3925cdc207d5d05232

8325525: Create jtreg test case for JDK-8325203

Reviewed-by: asemenyuk, almatvee

+ test/jdk/tools/jpackage/apps/ChildProcessAppLauncher.java
+ test/jdk/tools/jpackage/windows/WinChildProcessTest.java

Changeset: c703d290
Branch: premain
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-07-12 05:56:53 +0000
URL:       https://git.openjdk.org/leyden/commit/c703d290425f85a06e61d72c9672ac2adac92db9

8335710: serviceability/dcmd/vm/SystemDumpMapTest.java and SystemMapTest.java fail on Linux Alpine after 8322475

Reviewed-by: stuefe, lucy

! test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTestBase.java

Changeset: 1fe3ada0
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Alex Menkov <amenkov at openjdk.org>
Date:      2024-07-12 08:14:56 +0000
URL:       https://git.openjdk.org/leyden/commit/1fe3ada001e188754df5de00bf6804f028ad274b

8336284: Test TestClhsdbJstackLock.java/TestJhsdbJstackLock.java fails with -Xcomp after JDK-8335743

Reviewed-by: cjplummer, amenkov

! test/hotspot/jtreg/serviceability/sa/TestClhsdbJstackLock.java
! test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackLock.java

Changeset: f677b90e
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-07-12 08:19:24 +0000
URL:       https://git.openjdk.org/leyden/commit/f677b90eb93026d3fdfd4ae19d48415a7d8318e8

8267887: RMIConnector_NPETest.java fails after removal of RMI Activation (JDK-8267123)

Reviewed-by: cjplummer, sspitsyn

! test/jdk/ProblemList.txt
- test/jdk/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java

Changeset: 7a620329
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-12 09:30:38 +0000
URL:       https://git.openjdk.org/leyden/commit/7a6203296416268f1c3f269d0db2b0c817642a34

8336081: Fix -Wzero-as-null-pointer-constant warnings in JVMTypedFlagLimit ctors

Reviewed-by: dholmes, jwaters

! src/hotspot/share/runtime/flags/jvmFlagLimit.hpp

Changeset: 9b6f6c5c
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-12 09:33:04 +0000
URL:       https://git.openjdk.org/leyden/commit/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf

8336082: Fix -Wzero-as-null-pointer-constant warnings in SimpleCompactHashtable

Reviewed-by: coleenp, dholmes

! src/hotspot/share/classfile/compactHashtable.hpp

Changeset: eec0e155
Branch: premain
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2024-07-12 12:09:58 +0000
URL:       https://git.openjdk.org/leyden/commit/eec0e155f303ff4bbdab172765ca7c92c2b94cbd

8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors

Reviewed-by: alanb, stuefe, liach

! src/java.instrument/share/classes/java/lang/instrument/ClassFileTransformer.java

Changeset: 559826c2
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-07-12 12:17:21 +0000
URL:       https://git.openjdk.org/leyden/commit/559826c2922851dbe45ead23ad1d73b1846334ac

8332474: Tighten up ToolBox' JavacTask to not silently accept javac crash as a failure

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! test/langtools/tools/lib/toolbox/AbstractTask.java
! test/langtools/tools/lib/toolbox/JavacTask.java

Changeset: 2fc7eb44
Branch: premain
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
Date:      2024-07-12 12:37:58 +0000
URL:       https://git.openjdk.org/leyden/commit/2fc7eb44a018974734832576a0a2631ae747e0cd

8155030: The Menu Mnemonics are always displayed for GTK LAF

Hides mnemonics on menus, buttons, and labels for GTK L&F.

Moved shared code for hiding mnemonics into
sun/swing/MnemonicHandler and AltProcessor to avoid code duplication.

Reviewed-by: prr, tr, achung, dnguyen, aivanov

! src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaLabelUI.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaLookAndFeel.java
! src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java
- src/java.desktop/macosx/classes/com/apple/laf/AquaMnemonicHandler.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKGraphicsUtils.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
+ src/java.desktop/share/classes/sun/swing/AltProcessor.java
+ src/java.desktop/share/classes/sun/swing/MnemonicHandler.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsGraphicsUtils.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLabelUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuBarUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsMenuItemUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsPopupMenuUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsRootPaneUI.java
! test/jdk/javax/swing/JMenuBar/TestMenuMnemonic.java
+ test/jdk/javax/swing/JMenuBar/TestMenuMnemonicLinuxAndMac.java
! test/jdk/javax/swing/LookAndFeel/bug4736093.java
! test/jdk/javax/swing/plaf/windows/6921687/bug6921687.java

Changeset: 34d8562a
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-12 12:59:13 +0000
URL:       https://git.openjdk.org/leyden/commit/34d8562a913b8382601e4c0c31ad34a663b9ec0a

8335902: Parallel: Refactor VM_ParallelGCFailedAllocation and VM_ParallelGCSystemGC

Reviewed-by: gli, zgu

! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.inline.hpp
! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.cpp
! src/hotspot/share/gc/parallel/psGCAdaptivePolicyCounters.hpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/parallel/psScavenge.cpp
! src/hotspot/share/gc/parallel/psScavenge.hpp
! src/hotspot/share/gc/parallel/psVMOperations.cpp
! src/hotspot/share/gc/parallel/psVMOperations.hpp
! src/hotspot/share/gc/shared/gcVMOperations.hpp
! src/hotspot/share/runtime/vmOperation.hpp
! src/jdk.internal.jvmstat/share/classes/sun/jvmstat/perfdata/resources/aliasmap
! test/jdk/jdk/jfr/event/runtime/TestVMOperation.java

Changeset: 4f312d6b
Branch: premain
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2024-07-12 12:59:22 +0000
URL:       https://git.openjdk.org/leyden/commit/4f312d6bc1fda6e3863ac623902a7decb0704ec3

8336152: Remove unused forward declaration in classLoadInfo.hpp

Reviewed-by: dholmes, shade

! src/hotspot/share/classfile/classLoadInfo.hpp

Changeset: 84c74ad0
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-12 14:36:34 +0000
URL:       https://git.openjdk.org/leyden/commit/84c74ad0a94f5c36529c63d846f15916259ee6a5

8335802: Improve startup speed HexFormat uses boolean instead of enum

Reviewed-by: liach

! src/java.base/share/classes/java/util/HexFormat.java

Changeset: 1f6e106b
Branch: premain
Author:    Kevin Walls <kevinw at openjdk.org>
Date:      2024-07-12 17:11:20 +0000
URL:       https://git.openjdk.org/leyden/commit/1f6e106b45e5109224e13d70f1a40c9e666ec2ab

8335684: Test ThreadCpuTime.java should pause like ThreadCpuTimeArray.java

Reviewed-by: sspitsyn, cjplummer

! test/jdk/java/lang/management/ThreadMXBean/ThreadCpuTime.java

Changeset: 4957145e
Branch: premain
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-12 21:49:28 +0000
URL:       https://git.openjdk.org/leyden/commit/4957145e6c823bfaa638a77457da5c031af978b9

8336278: Micro-optimize Replace String.format("%n") to System.lineSeparator

Reviewed-by: dnsimon, shade

! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/code/CodeUtil.java
! src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotMethodData.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/tool/StructuredWriter.java

Changeset: 8ba9bc6f
Branch: premain
Author:    Sean Gwizdak <sgwizdak at amazon.com>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-12 21:49:51 +0000
URL:       https://git.openjdk.org/leyden/commit/8ba9bc6f1735be98dcc039244a28884b4d9620ae

8332249: Micro-optimize Method.hashCode

Reviewed-by: liach

! src/java.base/share/classes/java/lang/reflect/Method.java
! test/micro/org/openjdk/bench/java/lang/reflect/MethodBenchmark.java

Changeset: 5bc86f33
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-12 21:50:51 +0000
URL:       https://git.openjdk.org/leyden/commit/5bc86f332986e3fffc1363f569029bb73a706064

8336259: Wrong link to stylesheet.css in JavaDoc API documentation

Reviewed-by: jjg, liach

! src/java.base/share/classes/java/lang/doc-files/ValueBased.html
! src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html

Changeset: 4166e534
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-07-12 23:11:04 +0000
URL:       https://git.openjdk.org/leyden/commit/4166e5345283d118d76b20de579d73bd55436ea6

8318106: Generated HTML for snippet does not always contain an id

Reviewed-by: liach

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java
! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownTaglets.java
! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestLangProperties.java
! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java
! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java
! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetUnnamedPackage.java

Changeset: ae9f318f
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-13 02:19:25 +0000
URL:       https://git.openjdk.org/leyden/commit/ae9f318fc35eeab497e546ebab9faed6ec774ec5

8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO file upon test completion

Reviewed-by: alanb

! test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java

Changeset: 6f325db4
Branch: premain
Author:    Brian Stafford <bstafford at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-13 04:59:04 +0000
URL:       https://git.openjdk.org/leyden/commit/6f325db49365d3d06add5d194d4696a1428675fa

8310915: Typo in aarch64.ad: "envcodings"

Reviewed-by: thartmann

! src/hotspot/cpu/aarch64/aarch64.ad

Changeset: a9f5e76a
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-14 15:01:51 +0000
URL:       https://git.openjdk.org/leyden/commit/a9f5e76a65f743be9cd995fbea9c78ff9cef3402

8335905: CompoundElement API cleanup

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/ClassFileBuilder.java
! src/java.base/share/classes/java/lang/classfile/ClassModel.java
! src/java.base/share/classes/java/lang/classfile/CodeModel.java
! src/java.base/share/classes/java/lang/classfile/CompoundElement.java
! src/java.base/share/classes/java/lang/classfile/FieldModel.java
! src/java.base/share/classes/java/lang/classfile/MethodModel.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractUnboundModel.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedCodeBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BufferedMethodBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/ClassRemapperImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/CodeImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/FieldImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/MethodImpl.java
! src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/EventInstrumentation.java
! src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java
! test/jdk/java/lang/instrument/asmlib/Instrumentor.java
! test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
! test/jdk/java/lang/invoke/lambda/LambdaAsm.java
! test/jdk/jdk/classfile/AdaptCodeTest.java
! test/jdk/jdk/classfile/BasicBlockTest.java
! test/jdk/jdk/classfile/ClassHierarchyInfoTest.java
! test/jdk/jdk/classfile/CorpusTest.java
! test/jdk/jdk/classfile/LvtTest.java
! test/jdk/jdk/classfile/OptionsTest.java
! test/jdk/jdk/classfile/StackMapsTest.java
! test/jdk/jdk/classfile/TestRecordComponent.java
! test/jdk/jdk/classfile/VerifierSelfTest.java
! test/jdk/jdk/classfile/helpers/RebuildingTransformation.java
! test/jdk/jdk/classfile/helpers/Transforms.java
! test/jdk/jdk/jfr/event/compiler/TestCompilerInlining.java
! test/micro/org/openjdk/bench/jdk/classfile/ReadDeep.java
! test/micro/org/openjdk/bench/jdk/classfile/Transforms.java

Changeset: 3f2636d9
Branch: premain
Author:    Adam Sotona <asotona at openjdk.org>
Date:      2024-07-15 05:41:52 +0000
URL:       https://git.openjdk.org/leyden/commit/3f2636d9b71f5270c83d17dcf5d18cf907978475

8335820: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java fails due to IllegalArgumentException: hash must be nonzero

Reviewed-by: liach

! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BootstrapMethodEntryImpl.java
! src/java.base/share/classes/jdk/internal/classfile/impl/BoundAttribute.java
! test/jdk/jdk/classfile/LimitsTest.java

Changeset: a96de6d8
Branch: premain
Author:    Richard Reingruber <rrich at openjdk.org>
Date:      2024-07-15 07:34:10 +0000
URL:       https://git.openjdk.org/leyden/commit/a96de6d8d273d75a6500e10ed06faab9955f893b

8336256: memcpy short value to int local is incorrect in VtableStubs::unsafe_hash

Reviewed-by: stuefe, shade, kvn

! src/hotspot/share/code/vtableStubs.cpp

Changeset: 2b0adfc2
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-07-15 11:26:33 +0000
URL:       https://git.openjdk.org/leyden/commit/2b0adfc2decf47f6f49f072549c96f301f275285

8335817: javac AssertionError addLocalVar checkNull

Reviewed-by: vromero, mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java
+ test/langtools/tools/javac/patterns/MatchExceptionLambdaExpression.java

Changeset: a253e0ff
Branch: premain
Author:    Chen Liang <liach at openjdk.org>
Date:      2024-07-15 12:11:53 +0000
URL:       https://git.openjdk.org/leyden/commit/a253e0ff4b88541d01596b0e73ede4b96a258fca

8335642: Hide Transform implementation for Class-File API

Reviewed-by: asotona

! src/java.base/share/classes/java/lang/classfile/ClassFileBuilder.java
! src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
! src/java.base/share/classes/java/lang/classfile/ClassTransform.java
! src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
! src/java.base/share/classes/java/lang/classfile/CodeTransform.java
! src/java.base/share/classes/java/lang/classfile/FieldTransform.java
! src/java.base/share/classes/java/lang/classfile/MethodTransform.java
! src/java.base/share/classes/jdk/internal/classfile/impl/AbstractDirectBuilder.java
! src/java.base/share/classes/jdk/internal/classfile/impl/TransformImpl.java

Changeset: 46355319
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-07-15 14:24:27 +0000
URL:       https://git.openjdk.org/leyden/commit/4635531950dbcfcd3ee2f13a57f0909af78a94c7

8335159: Move method reference to lambda desugaring before Lower
8336320: NullPointerException: Cannot invoke Type.getTag because type is null after JDK-8334037

Reviewed-by: jlahoda, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransTypes.java
+ test/langtools/tools/javac/SuperInit/MrefDoubleTrans.java

Changeset: 000de306
Branch: premain
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2024-07-15 14:54:04 +0000
URL:       https://git.openjdk.org/leyden/commit/000de306286bb75bbdad2f572ce6dafd4184680e

8335269: [Graal] occasional timeout in java/lang/StringBuffer/TestSynchronization.java with loom

Reviewed-by: dholmes, alanb

! src/hotspot/share/runtime/continuationFreezeThaw.cpp
+ test/jdk/java/lang/Thread/virtual/ThreadPollOnYield.java

Changeset: 9dfcd75e
Branch: premain
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2024-07-15 15:28:24 +0000
URL:       https://git.openjdk.org/leyden/commit/9dfcd75ec4f6c1fb60e5416fa6fc759c969a24fb

8334121: Anonymous class capturing two enclosing instances fails to compile

Reviewed-by: jlahoda, vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
! test/langtools/tools/javac/MethodParameters/LocalClassTest.out
+ test/langtools/tools/javac/SuperInit/MultiLevelOuterInstance.java

Changeset: ab27acab
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-15 15:43:02 +0000
URL:       https://git.openjdk.org/leyden/commit/ab27acab0b0f4a8af080275e92c2f296f5f6486b

8336297: C2: Fix -Wzero-as-null-pointer-constant warnings in derived Node ctors

Reviewed-by: kvn, jwaters

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse2.cpp

Changeset: 388fcf03
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-15 16:00:00 +0000
URL:       https://git.openjdk.org/leyden/commit/388fcf03c02c41bb690733e8565642c24ead56e0

8336349: Fix more simple -Wzero-as-null-pointer-constant warnings in C2 code

Reviewed-by: kvn, shade

! src/hotspot/share/opto/buildOopMap.cpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/chaitin.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/domgraph.cpp
! src/hotspot/share/opto/idealKit.cpp
! src/hotspot/share/opto/ifg.cpp
! src/hotspot/share/opto/live.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/reg_split.cpp
! src/hotspot/share/opto/regalloc.cpp
! src/hotspot/share/opto/type.cpp

Changeset: c8a95a76
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-15 20:26:52 +0000
URL:       https://git.openjdk.org/leyden/commit/c8a95a763c169b94c5ba07d2c6fbdf99ba3b9e3b

8072701: resume001 failed due to ERROR: timeout for waiting for a BreakpintEvent

Reviewed-by: amenkov, kevinw, sspitsyn

! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001.java
! test/hotspot/jtreg/vmTestbase/nsk/jdi/ThreadReference/resume/resume001a.java
! test/hotspot/jtreg/vmTestbase/nsk/share/jdi/Debugee.java

Changeset: bc7cd42d
Branch: premain
Author:    Alexey Ushakov <avu at openjdk.org>
Date:      2024-07-15 23:25:11 +0000
URL:       https://git.openjdk.org/leyden/commit/bc7cd42d11943003470ed4c93a25db3a8f9b5d21

8314498: [macos] Transferring File objects to Finder fails

Co-authored-by: Andrey Starovoyt <Andrey.Starovoyt at jetbrains.com>
Reviewed-by: prr

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CClipboard.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m

Changeset: 8feabc84
Branch: premain
Author:    SendaoYan <syan at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-16 01:43:36 +0000
URL:       https://git.openjdk.org/leyden/commit/8feabc849ba2f617c8c6dbb2ec5074297beb6437

8334057: JLinkReproducibleTest.java support receive test.tool.vm.opts

Reviewed-by: jpai

! test/jdk/tools/jlink/JLinkReproducibleTest.java

Changeset: 419cc462
Branch: premain
Author:    Christoph Langer <clanger at openjdk.org>
Date:      2024-07-16 12:48:06 +0000
URL:       https://git.openjdk.org/leyden/commit/419cc4624891e5775847f8acaf92fa8c42a9719c

8335533: OutOfMemoryError: Metaspace observed again on AIX in test RedefineLeakThrowable.java after JDK-8294960

Reviewed-by: mbaesken, stuefe

! test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java

Changeset: c99be357
Branch: premain
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-16 15:23:55 +0000
URL:       https://git.openjdk.org/leyden/commit/c99be357c9ff3b4f7edd8673beefeab54aa4ee90

8336474: Problemlist compiler/interpreter/Test6833129 on x86_32

Reviewed-by: thartmann, stuefe

! test/hotspot/jtreg/ProblemList.txt

Changeset: 88eff4c3
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-07-16 16:11:00 +0000
URL:       https://git.openjdk.org/leyden/commit/88eff4c3054b7d9d6486ff418bbecca8f0388117

8336421: ciMethod() constructor should use ConditionalMutexLocker(Compile_lock)

Reviewed-by: jwaters, thartmann, shade

! src/hotspot/share/ci/ciMethod.cpp

Changeset: 59bf3d77
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-16 17:53:08 +0000
URL:       https://git.openjdk.org/leyden/commit/59bf3d77aa96dfdc199f5a6893c76c8a379e9fba

8336080: Fix -Wzero-as-null-pointer-constant warnings in ClassLoaderStats ctor

Reviewed-by: dholmes, iwalulya

! src/hotspot/share/classfile/classLoaderStats.hpp

Changeset: a60608e7
Branch: premain
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2024-07-16 18:10:47 +0000
URL:       https://git.openjdk.org/leyden/commit/a60608e7a35aeeed57bcce641d4957de1e4b4def

8334169: Long arguments of attach operation are silently truncated on Windows

Reviewed-by: sspitsyn, cjplummer

! src/jdk.attach/windows/native/libattach/VirtualMachineImpl.c
+ test/hotspot/jtreg/serviceability/attach/LongArgTest.java

Changeset: 005fb67e
Branch: premain
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-07-16 20:47:42 +0000
URL:       https://git.openjdk.org/leyden/commit/005fb67e99370ef2bd15dae621a3924e1cf00124

8331194: NPE in ArrayCreationTree.java with -XX:-UseCompressedOops

Reviewed-by: kvn

! src/hotspot/share/opto/machnode.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/output.hpp
+ test/hotspot/jtreg/compiler/escapeAnalysis/TestReduceAllocationAndNestedScalarized.java

Changeset: f3e7063e
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-16 23:27:32 +0000
URL:       https://git.openjdk.org/leyden/commit/f3e7063e26cefb6643e4150b7fcbdc9a1fdaebed

8336420: Add JVMTI setfldw001 and setfmodw001 tests to Xcomp problem list

Reviewed-by: dcubed

! test/hotspot/jtreg/ProblemList-Xcomp.txt

Changeset: 69baa7d2
Branch: premain
Author:    Harshitha Onkar <honkar at openjdk.org>
Date:      2024-07-16 23:46:41 +0000
URL:       https://git.openjdk.org/leyden/commit/69baa7d2850fafbd89978db12eec683c286eb921

8336413: gtk headers : Fix typedef redeclaration of GMainContext and GdkPixbuf

Reviewed-by: prr, dnguyen

! src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.h
! src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.h

Changeset: 5f365d44
Branch: premain
Author:    Tobias Hartmann <thartmann at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-01-23 08:25:53 +0000
URL:       https://git.openjdk.org/leyden/commit/5f365d44be9c1f3413c9ccde970e2745090a516a

8323231: Improve array management

Co-authored-by: Martin Balao <mbalao at openjdk.org>
Reviewed-by: iveresov, rhalade, mschoene, dlong, kvn

! src/hotspot/share/c1/c1_RangeCheckElimination.cpp

Changeset: 46c37686
Branch: premain
Author:    Emanuel Peter <epeter at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-01-25 14:47:13 +0000
URL:       https://git.openjdk.org/leyden/commit/46c37686454321011541499a79c776f774ff2b57

8320548: Improved loop handling

Reviewed-by: mschoene, rhalade, thartmann, chagedorn

! src/hotspot/share/opto/superword.cpp

Changeset: 227fc5e5
Branch: premain
Author:    Matias Saavedra Silva <matsaave at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-01-29 21:40:21 +0000
URL:       https://git.openjdk.org/leyden/commit/227fc5e591da0ea7540a7f25451240401ead3495

8314794: Improve UTF8 String supports

Reviewed-by: dholmes, coleenp, rhalade

! src/hotspot/share/utilities/exceptions.cpp
! src/hotspot/share/utilities/utf8.cpp

Changeset: aea9a08b
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-02-11 21:54:51 +0000
URL:       https://git.openjdk.org/leyden/commit/aea9a08bebb6555ef6f00daba24afec394dd245b

8319859: Better symbol storage

Reviewed-by: rhalade, coleenp, matsaave, iklam

! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/oops/symbol.cpp
! src/hotspot/share/oops/symbol.hpp

Changeset: c5a8c8a0
Branch: premain
Author:    David Holmes <dholmes at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-02-13 21:15:08 +0000
URL:       https://git.openjdk.org/leyden/commit/c5a8c8a0b6d51c33679efb02514f7a44e93ad290

8325600: Better symbol storage

Reviewed-by: coleenp, rhalade, matsaave

! src/hotspot/share/classfile/symbolTable.cpp

Changeset: e6363255
Branch: premain
Author:    Jayathirth D V <jdv at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-03-15 10:28:00 +0000
URL:       https://git.openjdk.org/leyden/commit/e636325510e882afa703752c6d37c183d111565c

8324559: Improve 2D image handling

Reviewed-by: rhalade, mschoene, psadhukhan, prr

! src/java.desktop/share/native/libawt/java2d/loops/MaskFill.c

Changeset: 553f21ae
Branch: premain
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-03-26 11:43:35 +0000
URL:       https://git.openjdk.org/leyden/commit/553f21ae5324029eef3c934d69be40f5d4266457

8327413: Enhance compilation efficiency

Co-authored-by: Roland Westrelin <roland at openjdk.org>
Reviewed-by: ahgross, rhalade, thartmann, epeter, mbalao, fferrari

! src/hotspot/share/opto/ifnode.cpp

Changeset: 8cc84bf7
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-03-29 17:40:00 +0000
URL:       https://git.openjdk.org/leyden/commit/8cc84bf71e42bb72755a9f2d8532cbdbd428c2a5

8320097: Improve Image transformations

Reviewed-by: jdv, psadhukhan, aivanov, rhalade

! src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java
! src/java.desktop/share/native/libawt/java2d/loops/TransformHelper.c

Changeset: 13341ca7
Branch: premain
Author:    Jayathirth D V <jdv at openjdk.org>
Committer: Jaikiran Pai <jaikiran.pai at oracle.com>
Date:      2024-04-02 06:02:01 +0000
URL:       https://git.openjdk.org/leyden/commit/13341ca70276c891add2e4652b6e1e8020610988

8323390: Enhance mask blit functionality

Reviewed-by: prr, rhalade, psadhukhan

! src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java
! src/java.desktop/share/native/libawt/java2d/SurfaceData.h
! src/java.desktop/share/native/libawt/java2d/loops/MaskBlit.c

Changeset: d90c20c0
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-17 06:05:51 +0000
URL:       https://git.openjdk.org/leyden/commit/d90c20c0c728ced94493e0e58956153f6f61f898

Merge

Reviewed-by: djelinski, dholmes


Changeset: 3babffd4
Branch: premain
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-17 06:12:01 +0000
URL:       https://git.openjdk.org/leyden/commit/3babffd4002be62f9f75a1a773c9561804612fad

8334167: Test java/lang/instrument/NativeMethodPrefixApp.java timed out

Reviewed-by: dholmes, sspitsyn, alanb

! test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
! test/jdk/java/lang/instrument/NativeMethodPrefixApp.java
+ test/jdk/java/lang/instrument/libNativeMethodPrefix.c

Changeset: b9b0b850
Branch: premain
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2024-07-17 06:46:34 +0000
URL:       https://git.openjdk.org/leyden/commit/b9b0b8504ec989ad0687188de4bccfe2c04e5d64

8336375: Crash on paste to JShell

Reviewed-by: jvernee

! src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/ffm/Kernel32.java

Changeset: 70f3e990
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-17 09:25:59 +0000
URL:       https://git.openjdk.org/leyden/commit/70f3e99016311a6520e6a7c0da4c7ff718364976

8336463: Parallel: Add PSOldGen::expand_and_allocate

Reviewed-by: iwalulya, zgu

! src/hotspot/share/gc/parallel/mutableSpace.cpp
! src/hotspot/share/gc/parallel/mutableSpace.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/psOldGen.cpp
! src/hotspot/share/gc/parallel/psOldGen.hpp

Changeset: 59843f4a
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
Date:      2024-07-17 09:42:04 +0000
URL:       https://git.openjdk.org/leyden/commit/59843f4a65c18b9a9cc32d4146e569b0e8c89baf

8336040: Missing closing anchor element in Docs.gmk

Reviewed-by: dholmes, jpai, shade

! make/Docs.gmk

Changeset: d41d2a7a
Branch: premain
Author:    Vladimir Petko <vpetko at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2024-07-17 09:43:47 +0000
URL:       https://git.openjdk.org/leyden/commit/d41d2a7a82cb6eff17396717e2e14139ad8179ba

8334502: gtest/GTestWrapper.java fails on armhf due to LogDecorations.iso8601_utctime_test

Reviewed-by: dholmes, shade

! src/hotspot/share/runtime/os.cpp

Changeset: 67979eb0
Branch: premain
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2024-07-17 11:17:10 +0000
URL:       https://git.openjdk.org/leyden/commit/67979eb0771ff834d6d3d18ba5a8bfe161cfc2ce

8334781: JFR crash:  assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSet.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp
! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp
! src/hotspot/share/jfr/support/jfrTraceIdExtension.hpp
! src/hotspot/share/prims/jvmtiRedefineClasses.cpp

Changeset: 87136287
Branch: premain
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Matthias Baesken <mbaesken at openjdk.org>
Date:      2024-07-17 11:24:08 +0000
URL:       https://git.openjdk.org/leyden/commit/871362870ea8dc5f4ac186876e91023116891a5b

8334217: [AIX] Misleading error messages after JDK-8320005

Reviewed-by: jkern, mbaesken

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/aix/porting_aix.cpp
! src/hotspot/os/aix/porting_aix.hpp

Changeset: 6df7acbc
Branch: premain
Author:    Pavel Rappo <prappo at openjdk.org>
Date:      2024-07-17 12:20:17 +0000
URL:       https://git.openjdk.org/leyden/commit/6df7acbc74922d297852044596045a8b32636423

8299080: Wrong default value of snippet lang attribute

Reviewed-by: jjg

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/SnippetTaglet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/taglets/snippet/Parser.java
! test/langtools/jdk/javadoc/doclet/testMarkdown/TestMarkdownTaglets.java
! test/langtools/jdk/javadoc/doclet/testSnippetTag/SnippetTester.java
! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetMarkup.java
! test/langtools/jdk/javadoc/doclet/testSnippetTag/TestSnippetTag.java

Changeset: 7ec55df3
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-17 14:49:00 +0000
URL:       https://git.openjdk.org/leyden/commit/7ec55df34af98e9a80381dba7f7f2127f2248f73

8336638: Parallel: Remove redundant mangle in PSScavenge::invoke

Reviewed-by: zgu

! src/hotspot/share/gc/parallel/psScavenge.cpp

Changeset: 10186ff4
Branch: premain
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2024-07-17 16:25:36 +0000
URL:       https://git.openjdk.org/leyden/commit/10186ff48fe67aeb83c028b47f6b7e5105513cf3

8336300: DateFormatSymbols#getInstanceRef returns non-cached instance

Reviewed-by: joehw, iris, jlu, aturbanov

! src/java.base/share/classes/java/text/DateFormatSymbols.java
! src/java.base/share/classes/java/text/SimpleDateFormat.java

Changeset: bcb5e695
Branch: premain
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2024-07-17 18:46:00 +0000
URL:       https://git.openjdk.org/leyden/commit/bcb5e69505f6cc8a4f323924cd2c58e630595fc0

8335921: Fix HotSpot VM build without JVMTI

Reviewed-by: dholmes, shade

! make/hotspot/lib/JvmFeatures.gmk
! src/hotspot/share/jfr/instrumentation/jfrJvmtiAgent.hpp
! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
! src/hotspot/share/jfr/recorder/jfrRecorder.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! test/jdk/jdk/jfr/event/runtime/TestAgentEvent.java

Changeset: 78cc0f95
Branch: premain
Author:    Nizar Benalla <nbenalla at openjdk.org>
Committer: Chen Liang <liach at openjdk.org>
Date:      2024-07-17 21:39:19 +0000
URL:       https://git.openjdk.org/leyden/commit/78cc0f9569535c72900cf4617e22cef99f695e61

8336091: Fix HTML warnings in the generated HTML files

Reviewed-by: dholmes

! make/jdk/src/classes/build/tools/fixuppandoc/Main.java

Changeset: 21a6cf84
Branch: premain
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2024-07-18 00:21:03 +0000
URL:       https://git.openjdk.org/leyden/commit/21a6cf848da00c795d833f926f831c7aea05dfa3

8336587: failure_handler lldb command times out on macosx-aarch64 core file

Reviewed-by: dlong, dholmes, jpai

! test/failure_handler/src/share/conf/mac.properties

Changeset: 72297d22
Branch: premain
Author:    Arseny Bochkarev <arseny.bochkarev at syntacore.com>
Committer: Vladimir Kempik <vkempik at openjdk.org>
Date:      2024-07-18 08:55:07 +0000
URL:       https://git.openjdk.org/leyden/commit/72297d22d19e34ff26bd34644dc087a1dec9527e

8317720: RISC-V: Implement Adler32 intrinsic

Reviewed-by: fyang

! src/hotspot/cpu/riscv/assembler_riscv.hpp
! src/hotspot/cpu/riscv/stubGenerator_riscv.cpp
! src/hotspot/cpu/riscv/vm_version_riscv.cpp

Changeset: 1b83bd92
Branch: premain
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Date:      2024-07-18 10:08:13 +0000
URL:       https://git.openjdk.org/leyden/commit/1b83bd9225fe9ada4c3770d5cd41242f82fe144f

8336661: Parallel: Remove stacks_empty assert in PSScavenge::invoke

Reviewed-by: sangheki

! src/hotspot/share/gc/parallel/psScavenge.cpp

Changeset: 7bf53132
Branch: premain
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2024-07-18 11:00:39 +0000
URL:       https://git.openjdk.org/leyden/commit/7bf531324404419e7de3e83e245d351e1a4e4499

8335480: Only deoptimize threads if needed when closing shared arena

Reviewed-by: mcimadamore, kvn, uschindler, vlivanov, eosterlund

! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/c1/c1_Compilation.hpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/prims/scopedMemoryAccess.cpp
! src/hotspot/share/runtime/vframe.cpp
! src/hotspot/share/runtime/vframe.hpp
+ test/jdk/java/foreign/TestConcurrentClose.java
! test/jdk/java/foreign/TestHandshake.java
+ test/micro/org/openjdk/bench/java/lang/foreign/ConcurrentClose.java

Changeset: 35df48e1
Branch: premain
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2024-07-18 11:22:58 +0000
URL:       https://git.openjdk.org/leyden/commit/35df48e1b321d16f44ba924065143af67143cf95

8335860: compiler/vectorization/TestFloat16VectorConvChain.java fails with non-standard AVX/SSE settings

Reviewed-by: sviswanathan, kvn

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java

Changeset: 4a73ed44
Branch: premain
Author:    Robert Toyonaga <rtoyonag at redhat.com>
Committer: Thomas Stuefe <stuefe at openjdk.org>
Date:      2024-07-18 13:35:32 +0000
URL:       https://git.openjdk.org/leyden/commit/4a73ed44f1af4ea3e53b1e1a6acfca1ba6b636c3

8330144: Revise os::free_memory()

Reviewed-by: stuefe, mbaesken

! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/mutableSpace.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp
! test/hotspot/gtest/runtime/test_os.cpp

Changeset: 5f7b0072
Branch: premain
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2024-07-18 15:24:51 +0000
URL:       https://git.openjdk.org/leyden/commit/5f7b0072cfe7434b43dea53b2a8d55c56c6668ea

8336346: Fix -Wzero-as-null-pointer-constant warnings in jvmciJavaClasses.cpp

Reviewed-by: jwaters, thartmann

! src/hotspot/share/jvmci/jvmciJavaClasses.cpp

Changeset: 245c0866
Branch: premain
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2024-07-18 15:54:41 +0000
URL:       https://git.openjdk.org/leyden/commit/245c08664896d63ac050ebc23259b23908dafed5

8332600: javac uses record components source position during compilation

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! test/langtools/tools/javac/records/RecordCompilationTests.java

Changeset: bbc79a5e
Branch: premain
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2024-07-18 16:33:48 +0000
URL:       https://git.openjdk.org/leyden/commit/bbc79a5e0144cb5ee6051e078681f9c6821441cb

8333768: Minor doc updates to java.lang.{Float, Double}

Reviewed-by: rgiulietti

! src/java.base/share/classes/java/lang/Double.java
! src/java.base/share/classes/java/lang/Float.java
! src/java.base/share/classes/java/lang/Math.java
! src/java.base/share/classes/java/lang/StrictMath.java

Changeset: 02be7b8d
Branch: premain
Author:    Phil Race <prr at openjdk.org>
Date:      2024-07-18 17:35:06 +0000
URL:       https://git.openjdk.org/leyden/commit/02be7b8ddcdb62977770cb5052e86bcada8478ba

8334495: Use FFM instead of jdk.internal.misc.Unsafe in java.desktop font implementation

Reviewed-by: jdv, dnguyen, achung

! src/java.desktop/share/classes/sun/font/FileFontStrike.java
! src/java.desktop/share/classes/sun/font/GlyphList.java
! src/java.desktop/share/classes/sun/font/StrikeCache.java
! src/java.desktop/share/native/libfontmanager/sunFont.c
! src/java.desktop/unix/classes/sun/font/XRGlyphCacheEntry.java

Changeset: 35a48278
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-18 17:06:47 +0000
URL:       https://git.openjdk.org/leyden/commit/35a4827802c7432d8370b5b3411cc53fac131e1c

Merge branch 'master' of https://github.com/openjdk/leyden into premain

! make/InitSupport.gmk
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/cdsEnumKlass.cpp
! src/hotspot/share/cds/cdsEnumKlass.hpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/compactHashtable.hpp
! src/hotspot/share/classfile/symbolTable.cpp
! src/hotspot/share/code/SCCache.cpp
! src/hotspot/share/code/SCCache.hpp
! src/hotspot/share/code/exceptionHandlerTable.hpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp
! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/methodData.hpp
! src/hotspot/share/oops/symbol.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/utilities/ostream.cpp
! test/hotspot/jtreg/ProblemList.txt
! make/InitSupport.gmk
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp
! src/hotspot/cpu/aarch64/relocInfo_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/cds/archiveBuilder.cpp
! src/hotspot/share/cds/cdsEnumKlass.cpp
! src/hotspot/share/cds/cdsEnumKlass.hpp
! src/hotspot/share/cds/filemap.hpp
! src/hotspot/share/cds/heapShared.hpp
! src/hotspot/share/cds/metaspaceShared.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/compactHashtable.hpp
! src/hotspot/share/classfile/symbolTable.cpp
+ src/hotspot/share/code/SCCache.cpp
+ src/hotspot/share/code/SCCache.hpp
! src/hotspot/share/code/exceptionHandlerTable.hpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/code/nmethod.hpp
! src/hotspot/share/code/relocInfo.cpp
! src/hotspot/share/code/relocInfo.hpp
! src/hotspot/share/gc/shared/barrierSetNMethod.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/memory/virtualspace.cpp
! src/hotspot/share/oops/klass.hpp
! src/hotspot/share/oops/methodData.hpp
! src/hotspot/share/oops/symbol.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/parse1.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/utilities/ostream.cpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: a03a63e3
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-18 17:06:50 +0000
URL:       https://git.openjdk.org/leyden/commit/a03a63e3b8feafe1614b7f8a5fd0cdac6305fa6f

Merge branch 'premain' of https://github.com/openjdk/leyden into premain

! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/opto/graphKit.cpp


From duke at openjdk.org  Fri Jul 19 20:34:00 2024
From: duke at openjdk.org (duke)
Date: Fri, 19 Jul 2024 20:34:00 GMT
Subject: git: openjdk/leyden: hermetic-java-runtime: Change
 TrustAnchorManager.loadKeyStore() to check `descriptor.storeFile` instead of
 `descriptor.lastModified` in non-hermetic case.
Message-ID: <125c1b27-2ea9-4fbd-b4d3-d081558f80e6@openjdk.org>

Changeset: bad068cd
Branch: hermetic-java-runtime
Author:    Jiangli Zhou <jianglizhou at google.com>
Date:      2024-07-19 13:30:49 +0000
URL:       https://git.openjdk.org/leyden/commit/bad068cd5bd6da024b8a370a2d7c27f29351aa9b

Change TrustAnchorManager.loadKeyStore() to check `descriptor.storeFile` instead of `descriptor.lastModified` in non-hermetic case.

The JDK cacerts file built into a docker image may has mtime set to 0.

Reviewed by Chuck Rasbold

! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java


From duke at openjdk.org  Mon Jul 22 18:08:01 2024
From: duke at openjdk.org (duke)
Date: Mon, 22 Jul 2024 18:08:01 GMT
Subject: git: openjdk/leyden: premain: Change TD has table to have keys with
 direct references
Message-ID: <7b7d3fca-c021-4426-bf81-9d107b8ea6e4@openjdk.org>

Changeset: 8423515c
Branch: premain
Author:    Igor Veresov <igor.veresov at oracle.com>
Date:      2024-07-17 14:31:44 +0000
URL:       https://git.openjdk.org/leyden/commit/8423515cba9ff9ccc10d7dae94e1f6559fa391b1

Change TD has table to have keys with direct references

! src/hotspot/share/oops/trainingData.cpp
! src/hotspot/share/oops/trainingData.hpp


From duke at openjdk.org  Tue Jul 23 08:01:12 2024
From: duke at openjdk.org (duke)
Date: Tue, 23 Jul 2024 08:01:12 GMT
Subject: git: openjdk/leyden: premain: Clean up cdsEnumKlass.cpp code for
 upstreaming to mainline
Message-ID: <267f47f4-1cc1-4e5b-905f-5edbed3b03ca@openjdk.org>

Changeset: ec5eb996
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-23 00:04:29 +0000
URL:       https://git.openjdk.org/leyden/commit/ec5eb99653624d02a923a314ce40086753b240fc

Clean up cdsEnumKlass.cpp code for upstreaming to mainline

! src/hotspot/share/cds/cdsEnumKlass.cpp
! src/hotspot/share/cds/cdsEnumKlass.hpp
! src/hotspot/share/cds/heapShared.cpp
! test/hotspot/jtreg/runtime/cds/appcds/cacheObject/ArchiveHeapTestClass.java


From adinn at redhat.com  Tue Jul 23 16:12:56 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Tue, 23 Jul 2024 17:12:56 +0100
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
Message-ID: <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>

Hi Vladimir,

On 18/07/2024 17:15, Vladimir Kozlov wrote:
> What about allocating word in CodeCache as we do for some intrinsics 
> stubs tables? You will need to generate it only once and can use 
> runtime_type relocation to access it.

I am looking into that now. I've been working on something else  that 
might interest you ...

> It is all about loading with existing relocation vs specialized 
> relocation for immediate value (Option three).
> I would like to see how complex option three is.
I have an implementation of option 3 in my JDK-8335440-aot-reloc branch. 
m.b. it is based on a slightly out of date premain but the 
implementation indicates what is involved even without a rebase (I'll do 
that soon):

 
https://github.com/openjdk/leyden/compare/premain...adinn:leyden:JDK-8335440-aot-reloc?expand=1

Basically this solution emits an aot_reloc for the GC barrier left shift 
immediate instruction when we are generating AOT code (StoreCachedCode 
== true). When loading AOT code (LoadCachedCode == true) any left shift 
immediate tagged with an aot_reloc has its operand patched with the log 
region grain size from the current JVM. I use a format field to identify 
what reloc is required so the same model will support other AOT Load 
time relocs if need be.

The implementation makes it fairly obvious that we could use the same 
technique of tagging with an aot_reloc at StoreCachedCode time and 
patching at LoadCachedCode time for any other instruction (or 
indivisible instruction sequence) which 1) encodes some runtime constant 
from the original JVM and 2) is able to be reset by patching it to use 
the value in the new JVM.

It is worth noting that for both C1 and C2 generated code I had to set a 
tag on the LIR node (c1_LIROp in C1, URShiftNode in C2) in order to mark 
it as a relocatable instruction. Later on, in the generation phase, I 
detect the mark and emit a reloc to the code buffer. This works because 
none of the LIR transforms modify the left shift node by merging it into 
some other operation or by merging another operation into it (I checked 
but this is a contingent fact based on the current state of the code).

Clearly, in the case of barrier patching we could finesse the above 
problem by generating the GC barrier late enough to bypass graph 
normalization and back end reductions. However, if we want to use a 
similar technique to AOT patch other instructions or sequences then we 
will need a more reliable way of ensuring that the relocatable 
instructions are not replaced or merged during normalization/final 
reduction.

regards,


Andrew Dinn
-----------


From vladimir.kozlov at oracle.com  Tue Jul 23 17:44:57 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 23 Jul 2024 10:44:57 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
Message-ID: <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>

 > The implementation makes it fairly obvious that we could use the same technique of tagging with an aot_reloc at
 > StoreCachedCode time and patching at LoadCachedCode time for any other instruction (or indivisible instruction sequence)
 > which 1) encodes some runtime constant from the original JVM and 2) is able to be reset by patching it to use the value
 > in the new JVM.

I agree. As we discussed on meeting we may use it to patch compressed oops/klass code too.

We have the same issue with card_table_address. I actually don't know why current AOT code works??? May be because it is 
the same value in training and production runs. But we need to fix it too.

It is constant node which is embedded into AddP node:
https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp#L96

I marked it only in platform specific code:
https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp#L68


Be careful with using `format()` in shared code because it depends on platform specific setting `format_width` in 
`relocInfo_<arch>.hpp` (32-bit arm has format_width = 0).

Thanks,
Vladimir K

On 7/23/24 9:12 AM, Andrew Dinn wrote:
> Hi Vladimir,
> 
> On 18/07/2024 17:15, Vladimir Kozlov wrote:
>> What about allocating word in CodeCache as we do for some intrinsics stubs tables? You will need to generate it only 
>> once and can use runtime_type relocation to access it.
> 
> I am looking into that now. I've been working on something else? that might interest you ...
> 
>> It is all about loading with existing relocation vs specialized relocation for immediate value (Option three).
>> I would like to see how complex option three is.
> I have an implementation of option 3 in my JDK-8335440-aot-reloc branch. m.b. it is based on a slightly out of date 
> premain but the implementation indicates what is involved even without a rebase (I'll do that soon):
> 
> 
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/compare/premain...adinn:leyden:JDK-8335440-aot-reloc?expand=1__;!!ACWV5N9M2RV99hQ!OUrEzWWlhEAqFsyLSPxuvh29GQ2eSz44-5Y2PpWI6ttTbJRcG6HWGLGXyVXUioqXgSChwiwlU2TcdtCAlzM$
> Basically this solution emits an aot_reloc for the GC barrier left shift immediate instruction when we are generating 
> AOT code (StoreCachedCode == true). When loading AOT code (LoadCachedCode == true) any left shift immediate tagged with 
> an aot_reloc has its operand patched with the log region grain size from the current JVM. I use a format field to 
> identify what reloc is required so the same model will support other AOT Load time relocs if need be.
> 
> The implementation makes it fairly obvious that we could use the same technique of tagging with an aot_reloc at 
> StoreCachedCode time and patching at LoadCachedCode time for any other instruction (or indivisible instruction sequence) 
> which 1) encodes some runtime constant from the original JVM and 2) is able to be reset by patching it to use the value 
> in the new JVM.
> 
> It is worth noting that for both C1 and C2 generated code I had to set a tag on the LIR node (c1_LIROp in C1, 
> URShiftNode in C2) in order to mark it as a relocatable instruction. Later on, in the generation phase, I detect the 
> mark and emit a reloc to the code buffer. This works because none of the LIR transforms modify the left shift node by 
> merging it into some other operation or by merging another operation into it (I checked but this is a contingent fact 
> based on the current state of the code).
> 
> Clearly, in the case of barrier patching we could finesse the above problem by generating the GC barrier late enough to 
> bypass graph normalization and back end reductions. However, if we want to use a similar technique to AOT patch other 
> instructions or sequences then we will need a more reliable way of ensuring that the relocatable instructions are not 
> replaced or merged during normalization/final reduction.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From adinn at redhat.com  Wed Jul 24 14:40:38 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 24 Jul 2024 15:40:38 +0100
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
Message-ID: <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>

On 23/07/2024 18:44, Vladimir Kozlov wrote:
> I agree. As we discussed on meeting we may use it to patch compressed 
> oops/klass code too.

Yes, we could potentially do something similar to adjust the shift and 
base adjustment employed when generating a narrow oop or klass encode or 
decode. However, that would only be useful with certain limits.

1) We can only cater for a change from one narrow-oop/klass base+shift 
configuration to another base+shift configuration. Patching code to 
switch from narrow oops/klass pointers to full width (or vice versa) 
would require adjusting not just the oop/klass load/store but also other 
instructions that hard-wire header/payload field sizes and offsets based 
on the narrow/full width layout assumptions. Likewise it would require 
resizing and repacking objects stored in the CDS mapped heap section.

2) Even if we restrict ourselves to the case where we retain narrow oops 
and simply allow for a change of base and/or shift (i.e. keep the object 
layouts the same), that will only work if pointers installed in mapped 
CDS heap objects are also rewritten to use the runtime encoding.

3) When generating AOT code for the encode and decode we would have to 
allow for the worst case i.e. leave room (nops) for both heap-base 
adjustment and shift even when they are not needed at generate time.

> We have the same issue with card_table_address. I actually don't know 
> why current AOT code works??? May be because it is the same value in 
> training and production runs. But we need to fix it too.

> It is constant node which is embedded into AddP node:
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp#L96

I believe C2 is ok. On AArch64 the C2 back end has an operand called 
immByteMapBase that matches any use of byte_map_base as a pointer 
constant. A corresponding rule ensures that any attempt to load that 
constant pointer is done by calling

   __ load_byte_map_base()

and the macr assembler uses an ExternalAddress when StoreCachedCode is set.

> I marked it only in platform specific code:
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp#L68

I also think there is no mystery as to why this works on AArch64. The 
equivalent code in cardTableBarrierSetAssembler_aarch64.cpp also calls

   __ load_byte_map_base()

However, that said, looking at the barrier card table write it seems the 
card table shift is another value that the user might decide to 
reconfigure between assembly and production runs. The shift is derived 
form GCCardTableSize which is a gc global command line option so 
susceptible to being reset.

We could use an aot_reloc with a different format to tag card table 
shift lsr instructions and patch them at shared code load to use the 
current runtime GCCardTableSize. Of course, this is not as urgent a 
problem as the grain size shift because the card table size only ever 
changes thanks to an explicit command line request whereas the grain 
size may be changed ergonomically when -Xmx is passed.

> Be careful with using `format()` in shared code because it depends on 
> platform specific setting `format_width` in `relocInfo_<arch>.hpp` 
> (32-bit arm has format_width = 0).

Oh, that's a nuisance. I was concerned that I was perhaps using the 
wrong reloc model here. Should I be encoding info about what/how to 
patch the target instruction(s) using reloc data?

regards,


Andrew Dinn
-----------


From asmehra at redhat.com  Wed Jul 24 14:54:01 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Wed, 24 Jul 2024 10:54:01 -0400
Subject: Missing entry in SCC due to decomp count mismatch
Message-ID: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>

During the startup of a quarkus app, I see a particular method that gets C2
compiled almost every time in the production run with the premain branch .
I don't see this happening with the mainline.
The reason this method caught my attention is the significant amount of
memory its C2 compilation consumes (between 25-40 mb) compared to the other
compilations.
The method in question is
jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z

The assembly phase added two entries for this method in the code cache:

[3.391s][info   ][scc,nmethod ] 2631 (L4): Writing nmethod
'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
(comp level: 4, decomp: 1, has clinit barriers) to Startup Code Cache
'quarkus-getting-started.cds.code'
...
[7.215s][info   ][scc,nmethod ] 4354 (L4): Writing nmethod
'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
(comp level: 4, decomp: 1) to Startup Code Cache
'quarkus-getting-started.cds.code'

In the production run the "preload" version was successfully loaded:

[0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod
'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
(decomp: 0, hash: 0x493f24e2, has clinit barriers)

The PrintTieredEvents logs indicate this method was also sent for
compilation during replay training:

0.877593: [force-compile level=4
[jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z]
@-1 queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0
mdo=0(0),0(0) max levels=4,0 compilable=c1,c1-osr,c2,c2-osr status=idle
mtd: mdo=18830(8306), 0(0), deps=0]

Ideally this request should have been fulfilled by the second entry in the
code cache. But instead I see this message:

[0.878s][info ][scc,nmethod ] Missing entry for
'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
(comp_level 4, decomp: 0, hash: 0x493f24e2)

This is followed by the C2 compilation of the method.

It looks like the failure to find the second entry is due to a mismatch of
the decomp count [0]. The decomp count is stored in the MethodData.
Is it possible that the method data is not yet installed when replay
training is done? If so, is that by design or a bug?

[0]
https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938

Thanks,
- Ashutosh Mehra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240724/f651d488/attachment.htm>

From duke at openjdk.org  Wed Jul 24 15:49:34 2024
From: duke at openjdk.org (duke)
Date: Wed, 24 Jul 2024 15:49:34 GMT
Subject: git: openjdk/leyden: premain: New "AOT" options (-XX:AOTCache=xxx,
 etc) implemented as aliases to existing CDS options
Message-ID: <51327a6e-0514-4d0b-8722-b7b2778510c5@openjdk.org>

Changeset: b24e6fa2
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-24 08:47:44 +0000
URL:       https://git.openjdk.org/leyden/commit/b24e6fa23528e9aadd4f4b41035c22b7db2bf5c9

New "AOT" options (-XX:AOTCache=xxx, etc) implemented as aliases to existing CDS options

! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cdsConfig.hpp
! src/hotspot/share/cds/cds_globals.hpp
! src/hotspot/share/runtime/arguments.cpp
! src/java.base/share/native/libjli/java.c
+ test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java


From duke at openjdk.org  Wed Jul 24 15:53:48 2024
From: duke at openjdk.org (duke)
Date: Wed, 24 Jul 2024 15:53:48 GMT
Subject: git: openjdk/leyden: premain: fixed typo
Message-ID: <46cee746-0c8c-4ec9-ba7c-6a94adcb4412@openjdk.org>

Changeset: 37b332cc
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-24 08:52:38 +0000
URL:       https://git.openjdk.org/leyden/commit/37b332cc445682814c36cd482244a146faa95511

fixed typo

! src/hotspot/share/cds/cds_globals.hpp


From vladimir.kozlov at oracle.com  Wed Jul 24 19:43:27 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Jul 2024 12:43:27 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
Message-ID: <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>

Thank you for checking code for card_table_address.

 > Oh, that's a nuisance. I was concerned that I was perhaps using the wrong reloc model here. Should I be encoding info
 > about what/how to patch the target instruction(s) using reloc data?

I am currently thinking about adding indication what relocation is pointing on: blob, stubs, external address, string.
Currently we are looking through all our address tables in SCCache to find match. Would be nice if we can get this 
information from relocation. And I also thought about using format for it but realized it is PD and it reserves bits in 
RelocInfo word. On other hand we can add an other 12 (31 - 18 - 1) new relocations without using additional bits.

In short add new relocation if you need it.

Thanks,
Vladimir K

On 7/24/24 7:40 AM, Andrew Dinn wrote:
> On 23/07/2024 18:44, Vladimir Kozlov wrote:
>> I agree. As we discussed on meeting we may use it to patch compressed oops/klass code too.
> 
> Yes, we could potentially do something similar to adjust the shift and base adjustment employed when generating a narrow 
> oop or klass encode or decode. However, that would only be useful with certain limits.
> 
> 1) We can only cater for a change from one narrow-oop/klass base+shift configuration to another base+shift 
> configuration. Patching code to switch from narrow oops/klass pointers to full width (or vice versa) would require 
> adjusting not just the oop/klass load/store but also other instructions that hard-wire header/payload field sizes and 
> offsets based on the narrow/full width layout assumptions. Likewise it would require resizing and repacking objects 
> stored in the CDS mapped heap section.
> 
> 2) Even if we restrict ourselves to the case where we retain narrow oops and simply allow for a change of base and/or 
> shift (i.e. keep the object layouts the same), that will only work if pointers installed in mapped CDS heap objects are 
> also rewritten to use the runtime encoding.
> 
> 3) When generating AOT code for the encode and decode we would have to allow for the worst case i.e. leave room (nops) 
> for both heap-base adjustment and shift even when they are not needed at generate time.
> 
>> We have the same issue with card_table_address. I actually don't know why current AOT code works??? May be because it 
>> is the same value in training and production runs. But we need to fix it too.
> 
>> It is constant node which is embedded into AddP node:
>> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp*L96__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-9E0w0Jbo$ 
> 
> I believe C2 is ok. On AArch64 the C2 back end has an operand called immByteMapBase that matches any use of 
> byte_map_base as a pointer constant. A corresponding rule ensures that any attempt to load that constant pointer is done 
> by calling
> 
>  ? __ load_byte_map_base()
> 
> and the macr assembler uses an ExternalAddress when StoreCachedCode is set.
> 
>> I marked it only in platform specific code:
>> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp*L68__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-92hI_Afg$ 
> 
> I also think there is no mystery as to why this works on AArch64. The equivalent code in 
> cardTableBarrierSetAssembler_aarch64.cpp also calls
> 
>  ? __ load_byte_map_base()
> 
> However, that said, looking at the barrier card table write it seems the card table shift is another value that the user 
> might decide to reconfigure between assembly and production runs. The shift is derived form GCCardTableSize which is a 
> gc global command line option so susceptible to being reset.
> 
> We could use an aot_reloc with a different format to tag card table shift lsr instructions and patch them at shared code 
> load to use the current runtime GCCardTableSize. Of course, this is not as urgent a problem as the grain size shift 
> because the card table size only ever changes thanks to an explicit command line request whereas the grain size may be 
> changed ergonomically when -Xmx is passed.
> 
>> Be careful with using `format()` in shared code because it depends on platform specific setting `format_width` in 
>> `relocInfo_<arch>.hpp` (32-bit arm has format_width = 0).
> 
> Oh, that's a nuisance. I was concerned that I was perhaps using the wrong reloc model here. Should I be encoding info 
> about what/how to patch the target instruction(s) using reloc data?
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 

From vladimir.kozlov at oracle.com  Wed Jul 24 19:55:33 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 24 Jul 2024 12:55:33 -0700
Subject: Missing entry in SCC due to decomp count mismatch
In-Reply-To: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>
References: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>
Message-ID: <0b62bdf4-dab5-46f9-b57d-6b835c95245b@oracle.com>

Thank you for report, Ashutosh

Is this with one step workflow? With one step workflow we should ignore decomp count because code is generated not 
during execution but based on training data in forked VM - no deoptimization happens there.

`decomp count` was introduced for 5 steps workflow when we generate aot code as we execute application with idea that 
production run will follow the same compilation/deoptimization steps.

Actually I implemented it before we start using TD to trigger compilation. May be this is the reason that 5 steps 
workflow is slow now when we use TD. I need to check.

Thanks,
Vladimir K

On 7/24/24 7:54 AM, Ashutosh Mehra wrote:
> During the startup of a quarkus?app, I see a particular method that gets C2 compiled almost every time in the production 
> run with?the premain branch . I don't see this happening with the mainline.
> The reason this method caught my attention is the significant amount?of memory its C2 compilation consumes (between 
> 25-40 mb) compared to the other compilations.
> The method in question is 
> jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z
> 
> The assembly phase added two entries for this method in the code cache:
> 
> [3.391s][info ? ][scc,nmethod ] 2631 (L4): Writing nmethod 
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp 
> level: 4, decomp: 1, has clinit barriers) to Startup Code Cache 'quarkus-getting-started.cds.code'
> ...
> [7.215s][info ? ][scc,nmethod ] 4354 (L4): Writing nmethod 
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (comp 
> level: 4, decomp: 1) to Startup Code Cache 'quarkus-getting-started.cds.code'
> 
> In the production run the "preload" version was successfully loaded:
> 
> [0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod 
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (decomp: 
> 0, hash: 0x493f24e2, has clinit barriers)
> 
> The PrintTieredEventslogs indicate this method was also sent for compilation during replay training:
> 
> 0.877593: [force-compile level=4 
> [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z] @-1 
> queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0 mdo=0(0),0(0) max levels=4,0 
> compilable=c1,c1-osr,c2,c2-osr status=idle mtd: mdo=18830(8306), 0(0), deps=0]
> 
> Ideally this request should have been fulfilled by the second entry in the code cache. But instead I see this message:
> 
> [0.878s][info ][scc,nmethod] Missing entry for 
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' 
> (comp_level 4, decomp: 0, hash: 0x493f24e2)
> 
> This is followed by the C2 compilation of the method.
> 
> It looks like the failure to find the second entry is due to a mismatch of the decomp count?[0]. The decomp count is 
> stored in the MethodData.
> Is it possible that the method data is not yet installed when replay training is done? If so, is that by design or a bug?
> 
> [0] 
> https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938 
> <https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938>
> 
> Thanks,
> - Ashutosh Mehra

From asmehra at redhat.com  Wed Jul 24 22:46:30 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Wed, 24 Jul 2024 18:46:30 -0400
Subject: Missing entry in SCC due to decomp count mismatch
In-Reply-To: <0b62bdf4-dab5-46f9-b57d-6b835c95245b@oracle.com>
References: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>
 <0b62bdf4-dab5-46f9-b57d-6b835c95245b@oracle.com>
Message-ID: <CAKt0pyRnX7sQ8MGGhh1dPf4TsxBZZUcyH2Zubf-g1g-QJ5+bbA@mail.gmail.com>

Hi Vladimir,
>
> Is this with one step workflow? With one step workflow we should ignore
> decomp count because code is generated not
> during execution but based on training data in forked VM - no
> deoptimization happens there.


Yes, this is with the 1-step workflow.

- Ashutosh Mehra


On Wed, Jul 24, 2024 at 3:56?PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Thank you for report, Ashutosh
>
> Is this with one step workflow? With one step workflow we should ignore
> decomp count because code is generated not
> during execution but based on training data in forked VM - no
> deoptimization happens there.
>
> `decomp count` was introduced for 5 steps workflow when we generate aot
> code as we execute application with idea that
> production run will follow the same compilation/deoptimization steps.
>
> Actually I implemented it before we start using TD to trigger compilation.
> May be this is the reason that 5 steps
> workflow is slow now when we use TD. I need to check.
>
> Thanks,
> Vladimir K
>
> On 7/24/24 7:54 AM, Ashutosh Mehra wrote:
> > During the startup of a quarkus app, I see a particular method that gets
> C2 compiled almost every time in the production
> > run with the premain branch . I don't see this happening with the
> mainline.
> > The reason this method caught my attention is the significant amount of
> memory its C2 compilation consumes (between
> > 25-40 mb) compared to the other compilations.
> > The method in question is
> >
> jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z
> >
> > The assembly phase added two entries for this method in the code cache:
> >
> > [3.391s][info   ][scc,nmethod ] 2631 (L4): Writing nmethod
> >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> (comp
> > level: 4, decomp: 1, has clinit barriers) to Startup Code Cache
> 'quarkus-getting-started.cds.code'
> > ...
> > [7.215s][info   ][scc,nmethod ] 4354 (L4): Writing nmethod
> >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> (comp
> > level: 4, decomp: 1) to Startup Code Cache
> 'quarkus-getting-started.cds.code'
> >
> > In the production run the "preload" version was successfully loaded:
> >
> > [0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod
> >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> (decomp:
> > 0, hash: 0x493f24e2, has clinit barriers)
> >
> > The PrintTieredEventslogs indicate this method was also sent for
> compilation during replay training:
> >
> > 0.877593: [force-compile level=4
> >
> [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z]
> @-1
> > queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0
> mdo=0(0),0(0) max levels=4,0
> > compilable=c1,c1-osr,c2,c2-osr status=idle mtd: mdo=18830(8306), 0(0),
> deps=0]
> >
> > Ideally this request should have been fulfilled by the second entry in
> the code cache. But instead I see this message:
> >
> > [0.878s][info ][scc,nmethod] Missing entry for
> >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>
> > (comp_level 4, decomp: 0, hash: 0x493f24e2)
> >
> > This is followed by the C2 compilation of the method.
> >
> > It looks like the failure to find the second entry is due to a mismatch
> of the decomp count [0]. The decomp count is
> > stored in the MethodData.
> > Is it possible that the method data is not yet installed when replay
> training is done? If so, is that by design or a bug?
> >
> > [0]
> >
> https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938
> > <
> https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938
> >
> >
> > Thanks,
> > - Ashutosh Mehra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240724/28940050/attachment.htm>

From duke at openjdk.org  Thu Jul 25 22:08:04 2024
From: duke at openjdk.org (duke)
Date: Thu, 25 Jul 2024 22:08:04 GMT
Subject: git: openjdk/leyden: premain: Added -XX:AOTMode as specified in latest
 JEP draft. Removed RecordAOTConfiguration/CreateAOTCache
Message-ID: <1390c2d0-45a0-4560-8038-2e683bb1fa9f@openjdk.org>

Changeset: f972b8dc
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-25 15:06:08 +0000
URL:       https://git.openjdk.org/leyden/commit/f972b8dcc92fb531cb8b9991676c9f1d1be05057

Added -XX:AOTMode as specified in latest JEP draft. Removed RecordAOTConfiguration/CreateAOTCache

! src/hotspot/share/cds/cdsConfig.cpp
! src/hotspot/share/cds/cds_globals.hpp
! src/java.base/share/native/libjli/java.c
! test/hotspot/jtreg/runtime/cds/appcds/AOTFlags.java


From vladimir.kozlov at oracle.com  Fri Jul 26 00:18:22 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Thu, 25 Jul 2024 17:18:22 -0700
Subject: [External] : Re: Missing entry in SCC due to decomp count mismatch
In-Reply-To: <CAKt0pyRnX7sQ8MGGhh1dPf4TsxBZZUcyH2Zubf-g1g-QJ5+bbA@mail.gmail.com>
References: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>
 <0b62bdf4-dab5-46f9-b57d-6b835c95245b@oracle.com>
 <CAKt0pyRnX7sQ8MGGhh1dPf4TsxBZZUcyH2Zubf-g1g-QJ5+bbA@mail.gmail.com>
Message-ID: <860ef233-2be7-404d-93bf-5ed95fb81502@oracle.com>

I looked on code and for "Preloading" nmethod we ignore decompile counter. We check it only when looking for "normal" 
AOT code.

The counter's value in "Preloading" and "Missing" messages is taking from current MDO [1] and not from the entry 
describing AOT code.

I remember (Igor may confirm it) that CompilerCounters data is nulled for TD including _nof_decompiles value. That is 
why we see 0 when loading code.

It seems we are "lucky" in most cases because we deoptimize (and update counter) may be level 2 (C1) AOT code or 
"Preloaded" code. That is what I see in my runs which has opposite issue: we record AOT code with `decomp == 0` and when 
we load it "preload" AOT code was deoptimized and counter updated in MDO and check failed when we tried to load "normal" 
AOT code.

Anyway. As I said, for one-step workflow we should not use decompile counter. I may actually save only latest version of 
"normal" nmethod even for 5-step workflow. The question is which nmethod version corresponds to saved MDO? For on-step 
workflow the answer is simple and we can ignore the counter. For 5 steps I need to check corresponding MDO to save 
correct version.

Thanks,
Vladimir K

[1] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L2868
[2] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L317

On 7/24/24 3:46 PM, Ashutosh Mehra wrote:
> Hi Vladimir,
> 
>     Is this with one step workflow? With one step workflow we should ignore decomp count because code is generated not
>     during execution but based on training data in forked VM - no deoptimization happens there.
> 
> 
> Yes, this is with the 1-step workflow.
> 
> - Ashutosh Mehra
> 
> 
> On Wed, Jul 24, 2024 at 3:56?PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     Thank you for report, Ashutosh
> 
>     Is this with one step workflow? With one step workflow we should ignore decomp count because code is generated not
>     during execution but based on training data in forked VM - no deoptimization happens there.
> 
>     `decomp count` was introduced for 5 steps workflow when we generate aot code as we execute application with idea that
>     production run will follow the same compilation/deoptimization steps.
> 
>     Actually I implemented it before we start using TD to trigger compilation. May be this is the reason that 5 steps
>     workflow is slow now when we use TD. I need to check.
> 
>     Thanks,
>     Vladimir K
> 
>     On 7/24/24 7:54 AM, Ashutosh Mehra wrote:
>      > During the startup of a quarkus?app, I see a particular method that gets C2 compiled almost every time in the
>     production
>      > run with?the premain branch . I don't see this happening with the mainline.
>      > The reason this method caught my attention is the significant amount?of memory its C2 compilation consumes (between
>      > 25-40 mb) compared to the other compilations.
>      > The method in question is
>      > jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z
>      >
>      > The assembly phase added two entries for this method in the code cache:
>      >
>      > [3.391s][info ? ][scc,nmethod ] 2631 (L4): Writing nmethod
>      > 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>     (comp
>      > level: 4, decomp: 1, has clinit barriers) to Startup Code Cache 'quarkus-getting-started.cds.code'
>      > ...
>      > [7.215s][info ? ][scc,nmethod ] 4354 (L4): Writing nmethod
>      > 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>     (comp
>      > level: 4, decomp: 1) to Startup Code Cache 'quarkus-getting-started.cds.code'
>      >
>      > In the production run the "preload" version was successfully loaded:
>      >
>      > [0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod
>      > 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>     (decomp:
>      > 0, hash: 0x493f24e2, has clinit barriers)
>      >
>      > The PrintTieredEventslogs indicate this method was also sent for compilation during replay training:
>      >
>      > 0.877593: [force-compile level=4
>      > [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z] @-1
>      > queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0 mdo=0(0),0(0) max levels=4,0
>      > compilable=c1,c1-osr,c2,c2-osr status=idle mtd: mdo=18830(8306), 0(0), deps=0]
>      >
>      > Ideally this request should have been fulfilled by the second entry in the code cache. But instead I see this
>     message:
>      >
>      > [0.878s][info ][scc,nmethod] Missing entry for
>      > 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>      > (comp_level 4, decomp: 0, hash: 0x493f24e2)
>      >
>      > This is followed by the C2 compilation of the method.
>      >
>      > It looks like the failure to find the second entry is due to a mismatch of the decomp count?[0]. The decomp count is
>      > stored in the MethodData.
>      > Is it possible that the method data is not yet installed when replay training is done? If so, is that by design
>     or a bug?
>      >
>      > [0]
>      >
>     https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$>
>      >
>     <https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$>>
>      >
>      > Thanks,
>      > - Ashutosh Mehra
> 

From duke at openjdk.org  Fri Jul 26 05:17:16 2024
From: duke at openjdk.org (duke)
Date: Fri, 26 Jul 2024 05:17:16 GMT
Subject: git: openjdk/leyden: premain: Fixed silly mistake in last commit
Message-ID: <2f670b25-249c-4451-bcc0-6c1e393046c8@openjdk.org>

Changeset: c0826c59
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-25 22:14:42 +0000
URL:       https://git.openjdk.org/leyden/commit/c0826c59c7d47b36660daa9b4b523e5eed1a3f12

Fixed silly mistake in last commit

! src/hotspot/share/cds/cdsConfig.cpp


From asmehra at redhat.com  Fri Jul 26 15:17:06 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Fri, 26 Jul 2024 11:17:06 -0400
Subject: [External] : Re: Missing entry in SCC due to decomp count mismatch
In-Reply-To: <860ef233-2be7-404d-93bf-5ed95fb81502@oracle.com>
References: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>
 <0b62bdf4-dab5-46f9-b57d-6b835c95245b@oracle.com>
 <CAKt0pyRnX7sQ8MGGhh1dPf4TsxBZZUcyH2Zubf-g1g-QJ5+bbA@mail.gmail.com>
 <860ef233-2be7-404d-93bf-5ed95fb81502@oracle.com>
Message-ID: <CAKt0pyT_rZBqozOm8jWJ6JPUanhJD8Z=9SWVh977H8MhoMWp1A@mail.gmail.com>

>
> The counter's value in "Preloading" and "Missing" messages is taking from
> current MDO [1] and not from the entry
> describing AOT code.
>

That's right.


> I remember (Igor may confirm it) that CompilerCounters data is nulled for
> TD including _nof_decompiles value. That is
> why we see 0 when loading code.
>

For "Missing" message, the counter is obtained from Method->method_data()
which would return null if the MethodData
recorded in the training data is not yet installed in the Method.  If
Method->method_data() is null, then it prints 0 as the counter value.
This is the case I am seeing if I print the method data in the "Missing"
message:

[0.878s][info ][scc,nmethod ] Missing entry for
'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
(md: (nil), comp_level 4, decomp: 0, hash: 0x493f24e2)

Notice that md is null.

 With one step workflow we should ignore decomp count because code is
> generated not
>  during execution but based on training data in forked VM - no
> deoptimization happens there.
>

hmm, I see some entries marked as "made not entrant" in the output of
PrintCompilation during the assembly phase of 1-step workflow.

   S131  432 %       2
jdk.internal.util.ArraysSupport::unsignedHashCode @ 8 (36 bytes)   made not
entrant
   S133  433         2
jdk.internal.util.ArraysSupport::unsignedHashCode (36 bytes)   made not
entrant
   S158  506         2       java.util.HashMap::putVal (300 bytes)   made
not entrant

Thanks,
- Ashutosh Mehra


On Thu, Jul 25, 2024 at 8:18?PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> I looked on code and for "Preloading" nmethod we ignore decompile counter.
> We check it only when looking for "normal"
> AOT code.
>
> The counter's value in "Preloading" and "Missing" messages is taking from
> current MDO [1] and not from the entry
> describing AOT code.
>
> I remember (Igor may confirm it) that CompilerCounters data is nulled for
> TD including _nof_decompiles value. That is
> why we see 0 when loading code.
>
> It seems we are "lucky" in most cases because we deoptimize (and update
> counter) may be level 2 (C1) AOT code or
> "Preloaded" code. That is what I see in my runs which has opposite issue:
> we record AOT code with `decomp == 0` and when
> we load it "preload" AOT code was deoptimized and counter updated in MDO
> and check failed when we tried to load "normal"
> AOT code.
>
> Anyway. As I said, for one-step workflow we should not use decompile
> counter. I may actually save only latest version of
> "normal" nmethod even for 5-step workflow. The question is which nmethod
> version corresponds to saved MDO? For on-step
> workflow the answer is simple and we can ignore the counter. For 5 steps I
> need to check corresponding MDO to save
> correct version.
>
> Thanks,
> Vladimir K
>
> [1]
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L2868
> [2]
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L317
>
> On 7/24/24 3:46 PM, Ashutosh Mehra wrote:
> > Hi Vladimir,
> >
> >     Is this with one step workflow? With one step workflow we should
> ignore decomp count because code is generated not
> >     during execution but based on training data in forked VM - no
> deoptimization happens there.
> >
> >
> > Yes, this is with the 1-step workflow.
> >
> > - Ashutosh Mehra
> >
> >
> > On Wed, Jul 24, 2024 at 3:56?PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> >
> >     Thank you for report, Ashutosh
> >
> >     Is this with one step workflow? With one step workflow we should
> ignore decomp count because code is generated not
> >     during execution but based on training data in forked VM - no
> deoptimization happens there.
> >
> >     `decomp count` was introduced for 5 steps workflow when we generate
> aot code as we execute application with idea that
> >     production run will follow the same compilation/deoptimization steps.
> >
> >     Actually I implemented it before we start using TD to trigger
> compilation. May be this is the reason that 5 steps
> >     workflow is slow now when we use TD. I need to check.
> >
> >     Thanks,
> >     Vladimir K
> >
> >     On 7/24/24 7:54 AM, Ashutosh Mehra wrote:
> >      > During the startup of a quarkus app, I see a particular method
> that gets C2 compiled almost every time in the
> >     production
> >      > run with the premain branch . I don't see this happening with the
> mainline.
> >      > The reason this method caught my attention is the significant
> amount of memory its C2 compilation consumes (between
> >      > 25-40 mb) compared to the other compilations.
> >      > The method in question is
> >      >
> jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z
> >      >
> >      > The assembly phase added two entries for this method in the code
> cache:
> >      >
> >      > [3.391s][info   ][scc,nmethod ] 2631 (L4): Writing nmethod
> >      >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >     (comp
> >      > level: 4, decomp: 1, has clinit barriers) to Startup Code Cache
> 'quarkus-getting-started.cds.code'
> >      > ...
> >      > [7.215s][info   ][scc,nmethod ] 4354 (L4): Writing nmethod
> >      >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >     (comp
> >      > level: 4, decomp: 1) to Startup Code Cache
> 'quarkus-getting-started.cds.code'
> >      >
> >      > In the production run the "preload" version was successfully
> loaded:
> >      >
> >      > [0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod
> >      >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >     (decomp:
> >      > 0, hash: 0x493f24e2, has clinit barriers)
> >      >
> >      > The PrintTieredEventslogs indicate this method was also sent for
> compilation during replay training:
> >      >
> >      > 0.877593: [force-compile level=4
> >      >
> [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z]
> @-1
> >      > queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0
> mdo=0(0),0(0) max levels=4,0
> >      > compilable=c1,c1-osr,c2,c2-osr status=idle mtd: mdo=18830(8306),
> 0(0), deps=0]
> >      >
> >      > Ideally this request should have been fulfilled by the second
> entry in the code cache. But instead I see this
> >     message:
> >      >
> >      > [0.878s][info ][scc,nmethod] Missing entry for
> >      >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >      > (comp_level 4, decomp: 0, hash: 0x493f24e2)
> >      >
> >      > This is followed by the C2 compilation of the method.
> >      >
> >      > It looks like the failure to find the second entry is due to a
> mismatch of the decomp count [0]. The decomp count is
> >      > stored in the MethodData.
> >      > Is it possible that the method data is not yet installed when
> replay training is done? If so, is that by design
> >     or a bug?
> >      >
> >      > [0]
> >      >
> >
> https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$
> >
> >      >
> >     <
> https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$
> >>
> >      >
> >      > Thanks,
> >      > - Ashutosh Mehra
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240726/75f0ca14/attachment.htm>

From vladimir.kozlov at oracle.com  Fri Jul 26 16:28:03 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 26 Jul 2024 09:28:03 -0700
Subject: [External] : Re: Missing entry in SCC due to decomp count mismatch
In-Reply-To: <CAKt0pyT_rZBqozOm8jWJ6JPUanhJD8Z=9SWVh977H8MhoMWp1A@mail.gmail.com>
References: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>
 <0b62bdf4-dab5-46f9-b57d-6b835c95245b@oracle.com>
 <CAKt0pyRnX7sQ8MGGhh1dPf4TsxBZZUcyH2Zubf-g1g-QJ5+bbA@mail.gmail.com>
 <860ef233-2be7-404d-93bf-5ed95fb81502@oracle.com>
 <CAKt0pyT_rZBqozOm8jWJ6JPUanhJD8Z=9SWVh977H8MhoMWp1A@mail.gmail.com>
Message-ID: <564107cb-a68a-4a6f-882e-deb226123301@oracle.com>

Ashutosh, please try this patch:

diff --git a/src/hotspot/share/code/SCCache.cpp b/src/hotspot/share/code/SCCache.cpp
index 551f80e1411..87f2d718320 100644
--- a/src/hotspot/share/code/SCCache.cpp
+++ b/src/hotspot/share/code/SCCache.cpp
@@ -934,8 +934,7 @@ static bool check_entry(SCCEntry::Kind kind, uint id, uint comp_level, uint deco
    if (entry->kind() == kind) {
      assert(entry->id() == id, "sanity");
      if (kind != SCCEntry::Code || (!entry->not_entrant() && !entry->has_clinit_barriers() &&
-                                  entry->comp_level() == comp_level &&
-                                  (comp_level == CompLevel_limited_profile || entry->decompile() == decomp))) {
+                                  (entry->comp_level() == comp_level))) {
        return true; // Found
      }
    }


Thanks,
Vladimir K

On 7/26/24 8:17 AM, Ashutosh Mehra wrote:
>     The counter's value in "Preloading" and "Missing" messages is taking from current MDO [1] and not from the entry
>     describing AOT code.
> 
> 
> That's right.
> 
> 
>     I remember (Igor may confirm it) that CompilerCounters data is nulled for TD including _nof_decompiles value. That is
>     why we see 0 when loading code.
> 
> 
> For "Missing" message, the counter is obtained from Method->method_data() which would return?null if the MethodData
> recorded in the training data is not yet installed in the Method.? If Method->method_data() is null, then it prints 0 as 
> the counter value.
> This is the case I am seeing if I print the method data in the "Missing" message:
> 
> [0.878s][info ][scc,nmethod ] Missing entry for 
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z' (md: 
> (nil), comp_level 4, decomp: 0, hash: 0x493f24e2)
> 
> Notice that md is null.
> 
>      ?With one step workflow we should ignore decomp count because code is generated not
>      ?during execution but based on training data in forked VM - no deoptimization happens there.
> 
> 
> hmm, I see some entries marked as "made not entrant" in the output of PrintCompilation during the assembly phase of 
> 1-step workflow.
> 
>  ? ?S131 ?432 % ? ? ? 2 ? ? ? jdk.internal.util.ArraysSupport::unsignedHashCode @ 8 (36 bytes) ? made not entrant
>  ? ?S133 ?433 ? ? ? ? 2 ? ? ? jdk.internal.util.ArraysSupport::unsignedHashCode (36 bytes) ? made not entrant
>  ? ?S158 ?506 ? ? ? ? 2 ? ? ? java.util.HashMap::putVal (300 bytes) ? made not entrant
> 
> Thanks,
> - Ashutosh Mehra
> 
> 
> On Thu, Jul 25, 2024 at 8:18?PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
>     I looked on code and for "Preloading" nmethod we ignore decompile counter. We check it only when looking for "normal"
>     AOT code.
> 
>     The counter's value in "Preloading" and "Missing" messages is taking from current MDO [1] and not from the entry
>     describing AOT code.
> 
>     I remember (Igor may confirm it) that CompilerCounters data is nulled for TD including _nof_decompiles value. That is
>     why we see 0 when loading code.
> 
>     It seems we are "lucky" in most cases because we deoptimize (and update counter) may be level 2 (C1) AOT code or
>     "Preloaded" code. That is what I see in my runs which has opposite issue: we record AOT code with `decomp == 0` and
>     when
>     we load it "preload" AOT code was deoptimized and counter updated in MDO and check failed when we tried to load
>     "normal"
>     AOT code.
> 
>     Anyway. As I said, for one-step workflow we should not use decompile counter. I may actually save only latest
>     version of
>     "normal" nmethod even for 5-step workflow. The question is which nmethod version corresponds to saved MDO? For on-step
>     workflow the answer is simple and we can ignore the counter. For 5 steps I need to check corresponding MDO to save
>     correct version.
> 
>     Thanks,
>     Vladimir K
> 
>     [1] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L2868
>     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp*L2868__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYcRh3ntYA$>
>     [2] https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L317
>     <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp*L317__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYe9CuvRDQ$>
> 
>     On 7/24/24 3:46 PM, Ashutosh Mehra wrote:
>      > Hi Vladimir,
>      >
>      >? ? ?Is this with one step workflow? With one step workflow we should ignore decomp count because code is
>     generated not
>      >? ? ?during execution but based on training data in forked VM - no deoptimization happens there.
>      >
>      >
>      > Yes, this is with the 1-step workflow.
>      >
>      > - Ashutosh Mehra
>      >
>      >
>      > On Wed, Jul 24, 2024 at 3:56?PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
>     <mailto:vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>>> wrote:
>      >
>      >? ? ?Thank you for report, Ashutosh
>      >
>      >? ? ?Is this with one step workflow? With one step workflow we should ignore decomp count because code is
>     generated not
>      >? ? ?during execution but based on training data in forked VM - no deoptimization happens there.
>      >
>      >? ? ?`decomp count` was introduced for 5 steps workflow when we generate aot code as we execute application with
>     idea that
>      >? ? ?production run will follow the same compilation/deoptimization steps.
>      >
>      >? ? ?Actually I implemented it before we start using TD to trigger compilation. May be this is the reason that 5 steps
>      >? ? ?workflow is slow now when we use TD. I need to check.
>      >
>      >? ? ?Thanks,
>      >? ? ?Vladimir K
>      >
>      >? ? ?On 7/24/24 7:54 AM, Ashutosh Mehra wrote:
>      >? ? ? > During the startup of a quarkus?app, I see a particular method that gets C2 compiled almost every time in the
>      >? ? ?production
>      >? ? ? > run with?the premain branch . I don't see this happening with the mainline.
>      >? ? ? > The reason this method caught my attention is the significant amount?of memory its C2 compilation consumes
>     (between
>      >? ? ? > 25-40 mb) compared to the other compilations.
>      >? ? ? > The method in question is
>      >? ? ? > jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z
>      >? ? ? >
>      >? ? ? > The assembly phase added two entries for this method in the code cache:
>      >? ? ? >
>      >? ? ? > [3.391s][info ? ][scc,nmethod ] 2631 (L4): Writing nmethod
>      >? ? ? >
>     'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>      >? ? ?(comp
>      >? ? ? > level: 4, decomp: 1, has clinit barriers) to Startup Code Cache 'quarkus-getting-started.cds.code'
>      >? ? ? > ...
>      >? ? ? > [7.215s][info ? ][scc,nmethod ] 4354 (L4): Writing nmethod
>      >? ? ? >
>     'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>      >? ? ?(comp
>      >? ? ? > level: 4, decomp: 1) to Startup Code Cache 'quarkus-getting-started.cds.code'
>      >? ? ? >
>      >? ? ? > In the production run the "preload" version was successfully loaded:
>      >? ? ? >
>      >? ? ? > [0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod
>      >? ? ? >
>     'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>      >? ? ?(decomp:
>      >? ? ? > 0, hash: 0x493f24e2, has clinit barriers)
>      >? ? ? >
>      >? ? ? > The PrintTieredEventslogs indicate this method was also sent for compilation during replay training:
>      >? ? ? >
>      >? ? ? > 0.877593: [force-compile level=4
>      >? ? ? >
>     [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z] @-1
>      >? ? ? > queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00 total=56,0 mdo=0(0),0(0) max levels=4,0
>      >? ? ? > compilable=c1,c1-osr,c2,c2-osr status=idle mtd: mdo=18830(8306), 0(0), deps=0]
>      >? ? ? >
>      >? ? ? > Ideally this request should have been fulfilled by the second entry in the code cache. But instead I see this
>      >? ? ?message:
>      >? ? ? >
>      >? ? ? > [0.878s][info ][scc,nmethod] Missing entry for
>      >? ? ? >
>     'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
>      >? ? ? > (comp_level 4, decomp: 0, hash: 0x493f24e2)
>      >? ? ? >
>      >? ? ? > This is followed by the C2 compilation of the method.
>      >? ? ? >
>      >? ? ? > It looks like the failure to find the second entry is due to a mismatch of the decomp count?[0]. The
>     decomp count is
>      >? ? ? > stored in the MethodData.
>      >? ? ? > Is it possible that the method data is not yet installed when replay training is done? If so, is that by
>     design
>      >? ? ?or a bug?
>      >? ? ? >
>      >? ? ? > [0]
>      >? ? ? >
>      >
>     https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYcE3EES5w$> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$ <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$>>
>      >? ? ? >
>      >   
>      ?<https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938 <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYcE3EES5w$> <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$ <https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$>>>
>      >? ? ? >
>      >? ? ? > Thanks,
>      >? ? ? > - Ashutosh Mehra
>      >
> 

From duke at openjdk.org  Fri Jul 26 17:30:09 2024
From: duke at openjdk.org (duke)
Date: Fri, 26 Jul 2024 17:30:09 GMT
Subject: git: openjdk/leyden: premain: Added spring-boot-getting-started demo
Message-ID: <116de1f9-47c0-4c9f-8a95-f8af01553c8d@openjdk.org>

Changeset: d7c97f22
Branch: premain
Author:    iklam <ilam3388 at gmail.com>
Date:      2024-07-26 10:27:04 +0000
URL:       https://git.openjdk.org/leyden/commit/d7c97f2257d329db98e42bd9a99959eefb7fbc71

Added spring-boot-getting-started demo

! README.md
! test/hotspot/jtreg/premain/README.md
! test/hotspot/jtreg/premain/lib/GithubMDChart.java
+ test/hotspot/jtreg/premain/spring-boot-getting-started/Application.java
+ test/hotspot/jtreg/premain/spring-boot-getting-started/Makefile
+ test/hotspot/jtreg/premain/spring-boot-getting-started/pom.xml


From asmehra at redhat.com  Fri Jul 26 18:53:13 2024
From: asmehra at redhat.com (Ashutosh Mehra)
Date: Fri, 26 Jul 2024 14:53:13 -0400
Subject: [External] : Re: Missing entry in SCC due to decomp count mismatch
In-Reply-To: <564107cb-a68a-4a6f-882e-deb226123301@oracle.com>
References: <CAKt0pySQsrmwjG0bvopvOKoob48sLnHYb6eXKRVy4_OZdakBOA@mail.gmail.com>
 <0b62bdf4-dab5-46f9-b57d-6b835c95245b@oracle.com>
 <CAKt0pyRnX7sQ8MGGhh1dPf4TsxBZZUcyH2Zubf-g1g-QJ5+bbA@mail.gmail.com>
 <860ef233-2be7-404d-93bf-5ed95fb81502@oracle.com>
 <CAKt0pyT_rZBqozOm8jWJ6JPUanhJD8Z=9SWVh977H8MhoMWp1A@mail.gmail.com>
 <564107cb-a68a-4a6f-882e-deb226123301@oracle.com>
Message-ID: <CAKt0pyToGmO78nyJ531vRAi+KfG_d+aEWGmbD-h3FPsw+HMMbw@mail.gmail.com>

Yes, this seems to work. I don't see the "Missing entry" message
for StackMapGenerator::processBlock any more,
and it is now able to locate the c2 compiled version in the code cache and
use it.

[0.911s][info ][scc,nmethod ] 2662 (L4): Reading nmethod
'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
(md: 0x7f99f00c5f68, decomp: 0, hash: 0x493f24e2)

Thanks,
- Ashutosh Mehra


On Fri, Jul 26, 2024 at 12:28?PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

> Ashutosh, please try this patch:
>
> diff --git a/src/hotspot/share/code/SCCache.cpp
> b/src/hotspot/share/code/SCCache.cpp
> index 551f80e1411..87f2d718320 100644
> --- a/src/hotspot/share/code/SCCache.cpp
> +++ b/src/hotspot/share/code/SCCache.cpp
> @@ -934,8 +934,7 @@ static bool check_entry(SCCEntry::Kind kind, uint id,
> uint comp_level, uint deco
>     if (entry->kind() == kind) {
>       assert(entry->id() == id, "sanity");
>       if (kind != SCCEntry::Code || (!entry->not_entrant() &&
> !entry->has_clinit_barriers() &&
> -                                  entry->comp_level() == comp_level &&
> -                                  (comp_level ==
> CompLevel_limited_profile || entry->decompile() == decomp))) {
> +                                  (entry->comp_level() == comp_level))) {
>         return true; // Found
>       }
>     }
>
>
> Thanks,
> Vladimir K
>
> On 7/26/24 8:17 AM, Ashutosh Mehra wrote:
> >     The counter's value in "Preloading" and "Missing" messages is taking
> from current MDO [1] and not from the entry
> >     describing AOT code.
> >
> >
> > That's right.
> >
> >
> >     I remember (Igor may confirm it) that CompilerCounters data is
> nulled for TD including _nof_decompiles value. That is
> >     why we see 0 when loading code.
> >
> >
> > For "Missing" message, the counter is obtained from
> Method->method_data() which would return null if the MethodData
> > recorded in the training data is not yet installed in the Method.  If
> Method->method_data() is null, then it prints 0 as
> > the counter value.
> > This is the case I am seeing if I print the method data in the "Missing"
> message:
> >
> > [0.878s][info ][scc,nmethod ] Missing entry for
> >
> 'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> (md:
> > (nil), comp_level 4, decomp: 0, hash: 0x493f24e2)
> >
> > Notice that md is null.
> >
> >       With one step workflow we should ignore decomp count because code
> is generated not
> >       during execution but based on training data in forked VM - no
> deoptimization happens there.
> >
> >
> > hmm, I see some entries marked as "made not entrant" in the output of
> PrintCompilation during the assembly phase of
> > 1-step workflow.
> >
> >     S131  432 %       2
> jdk.internal.util.ArraysSupport::unsignedHashCode @ 8 (36 bytes)   made not
> entrant
> >     S133  433         2
> jdk.internal.util.ArraysSupport::unsignedHashCode (36 bytes)   made not
> entrant
> >     S158  506         2       java.util.HashMap::putVal (300 bytes)
> made not entrant
> >
> > Thanks,
> > - Ashutosh Mehra
> >
> >
> > On Thu, Jul 25, 2024 at 8:18?PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> >
> >     I looked on code and for "Preloading" nmethod we ignore decompile
> counter. We check it only when looking for "normal"
> >     AOT code.
> >
> >     The counter's value in "Preloading" and "Missing" messages is taking
> from current MDO [1] and not from the entry
> >     describing AOT code.
> >
> >     I remember (Igor may confirm it) that CompilerCounters data is
> nulled for TD including _nof_decompiles value. That is
> >     why we see 0 when loading code.
> >
> >     It seems we are "lucky" in most cases because we deoptimize (and
> update counter) may be level 2 (C1) AOT code or
> >     "Preloaded" code. That is what I see in my runs which has opposite
> issue: we record AOT code with `decomp == 0` and
> >     when
> >     we load it "preload" AOT code was deoptimized and counter updated in
> MDO and check failed when we tried to load
> >     "normal"
> >     AOT code.
> >
> >     Anyway. As I said, for one-step workflow we should not use decompile
> counter. I may actually save only latest
> >     version of
> >     "normal" nmethod even for 5-step workflow. The question is which
> nmethod version corresponds to saved MDO? For on-step
> >     workflow the answer is simple and we can ignore the counter. For 5
> steps I need to check corresponding MDO to save
> >     correct version.
> >
> >     Thanks,
> >     Vladimir K
> >
> >     [1]
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L2868
> >     <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp*L2868__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYcRh3ntYA$
> >
> >     [2]
> https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp#L317
> >     <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/code/SCCache.cpp*L317__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYe9CuvRDQ$
> >
> >
> >     On 7/24/24 3:46 PM, Ashutosh Mehra wrote:
> >      > Hi Vladimir,
> >      >
> >      >     Is this with one step workflow? With one step workflow we
> should ignore decomp count because code is
> >     generated not
> >      >     during execution but based on training data in forked VM - no
> deoptimization happens there.
> >      >
> >      >
> >      > Yes, this is with the 1-step workflow.
> >      >
> >      > - Ashutosh Mehra
> >      >
> >      >
> >      > On Wed, Jul 24, 2024 at 3:56?PM Vladimir Kozlov <
> vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>
> >     <mailto:vladimir.kozlov at oracle.com <mailto:
> vladimir.kozlov at oracle.com>>> wrote:
> >      >
> >      >     Thank you for report, Ashutosh
> >      >
> >      >     Is this with one step workflow? With one step workflow we
> should ignore decomp count because code is
> >     generated not
> >      >     during execution but based on training data in forked VM - no
> deoptimization happens there.
> >      >
> >      >     `decomp count` was introduced for 5 steps workflow when we
> generate aot code as we execute application with
> >     idea that
> >      >     production run will follow the same
> compilation/deoptimization steps.
> >      >
> >      >     Actually I implemented it before we start using TD to trigger
> compilation. May be this is the reason that 5 steps
> >      >     workflow is slow now when we use TD. I need to check.
> >      >
> >      >     Thanks,
> >      >     Vladimir K
> >      >
> >      >     On 7/24/24 7:54 AM, Ashutosh Mehra wrote:
> >      >      > During the startup of a quarkus app, I see a particular
> method that gets C2 compiled almost every time in the
> >      >     production
> >      >      > run with the premain branch . I don't see this happening
> with the mainline.
> >      >      > The reason this method caught my attention is the
> significant amount of memory its C2 compilation consumes
> >     (between
> >      >      > 25-40 mb) compared to the other compilations.
> >      >      > The method in question is
> >      >      >
> jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z
> >      >      >
> >      >      > The assembly phase added two entries for this method in
> the code cache:
> >      >      >
> >      >      > [3.391s][info   ][scc,nmethod ] 2631 (L4): Writing nmethod
> >      >      >
> >
>  'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >      >     (comp
> >      >      > level: 4, decomp: 1, has clinit barriers) to Startup Code
> Cache 'quarkus-getting-started.cds.code'
> >      >      > ...
> >      >      > [7.215s][info   ][scc,nmethod ] 4354 (L4): Writing nmethod
> >      >      >
> >
>  'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >      >     (comp
> >      >      > level: 4, decomp: 1) to Startup Code Cache
> 'quarkus-getting-started.cds.code'
> >      >      >
> >      >      > In the production run the "preload" version was
> successfully loaded:
> >      >      >
> >      >      > [0.695s][info ][scc,nmethod ] 727 (L4): Preloading nmethod
> >      >      >
> >
>  'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >      >     (decomp:
> >      >      > 0, hash: 0x493f24e2, has clinit barriers)
> >      >      >
> >      >      > The PrintTieredEventslogs indicate this method was also
> sent for compilation during replay training:
> >      >      >
> >      >      > 0.877593: [force-compile level=4
> >      >      >
> >
>  [jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z]
> @-1
> >      >      > queues=0,0 rate=0.000000 load=0.007812 k=1.00,1.00
> total=56,0 mdo=0(0),0(0) max levels=4,0
> >      >      > compilable=c1,c1-osr,c2,c2-osr status=idle mtd:
> mdo=18830(8306), 0(0), deps=0]
> >      >      >
> >      >      > Ideally this request should have been fulfilled by the
> second entry in the code cache. But instead I see this
> >      >     message:
> >      >      >
> >      >      > [0.878s][info ][scc,nmethod] Missing entry for
> >      >      >
> >
>  'jdk.internal.classfile.impl.StackMapGenerator::processBlock(Ljdk/internal/classfile/impl/RawBytecodeHelper;)Z'
> >      >      > (comp_level 4, decomp: 0, hash: 0x493f24e2)
> >      >      >
> >      >      > This is followed by the C2 compilation of the method.
> >      >      >
> >      >      > It looks like the failure to find the second entry is due
> to a mismatch of the decomp count [0]. The
> >     decomp count is
> >      >      > stored in the MethodData.
> >      >      > Is it possible that the method data is not yet installed
> when replay training is done? If so, is that by
> >     design
> >      >     or a bug?
> >      >      >
> >      >      > [0]
> >      >      >
> >      >
> >
> https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYcE3EES5w$>
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$
> >>
> >      >      >
> >      >
> >       <
> https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp#L938
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MUQ7NwYRlq4ggiM1yNmZO3xJb1OV-cpfGFcPgPZ9zA7vbDKlPtPvsVtsm-gca03z_WTzgi8AUzOWOYcE3EES5w$>
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$
> <
> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/ec5eb99653624d02a923a314ce40086753b240fc/src/hotspot/share/code/SCCache.cpp*L938__;Iw!!ACWV5N9M2RV99hQ!MGy9Dev-630RGry8or7lUEBQ4OYoS8cYwif2Z56RKLsqk7kx5YSD65AzSK9yYycpOWGubLGwFIZSImuh3ykRKw$
> >>>
> >      >      >
> >      >      > Thanks,
> >      >      > - Ashutosh Mehra
> >      >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240726/c696a82e/attachment.htm>

From duke at openjdk.org  Fri Jul 26 22:15:01 2024
From: duke at openjdk.org (duke)
Date: Fri, 26 Jul 2024 22:15:01 GMT
Subject: git: openjdk/leyden: premain-ea: Do not use decomp count for one step
 workflow
Message-ID: <c822079e-6bb8-4222-8b1a-e9651015b605@openjdk.org>

Changeset: c0df40cf
Branch: premain-ea
Author:    Vladimir Kozlov <vladimir.kozlov at oracle.com>
Date:      2024-07-26 15:12:42 +0000
URL:       https://git.openjdk.org/leyden/commit/c0df40cfe099d2e64350130d80c81c301afbd9f2

Do not use decomp count for one step workflow

! src/hotspot/share/code/SCCache.cpp


From adinn at redhat.com  Wed Jul 31 15:23:11 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Wed, 31 Jul 2024 16:23:11 +0100
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
Message-ID: <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>

I now have a fourth solution to the region resizing problem which I 
think is probably the nicest looking one so far:

 
https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1

Opinions welcome!

This version relies on a code cache AOT data area, generated into the 
initial stubs blob, which stores runtime constants that parameterize 
operation of AOT code. The AOT data area is initialized with the current 
runtime constants immediately after universe init. AOT code loads the 
constants indirectly via the region base address rather than embedding 
them into instructions. Non-AOT code can continue to use these constants 
as immediate values.

With this patch I have included the region grain size shift and the card 
table shift in the data area. So, this patch ensures that AOT code loads 
both grain shift and card shift counts rather than using immediates. I 
tested it passing -XX:GCCardSizeInBytes=128 -Xmx4M to a production run 
and it works fine.

The only address that needs relocating wit this patch is the AOT data 
area base. Note that it was useful using this to implement loading of 
two AOT code parameters as it highlights a general problem that is not 
face with only one field.

I decide to register only the base address of the AOT data area with the 
code cache as a relocatable (external) address because this is more 
robust than requiring registration of the address of every data field 
embedded in the AOT data area. However, in order for the AOT cache to be 
able to relocate loads from the data area they need to be implemented by 
installing the base address in a register and then adding the offset 
before executing the load.

This is fine for stub code where the generator can simply plant a load 
effective address (lea) of a pointer constant into a register and then 
add in the offset. However, I know C2 Value optimizations will certainly 
coalesce a pointer constant load followed by an add to an updated 
pointer constant load. I think this can also happen with C1 (it doesn't 
at the moment because in the current C1 code the grain shift load -- at 
offset 0 -- happens inline, while the card shift load -- at offset 4 -- 
only happens in a callout to stub code). I fixed this general problem by 
ensuring that the C1 and C2 back ends detect pointer constants that lie 
anywhere in the data area address *range*. For (only) those cases the 
lea is implemenetd by generating a base address load plus offset add.

It would be nice to be ale to fold the offset into the subsequent load. 
I'll look into that as a follow-up. Either way, I think this looks like 
the simplest and most robust solution to ensuring that AOT code is 
correctly parameterized at runtime. It is particularly nice that it 
doesn't need any new relocations.

regards,


Andrew Dinn
-----------

On 24/07/2024 20:43, Vladimir Kozlov wrote:
> Thank you for checking code for card_table_address.
> 
>  > Oh, that's a nuisance. I was concerned that I was perhaps using the 
> wrong reloc model here. Should I be encoding info
>  > about what/how to patch the target instruction(s) using reloc data?
> 
> I am currently thinking about adding indication what relocation is 
> pointing on: blob, stubs, external address, string.
> Currently we are looking through all our address tables in SCCache to 
> find match. Would be nice if we can get this information from 
> relocation. And I also thought about using format for it but realized it 
> is PD and it reserves bits in RelocInfo word. On other hand we can add 
> an other 12 (31 - 18 - 1) new relocations without using additional bits.
> 
> In short add new relocation if you need it.
> 
> Thanks,
> Vladimir K
> 
> On 7/24/24 7:40 AM, Andrew Dinn wrote:
>> On 23/07/2024 18:44, Vladimir Kozlov wrote:
>>> I agree. As we discussed on meeting we may use it to patch compressed 
>>> oops/klass code too.
>>
>> Yes, we could potentially do something similar to adjust the shift and 
>> base adjustment employed when generating a narrow oop or klass encode 
>> or decode. However, that would only be useful with certain limits.
>>
>> 1) We can only cater for a change from one narrow-oop/klass base+shift 
>> configuration to another base+shift configuration. Patching code to 
>> switch from narrow oops/klass pointers to full width (or vice versa) 
>> would require adjusting not just the oop/klass load/store but also 
>> other instructions that hard-wire header/payload field sizes and 
>> offsets based on the narrow/full width layout assumptions. Likewise it 
>> would require resizing and repacking objects stored in the CDS mapped 
>> heap section.
>>
>> 2) Even if we restrict ourselves to the case where we retain narrow 
>> oops and simply allow for a change of base and/or shift (i.e. keep the 
>> object layouts the same), that will only work if pointers installed in 
>> mapped CDS heap objects are also rewritten to use the runtime encoding.
>>
>> 3) When generating AOT code for the encode and decode we would have to 
>> allow for the worst case i.e. leave room (nops) for both heap-base 
>> adjustment and shift even when they are not needed at generate time.
>>
>>> We have the same issue with card_table_address. I actually don't know 
>>> why current AOT code works??? May be because it is the same value in 
>>> training and production runs. But we need to fix it too.
>>
>>> It is constant node which is embedded into AddP node:
>>> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp*L96__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-9E0w0Jbo$ 
>>
>> I believe C2 is ok. On AArch64 the C2 back end has an operand called 
>> immByteMapBase that matches any use of byte_map_base as a pointer 
>> constant. A corresponding rule ensures that any attempt to load that 
>> constant pointer is done by calling
>>
>> ?? __ load_byte_map_base()
>>
>> and the macr assembler uses an ExternalAddress when StoreCachedCode is 
>> set.
>>
>>> I marked it only in platform specific code:
>>> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp*L68__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-92hI_Afg$ 
>>
>> I also think there is no mystery as to why this works on AArch64. The 
>> equivalent code in cardTableBarrierSetAssembler_aarch64.cpp also calls
>>
>> ?? __ load_byte_map_base()
>>
>> However, that said, looking at the barrier card table write it seems 
>> the card table shift is another value that the user might decide to 
>> reconfigure between assembly and production runs. The shift is derived 
>> form GCCardTableSize which is a gc global command line option so 
>> susceptible to being reset.
>>
>> We could use an aot_reloc with a different format to tag card table 
>> shift lsr instructions and patch them at shared code load to use the 
>> current runtime GCCardTableSize. Of course, this is not as urgent a 
>> problem as the grain size shift because the card table size only ever 
>> changes thanks to an explicit command line request whereas the grain 
>> size may be changed ergonomically when -Xmx is passed.
>>
>>> Be careful with using `format()` in shared code because it depends on 
>>> platform specific setting `format_width` in `relocInfo_<arch>.hpp` 
>>> (32-bit arm has format_width = 0).
>>
>> Oh, that's a nuisance. I was concerned that I was perhaps using the 
>> wrong reloc model here. Should I be encoding info about what/how to 
>> patch the target instruction(s) using reloc data?
>>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>>
> 

-- 
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 vladimir.kozlov at oracle.com  Wed Jul 31 20:06:41 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 31 Jul 2024 13:06:41 -0700
Subject: [External] : Re: premain: Possible solutions to use runtime G1
 region grain size in AOT code (JDK-8335440)
In-Reply-To: <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
References: <20b5a89a-bb09-4593-b994-bae1cd347963@redhat.com>
 <16d90ab3-80ee-45a1-ad56-790e5c4f08ea@oracle.com>
 <a8aff4d2-1743-44e0-a2bb-73535e0ed75f@redhat.com>
 <f5093cb2-363a-4a41-ba37-1a907287d978@oracle.com>
 <0b9641b5-c6c6-48f7-97b4-4baa9e41ea23@redhat.com>
 <84057040-3d3a-48be-88b3-502205ee6a7d@oracle.com>
 <a231c010-9fbc-485c-8e6e-6e8040524889@redhat.com>
 <b2f3983a-d6fa-4a07-a742-9e0c4a59e88d@oracle.com>
 <5e931bd6-c766-4939-b338-c60594b5e665@redhat.com>
 <5257f86c-2910-45c3-972f-929494fb3267@oracle.com>
 <3db5a5f3-41c3-4cfa-b446-273af5625ac1@redhat.com>
Message-ID: <594256c5-b81d-453d-a4f4-6165b8368a9e@oracle.com>

Very nice. I like it.

Thanks,
Vladimir K

On 7/31/24 8:23 AM, Andrew Dinn wrote:
> I now have a fourth solution to the region resizing problem which I think is probably the nicest looking one so far:
> 
> 
> https://urldefense.com/v3/__https://github.com/adinn/leyden/compare/premain...adinn:leyden:JDK-8335440-load-via-codecache?expand=1__;!!ACWV5N9M2RV99hQ!JI8n2MMyF844NBqR63MhWXggKzPCoouZ8pcwgasAa94iYPRzpcD7af-zSicg5Wm0nv9ZyaF1CpaC74Mqn3g$
> Opinions welcome!
> 
> This version relies on a code cache AOT data area, generated into the initial stubs blob, which stores runtime constants 
> that parameterize operation of AOT code. The AOT data area is initialized with the current runtime constants immediately 
> after universe init. AOT code loads the constants indirectly via the region base address rather than embedding them into 
> instructions. Non-AOT code can continue to use these constants as immediate values.
> 
> With this patch I have included the region grain size shift and the card table shift in the data area. So, this patch 
> ensures that AOT code loads both grain shift and card shift counts rather than using immediates. I tested it passing 
> -XX:GCCardSizeInBytes=128 -Xmx4M to a production run and it works fine.
> 
> The only address that needs relocating wit this patch is the AOT data area base. Note that it was useful using this to 
> implement loading of two AOT code parameters as it highlights a general problem that is not face with only one field.
> 
> I decide to register only the base address of the AOT data area with the code cache as a relocatable (external) address 
> because this is more robust than requiring registration of the address of every data field embedded in the AOT data 
> area. However, in order for the AOT cache to be able to relocate loads from the data area they need to be implemented by 
> installing the base address in a register and then adding the offset before executing the load.
> 
> This is fine for stub code where the generator can simply plant a load effective address (lea) of a pointer constant 
> into a register and then add in the offset. However, I know C2 Value optimizations will certainly coalesce a pointer 
> constant load followed by an add to an updated pointer constant load. I think this can also happen with C1 (it doesn't 
> at the moment because in the current C1 code the grain shift load -- at offset 0 -- happens inline, while the card shift 
> load -- at offset 4 -- only happens in a callout to stub code). I fixed this general problem by ensuring that the C1 and 
> C2 back ends detect pointer constants that lie anywhere in the data area address *range*. For (only) those cases the lea 
> is implemenetd by generating a base address load plus offset add.
> 
> It would be nice to be ale to fold the offset into the subsequent load. I'll look into that as a follow-up. Either way, 
> I think this looks like the simplest and most robust solution to ensuring that AOT code is correctly parameterized at 
> runtime. It is particularly nice that it doesn't need any new relocations.
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> 
> On 24/07/2024 20:43, Vladimir Kozlov wrote:
>> Thank you for checking code for card_table_address.
>>
>> ?> Oh, that's a nuisance. I was concerned that I was perhaps using the wrong reloc model here. Should I be encoding info
>> ?> about what/how to patch the target instruction(s) using reloc data?
>>
>> I am currently thinking about adding indication what relocation is pointing on: blob, stubs, external address, string.
>> Currently we are looking through all our address tables in SCCache to find match. Would be nice if we can get this 
>> information from relocation. And I also thought about using format for it but realized it is PD and it reserves bits 
>> in RelocInfo word. On other hand we can add an other 12 (31 - 18 - 1) new relocations without using additional bits.
>>
>> In short add new relocation if you need it.
>>
>> Thanks,
>> Vladimir K
>>
>> On 7/24/24 7:40 AM, Andrew Dinn wrote:
>>> On 23/07/2024 18:44, Vladimir Kozlov wrote:
>>>> I agree. As we discussed on meeting we may use it to patch compressed oops/klass code too.
>>>
>>> Yes, we could potentially do something similar to adjust the shift and base adjustment employed when generating a 
>>> narrow oop or klass encode or decode. However, that would only be useful with certain limits.
>>>
>>> 1) We can only cater for a change from one narrow-oop/klass base+shift configuration to another base+shift 
>>> configuration. Patching code to switch from narrow oops/klass pointers to full width (or vice versa) would require 
>>> adjusting not just the oop/klass load/store but also other instructions that hard-wire header/payload field sizes and 
>>> offsets based on the narrow/full width layout assumptions. Likewise it would require resizing and repacking objects 
>>> stored in the CDS mapped heap section.
>>>
>>> 2) Even if we restrict ourselves to the case where we retain narrow oops and simply allow for a change of base and/or 
>>> shift (i.e. keep the object layouts the same), that will only work if pointers installed in mapped CDS heap objects 
>>> are also rewritten to use the runtime encoding.
>>>
>>> 3) When generating AOT code for the encode and decode we would have to allow for the worst case i.e. leave room 
>>> (nops) for both heap-base adjustment and shift even when they are not needed at generate time.
>>>
>>>> We have the same issue with card_table_address. I actually don't know why current AOT code works??? May be because 
>>>> it is the same value in training and production runs. But we need to fix it too.
>>>
>>>> It is constant node which is embedded into AddP node:
>>>> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp*L96__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-9E0w0Jbo$ 
>>>
>>> I believe C2 is ok. On AArch64 the C2 back end has an operand called immByteMapBase that matches any use of 
>>> byte_map_base as a pointer constant. A corresponding rule ensures that any attempt to load that constant pointer is 
>>> done by calling
>>>
>>> ?? __ load_byte_map_base()
>>>
>>> and the macr assembler uses an ExternalAddress when StoreCachedCode is set.
>>>
>>>> I marked it only in platform specific code:
>>>> https://urldefense.com/v3/__https://github.com/openjdk/leyden/blob/premain/src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp*L68__;Iw!!ACWV5N9M2RV99hQ!LjgTGnmqk1Ez4pzqXuTXAbZZfHhhP9a1zAFdWGz7V59xO3ggQYVrdW3jTlSNYML_SvRN0Ip_HA-92hI_Afg$ 
>>>
>>> I also think there is no mystery as to why this works on AArch64. The equivalent code in 
>>> cardTableBarrierSetAssembler_aarch64.cpp also calls
>>>
>>> ?? __ load_byte_map_base()
>>>
>>> However, that said, looking at the barrier card table write it seems the card table shift is another value that the 
>>> user might decide to reconfigure between assembly and production runs. The shift is derived form GCCardTableSize 
>>> which is a gc global command line option so susceptible to being reset.
>>>
>>> We could use an aot_reloc with a different format to tag card table shift lsr instructions and patch them at shared 
>>> code load to use the current runtime GCCardTableSize. Of course, this is not as urgent a problem as the grain size 
>>> shift because the card table size only ever changes thanks to an explicit command line request whereas the grain size 
>>> may be changed ergonomically when -Xmx is passed.
>>>
>>>> Be careful with using `format()` in shared code because it depends on platform specific setting `format_width` in 
>>>> `relocInfo_<arch>.hpp` (32-bit arm has format_width = 0).
>>>
>>> Oh, that's a nuisance. I was concerned that I was perhaps using the wrong reloc model here. Should I be encoding info 
>>> about what/how to patch the target instruction(s) using reloc data?
>>>
>>> regards,
>>>
>>>
>>> Andrew Dinn
>>> -----------
>>>
>>
>