From fjiang at openjdk.org  Sun Dec  1 01:00:45 2024
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sun, 1 Dec 2024 01:00:45 GMT
Subject: RFR: 8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro
 assembler routines [v2]
In-Reply-To: <WjHDBUgEpgAouMfDck9qBk6D0QLeUyce8D9TA7lJazs=.05f1c990-1bba-4fdb-8984-5a65aa6732e8@github.com>
References: <Nf6LWOrVeOqPbXng9e8ORnascav3jFbD-g_Amw4_Nq8=.7dc51016-5883-41ef-8c16-159d35629bae@github.com>
 <WjHDBUgEpgAouMfDck9qBk6D0QLeUyce8D9TA7lJazs=.05f1c990-1bba-4fdb-8984-5a65aa6732e8@github.com>
Message-ID: <3_gOeH8VWJffgsUB5sKaqbnm3WinDAl-f-eOYHYNkms=.e76f1205-b377-4efe-98e2-52abd2964a2a@github.com>

On Fri, 29 Nov 2024 09:56:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> This is a further step after https://bugs.openjdk.org/browse/JDK-8345110.
>> `revb_h_h_u` and `revb_h_w_u` assembler routines are mainly used to change byte-ordering for one halfword and two halfwords respectively. But the names don't look obvious and the callsites will emit more instructions when Zbb is not available (6 and 14 instructions respectively).
>> 
>> Since we don't have instructions like aarch64 `rev32` or `rev16`, seems more reasonable for us to do the byte-ordering while loading the bytes for these callsites, which also results in less instructions. Similar approach is taken for other places in riscv [1] and other ports like arm [2]. This also renames `revb_w` into `revbw` so that we are more consistent in naming with integer instructions that manipulate 32-bit values like `addiw`.
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L1625
>> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/templateTable_arm.cpp#L756
>> 
>> Testing on linux-riscv64 platform.
>> - [x] tier1 (release)
>> - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Thanks for the cleanup!

-------------

Marked as reviewed by fjiang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22452#pullrequestreview-2471286217

From tanksherman27 at gmail.com  Sun Dec  1 07:55:30 2024
From: tanksherman27 at gmail.com (Julian Waters)
Date: Sun, 1 Dec 2024 15:55:30 +0800
Subject: Poisoning in HotSpot
In-Reply-To: <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
Message-ID: <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>

This seems to change the forbidden interface, which by itself is ok,
but I have some questions

1. Changing from signature to a name might make the forbidden function
less specific, as information on exactly which function is forbidden
is lost. Would this create problems in the event that another function
with the same name but different signature which is not forbidden is
called?
2. ALLOW_C_FUNCTION used to take a statement, changing it to a call
expression would mean every use site would have to change as well.
Many uses of the macro also use qualified names as well. There's also
the VC specific warning disable in compilerWarnings, which I'm not
sure why it was there in the first place when FORBID_C_FUNCTION does
nothing on VC: https://github.com/openjdk/jdk/blob/28ae281b42cd00f471e275db544a5d23a42df59c/src/hotspot/share/utilities/compilerWarnings_visCPP.hpp#L64
Now that ALLOW_C_FUNCTION takes an expression, I don't think that same
warning disable can be done, would that cause issues for
ALLOW_C_FUNCTION when VC is the compiler?
3. None of the big 3 compilers inline lambdas by default, only when
optimizations are enabled. In practice this means slowdebug HotSpot
will have the wrapper lambda in the final assembly instead of a direct
call to the C library code. I don't know if this issue is a deal
breaker

In any case I tried again after seeing the new example, but using
separate macros to handle the permitted namespace and the actual
forbidding of the function itself. I used the older style signature
based forbidding rather than the new name based solution (Due to
concerns over #1), but I included a toggle to switch between name
based and signature based variants anyway, so a comparison between the
2 can easily be made. Rather than ALLOW_C_FUNCTION this example
directly does permitted::symbol, the meaning of which is also rather
clear

https://godbolt.org/z/hdhrh5eev

best regards,
Julian


On Sun, Dec 1, 2024 at 3:56?AM Kim Barrett <kim.barrett at oracle.com> wrote:
>
> On 11/30/24 2:31 PM, Julian Waters wrote:
> > VC returns:
> >
> > <source>(21): error C2668: 'malloc': ambiguous call to overloaded function
> > Z:/compilers/windows-kits-10/include/10.0.22621.0/ucrt\corecrt_malloc.h(101):
> > note: could be 'void *malloc(size_t)'
> > <source>(18): note: or       'void *forbidden::malloc(size_t) noexcept'
> > <source>(21): note: while trying to match the argument list '(size_t)'
> > Compiler returned: 2
> >
> > While clang returns:
> >
> >
> > <source>:21:17: error: call to 'malloc' is ambiguous
> >     21 |     void *ptr = malloc(size_t{1});
> >        |                 ^~~~~~
> > /usr/include/stdlib.h:540:14: note: candidate function
> >    540 | extern void *malloc (size_t __size) __THROW __attribute_malloc__
> >        |              ^
> > <source>:18:25: note: candidate function has been explicitly deleted
> >     18 | FORBID_C_FUNCTION(void *malloc(size_t), "use os::malloc")
> >        |                         ^
> > 1 error generated.
> > Compiler returned: 1
> >
> > https://urldefense.com/v3/__https://godbolt.org/z/zbfPzoz54__;!!ACWV5N9M2RV99hQ!PeGhd4cAnGh4EmOWTWIiolLTwAfE11a3ZrFkFy0zSVTsMbsdcWDRAgZH9kvoQS7zYkGsp7g_SNSVg3VUsO71JgIx$
> >
> > I managed to put in an override system to allow C Standard library
> > methods to be used when they are really needed, but unfortunately the
> > method body of the forwarding method that calls the actual C library
> > code is still defined in a rather clunky way
> I've been working on this too. Here's what I've come up with, which I
> think is
> significantly simpler, yet appears to work well.
>
> No clunky forwarding mechanism needed. And no metaprogramming.
>
> I think this might just be what we're looking for. The error messages are
> about ambiguity, but they all list the candidates, and with appropriate
> naming
> there's plenty of information provided.
>
> ----- begin example -----
>
> void* frob(unsigned);
>
> namespace forbidden_functions_support {
> struct Forbidden {};
> }
>
> // name must be unqualified.
> #define FORBID_C_FUNCTION(name)                         \
>    namespace forbidden_functions_support {               \
>    using ::name;                                         \
>    }                                                     \
>    inline namespace forbidden_functions {                \
>    forbidden_functions_support::Forbidden name{};        \
>    }
>
> // name and references in expression must be unqualified.
> #define ALLOW_C_FUNCTION(name, expression) \
>    ([&]() { using forbidden_functions_support::name; return
> (expression); }())
>
> FORBID_C_FUNCTION(frob)
>
> // no error, calls ::frob.
> // name and expr ref must be unqualified.
> void* good_frob(unsigned x) {
>    return ALLOW_C_FUNCTION(frob, frob(x));
> }
>
> // demonstrate error for unqualified call.
> #if 1 // change to 0 to avoid error
> void* bad_frob1(unsigned x) {
>    return frob(x);
> }
> #endif
>
> // demonstrate error for qualified call.
> #if 1 // change to 0 to avoid error
> void* bad_frob2(unsigned x) {
>    return ::frob(x);
> }
> #endif
>
> /*
>
> For good_frob, all 3 of gcc, clang, and msvc generate a direct call to frob.
>
> gcc error message:
>
> poison.cpp: In function ?void* bad_frob(unsigned int)?:
> poison.cpp:25:10: error: reference to ?frob? is ambiguous
>     25 |   return frob(x);
>        |          ^~~~
> poison.cpp:16:19: note: candidates are:
> ?forbidden_functions_support::Forbidden forbidden_functions::frob?
>     16 | FORBID_C_FUNCTION(frob)
>        |                   ^~~~
> poison.cpp:10:44: note: in definition of macro ?FORBID_C_FUNCTION?
>     10 |     forbidden_functions_support::Forbidden name{}; \
>        |                                            ^~~~
> poison.cpp:1:7: note:                 ?void* frob(unsigned int)?
>      1 | void* frob(unsigned);
>        |       ^~~~
>
> clang error message:
>
> <source>:31:10: error: reference to 'frob' is ambiguous
>     31 |   return frob(x);
>        |          ^
> <source>:1:7: note: candidate found by name lookup is 'frob'
>      1 | void* frob(unsigned);
>        |       ^
> <source>:20:19: note: candidate found by name lookup is
> 'forbidden_functions::frob'
>     20 | FORBID_C_FUNCTION(frob)
>        |                   ^
>
> msvc error message:
>
> <source>(31): error C2872: 'frob': ambiguous symbol
> <source>(1): note: could be 'void *frob(unsigned int)'
> <source>(20): note: or 'forbidden_functions_support::Forbidden
> forbidden_functions::frob'
>
> */
>
>

From kim.barrett at oracle.com  Sun Dec  1 12:35:37 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sun, 1 Dec 2024 07:35:37 -0500
Subject: Poisoning in HotSpot
In-Reply-To: <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
 <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
Message-ID: <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>

On 12/1/24 2:55 AM, Julian Waters wrote:
> This seems to change the forbidden interface, which by itself is ok,
> but I have some questions

Changing the syntax also doesn't bother me. I've always expected that if 
the underlying mechanism got changed then the usage syntax might need to 
change. There aren't that many uses (there really shouldn't be lots of 
"allows"). I think there are currently ~35 allows?

> 1. Changing from signature to a name might make the forbidden function
> less specific, as information on exactly which function is forbidden
> is lost. Would this create problems in the event that another function
> with the same name but different signature which is not forbidden is
> called?
The purpose of this mechanism is to prevent the (non-casual) use of 
certain C
library functions.? C doesn't support overloading.? So different 
signatures is
not an issue.

It also doesn't matter, since we're manipulating name lookup. If there were
two overloads of malloc (or frob, in my example), the forbidding still 
blocks
access and the permitting just has to call with the proper arguments. That's
also a reason to *not* base the forbidding declaration on the function being
blocked. It can be anything, and making it a deleted and deprecated function
isn't useful. Mine works fine even if there are multiple overloaded
declarations of the global frob function.

> 2. ALLOW_C_FUNCTION used to take a statement, changing it to a call
> expression would mean every use site would have to change as well.
> Many uses of the macro also use qualified names as well.
Again, the syntax change doesn't bother me.

The statement-based syntax for the old ALLOW_C_FUNCTION is a matter of 
history
and the mechanism used to implement the feature.? The implementation 
involved
setting up a surrounding pragma context, which required a statement.? At 
that
time I had not yet realized that lambdas provide some of the functionality
needed to be expression-based while being able to establish such a 
surrounding
pragma context.? (gcc supports statements and declarations in expressions as
an extension.? lambda provides a portable mechanism for doing that.)? Had I
realized that at the time, I would have made ALLOW_C_FUNCTION 
expression-based.

>   There's also
> the VC specific warning disable in compilerWarnings, which I'm not
> sure why it was there in the first place when FORBID_C_FUNCTION does
> nothing on VC:https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/28ae281b42cd00f471e275db544a5d23a42df59c/src/hotspot/share/utilities/compilerWarnings_visCPP.hpp*L64__;Iw!!ACWV5N9M2RV99hQ!L0gUwZ8rkVwClErEUKrf4NKjn2-hjhuJu4_a1D6pE2GMOOc8KLuxs31FpxcObtQDkzbcsTmx25hpInegCuhgUM3C$ 
> Now that ALLOW_C_FUNCTION takes an expression, I don't think that same
> warning disable can be done, would that cause issues for
> ALLOW_C_FUNCTION when VC is the compiler?
The comment about the Windows definition of ALLOW_C_FUNCTIONS discusses 
why it
exists. At the time, it seemed like it might be useful for suppressing
deprecation warnings from other sources, such as the "security" warnings and
from _CRT_DECLARE_NONSTDC_NAMES. But we ultimately decided to just globally
use the warning suppression macros for those, so didn't need to use the 
ALLOW
macro for that purpose. So the current definition doesn't really serve any
purpose.

> 3. None of the big 3 compilers inline lambdas by default, only when
> optimizations are enabled. In practice this means slowdebug HotSpot
> will have the wrapper lambda in the final assembly instead of a direct
> call to the C library code. I don't know if this issue is a deal
> breaker
Regarding non-inlining of lambdas in unoptimized code, I don't really 
care all
that much. If it's *really* an issue, `__attribute__((always_inline))` or
`[[gnu::always_inline]]` can help. But the approach of requiring the use 
of a
specially qualified name instead of a context macro does have some 
appeal. But
I think I'd want a less convenient name. The point of this mechanism is to
make it intentionally inconvenient and obvious that the blockade is being
bypassed, because it shouldn't be done casually or "quietly".
>
> In any case I tried again after seeing the new example, but using
> separate macros to handle the permitted namespace and the actual
> forbidding of the function itself. I used the older style signature
> based forbidding rather than the new name based solution (Due to
> concerns over #1), but I included a toggle to switch between name
> based and signature based variants anyway, so a comparison between the
> 2 can easily be made. Rather than ALLOW_C_FUNCTION this example
> directly does permitted::symbol, the meaning of which is also rather
> clear
>
> https://urldefense.com/v3/__https://godbolt.org/z/hdhrh5eev__;!!ACWV5N9M2RV99hQ!L0gUwZ8rkVwClErEUKrf4NKjn2-hjhuJu4_a1D6pE2GMOOc8KLuxs31FpxcObtQDkzbcsTmx25hpInegCsNpF1Dt$ 
I think separate macros for registering the bypass and registering the
forbidding is a mistake, and just has the potential for accidental misuse.
The bypass *must* be registered first, and there's no point to it 
without the
forbidding, so one macro is better.

I've also dropped the "alternative" string. It doesn't do anything useful in
the code. Depending on which compiler is used, it may or may not appear 
in the
error message. I think just a comment at the point of forbidding would
suffice, and can be more extensive than one would want in a string, if/when
that's warranted. Anyone who is encountering a failure clearly has the 
source
code available, and the error messages from all three compilers seems to
provide information about where in the source to look.

How about this:

void* frob(unsigned);
void* frob(unsigned, unsigned);

// name must be unqualified.
#define FORBID_C_FUNCTION(name)???????????????????????????????? \
 ? namespace permit_forbidden_functions { using ::name; }??????? \
 ? inline namespace forbidden_functions { const int name = 0; }? \
 ? /* */

void* permit_frob(unsigned x) {
 ? return permit_forbidden_functions::frob(x);
}

void* permit_frob(unsigned x, unsigned y) {
 ? return permit_forbidden_functions::frob(x, y);
}

// demonstrate error for unqualified call.
#if 0 // change to 1 to trigger error
void* bad_frob1(unsigned x) {
 ? return frob(x);
}
#endif

// demonstrate error for qualified call.
#if 0 // change to 1 to trigger error
void* bad_frob2(unsigned x) {
 ? return ::frob(x);
}
#endif
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241201/4847480e/attachment-0001.htm>

From kim.barrett at oracle.com  Sun Dec  1 15:16:10 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sun, 1 Dec 2024 10:16:10 -0500
Subject: Poisoning in HotSpot
In-Reply-To: <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
 <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
 <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>
Message-ID: <e6474fe1-8f0d-494f-b06b-31d816f26c86@oracle.com>

On 12/1/24 7:35 AM, Kim Barrett wrote:
>
> How about this: [code snipped]
>

I decided I like this enough to work on implementing it.? A couple of 
points.

There are several uses of ALLOW_C_FUNCTION for functions that aren't
forbidden. The new mechanism prevents that from happening. Trying to 
reference
permit_forbidden_function::<name> without an in-scope
FORBID_C_FUNCTION(<name>) will fail. That seems like a good thing.

I'm adding two macros, FORBID_C_FUNCTION and FORBID_C_FUNCTION_ALWAYS.? The
latter doesn't provide a permit alias.? You're just never supposed to 
use it.
We have several like that, and the old mechanism didn't support such a
distinction.

There are uses of FORBID_C_FUNCTION in shared code for functions that might
not be declared. For example, get_current_dir_name is documented as a GNU
extension. I'm guessing it's not available on Windows.? That won't work with
the new mechanism.? That seems like probably a good thing too. Though it
might force forbidding in some non-obvious place.? Worse, it could force
inclusion of some file for the sake of a declaration that you are then going
to forbid.? Though you could forward declare such a function.


From kim.barrett at oracle.com  Sun Dec  1 16:13:43 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sun, 1 Dec 2024 11:13:43 -0500
Subject: Poisoning in HotSpot
In-Reply-To: <e6474fe1-8f0d-494f-b06b-31d816f26c86@oracle.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
 <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
 <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>
 <e6474fe1-8f0d-494f-b06b-31d816f26c86@oracle.com>
Message-ID: <bbc1d875-0a34-4789-b96b-e5fe14cc6b6a@oracle.com>

On 12/1/24 10:16 AM, Kim Barrett wrote:
> On 12/1/24 7:35 AM, Kim Barrett wrote:
>>
>> How about this: [code snipped]
>>
>
> I decided I like this enough to work on implementing it.

Unfortunately, there's a potentially fatal problem with this whole approach.
We don't have a mechanism for turning it off over some context. We need this
because there are files that ere not ours that are subject to our headers.
Consider gtest, for example. Apparently there are *lots* of calls to 
sprintf,
for example.

I've not yet come up with a way for this new mechanism to deal with that.

I've also not figured out how things are working now.? Why don't we get lots
of warnings for those calls to sprintf now?? I would have guessed there was
some suppression of -Wattribute-warning somewhere, but I'm not finding such.


From kbarrett at openjdk.org  Sun Dec  1 16:29:12 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 1 Dec 2024 16:29:12 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code
Message-ID: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>

Please review this change to remove -Wzero-as-null-pointer-constant warnings
in s390 code.

Most places involve just changing literal 0 to nullptr.

Removed a dead return after ShouldNotReachHere() that is no longer needed.

Testing:
GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
I don't have the capability to run tests for this platform, so hoping someone
from the aix-ppc maintainers can do more testing.

-------------

Commit messages:
 - simple s390 fixes

Changes: https://git.openjdk.org/jdk/pull/22469/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345273
  Stats: 14 lines in 6 files changed: 0 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/22469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22469/head:pull/22469

PR: https://git.openjdk.org/jdk/pull/22469

From david.holmes at oracle.com  Mon Dec  2 00:09:57 2024
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 2 Dec 2024 10:09:57 +1000
Subject: Poisoning in HotSpot
In-Reply-To: <bbc1d875-0a34-4789-b96b-e5fe14cc6b6a@oracle.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
 <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
 <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>
 <e6474fe1-8f0d-494f-b06b-31d816f26c86@oracle.com>
 <bbc1d875-0a34-4789-b96b-e5fe14cc6b6a@oracle.com>
Message-ID: <337d3e32-57c0-45b7-81bb-6ce6f8174ad2@oracle.com>

On 2/12/2024 2:13 am, Kim Barrett wrote:
> On 12/1/24 10:16 AM, Kim Barrett wrote:
>> On 12/1/24 7:35 AM, Kim Barrett wrote:
>>>
>>> How about this: [code snipped]
>>>
>>
>> I decided I like this enough to work on implementing it.
> 
> Unfortunately, there's a potentially fatal problem with this whole 
> approach.
> We don't have a mechanism for turning it off over some context. We need 
> this
> because there are files that ere not ours that are subject to our headers.
> Consider gtest, for example. Apparently there are *lots* of calls to 
> sprintf,
> for example.
> 
> I've not yet come up with a way for this new mechanism to deal with that.

Somewhat crude but couldn't gtests #define USING_GTEST before including 
our headers and then we could make the forbidden stuff conditional on 
ifndef USING_GTEST. ??

David

> I've also not figured out how things are working now.? Why don't we get 
> lots
> of warnings for those calls to sprintf now?? I would have guessed there was
> some suppression of -Wattribute-warning somewhere, but I'm not finding 
> such.
> 


From dholmes at openjdk.org  Mon Dec  2 00:14:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 00:14:48 GMT
Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and
 Thread.vthread_pollers diagnostic commands [v3]
In-Reply-To: <dgfsBaEGYL-iO-CzwDdnejH_dV6-lj-1T2t0Vpuq_Nw=.4b4ff10e-810e-4f6d-abbc-10d9e8d9665b@github.com>
References: <AIoBekqlY5FjErxaI4obOui5OyvhALPos9LwGM9SFjo=.d5f602e3-810d-4c04-9c7c-d6fe7b962265@github.com>
 <dgfsBaEGYL-iO-CzwDdnejH_dV6-lj-1T2t0Vpuq_Nw=.4b4ff10e-810e-4f6d-abbc-10d9e8d9665b@github.com>
Message-ID: <T_kvqLJgHddrBLG5YFlk88puoW1f4c8iKHg92XkoI48=.afc835ca-64e4-46f0-af60-21fcd375fd33@github.com>

On Fri, 29 Nov 2024 11:12:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adds `jcmd <pid> Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd <pid> Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations.
>> 
>> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort.
>> 
>> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8337199
>  - VThread*Dcmd::execute changes to use helper function
>  - Improve regex for matching poller String representation
>  - Improve vthread_pollers output
>  - Merge branch 'master' into JDK-8337199
>  - Initial commit

LGTM! Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22414#pullrequestreview-2471545814

From fyang at openjdk.org  Mon Dec  2 00:19:42 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 2 Dec 2024 00:19:42 GMT
Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg [v2]
In-Reply-To: <y0iGL_3a0Kc0sIJzTeyDMQ_mBVN4w5RxbCbnOQtxgoo=.68fbc866-7b5f-4e79-b379-38c35ecaf605@github.com>
References: <gFS_7r0eGaUJhR9S-OvqoaS83n3klR8Qd3kWNLfCPh8=.b6ebf62d-8c29-4eab-b2eb-2b1226d3e1b9@github.com>
 <y0iGL_3a0Kc0sIJzTeyDMQ_mBVN4w5RxbCbnOQtxgoo=.68fbc866-7b5f-4e79-b379-38c35ecaf605@github.com>
Message-ID: <4BevhrlYJCdNP3JNHxGghVK_vsFbKxa5okiBIBNzuUA=.2e0561e2-45f5-48d2-bd8a-b2cd951b0736@github.com>

On Fri, 29 Nov 2024 14:01:53 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests to some of the base cases.
>> Focusing on the cases when we pass in same register in some of the argument. (variant 0,1,2,3)
>> 
>> Note: Google Test filter = *RiscV.cmpxchg*
>> [==========] Running 4 tests from 1 test suite.
>> [----------] Global test environment set-up.
>> [----------] 4 tests from RiscV
>> [ RUN      ] RiscV.cmpxchg_int64_plain_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_plain_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_plain_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_plain_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20806 ms total)
>> 
>> [----------] Global test environment tear-down
>> [==========] 4 tests from 1 test suite ran. (20809 ms total)
>> [  PASSED  ] 4 tests.
>> 
>> 
>> Executed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZacas`
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CMF barrier

Updated change looks good. Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22437#pullrequestreview-2471547223

From dholmes at openjdk.org  Mon Dec  2 00:24:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 00:24:38 GMT
Subject: RFR: 8344609: Check ResourceMark nesting when allocating a
 GrowableArray on an alternative ResourceArea [v2]
In-Reply-To: <4UNqb8VvjoEoa3nUzqnQmqHhGebDJQ2qHi8ZrsSr9hA=.4fe7c96d-2199-4236-b43c-9d0ec7efc616@github.com>
References: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
 <4UNqb8VvjoEoa3nUzqnQmqHhGebDJQ2qHi8ZrsSr9hA=.4fe7c96d-2199-4236-b43c-9d0ec7efc616@github.com>
Message-ID: <KjgjA9ZmDHZv9seqghi99ZZj7pD8GcA3n5icl9Zb8lA=.7d850807-c710-4cef-8ac7-1586f916d4b2@github.com>

On Wed, 27 Nov 2024 11:00:17 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`.
>> 
>> The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085).
>> 
>> More testing is pending.
>
> Richard Reingruber has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add parentheses

Seems reasonable.

What testing did you do to see if the assert fires on existing code?

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22269#pullrequestreview-2471549274

From fyang at openjdk.org  Mon Dec  2 00:55:36 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 2 Dec 2024 00:55:36 GMT
Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v2]
In-Reply-To: <Dwi-JYwCPmRCteN7gXPitLaXUX8E_LS8bsoQmtVMtrk=.bf9962f2-e298-4e12-8c43-e9ac52dacace@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
 <Dwi-JYwCPmRCteN7gXPitLaXUX8E_LS8bsoQmtVMtrk=.bf9962f2-e298-4e12-8c43-e9ac52dacace@github.com>
Message-ID: <SsSno4mekJV97Jz0rBvuCTDCmz_jnN5DE0blLGGrzcs=.2493056b-4464-43ca-bef9-c4c71b74219d@github.com>

On Fri, 29 Nov 2024 14:01:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned narrow cmpxchg.
>> 
>> 
>> Note: Google Test filter = *RiscV*
>> [==========] Running 5 tests from 1 test suite.
>> [----------] Global test environment set-up.
>> [----------] 5 tests from RiscV
>> ...
>> [ RUN      ] RiscV.cmpxchg_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms)
>> [----------] 5 tests from RiscV (20831 ms total)
>> 
>> [----------] Global test environment tear-down
>> [==========] 5 tests from 1 test suite ran. (20834 ms total)
>> [  PASSED  ] 5 tests.
>> 
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CMF barrier

Thanks.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22445#pullrequestreview-2471563946

From amitkumar at openjdk.org  Mon Dec  2 04:42:42 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 2 Dec 2024 04:42:42 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code
In-Reply-To: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
Message-ID: <lJoRc1rvD-tI4NeDqtgrdZZxp9tPmWSAWhDEMDjechE=.0418abdd-a37e-4da9-932a-1c827b156492@github.com>

On Sun, 1 Dec 2024 16:23:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in s390 code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

hi @kimbarrett, 

I tried to build it on s390x with these changes: 

diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
index 57654514eb6..ce3077e7d38 100644
--- a/make/autoconf/flags-cflags.m4
+++ b/make/autoconf/flags-cflags.m4
@@ -448,7 +448,7 @@ AC_DEFUN([FLAGS_SETUP_CFLAGS],
   CC="$CC_OLD"
   CXX="$CXX_OLD"
   CFLAGS="$CFLAGS_OLD"
-  CXXFLAGS="$CXXFLAGS_OLD"
+  CXXFLAGS="$CXXFLAGS_OLD  -Wzero-as-null-pointer-constant"
 ])


is that correct way to test it ? 

I got couple of build warnings, good thing is that none of them are in s390x code. I am attaching build.log file. 

[build.log](https://github.com/user-attachments/files/17972560/build.log)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22469#issuecomment-2510564427

From duke at openjdk.org  Mon Dec  2 04:55:15 2024
From: duke at openjdk.org (Manjunath S Matti.)
Date: Mon, 2 Dec 2024 04:55:15 GMT
Subject: RFR: 8335367: [s390] Add support for load immediate on condition
 instructions. [v3]
In-Reply-To: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com>
References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com>
Message-ID: <1-wsaZp9KA0i0Vgvft2lMWPQVnKXvDuM90VSDrYZl4A=.800872c6-5ec4-4a17-97e1-e55514e3b8a3@github.com>

> Add support for load immediate on condition instructions.

Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments from Lutz.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22058/files
  - new: https://git.openjdk.org/jdk/pull/22058/files/31709a7d..9f5f3967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22058&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22058&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22058.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22058/head:pull/22058

PR: https://git.openjdk.org/jdk/pull/22058

From kbarrett at openjdk.org  Mon Dec  2 08:53:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 2 Dec 2024 08:53:38 GMT
Subject: RFR: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
Message-ID: <n6ZXzEEWxZl7kI2GytuPxuwzwu6T42dVZeSGab_apQ8=.854858fd-ec7d-4507-aa2f-0d5e1bda36a1@github.com>

On Sun, 1 Dec 2024 07:54:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how NULL_WORD is defined.  Instead of being a
> macro whose definition is in compiler-specific files with a conditionally
> defined expansion, it is now a simple integral constant with a single shared
> definition.
> 
> Testing: mach5 tier 1-5, GHA sanity tests.

attempting to poke skara to notice this PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22468#issuecomment-2510918136

From dholmes at openjdk.org  Mon Dec  2 09:08:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 09:08:38 GMT
Subject: RFR: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
Message-ID: <kwjW9tKLj9OYOb_2kszcwJLuyHmrxMdfGeOozLXMIn8=.7479feb8-1871-4589-98fa-1f30e9445bfd@github.com>

On Sun, 1 Dec 2024 07:54:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how NULL_WORD is defined.  Instead of being a
> macro whose definition is in compiler-specific files with a conditionally
> defined expansion, it is now a simple integral constant with a single shared
> definition.
> 
> Testing: mach5 tier 1-5, GHA sanity tests.

As long as all compilers are happy with this then it is nice to see it simplified. What was the obstacle to doing this sooner?

src/hotspot/share/utilities/globalDefinitions.hpp line 563:

> 561: const jfloat max_jfloat = jfloat_cast(max_jintFloat);
> 562: 
> 563: // A named constant for the integral representation of a Java null.

Some commentary on when/where/why to use this would be good. I see it being used in a lot of places related to oops (exceptions, VMResult) but other uses are not obviously (to me) Java object related.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22468#pullrequestreview-2472119703
PR Review Comment: https://git.openjdk.org/jdk/pull/22468#discussion_r1865475723

From rrich at openjdk.org  Mon Dec  2 09:13:41 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 2 Dec 2024 09:13:41 GMT
Subject: RFR: 8344609: Check ResourceMark nesting when allocating a
 GrowableArray on an alternative ResourceArea [v2]
In-Reply-To: <KjgjA9ZmDHZv9seqghi99ZZj7pD8GcA3n5icl9Zb8lA=.7d850807-c710-4cef-8ac7-1586f916d4b2@github.com>
References: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
 <4UNqb8VvjoEoa3nUzqnQmqHhGebDJQ2qHi8ZrsSr9hA=.4fe7c96d-2199-4236-b43c-9d0ec7efc616@github.com>
 <KjgjA9ZmDHZv9seqghi99ZZj7pD8GcA3n5icl9Zb8lA=.7d850807-c710-4cef-8ac7-1586f916d4b2@github.com>
Message-ID: <y-G1DkZJY7_voAMBHY80ILsI3THMAPlv6PHHEr--bsU=.299db41e-1cad-4a31-a9a8-efd8a37c6b1f@github.com>

On Mon, 2 Dec 2024 00:22:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Seems reasonable.

Thanks for having a look at it.

> What testing did you do to see if the assert fires on existing code?

I forgot to update the pr description, sorry.
I've added the change about a week ago to our CI testing where we test head of jdk with and without changes from the team currently in review.
We do tier 1-4 of hotspot and jdk tests. All of langtools and jaxp. Renaissance Suite and SAP specific tests.
The testing is done nightly on the main platforms and also on Linux/PPC64le and AIX.

I had no positves from the assert except for the ctw tests on ppc64 also mentioned in the JBS issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22269#issuecomment-2510965033

From mli at openjdk.org  Mon Dec  2 10:05:11 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 10:05:11 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less multiplication
Message-ID: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>

Hi,
Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
Thanks!


## Test
test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
test/jdk/java/util/zip/TestCRC32.java

-------------

Commit messages:
 - vclmul crc32: initial commit, MaxVectorSize == 32 & 16

Changes: https://git.openjdk.org/jdk/pull/22475/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22475&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339910
  Stats: 380 lines in 7 files changed: 377 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22475/head:pull/22475

PR: https://git.openjdk.org/jdk/pull/22475

From fyang at openjdk.org  Mon Dec  2 10:27:44 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 2 Dec 2024 10:27:44 GMT
Subject: Integrated: 8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro
 assembler routines
In-Reply-To: <Nf6LWOrVeOqPbXng9e8ORnascav3jFbD-g_Amw4_Nq8=.7dc51016-5883-41ef-8c16-159d35629bae@github.com>
References: <Nf6LWOrVeOqPbXng9e8ORnascav3jFbD-g_Amw4_Nq8=.7dc51016-5883-41ef-8c16-159d35629bae@github.com>
Message-ID: <pgbFgoh5kSU60xfYC6k83xHVpxZPG9jWbLS_2SY4Uco=.184b196b-2ee6-4d15-9e10-39ac2b37a7db@github.com>

On Fri, 29 Nov 2024 08:01:09 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please consider this cleanup change.
> 
> This is a further step after https://bugs.openjdk.org/browse/JDK-8345110.
> `revb_h_h_u` and `revb_h_w_u` assembler routines are mainly used to change byte-ordering for one halfword and two halfwords respectively. But the names don't look obvious and the callsites will emit more instructions when Zbb is not available (6 and 14 instructions respectively).
> 
> Since we don't have instructions like aarch64 `rev32` or `rev16`, seems more reasonable for us to do the byte-ordering while loading the bytes for these callsites, which also results in less instructions. Similar approach is taken for other places in riscv [1] and other ports like arm [2]. This also renames `revb_w` into `revbw` so that we are more consistent in naming with integer instructions that manipulate 32-bit values like `addiw`.
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/templateTable_riscv.cpp#L1625
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/arm/templateTable_arm.cpp#L756
> 
> Testing on linux-riscv64 platform.
> - [x] tier1 (release)
> - [x] non-trivial benchmark workloads like Dacapo, SpecJBB, Renaissance (release)

This pull request has now been integrated.

Changeset: dfcbfb5a
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfcbfb5a410592c6d5e54b4f9c1756853683414d
Stats:     81 lines in 3 files changed: 14 ins; 38 del; 29 mod

8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro assembler routines

Reviewed-by: rehn, fjiang

-------------

PR: https://git.openjdk.org/jdk/pull/22452

From fyang at openjdk.org  Mon Dec  2 10:27:43 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 2 Dec 2024 10:27:43 GMT
Subject: RFR: 8345236: RISC-V: Remove revb_h_h_u and revb_h_w_u macro
 assembler routines [v2]
In-Reply-To: <C3IEcV7dGtJNiHxPlRUj85LIjibfgwZWEiDlyqXciGc=.6544c092-1809-4aeb-8eff-b036e7957965@github.com>
References: <Nf6LWOrVeOqPbXng9e8ORnascav3jFbD-g_Amw4_Nq8=.7dc51016-5883-41ef-8c16-159d35629bae@github.com>
 <WjHDBUgEpgAouMfDck9qBk6D0QLeUyce8D9TA7lJazs=.05f1c990-1bba-4fdb-8984-5a65aa6732e8@github.com>
 <C3IEcV7dGtJNiHxPlRUj85LIjibfgwZWEiDlyqXciGc=.6544c092-1809-4aeb-8eff-b036e7957965@github.com>
Message-ID: <G8bmTBlUgWSkTzR-nMgGapx4IqGsy8stV5L0yS1dbDA=.0c673194-18f6-42e8-8e4e-1d8d714d4326@github.com>

On Fri, 29 Nov 2024 14:01:59 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>
> I'm always in favour of delta negative patches, thanks!

@robehn @feilongjiang : Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22452#issuecomment-2511135274

From adinn at redhat.com  Mon Dec  2 10:29:40 2024
From: adinn at redhat.com (Andrew Dinn)
Date: Mon, 2 Dec 2024 10:29:40 +0000
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas
In-Reply-To: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
References: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
Message-ID: <a12ea7a9-8174-4a29-9353-bb9e7480aece@redhat.com>

Vote: yes

On 27/11/2024 11:26, Stefan Karlsson wrote:
> I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group.
> 
> Axel is a member of Oracle's HotSpot GC team and has been contributing 
> to various parts of the JVM for over two years now.
> 
> Votes are due by 2024-12-11T12:24+01:00.
> 
> Only current Members of the HotSpot Group [1] are eligible
> to vote on this nomination.? Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Stefan Karlsson
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote
> 

-- 
regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


From aph at openjdk.org  Mon Dec  2 11:05:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 11:05:38 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication
In-Reply-To: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
Message-ID: <Q0wQiOPrpFzTk6UegxLiZhwPSP533eoi9Bm4UoMRZeo=.ddda1fc0-f3ba-409c-b1fd-29e08f661032@github.com>

On Mon, 2 Dec 2024 10:00:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
> Thanks!
> 
> 
> ## Test
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
> test/jdk/java/util/zip/TestCRC32.java

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1761:

> 1759:   bind(L_16_bytes_loop);
> 1760:   {
> 1761:     #define CRC32_VCLMUL_FOLD_16_BYTES(vx, vt, vtmp1, vtmp2, vtmp3, vtmp4) \

It makes no sense for this to be a macro, because it's called infrequently. Making it a function would save space.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1833:

> 1831:     vslideup_vi(vy, vtmp1, 1); \
> 1832:     vmv_x_s(tmp2, vtmp3); \
> 1833:     vmv_s_x(vy, tmp2);

Again, not a macro.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1865652614
PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1865653545

From azafari at openjdk.org  Mon Dec  2 11:18:30 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Dec 2024 11:18:30 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v6]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <Fu9joaglEQPRvf6YsmE_pLf3Cy-OQQmp48kwKVNK6m4=.b28a9029-d4af-46b6-9f0b-9c2bf17d638b@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  some fixes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/451b9047..771cb024

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=04-05

  Stats: 13 lines in 4 files changed: 4 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

PR: https://git.openjdk.org/jdk/pull/20425

From mli at openjdk.org  Mon Dec  2 11:45:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 11:45:38 GMT
Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v2]
In-Reply-To: <Dwi-JYwCPmRCteN7gXPitLaXUX8E_LS8bsoQmtVMtrk=.bf9962f2-e298-4e12-8c43-e9ac52dacace@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
 <Dwi-JYwCPmRCteN7gXPitLaXUX8E_LS8bsoQmtVMtrk=.bf9962f2-e298-4e12-8c43-e9ac52dacace@github.com>
Message-ID: <E1lmTXD1jx3baeAqtIo8QfX61M-Z3m-7vVr3PuBnYwY=.bdf840d1-0463-4b25-9cef-b3ba972271f2@github.com>

On Fri, 29 Nov 2024 14:01:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned narrow cmpxchg.
>> 
>> 
>> Note: Google Test filter = *RiscV*
>> [==========] Running 5 tests from 1 test suite.
>> [----------] Global test environment set-up.
>> [----------] 5 tests from RiscV
>> ...
>> [ RUN      ] RiscV.cmpxchg_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms)
>> [----------] 5 tests from RiscV (20831 ms total)
>> 
>> [----------] Global test environment tear-down
>> [==========] 5 tests from 1 test suite ran. (20834 ms total)
>> [  PASSED  ] 5 tests.
>> 
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CMF barrier

Thanks for adding the tests!

The test code looks good. Just some minor comment below.

And one general question, will we consider to add some concurrent tests in the future? Although I don't have a good idea how to implement such tests in a stable way. :)

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 144:

> 142:     data[i] = 121;
> 143:     ret = NarrowCmpxchgTester<TESTSIZE, ASMSIZE>::narrow_cmpxchg((intptr_t)&data[i], 121, 42, /* result */ 67,
> 144:                                                                           -1, -1, -1, false);

Seems we don't need to put these `-1, -1, -1` as the arguments of `NarrowCmpxchgTester::narrow_cmpxchg`, they could be just local variables in `narrow_cmpxchg`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22445#pullrequestreview-2472472430
PR Review Comment: https://git.openjdk.org/jdk/pull/22445#discussion_r1865705023

From kbarrett at openjdk.org  Mon Dec  2 11:49:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 2 Dec 2024 11:49:38 GMT
Subject: RFR: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <kwjW9tKLj9OYOb_2kszcwJLuyHmrxMdfGeOozLXMIn8=.7479feb8-1871-4589-98fa-1f30e9445bfd@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
 <kwjW9tKLj9OYOb_2kszcwJLuyHmrxMdfGeOozLXMIn8=.7479feb8-1871-4589-98fa-1f30e9445bfd@github.com>
Message-ID: <h-m1OJj5cX_xbZL11thF0kOLkzM7Frie8dluwRqB0PM=.b00a6443-bd22-446f-96b7-87631aba6809@github.com>

On Mon, 2 Dec 2024 09:04:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to how NULL_WORD is defined.  Instead of being a
>> macro whose definition is in compiler-specific files with a conditionally
>> defined expansion, it is now a simple integral constant with a single shared
>> definition.
>> 
>> Testing: mach5 tier 1-5, GHA sanity tests.
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 563:
> 
>> 561: const jfloat max_jfloat = jfloat_cast(max_jintFloat);
>> 562: 
>> 563: // A named constant for the integral representation of a Java null.
> 
> Some commentary on when/where/why to use this would be good. I see it being used in a lot of places related to oops (exceptions, VMResult) but other uses are not obviously (to me) Java object related.

I _think_ this change could have been made a long time ago.  But there was messy stuff related to 32bit, and
also maybe Solaris?  It was also hard to tell, because of the conflation with NULL and the various complexities
there.

I think some of the current uses could be classed as abuse, but again, it's hard to know without a little more
clarity in its definition.  I made a couple of attempts at cleaning up usage a while ago, but ended up abandoning
them because of that lack of clarity.  What came out of that was the realization that something like this might
be possible, and would be a useful precursor to usage changes.  That comment is my stake in the ground for
helping to distinguish good uses vs abuse.  I'm planning to revisit uses with that in mind.

The vast majority of uses are in x86/x64 assembly code, where I think it is usually about encoding a Java null
in an instruction.  I've looked at changing how that's done, but the messiness of the definition, crossed with
the 32/64bit issues there, again led me to balk.  Nuking 32bit x86 might reduce the complexity to something
more manageable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22468#discussion_r1865710829

From aph-open at littlepinkcloud.com  Mon Dec  2 11:53:35 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 2 Dec 2024 11:53:35 +0000
Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <r7aXd_kDs21Jf_lfS2rW9ouq4TvxkNaAKIb-81G5Zag=.962b7dd3-9c22-4c5c-ae75-611135626f56@github.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
 <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
 <ANJSrBX7tBlr7E1wuAaUKRe4ba-iLEzoinAILta7o8s=.c075c0c7-e837-40dd-a970-db1b7f205a5b@github.com>
 <r7aXd_kDs21Jf_lfS2rW9ouq4TvxkNaAKIb-81G5Zag=.962b7dd3-9c22-4c5c-ae75-611135626f56@github.com>
Message-ID: <84cbe8d4-df04-432c-b84e-a9ef2f57bfea@littlepinkcloud.com>

On 11/27/24 15:58, Amit Kumar wrote:
> On Wed, 27 Nov 2024 15:48:29 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:
> 
>> Are there any performance figures? Does the change help, or at least do no harm, on s390?
> 
> I do but they don't look interesting.

With the patch you should see this:

-XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:+UseSecondarySupersCache -XX:-UseSecondarySupersTable

Benchmark                                   Mode  Cnt    Score     Error  Units
SecondarySuperCacheInterContention.test     avgt    5  176.328 ?  69.341  ns/op
SecondarySuperCacheInterContention.test:t1  avgt    5  173.024 ?  29.227  ns/op
SecondarySuperCacheInterContention.test:t2  avgt    5  179.633 ? 110.211  ns/op

-XX:TieredStopAtLevel=1

Benchmark                                   Mode  Cnt  Score   Error  Units
SecondarySuperCacheInterContention.test     avgt    5  5.156 ? 0.855  ns/op
SecondarySuperCacheInterContention.test:t1  avgt    5  5.225 ? 1.604  ns/op
SecondarySuperCacheInterContention.test:t2  avgt    5  5.087 ? 0.740  ns/op

assuming you have >1 core. Try also SecondarySuperCacheIntraContention.test

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From mli at openjdk.org  Mon Dec  2 12:01:48 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 12:01:48 GMT
Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg [v2]
In-Reply-To: <y0iGL_3a0Kc0sIJzTeyDMQ_mBVN4w5RxbCbnOQtxgoo=.68fbc866-7b5f-4e79-b379-38c35ecaf605@github.com>
References: <gFS_7r0eGaUJhR9S-OvqoaS83n3klR8Qd3kWNLfCPh8=.b6ebf62d-8c29-4eab-b2eb-2b1226d3e1b9@github.com>
 <y0iGL_3a0Kc0sIJzTeyDMQ_mBVN4w5RxbCbnOQtxgoo=.68fbc866-7b5f-4e79-b379-38c35ecaf605@github.com>
Message-ID: <vCzrP1Q95SiH8PPoY8VQIOTb2xIMnlnrhsET-OvpStY=.34c0b42b-483b-45b4-aa12-84ad8fb08913@github.com>

On Fri, 29 Nov 2024 14:01:53 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests to some of the base cases.
>> Focusing on the cases when we pass in same register in some of the argument. (variant 0,1,2,3)
>> 
>> Note: Google Test filter = *RiscV.cmpxchg*
>> [==========] Running 4 tests from 1 test suite.
>> [----------] Global test environment set-up.
>> [----------] 4 tests from RiscV
>> [ RUN      ] RiscV.cmpxchg_int64_plain_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_plain_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_plain_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_plain_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20806 ms total)
>> 
>> [----------] Global test environment tear-down
>> [==========] 4 tests from 1 test suite ran. (20809 ms total)
>> [  PASSED  ] 4 tests.
>> 
>> 
>> Executed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZacas`
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove CMF barrier

Thanks for adding the tests. Looks good to me.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22437#pullrequestreview-2472504311

From dholmes at openjdk.org  Mon Dec  2 12:02:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 12:02:40 GMT
Subject: RFR: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
Message-ID: <YDbahSY3b1eiw96BP6x5LPYs0C0w7EsYho0SxKJ4j88=.ab1e26b4-bba6-41e1-9470-4d9d23ca577d@github.com>

On Sun, 1 Dec 2024 07:54:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how NULL_WORD is defined.  Instead of being a
> macro whose definition is in compiler-specific files with a conditionally
> defined expansion, it is now a simple integral constant with a single shared
> definition.
> 
> Testing: mach5 tier 1-5, GHA sanity tests.

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22468#pullrequestreview-2472506619

From dholmes at openjdk.org  Mon Dec  2 12:02:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 12:02:42 GMT
Subject: RFR: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <h-m1OJj5cX_xbZL11thF0kOLkzM7Frie8dluwRqB0PM=.b00a6443-bd22-446f-96b7-87631aba6809@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
 <kwjW9tKLj9OYOb_2kszcwJLuyHmrxMdfGeOozLXMIn8=.7479feb8-1871-4589-98fa-1f30e9445bfd@github.com>
 <h-m1OJj5cX_xbZL11thF0kOLkzM7Frie8dluwRqB0PM=.b00a6443-bd22-446f-96b7-87631aba6809@github.com>
Message-ID: <V9OsOmFnbUIQFZQ_nYL28qW_6f9y2-TVE_xUk0ZzvJE=.304c950f-713b-47a8-bf6e-fd79455703de@github.com>

On Mon, 2 Dec 2024 11:47:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions.hpp line 563:
>> 
>>> 561: const jfloat max_jfloat = jfloat_cast(max_jintFloat);
>>> 562: 
>>> 563: // A named constant for the integral representation of a Java null.
>> 
>> Some commentary on when/where/why to use this would be good. I see it being used in a lot of places related to oops (exceptions, VMResult) but other uses are not obviously (to me) Java object related.
>
> I _think_ this change could have been made a long time ago.  But there was messy stuff related to 32bit, and
> also maybe Solaris?  It was also hard to tell, because of the conflation with NULL and the various complexities
> there.
> 
> I think some of the current uses could be classed as abuse, but again, it's hard to know without a little more
> clarity in its definition.  I made a couple of attempts at cleaning up usage a while ago, but ended up abandoning
> them because of that lack of clarity.  What came out of that was the realization that something like this might
> be possible, and would be a useful precursor to usage changes.  That comment is my stake in the ground for
> helping to distinguish good uses vs abuse.  I'm planning to revisit uses with that in mind.
> 
> The vast majority of uses are in x86/x64 assembly code, where I think it is usually about encoding a Java null
> in an instruction.  I've looked at changing how that's done, but the messiness of the definition, crossed with
> the 32/64bit issues there, again led me to balk.  Nuking 32bit x86 might reduce the complexity to something
> more manageable.

Okay. Maybe NULL_OOP might be a better way to spell this in the future?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22468#discussion_r1865726762

From jwaters at openjdk.org  Mon Dec  2 12:03:50 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 2 Dec 2024 12:03:50 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
Message-ID: <iZMBG6lBQrnozZH0YHY5-0o0tbtODDPwTyHg3s4X3eQ=.875fb772-177f-4425-bf26-e9f70e1a04f1@github.com>

On Fri, 22 Nov 2024 09:17:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into hotspot
>  - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp
>  - fmod_win64 in sharedRuntime.cpp
>  - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp
>  - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - No spaces in test_os_windows.cpp
>  - No spaces in test/hotspot/gtest/runtime/test_os.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Revise comment in sharedRuntime.hpp
>  - Revise comment in sharedRuntime.cpp
>  - size_t brace initialization instead of unsigned literals in test_os_windows.cpp
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/e987ecd3...6cf1c83a

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2511347663

From mli at openjdk.org  Mon Dec  2 12:05:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 12:05:39 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication
In-Reply-To: <Q0wQiOPrpFzTk6UegxLiZhwPSP533eoi9Bm4UoMRZeo=.ddda1fc0-f3ba-409c-b1fd-29e08f661032@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Q0wQiOPrpFzTk6UegxLiZhwPSP533eoi9Bm4UoMRZeo=.ddda1fc0-f3ba-409c-b1fd-29e08f661032@github.com>
Message-ID: <BI8tbV3qvl1lspDDnkT2x_BOUMHrJxBOTcXmyQX8Z2Y=.455efd2f-b2e4-4113-9717-0735d2e4f88e@github.com>

On Mon, 2 Dec 2024 11:02:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1761:
> 
>> 1759:   bind(L_16_bytes_loop);
>> 1760:   {
>> 1761:     #define CRC32_VCLMUL_FOLD_16_BYTES(vx, vt, vtmp1, vtmp2, vtmp3, vtmp4) \
> 
> It makes no sense for this to be a macro, because it's called infrequently. Making it a function would save space.

Thanks for the suggestion, will fix it.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1833:
> 
>> 1831:     vslideup_vi(vy, vtmp1, 1); \
>> 1832:     vmv_x_s(tmp2, vtmp3); \
>> 1833:     vmv_s_x(vy, tmp2);
> 
> Again, not a macro.

Thanks for the suggestion, will fix it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1865731017
PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1865731104

From dholmes at openjdk.org  Mon Dec  2 12:07:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 12:07:24 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
Message-ID: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>

We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 

The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.

I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.

Testing:
 - tiers 1 - 4

Some frame management code was also moved from `VMError` to the `frame` class.

-------------

Commit messages:
 - Remove unused constructor
 - Missing file header
 - 8311542: Consolidate the native stack printing code

Changes: https://git.openjdk.org/jdk/pull/22472/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8311542
  Stats: 350 lines in 9 files changed: 231 ins; 96 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/22472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22472/head:pull/22472

PR: https://git.openjdk.org/jdk/pull/22472

From amitkumar at openjdk.org  Mon Dec  2 12:21:38 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 2 Dec 2024 12:21:38 GMT
Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <84cbe8d4-df04-432c-b84e-a9ef2f57bfea@littlepinkcloud.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
 <84cbe8d4-df04-432c-b84e-a9ef2f57bfea@littlepinkcloud.com>
Message-ID: <ftc4tXOW7DMBc3SXIb4NRMQW7gn0IfemOE2RDJEsZVE=.3f38f9f2-3fcd-435e-8740-36c35dc0b0b0@github.com>

On Mon, 2 Dec 2024 11:55:31 GMT, Andrew Haley <aph-open at littlepinkcloud.com> wrote:

> Are there any performance figures? Does the change help, or at least do no harm, on s390?

Hi @RealLucy, 

I guess I made a mistake. So by default `SecondarySupersTable` flag is `enabled/set to true`. By this piece of code: 

  if (FLAG_IS_DEFAULT(UseSecondarySupersTable)) {
    FLAG_SET_DEFAULT(UseSecondarySupersTable, VM_Version::supports_secondary_supers_table());
  } else if (UseSecondarySupersTable && !VM_Version::supports_secondary_supers_table()) {
    warning("UseSecondarySupersTable is not supported");
    FLAG_SET_DEFAULT(UseSecondarySupersTable, false);
  }
  if (!UseSecondarySupersTable) {
    FLAG_SET_DEFAULT(StressSecondarySupers, false);
    FLAG_SET_DEFAULT(VerifySecondarySupers, false);
  }


specifically `FLAG_SET_DEFAULT(UseSecondarySupersTable, VM_Version::supports_secondary_supers_table());`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2511385622

From amitkumar at openjdk.org  Mon Dec  2 12:21:39 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 2 Dec 2024 12:21:39 GMT
Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
 <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
Message-ID: <eQCeFl0PAco7VcZNNOTtp6Gtwom0AcoY2sMUXKjzey4=.e0690850-7f83-4608-bff6-b162edd08b60@github.com>

On Wed, 27 Nov 2024 11:23:14 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341)
>> 
>> Tier1 test: 
>> 1. `-XX:+UseSecondarySupersTable  -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache`
>> 2.  No flag turn on. i.e. used `UseSecondarySupersCache` by default. 
>> 3. `-XX:+UseSecondarySupersTable  -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates comments

Here are the correct benchmark results: 

make test TEST="micro:vm.compiler.SecondarySuperCacheInterContention"  MICRO="JAVA_OPTIONS=-XX:TieredStopAtLevel=1"

Benchmark                                   Mode  Cnt  Score   Error  Units
SecondarySuperCacheInterContention.test     avgt   15  8.201 ? 0.264  ns/op
SecondarySuperCacheInterContention.test:t1  avgt   15  8.181 ? 0.256  ns/op
SecondarySuperCacheInterContention.test:t2  avgt   15  8.221 ? 0.327  ns/op
Finished running test 'micro:vm.compiler.SecondarySuperCacheInterContention'

make test TEST="micro:vm.compiler.SecondarySuperCacheInterContention"  MICRO="JAVA_OPTIONS=-XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:+UseSecondarySupersCache -XX:-UseSecondarySupersTable"

Benchmark                                   Mode  Cnt     Score     Error  Units
SecondarySuperCacheInterContention.test     avgt   15  1873.536 ? 189.942  ns/op
SecondarySuperCacheInterContention.test:t1  avgt   15  1897.531 ? 175.604  ns/op
SecondarySuperCacheInterContention.test:t2  avgt   15  1849.541 ? 218.214  ns/op
Finished running test 'micro:vm.compiler.SecondarySuperCacheInterContention'



make test TEST="micro:vm.compiler.SecondarySuperCacheIntraContention"  MICRO="JAVA_OPTIONS=-XX:TieredStopAtLevel=1"

SecondarySuperCacheIntraContention.test  avgt   15  7.988 ? 0.361  ns/op
Finished running test 'micro:vm.compiler.SecondarySuperCacheIntraContention'


make test TEST="micro:vm.compiler.SecondarySuperCacheIntraContention"  MICRO="JAVA_OPTIONS=-XX:TieredStopAtLevel=1 -XX:+UnlockDiagnosticVMOptions -XX:+UseSecondarySupersCache -XX:-UseSecondarySupersTable"

SecondarySuperCacheIntraContention.test  avgt   15  2780.239 ? 110.116  ns/op
Finished running test 'micro:vm.compiler.SecondarySuperCacheIntraContention'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2511388077

From aph at openjdk.org  Mon Dec  2 12:41:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 12:41:40 GMT
Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <eQCeFl0PAco7VcZNNOTtp6Gtwom0AcoY2sMUXKjzey4=.e0690850-7f83-4608-bff6-b162edd08b60@github.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
 <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
 <eQCeFl0PAco7VcZNNOTtp6Gtwom0AcoY2sMUXKjzey4=.e0690850-7f83-4608-bff6-b162edd08b60@github.com>
Message-ID: <BM7ERt7yCb6c3-dPi8qXAFFt7X421ed-c31ryiNZ07M=.963533f4-e05f-4a89-ae37-eb81f30b321c@github.com>

On Mon, 2 Dec 2024 12:19:29 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Here are the correct benchmark results:

Very good, so we have a performance improvement of approximately 20000% on the InterContention test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2511433343

From shade at openjdk.org  Mon Dec  2 12:42:47 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 12:42:47 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is disallowed
Message-ID: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>

We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:


int VM_Version::get_current_sve_vector_length() {
  assert(VM_Version::supports_sve(), "should not call this");
  return prctl(PR_SVE_GET_VL);
}


That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.

Additional testing:
 - [x] Linux AArch64 server fastdebug, with seccomp reproducer
 - [ ] Linux AArch64 server fastdebug, `all`

-------------

Commit messages:
 - Do not set vector length to bad value
 - Fix

Changes: https://git.openjdk.org/jdk/pull/22479/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345296
  Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22479/head:pull/22479

PR: https://git.openjdk.org/jdk/pull/22479

From rehn at openjdk.org  Mon Dec  2 12:44:37 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 12:44:37 GMT
Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v2]
In-Reply-To: <E1lmTXD1jx3baeAqtIo8QfX61M-Z3m-7vVr3PuBnYwY=.bdf840d1-0463-4b25-9cef-b3ba972271f2@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
 <Dwi-JYwCPmRCteN7gXPitLaXUX8E_LS8bsoQmtVMtrk=.bf9962f2-e298-4e12-8c43-e9ac52dacace@github.com>
 <E1lmTXD1jx3baeAqtIo8QfX61M-Z3m-7vVr3PuBnYwY=.bdf840d1-0463-4b25-9cef-b3ba972271f2@github.com>
Message-ID: <g4Q7W7vzBwJ1sImMI3_fC4l1w5g5xGeXojvqAd0fbLU=.4a9cc97e-b19b-41d7-a456-9b2298cf5187@github.com>

On Mon, 2 Dec 2024 11:43:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Thanks for adding the tests!
> 
> The test code looks good. Just some minor comment below.
> 
> And one general question, will we consider to add some concurrent tests in the future? Although I don't have a good idea how to implement such tests in a stable way. :)

Thanks, yes I'm adding concurrent tests also.
There is several in the gtest suit.

> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 144:
> 
>> 142:     data[i] = 121;
>> 143:     ret = NarrowCmpxchgTester<TESTSIZE, ASMSIZE>::narrow_cmpxchg((intptr_t)&data[i], 121, 42, /* result */ 67,
>> 144:                                                                           -1, -1, -1, false);
> 
> Seems we don't need to put these `-1, -1, -1` as the arguments of `NarrowCmpxchgTester::narrow_cmpxchg`, they could be just local variables in `narrow_cmpxchg`.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22445#issuecomment-2511438119
PR Review Comment: https://git.openjdk.org/jdk/pull/22445#discussion_r1865781576

From mli at openjdk.org  Mon Dec  2 12:49:53 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 12:49:53 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v2]
In-Reply-To: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
Message-ID: <uNnTj17rkWImf4FmwFDg3Y8UZ0K9oiVkzrlZZIvgpHA=.74777cb6-4875-4791-bedb-78d8e366713c@github.com>

> Hi,
> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
> Thanks!
> 
> 
> ## Test
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
> test/jdk/java/util/zip/TestCRC32.java

Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:

 - minor
 - macros to functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22475/files
  - new: https://git.openjdk.org/jdk/pull/22475/files/63ac49f0..19808eda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22475&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22475&range=00-01

  Stats: 169 lines in 2 files changed: 84 ins; 67 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/22475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22475/head:pull/22475

PR: https://git.openjdk.org/jdk/pull/22475

From rehn at openjdk.org  Mon Dec  2 13:06:37 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 13:06:37 GMT
Subject: RFR: 8345177: RISC-V: Add gtests for cmpxchg [v2]
In-Reply-To: <4BevhrlYJCdNP3JNHxGghVK_vsFbKxa5okiBIBNzuUA=.2e0561e2-45f5-48d2-bd8a-b2cd951b0736@github.com>
References: <gFS_7r0eGaUJhR9S-OvqoaS83n3klR8Qd3kWNLfCPh8=.b6ebf62d-8c29-4eab-b2eb-2b1226d3e1b9@github.com>
 <y0iGL_3a0Kc0sIJzTeyDMQ_mBVN4w5RxbCbnOQtxgoo=.68fbc866-7b5f-4e79-b379-38c35ecaf605@github.com>
 <4BevhrlYJCdNP3JNHxGghVK_vsFbKxa5okiBIBNzuUA=.2e0561e2-45f5-48d2-bd8a-b2cd951b0736@github.com>
Message-ID: <pFzZGymOXb6PJkQxUpdXK_ZfkbN89gnyTKQEDTl_3Z0=.a8b30781-f423-4c96-9c1c-c4d45cf42abd@github.com>

On Mon, 2 Dec 2024 00:16:37 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove CMF barrier
>
> Updated change looks good. Thanks.

Thanks @RealFYang and @Hamlin-Li !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22437#issuecomment-2511487018

From rehn at openjdk.org  Mon Dec  2 13:08:08 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 13:08:08 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg
Message-ID: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>

Hi, please consider.

This adds tests of aligned weak narrow cmpxchg.

[ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
[       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
[ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
[       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
[ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
[       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
[ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
[       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
[----------] 4 tests from RiscV (20997 ms total)

Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas

Thanks, Robbin

-------------

Commit messages:
 - gtest weak narrow cmpxchg

Changes: https://git.openjdk.org/jdk/pull/22476/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345179
  Stats: 74 lines in 1 file changed: 74 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22476/head:pull/22476

PR: https://git.openjdk.org/jdk/pull/22476

From fyang at openjdk.org  Mon Dec  2 13:08:08 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 2 Dec 2024 13:08:08 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg
In-Reply-To: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
Message-ID: <ulLTS1pojQe1X_PdqS-xmkxDmkOw6iDgdGDJT-kFnoA=.1d780762-7739-4107-9b8c-a853a08fa570@github.com>

On Mon, 2 Dec 2024 10:46:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> This adds tests of aligned weak narrow cmpxchg.
> 
> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20997 ms total)
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Hi, Seems this only covers `MacroAssembler::weak_cmpxchg_narrow_value`. Are we going to add testing for this one: `MacroAssembler::cmpxchg_weak`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22476#issuecomment-2511335263

From rehn at openjdk.org  Mon Dec  2 13:08:08 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 13:08:08 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg
In-Reply-To: <ulLTS1pojQe1X_PdqS-xmkxDmkOw6iDgdGDJT-kFnoA=.1d780762-7739-4107-9b8c-a853a08fa570@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <ulLTS1pojQe1X_PdqS-xmkxDmkOw6iDgdGDJT-kFnoA=.1d780762-7739-4107-9b8c-a853a08fa570@github.com>
Message-ID: <R1GlLMykGJDKBzPQjEO7eZrQOMkPLdQ5JALESyH_QMU=.b487fc38-b91c-425f-9c59-0b2433998f82@github.com>

On Mon, 2 Dec 2024 11:55:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Seems this only covers `MacroAssembler::weak_cmpxchg_narrow_value`. Are we going to add testing for this one: `MacroAssembler::cmpxchg_weak`?

As the Zacas is the same as normal cmpxchg and the lr/sc just changes the loop to failure it wasn't my focus.

I can add it if you want, to this PR or a later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22476#issuecomment-2511485811

From rehn at openjdk.org  Mon Dec  2 13:10:16 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 13:10:16 GMT
Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v3]
In-Reply-To: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
Message-ID: <6-lOUZ6rBuRJcNraBOvdZC-PKcFGpNplhOKnNKlxoqI=.ade411e5-6f14-4e36-b288-b0e4e3bdefe1@github.com>

> Hi, please consider.
> 
> This adds tests of aligned narrow cmpxchg.
> 
> 
> Note: Google Test filter = *RiscV*
> [==========] Running 5 tests from 1 test suite.
> [----------] Global test environment set-up.
> [----------] 5 tests from RiscV
> ...
> [ RUN      ] RiscV.cmpxchg_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms)
> [ RUN      ] RiscV.cmpxchg_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms)
> [ RUN      ] RiscV.cmpxchg_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms)
> [----------] 5 tests from RiscV (20831 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 5 tests from 1 test suite ran. (20834 ms total)
> [  PASSED  ] 5 tests.
> 
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22445/files
  - new: https://git.openjdk.org/jdk/pull/22445/files/b07b2c10..22e8c4e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22445&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22445&range=01-02

  Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22445/head:pull/22445

PR: https://git.openjdk.org/jdk/pull/22445

From mli at openjdk.org  Mon Dec  2 13:14:40 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 13:14:40 GMT
Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v3]
In-Reply-To: <6-lOUZ6rBuRJcNraBOvdZC-PKcFGpNplhOKnNKlxoqI=.ade411e5-6f14-4e36-b288-b0e4e3bdefe1@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
 <6-lOUZ6rBuRJcNraBOvdZC-PKcFGpNplhOKnNKlxoqI=.ade411e5-6f14-4e36-b288-b0e4e3bdefe1@github.com>
Message-ID: <lbNcPo2OrI1oMNT2JIlIro8qopqXUw1qRf_fe1CFfYc=.9353d68e-0151-4c3d-9e56-61a6068d175f@github.com>

On Mon, 2 Dec 2024 13:10:16 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned narrow cmpxchg.
>> 
>> 
>> Note: Google Test filter = *RiscV*
>> [==========] Running 5 tests from 1 test suite.
>> [----------] Global test environment set-up.
>> [----------] 5 tests from RiscV
>> ...
>> [ RUN      ] RiscV.cmpxchg_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms)
>> [----------] 5 tests from RiscV (20831 ms total)
>> 
>> [----------] Global test environment tear-down
>> [==========] 5 tests from 1 test suite ran. (20834 ms total)
>> [  PASSED  ] 5 tests.
>> 
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Thanks for updating, looks good!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22445#pullrequestreview-2472663437

From eastigeevich at openjdk.org  Mon Dec  2 13:16:40 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 13:16:40 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed
In-Reply-To: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
Message-ID: <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>

On Mon, 2 Dec 2024 12:17:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
> 
> 
> int VM_Version::get_current_sve_vector_length() {
>   assert(VM_Version::supports_sve(), "should not call this");
>   return prctl(PR_SVE_GET_VL);
> }
> 
> 
> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>  - [ ] Linux AArch64 server fastdebug, `all`

Changes requested by eastigeevich (Committer).

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 447:

> 445: 
> 446:   if (UseSVE > 0) {
> 447:     _initial_sve_vector_length = get_current_sve_vector_length();

We need an assert checking `_initial_sve_vector_length > 0`

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 453:

> 451:     } else {
> 452:       _initial_sve_vector_length = vl;
> 453:     }

I think we need to disable SVE in `VM_Version::get_os_cpu_info` in `src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp`:


  if (auxv2 & HWCAP2_SVE2) _features |= CPU_SVE2;
  if (auxv2 & HWCAP2_SVEBITPERM) _features |= CPU_SVEBITPERM;

  if (prctl(PR_SVE_GET_VL) == -1) {
    warning("Unable to get SVE vector length on this system. Disabling SVE.");
    _features &= ~CPU_SVE;
  }

-------------

PR Review: https://git.openjdk.org/jdk/pull/22479#pullrequestreview-2472663905
PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1865833797
PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1865828571

From rehn at openjdk.org  Mon Dec  2 13:17:41 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 13:17:41 GMT
Subject: Integrated: 8345177: RISC-V: Add gtests for cmpxchg
In-Reply-To: <gFS_7r0eGaUJhR9S-OvqoaS83n3klR8Qd3kWNLfCPh8=.b6ebf62d-8c29-4eab-b2eb-2b1226d3e1b9@github.com>
References: <gFS_7r0eGaUJhR9S-OvqoaS83n3klR8Qd3kWNLfCPh8=.b6ebf62d-8c29-4eab-b2eb-2b1226d3e1b9@github.com>
Message-ID: <2z9KeQavqrBXkuCFz4t4HsPTDfTU3FMjZYVE_ZPqCfs=.1473ee1a-a744-413b-9fd8-b251a72c1ca5@github.com>

On Thu, 28 Nov 2024 12:30:12 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> This adds tests to some of the base cases.
> Focusing on the cases when we pass in same register in some of the argument. (variant 0,1,2,3)
> 
> Note: Google Test filter = *RiscV.cmpxchg*
> [==========] Running 4 tests from 1 test suite.
> [----------] Global test environment set-up.
> [----------] 4 tests from RiscV
> [ RUN      ] RiscV.cmpxchg_int64_plain_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_plain_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_plain_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_int32_plain_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_plain_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_plain_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20806 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 4 tests from 1 test suite ran. (20809 ms total)
> [  PASSED  ] 4 tests.
> 
> 
> Executed with `-XX:+UnlockExperimentalVMOptions -XX:+UseZacas`
> 
> Thanks, Robbin

This pull request has now been integrated.

Changeset: 9a48e4d9
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a48e4d9d2637bf152d6611061a0a0a195cc2caf
Stats:     157 lines in 1 file changed: 155 ins; 1 del; 1 mod

8345177: RISC-V: Add gtests for cmpxchg

Reviewed-by: fyang, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22437

From rehn at openjdk.org  Mon Dec  2 13:22:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 13:22:38 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v2]
In-Reply-To: <uNnTj17rkWImf4FmwFDg3Y8UZ0K9oiVkzrlZZIvgpHA=.74777cb6-4875-4791-bedb-78d8e366713c@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <uNnTj17rkWImf4FmwFDg3Y8UZ0K9oiVkzrlZZIvgpHA=.74777cb6-4875-4791-bedb-78d8e366713c@github.com>
Message-ID: <Q9JsX22KbywMvpOIeckWggE9cIK3XRpkM1RNqS9ow50=.12a9fbab-d1c8-4769-ac13-fd8492b890c3@github.com>

On Mon, 2 Dec 2024 12:49:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor
>  - macros to functions

Nice @Hamlin-Li, thanks!!!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22475#issuecomment-2511526721

From aph at openjdk.org  Mon Dec  2 13:27:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 13:27:38 GMT
Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
 <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
Message-ID: <BnA1J6rQ4mH04PmKsoV44F0k6eNtwlczFlj7n3s981Y=.b2c5b8d3-8044-448c-a693-ccccf32363ba@github.com>

On Wed, 27 Nov 2024 11:23:14 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341)
>> 
>> Tier1 test: 
>> 1. `-XX:+UseSecondarySupersTable  -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache`
>> 2.  No flag turn on. i.e. used `UseSecondarySupersCache` by default. 
>> 3. `-XX:+UseSecondarySupersTable  -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates comments

Looks good, thanks.
It's probably worth making sure there's a `make bootcycle-images` and if it doesn't take forever, tiers 2-4. We don't want any nasty surprises.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22341#pullrequestreview-2472695930

From coleen.phillimore at oracle.com  Mon Dec  2 13:38:10 2024
From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com)
Date: Mon, 2 Dec 2024 08:38:10 -0500
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas
In-Reply-To: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
References: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
Message-ID: <24aef46e-af96-46a0-84e5-c0d5325f014b@oracle.com>

Vote: yes

On 11/27/24 6:26 AM, Stefan Karlsson wrote:
> I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot 
> Group.
>
> Axel is a member of Oracle's HotSpot GC team and has been contributing 
> to various parts of the JVM for over two years now.
>
> Votes are due by 2024-12-11T12:24+01:00.
>
> Only current Members of the HotSpot Group [1] are eligible
> to vote on this nomination.? Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Stefan Karlsson
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


From thomas.stuefe at gmail.com  Mon Dec  2 13:41:28 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Mon, 2 Dec 2024 14:41:28 +0100
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas
In-Reply-To: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
References: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
Message-ID: <CAA-vtUwdRoGRbntACsQDLoxe+hU4tcuSqtK9zC3fXJ+gA+XiJQ@mail.gmail.com>

Vote: yes

On Wed, Nov 27, 2024 at 12:26?PM Stefan Karlsson <stefan.karlsson at oracle.com>
wrote:

> I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group.
>
> Axel is a member of Oracle's HotSpot GC team and has been contributing
> to various parts of the JVM for over two years now.
>
> Votes are due by 2024-12-11T12:24+01:00.
>
> Only current Members of the HotSpot Group [1] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Stefan Karlsson
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241202/e1d0ce3b/attachment-0001.htm>

From rrich at openjdk.org  Mon Dec  2 13:42:25 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 2 Dec 2024 13:42:25 GMT
Subject: RFR: 8344609: Check ResourceMark nesting when allocating a
 GrowableArray on an alternative ResourceArea [v3]
In-Reply-To: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
References: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
Message-ID: <inlLn9OWfyqk_1WaK7IzYIgQbbHDVrGjOLpXwR_gFsw=.24ae107d-069c-4eee-84dd-7401cdf15404@github.com>

> With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`.
> 
> The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085).
> 
> The fix passed our nightly CI testing:
> Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests.
> Testing was done on the main platforms and also on Linux/PPC64le and AIX.
> 
> Besides ctw tests on ppc64 (see [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085)) the check never failed.

Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master'
 - Add parentheses
 - Check GrowableArray nesting if allocating on alternative ResourceArea

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22269/files
  - new: https://git.openjdk.org/jdk/pull/22269/files/e00d6154..54749167

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22269&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22269&range=01-02

  Stats: 87557 lines in 1628 files changed: 53712 ins; 25375 del; 8470 mod
  Patch: https://git.openjdk.org/jdk/pull/22269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22269/head:pull/22269

PR: https://git.openjdk.org/jdk/pull/22269

From aph at openjdk.org  Mon Dec  2 13:42:43 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 13:42:43 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed
In-Reply-To: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
Message-ID: <0vxoQZVP7jx6R9O8Pk8exW7YFcCHtKfzFCmwDsshHA8=.63c2ea75-165a-4f78-9dde-012f5054c07c@github.com>

On Mon, 2 Dec 2024 12:17:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
> 
> 
> int VM_Version::get_current_sve_vector_length() {
>   assert(VM_Version::supports_sve(), "should not call this");
>   return prctl(PR_SVE_GET_VL);
> }
> 
> 
> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>  - [ ] Linux AArch64 server fastdebug, `all`

Huh. That's annoying.
Does this patch mean that a warning is printed unconditionally on systems where `prctl` is disabled?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2511573977

From aph at openjdk.org  Mon Dec  2 13:46:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 13:46:40 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v2]
In-Reply-To: <uNnTj17rkWImf4FmwFDg3Y8UZ0K9oiVkzrlZZIvgpHA=.74777cb6-4875-4791-bedb-78d8e366713c@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <uNnTj17rkWImf4FmwFDg3Y8UZ0K9oiVkzrlZZIvgpHA=.74777cb6-4875-4791-bedb-78d8e366713c@github.com>
Message-ID: <OJnjtUN5wEMoGvzn5GsXOSP28cKhc1YSQwLUuCTuc_Y=.3a7921e4-940f-4477-bf07-2d2e20fe4981@github.com>

On Mon, 2 Dec 2024 12:49:53 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - minor
>  - macros to functions

No further objections from me. It looks fine, but I'm not a RISC V expert so I won't tick the box.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22475#pullrequestreview-2472740972

From mli at openjdk.org  Mon Dec  2 13:54:18 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 13:54:18 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
Message-ID: <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>

> Hi,
> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
> Thanks!
> 
> 
> ## Test
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
> test/jdk/java/util/zip/TestCRC32.java

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  add some background description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22475/files
  - new: https://git.openjdk.org/jdk/pull/22475/files/19808eda..b6b87943

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22475&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22475&range=01-02

  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22475/head:pull/22475

PR: https://git.openjdk.org/jdk/pull/22475

From shade at openjdk.org  Mon Dec  2 14:08:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 14:08:40 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed
In-Reply-To: <0vxoQZVP7jx6R9O8Pk8exW7YFcCHtKfzFCmwDsshHA8=.63c2ea75-165a-4f78-9dde-012f5054c07c@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <0vxoQZVP7jx6R9O8Pk8exW7YFcCHtKfzFCmwDsshHA8=.63c2ea75-165a-4f78-9dde-012f5054c07c@github.com>
Message-ID: <bGLe9zS4ZgsEJkfa8gnbieIdW6A2RZjw95r27u4oJoY=.7ce9e296-e828-4be3-a34e-270869ff0fc8@github.com>

On Mon, 2 Dec 2024 13:40:27 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Huh. That's annoying.  

Yes.

> Does this patch mean that a warning is printed unconditionally on systems where `prctl` is disabled?

Unfortunately, yes. On the other hand, I believe it is recognized that disabling "innocuous" `prctl` queries is not great. We really just want a more graceful JVM behavior in these cases. Anything apart VM crash would do better. The alternative is to exit the VM and ask users to `UseSVE=0` manually. Doing this automatically and proceeding with the warning looks like a sane middle ground.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2511637673

From mli at openjdk.org  Mon Dec  2 14:15:17 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 14:15:17 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe
Message-ID: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>

Hi,
Can you help to review the patch?
Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.

Thanks!

Tests running so far so good.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/22474/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345289
  Stats: 17 lines in 3 files changed: 16 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22474/head:pull/22474

PR: https://git.openjdk.org/jdk/pull/22474

From luhenry at openjdk.org  Mon Dec  2 14:15:17 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Mon, 2 Dec 2024 14:15:17 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe
In-Reply-To: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
Message-ID: <ViX-176Ld6IaNB3jfc32o3KVF2Up1JKhdJjQ4eUxRz0=.816b9a56-25cc-4f9e-8d3b-465364c40158@github.com>

On Mon, 2 Dec 2024 09:55:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review the patch?
> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
> 
> Thanks!
> 
> Tests running so far so good.

src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 184:

> 182:     VM_Version::ext_Zfh.enable_feature();
> 183:   }
> 184:   if (is_set(RISCV_HWPROBE_KEY_IMA_EXT_0, RISCV_HWPROBE_EXT_ZICBOZ)) {

Could you add Zicbop and Zicbom as well? Are they even supported/defined in the kernel headers?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22474#discussion_r1865565589

From mli at openjdk.org  Mon Dec  2 14:15:17 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 14:15:17 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe
In-Reply-To: <ViX-176Ld6IaNB3jfc32o3KVF2Up1JKhdJjQ4eUxRz0=.816b9a56-25cc-4f9e-8d3b-465364c40158@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
 <ViX-176Ld6IaNB3jfc32o3KVF2Up1JKhdJjQ4eUxRz0=.816b9a56-25cc-4f9e-8d3b-465364c40158@github.com>
Message-ID: <imrqLAaLPdpSREv5l_RQyomt5xVNgRa_DWD4ha8vYN0=.f2a0fb99-0cc4-4b34-8d5f-2247ac306a3f@github.com>

On Mon, 2 Dec 2024 10:03:21 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
>> 
>> Thanks!
>> 
>> Tests running so far so good.
>
> src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 184:
> 
>> 182:     VM_Version::ext_Zfh.enable_feature();
>> 183:   }
>> 184:   if (is_set(RISCV_HWPROBE_KEY_IMA_EXT_0, RISCV_HWPROBE_EXT_ZICBOZ)) {
> 
> Could you add Zicbop and Zicbom as well? Are they even supported/defined in the kernel headers?

Seems they are not supported in kernel yet, please check https://github.com/torvalds/linux/blob/master/arch/riscv/include/uapi/asm/hwprobe.h.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22474#discussion_r1865795175

From mdoerr at openjdk.org  Mon Dec  2 14:15:44 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 2 Dec 2024 14:15:44 GMT
Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
 <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
Message-ID: <Inumu1CRB7VCFi9ffJuUqpVXVy0vOvpsSeCeLQ9SHzc=.8e629955-c4a9-4abf-950e-254136d87c20@github.com>

On Thu, 28 Nov 2024 21:33:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future.
>> VectorCastNodes are not yet implemented on PPC64. Power9 is recognized by the availability of the "darn" instruction.
>> 
>> Performance on Power9:
>> Before patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score     Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15     18.995 ?   0.156  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15     18.730 ?   0.331  ops/ms
>> 
>> 
>> After patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score      Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15    522.637 ?   11.274  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15    408.112 ?    9.069  ops/ms
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure interpreter entries are not called on Power8 or older.

src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 700:

> 698:       LIR_Opr tmp = new_register(T_FLOAT);
> 699:       // f2hf treats tmp as live_in. Workaround: initialize to some value.
> 700:       __ move(LIR_OprFact::floatConst(-0.0), tmp); // just to satisfy LinearScan

@vnkozlov What do you think about introducing a dummy `LIR_Op0` which provides an undefined float for such workarounds (separate RFE)? That could be used on multiple platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22433#discussion_r1865923138

From shade at openjdk.org  Mon Dec  2 14:20:45 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 14:20:45 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed
In-Reply-To: <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
Message-ID: <reFlUbR4kCUC18gwLHqoFX6n6-OGdtV_228xPM9QEUQ=.4508b841-d4fb-4f52-83e5-c7c371c70684@github.com>

On Mon, 2 Dec 2024 13:12:13 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 453:
> 
>> 451:     } else {
>> 452:       _initial_sve_vector_length = vl;
>> 453:     }
> 
> I think we need to disable SVE in `VM_Version::get_os_cpu_info` in `src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp`:
> 
> 
>   if (auxv2 & HWCAP2_SVE2) _features |= CPU_SVE2;
>   if (auxv2 & HWCAP2_SVEBITPERM) _features |= CPU_SVEBITPERM;
> 
>   if (prctl(PR_SVE_GET_VL) == -1) {
>     warning("Unable to get SVE vector length on this system. Disabling SVE.");
>     _features &= ~CPU_SVE;
>   }

I think this part later in the same method does the sync for us already:
https://github.com/openjdk/jdk/blob/b8233989e7605268dda908e6b639ca373789792b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L590-L597

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1865930448

From azafari at openjdk.org  Mon Dec  2 14:36:06 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Dec 2024 14:36:06 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v7]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <Rd5sg8NNYUf5BidQGhmmLzn6LdOd71nkbqTiVOdaTgs=.3b5851c2-75f5-4fc0-ad79-a694d8e3b67f@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 50 commits:

 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - some fixes.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - Roberto's feedback applied.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - gc/x directory removed.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - added some descriptions of how VMT works.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - fixes after merge with use_tag_inplace
 - ... and 40 more: https://git.openjdk.org/jdk/compare/0b0f83c0...7fc7b343

-------------

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=06
  Stats: 3067 lines in 54 files changed: 1277 ins; 1529 del; 261 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

PR: https://git.openjdk.org/jdk/pull/20425

From erikj at openjdk.org  Mon Dec  2 14:41:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 2 Dec 2024 14:41:46 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v21]
In-Reply-To: <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
Message-ID: <SSp4ejSHwJ3SmjF_E0hztbwUV2lZlNr-rfKMgV2xiUc=.993ca166-4f57-40f8-a180-a9b5f4d601bb@github.com>

On Tue, 26 Nov 2024 17:17:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into static-jdk-image
>  - Remove LDFLAGS_STATIC_JDK
>  - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt
>  - Find LIBZIP_OBJS automatically
>  - Find LIBJAVA_JPEG_OBJS automatically
>  - Just exclude the a11y libraries from static builds
>  - Copy debuginfo
>  - Restore SetExecname in java_md.c
>  - Fix incremental builds
>  - Merge branch 'master' into static-jdk-image
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/20837#pullrequestreview-2472889294

From mli at openjdk.org  Mon Dec  2 14:58:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 14:58:38 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v2]
In-Reply-To: <Q9JsX22KbywMvpOIeckWggE9cIK3XRpkM1RNqS9ow50=.12a9fbab-d1c8-4769-ac13-fd8492b890c3@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <uNnTj17rkWImf4FmwFDg3Y8UZ0K9oiVkzrlZZIvgpHA=.74777cb6-4875-4791-bedb-78d8e366713c@github.com>
 <Q9JsX22KbywMvpOIeckWggE9cIK3XRpkM1RNqS9ow50=.12a9fbab-d1c8-4769-ac13-fd8492b890c3@github.com>
Message-ID: <0mPdohB6q4pZbFbVH59DDh9wNTcIGTMdqrQ4WJmsFTk=.44f2792d-8d98-4b7a-ae73-5fd459dfdbff@github.com>

On Mon, 2 Dec 2024 13:19:54 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Nice @Hamlin-Li, thanks!!!

Thank you Robbin!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22475#issuecomment-2511760962

From mli at openjdk.org  Mon Dec  2 14:58:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 2 Dec 2024 14:58:39 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v2]
In-Reply-To: <OJnjtUN5wEMoGvzn5GsXOSP28cKhc1YSQwLUuCTuc_Y=.3a7921e4-940f-4477-bf07-2d2e20fe4981@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <uNnTj17rkWImf4FmwFDg3Y8UZ0K9oiVkzrlZZIvgpHA=.74777cb6-4875-4791-bedb-78d8e366713c@github.com>
 <OJnjtUN5wEMoGvzn5GsXOSP28cKhc1YSQwLUuCTuc_Y=.3a7921e4-940f-4477-bf07-2d2e20fe4981@github.com>
Message-ID: <1hPqB0N7aSIIKkKtqC3fV28TiAq6VKyOLeyYtp5-dps=.6cc0a452-5fa2-4a6a-adbc-5c27d91dccf3@github.com>

On Mon, 2 Dec 2024 13:44:09 GMT, Andrew Haley <aph at openjdk.org> wrote:

> No further objections from me. It looks fine, but I'm not a RISC V expert so I won't tick the box.

Thank you Andrew!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22475#issuecomment-2511762258

From aph at openjdk.org  Mon Dec  2 15:06:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 15:06:38 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed
In-Reply-To: <bGLe9zS4ZgsEJkfa8gnbieIdW6A2RZjw95r27u4oJoY=.7ce9e296-e828-4be3-a34e-270869ff0fc8@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <0vxoQZVP7jx6R9O8Pk8exW7YFcCHtKfzFCmwDsshHA8=.63c2ea75-165a-4f78-9dde-012f5054c07c@github.com>
 <bGLe9zS4ZgsEJkfa8gnbieIdW6A2RZjw95r27u4oJoY=.7ce9e296-e828-4be3-a34e-270869ff0fc8@github.com>
Message-ID: <WqVhx99XKVuPCxxvIpGuKGWM7o9UxVgMEhElFleEvSU=.6e668f2a-f55d-4431-a847-4408bb9733c6@github.com>

On Mon, 2 Dec 2024 14:06:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Does this patch mean that a warning is printed unconditionally on systems where `prctl` is disabled?
> 
> Unfortunately, yes. On the other hand, I believe it is recognized that disabling "innocuous" `prctl` queries is not great, and sandboxes should actually allow them. We really just want a more graceful JVM behavior in these cases. Anything apart the VM crash would do better. The alternative is to exit the VM and ask users to `UseSVE=0` manually. Doing this automatically and proceeding with the warning looks like a sane middle ground.

I understand, but there are compatibility issues. As far as I can tell this issue is only likely to manifest on systems where the console isn't monitored, so I'm not sure I'd print the warning unconditionally, but your call.

Anyway, please print something like "Use -XX:UseSVE=0 to remove this warning."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2511782585

From shade at openjdk.org  Mon Dec  2 15:15:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 15:15:19 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
Message-ID: <6nTmn9_ttqyKgackXyVTY2CpQJ6L1nNBJez5exjEsaQ=.91ad67fa-cf61-47ca-a0ab-0bb3ff98733c@github.com>

> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
> 
> 
> int VM_Version::get_current_sve_vector_length() {
>   assert(VM_Version::supports_sve(), "should not call this");
>   return prctl(PR_SVE_GET_VL);
> }
> 
> 
> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22479/files
  - new: https://git.openjdk.org/jdk/pull/22479/files/abc18fc2..be5805b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=00-01

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22479/head:pull/22479

PR: https://git.openjdk.org/jdk/pull/22479

From shade at openjdk.org  Mon Dec  2 15:15:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 15:15:19 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed
In-Reply-To: <WqVhx99XKVuPCxxvIpGuKGWM7o9UxVgMEhElFleEvSU=.6e668f2a-f55d-4431-a847-4408bb9733c6@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <0vxoQZVP7jx6R9O8Pk8exW7YFcCHtKfzFCmwDsshHA8=.63c2ea75-165a-4f78-9dde-012f5054c07c@github.com>
 <bGLe9zS4ZgsEJkfa8gnbieIdW6A2RZjw95r27u4oJoY=.7ce9e296-e828-4be3-a34e-270869ff0fc8@github.com>
 <WqVhx99XKVuPCxxvIpGuKGWM7o9UxVgMEhElFleEvSU=.6e668f2a-f55d-4431-a847-4408bb9733c6@github.com>
Message-ID: <gjcM6WgwFWuoEnkoEOjh5zGzRxQF-5CTgSbEgXp2DsI=.05db9670-450b-4600-a145-c35453f8c298@github.com>

On Mon, 2 Dec 2024 15:03:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

> I understand, but there are compatibility issues. As far as I can tell this issue is only likely to manifest on systems where the console isn't monitored, so I'm not sure I'd print the warning unconditionally, but your call.

We print all sorts of unconditional warnings in the adjacent code, so I think it stays :)
 
> Anyway, please print something like "Use -XX:UseSVE=0 to remove this warning."

Added another blurb into the warning message.

I am running tests to see if any Hotspot test cares about any of this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2511803424

From shade at openjdk.org  Mon Dec  2 15:15:20 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 15:15:20 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
Message-ID: <pFRPXBO26eJUOz9r67qt2KziqL74ECFqF3L5mu8HYEs=.f3777686-c492-4a73-8879-a54f9d3c33fd@github.com>

On Mon, 2 Dec 2024 13:14:24 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 447:
> 
>> 445: 
>> 446:   if (UseSVE > 0) {
>> 447:     _initial_sve_vector_length = get_current_sve_vector_length();
> 
> We need an assert checking `_initial_sve_vector_length > 0`

Speaking of the valid ranges for SVE vector length, I don't think we want to blindly accept any `>0` value either. There is a block downwards that tries to check that vector length is not smaller than a `FloatRegister::sve_vl_min`, and that it is a power of two. But that block only works for manual overrides of `MaxVectorSize`. I say we co-opt that block for checking the `prctl` result on a common path. See new commit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866026850

From coleenp at openjdk.org  Mon Dec  2 15:15:59 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Dec 2024 15:15:59 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v21]
In-Reply-To: <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
Message-ID: <ri70tpMH0Llhjbd-a3XJy2HATdVfNf53KHiCNtVbop0=.1ea46618-cad3-48b9-97a4-b53bf7718965@github.com>

On Tue, 26 Nov 2024 17:17:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into static-jdk-image
>  - Remove LDFLAGS_STATIC_JDK
>  - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt
>  - Find LIBZIP_OBJS automatically
>  - Find LIBJAVA_JPEG_OBJS automatically
>  - Just exclude the a11y libraries from static builds
>  - Copy debuginfo
>  - Restore SetExecname in java_md.c
>  - Fix incremental builds
>  - Merge branch 'master' into static-jdk-image
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8

Hotspot code looks okay.

src/hotspot/os/linux/os_linux.cpp line 590:

> 588: 
> 589:     // Found the full path to the binary. It is normally of this structure:
> 590:     //   <jdk_path>/lib/<hotspot_variant>/libjvm.so

You could change <hotspot_variant> to server I believe, since there isn't a client (I hope) version anymore.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20837#pullrequestreview-2472978117
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1866025164

From ihse at openjdk.org  Mon Dec  2 15:16:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 2 Dec 2024 15:16:00 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v21]
In-Reply-To: <aH35W513u731UVHZ69b2ORTrSZy4rtejOiPALC5oLv4=.85cea908-42c0-4b34-ace8-5a0f6b3e566f@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
 <aH35W513u731UVHZ69b2ORTrSZy4rtejOiPALC5oLv4=.85cea908-42c0-4b34-ace8-5a0f6b3e566f@github.com>
Message-ID: <dFiqxG440j4xzNPMtKA_QGFTr55mZHLXp4LmTD9oQ9c=.00e7f697-1d96-48ea-bb2c-a3894185b1de@github.com>

On Tue, 26 Nov 2024 21:20:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into static-jdk-image
>>  - Remove LDFLAGS_STATIC_JDK
>>  - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt
>>  - Find LIBZIP_OBJS automatically
>>  - Find LIBJAVA_JPEG_OBJS automatically
>>  - Just exclude the a11y libraries from static builds
>>  - Copy debuginfo
>>  - Restore SetExecname in java_md.c
>>  - Fix incremental builds
>>  - Merge branch 'master' into static-jdk-image
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8
>
> Hotspot changes look fine.
> 
> Thanks

@dholmes-ora @coleenp @erikj79 Thanks for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2511804187

From ihse at openjdk.org  Mon Dec  2 15:16:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 2 Dec 2024 15:16:01 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v21]
In-Reply-To: <ri70tpMH0Llhjbd-a3XJy2HATdVfNf53KHiCNtVbop0=.1ea46618-cad3-48b9-97a4-b53bf7718965@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
 <ri70tpMH0Llhjbd-a3XJy2HATdVfNf53KHiCNtVbop0=.1ea46618-cad3-48b9-97a4-b53bf7718965@github.com>
Message-ID: <WM7Zde5Uo3FsYFu-H-btodJ7V49jfqUUwdFyWR2tQUA=.28c894a9-2c33-48a0-aa43-545f819a4971@github.com>

On Mon, 2 Dec 2024 15:10:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into static-jdk-image
>>  - Remove LDFLAGS_STATIC_JDK
>>  - Rename EXCLUDE_FROM_STATIC_LIBS to ONLY_EXPORTED, $(MODULE)_JDK_LIBS to $(MODULE)_INCLUDED_LIBS and module-libs.txt to module-included-libs.txt
>>  - Find LIBZIP_OBJS automatically
>>  - Find LIBJAVA_JPEG_OBJS automatically
>>  - Just exclude the a11y libraries from static builds
>>  - Copy debuginfo
>>  - Restore SetExecname in java_md.c
>>  - Fix incremental builds
>>  - Merge branch 'master' into static-jdk-image
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/c329f97f...8b1217a8
>
> src/hotspot/os/linux/os_linux.cpp line 590:
> 
>> 588: 
>> 589:     // Found the full path to the binary. It is normally of this structure:
>> 590:     //   <jdk_path>/lib/<hotspot_variant>/libjvm.so
> 
> You could change <hotspot_variant> to server I believe, since there isn't a client (I hope) version anymore.

Variant can also be e.g. `minimal`. And I do think the client variant is still supported, even if it is not actively built..?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1866028280

From ihse at openjdk.org  Mon Dec  2 15:16:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 2 Dec 2024 15:16:02 GMT
Subject: Integrated: 8339480: Build static-jdk image with a statically linked
 launcher
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <h3F1RVjbwtRl3VApwV1Jr60V00rQ7VBgQaYqxIWxJ00=.2739205c-bf9e-4347-b529-3e391fc9762b@github.com>

On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

This pull request has now been integrated.

Changeset: 1ca76445
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ca764454b1cb296f4aa38a4dfdf3d4abb5c19d6
Stats:     497 lines in 27 files changed: 399 ins; 23 del; 75 mod

8339480: Build static-jdk image with a statically linked launcher

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Co-authored-by: Jiangli Zhou <jiangli at openjdk.org>
Reviewed-by: dholmes, erikj, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/20837

From coleenp at openjdk.org  Mon Dec  2 15:22:53 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Dec 2024 15:22:53 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v21]
In-Reply-To: <WM7Zde5Uo3FsYFu-H-btodJ7V49jfqUUwdFyWR2tQUA=.28c894a9-2c33-48a0-aa43-545f819a4971@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
 <ri70tpMH0Llhjbd-a3XJy2HATdVfNf53KHiCNtVbop0=.1ea46618-cad3-48b9-97a4-b53bf7718965@github.com>
 <WM7Zde5Uo3FsYFu-H-btodJ7V49jfqUUwdFyWR2tQUA=.28c894a9-2c33-48a0-aa43-545f819a4971@github.com>
Message-ID: <RQjI_iN0JwlKEBQtmSYa82xu9EEP_RxLp2QOOsIXw6E=.13f34ca3-a094-4240-b9fa-61fda1106d4c@github.com>

On Mon, 2 Dec 2024 15:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/hotspot/os/linux/os_linux.cpp line 590:
>> 
>>> 588: 
>>> 589:     // Found the full path to the binary. It is normally of this structure:
>>> 590:     //   <jdk_path>/lib/<hotspot_variant>/libjvm.so
>> 
>> You could change <hotspot_variant> to server I believe, since there isn't a client (I hope) version anymore.
>
> Variant can also be e.g. `minimal`. And I do think the client variant is still supported, even if it is not actively built..?

Okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1866042498

From azafari at openjdk.org  Mon Dec  2 15:27:39 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 2 Dec 2024 15:27:39 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  a missed change in a shenandoah file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/7fc7b343..fd77057b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

PR: https://git.openjdk.org/jdk/pull/20425

From eastigeevich at openjdk.org  Mon Dec  2 15:33:41 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 15:33:41 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <pFRPXBO26eJUOz9r67qt2KziqL74ECFqF3L5mu8HYEs=.f3777686-c492-4a73-8879-a54f9d3c33fd@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <pFRPXBO26eJUOz9r67qt2KziqL74ECFqF3L5mu8HYEs=.f3777686-c492-4a73-8879-a54f9d3c33fd@github.com>
Message-ID: <__bOt2JXoDga2Z0QbWNCfnT10sDK243O-bev3hK42v0=.fff374e7-96c6-48a9-b10e-02a0d7024d18@github.com>

On Mon, 2 Dec 2024 15:11:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 447:
>> 
>>> 445: 
>>> 446:   if (UseSVE > 0) {
>>> 447:     _initial_sve_vector_length = get_current_sve_vector_length();
>> 
>> We need an assert checking `_initial_sve_vector_length > 0`
>
> Speaking of the valid ranges for SVE vector length, I don't think we want to blindly accept any `>0` value either. There is a block downwards that tries to check that vector length is not smaller than a `FloatRegister::sve_vl_min`, and that it is a power of two. But that block only works for manual overrides of `MaxVectorSize`. I say we co-opt that block for checking the `prctl` result on a common path. See new commit?

I don't like `get_current_sve_vector_length` returning `-1`. IMO if you cannot use SVE calling it makes no sense.
I see its doc mentions a negative result: https://github.com/openjdk/jdk/blob/b8233989e7605268dda908e6b639ca373789792b/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp#L58-L62

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866062683

From shade at openjdk.org  Mon Dec  2 15:38:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 15:38:40 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <__bOt2JXoDga2Z0QbWNCfnT10sDK243O-bev3hK42v0=.fff374e7-96c6-48a9-b10e-02a0d7024d18@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <pFRPXBO26eJUOz9r67qt2KziqL74ECFqF3L5mu8HYEs=.f3777686-c492-4a73-8879-a54f9d3c33fd@github.com>
 <__bOt2JXoDga2Z0QbWNCfnT10sDK243O-bev3hK42v0=.fff374e7-96c6-48a9-b10e-02a0d7024d18@github.com>
Message-ID: <9O7QUHWwa_aJLJ1KWN_gLPNsXO6-WJlwC64LEN67Nkk=.458848ca-9104-4b2a-80b8-49d8759e822c@github.com>

On Mon, 2 Dec 2024 15:31:15 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Speaking of the valid ranges for SVE vector length, I don't think we want to blindly accept any `>0` value either. There is a block downwards that tries to check that vector length is not smaller than a `FloatRegister::sve_vl_min`, and that it is a power of two. But that block only works for manual overrides of `MaxVectorSize`. I say we co-opt that block for checking the `prctl` result on a common path. See new commit?
>
> I don't like `get_current_sve_vector_length` returning `-1`. IMO if you cannot use SVE calling it makes no sense.
> I see its doc mentions a negative result: https://github.com/openjdk/jdk/blob/b8233989e7605268dda908e6b639ca373789792b/src/hotspot/cpu/aarch64/vm_version_aarch64.hpp#L58-L62

Well, yes. But I don't quite get what are you suggesting? AFAICS, we don't know we are in `prctl`-is-forbidden mess until we actually try to do it in `get_current_sve_vector_length()`. Then we have to deal with the consequences of `prctl` returning `-1`, which is what this PR does.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866070291

From cnorrbin at openjdk.org  Mon Dec  2 15:46:15 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 2 Dec 2024 15:46:15 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
Message-ID: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>

Hi everyone,

This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.

The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.

Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks att all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.

For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

-------------

Commit messages:
 - removed whitespace
 - reverted vmatree
 - more feedback fixes
 - Merge branch 'master' into rb-tree
 - encoded color in black height
 - removed split/merge/update_key
 - find_enclosing_range and edit key
 - test changes
 - iterator
 - min/max fix
 - ... and 5 more: https://git.openjdk.org/jdk/compare/a032de29...1b45feaf

Changes: https://git.openjdk.org/jdk/pull/22360/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345314
  Stats: 1157 lines in 2 files changed: 1157 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From jsjolen at openjdk.org  Mon Dec  2 15:46:17 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 2 Dec 2024 15:46:17 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <--0jM8RJnB7JzFMOkbEbCFZtOQayMtfUPJispjZyDpc=.9f85d8a1-5de4-4698-984b-e7209853eeb9@github.com>

On Mon, 25 Nov 2024 13:11:52 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks att all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Initial review

src/hotspot/share/utilities/rbTree.hpp line 47:

> 45: 
> 46: private:
> 47:   enum Color { BLACK, RED };

`enum Color : uint8_t { BLACK, RED };`

Minimize to 1 byte

src/hotspot/share/utilities/rbTree.hpp line 60:

> 58:     RBNode* _left;
> 59:     RBNode* _right;
> 60:     unsigned int _black_height; // MSB encodes Red/Black, 0 - red, 1 - black

Suggestion: Use explicitly sized type `uint32_t`

src/hotspot/share/utilities/rbTree.hpp line 61:

> 59:     RBNode* _left;
> 60:     RBNode* _right;
> 61:     Color _color;

Move to the end, this avoids padding and might save us some memory.

src/hotspot/share/utilities/rbTree.hpp line 79:

> 77:     #endif // ASSERT
> 78:       _key = new_key;
> 79:     }

Seems unused? Kill it, it's too dangerous to be left alive!

src/hotspot/share/utilities/rbTree.hpp line 89:

> 87:       _black_height &= (-1U >> 1);
> 88:     }
> 89:     RBNode(const K& k, const V& v)

Space missing

src/hotspot/share/utilities/rbTree.hpp line 96:

> 94:       return _parent != nullptr && _parent->_right == this;
> 95:     }
> 96:     bool is_left_child() {

Space

src/hotspot/share/utilities/rbTree.hpp line 317:

> 315:   void fix_violations(RBNode* node) {
> 316:     if(node->is_black()) { // node's value was updated
> 317:       return;                    // Tree is already correct

Fix indentation of comment

src/hotspot/share/utilities/rbTree.hpp line 377:

> 375:   }
> 376: 
> 377:   void remove_inner(RBNode* node) {

Seems like this function is made to remove nodes whose color is black and whose removal would cause an imbalance. Maybe we can have a better name for this function or documentation, and also a few asserts?

src/hotspot/share/utilities/rbTree.hpp line 381:

> 379:     RBNode* parent = node->_parent;
> 380:     while (parent != nullptr) {
> 381:       RBNode* sibling = node->is_left_child() ? parent->_right : parent->_left;

I'm missing why this is guaranteed to not be null

src/hotspot/share/utilities/rbTree.hpp line 474:

> 472:     RBNode* parent = node->_parent;
> 473:     RBNode* left = node->_left;
> 474:     RBNode* right = node->_right;

We don't get that much usage out of these. If you make them references, or `RBNode*&`, then you can stop accessing `node->_left` etc and use these directly.

src/hotspot/share/utilities/rbTree.hpp line 475:

> 473:     RBNode* left = node->_left;
> 474:     RBNode* right = node->_right;
> 475:     if (left != nullptr) { // node has a left only-child

In each branch assert that the other child is missing. Document this assumption in a comment above the function (along with a rudimentary explanation). Also, add in the assertions regarding the nodes' color.

src/hotspot/share/utilities/rbTree.hpp line 482:

> 480:       node->_left->_parent = node->_parent;
> 481:       if (parent == nullptr) {
> 482:         _root = node->_left;

`assert` that node is root.

src/hotspot/share/utilities/rbTree.hpp line 710:

> 708:   }
> 709: 
> 710:   void insert(const K& k, const V& v) {

Why is `insert` needed on top of `upsert`?

src/hotspot/share/utilities/rbTree.hpp line 933:

> 931: 
> 932:     return true;
> 933:   }

I think these are *great* and I want them in. They might be difficult for some reviewers to accept, because they allow you to break stuff like node count. I know that I asked you to implement these, but I think it's best to remove them for now and add them back in a future PR. I'm sorry!!!

-------------

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2458414366
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1856601465
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865455956
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1856602354
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1856603838
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865456938
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865457281
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865616079
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865498056
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865527034
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865471302
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865465101
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865469976
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1856612496
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1856616952

From cnorrbin at openjdk.org  Mon Dec  2 15:46:17 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 2 Dec 2024 15:46:17 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <Coex7uB28U69Kdbubwf9onPzITJWyIdFmWDgYZ9-BVQ=.d1dfee14-934b-430c-bb2f-cdcb21efc4c9@github.com>

On Mon, 25 Nov 2024 13:11:52 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks att all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Thanks for the feedback ? I've made the changes requested

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2511872300

From jsjolen at openjdk.org  Mon Dec  2 15:46:17 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 2 Dec 2024 15:46:17 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
In-Reply-To: <--0jM8RJnB7JzFMOkbEbCFZtOQayMtfUPJispjZyDpc=.9f85d8a1-5de4-4698-984b-e7209853eeb9@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <--0jM8RJnB7JzFMOkbEbCFZtOQayMtfUPJispjZyDpc=.9f85d8a1-5de4-4698-984b-e7209853eeb9@github.com>
Message-ID: <51luW80qdEa_KOraIWxTr8aSpFk9TO3Yqx61LLLNruk=.d77597d3-d3de-4ac5-ba13-2039e0c6680c@github.com>

On Mon, 2 Dec 2024 08:51:55 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks att all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> src/hotspot/share/utilities/rbTree.hpp line 60:
> 
>> 58:     RBNode* _left;
>> 59:     RBNode* _right;
>> 60:     unsigned int _black_height; // MSB encodes Red/Black, 0 - red, 1 - black
> 
> Suggestion: Use explicitly sized type `uint32_t`

If you remove this, move the `color` to the end, after K and V.

> src/hotspot/share/utilities/rbTree.hpp line 61:
> 
>> 59:     RBNode* _left;
>> 60:     RBNode* _right;
>> 61:     Color _color;
> 
> Move to the end, this avoids padding and might save us some memory.

Actually, we could even use the MSB of `_black_height` to encode the red/black-ness of a node. 0 bytes used, then.

> src/hotspot/share/utilities/rbTree.hpp line 79:
> 
>> 77:     #endif // ASSERT
>> 78:       _key = new_key;
>> 79:     }
> 
> Seems unused? Kill it, it's too dangerous to be left alive!

If it's needed, save it for a future PR. We'll take the pain of getting it past reviewers then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1865723089
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1856625894
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1856626719

From cnorrbin at openjdk.org  Mon Dec  2 15:46:17 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Mon, 2 Dec 2024 15:46:17 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
In-Reply-To: <--0jM8RJnB7JzFMOkbEbCFZtOQayMtfUPJispjZyDpc=.9f85d8a1-5de4-4698-984b-e7209853eeb9@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <--0jM8RJnB7JzFMOkbEbCFZtOQayMtfUPJispjZyDpc=.9f85d8a1-5de4-4698-984b-e7209853eeb9@github.com>
Message-ID: <2bohfZduScE91QhuA1LW2gH94lzWYy1MRJf1Tk6f3so=.c6877b69-2494-4321-ad1b-c449161cd41e@github.com>

On Mon, 2 Dec 2024 09:19:55 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks att all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> src/hotspot/share/utilities/rbTree.hpp line 377:
> 
>> 375:   }
>> 376: 
>> 377:   void remove_inner(RBNode* node) {
> 
> Seems like this function is made to remove nodes whose color is black and whose removal would cause an imbalance. Maybe we can have a better name for this function or documentation, and also a few asserts?

Renamed to `remove_black_leaf()`

> src/hotspot/share/utilities/rbTree.hpp line 381:
> 
>> 379:     RBNode* parent = node->_parent;
>> 380:     while (parent != nullptr) {
>> 381:       RBNode* sibling = node->is_left_child() ? parent->_right : parent->_left;
> 
> I'm missing why this is guaranteed to not be null

Once we reach here, node is a leaf node and black, which means that a sibling has to exist to not cause a black-violation where the path through the sibling has one less black node.
I added an explaining comment + changed the function name to be clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1866077812
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1866076543

From eastigeevich at openjdk.org  Mon Dec  2 15:47:45 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 15:47:45 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <reFlUbR4kCUC18gwLHqoFX6n6-OGdtV_228xPM9QEUQ=.4508b841-d4fb-4f52-83e5-c7c371c70684@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <reFlUbR4kCUC18gwLHqoFX6n6-OGdtV_228xPM9QEUQ=.4508b841-d4fb-4f52-83e5-c7c371c70684@github.com>
Message-ID: <HNsVOYi_R-M41oTc5OMK0uTf-Qxj2JL1vqZchejK0GU=.4f211e9d-5e33-4078-bce0-7a61e0e0a42d@github.com>

On Mon, 2 Dec 2024 14:17:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 453:
>> 
>>> 451:     } else {
>>> 452:       _initial_sve_vector_length = vl;
>>> 453:     }
>> 
>> I think we need to disable SVE in `VM_Version::get_os_cpu_info` in `src/hotspot/os_cpu/linux_aarch64/vm_version_linux_aarch64.cpp`:
>> 
>> 
>>   if (auxv2 & HWCAP2_SVE2) _features |= CPU_SVE2;
>>   if (auxv2 & HWCAP2_SVEBITPERM) _features |= CPU_SVEBITPERM;
>> 
>>   if (prctl(PR_SVE_GET_VL) == -1) {
>>     warning("Unable to get SVE vector length on this system. Disabling SVE.");
>>     _features &= ~CPU_SVE;
>>   }
>
> I think this part later in the same method does the sync for us already:
> https://github.com/openjdk/jdk/blob/b8233989e7605268dda908e6b639ca373789792b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L590-L597

Maybe it's worth to move your new code under IF at line 518?

if (UseSVE > 0) {
  int vl = get_current_sve_vector_length();
  if ((FLAG_IS_DEFAULT(MaxVectorSize)) {
      MaxVectorSize = vl;
  }

  if (vl < 0) {
     warning("Unable to get SVE vector length on this system. Disabling SVE. Specify -XX:UseSVE=0 to avoid this warning.");
      FLAG_SET_DEFAULT(UseSVE, 0);
  } else if (MaxVectorSize < FloatRegister::sve_vl_min) {
      ...
  }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866087358

From eastigeevich at openjdk.org  Mon Dec  2 15:58:44 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 15:58:44 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <9O7QUHWwa_aJLJ1KWN_gLPNsXO6-WJlwC64LEN67Nkk=.458848ca-9104-4b2a-80b8-49d8759e822c@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <pFRPXBO26eJUOz9r67qt2KziqL74ECFqF3L5mu8HYEs=.f3777686-c492-4a73-8879-a54f9d3c33fd@github.com>
 <__bOt2JXoDga2Z0QbWNCfnT10sDK243O-bev3hK42v0=.fff374e7-96c6-48a9-b10e-02a0d7024d18@github.com>
 <9O7QUHWwa_aJLJ1KWN_gLPNsXO6-WJlwC64LEN67Nkk=.458848ca-9104-4b2a-80b8-49d8759e822c@github.com>
Message-ID: <lb7lZ3q7noBUmEYv3JVW7CjHzMcnzlAWGZvyfHnbtvg=.0130777a-cb28-4f73-b250-1ded2956354a@github.com>

On Mon, 2 Dec 2024 15:35:48 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> But I don't quite get what are you suggesting?

As the doc mentions a negative result, my suggestion to add an assert can be ignored.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866106934

From gziemski at openjdk.org  Mon Dec  2 16:00:48 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 2 Dec 2024 16:00:48 GMT
Subject: RFR: 8328944: NMT reports "unknown" memory [v2]
In-Reply-To: <gOgY8WianvtvdUezeU0iMihioxoN4JEhdscPeMIkAvk=.badfee4f-f4d6-4835-aa6d-b4bfa3ae41b6@github.com>
References: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
 <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com>
 <gOgY8WianvtvdUezeU0iMihioxoN4JEhdscPeMIkAvk=.badfee4f-f4d6-4835-aa6d-b4bfa3ae41b6@github.com>
Message-ID: <NpXGor-H932EK7Pn1DDvOMYYPhnudXS0hjb8rPErA6A=.65312f6b-340b-4789-acdb-e45531f3fa92@github.com>

On Wed, 20 Nov 2024 11:32:25 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - avoid using mtNone
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8328944
>>  - revert, we will re-do with a smaller change
>>  - remove more mtNone
>>  - remove API that allows to change the mem_tag for virtual memory, feedback
>>  - do not allow default parameter for mtNone
>
> Thanks for taking this issue. I add my points here:
> 
> 1) The `ReservedSpace` objects in these files have to have extra MemTag (`mtTest`) parameter:
>   - test_freeRegionList.cpp
>   - test_virtualspace.cpp
>   - test_virtualMemoryTracker.cpp
>  
> 2) The `mtNone` as default value for the parameter should be removed from the following functions, otherwise Unknown memory types can still be reported:
> 
> 
> 
> Source root ? src/hotspot/os/windows/os_windows.cpp:
>     3239: static char* map_or_reserve_memory_aligned(size_t size, size_t alignment, int file_desc, MemTag mem_tag = mtNone) {
>   3239    assert(is_aligned(alignment, os::vm_allocation_granularity()),
>   3240    assert(is_aligned(alignment, os::vm_allocation_granularity()),
> 
> Source root ? src/hotspot/share/cds/filemap.cpp:
>   1773                          char *addr, size_t bytes, bool read_only,
>   1774:                         bool allow_exec, MemTag mem_tag = mtNone) {
>   1775    char* mem = os::map_memory(fd, file_name, file_offset, addr, bytes,
> 
> Source root ? src/hotspot/share/memory/virtualspace.hpp:
>   63    void initialize(size_t size, size_t alignment, size_t page_size,
>   64    void initialize(size_t size, size_t alignment, size_t page_size,
>   65:                   char* requested_address, bool executable, MemTag mem_tag = mtNone);
>   65  
>   66  
> 
> Source root ? src/hotspot/share/nmt/memReporter.hpp:
>   110    void print_total(size_t reserved, size_t committed, size_t peak = 0) const;
>   111:   void print_malloc(const MemoryCounter* c, MemTag mem_tag = mtNone) const;
>   112    void print_virtual_memory(size_t reserved, size_t committed, size_t peak) const;
> 
> Source root ? src/hotspot/share/nmt/memTracker.hpp:
>   123    static inline void record_virtual_memory_reserve(void* addr, size_t size, const NativeCallStack& stack,
>   124:     MemTag mem_tag = mtNone) {
>   125      assert_post_init();
> 
>   149    static inline void record_virtual_memory_reserve_and_commit(void* addr, size_t size,
>   150:     const NativeCallStack& stack, MemTag mem_tag = mtNone) {
> 
> Source root ? src/hotspot/share/nmt/virtualMemoryTracker.hpp:
>   299    ReservedMemoryRegion(address base, size_t size, const NativeCallStack& stack,
>   300:     MemTag mem_tag = mtNone) :
> 
>   383:   static bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MemTag mem_tag = mtNone);
>   384  
> 
> Source root ? src/hotspot/share/runtime/os.hpp:
>   453:   static char*  reserve_memory(size_t bytes, bool executable = false, MemTag mem_tag = mtNone);
> 
>   46...

@afshin-zafari @tstuefe @stefank

ping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2511920933

From adinn at openjdk.org  Mon Dec  2 16:13:21 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 2 Dec 2024 16:13:21 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v8]
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <mHdxZMRYcxkSUwjwwizCh9ahgbXou8dF3S6HchR9ITU=.9beec8d2-8d38-4ff9-8c73-19b21f777365@github.com>

> Implementation of JDK-8343767

Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:

  increase compiler stub space for macos x86_64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21957/files
  - new: https://git.openjdk.org/jdk/pull/21957/files/8497b11e..a24ee57a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957

PR: https://git.openjdk.org/jdk/pull/21957

From adinn at openjdk.org  Mon Dec  2 16:18:07 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Mon, 2 Dec 2024 16:18:07 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
Message-ID: <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>

> Implementation of JDK-8343767

Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  increase compiler stub space for macos x86_64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21957/files
  - new: https://git.openjdk.org/jdk/pull/21957/files/a24ee57a..73b73c53

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21957&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21957/head:pull/21957

PR: https://git.openjdk.org/jdk/pull/21957

From shade at openjdk.org  Mon Dec  2 16:20:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 16:20:41 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <lb7lZ3q7noBUmEYv3JVW7CjHzMcnzlAWGZvyfHnbtvg=.0130777a-cb28-4f73-b250-1ded2956354a@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <pFRPXBO26eJUOz9r67qt2KziqL74ECFqF3L5mu8HYEs=.f3777686-c492-4a73-8879-a54f9d3c33fd@github.com>
 <__bOt2JXoDga2Z0QbWNCfnT10sDK243O-bev3hK42v0=.fff374e7-96c6-48a9-b10e-02a0d7024d18@github.com>
 <9O7QUHWwa_aJLJ1KWN_gLPNsXO6-WJlwC64LEN67Nkk=.458848ca-9104-4b2a-80b8-49d8759e822c@github.com>
 <lb7lZ3q7noBUmEYv3JVW7CjHzMcnzlAWGZvyfHnbtvg=.0130777a-cb28-4f73-b250-1ded2956354a@github.com>
Message-ID: <SngdTzNKsa1Nr84_Q8JuMyG0rvOP5T4foDXo0GLsp-w=.9f7b6d1d-a6bf-4f44-a451-22213cf265ea@github.com>

On Mon, 2 Dec 2024 15:55:59 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> As the doc mentions a negative result, my suggestion to add an assert can be ignored.

Where do you see this assert going?


  if (UseSVE > 0) {
    int vl = get_current_sve_vector_length();
    if (vl < 0) {
      warning("Unable to get SVE vector length on this system. Disabling SVE. Specify -XX:UseSVE=0 to shun this warning.");
      FLAG_SET_DEFAULT(UseSVE, 0);
    } else {
      _initial_sve_vector_length = vl;
    }
  }


We are already checking `< 0` path here. Checking for `> 0` formally does not follow the docs, because the call can formally return `0` without claiming this is an error. What we should be doing is testing the value `get_current_sve_vector_length()` giving us -- that I think is done in current PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866148715

From aph at openjdk.org  Mon Dec  2 16:25:44 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 16:25:44 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v2]
In-Reply-To: <6nTmn9_ttqyKgackXyVTY2CpQJ6L1nNBJez5exjEsaQ=.91ad67fa-cf61-47ca-a0ab-0bb3ff98733c@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <6nTmn9_ttqyKgackXyVTY2CpQJ6L1nNBJez5exjEsaQ=.91ad67fa-cf61-47ca-a0ab-0bb3ff98733c@github.com>
Message-ID: <QdVgqXyokPf3wl_sU7Q920Ysmt90GR7UiMTDwg8Teu8=.5d8c42d2-d756-4fe9-8939-bedc653c05c5@github.com>

On Mon, 2 Dec 2024 15:15:19 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22479#pullrequestreview-2473193848

From shade at openjdk.org  Mon Dec  2 16:37:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 16:37:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
Message-ID: <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>

> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
> 
> 
> int VM_Version::get_current_sve_vector_length() {
>   assert(VM_Version::supports_sve(), "should not call this");
>   return prctl(PR_SVE_GET_VL);
> }
> 
> 
> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Handle zero too
 - Check get_current_sve_vector_length more comprehensively

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22479/files
  - new: https://git.openjdk.org/jdk/pull/22479/files/be5805b6..5777379a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=01-02

  Stats: 9 lines in 1 file changed: 6 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22479/head:pull/22479

PR: https://git.openjdk.org/jdk/pull/22479

From shade at openjdk.org  Mon Dec  2 16:37:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 16:37:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <HNsVOYi_R-M41oTc5OMK0uTf-Qxj2JL1vqZchejK0GU=.4f211e9d-5e33-4078-bce0-7a61e0e0a42d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <reFlUbR4kCUC18gwLHqoFX6n6-OGdtV_228xPM9QEUQ=.4508b841-d4fb-4f52-83e5-c7c371c70684@github.com>
 <HNsVOYi_R-M41oTc5OMK0uTf-Qxj2JL1vqZchejK0GU=.4f211e9d-5e33-4078-bce0-7a61e0e0a42d@github.com>
Message-ID: <IRVlWC1l4afOOfKrQtgbyx94JOFMr0sNQ9R9zseEZqk=.1942c41b-668d-4c98-a2f1-8e9c73a5fb8f@github.com>

On Mon, 2 Dec 2024 15:44:56 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> I think this part later in the same method does the sync for us already:
>> https://github.com/openjdk/jdk/blob/b8233989e7605268dda908e6b639ca373789792b/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L590-L597
>
> Maybe it's worth to move your new code under IF at line 518?
> 
> if (UseSVE > 0) {
>   int vl = get_current_sve_vector_length();
>   if ((FLAG_IS_DEFAULT(MaxVectorSize)) {
>       MaxVectorSize = vl;
>   }
> 
>   if (vl < 0) {
>      warning("Unable to get SVE vector length on this system. Disabling SVE. Specify -XX:UseSVE=0 to avoid this warning.");
>       FLAG_SET_DEFAULT(UseSVE, 0);
>   } else if (MaxVectorSize < FloatRegister::sve_vl_min) {
>       ...
>   }

Aha. I think the other way around: we need to do more checks right near the `_initial_sve_vector_length` inits. Hold on...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866168695

From shade at openjdk.org  Mon Dec  2 16:37:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 16:37:04 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <IRVlWC1l4afOOfKrQtgbyx94JOFMr0sNQ9R9zseEZqk=.1942c41b-668d-4c98-a2f1-8e9c73a5fb8f@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <reFlUbR4kCUC18gwLHqoFX6n6-OGdtV_228xPM9QEUQ=.4508b841-d4fb-4f52-83e5-c7c371c70684@github.com>
 <HNsVOYi_R-M41oTc5OMK0uTf-Qxj2JL1vqZchejK0GU=.4f211e9d-5e33-4078-bce0-7a61e0e0a42d@github.com>
 <IRVlWC1l4afOOfKrQtgbyx94JOFMr0sNQ9R9zseEZqk=.1942c41b-668d-4c98-a2f1-8e9c73a5fb8f@github.com>
Message-ID: <G4LCnstMSn-9hw5B9za920GnK9HzfpzgXugb7g-JoMc=.c2ef0c44-ee9b-4520-bf46-f0dd854a698f@github.com>

On Mon, 2 Dec 2024 16:30:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Maybe it's worth to move your new code under IF at line 518?
>> 
>> if (UseSVE > 0) {
>>   int vl = get_current_sve_vector_length();
>>   if ((FLAG_IS_DEFAULT(MaxVectorSize)) {
>>       MaxVectorSize = vl;
>>   }
>> 
>>   if (vl < 0) {
>>      warning("Unable to get SVE vector length on this system. Disabling SVE. Specify -XX:UseSVE=0 to avoid this warning.");
>>       FLAG_SET_DEFAULT(UseSVE, 0);
>>   } else if (MaxVectorSize < FloatRegister::sve_vl_min) {
>>       ...
>>   }
>
> Aha. I think the other way around: we need to do more checks right near the `_initial_sve_vector_length` inits. Hold on...

See new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866173285

From shade at openjdk.org  Mon Dec  2 16:46:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 16:46:43 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <SngdTzNKsa1Nr84_Q8JuMyG0rvOP5T4foDXo0GLsp-w=.9f7b6d1d-a6bf-4f44-a451-22213cf265ea@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <z9JGe5EDEz9motdmYONbClh5GGHHvOoaDL32-HvvuCI=.c1c3603f-d37b-4f8c-8380-c9dfaf0f527c@github.com>
 <pFRPXBO26eJUOz9r67qt2KziqL74ECFqF3L5mu8HYEs=.f3777686-c492-4a73-8879-a54f9d3c33fd@github.com>
 <__bOt2JXoDga2Z0QbWNCfnT10sDK243O-bev3hK42v0=.fff374e7-96c6-48a9-b10e-02a0d7024d18@github.com>
 <9O7QUHWwa_aJLJ1KWN_gLPNsXO6-WJlwC64LEN67Nkk=.458848ca-9104-4b2a-80b8-49d8759e822c@github.com>
 <lb7lZ3q7noBUmEYv3JVW7CjHzMcnzlAWGZvyfHnbtvg=.0130777a-cb28-4f73-b250-1ded2956354a@github.com>
 <SngdTzNKsa1Nr84_Q8JuMyG0rvOP5T4foDXo0GLsp-w=.9f7b6d1d-a6bf-4f44-a451-22213cf265ea@github.com>
Message-ID: <3VPKkP9r7f8pmyjDqy0lJLOMHtO5nBDMGPw2YeNDwms=.219c6a9d-1df8-4c70-9fb8-282a6e61beb3@github.com>

On Mon, 2 Dec 2024 16:18:14 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> But I don't quite get what are you suggesting?
>> 
>> As the doc mentions a negative result, my suggestion to add an assert can be ignored.
>
>> As the doc mentions a negative result, my suggestion to add an assert can be ignored.
> 
> Where do you see this assert going?
> 
> 
>   if (UseSVE > 0) {
>     int vl = get_current_sve_vector_length();
>     if (vl < 0) {
>       warning("Unable to get SVE vector length on this system. Disabling SVE. Specify -XX:UseSVE=0 to shun this warning.");
>       FLAG_SET_DEFAULT(UseSVE, 0);
>     } else {
>       _initial_sve_vector_length = vl;
>     }
>   }
> 
> 
> We are already checking `< 0` path here. Checking for `> 0` formally does not follow the docs, because the call can formally return `0` without claiming this is an error. What we should be doing is testing the value `get_current_sve_vector_length()` giving us -- that I think is done in current PR.

New commit adds more comprehensive checks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866204286

From rehn at openjdk.org  Mon Dec  2 17:16:13 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 17:16:13 GMT
Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v4]
In-Reply-To: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
Message-ID: <F6rDRSIAJlZT8KPcR3Hc9PqXo3VLW8IWMrjt3xWlkLQ=.d52a0fa6-b7d8-4a91-8955-369949469a71@github.com>

> Hi, please consider.
> 
> This adds tests of aligned narrow cmpxchg.
> 
> 
> Note: Google Test filter = *RiscV*
> [==========] Running 5 tests from 1 test suite.
> [----------] Global test environment set-up.
> [----------] 5 tests from RiscV
> ...
> [ RUN      ] RiscV.cmpxchg_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms)
> [ RUN      ] RiscV.cmpxchg_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms)
> [ RUN      ] RiscV.cmpxchg_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms)
> [----------] 5 tests from RiscV (20831 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 5 tests from 1 test suite ran. (20834 ms total)
> [  PASSED  ] 5 tests.
> 
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into narrow
 - Review comment
 - Remove CMF barrier
 - gtest narrow cmpxchg

-------------

Changes: https://git.openjdk.org/jdk/pull/22445/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22445&range=03
  Stats: 81 lines in 1 file changed: 81 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22445.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22445/head:pull/22445

PR: https://git.openjdk.org/jdk/pull/22445

From aph at openjdk.org  Mon Dec  2 17:20:48 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 17:20:48 GMT
Subject: RFR: 8337251: C1: Improve Class.isInstance intrinsic
Message-ID: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>

This replaces a runtime call to `Runtime1::is_instance_of()` by a platform-dependent C1 intrinsic.

This improves overall performance significantly. and it minimizes icache footprint.

The original commit contains this comment:


  // TODO could try to substitute this node with an equivalent InstanceOf
  // if clazz is known to be a constant Class. This will pick up newly found
  // constants after HIR construction. I'll leave this to a future change.



However, there's little performance to be gained by restricting this optimization to constant Class instances, and after this this patch, C1 `Class.isInstance()` compares favorably with the current platform-dependent `instanceof` intrinsic.

It's not strictly necessary for other platforms to implement this optimization.

Performance:

Xeon-E5 2430, before and after::


Benchmark                               Score    Error       Score     Error  Units
SecondarySupersLookup.testNegative00   11.783 ?  0.491      10.459 ?   0.183  ns/op
SecondarySupersLookup.testNegative01   11.757 ?  0.127      10.475 ?   0.661  ns/op
SecondarySupersLookup.testNegative02   11.771 ?  0.700      10.479 ?   0.357  ns/op
SecondarySupersLookup.testNegative55   23.997 ?  1.816      16.854 ?   1.034  ns/op
SecondarySupersLookup.testNegative60   29.598 ?  1.326      26.828 ?   0.637  ns/op
SecondarySupersLookup.testNegative63   74.528 ?  3.157      69.431 ?   0.357  ns/op
SecondarySupersLookup.testNegative64   75.936 ?  1.805      70.124 ?   0.397  ns/op

SecondarySupersLookup.testPositive01   15.257 ?  1.179       9.722 ?   0.326  ns/op
SecondarySupersLookup.testPositive02   15.164 ?  1.383       9.737 ?   0.708  ns/op
SecondarySupersLookup.testPositive03   15.166 ?  0.934       9.726 ?   0.184  ns/op
SecondarySupersLookup.testPositive40   20.384 ?  0.530      12.805 ?   0.778  ns/op
SecondarySupersLookup.testPositive50   15.118 ?  0.140       9.735 ?   0.555  ns/op
SecondarySupersLookup.testPositive60   20.415 ?  3.083      11.603 ?   0.106  ns/op
SecondarySupersLookup.testPositive63   65.478 ?  8.484      58.507 ?   2.837  ns/op
SecondarySupersLookup.testPositive64   75.880 ?  1.047      68.667 ?   1.347  ns/op


AArch64 (Apple M1)


Benchmark                              Score   Error   Score   Error  Units
SecondarySupersLookup.testNegative00   4.139 ? 0.005   2.815 ? 0.014  ns/op
SecondarySupersLookup.testNegative01   4.071 ? 0.153   2.826 ? 0.291  ns/op
SecondarySupersLookup.testNegative02   4.089 ? 0.752   2.817 ? 0.028  ns/op
SecondarySupersLookup.testNegative55   7.191 ? 0.041   4.704 ? 0.036  ns/op
SecondarySupersLookup.testNegative60  10.712 ? 0.107   7.686 ? 0.763  ns/op
SecondarySupersLookup.testNegative63  28.270 ? 1.294  23.756 ? 0.026  ns/op
SecondarySupersLookup.testNegative64  28.618 ? 0.334  24.084 ? 0.238  ns/op

SecondarySupersLookup.testPositive01   4.379 ? 0.042   2.989 ? 0.600  ns/op
SecondarySupersLookup.testPositive02   4.462 ? 0.028   3.036 ? 0.261  ns/op
SecondarySupersLookup.testPositive03   4.749 ? 0.934   2.989 ? 0.586  ns/op
SecondarySupersLookup.testPositive40   5.352 ? 0.997   3.482 ? 0.696  ns/op
SecondarySupersLookup.testPositive50   4.435 ? 0.832   2.989 ? 0.571  ns/op
SecondarySupersLookup.testPositive60   5.349 ? 1.050   3.482 ? 0.680  ns/op
SecondarySupersLookup.testPositive63  23.879 ? 0.200  19.743 ? 1.668  ns/op
SecondarySupersLookup.testPositive64  28.340 ? 0.190  24.106 ? 0.454  ns/op

-------------

Commit messages:
 - Remove obsolete comment
 - Cleanup
 - Cleanup
 - Merge branch 'JDK-8337251' of https://github.com/theRealAph/jdk into JDK-8337251
 - AArch64
 - Temp
 - More
 - More
 - More
 - Merge branch 'clean' into JDK-8337251
 - ... and 6 more: https://git.openjdk.org/jdk/compare/d589bafe...ae6e2355

Changes: https://git.openjdk.org/jdk/pull/22491/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22491&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337251
  Stats: 102 lines in 5 files changed: 94 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22491/head:pull/22491

PR: https://git.openjdk.org/jdk/pull/22491

From eastigeevich at openjdk.org  Mon Dec  2 17:23:48 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 17:23:48 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
Message-ID: <XAmyWlMG0WnNxnDHn82vkhrYDLqmwwow58nr_aox0xE=.eec431da-fb74-4292-a8e8-7455163adca5@github.com>

On Mon, 2 Dec 2024 16:37:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Handle zero too
>  - Check get_current_sve_vector_length more comprehensively

src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 452:

> 450:               "Disabling SVE. Specify -XX:UseSVE=0 to shun this warning.");
> 451:       FLAG_SET_DEFAULT(UseSVE, 0);
> 452:     } else if (vl < FloatRegister::sve_vl_min || ((vl % FloatRegister::sve_vl_min) != 0) || !is_power_of_2(vl)) {

I think `vl < FloatRegister::sve_vl_min` is redundant.
It is covered by `vl % FloatRegister::sve_vl_min) != 0`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866284225

From rehn at openjdk.org  Mon Dec  2 17:27:12 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 17:27:12 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v2]
In-Reply-To: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
Message-ID: <DEkYoWWmMBaZ9z4v1c4zDspCIeBunVYZzsg40j_yIHg=.22f4185a-f765-47f3-8546-ec6937a2dc85@github.com>

> Hi, please consider.
> 
> This adds tests of aligned weak narrow cmpxchg.
> 
> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20997 ms total)
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into weak_narrow
 - gtest weak narrow cmpxchg

-------------

Changes: https://git.openjdk.org/jdk/pull/22476/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=01
  Stats: 74 lines in 1 file changed: 74 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22476/head:pull/22476

PR: https://git.openjdk.org/jdk/pull/22476

From eastigeevich at openjdk.org  Mon Dec  2 17:29:42 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 17:29:42 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
Message-ID: <wovDeoiQMa5ts0W22jd4a9Zlr80DvnTETLbt15aWrmE=.82dee718-6b66-4c41-a5a5-fe1d7b8347bd@github.com>

On Mon, 2 Dec 2024 16:37:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Handle zero too
>  - Check get_current_sve_vector_length more comprehensively

lgtm

-------------

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22479#pullrequestreview-2473410074

From shade at openjdk.org  Mon Dec  2 17:29:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 17:29:43 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <XAmyWlMG0WnNxnDHn82vkhrYDLqmwwow58nr_aox0xE=.eec431da-fb74-4292-a8e8-7455163adca5@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
 <XAmyWlMG0WnNxnDHn82vkhrYDLqmwwow58nr_aox0xE=.eec431da-fb74-4292-a8e8-7455163adca5@github.com>
Message-ID: <ofoVv0KZvCOclZ5Rd8qAeG64mNt6vqvcGMB2AVkE1Gw=.6ec53d0e-cddc-40e1-980e-3aa667ae3620@github.com>

On Mon, 2 Dec 2024 17:21:19 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Handle zero too
>>  - Check get_current_sve_vector_length more comprehensively
>
> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 452:
> 
>> 450:               "Disabling SVE. Specify -XX:UseSVE=0 to shun this warning.");
>> 451:       FLAG_SET_DEFAULT(UseSVE, 0);
>> 452:     } else if (vl < FloatRegister::sve_vl_min || ((vl % FloatRegister::sve_vl_min) != 0) || !is_power_of_2(vl)) {
> 
> I think `vl < FloatRegister::sve_vl_min` is redundant.
> It is covered by `vl % FloatRegister::sve_vl_min) != 0`.

I thought so too, but it is not, if `vl == 0`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866288142

From eastigeevich at openjdk.org  Mon Dec  2 17:29:43 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 17:29:43 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <ofoVv0KZvCOclZ5Rd8qAeG64mNt6vqvcGMB2AVkE1Gw=.6ec53d0e-cddc-40e1-980e-3aa667ae3620@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
 <XAmyWlMG0WnNxnDHn82vkhrYDLqmwwow58nr_aox0xE=.eec431da-fb74-4292-a8e8-7455163adca5@github.com>
 <ofoVv0KZvCOclZ5Rd8qAeG64mNt6vqvcGMB2AVkE1Gw=.6ec53d0e-cddc-40e1-980e-3aa667ae3620@github.com>
Message-ID: <yr91HtmBer4dHgG12dv-LLCfNehgUy7Tb4JXVCsvWnY=.a811faff-d627-443e-abff-74b836f496d5@github.com>

On Mon, 2 Dec 2024 17:24:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 452:
>> 
>>> 450:               "Disabling SVE. Specify -XX:UseSVE=0 to shun this warning.");
>>> 451:       FLAG_SET_DEFAULT(UseSVE, 0);
>>> 452:     } else if (vl < FloatRegister::sve_vl_min || ((vl % FloatRegister::sve_vl_min) != 0) || !is_power_of_2(vl)) {
>> 
>> I think `vl < FloatRegister::sve_vl_min` is redundant.
>> It is covered by `vl % FloatRegister::sve_vl_min) != 0`.
>
> I thought so too, but it is not, if `vl == 0`?

It covers the case: `vl == 0`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866291313

From vladimir.kozlov at oracle.com  Mon Dec  2 17:33:53 2024
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 2 Dec 2024 09:33:53 -0800
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas
In-Reply-To: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
References: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
Message-ID: <b0e87091-9f8f-43d9-a5a3-78cacd9698d6@oracle.com>

Vote: yes

Thanks,
Vladimir K

On 11/27/24 3:26 AM, Stefan Karlsson wrote:
> I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group.
> 
> Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now.
> 
> Votes are due by 2024-12-11T12:24+01:00.
> 
> Only current Members of the HotSpot Group [1] are eligible
> to vote on this nomination.? Votes must be cast in the open by
> replying to this mailing list
> 
> For Lazy Consensus voting instructions, see [2].
> 
> Stefan Karlsson
> 
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


From shade at openjdk.org  Mon Dec  2 17:39:02 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 17:39:02 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v4]
In-Reply-To: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
Message-ID: <oS1jKAuFMe--1sprGSLkyss314wobFbLBo45stAVWOk=.d6675efe-0f32-41a1-913a-509028fb8a12@github.com>

> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
> 
> 
> int VM_Version::get_current_sve_vector_length() {
>   assert(VM_Version::supports_sve(), "should not call this");
>   return prctl(PR_SVE_GET_VL);
> }
> 
> 
> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Simplify the condition: zero is handled by is_power_of_two

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22479/files
  - new: https://git.openjdk.org/jdk/pull/22479/files/5777379a..16bde2b1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22479/head:pull/22479

PR: https://git.openjdk.org/jdk/pull/22479

From aph at openjdk.org  Mon Dec  2 17:39:02 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 17:39:02 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v4]
In-Reply-To: <oS1jKAuFMe--1sprGSLkyss314wobFbLBo45stAVWOk=.d6675efe-0f32-41a1-913a-509028fb8a12@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oS1jKAuFMe--1sprGSLkyss314wobFbLBo45stAVWOk=.d6675efe-0f32-41a1-913a-509028fb8a12@github.com>
Message-ID: <un-EnyK4QqXY5PkDu1VmCIfcy2BGT1FXBuAyNwB1Eqs=.e83c69ed-4424-40b2-aaaf-a21047125525@github.com>

On Mon, 2 Dec 2024 17:36:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify the condition: zero is handled by is_power_of_two

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22479#pullrequestreview-2473429923

From eastigeevich at openjdk.org  Mon Dec  2 17:39:03 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 17:39:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v4]
In-Reply-To: <oS1jKAuFMe--1sprGSLkyss314wobFbLBo45stAVWOk=.d6675efe-0f32-41a1-913a-509028fb8a12@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oS1jKAuFMe--1sprGSLkyss314wobFbLBo45stAVWOk=.d6675efe-0f32-41a1-913a-509028fb8a12@github.com>
Message-ID: <yQmZDJa-xLiv2QLhgatTbdRDNLP3SaUOo6sPHCHeSNo=.a00adf36-1525-46e7-a4fd-da137c24790a@github.com>

On Mon, 2 Dec 2024 17:36:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify the condition: zero is handled by is_power_of_two

lgtm

-------------

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22479#pullrequestreview-2473432775

From shade at openjdk.org  Mon Dec  2 17:39:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 17:39:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
Message-ID: <SuConW7UdXBbrivtdZFyBMB0bg3u34m1MnG1uMxc8pE=.85e46cdc-ca7b-4c3b-8818-e43106429b93@github.com>

On Mon, 2 Dec 2024 16:37:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Handle zero too
>  - Check get_current_sve_vector_length more comprehensively

Thanks for reviews! I kicked off a test run again, and if it is clean, I would be able to integrate it tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2512249348

From aph at openjdk.org  Mon Dec  2 17:39:03 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 2 Dec 2024 17:39:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
Message-ID: <xrwcF86RBpjIclHYBUOJ6VbAyUMGrvrLVdI2V9xsFjU=.f85f986f-c4d7-4db7-ac14-cf1fbe558e8b@github.com>

On Mon, 2 Dec 2024 16:37:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Handle zero too
>  - Check get_current_sve_vector_length more comprehensively

On 12/2/24 17:33, Evgeny Astigeevich wrote:
> Yes, our implementation of |is_power_of_2| returns |false| for 0.

Even if it does, callers shouldn't depend on that. Someone might fix it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2512249467

From eastigeevich at openjdk.org  Mon Dec  2 17:39:03 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 17:39:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <yr91HtmBer4dHgG12dv-LLCfNehgUy7Tb4JXVCsvWnY=.a811faff-d627-443e-abff-74b836f496d5@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
 <XAmyWlMG0WnNxnDHn82vkhrYDLqmwwow58nr_aox0xE=.eec431da-fb74-4292-a8e8-7455163adca5@github.com>
 <ofoVv0KZvCOclZ5Rd8qAeG64mNt6vqvcGMB2AVkE1Gw=.6ec53d0e-cddc-40e1-980e-3aa667ae3620@github.com>
 <yr91HtmBer4dHgG12dv-LLCfNehgUy7Tb4JXVCsvWnY=.a811faff-d627-443e-abff-74b836f496d5@github.com>
Message-ID: <56fuCk8YhqjSavq_KaUunojdj1KZd3giTgHSkUdlhLo=.7ae546ab-065b-4991-8e79-bc9ca65a06d8@github.com>

On Mon, 2 Dec 2024 17:26:19 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> I thought so too, but it is not, if `vl == 0`?
>
> It covers the case: `vl == 0`.

According to https://man7.org/linux/man-pages/man2/prctl.2.html, `prctl` returns a nonnegative value. So we need to check `vl` for zero.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866297025

From shade at openjdk.org  Mon Dec  2 17:39:03 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 17:39:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <56fuCk8YhqjSavq_KaUunojdj1KZd3giTgHSkUdlhLo=.7ae546ab-065b-4991-8e79-bc9ca65a06d8@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
 <XAmyWlMG0WnNxnDHn82vkhrYDLqmwwow58nr_aox0xE=.eec431da-fb74-4292-a8e8-7455163adca5@github.com>
 <ofoVv0KZvCOclZ5Rd8qAeG64mNt6vqvcGMB2AVkE1Gw=.6ec53d0e-cddc-40e1-980e-3aa667ae3620@github.com>
 <yr91HtmBer4dHgG12dv-LLCfNehgUy7Tb4JXVCsvWnY=.a811faff-d627-443e-abff-74b836f496d5@github.com>
 <56fuCk8YhqjSavq_KaUunojdj1KZd3giTgHSkUdlhLo=.7ae546ab-065b-4991-8e79-bc9ca65a06d8@github.com>
Message-ID: <FurzcC_kFcTUsjsbtDr2iNQH-b9gF1xMZ71wmhEBwns=.688cd384-dff8-4d97-bfec-2d7f136575d6@github.com>

On Mon, 2 Dec 2024 17:30:03 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> It covers the case: `vl == 0`.
>
> According to https://man7.org/linux/man-pages/man2/prctl.2.html, `prctl` returns a nonnegative value. So we need to check `vl` for zero.

How? `0 < 16` => `TRUE`, but `(0 % 16) != 0` => `FALSE`.
What I can see is that `0` is covered by `is_power_of_2`, however.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866297191

From eastigeevich at openjdk.org  Mon Dec  2 17:39:03 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 17:39:03 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <FurzcC_kFcTUsjsbtDr2iNQH-b9gF1xMZ71wmhEBwns=.688cd384-dff8-4d97-bfec-2d7f136575d6@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
 <XAmyWlMG0WnNxnDHn82vkhrYDLqmwwow58nr_aox0xE=.eec431da-fb74-4292-a8e8-7455163adca5@github.com>
 <ofoVv0KZvCOclZ5Rd8qAeG64mNt6vqvcGMB2AVkE1Gw=.6ec53d0e-cddc-40e1-980e-3aa667ae3620@github.com>
 <yr91HtmBer4dHgG12dv-LLCfNehgUy7Tb4JXVCsvWnY=.a811faff-d627-443e-abff-74b836f496d5@github.com>
 <56fuCk8YhqjSavq_KaUunojdj1KZd3giTgHSkUdlhLo=.7ae546ab-065b-4991-8e79-bc9ca65a06d8@github.com>
 <FurzcC_kFcTUsjsbtDr2iNQH-b9gF1xMZ71wmhEBwns=.688cd384-dff8-4d97-bfec-2d7f136575d6@github.com>
Message-ID: <GPSnv4mIXjP1T4nNKnU-J3TrbEiQ4uH131rKZSDcvws=.cf47471c-c688-48cd-9ad5-17e57900734c@github.com>

On Mon, 2 Dec 2024 17:30:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> According to https://man7.org/linux/man-pages/man2/prctl.2.html, `prctl` returns a nonnegative value. So we need to check `vl` for zero.
>
> How? `0 < 16` => `TRUE`, but `(0 % 16) != 0` => `FALSE`.
> What I can see is that `0` is covered by `is_power_of_2`, however.

Yes, our implementation of `is_power_of_2` returns `false` for 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22479#discussion_r1866302171

From rehn at openjdk.org  Mon Dec  2 17:46:16 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 2 Dec 2024 17:46:16 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v3]
In-Reply-To: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
Message-ID: <R4eGHUXGY-fQUdIFQ0mr9pzex9ttSybXCRbvJAI8tUQ=.f09f9247-1601-43e8-b50c-02b874d061ed@github.com>

> Hi, please consider.
> 
> This adds tests of aligned weak narrow cmpxchg.
> 
> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20997 ms total)
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Added weak 4/8 byte cmpxchg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22476/files
  - new: https://git.openjdk.org/jdk/pull/22476/files/66cdf740..bb43ec8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=01-02

  Stats: 68 lines in 1 file changed: 58 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22476/head:pull/22476

PR: https://git.openjdk.org/jdk/pull/22476

From shade at openjdk.org  Mon Dec  2 17:49:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 17:49:01 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <xrwcF86RBpjIclHYBUOJ6VbAyUMGrvrLVdI2V9xsFjU=.f85f986f-c4d7-4db7-ac14-cf1fbe558e8b@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
 <xrwcF86RBpjIclHYBUOJ6VbAyUMGrvrLVdI2V9xsFjU=.f85f986f-c4d7-4db7-ac14-cf1fbe558e8b@github.com>
Message-ID: <7030J4OPnioM1nGgjcW2CUslcYanHJU_TuXp88gNwI8=.d8f37c11-76a2-49a2-a93d-72c2dbbb571d@github.com>

On Mon, 2 Dec 2024 17:36:06 GMT, Andrew Haley <aph at openjdk.org> wrote:

> On 12/2/24 17:33, Evgeny Astigeevich wrote: Yes, our implementation of |is_power_of_2| returns |false| for 0.
> Even if it does, callers shouldn't depend on that. Someone might fix it.

Honestly, let's just test for `== 0` directly to close the gap that `%` exposes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2512267465

From shade at openjdk.org  Mon Dec  2 17:49:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 17:49:01 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v5]
In-Reply-To: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
Message-ID: <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>

> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
> 
> 
> int VM_Version::get_current_sve_vector_length() {
>   assert(VM_Version::supports_sve(), "should not call this");
>   return prctl(PR_SVE_GET_VL);
> }
> 
> 
> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>  - [ ] Linux AArch64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Do the explicit == 0 check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22479/files
  - new: https://git.openjdk.org/jdk/pull/22479/files/16bde2b1..58f06aec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22479&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22479.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22479/head:pull/22479

PR: https://git.openjdk.org/jdk/pull/22479

From eastigeevich at openjdk.org  Mon Dec  2 18:01:40 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 18:01:40 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v3]
In-Reply-To: <7030J4OPnioM1nGgjcW2CUslcYanHJU_TuXp88gNwI8=.d8f37c11-76a2-49a2-a93d-72c2dbbb571d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <WuHQw-8SqHzCuoIrDkFrFccIQ4vvP4K3K2TWYfD5pRY=.cf933b16-2bee-48b1-b3e3-0b4399fd8c18@github.com>
 <xrwcF86RBpjIclHYBUOJ6VbAyUMGrvrLVdI2V9xsFjU=.f85f986f-c4d7-4db7-ac14-cf1fbe558e8b@github.com>
 <7030J4OPnioM1nGgjcW2CUslcYanHJU_TuXp88gNwI8=.d8f37c11-76a2-49a2-a93d-72c2dbbb571d@github.com>
Message-ID: <B506ir8xLeHYn_ObJWYwEAHM2ZyklitmAdqB0fVa46o=.d3d675e2-7eb2-4ad3-b259-8bf6ebbfeeaf@github.com>

On Mon, 2 Dec 2024 17:45:07 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > On 12/2/24 17:33, Evgeny Astigeevich wrote: Yes, our implementation of |is_power_of_2| returns |false| for 0.
> > Even if it does, callers shouldn't depend on that. Someone might fix it.
> 
> Honestly, let's just test for `== 0` directly to close the gap that `%` exposes.

Maybe my math is too rusty :)

`2^x` cannot be zero for any integer `x >= 0`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2512293330

From eastigeevich at openjdk.org  Mon Dec  2 18:01:41 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 18:01:41 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v5]
In-Reply-To: <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
Message-ID: <f-NjmAbk_TSRf4XLNdOJawTv-vM6CzmQYoFOIEALB7w=.3e48ed8a-73c1-470e-857b-278f5d6bf51d@github.com>

On Mon, 2 Dec 2024 17:49:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do the explicit == 0 check

So `is_power_of_2(0)` is always false independent of its implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2512298113

From shade at openjdk.org  Mon Dec  2 18:18:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 18:18:40 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v5]
In-Reply-To: <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
Message-ID: <oehtJvHCQPeeory0j1OlerEgCQrlNrwIGWH12LQ8-Zw=.e6c43ff9-b673-4b72-93c2-79a03be86fa8@github.com>

On Mon, 2 Dec 2024 17:49:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do the explicit == 0 check

I prefer not to think about these gaps, and instead test for them directly. If anyone removes `is_power_of_2` later, they would need to remember (somehow) that `== 0` case should be handled too. Explicit test is cleaner intention-wise. Let's not spend more time on this, if we can :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2512334746

From eastigeevich at openjdk.org  Mon Dec  2 18:35:42 2024
From: eastigeevich at openjdk.org (Evgeny Astigeevich)
Date: Mon, 2 Dec 2024 18:35:42 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v5]
In-Reply-To: <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
Message-ID: <u03gSH326r33F1FsD2jvLUrJDmWQaOQh0NPzxKj__8s=.23dc57b7-e7c8-4313-b841-47722592c46f@github.com>

On Mon, 2 Dec 2024 17:49:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [ ] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do the explicit == 0 check

lgtm

-------------

Marked as reviewed by eastigeevich (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22479#pullrequestreview-2473561013

From alanb at openjdk.org  Mon Dec  2 18:37:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Dec 2024 18:37:52 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <v4ZLCB34Y0sGB3jp2PQ0lgrp0j98vzIFJfBtqUvHmEg=.b8ba98e6-3c5b-49aa-bb1e-e054d705061e@github.com>

On Thu, 7 Nov 2024 21:38:28 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

src/hotspot/share/runtime/threads.cpp line 654:

> 652:   initialize_java_lang_classes(main_thread, CHECK_JNI_ERR);
> 653:   // Update the java.vm.vendor property with java.lang.VersionProps.VM_VENDOR
> 654:   Arguments::update_vm_vendor(VM_Version::vm_vendor());

It seems very ad hoc to update this after initPhase1 has run, need to think through if there is a better way to do this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1866392413

From alanb at openjdk.org  Mon Dec  2 18:43:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 2 Dec 2024 18:43:43 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <UnDnPUetpeDdB_t24QbjT6XXx_ZK_l8MJrRvqpQXAhc=.52238613-4b53-4dca-aed2-4b9e27fdef96@github.com>

On Thu, 7 Nov 2024 21:38:28 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

src/java.base/share/classes/java/lang/VersionProps.java.template line 131:

> 129:         // Default branding.conf value is "N/A", which did not affect java.vm.vendor
> 130:         if (! VENDOR_VM.equals("N/A")) {
> 131:             props.put("java.vm.vendor", VENDOR_VM);

Magnus might have suggestions on this, maybe it would be better to default in the conf file to the empty string so that we don't have to deal with "N/A" in several places.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1866399627

From jiangli at openjdk.org  Mon Dec  2 18:46:49 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 2 Dec 2024 18:46:49 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v21]
In-Reply-To: <dFiqxG440j4xzNPMtKA_QGFTr55mZHLXp4LmTD9oQ9c=.00e7f697-1d96-48ea-bb2c-a3894185b1de@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <DhafIjNC2lndUqMWFckNSY_crKIV_4j5zcuAD9tvpVw=.dbadee9c-ae79-4ef1-af6c-7192cd040df0@github.com>
 <aH35W513u731UVHZ69b2ORTrSZy4rtejOiPALC5oLv4=.85cea908-42c0-4b34-ace8-5a0f6b3e566f@github.com>
 <dFiqxG440j4xzNPMtKA_QGFTr55mZHLXp4LmTD9oQ9c=.00e7f697-1d96-48ea-bb2c-a3894185b1de@github.com>
Message-ID: <pYTO6N_ipiWfYuD_0bMSqXxXzGQlmuDy4J3BKs4TTf4=.e093a237-9e4a-4923-b7e7-a57cd82f6bcf@github.com>

On Mon, 2 Dec 2024 15:12:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hotspot changes look fine.
>> 
>> Thanks
>
> @dholmes-ora @coleenp @erikj79 Thanks for your reviews!

@magicus Thanks for integrating the changes, particularly reworking and making the statically linked launcher build changes cleaner!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2512408268

From coleenp at openjdk.org  Mon Dec  2 18:47:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Dec 2024 18:47:42 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v4]
In-Reply-To: <1F-lKOjcqx8WkskxnR9zrcT2I-j6jNCe-YAKhQLuVlE=.02e5bf5b-b486-45e7-8385-f0b8d134316f@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <tR_gcUNX2_3YF0_wUQXVaE5513aINvC0wV3oO8-wWUA=.638f6c8f-20f7-4594-8df1-74a721a9e429@github.com>
 <1F-lKOjcqx8WkskxnR9zrcT2I-j6jNCe-YAKhQLuVlE=.02e5bf5b-b486-45e7-8385-f0b8d134316f@github.com>
Message-ID: <hCw524OC-UmFC6W8-7QFfepkmq9D4IkoG1XcqrTOeIE=.c81a4b67-9ed7-4cbc-a0f6-230dda76a16c@github.com>

On Fri, 29 Nov 2024 09:51:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The former is a user error and should result in an initialization error, exactly like we do for a wrong CompressedClassSpaceBaseAddress.

I was trying to allow SharedBaseAddress to turn off CDS and not give an error.  What you suggested is easier.  I had a variant of this at one point with klass_decode_node() returning false but not setting decode_node also would work.

Thanks for looking at this.  I'm going to continue to subsume your PR in this one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2512412771

From henryjen at openjdk.org  Mon Dec  2 18:55:40 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 2 Dec 2024 18:55:40 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <v4ZLCB34Y0sGB3jp2PQ0lgrp0j98vzIFJfBtqUvHmEg=.b8ba98e6-3c5b-49aa-bb1e-e054d705061e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <v4ZLCB34Y0sGB3jp2PQ0lgrp0j98vzIFJfBtqUvHmEg=.b8ba98e6-3c5b-49aa-bb1e-e054d705061e@github.com>
Message-ID: <nj3brKPZBjc5-zAkv42-sMUNkGxRnq-yl25aNWU6GT0=.a7088400-63e4-4911-b59c-f3323f897429@github.com>

On Mon, 2 Dec 2024 18:34:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> src/hotspot/share/runtime/threads.cpp line 654:
> 
>> 652:   initialize_java_lang_classes(main_thread, CHECK_JNI_ERR);
>> 653:   // Update the java.vm.vendor property with java.lang.VersionProps.VM_VENDOR
>> 654:   Arguments::update_vm_vendor(VM_Version::vm_vendor());
> 
> It seems very ad hoc to update this after initPhase1 has run, need to think through if there is a better way to do this.

I agree. This is to minimize change on behavior. 

Not sure what kind of requirement is there for java.vm.vendor, would it be OK for VM not the set this value and wait until loading of VersionProps class?

The update is needed for the assertion in statSampler, I don't see other reference to the property in the repo. So the question is when we need the property to be available and exposure scope.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1866420143

From ccheung at openjdk.org  Mon Dec  2 19:27:37 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 2 Dec 2024 19:27:37 GMT
Subject: RFR: 8344904: Interned strings in old classes are not stored in
 CDS archive [v2]
In-Reply-To: <7ausG_UkrSqNJBoU4iMf1WgvrymR0gtOQmm_uUOw3tg=.558f2d07-cd4b-4031-87ed-0889cdf04d9f@github.com>
References: <yEa3lLeX-hxY_vT2EMcnQySu0JUF4QO2pu4qvXZ3T5A=.6b610fb3-ace3-4a2f-9fd0-4007c24b5d5a@github.com>
 <7ausG_UkrSqNJBoU4iMf1WgvrymR0gtOQmm_uUOw3tg=.558f2d07-cd4b-4031-87ed-0889cdf04d9f@github.com>
Message-ID: <ZvhW_ZfLGKweRaLGZfEgyebE_Pzh4LoV_1nhbEDhF3Y=.14ad063e-0d2f-4595-b789-bb2734449e7a@github.com>

On Tue, 26 Nov 2024 05:32:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Before this fix, CDS will only archive interned strings that are reachable from `ConstantPool::resolved_references()`, which is created only after a class is linked. However, old classes are not linked, so we didn't archive their interned strings.
>> 
>> It's possible for the Java mirror of an (unlinked) old class to point to interned strings. E.g.,
>> 
>> 
>> public super class OldClassWithStaticString
>>     version 49:0
>> {
>>     public static final Field s:"Ljava/lang/String;" = String "xxxx123yyyy456";
>> 
>> 
>> The 's' field is initialized during class file parsing, so we must intern the `"xxxx123yyyy456"` string.
>> 
>> The fix is to collect interned strings from the static fields of unlinked classes.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

LGTM

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22340#pullrequestreview-2473721717

From coleenp at openjdk.org  Mon Dec  2 19:32:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Dec 2024 19:32:55 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v5]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <-U6FwTVhODRmHmlOzISvDZ61v_igsd_nAb4Le3pgCNg=.e131d0ec-5248-4b80-9a5e-689cf6aa4a15@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into decode-mode
 - Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932
 - Merge branch 'master' into decode-mode
 - include formatBuffer.hpp
 - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

-------------

Changes: https://git.openjdk.org/jdk/pull/21695/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=04
  Stats: 105 lines in 8 files changed: 98 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From markus.gronlund at oracle.com  Mon Dec  2 19:47:00 2024
From: markus.gronlund at oracle.com (Markus Gronlund)
Date: Mon, 2 Dec 2024 19:47:00 +0000
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas
In-Reply-To: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
References: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
Message-ID: <IA1PR10MB5971337DF87E0FE4FD577C1F99352@IA1PR10MB5971.namprd10.prod.outlook.com>

Vote: yes

Markus

-----Original Message-----
From: hotspot-dev <hotspot-dev-retn at openjdk.org> On Behalf Of Stefan Karlsson
Sent: Wednesday, 27 November 2024 12:27
To: hotspot-dev at openjdk.org
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas

I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot Group.

Axel is a member of Oracle's HotSpot GC team and has been contributing to various parts of the JVM for over two years now.

Votes are due by 2024-12-11T12:24+01:00.

Only current Members of the HotSpot Group [1] are eligible to vote on this nomination.? Votes must be cast in the open by replying to this mailing list

For Lazy Consensus voting instructions, see [2].

Stefan Karlsson

[1] https://openjdk.org/census
[2] https://openjdk.org/groups/#member-vote

From kvn at openjdk.org  Mon Dec  2 19:49:40 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 2 Dec 2024 19:49:40 GMT
Subject: RFR: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
Message-ID: <4t_TAvqCvhG3Yryo9XDiIn86NtpgeteL4aRKbIuh8IE=.31889885-bb55-42e2-8cec-9862e11e318f@github.com>

On Sun, 1 Dec 2024 07:54:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how NULL_WORD is defined.  Instead of being a
> macro whose definition is in compiler-specific files with a conditionally
> defined expansion, it is now a simple integral constant with a single shared
> definition.
> 
> Testing: mach5 tier 1-5, GHA sanity tests.

LGTM

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22468#pullrequestreview-2473763293

From dholmes at openjdk.org  Mon Dec  2 20:06:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 20:06:38 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <AIF536W8iYU_q-LwknzH2Xegpee2H_CWDmIbWVQVqx4=.af05fa54-f538-4521-a319-49d9b45dacd1@github.com>

On Thu, 7 Nov 2024 21:38:28 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

I'm not very familiar with jlink so am missing the connection of exactly how the plugin is causing the VM vendor to be overridden. ??

Overall this seems like a huge amount of boiler-plate to change one property at runtime.

src/hotspot/share/runtime/abstract_vm_version.hpp line 30:

> 28: #include "memory/allStatic.hpp"  // For declaration of class AllStatic
> 29: #include "utilities/globalDefinitions.hpp"
> 30: #include "runtime/os.hpp"

This include is not needed by the hpp file please put it in the cpp file.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21964#pullrequestreview-2473773598
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1866523621

From dholmes at openjdk.org  Mon Dec  2 20:06:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 2 Dec 2024 20:06:40 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <nj3brKPZBjc5-zAkv42-sMUNkGxRnq-yl25aNWU6GT0=.a7088400-63e4-4911-b59c-f3323f897429@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <v4ZLCB34Y0sGB3jp2PQ0lgrp0j98vzIFJfBtqUvHmEg=.b8ba98e6-3c5b-49aa-bb1e-e054d705061e@github.com>
 <nj3brKPZBjc5-zAkv42-sMUNkGxRnq-yl25aNWU6GT0=.a7088400-63e4-4911-b59c-f3323f897429@github.com>
Message-ID: <SnAAfQCHY4OYzqnbbmHAwJIMHpDYbx7uncO1KzshJVc=.cb736b99-6372-4eb2-adef-f47f98e1ebf1@github.com>

On Mon, 2 Dec 2024 18:53:12 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 654:
>> 
>>> 652:   initialize_java_lang_classes(main_thread, CHECK_JNI_ERR);
>>> 653:   // Update the java.vm.vendor property with java.lang.VersionProps.VM_VENDOR
>>> 654:   Arguments::update_vm_vendor(VM_Version::vm_vendor());
>> 
>> It seems very ad hoc to update this after initPhase1 has run, need to think through if there is a better way to do this.
>
> I agree. This is to minimize change on behavior. 
> 
> Not sure what kind of requirement is there for java.vm.vendor, would it be OK for VM not the set this value and wait until loading of VersionProps class?
> 
> The update is needed for the assertion in statSampler, I don't see other reference to the property in the repo. So the question is when we need the property to be available and exposure scope.

I'm a little lost in the sequence of events here as well. Why do we call `override_vm_vendor` in `initialize_java_lang_classes` and then `update_vm_vendor` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1866534288

From liach at openjdk.org  Mon Dec  2 20:15:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Dec 2024 20:15:38 GMT
Subject: RFR: 8341649: Regressions with large metaspace apps after 8338526
In-Reply-To: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
References: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
Message-ID: <hSH-Vl5lC98pBpXxCzKeGnLW8ckNpJUPqIIUytyM-II=.cba4df9b-e816-464e-a1dc-7decd0536ea5@github.com>

On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause excess dependency checking for c2 compiled code and shows a performance regression in a new JMH performance test for MethodHandles (to be checked in at a later time).
> 
> When I made this abstract rather than final, I thought there were a many generated classes but I haven't found in testing more than a small percentage.  For example, Dacapo xalan there are 43/1000 classes that are these generated classes.  In Eric's new JMH test, it was more like 51/681.  Special casing "AllStatic" classes to go in non-class metaspace is a bit too risky at this time.  If it does become a problem with limited class metaspace, we can create another attribute to use.
> 
> Tested with tier1-4 and the JMH test.  Thanks Eric Caspole for finding this and all the testing.

Interesting discovery; glad to hear that our final + private constructor pattern for utility classes is fine for now!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22493#pullrequestreview-2473813433

From mchung at openjdk.org  Mon Dec  2 20:23:37 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 2 Dec 2024 20:23:37 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <2YlNnpfdsRwkhgvbewfxqJcb8qVgS8J90bD5nV8N0jM=.f6b1ffc1-acb5-439e-9314-910f3b24873c@github.com>

On Thu, 7 Nov 2024 21:38:28 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

I think it's cleaner to explore defining the VM related branding configuration `make/conf/branding.conf` where the OpenJDK value of system properties in VersionProps.java.template are defined.    One idea is to add .template file in `src/hotspot` that the build can patch the values before starting building VM so that it will not depend on VersionProps class to be loaded.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21964#issuecomment-2512713166

From sangheon.kim at oracle.com  Mon Dec  2 21:21:10 2024
From: sangheon.kim at oracle.com (Sangheon Kim)
Date: Mon, 2 Dec 2024 13:21:10 -0800
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas
In-Reply-To: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
References: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
Message-ID: <6c9afbaf-781e-4fc9-9f4c-039af486c7f9@oracle.com>

Vote: yes



On 11/27/24 3:26 AM, Stefan Karlsson wrote:
> I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot 
> Group.
>
> Axel is a member of Oracle's HotSpot GC team and has been contributing 
> to various parts of the JVM for over two years now.
>
> Votes are due by 2024-12-11T12:24+01:00.
>
> Only current Members of the HotSpot Group [1] are eligible
> to vote on this nomination.? Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Stefan Karlsson
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote


From coleenp at openjdk.org  Mon Dec  2 22:11:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Dec 2024 22:11:09 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v6]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <HwFH1WV5BQe7z5MVI7Bw4JKnUPW_d7GvI_0LylbDcVU=.3cedfb45-23c4-4661-90f6-1f4ba30ddb95@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Rename ceil_log2 to log2i_ceil

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21695/files
  - new: https://git.openjdk.org/jdk/pull/21695/files/83e244f5..48cd91b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From iklam at openjdk.org  Mon Dec  2 22:58:48 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 2 Dec 2024 22:58:48 GMT
Subject: Integrated: 8344904: Interned strings in old classes are not stored in
 CDS archive
In-Reply-To: <yEa3lLeX-hxY_vT2EMcnQySu0JUF4QO2pu4qvXZ3T5A=.6b610fb3-ace3-4a2f-9fd0-4007c24b5d5a@github.com>
References: <yEa3lLeX-hxY_vT2EMcnQySu0JUF4QO2pu4qvXZ3T5A=.6b610fb3-ace3-4a2f-9fd0-4007c24b5d5a@github.com>
Message-ID: <pnlc6v4cxozbmiR4v8bQ1RkWY2-pkDxCDbvkzgAYOI4=.72b9f5ae-056b-41d1-9bf7-43031f83f900@github.com>

On Sat, 23 Nov 2024 03:25:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Before this fix, CDS will only archive interned strings that are reachable from `ConstantPool::resolved_references()`, which is created only after a class is linked. However, old classes are not linked, so we didn't archive their interned strings.
> 
> It's possible for the Java mirror of an (unlinked) old class to point to interned strings. E.g.,
> 
> 
> public super class OldClassWithStaticString
>     version 49:0
> {
>     public static final Field s:"Ljava/lang/String;" = String "xxxx123yyyy456";
> 
> 
> The 's' field is initialized during class file parsing, so we must intern the `"xxxx123yyyy456"` string.
> 
> The fix is to collect interned strings from the static fields of unlinked classes.

This pull request has now been integrated.

Changeset: 68b1b94d
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68b1b94d1be686037e2aaef57c0d9adc594fac7a
Stats:     155 lines in 5 files changed: 144 ins; 2 del; 9 mod

8344904: Interned strings in old classes are not stored in CDS archive

Reviewed-by: dholmes, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/22340

From iklam at openjdk.org  Mon Dec  2 22:58:46 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 2 Dec 2024 22:58:46 GMT
Subject: RFR: 8344904: Interned strings in old classes are not stored in
 CDS archive [v2]
In-Reply-To: <Y4NNnk4_oyaAmLnxV7X2nWKF-auJftDCKKPj3uXszxw=.51d6e8a9-b009-4455-9e59-56bcb00ee1c8@github.com>
References: <yEa3lLeX-hxY_vT2EMcnQySu0JUF4QO2pu4qvXZ3T5A=.6b610fb3-ace3-4a2f-9fd0-4007c24b5d5a@github.com>
 <7ausG_UkrSqNJBoU4iMf1WgvrymR0gtOQmm_uUOw3tg=.558f2d07-cd4b-4031-87ed-0889cdf04d9f@github.com>
 <Y4NNnk4_oyaAmLnxV7X2nWKF-auJftDCKKPj3uXszxw=.51d6e8a9-b009-4455-9e59-56bcb00ee1c8@github.com>
Message-ID: <0vwsHxU1JLuIXwsWJiaWpDBDWK_RM2TX7RZddqycPKY=.cda25885-74a5-49a9-8da9-ee368be95c00@github.com>

On Wed, 27 Nov 2024 06:08:58 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @dholmes-ora comments
>
> Looks good.
> 
> Thanks

Thanks @dholmes-ora @calvinccheung for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22340#issuecomment-2513149903

From coleenp at openjdk.org  Mon Dec  2 23:03:57 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 2 Dec 2024 23:03:57 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v7]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <XFvevUm3-tX2xCH-E8rzd1yLdse-CGtYVBBlgxsmoTQ=.d37ad96c-14c3-4029-a2dd-c1af69a17752@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Missed one. Another good reason to not copy code.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21695/files
  - new: https://git.openjdk.org/jdk/pull/21695/files/48cd91b6..cf6f9124

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From henryjen at openjdk.org  Mon Dec  2 23:14:44 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 2 Dec 2024 23:14:44 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <wJZo-AFHSmXX6B2LVSxVnO0mfqjYNdyWrAwEPx_hMt8=.79b77b9a-b222-4c4c-9962-5a38f91e47d6@github.com>

On Thu, 7 Nov 2024 21:38:28 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

If we don't need java.vm.vendor to be set before loading VersionProps, it would be nice to leave that out and simply let VersionProps set the properties.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21964#pullrequestreview-2474129016

From henryjen at openjdk.org  Mon Dec  2 23:14:45 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 2 Dec 2024 23:14:45 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <AIF536W8iYU_q-LwknzH2Xegpee2H_CWDmIbWVQVqx4=.af05fa54-f538-4521-a319-49d9b45dacd1@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <AIF536W8iYU_q-LwknzH2Xegpee2H_CWDmIbWVQVqx4=.af05fa54-f538-4521-a319-49d9b45dacd1@github.com>
Message-ID: <49D4rYqXMgLQDAlELe50vj_mrpsoQn0iomgh0G85wj8=.4d1871d5-0cf9-4f88-9893-c9e3b0615697@github.com>

On Mon, 2 Dec 2024 19:52:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> src/hotspot/share/runtime/abstract_vm_version.hpp line 30:
> 
>> 28: #include "memory/allStatic.hpp"  // For declaration of class AllStatic
>> 29: #include "utilities/globalDefinitions.hpp"
>> 30: #include "runtime/os.hpp"
> 
> This include is not needed by the hpp file please put it in the cpp file.

Yes, I start with a simpler version of override as inline function, should have moved this include along with refactoring.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1866748950

From henryjen at openjdk.org  Mon Dec  2 23:14:45 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Mon, 2 Dec 2024 23:14:45 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <SnAAfQCHY4OYzqnbbmHAwJIMHpDYbx7uncO1KzshJVc=.cb736b99-6372-4eb2-adef-f47f98e1ebf1@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <v4ZLCB34Y0sGB3jp2PQ0lgrp0j98vzIFJfBtqUvHmEg=.b8ba98e6-3c5b-49aa-bb1e-e054d705061e@github.com>
 <nj3brKPZBjc5-zAkv42-sMUNkGxRnq-yl25aNWU6GT0=.a7088400-63e4-4911-b59c-f3323f897429@github.com>
 <SnAAfQCHY4OYzqnbbmHAwJIMHpDYbx7uncO1KzshJVc=.cb736b99-6372-4eb2-adef-f47f98e1ebf1@github.com>
Message-ID: <M04RU37zZ_gpDm7tvilauu_zC_tpttuxNcM6pRsN4Ak=.2b557c1d-23be-4c00-b9d2-c86c3f182a62@github.com>

On Mon, 2 Dec 2024 19:59:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I agree. This is to minimize change on behavior. 
>> 
>> Not sure what kind of requirement is there for java.vm.vendor, would it be OK for VM not the set this value and wait until loading of VersionProps class?
>> 
>> The update is needed for the assertion in statSampler, I don't see other reference to the property in the repo. So the question is when we need the property to be available and exposure scope.
>
> I'm a little lost in the sequence of events here as well. Why do we call `override_vm_vendor` in `initialize_java_lang_classes` and then `update_vm_vendor` here?

I can do it together, override_vm_vendor read the value from the VersionProps class and set the value in VM. 
update_vm_vendor update the java.vm.vendor system property with the override value.

So I think override is part of the initialize class, and the replace the system property after initialize of VersionProps.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1866747941

From fyang at openjdk.org  Tue Dec  3 00:10:41 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Dec 2024 00:10:41 GMT
Subject: RFR: 8345178: RISC-V: Add gtests for narrow cmpxchg [v4]
In-Reply-To: <F6rDRSIAJlZT8KPcR3Hc9PqXo3VLW8IWMrjt3xWlkLQ=.d52a0fa6-b7d8-4a91-8955-369949469a71@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
 <F6rDRSIAJlZT8KPcR3Hc9PqXo3VLW8IWMrjt3xWlkLQ=.d52a0fa6-b7d8-4a91-8955-369949469a71@github.com>
Message-ID: <oCWa-x4M20f1UtmkxsMf_l6XUQnZzl4h14OTneAaMdg=.f6993ddf-0aa6-4b41-93ba-d117d68f96e5@github.com>

On Mon, 2 Dec 2024 17:16:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned narrow cmpxchg.
>> 
>> 
>> Note: Google Test filter = *RiscV*
>> [==========] Running 5 tests from 1 test suite.
>> [----------] Global test environment set-up.
>> [----------] 5 tests from RiscV
>> ...
>> [ RUN      ] RiscV.cmpxchg_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms)
>> [----------] 5 tests from RiscV (20831 ms total)
>> 
>> [----------] Global test environment tear-down
>> [==========] 5 tests from 1 test suite ran. (20834 ms total)
>> [  PASSED  ] 5 tests.
>> 
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into narrow
>  - Review comment
>  - Remove CMF barrier
>  - gtest narrow cmpxchg

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22445#pullrequestreview-2474189361

From fyang at openjdk.org  Tue Dec  3 01:42:27 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Dec 2024 01:42:27 GMT
Subject: RFR: 8345351: RISC-V: Rename macro-assembler routine cmpxchg_weak to
 weak_cmpxchg
Message-ID: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>

Hi, Please consider this trivial change.

We have macro-assembler routine names like `cmpxchg_narrow_value` and `weak_cmpxchg_narrow_value`.
We should rename `MacroAssembler::cmpxchg_weak` to `MacroAssembler::weak_cmpxchg` for consistency
in naming. This will also be consistent with names like `weakCompareAndSwapI`, `weakCompareAndSwapL` in AD files.

- [x] hotspot:tier1 test on linux-riscv64 platform.

-------------

Commit messages:
 - 8345351: RISC-V: Rename macro-assembler routine cmpxchg_weak to weak_cmpxchg

Changes: https://git.openjdk.org/jdk/pull/22505/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22505&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345351
  Stats: 23 lines in 4 files changed: 0 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/22505.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22505/head:pull/22505

PR: https://git.openjdk.org/jdk/pull/22505

From dholmes at openjdk.org  Tue Dec  3 01:43:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Dec 2024 01:43:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>

On Mon, 25 Nov 2024 13:11:52 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

src/hotspot/share/utilities/rbTree.hpp line 1:

> 1: /*

Just a drive-by comment but why is this all in the hpp file instead of being split into hpp (and maybe .inline.hpp) and cpp files?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1866861073

From fyang at openjdk.org  Tue Dec  3 01:46:38 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Dec 2024 01:46:38 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v3]
In-Reply-To: <R4eGHUXGY-fQUdIFQ0mr9pzex9ttSybXCRbvJAI8tUQ=.f09f9247-1601-43e8-b50c-02b874d061ed@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <R4eGHUXGY-fQUdIFQ0mr9pzex9ttSybXCRbvJAI8tUQ=.f09f9247-1601-43e8-b50c-02b874d061ed@github.com>
Message-ID: <xSOnID6SWBvqCKPaLkNyGS96uW15MwfCS2chf60sBwU=.649d0c37-2e99-4d4e-8cb1-d4dc954e05d0@github.com>

On Mon, 2 Dec 2024 17:46:16 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned weak narrow cmpxchg.
>> 
>> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20997 ms total)
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added weak 4/8 byte cmpxchg

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 295:

> 293:     address entry = _masm.pc();
> 294:     {
> 295:        _masm.cmpxchg_weak(/*addr*/ c_rarg0, /*expected*/ c_rarg1, /*new_value*/ c_rarg2,

Seems that we should rename macro-assembler routine `cmpxchg_weak` to `weak_cmpxchg`.
I have prepared another PR to fix this naming issue: https://github.com/openjdk/jdk/pull/22505.

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 308:

> 306: 
> 307: template <typename TESTSIZE, Assembler::operand_size ASMSIZE>
> 308: void run_narrow_cmpxchg_tests() {

Consider rename to `run_weak_cmpxchg_narrow_value_tests`.

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 354:

> 352: 
> 353: template <typename TESTSIZE, Assembler::operand_size ASMSIZE>
> 354: void weak_cmpxchg_test() {

Consider rename to `run_weak_cmpxchg_tests`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1866856894
PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1866808350
PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1866808552

From fyang at openjdk.org  Tue Dec  3 02:20:37 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Dec 2024 02:20:37 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe
In-Reply-To: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
Message-ID: <js_Oa_5suvIHWm_p6DOYBeuiEGGZRm5MwvS5RJhp9ks=.f345702a-711a-4473-b814-f7a0af140ee4@github.com>

On Mon, 2 Dec 2024 09:55:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review the patch?
> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
> 
> Thanks!
> 
> Tests running so far so good.

I assume these EXPERIMENTAL features are not fully tested on real hardware, right? As we disscussed somewhere before, we won't do that before the hardware is available.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22474#pullrequestreview-2474358441

From vlivanov at openjdk.org  Tue Dec  3 02:47:42 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 3 Dec 2024 02:47:42 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
Message-ID: <kBUMTZM_oooYkibxwKfTJ7kvEqmIemr0ir0DSSQWi9s=.4bae0b8c-54be-4467-a1c6-60560b8fdcd9@github.com>

On Mon, 2 Dec 2024 16:18:07 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   increase compiler stub space for macos x86_64

Looks good. 

Testing results (hs-tier1 - hs-tier4) are clean.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2513426978

From amitkumar at openjdk.org  Tue Dec  3 04:09:41 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Dec 2024 04:09:41 GMT
Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <BnA1J6rQ4mH04PmKsoV44F0k6eNtwlczFlj7n3s981Y=.b2c5b8d3-8044-448c-a693-ccccf32363ba@github.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
 <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
 <BnA1J6rQ4mH04PmKsoV44F0k6eNtwlczFlj7n3s981Y=.b2c5b8d3-8044-448c-a693-ccccf32363ba@github.com>
Message-ID: <zbEk_RRockbWur0tJvawQsihaHNVSCElNmG1kUTY0g4=.90ea8828-af3a-4c73-9fdd-4160145a76ad@github.com>

On Mon, 2 Dec 2024 13:24:46 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Looks good, thanks. It's probably worth making sure there's a `make bootcycle-images` and if it doesn't take forever, tiers 2-4. We don't want any nasty surprises.

bootcycle-images was success, also I don't see any test failure related to this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2513500999

From amitkumar at openjdk.org  Tue Dec  3 04:09:42 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Dec 2024 04:09:42 GMT
Subject: RFR: 8339983: [s390x] secondary_super_cache does not scale well:
 C1 and interpreter
In-Reply-To: <6Ahq-U8CmimPtLVINuuq5ATx4_ggQ9S17bXzhxJ52a4=.46e0c612-18bf-4a34-bb35-e17ba5ddf3bb@github.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
 <Ss5G61PU0e3ZaM6n1eghTQrED9wOJLRNeit1IwxbTt8=.0ef0a858-17af-4195-b176-335f18c8fb23@github.com>
 <ANJSrBX7tBlr7E1wuAaUKRe4ba-iLEzoinAILta7o8s=.c075c0c7-e837-40dd-a970-db1b7f205a5b@github.com>
 <r7aXd_kDs21Jf_lfS2rW9ouq4TvxkNaAKIb-81G5Zag=.962b7dd3-9c22-4c5c-ae75-611135626f56@github.com>
 <6Ahq-U8CmimPtLVINuuq5ATx4_ggQ9S17bXzhxJ52a4=.46e0c612-18bf-4a34-bb35-e17ba5ddf3bb@github.com>
Message-ID: <SNOzW0ifiLz0voe5OQs257kxRl1VSSYcxPCGNyhN6Tc=.5338707b-1103-4f27-9eb6-c6f0711e9852@github.com>

On Wed, 27 Nov 2024 16:03:55 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

>> On 11\/27\/24 15\:58\, Amit Kumar wrote\:
>>> On Wed\, 27 Nov 2024 15\:48\:29 GMT\, Lutz Schmidt \<lucy at openjdk\.org> wrote\:
>>> 
>>>> Are there any performance figures\? Does the change help\, or at least do no harm\, on s390\?
>>> 
>>> I do but they don\'t look interesting\.
>> 
>> With the patch you should see this\:
>> 
>> \-XX\:TieredStopAtLevel\=1 \-XX\:\+UnlockDiagnosticVMOptions \-XX\:\+UseSecondarySupersCache \-XX\:\-UseSecondarySupersTable
>> 
>> Benchmark                                   Mode  Cnt    Score     Error  Units
>> SecondarySuperCacheInterContention\.test     avgt    5  176\.328 \?  69\.341  ns\/op
>> SecondarySuperCacheInterContention\.test\:t1  avgt    5  173\.024 \?  29\.227  ns\/op
>> SecondarySuperCacheInterContention\.test\:t2  avgt    5  179\.633 \? 110\.211  ns\/op
>> 
>> \-XX\:TieredStopAtLevel\=1
>> 
>> Benchmark                                   Mode  Cnt  Score   Error  Units
>> SecondarySuperCacheInterContention\.test     avgt    5  5\.156 \? 0\.855  ns\/op
>> SecondarySuperCacheInterContention\.test\:t1  avgt    5  5\.225 \? 1\.604  ns\/op
>> SecondarySuperCacheInterContention\.test\:t2  avgt    5  5\.087 \? 0\.740  ns\/op
>> 
>> assuming you have >1 core\. Try also SecondarySuperCacheIntraContention\.test
>> 
>> \-\- 
>> Andrew Haley  \(he\/him\)
>> Java Platform Lead Engineer
>> Red Hat UK Ltd\. \<https\:\/\/www\.redhat\.com>
>> https\:\/\/keybase\.io\/andrewhaley
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>> I do but they don't look interesting.
> 
> OK. No harm detected.

Thank you for reviews and suggestions @RealLucy, @theRealAph.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22341#issuecomment-2513502558

From amitkumar at openjdk.org  Tue Dec  3 04:09:43 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Dec 2024 04:09:43 GMT
Subject: Integrated: 8339983: [s390x] secondary_super_cache does not scale
 well: C1 and interpreter
In-Reply-To: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
References: <bl-MLvlewiD0up11P7Y9svEaDpn32RqFoYVj5bf9vtc=.8563b739-e8ca-42d7-be51-670f699bf034@github.com>
Message-ID: <k0IeB863g5aVrv0NRWwic3SbaAQ2plBQ2kMkkvpzBS4=.d8a42dcd-8c7a-42b1-8ece-c7f304619a4e@github.com>

On Sat, 23 Nov 2024 12:24:31 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> s390x Port for : [JDK-8331341](https://bugs.openjdk.org/browse/JDK-8331341)
> 
> Tier1 test: 
> 1. `-XX:+UseSecondarySupersTable  -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache`
> 2.  No flag turn on. i.e. used `UseSecondarySupersCache` by default. 
> 3. `-XX:+UseSecondarySupersTable  -XX:+VerifySecondarySupers -XX:+VerifySecondarySupers -XX:-UseSecondarySupersCache` with C1 compiler

This pull request has now been integrated.

Changeset: a3b58ee5
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3b58ee5cd1ec0ea78649d4128d272458b05eb13
Stats:     429 lines in 6 files changed: 321 ins; 50 del; 58 mod

8339983: [s390x] secondary_super_cache does not scale well: C1 and interpreter

Reviewed-by: lucy, aph

-------------

PR: https://git.openjdk.org/jdk/pull/22341

From kbarrett at openjdk.org  Tue Dec  3 04:57:45 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 3 Dec 2024 04:57:45 GMT
Subject: RFR: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <YDbahSY3b1eiw96BP6x5LPYs0C0w7EsYho0SxKJ4j88=.ab1e26b4-bba6-41e1-9470-4d9d23ca577d@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
 <YDbahSY3b1eiw96BP6x5LPYs0C0w7EsYho0SxKJ4j88=.ab1e26b4-bba6-41e1-9470-4d9d23ca577d@github.com>
Message-ID: <f1iYQcoS-CDapx03Z8bFimU0v23XNjVXHxe-BDdf2Sw=.ee290542-2e54-4a25-aa0c-ae32b8f488a6@github.com>

On Mon, 2 Dec 2024 11:59:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to how NULL_WORD is defined.  Instead of being a
>> macro whose definition is in compiler-specific files with a conditionally
>> defined expansion, it is now a simple integral constant with a single shared
>> definition.
>> 
>> Testing: mach5 tier 1-5, GHA sanity tests.
>
> Marked as reviewed by dholmes (Reviewer).

Thanks for reviews @dholmes-ora and @vnkozlov

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22468#issuecomment-2513550321

From kbarrett at openjdk.org  Tue Dec  3 04:57:46 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 3 Dec 2024 04:57:46 GMT
Subject: Integrated: 8343800: Cleanup definition of NULL_WORD
In-Reply-To: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
References: <bqBryOlwlJn9PGh8pGCSfMB21lBNJcQqUjJvrny8e48=.afe8bbea-3b2b-4e00-939c-9862362e8a1c@github.com>
Message-ID: <1wBQ200mY1L2mRgZrwlFJKKVgqqbAkNO0igXjmnnnFw=.a809b4e5-fb43-4c8a-a641-9c867a88d457@github.com>

On Sun, 1 Dec 2024 07:54:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how NULL_WORD is defined.  Instead of being a
> macro whose definition is in compiler-specific files with a conditionally
> defined expansion, it is now a simple integral constant with a single shared
> definition.
> 
> Testing: mach5 tier 1-5, GHA sanity tests.

This pull request has now been integrated.

Changeset: 4ac2e477
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ac2e477b9bb9995047718b7d8df36c3dc739a9d
Stats:     27 lines in 3 files changed: 3 ins; 24 del; 0 mod

8343800: Cleanup definition of NULL_WORD

Reviewed-by: dholmes, kvn

-------------

PR: https://git.openjdk.org/jdk/pull/22468

From amitkumar at openjdk.org  Tue Dec  3 06:06:08 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Dec 2024 06:06:08 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware
Message-ID: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>

This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 


CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash


So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 

This is the output with current changes: 


CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash

-------------

Commit messages:
 - z16 detection

Changes: https://git.openjdk.org/jdk/pull/22508/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22508&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345355
  Stats: 27 lines in 2 files changed: 17 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/22508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22508/head:pull/22508

PR: https://git.openjdk.org/jdk/pull/22508

From rehn at openjdk.org  Tue Dec  3 06:33:37 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 3 Dec 2024 06:33:37 GMT
Subject: RFR: 8345351: RISC-V: Rename macro-assembler routine cmpxchg_weak
 to weak_cmpxchg
In-Reply-To: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>
References: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>
Message-ID: <o3uGxj-MNOoJc64zegdCYY0L6KyN6rPkG0frTkDrdrU=.2f331f8f-a330-4b6b-b4e4-2b39d3f4f703@github.com>

On Tue, 3 Dec 2024 01:31:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Please consider this trivial change.
> 
> We have macro-assembler routine names like `cmpxchg_narrow_value` and `weak_cmpxchg_narrow_value`.
> We should rename `MacroAssembler::cmpxchg_weak` to `MacroAssembler::weak_cmpxchg` for consistency
> in naming. This will also be consistent with names like `weakCompareAndSwapI`, `weakCompareAndSwapL` in AD files.
> 
> - [x] hotspot:tier1 test on linux-riscv64 platform.

Thanks!

-------------

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22505#pullrequestreview-2474697780

From amitkumar at openjdk.org  Tue Dec  3 06:36:45 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Dec 2024 06:36:45 GMT
Subject: RFR: 8343653: [s390x] Replace load/store sequence with move
 instruction
In-Reply-To: <a9DOjMA4L2rqIxzZn-UsrSQHzIZJPYFn2hfUheOZueI=.8cc8d3c3-bc23-4eee-87f4-be46995856dc@github.com>
References: <a9DOjMA4L2rqIxzZn-UsrSQHzIZJPYFn2hfUheOZueI=.8cc8d3c3-bc23-4eee-87f4-be46995856dc@github.com>
Message-ID: <f3OIkZ80B7gs3DSWx9mfO9EsU_mgi65utazVg4x5dbs=.9dca700b-8ec3-4cc3-aef5-8cd9e5bf4ae5@github.com>

On Wed, 27 Nov 2024 08:56:07 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Replaces load+store with mvc/mvghi instruction for in-memory operation. Tier1 test are clean except `ShowRegistersOnAssertTest.java` failure, but it failed on head stream also. I am doing git bisect to figure out what's going with that test.  
> 
> update: did a git bisect and found bad commit, so I have opened [JDK-8345102](https://bugs.openjdk.org/browse/JDK-8345102)
> 
> Testing: 
> - tier1 test with no flag 
> - tier1 with -XX:+UseCompactObjectHeaders

closing as there is no significant benefit from this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22408#issuecomment-2513675508

From amitkumar at openjdk.org  Tue Dec  3 06:36:46 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Dec 2024 06:36:46 GMT
Subject: Withdrawn: 8343653: [s390x] Replace load/store sequence with move
 instruction
In-Reply-To: <a9DOjMA4L2rqIxzZn-UsrSQHzIZJPYFn2hfUheOZueI=.8cc8d3c3-bc23-4eee-87f4-be46995856dc@github.com>
References: <a9DOjMA4L2rqIxzZn-UsrSQHzIZJPYFn2hfUheOZueI=.8cc8d3c3-bc23-4eee-87f4-be46995856dc@github.com>
Message-ID: <Pfq9ZDGwP_-8LLrNnNFjsx12gj2PV51qKEWkpf80r0c=.45f50523-04f1-4192-b6ef-f8bc5413081e@github.com>

On Wed, 27 Nov 2024 08:56:07 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Replaces load+store with mvc/mvghi instruction for in-memory operation. Tier1 test are clean except `ShowRegistersOnAssertTest.java` failure, but it failed on head stream also. I am doing git bisect to figure out what's going with that test.  
> 
> update: did a git bisect and found bad commit, so I have opened [JDK-8345102](https://bugs.openjdk.org/browse/JDK-8345102)
> 
> Testing: 
> - tier1 test with no flag 
> - tier1 with -XX:+UseCompactObjectHeaders

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22408

From iklam at openjdk.org  Tue Dec  3 06:46:22 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 3 Dec 2024 06:46:22 GMT
Subject: RFR: 8344140: Refactor the discovery of AOT cache artifacts [v3]
In-Reply-To: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
References: <YbxbRup4mdeX5izkteclVarz4oZ54Zj77fvzz4U1ino=.b6fface8-c043-4405-a1b2-03dcc5646528@github.com>
Message-ID: <C_aAQOl_agKc49vGZe5pdpUIORd2HIV4stAPJ0HEnis=.a670485e-9c9e-4a99-ad18-a31b6d750e28@github.com>

> This is a clean up after the initial integration for [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737)
> 
> - Merged 3 loops into 1 for discovering the classes and oops that should be stored in the AOT cache. About 250 lines of code are deleted.
> - Added comments in aotArtifactFinder.hpp to describe the logic, which is much simpler than before.
> - Enum classes are no longer unconditionally AOT-initialized -- an Enum class is AOT-initialized only if we find an archived oop of this type.
> 
> Note to reviewers:
> 
> One consequence of this refactoring is that archived oops are now discovered (by heapShared.cpp) before the metadata are copied (by ArchiveBuilder). There are some functions that depend on the old order (metadata were copied before oop discovery), so I had to shuffle them around. Examples are `Modules::check_archived_module_oop()`, or the new code in `Klass::remove_java_mirror()`.

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into 8344140-consolidate-aot-artifact-gathering-discovery
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8344140-consolidate-aot-artifact-gathering-discovery
 - Fixe 32-bit builds; removed unused function
 - more clean up
 - tmp
 - More clean up
 - Removed unnecessary code
 - 8344140: Consolidate AOT cache code for artifact discovery

-------------

Changes: https://git.openjdk.org/jdk/pull/22291/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22291&range=02
  Stats: 1325 lines in 29 files changed: 560 ins; 676 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/22291.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22291/head:pull/22291

PR: https://git.openjdk.org/jdk/pull/22291

From karianna at openjdk.org  Tue Dec  3 06:51:41 2024
From: karianna at openjdk.org (Martijn Verburg)
Date: Tue, 3 Dec 2024 06:51:41 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <iZMBG6lBQrnozZH0YHY5-0o0tbtODDPwTyHg3s4X3eQ=.875fb772-177f-4425-bf26-e9f70e1a04f1@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <iZMBG6lBQrnozZH0YHY5-0o0tbtODDPwTyHg3s4X3eQ=.875fb772-177f-4425-bf26-e9f70e1a04f1@github.com>
Message-ID: <GdzhrSnhzRRzRA0fHs7zd8gKBSvR1-l8tPH3P9a9Vho=.349ee0a9-fdf3-4494-ade6-bcbc51b31b78@github.com>

On Mon, 2 Dec 2024 12:01:17 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into hotspot
>>  - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp
>>  - fmod_win64 in sharedRuntime.cpp
>>  - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp
>>  - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - No spaces in test_os_windows.cpp
>>  - No spaces in test/hotspot/gtest/runtime/test_os.cpp
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Revise comment in sharedRuntime.hpp
>>  - Revise comment in sharedRuntime.cpp
>>  - size_t brace initialization instead of unsigned literals in test_os_windows.cpp
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/b32da65a...6cf1c83a
>
> Bumping

@TheShermanTanker - Is there someone in particular you're waiting to approve this PR?  I think you can re-request reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2513693850

From rehn at openjdk.org  Tue Dec  3 07:13:13 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 3 Dec 2024 07:13:13 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v4]
In-Reply-To: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
Message-ID: <FpD4csL_jfwOEtVvLBoKpLm-U4-aXiWEmdTAzvZJMYo=.162fac73-e9dc-4d84-8263-25cde561fca6@github.com>

> Hi, please consider.
> 
> This adds tests of aligned weak narrow cmpxchg.
> 
> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20997 ms total)
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22476/files
  - new: https://git.openjdk.org/jdk/pull/22476/files/bb43ec8f..4dd4077f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=02-03

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/22476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22476/head:pull/22476

PR: https://git.openjdk.org/jdk/pull/22476

From rehn at openjdk.org  Tue Dec  3 07:13:14 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 3 Dec 2024 07:13:14 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v3]
In-Reply-To: <xSOnID6SWBvqCKPaLkNyGS96uW15MwfCS2chf60sBwU=.649d0c37-2e99-4d4e-8cb1-d4dc954e05d0@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <R4eGHUXGY-fQUdIFQ0mr9pzex9ttSybXCRbvJAI8tUQ=.f09f9247-1601-43e8-b50c-02b874d061ed@github.com>
 <xSOnID6SWBvqCKPaLkNyGS96uW15MwfCS2chf60sBwU=.649d0c37-2e99-4d4e-8cb1-d4dc954e05d0@github.com>
Message-ID: <cKDlf4DdDZkvSw6smsa7Tj5Mm-VTwRu6j_cU96hGW30=.a990394a-fbab-4671-ba9f-a343bf9356c4@github.com>

On Tue, 3 Dec 2024 01:34:40 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added weak 4/8 byte cmpxchg
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 295:
> 
>> 293:     address entry = _masm.pc();
>> 294:     {
>> 295:        _masm.cmpxchg_weak(/*addr*/ c_rarg0, /*expected*/ c_rarg1, /*new_value*/ c_rarg2,
> 
> Seems that we should rename macro-assembler routine `cmpxchg_weak` to `weak_cmpxchg`.
> I have prepared another PR to fix this naming issue: https://github.com/openjdk/jdk/pull/22505.

Ok!

> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 308:
> 
>> 306: 
>> 307: template <typename TESTSIZE, Assembler::operand_size ASMSIZE>
>> 308: void run_narrow_cmpxchg_tests() {
> 
> Consider rename to `run_weak_cmpxchg_narrow_value_tests`.

Fixed

> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 354:
> 
>> 352: 
>> 353: template <typename TESTSIZE, Assembler::operand_size ASMSIZE>
>> 354: void weak_cmpxchg_test() {
> 
> Consider rename to `run_weak_cmpxchg_tests`.

Fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1867159211
PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1867158865
PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1867159033

From jwaters at openjdk.org  Tue Dec  3 07:14:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 3 Dec 2024 07:14:42 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <GdzhrSnhzRRzRA0fHs7zd8gKBSvR1-l8tPH3P9a9Vho=.349ee0a9-fdf3-4494-ade6-bcbc51b31b78@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <iZMBG6lBQrnozZH0YHY5-0o0tbtODDPwTyHg3s4X3eQ=.875fb772-177f-4425-bf26-e9f70e1a04f1@github.com>
 <GdzhrSnhzRRzRA0fHs7zd8gKBSvR1-l8tPH3P9a9Vho=.349ee0a9-fdf3-4494-ade6-bcbc51b31b78@github.com>
Message-ID: <v-Eb-qk7za6FoznAuBTpma0zksIDFPJNxzQEPeS2Irc=.3917f8f4-3af7-4f11-b1fe-83cd2042bd25@github.com>

On Tue, 3 Dec 2024 06:48:58 GMT, Martijn Verburg <karianna at openjdk.org> wrote:

>> Bumping
>
> @TheShermanTanker - Is there someone in particular you're waiting to approve this PR?  I think you can re-request reviews.

@karianna I need 2 reviews with at least 1 of them being from a reviewer before this is marked by the automated systems as allowed for integration - Skara doesn't count swesonga's review because he's apparently not registered in the census (I think there might be a mistake there, either in the Skara tool or someone forgot to register him). I guess David or Andrew, or any one of the people from Microsoft who have seen this PR are the next best people to approve this. I had forgotten completely about the review request feature, thanks for reminding me :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2513725439

From shade at openjdk.org  Tue Dec  3 07:19:41 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Dec 2024 07:19:41 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v5]
In-Reply-To: <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
Message-ID: <h49qkP3NzXB662Y9p59xC8WYzfxy-ndszY2lwJHo_EA=.27f3e91b-b711-4b80-aceb-2cb0e5ce2ba8@github.com>

On Mon, 2 Dec 2024 17:49:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do the explicit == 0 check

`all` tests are passing. I plan to integrate this later today. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2513732767

From fyang at openjdk.org  Tue Dec  3 07:27:42 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Dec 2024 07:27:42 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v4]
In-Reply-To: <FpD4csL_jfwOEtVvLBoKpLm-U4-aXiWEmdTAzvZJMYo=.162fac73-e9dc-4d84-8263-25cde561fca6@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <FpD4csL_jfwOEtVvLBoKpLm-U4-aXiWEmdTAzvZJMYo=.162fac73-e9dc-4d84-8263-25cde561fca6@github.com>
Message-ID: <UTvfSYpSOonxym086dQ-J_3tkFiBgj7D_6dlLZtDDRk=.1b49f1a9-b38b-4901-8bb7-efb82a49db2d@github.com>

On Tue, 3 Dec 2024 07:13:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned weak narrow cmpxchg.
>> 
>> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20997 ms total)
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Thanks for the update. BTW: You need to fix the trailing whitespace issue reported by jcheck.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22476#pullrequestreview-2474778315

From alanb at openjdk.org  Tue Dec  3 07:27:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 07:27:55 GMT
Subject: Integrated: 8337199: Add jcmd Thread.vthread_scheduler and
 Thread.vthread_pollers diagnostic commands
In-Reply-To: <AIoBekqlY5FjErxaI4obOui5OyvhALPos9LwGM9SFjo=.d5f602e3-810d-4c04-9c7c-d6fe7b962265@github.com>
References: <AIoBekqlY5FjErxaI4obOui5OyvhALPos9LwGM9SFjo=.d5f602e3-810d-4c04-9c7c-d6fe7b962265@github.com>
Message-ID: <gCyVjPoSxaXBug57O7wtoDKqTlo46XjgFNWCrtrzXU4=.66b11d1a-8beb-437a-b8ab-e4a5670eec8a@github.com>

On Wed, 27 Nov 2024 15:59:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Adds `jcmd <pid> Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd <pid> Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations.
> 
> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort.
> 
> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out.

This pull request has now been integrated.

Changeset: 5c8cb2ed
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c8cb2edcb0a919bfcad11b3f2cb399402915a0c
Stats:     391 lines in 11 files changed: 379 ins; 8 del; 4 mod

8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands

Reviewed-by: dholmes, kevinw

-------------

PR: https://git.openjdk.org/jdk/pull/22414

From rehn at openjdk.org  Tue Dec  3 07:34:04 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 3 Dec 2024 07:34:04 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v5]
In-Reply-To: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
Message-ID: <2JKi_Goke42hWmNW04ioGKBy0_Sj2qycjbyt83tEu54=.04ac83b2-9f8f-414f-bb89-18c0ea4f915d@github.com>

> Hi, please consider.
> 
> This adds tests of aligned weak narrow cmpxchg.
> 
> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20997 ms total)
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Fixed WS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22476/files
  - new: https://git.openjdk.org/jdk/pull/22476/files/4dd4077f..0a7e604c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22476/head:pull/22476

PR: https://git.openjdk.org/jdk/pull/22476

From aph at openjdk.org  Tue Dec  3 09:19:45 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 3 Dec 2024 09:19:45 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
Message-ID: <Jo3B0xC_ZLpyBkyqZjSlhkJUB4MhArHbhrcmtzs5QlQ=.967d3391-90f2-421b-b03a-bd0349162f3e@github.com>

On Fri, 22 Nov 2024 09:17:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into hotspot
>  - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp
>  - fmod_win64 in sharedRuntime.cpp
>  - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp
>  - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - No spaces in test_os_windows.cpp
>  - No spaces in test/hotspot/gtest/runtime/test_os.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Revise comment in sharedRuntime.hpp
>  - Revise comment in sharedRuntime.cpp
>  - size_t brace initialization instead of unsigned literals in test_os_windows.cpp
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/5c53c7aa...6cf1c83a

Looks good.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21627#pullrequestreview-2475029054

From mli at openjdk.org  Tue Dec  3 09:23:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 3 Dec 2024 09:23:39 GMT
Subject: RFR: 8345351: RISC-V: Rename macro-assembler routine cmpxchg_weak
 to weak_cmpxchg
In-Reply-To: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>
References: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>
Message-ID: <TubAC9Gce3SU6vKP7Pv57KwkKVzNvtC6j8-1sxPx4wY=.12bed2b0-a48b-4a9f-b774-a6cbf4fa1428@github.com>

On Tue, 3 Dec 2024 01:31:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Please consider this trivial change.
> 
> We have macro-assembler routine names like `cmpxchg_narrow_value` and `weak_cmpxchg_narrow_value`. And we also have `cmpxchg` and `cmpxchg_weak`. We should rename `MacroAssembler::cmpxchg_weak` to `MacroAssembler::weak_cmpxchg` for consistency in naming with friends. This will also be consistent with names like `weakCompareAndSwapI`, `weakCompareAndSwapL` in AD files.
> 
> - [x] hotspot:tier1 test on linux-riscv64 platform.

Make sense, thanks!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22505#pullrequestreview-2475040137

From mli at openjdk.org  Tue Dec  3 09:36:37 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 3 Dec 2024 09:36:37 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe
In-Reply-To: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
Message-ID: <rJpRTjpbmZC42i8_0RTy3Krkda1nfw2aKHl21RaPyrA=.21ac38e3-a5e6-411f-afb5-5b19bd7ccc9d@github.com>

On Mon, 2 Dec 2024 09:55:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review the patch?
> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
> 
> Thanks!
> 
> Tests running so far so good.

I think you're right, I'll only check and enable zicboz in this pr.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22474#issuecomment-2513997803

From amitkumar at openjdk.org  Tue Dec  3 09:37:40 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 3 Dec 2024 09:37:40 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <jMNIsdrSHLHNmrodyOYcZo4sn_kT7wVhq3qiSf7TQwI=.5f96f301-38c9-4641-a588-75a99238004a@github.com>

On Mon, 25 Nov 2024 13:11:52 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

src/hotspot/share/utilities/rbTree.hpp line 86:

> 84:     void color_red() {
> 85:       _color = RED;
> 86:     }

Suggestion:

    void set_color_black() {
      _color = BLACK;
    }

    void set_color_red() {
      _color = RED;
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1867356788

From mli at openjdk.org  Tue Dec  3 10:02:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 3 Dec 2024 10:02:39 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v5]
In-Reply-To: <2JKi_Goke42hWmNW04ioGKBy0_Sj2qycjbyt83tEu54=.04ac83b2-9f8f-414f-bb89-18c0ea4f915d@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <2JKi_Goke42hWmNW04ioGKBy0_Sj2qycjbyt83tEu54=.04ac83b2-9f8f-414f-bb89-18c0ea4f915d@github.com>
Message-ID: <pKown4EA98PnnOJhFa_I9ux66U-YNOar2t5TBYCtygk=.4f2000c9-a254-41fe-8944-6814072d3353@github.com>

On Tue, 3 Dec 2024 07:34:04 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned weak narrow cmpxchg.
>> 
>> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20997 ms total)
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed WS

Looks good, thanks for adding the tests.
Just one minor comment.

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 327:

> 325: }
> 326: 
> 327: TEST_VM(RiscV, cmpxchg_weak_int16_lr_sc) {

I'm not familiar with the gtest syntax in JDK, seems this (`cmpxchg_weak_int16_lr_sc`) is just a name?
But it still good to follow the name convenction, i.e. weak_cmpxchg.

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 366:

> 364: }
> 365: 
> 366: TEST_VM(RiscV, cmpxchg_weak_int64_lr_sc) {

similar comment here, and below

-------------

PR Review: https://git.openjdk.org/jdk/pull/22476#pullrequestreview-2475152687
PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1867407796
PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1867409382

From fyang at openjdk.org  Tue Dec  3 10:20:37 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 3 Dec 2024 10:20:37 GMT
Subject: RFR: 8345351: RISC-V: Rename macro-assembler routine cmpxchg_weak
 to weak_cmpxchg
In-Reply-To: <o3uGxj-MNOoJc64zegdCYY0L6KyN6rPkG0frTkDrdrU=.2f331f8f-a330-4b6b-b4e4-2b39d3f4f703@github.com>
References: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>
 <o3uGxj-MNOoJc64zegdCYY0L6KyN6rPkG0frTkDrdrU=.2f331f8f-a330-4b6b-b4e4-2b39d3f4f703@github.com>
Message-ID: <8tWodew_NESafGeUxMF6d4K5fLdi5rEyWyPYNJao0K0=.c6a6950f-54ea-41cd-b517-d4be837b41a7@github.com>

On Tue, 3 Dec 2024 06:30:41 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, Please consider this trivial change.
>> 
>> We have macro-assembler routine names like `cmpxchg_narrow_value` and `weak_cmpxchg_narrow_value`. And we also have `cmpxchg` and `cmpxchg_weak`. We should rename `MacroAssembler::cmpxchg_weak` to `MacroAssembler::weak_cmpxchg` for consistency in naming with friends. This will also be consistent with names like `weakCompareAndSwapI`, `weakCompareAndSwapL` in AD files.
>> 
>> - [x] hotspot:tier1 test on linux-riscv64 platform.
>
> Thanks!

@robehn @Hamlin-Li : Thanks for having a look!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22505#issuecomment-2514125755

From cnorrbin at openjdk.org  Tue Dec  3 10:30:43 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 3 Dec 2024 10:30:43 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure
In-Reply-To: <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
Message-ID: <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>

On Tue, 3 Dec 2024 01:41:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> src/hotspot/share/utilities/rbTree.hpp line 1:
> 
>> 1: /*
> 
> Just a drive-by comment but why is this all in the hpp file instead of being split into hpp (and maybe .inline.hpp) and cpp files?

The entire tree is templated, so we can't easily move the implementation to a cpp file

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1867454954

From cnorrbin at openjdk.org  Tue Dec  3 10:57:13 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 3 Dec 2024 10:57:13 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v2]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <vDqVbov_2bu4Vyv69KLv_FRpTQpqFXTkMsrKI3HFmlg=.8f3bf9fa-580f-4613-811d-02a0f2014a87@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  further cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/1b45feaf..9b641fb9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=00-01

  Stats: 42 lines in 2 files changed: 0 ins; 30 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From adinn at openjdk.org  Tue Dec  3 11:39:43 2024
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 3 Dec 2024 11:39:43 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <kBUMTZM_oooYkibxwKfTJ7kvEqmIemr0ir0DSSQWi9s=.4bae0b8c-54be-4467-a1c6-60560b8fdcd9@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
 <kBUMTZM_oooYkibxwKfTJ7kvEqmIemr0ir0DSSQWi9s=.4bae0b8c-54be-4467-a1c6-60560b8fdcd9@github.com>
Message-ID: <16VjjZ_b_RhIrFPJjx_LIB9A3Rr5f78oKY1or3tA8-U=.18e3875e-fb77-4277-a360-e787fd5ecd30@github.com>

On Tue, 3 Dec 2024 02:45:09 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   increase compiler stub space for macos x86_64
>
> Looks good. 
> 
> Testing results (hs-tier1 - hs-tier4) are clean.

@iwanowww Thanks for the heads up on the tests.

I believe I still have the following outstanding things to check:

1. See if I can help @offamitkumar sort out any remaining s390 issues.
2. Get confirmation that riscv and ppc are ok (@RealFYang @TheRealMDoerr? could either of you run tests?)
3. Check that zero is ok (I can do that).
4. Resolve the test failures with macos-x64 (it occurs in string index tests that set -XX:+UseAVX2 -XX:+Enablex86ECoreOpts so it looks like a problem with the compiler stubs buffer being too small).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2514310752

From luhenry at openjdk.org  Tue Dec  3 12:38:42 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 3 Dec 2024 12:38:42 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
Message-ID: <q5_Z08p9Ynt4Q7JOv6sNMXWwgXgiLlpRkit3b6og4OY=.f9690ecb-18f1-4bc9-971c-68cf008c8e6b@github.com>

On Mon, 2 Dec 2024 13:54:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some background description

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1795:

> 1793:   vle64_v(v7, buf); addi(buf, buf, STEP);
> 1794: 
> 1795:   vmv_v_x(v31, zr);

Why the `vmv_v_x`? Where is `v31` used here? Same for https://github.com/openjdk/jdk/pull/22475/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR1797

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1805:

> 1803: 
> 1804:   Label L_16_bytes_loop;
> 1805:   j(L_16_bytes_loop);

Why this unconditional jump which will go to the next instruction?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1867646741
PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1867650489

From cnorrbin at openjdk.org  Tue Dec  3 12:51:18 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Tue, 3 Dec 2024 12:51:18 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <smjKgcMFaWdOoyn6XR9VjzC6nHP1PXQE5ZgHBf3yqF0=.bb68526f-4119-46a7-829f-b311447ecbb9@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  fixed nmt tag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/9b641fb9..5bf6082a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=01-02

  Stats: 25 lines in 2 files changed: 4 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From luhenry at openjdk.org  Tue Dec  3 12:51:43 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 3 Dec 2024 12:51:43 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
Message-ID: <feFJZZ-o2eygl5rPZQWmHShfHdmunACL0G1bGmQewsc=.36e920c1-9506-484a-b37d-ee4045bf2eb3@github.com>

On Mon, 2 Dec 2024 13:54:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some background description

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2048:

> 2046:   const int64_t single_table_size = 256;
> 2047:   const int64_t table_num = 8;   // 4 for scalar, 4 for plain vector
> 2048:   const ExternalAddress table_addr = StubRoutines::crc_table_addr();

Wouldn't it be easier and clearer to have a dedicated table?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1867667506

From mdoerr at openjdk.org  Tue Dec  3 12:54:44 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 3 Dec 2024 12:54:44 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
Message-ID: <Ngufsw47Yen1b-YJvhcVf3pTva3zLzFZnyK728IrECQ=.5bd8486f-abae-4d3f-915f-58842a6097e3@github.com>

On Mon, 2 Dec 2024 16:18:07 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   increase compiler stub space for macos x86_64

I got `SIGSEGV (0xb) at pc=0x0000000000000000, pid=2351564, tid=2351564` in `StubRoutines_array_fill_routine_vm_Test::TestBody()+0xac` on PPC64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2514479708

From mdoerr at openjdk.org  Tue Dec  3 12:57:44 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 3 Dec 2024 12:57:44 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
Message-ID: <2oHCYMO-OdA8jaF26McK5d7vavmKvcyryiuAnKpBKKg=.a103d25b-25e1-4a3e-8d75-7a9c12b82d09@github.com>

On Mon, 2 Dec 2024 16:18:07 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   increase compiler stub space for macos x86_64

And `assert(false) failed: No address descriptor found containing offset_in_library.` in `DwarfFile::DebugAranges::find_compilation_unit_offset(unsigned int, unsigned int*)+0x26c` on PPC64 Big Endian (linux).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2514487177

From mli at openjdk.org  Tue Dec  3 13:40:40 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 3 Dec 2024 13:40:40 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <q5_Z08p9Ynt4Q7JOv6sNMXWwgXgiLlpRkit3b6og4OY=.f9690ecb-18f1-4bc9-971c-68cf008c8e6b@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <q5_Z08p9Ynt4Q7JOv6sNMXWwgXgiLlpRkit3b6og4OY=.f9690ecb-18f1-4bc9-971c-68cf008c8e6b@github.com>
Message-ID: <vUbG4lGMFrhXaN0k59XIOByNTXeK1Fwp74-Z9eKe9nM=.e902ee8f-3fcc-44ea-95d3-d101bc5eb048@github.com>

On Tue, 3 Dec 2024 12:34:00 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add some background description
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1795:
> 
>> 1793:   vle64_v(v7, buf); addi(buf, buf, STEP);
>> 1794: 
>> 1795:   vmv_v_x(v31, zr);
> 
> Why the `vmv_v_x`? Where is `v31` used here? Same for https://github.com/openjdk/jdk/pull/22475/files#diff-7a5c3ed05b6f3f06ed1c59f5fc2a14ec566a6a5bd1d09606115767daa99115bdR1797

Thanks for have a look!

This is because we only want to put the initial `crc` value into the lowest part of the vector register, so explicitly reset the other parts to zero. Hope this answer your question.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 1805:
> 
>> 1803: 
>> 1804:   Label L_16_bytes_loop;
>> 1805:   j(L_16_bytes_loop);
> 
> Why this unconditional jump which will go to the next instruction?

Because we have a `align(OptoLoopAlignment);` below just before the loop.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2048:
> 
>> 2046:   const int64_t single_table_size = 256;
>> 2047:   const int64_t table_num = 8;   // 4 for scalar, 4 for plain vector
>> 2048:   const ExternalAddress table_addr = StubRoutines::crc_table_addr();
> 
> Wouldn't it be easier and clearer to have a dedicated table?

Make sense to me, I'll fix it later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1867736242
PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1867736334
PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1867736533

From coleenp at openjdk.org  Tue Dec  3 13:41:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 13:41:39 GMT
Subject: RFR: 8341649: Regressions with large metaspace apps after 8338526
In-Reply-To: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
References: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
Message-ID: <The-qyaafD_DQ8oINTaLTpQrlCdhJNhvKAYCCqkdEZ0=.fc8cdfa6-0a09-45b0-a3b2-77cf1280dac2@github.com>

On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause excess dependency checking for c2 compiled code and shows a performance regression in a new JMH performance test for MethodHandles (to be checked in at a later time).
> 
> When I made this abstract rather than final, I thought there were a many generated classes but I haven't found in testing more than a small percentage.  For example, Dacapo xalan there are 43/1000 classes that are these generated classes.  In Eric's new JMH test, it was more like 51/681.  Special casing "AllStatic" classes to go in non-class metaspace is a bit too risky at this time.  If it does become a problem with limited class metaspace, we can create another attribute to use.
> 
> Tested with tier1-4 and the JMH test.  Thanks Eric Caspole for finding this and all the testing.

Thank you for the code review.  ACC_FINAL is a good thing to have for these generated classes as it helps the JIT compilers.  It would be really nice if there was some ACC_ALLSTATIC which meant that the code cannot create instances of these classes but that doesn't exist.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22493#issuecomment-2514584072

From mli at openjdk.org  Tue Dec  3 13:51:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 3 Dec 2024 13:51:38 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <vUbG4lGMFrhXaN0k59XIOByNTXeK1Fwp74-Z9eKe9nM=.e902ee8f-3fcc-44ea-95d3-d101bc5eb048@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <q5_Z08p9Ynt4Q7JOv6sNMXWwgXgiLlpRkit3b6og4OY=.f9690ecb-18f1-4bc9-971c-68cf008c8e6b@github.com>
 <vUbG4lGMFrhXaN0k59XIOByNTXeK1Fwp74-Z9eKe9nM=.e902ee8f-3fcc-44ea-95d3-d101bc5eb048@github.com>
Message-ID: <qP08LLafMYHEMx7eYGizr6fstu7VVFRTRCXzhV-VAkA=.c9712fee-9a08-4b0c-97ad-54476eea55ee@github.com>

On Tue, 3 Dec 2024 13:37:41 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2048:
>> 
>>> 2046:   const int64_t single_table_size = 256;
>>> 2047:   const int64_t table_num = 8;   // 4 for scalar, 4 for plain vector
>>> 2048:   const ExternalAddress table_addr = StubRoutines::crc_table_addr();
>> 
>> Wouldn't it be easier and clearer to have a dedicated table?
>
> Make sense to me, I'll fix it later.

If we do it as you suggested, we could either add new api in shared class `StubRoutines` or we add and use something like StubRoutines::riscv::vclmul_crc_table() directly, but seems either ways are not good enough, and I see other platforms are using the similar pattern as the current patch.
So maybe we should keep it as it is now?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1867753596

From liach at openjdk.org  Tue Dec  3 14:09:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 3 Dec 2024 14:09:38 GMT
Subject: RFR: 8341649: Regressions with large metaspace apps after 8338526
In-Reply-To: <The-qyaafD_DQ8oINTaLTpQrlCdhJNhvKAYCCqkdEZ0=.fc8cdfa6-0a09-45b0-a3b2-77cf1280dac2@github.com>
References: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
 <The-qyaafD_DQ8oINTaLTpQrlCdhJNhvKAYCCqkdEZ0=.fc8cdfa6-0a09-45b0-a3b2-77cf1280dac2@github.com>
Message-ID: <H4yo5vxWYRCEyu2IGSFIxtxzR1cAcDvumoy7Dj65wQk=.da2a61b0-320d-4378-a4ee-8b4c3efb5e1c@github.com>

On Tue, 3 Dec 2024 13:39:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>  It would be really nice if there was some ACC_ALLSTATIC which meant that the code cannot create instances of these classes but that doesn't exist.

The Lambda form implementation classes do not have any `<init>` constructor methods.  Can that clue be used by the VM, as I believe many other bytecode generation users use the same technique to create static utility classes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22493#issuecomment-2514657149

From ihse at openjdk.org  Tue Dec  3 14:30:42 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 3 Dec 2024 14:30:42 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <UnDnPUetpeDdB_t24QbjT6XXx_ZK_l8MJrRvqpQXAhc=.52238613-4b53-4dca-aed2-4b9e27fdef96@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <UnDnPUetpeDdB_t24QbjT6XXx_ZK_l8MJrRvqpQXAhc=.52238613-4b53-4dca-aed2-4b9e27fdef96@github.com>
Message-ID: <2QmSUsTORzIEAX-FEPnnPcfk9lzIpFzEfkNFxDKv1Mk=.4a555875-9d22-4eaa-9b51-8436094cd9bd@github.com>

On Mon, 2 Dec 2024 18:40:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> src/java.base/share/classes/java/lang/VersionProps.java.template line 131:
> 
>> 129:         // Default branding.conf value is "N/A", which did not affect java.vm.vendor
>> 130:         if (! VENDOR_VM.equals("N/A")) {
>> 131:             props.put("java.vm.vendor", VENDOR_VM);
> 
> Magnus might have suggestions on this, maybe it would be better to default in the conf file to the empty string so that we don't have to deal with "N/A" in several places.

We can surely change the default. We just must make sure that all code that uses the vendor define is prepared to handle an empty string.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1867825103

From coleenp at openjdk.org  Tue Dec  3 15:26:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 15:26:39 GMT
Subject: RFR: 8341649: Regressions with large metaspace apps after 8338526
In-Reply-To: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
References: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
Message-ID: <kSPx2AJYkIfggCVupU8Dcj7fBQ1HImlqffxHgnxK-b0=.560e7679-7198-4cb3-9bf4-4ce24645e8c2@github.com>

On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause excess dependency checking for c2 compiled code and shows a performance regression in a new JMH performance test for MethodHandles (to be checked in at a later time).
> 
> When I made this abstract rather than final, I thought there were a many generated classes but I haven't found in testing more than a small percentage.  For example, Dacapo xalan there are 43/1000 classes that are these generated classes.  In Eric's new JMH test, it was more like 51/681.  Special casing "AllStatic" classes to go in non-class metaspace is a bit too risky at this time.  If it does become a problem with limited class metaspace, we can create another attribute to use.
> 
> Tested with tier1-4 and the JMH test.  Thanks Eric Caspole for finding this and all the testing.

I did have a version of this patch that allocated InstanceKlass in non-class metaspace if all methods were static but I thought it was too risky.  But maybe you cannot allocate an object if there's no `<init>` method.  That might be a future patch if we decide that there are too many of these generated classes filling up limited class metaspace.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22493#issuecomment-2514868050

From stuefe at openjdk.org  Tue Dec  3 15:37:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 3 Dec 2024 15:37:39 GMT
Subject: RFR: 8341649: Regressions with large metaspace apps after 8338526
In-Reply-To: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
References: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
Message-ID: <BREH92xGHNlIi3pvtR6Oa0obov3gLCGNUhxXW8SSF7w=.5b04d613-8a10-43d3-bf56-f837f9a2aeda@github.com>

On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause excess dependency checking for c2 compiled code and shows a performance regression in a new JMH performance test for MethodHandles (to be checked in at a later time).
> 
> When I made this abstract rather than final, I thought there were a many generated classes but I haven't found in testing more than a small percentage.  For example, Dacapo xalan there are 43/1000 classes that are these generated classes.  In Eric's new JMH test, it was more like 51/681.  Special casing "AllStatic" classes to go in non-class metaspace is a bit too risky at this time.  If it does become a problem with limited class metaspace, we can create another attribute to use.
> 
> Tested with tier1-4 and the JMH test.  Thanks Eric Caspole for finding this and all the testing.

Makes sense

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22493#pullrequestreview-2476060592

From coleenp at openjdk.org  Tue Dec  3 15:46:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 15:46:42 GMT
Subject: RFR: 8341649: Regressions with large metaspace apps after 8338526
In-Reply-To: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
References: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
Message-ID: <xyBAbWQFMIOZELG1NTsvdEWeRdgB7zN0F6MJkrwatF0=.2b2d2f99-21e6-4937-abd1-d7a1a40ba034@github.com>

On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause excess dependency checking for c2 compiled code and shows a performance regression in a new JMH performance test for MethodHandles (to be checked in at a later time).
> 
> When I made this abstract rather than final, I thought there were a many generated classes but I haven't found in testing more than a small percentage.  For example, Dacapo xalan there are 43/1000 classes that are these generated classes.  In Eric's new JMH test, it was more like 51/681.  Special casing "AllStatic" classes to go in non-class metaspace is a bit too risky at this time.  If it does become a problem with limited class metaspace, we can create another attribute to use.
> 
> Tested with tier1-4 and the JMH test.  Thanks Eric Caspole for finding this and all the testing.

Thanks Thomas and Chen.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22493#issuecomment-2514921833

From coleenp at openjdk.org  Tue Dec  3 15:46:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 15:46:43 GMT
Subject: Integrated: 8341649: Regressions with large metaspace apps after
 8338526
In-Reply-To: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
References: <I974VVlzlYFjDUz3xtqbq_zbOgTMX50sYuAHrHGEo30=.646a34cf-fc88-48cc-8137-4292cb08751c@github.com>
Message-ID: <uRAj4KP5XCGQvdMb9LtkddMgESsnJAkEhgdMMnGbIBM=.623fae32-eb01-4431-91ce-acdbaa5ad369@github.com>

On Mon, 2 Dec 2024 17:41:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Putting generated LambdaForm$MH and $DMH in non-class space seems to cause excess dependency checking for c2 compiled code and shows a performance regression in a new JMH performance test for MethodHandles (to be checked in at a later time).
> 
> When I made this abstract rather than final, I thought there were a many generated classes but I haven't found in testing more than a small percentage.  For example, Dacapo xalan there are 43/1000 classes that are these generated classes.  In Eric's new JMH test, it was more like 51/681.  Special casing "AllStatic" classes to go in non-class metaspace is a bit too risky at this time.  If it does become a problem with limited class metaspace, we can create another attribute to use.
> 
> Tested with tier1-4 and the JMH test.  Thanks Eric Caspole for finding this and all the testing.

This pull request has now been integrated.

Changeset: ba509393
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba5093935ddedfecaaa80d3107dc0d84d4d18756
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8341649: Regressions with large metaspace apps after 8338526

Reviewed-by: liach, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/22493

From coleenp at openjdk.org  Tue Dec  3 16:04:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 16:04:42 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v7]
In-Reply-To: <XFvevUm3-tX2xCH-E8rzd1yLdse-CGtYVBBlgxsmoTQ=.d37ad96c-14c3-4029-a2dd-c1af69a17752@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <XFvevUm3-tX2xCH-E8rzd1yLdse-CGtYVBBlgxsmoTQ=.d37ad96c-14c3-4029-a2dd-c1af69a17752@github.com>
Message-ID: <5migBxpt1CT5ptBAT0198egw7II0wVTQf5yOw_FS4lE=.8cfaa005-b1a1-4571-be4a-fe5cedd9bb8b@github.com>

On Mon, 2 Dec 2024 23:03:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed one. Another good reason to not copy code.

I did my patch this way because I thought for the test failures, that SharedBaseAddress shouldn't be a user error.  It doesn't fail mostly because it's ignored when the OS can't map to that address so I thought that this should ignore it too, rather than give a fatal error.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2514967757

From phh at openjdk.org  Tue Dec  3 16:27:44 2024
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 3 Dec 2024 16:27:44 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v5]
In-Reply-To: <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
Message-ID: <ZQtfyOQPndXqHT4kM9UNmVipjlXFer0s3AFEfiFb_Vo=.27f7abdf-4764-4ced-8dcb-3ea0e4f560c7@github.com>

On Mon, 2 Dec 2024 17:49:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do the explicit == 0 check

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22479#pullrequestreview-2476193103

From shade at openjdk.org  Tue Dec  3 16:32:00 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Dec 2024 16:32:00 GMT
Subject: RFR: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed [v5]
In-Reply-To: <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
 <oXGIoh00ELmr0M8NPkxK6-9SUWV8BpaOx5toxT32FQg=.5e0725da-3fdb-4381-921f-e6061c8b8bd1@github.com>
Message-ID: <v-w-PAx5E8-ECKpS7vJ8x3-Pg_1RsBA-bhzAadcZAw4=.d3b55a9c-8ec4-40fb-a556-cbea773cc71a@github.com>

On Mon, 2 Dec 2024 17:49:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
>> 
>> 
>> int VM_Version::get_current_sve_vector_length() {
>>   assert(VM_Version::supports_sve(), "should not call this");
>>   return prctl(PR_SVE_GET_VL);
>> }
>> 
>> 
>> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
>> 
>> Additional testing:
>>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>>  - [x] Linux AArch64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do the explicit == 0 check

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22479#issuecomment-2515030375

From shade at openjdk.org  Tue Dec  3 16:32:05 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Dec 2024 16:32:05 GMT
Subject: Integrated: 8345296: AArch64: VM crashes with SIGILL when prctl is
 disallowed
In-Reply-To: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
References: <YeSHkgezRZC3CLZDi2vrkgxRYvIXjy-zgmMgDj9glYg=.22a905fb-5476-44f6-b9ba-4445898d927d@github.com>
Message-ID: <x-Ecn0m2nFoDK4D_gosEbXHjBGmOBOqphEhLGL-ZpZU=.bdff0900-153c-452e-8b5c-dbb6f65a0e6c@github.com>

On Mon, 2 Dec 2024 12:17:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> We have caught this in some prod environments, where `prctl` is forbidden by the sandboxing mechanism. This fails the JVM, because we have the following code to check for SVE vector length:
> 
> 
> int VM_Version::get_current_sve_vector_length() {
>   assert(VM_Version::supports_sve(), "should not call this");
>   return prctl(PR_SVE_GET_VL);
> }
> 
> 
> That code returns `-1` when `prctl` is disallowed, which JVM then blindly interprets as vector length, leading to `SIGILL`. I looked around other uses of `prctl` around Hotspot, and they all seem to handle the errors correctly.
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, with seccomp reproducer
>  - [x] Linux AArch64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: 3c60f0b2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c60f0b2bb75150d49da9ab94d88b767275de5e2
Stats:     13 lines in 1 file changed: 12 ins; 0 del; 1 mod

8345296: AArch64: VM crashes with SIGILL when prctl is disallowed

Reviewed-by: eastigeevich, phh, aph

-------------

PR: https://git.openjdk.org/jdk/pull/22479

From henryjen at openjdk.org  Tue Dec  3 16:32:42 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 3 Dec 2024 16:32:42 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <2QmSUsTORzIEAX-FEPnnPcfk9lzIpFzEfkNFxDKv1Mk=.4a555875-9d22-4eaa-9b51-8436094cd9bd@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <UnDnPUetpeDdB_t24QbjT6XXx_ZK_l8MJrRvqpQXAhc=.52238613-4b53-4dca-aed2-4b9e27fdef96@github.com>
 <2QmSUsTORzIEAX-FEPnnPcfk9lzIpFzEfkNFxDKv1Mk=.4a555875-9d22-4eaa-9b51-8436094cd9bd@github.com>
Message-ID: <uh1S8K-Km65ExyICMt06HhtEzAAY95iC9UCHZsdKvPg=.f4f160a1-021a-471e-a897-2a8cedd43276@github.com>

On Tue, 3 Dec 2024 14:28:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VersionProps.java.template line 131:
>> 
>>> 129:         // Default branding.conf value is "N/A", which did not affect java.vm.vendor
>>> 130:         if (! VENDOR_VM.equals("N/A")) {
>>> 131:             props.put("java.vm.vendor", VENDOR_VM);
>> 
>> Magnus might have suggestions on this, maybe it would be better to default in the conf file to the empty string so that we don't have to deal with "N/A" in several places.
>
> We can surely change the default. We just must make sure that all code that uses the vendor define is prepared to handle an empty string.

I think the issue is not the default value, but the special treatment with default value. Is there a reason we didn't set COMPANY_NAME to "N/A" as in branding.conf?
https://github.com/openjdk/jdk/blame/master/make/autoconf/spec.gmk.template#L276-L285

Instead of default to "N/A", personally I think "OpenJDK" as an organization can be used?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868041678

From sgehwolf at openjdk.org  Tue Dec  3 17:03:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Dec 2024 17:03:45 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <uh1S8K-Km65ExyICMt06HhtEzAAY95iC9UCHZsdKvPg=.f4f160a1-021a-471e-a897-2a8cedd43276@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <UnDnPUetpeDdB_t24QbjT6XXx_ZK_l8MJrRvqpQXAhc=.52238613-4b53-4dca-aed2-4b9e27fdef96@github.com>
 <2QmSUsTORzIEAX-FEPnnPcfk9lzIpFzEfkNFxDKv1Mk=.4a555875-9d22-4eaa-9b51-8436094cd9bd@github.com>
 <uh1S8K-Km65ExyICMt06HhtEzAAY95iC9UCHZsdKvPg=.f4f160a1-021a-471e-a897-2a8cedd43276@github.com>
Message-ID: <6b6QTyk1-if8DIdaGv5NmWb_UIIKeA0q3Wjw7jaPYyE=.2c5183a6-61ae-4b6d-9965-0f6cf1b6329e@github.com>

On Tue, 3 Dec 2024 16:29:52 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> Instead of default to "N/A", personally I think "OpenJDK" as an organization can be used?

OpenJDK is a source only distribution. As such vendor being set to OpenJDK for the binary doesn't make sense. It's the downstream distro shipping the binary that should set it. "N/A" is OK. I don't know if the empty string is a good one.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868091930

From henryjen at openjdk.org  Tue Dec  3 17:34:44 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 3 Dec 2024 17:34:44 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
In-Reply-To: <6b6QTyk1-if8DIdaGv5NmWb_UIIKeA0q3Wjw7jaPYyE=.2c5183a6-61ae-4b6d-9965-0f6cf1b6329e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <UnDnPUetpeDdB_t24QbjT6XXx_ZK_l8MJrRvqpQXAhc=.52238613-4b53-4dca-aed2-4b9e27fdef96@github.com>
 <2QmSUsTORzIEAX-FEPnnPcfk9lzIpFzEfkNFxDKv1Mk=.4a555875-9d22-4eaa-9b51-8436094cd9bd@github.com>
 <uh1S8K-Km65ExyICMt06HhtEzAAY95iC9UCHZsdKvPg=.f4f160a1-021a-471e-a897-2a8cedd43276@github.com>
 <6b6QTyk1-if8DIdaGv5NmWb_UIIKeA0q3Wjw7jaPYyE=.2c5183a6-61ae-4b6d-9965-0f6cf1b6329e@github.com>
Message-ID: <G4hmdHGNCyWamb5Gumhl6N7jJRung_HSnNF9Ie-24w8=.7708d19c-a6d2-4529-b9ac-c565ff3d4136@github.com>

On Tue, 3 Dec 2024 17:01:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I think the issue is not the default value, but the special treatment with default value. Is there a reason we didn't set COMPANY_NAME to "N/A" as in branding.conf?
>> https://github.com/openjdk/jdk/blame/master/make/autoconf/spec.gmk.template#L276-L285
>> 
>> Instead of default to "N/A", personally I think "OpenJDK" as an organization can be used?
>
>> Instead of default to "N/A", personally I think "OpenJDK" as an organization can be used?
> 
> OpenJDK is a source only distribution. As such vendor being set to OpenJDK for the binary doesn't make sense. It's the downstream distro shipping the binary that should set it. "N/A" is OK. I don't know if the empty string is a good one.

Point taken.
I would imagine downstream vendor would modify branding.conf to proper value instead of using the default.

"N/A" is fine to me, question is whether COMPANY_NAME should be derived from branding.conf regardless.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868138657

From cjplummer at openjdk.org  Tue Dec  3 19:08:40 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 3 Dec 2024 19:08:40 GMT
Subject: RFR: 8344987: Test
 serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails:
 NoClassDefFoundError: jdk/test/lib/Utils
In-Reply-To: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
References: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
Message-ID: <LpZyZNcTTtYmLWV706jm6-v8wD6WvuRuCb7SFyf-Ip4=.ded33e36-d99d-43ab-b40f-dd4f39f43804@github.com>

On Wed, 27 Nov 2024 02:13:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The real bug is
> https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library
> 
> and the following workaround just excludes the testing group where it fails often. 
> 
> There is no plans to update test right now. The jtreg should be fixed.

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22405#pullrequestreview-2476567147

From pchilanomate at openjdk.org  Tue Dec  3 20:11:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 3 Dec 2024 20:11:53 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
Message-ID: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>

Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.

Thanks,
Patricio

-------------

Commit messages:
 - v1

Changes: https://git.openjdk.org/jdk/pull/22524/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343957
  Stats: 83 lines in 19 files changed: 0 ins; 2 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/22524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22524/head:pull/22524

PR: https://git.openjdk.org/jdk/pull/22524

From lmesnik at openjdk.org  Tue Dec  3 20:35:48 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 3 Dec 2024 20:35:48 GMT
Subject: Integrated: 8344987: Test
 serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails:
 NoClassDefFoundError: jdk/test/lib/Utils
In-Reply-To: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
References: <15eNCXw4oid2xwKbfjrFJ0gLo9w-ZekovlM4-mLnSeM=.13db466d-cbdd-4c4e-b589-4f57c326f623@github.com>
Message-ID: <tLru6IHLhTdNIbO6UWFuj8gwwhnH0U7FRI6xoqmL6Kw=.36750b3b-697f-4b2d-89c8-03491cc1e5a8@github.com>

On Wed, 27 Nov 2024 02:13:41 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The real bug is
> https://bugs.openjdk.org/browse/CODETOOLS-7902847 Class directory of a test case should not be used to compile a library
> 
> and the following workaround just excludes the testing group where it fails often. 
> 
> There is no plans to update test right now. The jtreg should be fixed.

This pull request has now been integrated.

Changeset: 0664b517
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0664b517650c622dcf21f8bd2e3e389e7d81bbab
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8344987: Test serviceability/sa/TestJhsdbJstackPrintVMLocks.java fails: NoClassDefFoundError: jdk/test/lib/Utils

Reviewed-by: cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/22405

From henryjen at openjdk.org  Tue Dec  3 22:32:05 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Tue, 3 Dec 2024 22:32:05 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v2]
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <AfctDlu-HWYnS1tpHZ4MGbjxWrwUuC044SpJ6zoZBBA=.1b584b15-0194-4187-9da8-c42f78ae6acb@github.com>

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8342035
 - include only needed in .cpp
 - Merge remote-tracking branch 'openjdk/master' into JDK-8342035
 - Avoid N/A used as java.vm.vendor value as currently build behavior
 - 8342035: jlink plugins for setting java.vendor, java.vm.vendor and java.vendor.url

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21964/files
  - new: https://git.openjdk.org/jdk/pull/21964/files/49f19577..096692d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=00-01

  Stats: 303781 lines in 5209 files changed: 146673 ins; 135141 del; 21967 mod
  Patch: https://git.openjdk.org/jdk/pull/21964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21964/head:pull/21964

PR: https://git.openjdk.org/jdk/pull/21964

From coleenp at openjdk.org  Tue Dec  3 23:00:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 23:00:37 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <xCBI5JCMILoD-f0Ec5WI5NEHktmOVa8Z9dQ2h7UrJqA=.32609b13-0626-458b-93c3-32eb96f27421@github.com>

On Tue, 3 Dec 2024 19:10:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

Renaming looks good and makes it clearer what the id is.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22524#pullrequestreview-2476917190

From coleenp at openjdk.org  Tue Dec  3 23:15:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 23:15:43 GMT
Subject: RFR: 8328944: NMT reports "unknown" memory [v4]
In-Reply-To: <WE3g3ujzzV9COo98K9kSBuhjku1qQBsh7Lp3ajsZsDg=.53795dab-550d-47b2-96b1-55cdfe82d111@github.com>
References: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
 <WE3g3ujzzV9COo98K9kSBuhjku1qQBsh7Lp3ajsZsDg=.53795dab-550d-47b2-96b1-55cdfe82d111@github.com>
Message-ID: <pspug4-ZX9r4bMNHpXLFsTFZMR4ru4_zjkNhExkP6Kw=.7b4de66f-08d1-433a-99fe-314cea816446@github.com>

On Thu, 21 Nov 2024 21:09:33 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We use `mtNone` value in several functions default parameters, which may show up in NMT reports.
>> 
>> We address this, by avoiding using `mtNone`.
>> 
>> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that.
>> 
>> Testing: passes MARCH5 tier1-5
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stefan's feedback

Yes, this is much better to require the mt parameter to be passed down rather than fixing it up after the memory reservation, and having some code miss doing it.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21843#pullrequestreview-2476944377

From coleenp at openjdk.org  Tue Dec  3 23:16:52 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 23:16:52 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v8]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <TnhBB2r0-UYb5FzA-2hPCNTaFZ6X9EMitYjA-b5M3Yo=.946e0ede-847f-4171-8584-ebe23ccdb65b@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Only calculate klass-decode-mode in one place.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21695/files
  - new: https://git.openjdk.org/jdk/pull/21695/files/cf6f9124..16cdc5b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=06-07

  Stats: 36 lines in 3 files changed: 10 ins; 15 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From dholmes at openjdk.org  Tue Dec  3 23:32:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 3 Dec 2024 23:32:39 GMT
Subject: RFR: 8344609: Check ResourceMark nesting when allocating a
 GrowableArray on an alternative ResourceArea [v3]
In-Reply-To: <inlLn9OWfyqk_1WaK7IzYIgQbbHDVrGjOLpXwR_gFsw=.24ae107d-069c-4eee-84dd-7401cdf15404@github.com>
References: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
 <inlLn9OWfyqk_1WaK7IzYIgQbbHDVrGjOLpXwR_gFsw=.24ae107d-069c-4eee-84dd-7401cdf15404@github.com>
Message-ID: <ZxbHz4cebOcxO5TwMQg89TquLPFj9i2iIhmSgvHWrk4=.c071f0db-91db-4384-94b7-550d38a01d0b@github.com>

On Mon, 2 Dec 2024 13:42:25 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`.
>> 
>> The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085).
>> 
>> The fix passed our nightly CI testing:
>> Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests.
>> Testing was done on the main platforms and also on Linux/PPC64le and AIX.
>> 
>> Besides ctw tests on ppc64 (see [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085)) the check never failed.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master'
>  - Add parentheses
>  - Check GrowableArray nesting if allocating on alternative ResourceArea

I ran this through our CI as well - no issues in T1-4

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22269#issuecomment-2515800342

From dholmes at openjdk.org  Wed Dec  4 01:30:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 01:30:48 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
Message-ID: <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>

On Fri, 22 Nov 2024 09:17:53 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into hotspot
>  - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp
>  - fmod_win64 in sharedRuntime.cpp
>  - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp
>  - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - No spaces in test_os_windows.cpp
>  - No spaces in test/hotspot/gtest/runtime/test_os.cpp
>    
>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>  - Revise comment in sharedRuntime.hpp
>  - Revise comment in sharedRuntime.cpp
>  - size_t brace initialization instead of unsigned literals in test_os_windows.cpp
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/857311cb...6cf1c83a

So for the sharedRuntime changes, IIUC what was previously only needed for Windows x64 is now only needed for Windows Aarch64 - correct?

src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:

> 26: #include "runtime/sharedRuntime.hpp"
> 27: 
> 28: #ifdef _M_ARM64

As this is ARM64 only now, the comment block at line 34 needs updating

src/hotspot/os/windows/sharedRuntimeRem.cpp line 42:

> 40: static const double one = 1.0, Zero[] = { 0.0, -0.0, };
> 41: 
> 42: double SharedRuntime::fmod_win64(double x, double y)

Wouldn't `fmod_winAarch64` or `fmod_winARM64` make more sense given this is now only used for Aarch64?

src/hotspot/share/runtime/sharedRuntime.cpp line 287:

> 285: 
> 286: 
> 287: #ifdef _M_ARM64

If this is ARM64 only then the `#if !defined(X86)` at line 294 is not needed.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21627#pullrequestreview-2477063681
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868566991
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868569795
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868568059

From dholmes at openjdk.org  Wed Dec  4 01:30:49 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 01:30:49 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <v-Eb-qk7za6FoznAuBTpma0zksIDFPJNxzQEPeS2Irc=.3917f8f4-3af7-4f11-b1fe-83cd2042bd25@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <iZMBG6lBQrnozZH0YHY5-0o0tbtODDPwTyHg3s4X3eQ=.875fb772-177f-4425-bf26-e9f70e1a04f1@github.com>
 <GdzhrSnhzRRzRA0fHs7zd8gKBSvR1-l8tPH3P9a9Vho=.349ee0a9-fdf3-4494-ade6-bcbc51b31b78@github.com>
 <v-Eb-qk7za6FoznAuBTpma0zksIDFPJNxzQEPeS2Irc=.3917f8f4-3af7-4f11-b1fe-83cd2042bd25@github.com>
Message-ID: <rsfBxtIAUxuoewuF_9r92atpkSP2FNmyLLPdysbM9ok=.a9aa6364-cbfe-4517-b44f-c4b68cb355b3@github.com>

On Tue, 3 Dec 2024 07:11:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I had forgotten completely about the review request feature, thanks for reminding me :)

Only works if you have Github notifications enabled (I don't) else you have to return to the PR to see it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2515964242

From dholmes at openjdk.org  Wed Dec  4 01:47:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 01:47:39 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <K5QJS8g6pvQ7Kf2_-Bl2FAyKWFtQBhcxG6cyalDif6w=.022e4ddf-5e79-4b16-a931-959c4fff5b7f@github.com>

On Tue, 3 Dec 2024 19:10:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

Thanks for making the changes.

One minor nit, but looks good.

src/hotspot/share/runtime/javaThread.hpp line 174:

> 172:   void set_monitor_owner_id(int64_t val) {
> 173:     assert(val >= ThreadIdentifier::initial() && val < ThreadIdentifier::current(), "");
> 174:     _monitor_owner_id = val;

Nit: Using `id`  rather than `val` would be more consistent with other changes (`ObjectMonitor::owner_id_from`)

src/hotspot/share/runtime/threads.cpp line 1363:

> 1361:         p->print_stack_on(st);
> 1362:         if (p->is_vthread_mounted()) {
> 1363:           st->print_cr("   Mounted virtual thread #" INT64_FORMAT, java_lang_Thread::thread_id(p->vthread()));

Was initially unsure why `p->lock_id()` didn't change to `p->monitor_owner_id()`, but here you want the thread-id not something that happens to match the thread-id.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22524#pullrequestreview-2477079004
PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1868577497
PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1868580851

From fyang at openjdk.org  Wed Dec  4 01:47:42 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 4 Dec 2024 01:47:42 GMT
Subject: Integrated: 8345351: RISC-V: Rename macro-assembler routine
 cmpxchg_weak to weak_cmpxchg
In-Reply-To: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>
References: <E81EoeNnFBQdgI2gux_jGmFx3nVGZ03_q-Bw-4w540g=.335c03c6-473a-4bb9-815e-f8382bd7f193@github.com>
Message-ID: <CkPAxWmZeDADSKzIR-cWv7DqxYfJtXXI3Wmqm17sEZc=.a9ab3cfc-bec4-4158-9e4c-006191614f03@github.com>

On Tue, 3 Dec 2024 01:31:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, Please consider this trivial change.
> 
> We have macro-assembler routine names like `cmpxchg_narrow_value` and `weak_cmpxchg_narrow_value`. And we also have `cmpxchg` and `cmpxchg_weak`. We should rename `MacroAssembler::cmpxchg_weak` to `MacroAssembler::weak_cmpxchg` for consistency in naming with friends. This will also be consistent with names like `weakCompareAndSwapI`, `weakCompareAndSwapL` in AD files.
> 
> - [x] hotspot:tier1 test on linux-riscv64 platform.

This pull request has now been integrated.

Changeset: c143138a
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c143138a35689605ebe44d847904e226ffcaeb74
Stats:     23 lines in 4 files changed: 0 ins; 0 del; 23 mod

8345351: RISC-V: Rename macro-assembler routine cmpxchg_weak to weak_cmpxchg

Reviewed-by: rehn, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22505

From fyang at openjdk.org  Wed Dec  4 01:51:39 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 4 Dec 2024 01:51:39 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v5]
In-Reply-To: <2JKi_Goke42hWmNW04ioGKBy0_Sj2qycjbyt83tEu54=.04ac83b2-9f8f-414f-bb89-18c0ea4f915d@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <2JKi_Goke42hWmNW04ioGKBy0_Sj2qycjbyt83tEu54=.04ac83b2-9f8f-414f-bb89-18c0ea4f915d@github.com>
Message-ID: <KxHHLXuNyKtSnS4-2SsW16Z9o0J1VMu_RWfjoA-c5aA=.6c4846c6-17bd-41f3-a6b5-0c99c6ddfcfa@github.com>

On Tue, 3 Dec 2024 07:34:04 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned weak narrow cmpxchg.
>> 
>> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20997 ms total)
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed WS

Hi, Please merge with latest jdk master as https://github.com/openjdk/jdk/pull/22505 has been integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22476#issuecomment-2515984785

From jwaters at openjdk.org  Wed Dec  4 04:15:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Dec 2024 04:15:39 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
Message-ID: <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>

On Wed, 4 Dec 2024 01:26:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

> So for the sharedRuntime changes, IIUC what was previously only needed for Windows x64 is now only needed for Windows Aarch64 - correct?

Yes, that seems to be the case

> src/hotspot/os/windows/sharedRuntimeRem.cpp line 42:
> 
>> 40: static const double one = 1.0, Zero[] = { 0.0, -0.0, };
>> 41: 
>> 42: double SharedRuntime::fmod_win64(double x, double y)
> 
> Wouldn't `fmod_winAarch64` or `fmod_winARM64` make more sense given this is now only used for Aarch64?

The name was suggested by Andrew, I'll change it to fmod_winarm64 if you prefer

> src/hotspot/share/runtime/sharedRuntime.cpp line 287:
> 
>> 285: 
>> 286: 
>> 287: #ifdef _M_ARM64
> 
> If this is ARM64 only then the `#if !defined(X86)` at line 294 is not needed.

Wouldn't this cause a multiple definition error for frem and drem if the #if !defined(X86) was removed? The #if prevents those 2 methods from being defined when on x86 so it doesn't conflict with the x86 specific definitions, without it frem and drem would be defined twice on x86

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21627#issuecomment-2516148063
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868690717
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868691936

From jwaters at openjdk.org  Wed Dec  4 04:27:17 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Dec 2024 04:27:17 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v10]
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <lP0N-gIZ6i5AAePFrAwga6F3M-o4UdE9kH5tdxg4_4w=.f1872433-720f-4dd1-b12b-31ed8ebe4634@github.com>

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

Julian Waters has updated the pull request incrementally with two additional commits since the last revision:

 - Typo in sharedRuntimeRem.cpp
 - Comment in sharedRuntimeRem.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21627/files
  - new: https://git.openjdk.org/jdk/pull/21627/files/6cf1c83a..3fe38a6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=08-09

  Stats: 7 lines in 1 file changed: 2 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627

PR: https://git.openjdk.org/jdk/pull/21627

From jwaters at openjdk.org  Wed Dec  4 04:27:20 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Dec 2024 04:27:20 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
Message-ID: <dnke5O47Jcfuj_pdxk1sVp_c2Z279G6BhQTCl6Z5ixE=.95959d25-1cfa-4f96-947f-c35c59ac9a3a@github.com>

On Wed, 4 Dec 2024 01:19:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into hotspot
>>  - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp
>>  - fmod_win64 in sharedRuntime.cpp
>>  - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp
>>  - fmod_win64 in src/hotspot/share/runtime/sharedRuntime.hpp
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - No spaces in test_os_windows.cpp
>>  - No spaces in test/hotspot/gtest/runtime/test_os.cpp
>>    
>>    Co-authored-by: Andrew Haley <aph-open at littlepinkcloud.com>
>>  - Revise comment in sharedRuntime.hpp
>>  - Revise comment in sharedRuntime.cpp
>>  - size_t brace initialization instead of unsigned literals in test_os_windows.cpp
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/741dd6d5...6cf1c83a
>
> src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:
> 
>> 26: #include "runtime/sharedRuntime.hpp"
>> 27: 
>> 28: #ifdef _M_ARM64
> 
> As this is ARM64 only now, the comment block at line 34 needs updating

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868698927

From amitkumar at openjdk.org  Wed Dec  4 04:34:15 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Dec 2024 04:34:15 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v2]
In-Reply-To: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
Message-ID: <G-bCVjjFsXQpViVtEipC8Uc_19Ud_terPCm5B2sKxco=.1eaa28e0-887d-43d7-8d74-64ef1fe225e2@github.com>

> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
> 
> 
> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
> 
> 
> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
> 
> This is the output with current changes: 
> 
> 
> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Correct NNP Assist Facility Mask

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22508/files
  - new: https://git.openjdk.org/jdk/pull/22508/files/0f7e8d08..6b51ebce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22508&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22508&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22508/head:pull/22508

PR: https://git.openjdk.org/jdk/pull/22508

From amitkumar at openjdk.org  Wed Dec  4 04:34:15 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Dec 2024 04:34:15 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v2]
In-Reply-To: <G-bCVjjFsXQpViVtEipC8Uc_19Ud_terPCm5B2sKxco=.1eaa28e0-887d-43d7-8d74-64ef1fe225e2@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
 <G-bCVjjFsXQpViVtEipC8Uc_19Ud_terPCm5B2sKxco=.1eaa28e0-887d-43d7-8d74-64ef1fe225e2@github.com>
Message-ID: <Cp-Bl5nZpEbXMyq1cZvUaNHrm7YnDMYMWWXHQ6oaaVw=.88a39009-7b27-4829-8330-73d5b6a00f24@github.com>

On Wed, 4 Dec 2024 04:30:47 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
>> 
>> 
>> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>> 
>> 
>> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
>> 
>> This is the output with current changes: 
>> 
>> 
>> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct NNP Assist Facility Mask

src/hotspot/cpu/s390/vm_version_s390.hpp line 93:

> 91: 
> 92: #define BEAREnhFacilityMask             0x4000000000000000UL  // z16, BEAR-enhancement facility, Bit: 193
> 93: #define NNPAssistFacilityMask           0x0000000000040000UL  // z16, Neural-network-processing-assist facility, Bit: 165

[My script](https://github.com/offamitkumar/s390xFacilityMask) says that this should be 
Suggestion:

#define NNPAssistFacilityMask           0x0000000004000000UL  // z16, Neural-network-processing-assist facility, Bit: 165



Enter Facility Bit Number: 165
_feature array index: 2
bit position to set: 37
bit string: 0000000000000000000000000000000000000100000000000000000000000000
Mask:  0x0000000004000000UL

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22508#discussion_r1868702977

From amitkumar at openjdk.org  Wed Dec  4 05:10:57 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Dec 2024 05:10:57 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v3]
In-Reply-To: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
Message-ID: <Kqe6x1_Nh5Bkri2FqaFRqyNTy5sgTbMrpdPaNFuWVGs=.16304819-9dd8-4313-b82c-63e3ade36330@github.com>

> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
> 
> 
> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
> 
> 
> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
> 
> This is the output with current changes: 
> 
> 
> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  make other mask consistent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22508/files
  - new: https://git.openjdk.org/jdk/pull/22508/files/6b51ebce..8e8fa379

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22508&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22508&range=01-02

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22508/head:pull/22508

PR: https://git.openjdk.org/jdk/pull/22508

From amitkumar at openjdk.org  Wed Dec  4 05:22:17 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Dec 2024 05:22:17 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v4]
In-Reply-To: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
Message-ID: <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>

> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
> 
> 
> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
> 
> 
> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
> 
> This is the output with current changes: 
> 
> 
> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash

Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:

  move mask to correction location

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22508/files
  - new: https://git.openjdk.org/jdk/pull/22508/files/8e8fa379..71dd1170

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22508&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22508&range=02-03

  Stats: 9 lines in 1 file changed: 6 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22508.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22508/head:pull/22508

PR: https://git.openjdk.org/jdk/pull/22508

From henryjen at openjdk.org  Wed Dec  4 05:24:15 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 05:24:15 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v3]
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Set java.vm.vendor from VersionProps.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21964/files
  - new: https://git.openjdk.org/jdk/pull/21964/files/096692d2..c07b4e4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=01-02

  Stats: 36 lines in 6 files changed: 0 ins; 32 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21964/head:pull/21964

PR: https://git.openjdk.org/jdk/pull/21964

From henryjen at openjdk.org  Wed Dec  4 05:30:43 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 05:30:43 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v3]
In-Reply-To: <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
Message-ID: <qG1Mab-TFS-mVGpvKZvg9rDG338DCz1yS9W3fyYUu6Y=.0e793c09-8ba5-46e0-afc2-b434ae3e4850@github.com>

On Wed, 4 Dec 2024 05:24:15 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set java.vm.vendor from VersionProps.java

In the latest commit, we simplify the java.vm.vendor to be set by VersionProps.java with hotspot not to set the property.

If a different VM implementation actually set the property, then we keeps the existing value.

Also, we allow branding.conf N/A value to be used when --with-vendor not specified.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21964#issuecomment-2516227357

From henryjen at openjdk.org  Wed Dec  4 05:35:38 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 05:35:38 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v3]
In-Reply-To: <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
Message-ID: <X-Xx02I9C8aB7TjZ4M_8t3_SFK6EYBAYilq9ea55o9U=.dd31e349-bf3a-4073-b015-5dcb2064f1ed@github.com>

On Wed, 4 Dec 2024 05:24:15 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set java.vm.vendor from VersionProps.java

src/java.base/share/classes/java/lang/VersionProps.java.template line 97:

> 95:         "@@VENDOR_URL_VM_BUG@@";
> 96: 
> 97:     @SuppressWarnings("unused")

This is no longer needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868744023

From dholmes at openjdk.org  Wed Dec  4 06:02:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 06:02:40 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v3]
In-Reply-To: <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
Message-ID: <j-4D4y0vJ1gGQ5pk6GiSaqFY4tYAaKmZdKE92jJTpbQ=.f1348866-7504-4395-b8ed-b26a4f4385d7@github.com>

On Wed, 4 Dec 2024 05:24:15 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set java.vm.vendor from VersionProps.java

src/hotspot/share/runtime/abstract_vm_version.cpp line 132:

> 130: 
> 131: static const char vm_vendor_string[sizeof(VENDOR) < VENDOR_PADDING ? VENDOR_PADDING : sizeof(VENDOR)] = VENDOR;
> 132: const char* Abstract_VM_Version::_vendor_branding_override = nullptr;

Can't we just have:

const char* Abstract_VM_Version::_vm_vendor = vm_vendor_string; // Default unless overridden from VersionProps
const char* Abstract_VM_Version::vm_vendor() { return _vm_vendor; }
void Abstract_VM_Version::set_vm_vendor(const char* vm_vendor) {
  _vm_vendor = ...
}

???

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868765345

From dholmes at openjdk.org  Wed Dec  4 06:06:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 06:06:38 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v3]
In-Reply-To: <j-4D4y0vJ1gGQ5pk6GiSaqFY4tYAaKmZdKE92jJTpbQ=.f1348866-7504-4395-b8ed-b26a4f4385d7@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
 <j-4D4y0vJ1gGQ5pk6GiSaqFY4tYAaKmZdKE92jJTpbQ=.f1348866-7504-4395-b8ed-b26a4f4385d7@github.com>
Message-ID: <WlVSJp0-T0ZJsHyRw_w7bdFWj11FcpeuHvZRyzrnJPE=.3d70341b-d7c2-454d-b3b7-a1f0938b69cc@github.com>

On Wed, 4 Dec 2024 05:59:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Set java.vm.vendor from VersionProps.java
>
> src/hotspot/share/runtime/abstract_vm_version.cpp line 132:
> 
>> 130: 
>> 131: static const char vm_vendor_string[sizeof(VENDOR) < VENDOR_PADDING ? VENDOR_PADDING : sizeof(VENDOR)] = VENDOR;
>> 132: const char* Abstract_VM_Version::_vendor_branding_override = nullptr;
> 
> Can't we just have:
> 
> const char* Abstract_VM_Version::_vm_vendor = vm_vendor_string; // Default unless overridden from VersionProps
> const char* Abstract_VM_Version::vm_vendor() { return _vm_vendor; }
> void Abstract_VM_Version::set_vm_vendor(const char* vm_vendor) {
>   _vm_vendor = ...
> }
> 
> ???

Or are you assuming/expecting the VersionProps value is null unless being overridden? You could initialize the VersionProps value to be the same as what VENDOR is at build time and always use it to set the Abstract_VM_Version field ... though I'm not sure if we really need it in Abstract_VM_Version ...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868768746

From dholmes at openjdk.org  Wed Dec  4 06:10:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 4 Dec 2024 06:10:43 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
Message-ID: <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>

On Wed, 4 Dec 2024 04:09:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/sharedRuntimeRem.cpp line 42:
>> 
>>> 40: static const double one = 1.0, Zero[] = { 0.0, -0.0, };
>>> 41: 
>>> 42: double SharedRuntime::fmod_win64(double x, double y)
>> 
>> Wouldn't `fmod_winAarch64` or `fmod_winARM64` make more sense given this is now only used for Aarch64?
>
> The name was suggested by Andrew, I'll change it to fmod_winarm64 if you prefer

I thought at the time the name was because it was for both x64 and aarch64 - hence any win64 platform. But if it is only for Aarch64 then it makes sense to me that the function name conveys that.

>> src/hotspot/share/runtime/sharedRuntime.cpp line 287:
>> 
>>> 285: 
>>> 286: 
>>> 287: #ifdef _M_ARM64
>> 
>> If this is ARM64 only then the `#if !defined(X86)` at line 294 is not needed.
>
> Wouldn't this cause a multiple definition error for frem and drem if the #if !defined(X86) was removed? The #if prevents those 2 methods from being defined when on x86 so it doesn't conflict with the x86 specific definitions, without it frem and drem would be defined twice on x86

But if we enter this block because _M_ARM64 is defined then X86 cannot be defined so line 294 is vacuously true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868772112
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868771179

From henryjen at openjdk.org  Wed Dec  4 06:18:38 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 06:18:38 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v3]
In-Reply-To: <WlVSJp0-T0ZJsHyRw_w7bdFWj11FcpeuHvZRyzrnJPE=.3d70341b-d7c2-454d-b3b7-a1f0938b69cc@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
 <j-4D4y0vJ1gGQ5pk6GiSaqFY4tYAaKmZdKE92jJTpbQ=.f1348866-7504-4395-b8ed-b26a4f4385d7@github.com>
 <WlVSJp0-T0ZJsHyRw_w7bdFWj11FcpeuHvZRyzrnJPE=.3d70341b-d7c2-454d-b3b7-a1f0938b69cc@github.com>
Message-ID: <kb7230d1rkMeOPsokFofnHdNHNLH_A2JYJYukyhB2Bg=.07c835e3-c515-48e1-b764-c7f8e029f544@github.com>

On Wed, 4 Dec 2024 06:04:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/abstract_vm_version.cpp line 132:
>> 
>>> 130: 
>>> 131: static const char vm_vendor_string[sizeof(VENDOR) < VENDOR_PADDING ? VENDOR_PADDING : sizeof(VENDOR)] = VENDOR;
>>> 132: const char* Abstract_VM_Version::_vendor_branding_override = nullptr;
>> 
>> Can't we just have:
>> 
>> const char* Abstract_VM_Version::_vm_vendor = vm_vendor_string; // Default unless overridden from VersionProps
>> const char* Abstract_VM_Version::vm_vendor() { return _vm_vendor; }
>> void Abstract_VM_Version::set_vm_vendor(const char* vm_vendor) {
>>   _vm_vendor = ...
>> }
>> 
>> ???
>
> Or are you assuming/expecting the VersionProps value is null unless being overridden? You could initialize the VersionProps value to be the same as what VENDOR is at build time and always use it to set the Abstract_VM_Version field ... though I'm not sure if we really need it in Abstract_VM_Version ...

We can, if we don't care original value. The origin build of the image would have same value in VersionProps and VM. However, VersionProps value can be altered with JLink plugin when create a new image from the built image.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868777689

From jwaters at openjdk.org  Wed Dec  4 06:24:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Dec 2024 06:24:13 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v11]
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <iyt3ogtf_Cc-j026FaQTdQAqkbbBxBn8JgRARUU_WUQ=.a84405d9-a0dd-4318-8d63-d639a89968d9@github.com>

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - fmod_winarm64 in sharedRuntime.cpp
 - fmod_winarm64 in sharedRuntimeRem.cpp
 - fmod_winarm64 in sharedRuntime.hpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21627/files
  - new: https://git.openjdk.org/jdk/pull/21627/files/3fe38a6b..37e0e4d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=09-10

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627

PR: https://git.openjdk.org/jdk/pull/21627

From jwaters at openjdk.org  Wed Dec  4 06:24:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 4 Dec 2024 06:24:13 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
Message-ID: <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>

On Wed, 4 Dec 2024 06:08:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The name was suggested by Andrew, I'll change it to fmod_winarm64 if you prefer
>
> I thought at the time the name was because it was for both x64 and aarch64 - hence any win64 platform. But if it is only for Aarch64 then it makes sense to me that the function name conveys that.

Alright, I'll change it

>> Wouldn't this cause a multiple definition error for frem and drem if the #if !defined(X86) was removed? The #if prevents those 2 methods from being defined when on x86 so it doesn't conflict with the x86 specific definitions, without it frem and drem would be defined twice on x86
>
> But if we enter this block because _M_ARM64 is defined then X86 cannot be defined so line 294 is vacuously true.

I'm not sure I follow - The _M_ARM64 block is terminated by an endif before line 294, it is only there to define the global constants and does not guard the code below that line 294 does. Additionally, the code guarded by the if X86 seems to be for all non x86 platforms, not just ARM64

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868780144
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1868780027

From henryjen at openjdk.org  Wed Dec  4 06:38:42 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 06:38:42 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v3]
In-Reply-To: <kb7230d1rkMeOPsokFofnHdNHNLH_A2JYJYukyhB2Bg=.07c835e3-c515-48e1-b764-c7f8e029f544@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <TEszPE2rQLf45k5uEAvZbj_hRul_uHEEt-YlqbI5A5k=.83099de6-6510-4bde-922f-6750060e2c0f@github.com>
 <j-4D4y0vJ1gGQ5pk6GiSaqFY4tYAaKmZdKE92jJTpbQ=.f1348866-7504-4395-b8ed-b26a4f4385d7@github.com>
 <WlVSJp0-T0ZJsHyRw_w7bdFWj11FcpeuHvZRyzrnJPE=.3d70341b-d7c2-454d-b3b7-a1f0938b69cc@github.com>
 <kb7230d1rkMeOPsokFofnHdNHNLH_A2JYJYukyhB2Bg=.07c835e3-c515-48e1-b764-c7f8e029f544@github.com>
Message-ID: <Su0YtV2eaA22uShcs1dvluMrUY4osoUSZ8mBEGyMp6g=.76ed14a5-8864-4025-a6c9-f9484daa873b@github.com>

On Wed, 4 Dec 2024 06:15:56 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Or are you assuming/expecting the VersionProps value is null unless being overridden? You could initialize the VersionProps value to be the same as what VENDOR is at build time and always use it to set the Abstract_VM_Version field ... though I'm not sure if we really need it in Abstract_VM_Version ...
>
> We can, if we don't care original value. The origin build of the image would have same value in VersionProps and VM. However, VersionProps value can be altered with JLink plugin when create a new image from the built image.

never mind, the built value is still in vm_vendor_string. Since we should only call set_vm_vendor once, we don't worry about free.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1868794281

From rrich at openjdk.org  Wed Dec  4 07:29:48 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 4 Dec 2024 07:29:48 GMT
Subject: RFR: 8344609: Check ResourceMark nesting when allocating a
 GrowableArray on an alternative ResourceArea [v3]
In-Reply-To: <inlLn9OWfyqk_1WaK7IzYIgQbbHDVrGjOLpXwR_gFsw=.24ae107d-069c-4eee-84dd-7401cdf15404@github.com>
References: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
 <inlLn9OWfyqk_1WaK7IzYIgQbbHDVrGjOLpXwR_gFsw=.24ae107d-069c-4eee-84dd-7401cdf15404@github.com>
Message-ID: <4Q6qRFDU4uFxrLxEHEVXHErkHcXcuNKv6EAGrmXZWPI=.0d03b150-0527-411b-b87e-dcd8d838e36d@github.com>

On Mon, 2 Dec 2024 13:42:25 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`.
>> 
>> The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085).
>> 
>> The fix passed our nightly CI testing:
>> Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests.
>> Testing was done on the main platforms and also on Linux/PPC64le and AIX.
>> 
>> Besides ctw tests on ppc64 (see [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085)) the check never failed.
>
> Richard Reingruber has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master'
>  - Add parentheses
>  - Check GrowableArray nesting if allocating on alternative ResourceArea

Thanks for the reviews and the testing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22269#issuecomment-2516398262

From rrich at openjdk.org  Wed Dec  4 07:29:49 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 4 Dec 2024 07:29:49 GMT
Subject: RFR: 8344609: Check ResourceMark nesting when allocating a
 GrowableArray on an alternative ResourceArea [v3]
In-Reply-To: <Qjsz9XQSjIr-IiAi45yjzloYeOZ4AHWYLTFD_9cIY_0=.55e0d4c7-a74f-4715-8cc1-6478b464e475@github.com>
References: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
 <0BaoLMx7Ia-ghk6qk0Eg47ZMdKK_U-rUoLC0jPS2JkE=.963d7883-5aeb-46da-ba5c-a39f253cf5e6@github.com>
 <Qjsz9XQSjIr-IiAi45yjzloYeOZ4AHWYLTFD_9cIY_0=.55e0d4c7-a74f-4715-8cc1-6478b464e475@github.com>
Message-ID: <vYUGd8D64j_kmzLGJ-4TWoSnT2td57TW2DYHoJxnSoM=.2ac06e89-180c-442e-be7b-385e860b88bb@github.com>

On Wed, 27 Nov 2024 10:50:45 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/utilities/growableArray.cpp line 79:
>> 
>>> 77: void GrowableArrayNestingCheck::on_arena_alloc(Arena* arena) const {
>>> 78:   if ((arena->get_tag() == Arena::Tag::tag_ra) && _nesting != static_cast<ResourceArea*>(arena)->nesting()) {
>>> 79:     fatal("allocation bug: GrowableArray is growing within nested ResourceMark");
>> 
>> Should it say "could grow"?
>
> It *is* growing since the check is done when allocating to accommodate more array elements. And the RM nesting is different now than when the array was created.

Should be a little more specific: [a new `_data` array is allocated](https://github.com/openjdk/jdk/blob/4b928167435bbf41dd00425c927da761751ca704/src/hotspot/share/utilities/growableArray.hpp#L526-L530) in the scope of a nested RM. Existing array elements are copied to the new `_data` array.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22269#discussion_r1868842375

From rrich at openjdk.org  Wed Dec  4 07:29:49 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 4 Dec 2024 07:29:49 GMT
Subject: Integrated: 8344609: Check ResourceMark nesting when allocating a
 GrowableArray on an alternative ResourceArea
In-Reply-To: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
References: <REbzTxa4QGp44-EP4QR15BYUxJC9XA46zBSImdRR1cE=.4cbe9f77-7a23-4b8e-8cd4-7d53d92bffdb@github.com>
Message-ID: <Fs4seuizj4e-d8_xZr5D3STkYBsQs4hL8M8VB7if8Uk=.1357d00d-02ae-44ea-8232-3b193cf92ec0@github.com>

On Wed, 20 Nov 2024 10:01:24 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> With this change the GrowableArray nesting check is also performed if allocating from an `Arena` which in fact is a `ResourceArea`.
> 
> The additional checking can help find issue as [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085).
> 
> The fix passed our nightly CI testing:
> Tier 1-4 of hotspot and jdk. All of langtools and jaxp. Renaissance Suite and SAP specific tests.
> Testing was done on the main platforms and also on Linux/PPC64le and AIX.
> 
> Besides ctw tests on ppc64 (see [JDK-8328085](https://bugs.openjdk.org/browse/JDK-8328085)) the check never failed.

This pull request has now been integrated.

Changeset: 4c33caa1
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c33caa185ccc2f406cf2e9c4c58c3cc0a1856f8
Stats:     18 lines in 2 files changed: 17 ins; 0 del; 1 mod

8344609: Check ResourceMark nesting when allocating a GrowableArray on an alternative ResourceArea

Reviewed-by: dholmes, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/22269

From henryjen at openjdk.org  Wed Dec  4 07:31:24 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 07:31:24 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Clean up adapting review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21964/files
  - new: https://git.openjdk.org/jdk/pull/21964/files/c07b4e4f..eeeb7181

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=02-03

  Stats: 12 lines in 4 files changed: 0 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21964/head:pull/21964

PR: https://git.openjdk.org/jdk/pull/21964

From rehn at openjdk.org  Wed Dec  4 07:56:44 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 4 Dec 2024 07:56:44 GMT
Subject: Integrated: 8345178: RISC-V: Add gtests for narrow cmpxchg
In-Reply-To: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
References: <EElNEIghgtFEae-hpgvBdsAdzljDVmkeJ5WEkaA8Ass=.d2613a41-4616-49a6-b212-fd32dcbb33ad@github.com>
Message-ID: <nENa5vv1F1ClOdt94Yzsb5-6wxvdaQafbBYqGa5aPPQ=.e9c08726-04a8-4226-b9b5-a103906972af@github.com>

On Thu, 28 Nov 2024 15:58:15 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> This adds tests of aligned narrow cmpxchg.
> 
> 
> Note: Google Test filter = *RiscV*
> [==========] Running 5 tests from 1 test suite.
> [----------] Global test environment set-up.
> [----------] 5 tests from RiscV
> ...
> [ RUN      ] RiscV.cmpxchg_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_lr_sc_vm (1 ms)
> [ RUN      ] RiscV.cmpxchg_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_maybe_zacas_vm (1 ms)
> [ RUN      ] RiscV.cmpxchg_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_maybe_zacas_vm (1 ms)
> [----------] 5 tests from RiscV (20831 ms total)
> 
> [----------] Global test environment tear-down
> [==========] 5 tests from 1 test suite ran. (20834 ms total)
> [  PASSED  ] 5 tests.
> 
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

This pull request has now been integrated.

Changeset: 9e2b66fb
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e2b66fb0f2b86d2c70b8ec5cce2eab123c7a9c1
Stats:     81 lines in 1 file changed: 81 ins; 0 del; 0 mod

8345178: RISC-V: Add gtests for narrow cmpxchg

Reviewed-by: fyang, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22445

From rehn at openjdk.org  Wed Dec  4 08:21:24 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 4 Dec 2024 08:21:24 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v6]
In-Reply-To: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
Message-ID: <RL5YV0V_cVwUBLY3AKVMDxgZhT2FCRz5fj_-UMUqvJg=.c230e467-5453-468c-b1f2-a1df5c057fce@github.com>

> Hi, please consider.
> 
> This adds tests of aligned weak narrow cmpxchg.
> 
> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20997 ms total)
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into weak_narrow
 - Fixed WS
 - Review comment
 - Added weak 4/8 byte cmpxchg
 - Merge branch 'master' into weak_narrow
 - gtest weak narrow cmpxchg

-------------

Changes: https://git.openjdk.org/jdk/pull/22476/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22476&range=05
  Stats: 129 lines in 1 file changed: 129 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22476/head:pull/22476

PR: https://git.openjdk.org/jdk/pull/22476

From rehn at openjdk.org  Wed Dec  4 08:21:24 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 4 Dec 2024 08:21:24 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v5]
In-Reply-To: <pKown4EA98PnnOJhFa_I9ux66U-YNOar2t5TBYCtygk=.4f2000c9-a254-41fe-8944-6814072d3353@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <2JKi_Goke42hWmNW04ioGKBy0_Sj2qycjbyt83tEu54=.04ac83b2-9f8f-414f-bb89-18c0ea4f915d@github.com>
 <pKown4EA98PnnOJhFa_I9ux66U-YNOar2t5TBYCtygk=.4f2000c9-a254-41fe-8944-6814072d3353@github.com>
Message-ID: <WDedzWA9Cx5989cHWqWoa-hID6ZA7vD3mK_ytaAxxiw=.97f02364-248b-44ad-a63b-b554eec6618c@github.com>

On Tue, 3 Dec 2024 09:58:43 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed WS
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 327:
> 
>> 325: }
>> 326: 
>> 327: TEST_VM(RiscV, cmpxchg_weak_int16_lr_sc) {
> 
> I'm not familiar with the gtest syntax in JDK, seems this (`cmpxchg_weak_int16_lr_sc`) is just a name?
> But it still good to follow the name convenction, i.e. weak_cmpxchg.

fixed in merge

> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 366:
> 
>> 364: }
>> 365: 
>> 366: TEST_VM(RiscV, cmpxchg_weak_int64_lr_sc) {
> 
> similar comment here, and below

fixed in merge

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1868929836
PR Review Comment: https://git.openjdk.org/jdk/pull/22476#discussion_r1868930071

From lucy at openjdk.org  Wed Dec  4 08:22:40 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 4 Dec 2024 08:22:40 GMT
Subject: RFR: 8335367: [s390] Add support for load immediate on condition
 instructions. [v3]
In-Reply-To: <1-wsaZp9KA0i0Vgvft2lMWPQVnKXvDuM90VSDrYZl4A=.800872c6-5ec4-4a17-97e1-e55514e3b8a3@github.com>
References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com>
 <1-wsaZp9KA0i0Vgvft2lMWPQVnKXvDuM90VSDrYZl4A=.800872c6-5ec4-4a17-97e1-e55514e3b8a3@github.com>
Message-ID: <iqzG1U62b673AN0zBBalMtGrvOMKcyRcZNkvKqRVgjk=.a768ab5a-05ef-402d-80fd-91a967629f54@github.com>

On Mon, 2 Dec 2024 04:55:15 GMT, Manjunath S Matti. <duke at openjdk.org> wrote:

>> Add support for load immediate on condition instructions.
>
> Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments from Lutz.

LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22058#pullrequestreview-2477633164

From mli at openjdk.org  Wed Dec  4 09:16:41 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 4 Dec 2024 09:16:41 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v6]
In-Reply-To: <RL5YV0V_cVwUBLY3AKVMDxgZhT2FCRz5fj_-UMUqvJg=.c230e467-5453-468c-b1f2-a1df5c057fce@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <RL5YV0V_cVwUBLY3AKVMDxgZhT2FCRz5fj_-UMUqvJg=.c230e467-5453-468c-b1f2-a1df5c057fce@github.com>
Message-ID: <mNmrUy1b8DXo2NJrdcIENaFj21FxgmDZK58RjNg_DGo=.3d7afc7a-2b50-4bdc-9652-1eee7db2aa38@github.com>

On Wed, 4 Dec 2024 08:21:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned weak narrow cmpxchg.
>> 
>> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20997 ms total)
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into weak_narrow
>  - Fixed WS
>  - Review comment
>  - Added weak 4/8 byte cmpxchg
>  - Merge branch 'master' into weak_narrow
>  - gtest weak narrow cmpxchg

Thanks for updating, looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22476#pullrequestreview-2477792469

From fbredberg at openjdk.org  Wed Dec  4 09:25:52 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 4 Dec 2024 09:25:52 GMT
Subject: RFR: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for
 recursive Java monitor stress testing [v4]
In-Reply-To: <uQ6iKtHsGph3n5GsFGuSGZPKn9xWxaFa06qIG8quHIg=.df468af0-3713-4d96-8cee-068add00a0a7@github.com>
References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com>
 <uQ6iKtHsGph3n5GsFGuSGZPKn9xWxaFa06qIG8quHIg=.df468af0-3713-4d96-8cee-068add00a0a7@github.com>
Message-ID: <uAuVSLrTHZ8bWjsxbKgPidQrK_HGz7yLAD9Qs9J1VHA=.8378c70f-5064-41a5-a825-32b85c58ed9d@github.com>

On Wed, 20 Nov 2024 18:53:37 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it.
>> 
>> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR.
>> 
>> Tests run without failures on supported platforms.
>
> Fredrik Bredberg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update two after review

Thanks everyone for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22238#issuecomment-2516663902

From fbredberg at openjdk.org  Wed Dec  4 09:35:49 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 4 Dec 2024 09:35:49 GMT
Subject: Integrated: 8329351: Add runtime/Monitor/TestRecursiveLocking.java for
 recursive Java monitor stress testing
In-Reply-To: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com>
References: <0NTaW3-5mUDKYnAwHhL7liYSShEE01lguO1v5DEcFoY=.25532d78-5f9e-46db-9aea-a75b0a8dae6d@github.com>
Message-ID: <AwKEiB7vbW5XA9EELaId1HPAZoMy8B987auoPDj-YfM=.4fdd52e1-97e5-49f1-90fc-0920c4886c67@github.com>

On Tue, 19 Nov 2024 13:09:22 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

> @dcubed-ojdk is too busy, so I was asked to take over [https://github.com/openjdk/jdk/pull/18664](https://github.com/openjdk/jdk/pull/18664) and finish it.
> 
> That old PR contains all the details and also got some review comments, which I have tried to address in this new PR.
> 
> Tests run without failures on supported platforms.

This pull request has now been integrated.

Changeset: 994504c3
Author:    Fredrik Bredberg <fbredberg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/994504c3e1440401a22ad3bdb30413f9db8a7780
Stats:     778 lines in 3 files changed: 778 ins; 0 del; 0 mod

8329351: Add runtime/Monitor/TestRecursiveLocking.java for recursive Java monitor stress testing

Co-authored-by: Daniel D. Daugherty <dcubed at openjdk.org>
Reviewed-by: dcubed, coleenp, aboldtch

-------------

PR: https://git.openjdk.org/jdk/pull/22238

From aph at openjdk.org  Wed Dec  4 10:19:42 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 4 Dec 2024 10:19:42 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
Message-ID: <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>

On Tue, 3 Dec 2024 10:27:48 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> src/hotspot/share/utilities/rbTree.hpp line 1:
>> 
>>> 1: /*
>> 
>> Just a drive-by comment but why is this all in the hpp file instead of being split into hpp (and maybe .inline.hpp) and cpp files?
>
> The entire tree is templated, so we can't easily move the implementation to a cpp file

You can, by using explicit template instantiation. That would be an improvement over putting it all in the header file, IMHO.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1869140217

From fyang at openjdk.org  Wed Dec  4 10:36:39 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 4 Dec 2024 10:36:39 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v6]
In-Reply-To: <RL5YV0V_cVwUBLY3AKVMDxgZhT2FCRz5fj_-UMUqvJg=.c230e467-5453-468c-b1f2-a1df5c057fce@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <RL5YV0V_cVwUBLY3AKVMDxgZhT2FCRz5fj_-UMUqvJg=.c230e467-5453-468c-b1f2-a1df5c057fce@github.com>
Message-ID: <CWgNw-Jexvlq5eQLJYOIQclvbAsU-VbeJFoCLwMjkgE=.30b1581a-e0e4-430f-a38e-dc46d4a2e501@github.com>

On Wed, 4 Dec 2024 08:21:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned weak narrow cmpxchg.
>> 
>> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20997 ms total)
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into weak_narrow
>  - Fixed WS
>  - Review comment
>  - Added weak 4/8 byte cmpxchg
>  - Merge branch 'master' into weak_narrow
>  - gtest weak narrow cmpxchg

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22476#pullrequestreview-2478047532

From jsjolen at openjdk.org  Wed Dec  4 11:58:39 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 4 Dec 2024 11:58:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
Message-ID: <gKlnBcLyIA-wrX_RcGzBUDyEWbfx13eVjGjgN0xR_VI=.ac445b67-1ab8-4740-b0d4-1e25c6854d7e@github.com>

On Wed, 4 Dec 2024 10:16:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The entire tree is templated, so we can't easily move the implementation to a cpp file
>
> You can, by using explicit template instantiation. That would be an improvement over putting it all in the header file, IMHO.

I'm a bit surprised that it's contentious to have the whole tree in the header file when we do the same with other templated types such as `GrowableArray`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1869344185

From cnorrbin at openjdk.org  Wed Dec  4 12:07:38 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 4 Dec 2024 12:07:38 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
Message-ID: <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>

On Wed, 4 Dec 2024 10:16:55 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The entire tree is templated, so we can't easily move the implementation to a cpp file
>
> You can, by using explicit template instantiation. That would be an improvement over putting it all in the header file, IMHO.

@theRealAph I don't think that would be possible either. We can't possibly know every type combination to instantiate, especially since we're asking users to provide their own comparator and allocator through the template.

And like Johan said, we already have templated header-only structures, like `GrowableArray` and `ConcurrentHashTable`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1869362633

From aph at openjdk.org  Wed Dec  4 12:16:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 4 Dec 2024 12:16:38 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
Message-ID: <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>

On Wed, 4 Dec 2024 12:05:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> You can, by using explicit template instantiation. That would be an improvement over putting it all in the header file, IMHO.
>
> @theRealAph I don't think that would be possible either. We can't possibly know every type combination to instantiate, especially since we're asking users to provide their own comparator and allocator through the template.
> 
> And like Johan said, we already have templated header-only structures, like `GrowableArray` and `ConcurrentHashTable`.

Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1869381759

From aph at openjdk.org  Wed Dec  4 12:23:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 4 Dec 2024 12:23:39 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
Message-ID: <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>

On Wed, 4 Dec 2024 12:13:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> @theRealAph I don't think that would be possible either. We can't possibly know every type combination to instantiate, especially since we're asking users to provide their own comparator and allocator through the template.
>> 
>> And like Johan said, we already have templated header-only structures, like `GrowableArray` and `ConcurrentHashTable`.
>
> Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.

I think the case for making the whole thing in a header depends on how much code there is, that's all.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1869392940

From kim.barrett at oracle.com  Wed Dec  4 12:42:15 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Wed, 4 Dec 2024 07:42:15 -0500
Subject: Poisoning in HotSpot
In-Reply-To: <337d3e32-57c0-45b7-81bb-6ce6f8174ad2@oracle.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
 <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
 <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>
 <e6474fe1-8f0d-494f-b06b-31d816f26c86@oracle.com>
 <bbc1d875-0a34-4789-b96b-e5fe14cc6b6a@oracle.com>
 <337d3e32-57c0-45b7-81bb-6ce6f8174ad2@oracle.com>
Message-ID: <048a76f8-38b5-454e-b427-5bdadeae702d@oracle.com>

On 12/1/24 7:09 PM, David Holmes wrote:
> On 2/12/2024 2:13 am, Kim Barrett wrote:
>> Unfortunately, there's a potentially fatal problem with this whole 
>> approach.
>> We don't have a mechanism for turning it off over some context. We 
>> need this
>> because there are files that ere not ours that are subject to our 
>> headers.
>> Consider gtest, for example. Apparently there are *lots* of calls to 
>> sprintf,
>> for example.
>>
>> I've not yet come up with a way for this new mechanism to deal with 
>> that.
>
> Somewhat crude but couldn't gtests #define USING_GTEST before 
> including our headers and then we could make the forbidden stuff 
> conditional on ifndef USING_GTEST. ?? 

Things are more complicated than that, unfortunately.

I think I might have a way forward, in part using that kind of thing.? 
But it might interfere with other future work.



From amitkumar at openjdk.org  Wed Dec  4 12:46:41 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 4 Dec 2024 12:46:41 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v4]
In-Reply-To: <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
 <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
Message-ID: <1M6P2xZhpkOb75DJMyFScehvWV8Kf1YvDz5hPbqo5Ks=.c9913ab0-c06e-44b7-a8f1-8c55bfc78e51@github.com>

On Wed, 4 Dec 2024 05:22:17 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
>> 
>> 
>> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>> 
>> 
>> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
>> 
>> This is the output with current changes: 
>> 
>> 
>> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move mask to correction location

@RealLucy ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22508#issuecomment-2517247261

From kbarrett at openjdk.org  Wed Dec  4 13:05:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 4 Dec 2024 13:05:37 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code
In-Reply-To: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
Message-ID: <E-gzafwASr2UGNpQR6Zh0fKNFzqPzPnjCprQ2hZ-OfI=.6ebfafc9-c67c-4666-9ead-72c31c1a6244@github.com>

On Sun, 1 Dec 2024 16:23:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in s390 code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

> hi @kimbarrett,
> 
> I tried to build it on s390x with these changes:
> 
> ```diff
> diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
> index 57654514eb6..ce3077e7d38 100644
> --- a/make/autoconf/flags-cflags.m4
> +++ b/make/autoconf/flags-cflags.m4
> ```
[snip]
> is that correct way to test it ?

That's too general, affecting the entire JDK. The rule we're trying to enforce
(don't use literal 0 as a null pointer constant) is specific to HotSpot.

For testing, I've been adding the warning to the list here:

https://github.com/openjdk/jdk/blob/e13206d3a16a67a604076faecded88cbed85db1a/make/autoconf/flags-cflags.m4#L785

I've not verified with the build team that this is the right place ultimately.
And I suspect it's not, since your log listed warnings in adlc. I'm not seeing
any warnings there, even though (looking at the code) there clearly should be.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22469#issuecomment-2517290216

From fyang at openjdk.org  Wed Dec  4 13:23:46 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 4 Dec 2024 13:23:46 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
Message-ID: <pWkuwsIlU7h68gOXI4KqCf_2rY3vXiZsXqhvk6YZ88E=.475e759e-c201-4f13-8850-55a303e5702c@github.com>

On Mon, 2 Dec 2024 16:18:07 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   increase compiler stub space for macos x86_64

FYI: I have performed hs:tier1-hs:tier4 tests on linux-riscv64. No regression witnessed with this change on this platform.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2517331824

From coleenp at openjdk.org  Wed Dec  4 13:30:41 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Dec 2024 13:30:41 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
 <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
Message-ID: <dZiNe6a2ntA89b2Cl-zsGcp5UqwrZkQhCdYKvjVm80Q=.089cdc88-4f41-4f44-95e0-3a4f32c2f72c@github.com>

On Wed, 4 Dec 2024 12:21:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Yes of course we can. Users add their own instantiations as required. I'm not saying you must do this, but I am saying it's not hard.
>
> I think the case for making the whole thing in a header depends on how much code there is, that's all.

concurrentHashTable uses the trick of inlining a lot of methods in concurrentHashTable.inline.hpp and concurrentHashTableTasks.inline.hpp that are included in the .cpp callers.  This might work for this also.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1869496735

From coleenp at openjdk.org  Wed Dec  4 13:47:40 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Dec 2024 13:47:40 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v8]
In-Reply-To: <TnhBB2r0-UYb5FzA-2hPCNTaFZ6X9EMitYjA-b5M3Yo=.946e0ede-847f-4171-8584-ebe23ccdb65b@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <TnhBB2r0-UYb5FzA-2hPCNTaFZ6X9EMitYjA-b5M3Yo=.946e0ede-847f-4171-8584-ebe23ccdb65b@github.com>
Message-ID: <95XxXY5ksBesYh4h-SOOr6zLJWjwqUeTRQWhHHka8tM=.2487c46f-ce5a-4424-929c-567c78f530ea@github.com>

On Tue, 3 Dec 2024 23:16:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Only calculate klass-decode-mode in one place.

see https://bugs.openjdk.org/browse/JDK-8340212?focusedId=14727916&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14727916

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2517443771

From lucy at openjdk.org  Wed Dec  4 13:51:42 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Wed, 4 Dec 2024 13:51:42 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v4]
In-Reply-To: <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
 <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
Message-ID: <kw_pDZN9RwBTEqHlx04aR5D9BqHi4MPY7Lyf3MuO_cQ=.091f1c46-030c-4724-818c-871cb83b6bf9@github.com>

On Wed, 4 Dec 2024 05:22:17 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
>> 
>> 
>> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>> 
>> 
>> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
>> 
>> This is the output with current changes: 
>> 
>> 
>> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move mask to correction location

LGTM.
It's good to have new H/W detected correctly.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22508#pullrequestreview-2478706260

From egahlin at openjdk.org  Wed Dec  4 14:46:43 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 4 Dec 2024 14:46:43 GMT
Subject: RFR: 8340969: jdk/jfr/startupargs/TestStartDuration.java should be
 marked as flagless
In-Reply-To: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
References: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
Message-ID: <RXTf00_Pw_5kLW0BKmLpzNyPGXlN-Ai-J-aUHThkchI=.2abe93ee-bf9f-40b5-8e66-4298dbd8dc05@github.com>

On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test jdk/jfr/startupargs/TestStartDuration.java
> checks duration, the time might be too small for stress options like Xcomp.
> So it makes sense to mark it as flaglesss.

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21237#pullrequestreview-2478912826

From pchilanomate at openjdk.org  Wed Dec  4 15:47:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 15:47:26 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Fix parameter name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22524/files
  - new: https://git.openjdk.org/jdk/pull/22524/files/108abc2b..8cfc9a10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22524&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22524&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22524/head:pull/22524

PR: https://git.openjdk.org/jdk/pull/22524

From pchilanomate at openjdk.org  Wed Dec  4 15:47:26 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 15:47:26 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <K5QJS8g6pvQ7Kf2_-Bl2FAyKWFtQBhcxG6cyalDif6w=.022e4ddf-5e79-4b16-a931-959c4fff5b7f@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
 <K5QJS8g6pvQ7Kf2_-Bl2FAyKWFtQBhcxG6cyalDif6w=.022e4ddf-5e79-4b16-a931-959c4fff5b7f@github.com>
Message-ID: <-c_LKYc0sEMbVtxPOCYWt8Fv2L-XoBfY9kmyDbNbhfg=.7b9bf7cf-1f46-471e-b184-5253add1f846@github.com>

On Wed, 4 Dec 2024 01:36:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix parameter name
>
> src/hotspot/share/runtime/javaThread.hpp line 174:
> 
>> 172:   void set_monitor_owner_id(int64_t val) {
>> 173:     assert(val >= ThreadIdentifier::initial() && val < ThreadIdentifier::current(), "");
>> 174:     _monitor_owner_id = val;
> 
> Nit: Using `id`  rather than `val` would be more consistent with other changes (`ObjectMonitor::owner_id_from`)

Fixed.

> src/hotspot/share/runtime/threads.cpp line 1363:
> 
>> 1361:         p->print_stack_on(st);
>> 1362:         if (p->is_vthread_mounted()) {
>> 1363:           st->print_cr("   Mounted virtual thread #" INT64_FORMAT, java_lang_Thread::thread_id(p->vthread()));
> 
> Was initially unsure why `p->lock_id()` didn't change to `p->monitor_owner_id()`, but here you want the thread-id not something that happens to match the thread-id.

Exactly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1869818716
PR Review Comment: https://git.openjdk.org/jdk/pull/22524#discussion_r1869819018

From mdoerr at openjdk.org  Wed Dec  4 16:08:45 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Dec 2024 16:08:45 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
Message-ID: <gZQWNQgWsEbnwCUHwzRoBVDSw49TfuTC1Ex2qRQKL4Y=.706d1968-c7a3-44c0-b20c-b9b2ade86131@github.com>

On Mon, 2 Dec 2024 16:18:07 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   increase compiler stub space for macos x86_64

GHA shows "guarantee(sect->end() <= tend) failed: sanity" on macOS-x64. Is that related?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2517882274

From aph at openjdk.org  Wed Dec  4 16:52:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 4 Dec 2024 16:52:40 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v4]
In-Reply-To: <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
 <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
Message-ID: <l4RHXPGWgPkgXyCKEzuLbF-qkiCiWUziY_NOmD1ZGqo=.4f131a23-5fbe-431a-88a6-52dd1b02b5f9@github.com>

On Wed, 4 Dec 2024 05:22:17 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
>> 
>> 
>> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>> 
>> 
>> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
>> 
>> This is the output with current changes: 
>> 
>> 
>> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move mask to correction location

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22508#pullrequestreview-2479334445

From luhenry at openjdk.org  Wed Dec  4 17:21:40 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Wed, 4 Dec 2024 17:21:40 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <qP08LLafMYHEMx7eYGizr6fstu7VVFRTRCXzhV-VAkA=.c9712fee-9a08-4b0c-97ad-54476eea55ee@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <q5_Z08p9Ynt4Q7JOv6sNMXWwgXgiLlpRkit3b6og4OY=.f9690ecb-18f1-4bc9-971c-68cf008c8e6b@github.com>
 <vUbG4lGMFrhXaN0k59XIOByNTXeK1Fwp74-Z9eKe9nM=.e902ee8f-3fcc-44ea-95d3-d101bc5eb048@github.com>
 <qP08LLafMYHEMx7eYGizr6fstu7VVFRTRCXzhV-VAkA=.c9712fee-9a08-4b0c-97ad-54476eea55ee@github.com>
Message-ID: <VUZFKfgNfW1Rz9Q8_3p3fl40EZ9ksNhNCzTUaeozLDI=.c0cd37ac-76e0-42f8-866a-db0883174e23@github.com>

On Tue, 3 Dec 2024 13:48:49 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Make sense to me, I'll fix it later.
>
> If we do it as you suggested, we could either add new api in shared class `StubRoutines` or we add and use something like StubRoutines::riscv::vclmul_crc_table() directly, but seems either ways are not good enough, and I see other platforms are using the similar pattern as the current patch.
> So maybe we should keep it as it is now?

Sounds good, let's keep it as-is since other platforms do it this way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1869977352

From mchung at openjdk.org  Wed Dec  4 18:06:44 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Dec 2024 18:06:44 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
Message-ID: <2sW2VYXiihycsImrZiHDWuLcB3iZeSBhTE_iqx9UmfA=.8adbe1f5-d2f7-4d7e-a702-064fa501cc98@github.com>

On Wed, 4 Dec 2024 07:31:24 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up adapting review comments

make/autoconf/spec.gmk.template line 276:

> 274: 
> 275: ifneq ($(COMPANY_NAME), )
> 276:   VERSION_CFLAGS += -DVENDOR='"$(COMPANY_NAME)"'

With this change, it will also fix the value of `java.vm.vendor` system property to "N/A" instead of "Oracle Corporation" hardcoded in the source.   The CSR  can mention this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870038850

From henryjen at openjdk.org  Wed Dec  4 18:26:41 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 18:26:41 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <2sW2VYXiihycsImrZiHDWuLcB3iZeSBhTE_iqx9UmfA=.8adbe1f5-d2f7-4d7e-a702-064fa501cc98@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
 <2sW2VYXiihycsImrZiHDWuLcB3iZeSBhTE_iqx9UmfA=.8adbe1f5-d2f7-4d7e-a702-064fa501cc98@github.com>
Message-ID: <CB1lOyE7guI_LvACY1saSlUTrcz4ikiwUKupKF-mQTQ=.c5922577-101f-4aa1-a30f-57265be67b37@github.com>

On Wed, 4 Dec 2024 18:03:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up adapting review comments
>
> make/autoconf/spec.gmk.template line 276:
> 
>> 274: 
>> 275: ifneq ($(COMPANY_NAME), )
>> 276:   VERSION_CFLAGS += -DVENDOR='"$(COMPANY_NAME)"'
> 
> With this change, it will also fix the value of `java.vm.vendor` system property to "N/A" instead of "Oracle Corporation" hardcoded in the source.   The CSR  can mention this change.

That's for OpenJDK build with default branding.conf though. Build with proper branding.conf setup or configured using --with-vendor-name won't be affected.
In fact, IIUC, `--with-vendor-name='N/A'` won't work either.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870067820

From mchung at openjdk.org  Wed Dec  4 18:26:42 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Dec 2024 18:26:42 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
Message-ID: <UXHjcHrhRdvQjyzuR0SpNRjV7l_jHRXDT01ppfT3UUY=.014e23f0-db66-4d0a-8e79-6bd5929c19b2@github.com>

On Wed, 4 Dec 2024 07:31:24 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up adapting review comments

src/java.base/share/classes/java/lang/VersionProps.java.template line 128:

> 126: 
> 127:         // In case VM is not yet set this property
> 128:         props.putIfAbsent("java.vm.vendor", VENDOR_VM);

Can this system property just be set here for simplicity?  The value of  `java.vendor` and `java.vm.vendor` system property are the same.

The VM does not need this value until VM initialization completes.  It's only needed by StatSampler (jstat).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870070455

From mchung at openjdk.org  Wed Dec  4 18:30:42 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Dec 2024 18:30:42 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <UXHjcHrhRdvQjyzuR0SpNRjV7l_jHRXDT01ppfT3UUY=.014e23f0-db66-4d0a-8e79-6bd5929c19b2@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
 <UXHjcHrhRdvQjyzuR0SpNRjV7l_jHRXDT01ppfT3UUY=.014e23f0-db66-4d0a-8e79-6bd5929c19b2@github.com>
Message-ID: <zkzrtb6AJV37-MHV4g7DdmCOLO1uENNNY4naiSuoLxo=.05283c46-c5de-40fb-8191-bc31cb42342d@github.com>

On Wed, 4 Dec 2024 18:24:26 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clean up adapting review comments
>
> src/java.base/share/classes/java/lang/VersionProps.java.template line 128:
> 
>> 126: 
>> 127:         // In case VM is not yet set this property
>> 128:         props.putIfAbsent("java.vm.vendor", VENDOR_VM);
> 
> Can this system property just be set here for simplicity?  The value of  `java.vendor` and `java.vm.vendor` system property are the same.
> 
> The VM does not need this value until VM initialization completes.  It's only needed by StatSampler (jstat).

In fact, VM no longer sets this property.   This should be updated to simply do `props.put`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870075224

From mchung at openjdk.org  Wed Dec  4 18:44:41 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Dec 2024 18:44:41 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
Message-ID: <todjb_3q9JjfCx_CXUDhIUW5PhbkDFEbzCCxNuayHd0=.bf609a45-ebcc-4ba7-869a-7370702f6c32@github.com>

On Wed, 4 Dec 2024 07:31:24 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up adapting review comments

src/hotspot/share/runtime/threads.cpp line 401:

> 399:     JDK_Version::set_runtime_vendor_vm_bug_url(get_java_version_info(ik, vmSymbols::java_runtime_vendor_vm_bug_url_name()));
> 400: 
> 401:     VM_Version::set_vm_vendor(get_java_version_info(ik, vmSymbols::java_runtime_vendor_vm_name()));

Nit: not sure what naming convention should follow as VM_Version and JDK_Version no longer contain version info only.  

`vm_vendor` and `runtime_vendor_vm_bug_url` should be together.    Perhaps `JDK_Version` should be renamed to reflect that they are fields in `VersionProps` class and so `VM_Version::vm_vendor` can be moved/renamed to `JDK_Version::runtime_vendor_vm`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870098185

From coleenp at openjdk.org  Wed Dec  4 18:44:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Dec 2024 18:44:55 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v9]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <T4RxnXT-3OkAf_areEU3od_XqdTEVzhR9XyB0GADLGo=.67ef7d88-3797-484f-a32f-82a60e885a90@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Recalculate decode mode if OS picks a different encoding.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21695/files
  - new: https://git.openjdk.org/jdk/pull/21695/files/16cdc5b0..5c660b01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=07-08

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From mli at openjdk.org  Wed Dec  4 19:00:56 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 4 Dec 2024 19:00:56 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <VUZFKfgNfW1Rz9Q8_3p3fl40EZ9ksNhNCzTUaeozLDI=.c0cd37ac-76e0-42f8-866a-db0883174e23@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <q5_Z08p9Ynt4Q7JOv6sNMXWwgXgiLlpRkit3b6og4OY=.f9690ecb-18f1-4bc9-971c-68cf008c8e6b@github.com>
 <vUbG4lGMFrhXaN0k59XIOByNTXeK1Fwp74-Z9eKe9nM=.e902ee8f-3fcc-44ea-95d3-d101bc5eb048@github.com>
 <qP08LLafMYHEMx7eYGizr6fstu7VVFRTRCXzhV-VAkA=.c9712fee-9a08-4b0c-97ad-54476eea55ee@github.com>
 <VUZFKfgNfW1Rz9Q8_3p3fl40EZ9ksNhNCzTUaeozLDI=.c0cd37ac-76e0-42f8-866a-db0883174e23@github.com>
Message-ID: <gBafeBW0DzDTxNnX9ANTk5saIZ-i1BGWJwo1AXPBYC0=.dbfb5c03-9159-4b41-8ca8-595629ce4a18@github.com>

On Wed, 4 Dec 2024 17:18:56 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> If we do it as you suggested, we could either add new api in shared class `StubRoutines` or we add and use something like StubRoutines::riscv::vclmul_crc_table() directly, but seems either ways are not good enough, and I see other platforms are using the similar pattern as the current patch.
>> So maybe we should keep it as it is now?
>
> Sounds good, let's keep it as-is since other platforms do it this way.

Thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1870118223

From mchung at openjdk.org  Wed Dec  4 19:04:42 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Dec 2024 19:04:42 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
Message-ID: <F0F9oFpNcZC1zG8I1sOxb29Rx2Buq_PusC2J6roXcIU=.b2ea9ff7-e608-45c6-a929-8e1fd439d055@github.com>

On Wed, 4 Dec 2024 07:31:24 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up adapting review comments

src/hotspot/share/runtime/abstract_vm_version.cpp line 132:

> 130: 
> 131: static const char vm_vendor_string[sizeof(VENDOR) < VENDOR_PADDING ? VENDOR_PADDING : sizeof(VENDOR)] = VENDOR;
> 132: const char* Abstract_VM_Version::_vm_vendor = vm_vendor_string;

As the system property is no longer set by VM, it can be initialized to null and this field should only be read after initPhase1.  The implementation would be much simplified.

src/java.base/share/classes/java/lang/VersionProps.java.template line 99:

> 97:     private static String VENDOR_VM =
> 98:         "@@VENDOR@@";
> 99: 

suggest to move after `VENDOR`.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/VendorVMPlugin.java line 30:

> 28: /**
> 29:  * Plugin to set the vendor, by redefining the static field
> 30:  * java.lang.VersionProps.VENDOR

Suggestion:

 * Plugin to set the vendor for the VM, by redefining the static field
 * java.lang.VersionProps.VENDOR_VM

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 226:

> 224: vendor-url.description=\
> 225: Override the vendor bug URL baked into the build.  The value\n\
> 226: of the system property "java.vendor.url" will be <vendor-url>.

Suggestion:

Override the vendor URL baked into the build.  The value\n\
of the system property "java.vendor.url" will be <vendor-url>.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 226:

> 224: vendor-url.description=\
> 225: Override the vendor bug URL baked into the build.  The value\n\
> 226: of the system property "java.vendor.url" will be <vendor-url>.

Suggestion:

Override the vendor URL baked into the build.  The value\n\
of the system property "java.vendor.url" will be <vendor-url>.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 230:

> 228: vendor-url.usage=\
> 229: \  --vendor-url <vendor-url>\n\
> 230: \                            Override the vendor bug URL baked into the build.\n\

Suggestion:

\                            Override the vendor URL baked into the build.\n\

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870107669
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870109361
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870110428
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870121641
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870123384
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870123680

From henryjen at openjdk.org  Wed Dec  4 19:04:48 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 4 Dec 2024 19:04:48 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <zkzrtb6AJV37-MHV4g7DdmCOLO1uENNNY4naiSuoLxo=.05283c46-c5de-40fb-8191-bc31cb42342d@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
 <UXHjcHrhRdvQjyzuR0SpNRjV7l_jHRXDT01ppfT3UUY=.014e23f0-db66-4d0a-8e79-6bd5929c19b2@github.com>
 <zkzrtb6AJV37-MHV4g7DdmCOLO1uENNNY4naiSuoLxo=.05283c46-c5de-40fb-8191-bc31cb42342d@github.com>
Message-ID: <4gVNdCGBsGD8TKr4SpT2crkvnSumgB_1AYu7OaBUwuM=.7baa744d-1cf8-4a78-a75d-2d755ec3a2fd@github.com>

On Wed, 4 Dec 2024 18:27:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VersionProps.java.template line 128:
>> 
>>> 126: 
>>> 127:         // In case VM is not yet set this property
>>> 128:         props.putIfAbsent("java.vm.vendor", VENDOR_VM);
>> 
>> Can this system property just be set here for simplicity?  The value of  `java.vendor` and `java.vm.vendor` system property are the same.
>> 
>> The VM does not need this value until VM initialization completes.  It's only needed by StatSampler (jstat).
>
> In fact, VM no longer sets this property.   This should be updated to simply do `props.put`.

It is just for compatibility with other VM implementation. We don't set the property in hotspot with this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870123819

From mchung at openjdk.org  Wed Dec  4 19:07:20 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Dec 2024 19:07:20 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
Message-ID: <DSM4mqvnczfjVY8bPDIcfV40AMpJzQ7adx1KhvjQwys=.8efdb99a-50fc-47c6-8d1b-96c5b994f413@github.com>

On Wed, 4 Dec 2024 07:31:24 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clean up adapting review comments

The copyright headers need to be updated.  `@bug` in VendorInfoPluginsTest.java should also be updated.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21964#pullrequestreview-2479666243

From coleenp at openjdk.org  Wed Dec  4 19:08:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 4 Dec 2024 19:08:13 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
 <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
Message-ID: <NGQLIbLf5E5mAhtLmis1zVrAXOstJ74vpNu7eS1ygpE=.3f99064a-1914-4be8-8676-5bbba13b8fec@github.com>

On Wed, 4 Dec 2024 15:47:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix parameter name

Update looks good!

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22524#pullrequestreview-2479668829

From ecaspole at openjdk.org  Wed Dec  4 19:13:59 2024
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 4 Dec 2024 19:13:59 GMT
Subject: RFR: 8345405: Add JMH showing the regression in 8341649
Message-ID: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>

This JMH using MethodHandles shows the regression in 8341649, for example comparing 24-b15, which included the regression to today's head. It was an interaction between the runtime and C2 rather than a change in MethodHandles.

Here are example results from an Ampere platform:
jdk-24-b25 before the fix:
Benchmark                (classes)  (instances)   Mode  Cnt   Score   Error   Units
MethodHandleStress.work       1000          100  thrpt   20  33.423 ? 7.678  ops/ms

Today's head with the fix:
Benchmark                (classes)  (instances)   Mode  Cnt    Score    Error   Units
MethodHandleStress.work       1000          100  thrpt   20  709.249 ? 50.575  ops/ms

-------------

Commit messages:
 - 8345405: Add JMH showing the regression in 8341649

Changes: https://git.openjdk.org/jdk/pull/22556/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345405
  Stats: 224 lines in 1 file changed: 224 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22556/head:pull/22556

PR: https://git.openjdk.org/jdk/pull/22556

From mchung at openjdk.org  Wed Dec  4 19:32:39 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Dec 2024 19:32:39 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v4]
In-Reply-To: <4gVNdCGBsGD8TKr4SpT2crkvnSumgB_1AYu7OaBUwuM=.7baa744d-1cf8-4a78-a75d-2d755ec3a2fd@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <4WHLghPV-r5KoSMHTtB4m1sT9KC-GhZbIqJG5SbGhBg=.8c5fa90e-17ae-4994-aad9-d602a844f1c9@github.com>
 <UXHjcHrhRdvQjyzuR0SpNRjV7l_jHRXDT01ppfT3UUY=.014e23f0-db66-4d0a-8e79-6bd5929c19b2@github.com>
 <zkzrtb6AJV37-MHV4g7DdmCOLO1uENNNY4naiSuoLxo=.05283c46-c5de-40fb-8191-bc31cb42342d@github.com>
 <4gVNdCGBsGD8TKr4SpT2crkvnSumgB_1AYu7OaBUwuM=.7baa744d-1cf8-4a78-a75d-2d755ec3a2fd@github.com>
Message-ID: <RzbsGtU7ZSsZf_Y5sZtNTLpUMgC1EJZQ8_ukpUt7yM8=.0931ef89-ace0-439f-9d97-cfe86cfc369e@github.com>

On Wed, 4 Dec 2024 19:00:33 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> In fact, VM no longer sets this property.   This should be updated to simply do `props.put`.
>
> It is just for compatibility with other VM implementation. We don't set the property in hotspot with this PR.

Is it part of the implementation specification?   If not, I would expect other VM implementations should be updated for this release.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1870168736

From iklam at openjdk.org  Wed Dec  4 19:38:58 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 4 Dec 2024 19:38:58 GMT
Subject: RFR: 8345224: Test
 runtime/cds/appcds/applications/JavacBench.java#dynamic fails after
 JDK-8344822
Message-ID: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>

The `hotspot_runtime_non_cds_mode` test group is for running jtreg tests with `-vmoptions:-Xshare:off`. Such a scenario doesn't make sense for the CDS tests, and could cause similar failures in the future.

We should remove all CDS tests from `hotspot_runtime_non_cds_mode`

-------------

Commit messages:
 - 8345224: Test runtime/cds/appcds/applications/JavacBench.java#dynamic fails after JDK-8344822

Changes: https://git.openjdk.org/jdk/pull/22558/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22558&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345224
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22558.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22558/head:pull/22558

PR: https://git.openjdk.org/jdk/pull/22558

From matsaave at openjdk.org  Wed Dec  4 20:49:37 2024
From: matsaave at openjdk.org (Matias Saavedra Silva)
Date: Wed, 4 Dec 2024 20:49:37 GMT
Subject: RFR: 8345224: Test
 runtime/cds/appcds/applications/JavacBench.java#dynamic fails after
 JDK-8344822
In-Reply-To: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
References: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
Message-ID: <aRhUph0cC2n0lZpbRhVuOL2VhV5l-447nR1OsmCzTgw=.f6fc9a95-776b-44ec-8dcd-1add505ef839@github.com>

On Wed, 4 Dec 2024 19:34:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `hotspot_runtime_non_cds_mode` test group is for running jtreg tests with `-vmoptions:-Xshare:off`. Such a scenario doesn't make sense for the CDS tests, and could cause similar failures in the future.
> 
> We should remove all CDS tests from `hotspot_runtime_non_cds_mode`

Makes sense to me, thanks!

-------------

Marked as reviewed by matsaave (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22558#pullrequestreview-2479867755

From mdoerr at openjdk.org  Wed Dec  4 20:55:43 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 4 Dec 2024 20:55:43 GMT
Subject: RFR: 8343767: Enumerate StubGen blobs,
 stubs and entries and generate code from declarations [v9]
In-Reply-To: <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
References: <-AWWTyIzvOXQ2aUXAFu2U4Bz5cc8NrDzp0x1sVOYcjg=.3a4734d8-78a4-4498-bcbe-34ce589637c3@github.com>
 <VYFLerAoI3B4R8Zd7U4Ge6AHiBezgRmSBLM3G5TM2NQ=.844c5ce9-d07c-48ad-ba06-58a3e9aea601@github.com>
Message-ID: <kILFdiUs-nQLzJaCs0J18D3ue9eTLZsFcW2fIUE1uyA=.4798b477-18e8-41bc-aea5-88a7dc3266d8@github.com>

On Mon, 2 Dec 2024 16:18:07 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Implementation of JDK-8343767
>
> Andrew Dinn has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   increase compiler stub space for macos x86_64

I think I found the problem on PPC64: `TEST_FILL` should only run when `OptimizeFill` is enabled. Note that this feature is unsupported on PPC64.
In addition, feel free to remove `zero_words_aligned8` completely. It's dead code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21957#issuecomment-2518537113

From ccheung at openjdk.org  Wed Dec  4 20:56:37 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Wed, 4 Dec 2024 20:56:37 GMT
Subject: RFR: 8345224: Test
 runtime/cds/appcds/applications/JavacBench.java#dynamic fails after
 JDK-8344822
In-Reply-To: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
References: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
Message-ID: <--91A_1hoSlOs7Pt-zxkO49GNgTMDY0U_wq6OPj7edc=.f0d5bc14-0473-472c-9ee2-8bdbea0148ac@github.com>

On Wed, 4 Dec 2024 19:34:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `hotspot_runtime_non_cds_mode` test group is for running jtreg tests with `-vmoptions:-Xshare:off`. Such a scenario doesn't make sense for the CDS tests, and could cause similar failures in the future.
> 
> We should remove all CDS tests from `hotspot_runtime_non_cds_mode`

LGTM

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22558#pullrequestreview-2479880595

From pchilanomate at openjdk.org  Wed Dec  4 21:28:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 21:28:47 GMT
Subject: Integrated: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id
In-Reply-To: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
Message-ID: <E499NqnB06_eCIvFDcBXM3XEGVGYLOUapfd89hsIbyI=.6ee58bb9-b7a1-4f4f-b3b1-c0a1f723c488@github.com>

On Tue, 3 Dec 2024 19:10:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: c113f82f
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c113f82f78c7d9be1ac297aebfeb6051f0f904fb
Stats:     83 lines in 19 files changed: 0 ins; 2 del; 81 mod

8343957: Rename ObjectMonitor::owner_from() and JavaThread::_lock_id

Reviewed-by: coleenp, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22524

From pchilanomate at openjdk.org  Wed Dec  4 21:28:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 4 Dec 2024 21:28:46 GMT
Subject: RFR: 8343957: Rename ObjectMonitor::owner_from() and
 JavaThread::_lock_id [v2]
In-Reply-To: <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
References: <9PPc-HCpTmRz0ouqvFaawkmB510eCOWmwmzv4CeilW8=.a894cabb-45bf-40be-a516-ff7f8488c435@github.com>
 <qQWOvEtVu1I5KPcjggOuj--AF-zuAJI0ipBQp1pnTHY=.1d7f8833-f1db-4fdb-a80f-a1896eb13855@github.com>
Message-ID: <hVBseQjbCZe-_o7YhA0CdDgv6gWDaGGD8D3z9fWkfsE=.40e9f97a-b073-4e02-a4fb-4ad0d889f11a@github.com>

On Wed, 4 Dec 2024 15:47:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Please review this small renaming patch. During the review of JDK-8338383 there were some comments about improving the naming for `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate from the changes introduced to inflated monitors, where we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a `JavaThread*`. I renamed `_lock_id` as `_monitor_owner_id` and `owner_from()` as `owner_id_from()`.
>> 
>> Thanks,
>> Patricio
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix parameter name

Thanks for the reviews Coleen and David!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22524#issuecomment-2518592483

From lmesnik at openjdk.org  Wed Dec  4 22:05:49 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 4 Dec 2024 22:05:49 GMT
Subject: RFR: 8345435: Eliminate tier1_compiler_not_xcomp group
Message-ID: <Ij9wJgt4dUiHjJcU6PZ3Oz7YtqXGhsBFnOItxKfiGew=.096ff918-f850-445c-821e-52f7af644936@github.com>

The fix remove tier1_compiler_not_xcomp group. All profiling tests are marked as non Xcomp and added to tier1.

Verified that :tier1_compiler_3 contains them and that tier1 passed.

-------------

Commit messages:
 - 8345435: Eliminate tier1_compiler_not_xcomp group

Changes: https://git.openjdk.org/jdk/pull/22563/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22563&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345435
  Stats: 31 lines in 13 files changed: 14 ins; 8 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22563.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22563/head:pull/22563

PR: https://git.openjdk.org/jdk/pull/22563

From kvn at openjdk.org  Wed Dec  4 22:50:37 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 4 Dec 2024 22:50:37 GMT
Subject: RFR: 8345435: Eliminate tier1_compiler_not_xcomp group
In-Reply-To: <Ij9wJgt4dUiHjJcU6PZ3Oz7YtqXGhsBFnOItxKfiGew=.096ff918-f850-445c-821e-52f7af644936@github.com>
References: <Ij9wJgt4dUiHjJcU6PZ3Oz7YtqXGhsBFnOItxKfiGew=.096ff918-f850-445c-821e-52f7af644936@github.com>
Message-ID: <l1A-q8It2IfONEq_Zxc6-fOQePeF_TPTIYQXGVFDRd8=.c1a89f99-9c32-48ff-b5ca-7a380f3832aa@github.com>

On Wed, 4 Dec 2024 22:01:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix remove tier1_compiler_not_xcomp group. All profiling tests are marked as non Xcomp and added to tier1.
> 
> Verified that :tier1_compiler_3 contains them and that tier1 passed.

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22563#pullrequestreview-2480072284

From rrich at openjdk.org  Wed Dec  4 22:50:39 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 4 Dec 2024 22:50:39 GMT
Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <Inumu1CRB7VCFi9ffJuUqpVXVy0vOvpsSeCeLQ9SHzc=.8e629955-c4a9-4abf-950e-254136d87c20@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
 <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
 <Inumu1CRB7VCFi9ffJuUqpVXVy0vOvpsSeCeLQ9SHzc=.8e629955-c4a9-4abf-950e-254136d87c20@github.com>
Message-ID: <gitDDrqHWO7iACpVRrZ7ehFs1mOc-IC8z8VIAMgnnxg=.652da708-cadb-4924-b614-4f47daf9aa23@github.com>

On Mon, 2 Dec 2024 14:13:15 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make sure interpreter entries are not called on Power8 or older.
>
> src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp line 700:
> 
>> 698:       LIR_Opr tmp = new_register(T_FLOAT);
>> 699:       // f2hf treats tmp as live_in. Workaround: initialize to some value.
>> 700:       __ move(LIR_OprFact::floatConst(-0.0), tmp); // just to satisfy LinearScan
> 
> @vnkozlov What do you think about introducing a dummy `LIR_Op0` which provides an undefined float for such workarounds (separate RFE)? That could be used on multiple platforms.

I'm trying to understand this. Wouldn't `_floatToFloat16` naturally be modeled as a `LIR_Op1`? `LIR_Op1` cannot currently accomodate a tmp. That's why `LIR_Op2` is used. Is that correct?
If so, wouldn't it be best to add a tmp to `LIR_Op1`? 
And if we don't want to do that then we could still use `LIR_O2::_tmp1`, can't we? This is a [little experiment](https://github.com/reinrich/jdk/commit/c34ef322c7eb9708afb804e08fec6bc4933260e5) which does so. Binary16Conversion.java succeeds with it.
And if we don't want to change shared code then we could have one float scratch register that's not allocated by linear scan.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22433#discussion_r1870316991

From henryjen at openjdk.org  Thu Dec  5 03:08:36 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 5 Dec 2024 03:08:36 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v5]
In-Reply-To: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
Message-ID: <pRqo0j2VErcSwhdtYNy7pgvVAJ25vHJC0jrNqpjYnKI=.7e936038-4e55-48af-a327-9c6c9a30eb83@github.com>

> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
> 
> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
> 
> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Adapt review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21964/files
  - new: https://git.openjdk.org/jdk/pull/21964/files/eeeb7181..ebed0185

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=03-04

  Stats: 54 lines in 10 files changed: 13 ins; 31 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21964/head:pull/21964

PR: https://git.openjdk.org/jdk/pull/21964

From amitkumar at openjdk.org  Thu Dec  5 03:10:57 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 5 Dec 2024 03:10:57 GMT
Subject: RFR: 8345355: [s390x] support for z16 hardware [v4]
In-Reply-To: <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
 <VU6VnhF2rixGcykb7bvU-9AAzPORSZ4njDJc6BylnDM=.49715432-7f43-4e24-9d5f-314736628e6d@github.com>
Message-ID: <hfmmCEvape-d_kJCXs9kB9aHBiKWrfwdhsm0bfnuBIY=.5bdad6df-d409-4069-9b59-699321caf389@github.com>

On Wed, 4 Dec 2024 05:22:17 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
>> 
>> 
>> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>> 
>> 
>> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
>> 
>> This is the output with current changes: 
>> 
>> 
>> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
>
> Amit Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move mask to correction location

Thanks for the approval Lutz, Andrew :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22508#issuecomment-2518991746

From amitkumar at openjdk.org  Thu Dec  5 03:10:57 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 5 Dec 2024 03:10:57 GMT
Subject: Integrated: 8345355: [s390x] support for z16 hardware
In-Reply-To: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
References: <U8RFEbA-WJvpJhiT7WgA5p2Xejn3BXrde4tLLUgQ8SY=.9ef4b552-005b-4b8a-98d8-0f85d17f8137@github.com>
Message-ID: <OJz5Q5o2PjT0Ne6c0CYhFASay-kTX8ci7bzsTCZWUGg=.177d70d1-bd29-4f92-9284-ff308f397b17@github.com>

On Tue, 3 Dec 2024 06:01:27 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This was the output for `jdk/bin/java -XX:+Verbose --version` command on a z16 hardware: 
> 
> 
> CPU Version as detected internally: system-z, g9-z15, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash
> 
> 
> So the issue is that z16 should be recognized as g10-z16 but instead I got g9-z15. 
> 
> This is the output with current changes: 
> 
> 
> CPU Version as detected internally: system-z, g10-z16, ldisp_fast, extimm, pcrel_load/store, cmpb, cond_load/store, interlocked_update, txm, vectorinstr, instrext2, venh1, instrext3, venh2,bear_enh, sort_enh, nnpa_assist, storage_key_removal, vpack_decimal_enh, out-of-support_as_of_tbd, aes128, aes192, aes256, sha1, sha256, sha512, ghash

This pull request has now been integrated.

Changeset: 67a7b004
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67a7b0049d373293f68699c3b985dc355361cda7
Stats:     36 lines in 2 files changed: 23 ins; 0 del; 13 mod

8345355: [s390x] support for z16 hardware

Reviewed-by: lucy, aph

-------------

PR: https://git.openjdk.org/jdk/pull/22508

From iklam at openjdk.org  Thu Dec  5 05:23:44 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 5 Dec 2024 05:23:44 GMT
Subject: RFR: 8345224: Test
 runtime/cds/appcds/applications/JavacBench.java#dynamic fails after
 JDK-8344822
In-Reply-To: <--91A_1hoSlOs7Pt-zxkO49GNgTMDY0U_wq6OPj7edc=.f0d5bc14-0473-472c-9ee2-8bdbea0148ac@github.com>
References: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
 <--91A_1hoSlOs7Pt-zxkO49GNgTMDY0U_wq6OPj7edc=.f0d5bc14-0473-472c-9ee2-8bdbea0148ac@github.com>
Message-ID: <GKxojiHa1KhRgY98Y01kGlCkKbMiZZVN3_Ttq2I0C4M=.745f7bd7-2d35-4db3-85f8-786121db4680@github.com>

On Wed, 4 Dec 2024 20:53:55 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The `hotspot_runtime_non_cds_mode` test group is for running jtreg tests with `-vmoptions:-Xshare:off`. Such a scenario doesn't make sense for the CDS tests, and could cause similar failures in the future.
>> 
>> We should remove all CDS tests from `hotspot_runtime_non_cds_mode`
>
> LGTM

Thanks @calvinccheung @matias9927 for the review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22558#issuecomment-2519194618

From iklam at openjdk.org  Thu Dec  5 05:23:44 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Thu, 5 Dec 2024 05:23:44 GMT
Subject: Integrated: 8345224: Test
 runtime/cds/appcds/applications/JavacBench.java#dynamic fails after
 JDK-8344822
In-Reply-To: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
References: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
Message-ID: <EUVl1rZLz31XTvYgilQZGqlcWnbxIio44lkMkO9WnxY=.7a8e6e58-32f2-4e1c-8090-462af0bfd89a@github.com>

On Wed, 4 Dec 2024 19:34:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `hotspot_runtime_non_cds_mode` test group is for running jtreg tests with `-vmoptions:-Xshare:off`. Such a scenario doesn't make sense for the CDS tests, and could cause similar failures in the future.
> 
> We should remove all CDS tests from `hotspot_runtime_non_cds_mode`

This pull request has now been integrated.

Changeset: 7c8cec18
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7c8cec186a8d0e5e87baf0ece24e7bc59700263f
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8345224: Test runtime/cds/appcds/applications/JavacBench.java#dynamic fails after JDK-8344822

Reviewed-by: matsaave, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/22558

From rehn at openjdk.org  Thu Dec  5 07:20:44 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Dec 2024 07:20:44 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
Message-ID: <mSbTMgieT2PuPjtM9LOEvNxDZDvtuMOY0DYUB2s-nLI=.803cd2b0-528d-4a7b-a7cc-b78db41b0f9b@github.com>

On Mon, 2 Dec 2024 13:54:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
>> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some background description

src/hotspot/cpu/riscv/stubRoutines_riscv.cpp line 494:

> 492:     0x5a546366UL, 0x00000001UL,
> 493:     0x751997d0UL, 0x00000001UL,
> 494:     0xccaa009eUL, 0x00000000UL,

Did you calculate these yourself, or where do they come from?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1870781890

From rehn at openjdk.org  Thu Dec  5 07:22:41 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Dec 2024 07:22:41 GMT
Subject: RFR: 8345179: RISC-V: Add gtests for weak cmpxchg [v6]
In-Reply-To: <RL5YV0V_cVwUBLY3AKVMDxgZhT2FCRz5fj_-UMUqvJg=.c230e467-5453-468c-b1f2-a1df5c057fce@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
 <RL5YV0V_cVwUBLY3AKVMDxgZhT2FCRz5fj_-UMUqvJg=.c230e467-5453-468c-b1f2-a1df5c057fce@github.com>
Message-ID: <WkjJ38FKEYOwFt85-rHpUAMzbHyLtaWRTm_ozVraQHk=.bbe4fd93-e319-4b36-9c36-9a66871b2c9b@github.com>

On Wed, 4 Dec 2024 08:21:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider.
>> 
>> This adds tests of aligned weak narrow cmpxchg.
>> 
>> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
>> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
>> [----------] 4 tests from RiscV (20997 ms total)
>> 
>> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into weak_narrow
>  - Fixed WS
>  - Review comment
>  - Added weak 4/8 byte cmpxchg
>  - Merge branch 'master' into weak_narrow
>  - gtest weak narrow cmpxchg

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22476#issuecomment-2519436463

From rehn at openjdk.org  Thu Dec  5 07:27:42 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Dec 2024 07:27:42 GMT
Subject: Integrated: 8345179: RISC-V: Add gtests for weak cmpxchg
In-Reply-To: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
References: <bPpZOk7G0WXSLX9_Db1WL2NZ0FDRbhbeWsWL_LCRQPA=.c2c0b0a2-19cb-47fe-8acf-bdab54d2ebec@github.com>
Message-ID: <0bXdjOsykWJiyp0ssbIIvdrHhgblY6yCWtat22bDBVM=.063676dd-69e6-4b74-a340-4aac798cb9bb@github.com>

On Mon, 2 Dec 2024 10:46:09 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider.
> 
> This adds tests of aligned weak narrow cmpxchg.
> 
> [ RUN      ] RiscV.cmpxchg_weak_int16_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int16_lr_sc_vm (2 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_lr_sc_vm
> [       OK ] RiscV.cmpxchg_weak_int8_lr_sc_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int16_maybe_zacas_vm (0 ms)
> [ RUN      ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_weak_int8_maybe_zacas_vm (0 ms)
> [----------] 4 tests from RiscV (20997 ms total)
> 
> Executed with -XX:+UnlockExperimentalVMOptions -XX:+UseZacas
> 
> Thanks, Robbin

This pull request has now been integrated.

Changeset: 2331782c
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2331782cf713e2db6d65b490c52c4de0a6555dca
Stats:     129 lines in 1 file changed: 129 ins; 0 del; 0 mod

8345179: RISC-V: Add gtests for weak cmpxchg

Reviewed-by: fyang, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22476

From mli at openjdk.org  Thu Dec  5 09:16:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 5 Dec 2024 09:16:38 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <mSbTMgieT2PuPjtM9LOEvNxDZDvtuMOY0DYUB2s-nLI=.803cd2b0-528d-4a7b-a7cc-b78db41b0f9b@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <mSbTMgieT2PuPjtM9LOEvNxDZDvtuMOY0DYUB2s-nLI=.803cd2b0-528d-4a7b-a7cc-b78db41b0f9b@github.com>
Message-ID: <De8aXDg9t4jbKm0o-JX_ylGHImSVjDP7XukWnaDjB-Y=.07a2c17d-7e48-48d2-af1c-0bd0fbc6e862@github.com>

On Thu, 5 Dec 2024 07:15:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add some background description
>
> src/hotspot/cpu/riscv/stubRoutines_riscv.cpp line 494:
> 
>> 492:     0x5a546366UL, 0x00000001UL,
>> 493:     0x751997d0UL, 0x00000001UL,
>> 494:     0xccaa009eUL, 0x00000000UL,
> 
> Did you calculate these yourself, or where do they come from?

They're from aarch64 implementation, and I think x86 use the same ones.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1870961263

From mdoerr at openjdk.org  Thu Dec  5 09:27:38 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 5 Dec 2024 09:27:38 GMT
Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <gitDDrqHWO7iACpVRrZ7ehFs1mOc-IC8z8VIAMgnnxg=.652da708-cadb-4924-b614-4f47daf9aa23@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
 <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
 <Inumu1CRB7VCFi9ffJuUqpVXVy0vOvpsSeCeLQ9SHzc=.8e629955-c4a9-4abf-950e-254136d87c20@github.com>
 <gitDDrqHWO7iACpVRrZ7ehFs1mOc-IC8z8VIAMgnnxg=.652da708-cadb-4924-b614-4f47daf9aa23@github.com>
Message-ID: <wm-Ort3SOYMA07meBfDVV6iiszp5pjODEVs98yiuRWE=.89e712c3-6274-4402-b339-7d40464b0a90@github.com>

On Wed, 4 Dec 2024 21:41:49 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> I'm trying to understand this. Wouldn't `_floatToFloat16` naturally be modeled as a `LIR_Op1`? `LIR_Op1` cannot currently accomodate a tmp. That's why `LIR_Op2` is used. Is that correct?

I didn't write that code, but I believe that this is correct.

> If so, wouldn't it be best to add a tmp to LIR_Op1?
And if we don't want to do that then we could still use LIR_O2::_tmp1, can't we? This is a [little experiment](https://github.com/reinrich/jdk/commit/c34ef322c7eb9708afb804e08fec6bc4933260e5) which does so. Binary16Conversion.java succeeds with it.

I like this proposal. But I prefer doing that in a separate RFE for all affected platforms.

> And if we don't want to change shared code then we could have one float scratch register that's not allocated by linear scan.

I strongly prefer the solution above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22433#discussion_r1870981321

From dholmes at openjdk.org  Thu Dec  5 09:28:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Dec 2024 09:28:44 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
Message-ID: <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>

On Wed, 4 Dec 2024 06:18:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> But if we enter this block because _M_ARM64 is defined then X86 cannot be defined so line 294 is vacuously true.
>
> I'm not sure I follow - The _M_ARM64 block is terminated by an endif before line 294, it is only there to define the global constants and does not guard the code below that line 294 does. Additionally, the code guarded by the if X86 seems to be for all non x86 platforms, not just ARM64

Apologies somehow the endif at line 292 was invisible

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1870979837

From dholmes at openjdk.org  Thu Dec  5 09:28:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Dec 2024 09:28:45 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
Message-ID: <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>

On Thu, 5 Dec 2024 09:24:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'm not sure I follow - The _M_ARM64 block is terminated by an endif before line 294, it is only there to define the global constants and does not guard the code below that line 294 does. Additionally, the code guarded by the if X86 seems to be for all non x86 platforms, not just ARM64
>
> Apologies somehow the endif at line 292 was invisible

Though now I am even more confused. For x64 where are the definitions for `float_sign_mask` etc??

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1870983190

From rehn at openjdk.org  Thu Dec  5 09:30:40 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Dec 2024 09:30:40 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
Message-ID: <JjlPrCLwOREOP8nn_tuEOTqMrdPHwBYEUaX2kI92W7o=.bad5a9c6-512a-48ea-81a6-ee585e222fb5@github.com>

On Mon, 2 Dec 2024 13:54:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
>> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some background description

There is a bunch of more tests you can run.
I see around 40, e.g. test/jdk/java/util/zip/ZipFile/TestZipFile.java.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22475#issuecomment-2519739309

From dholmes at openjdk.org  Thu Dec  5 09:39:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Dec 2024 09:39:44 GMT
Subject: RFR: 8345224: Test
 runtime/cds/appcds/applications/JavacBench.java#dynamic fails after
 JDK-8344822
In-Reply-To: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
References: <_A8bjst8M1VlIGqBEBQRhMK3ep7xzhedJPGrmusYY-o=.eb2ed8ab-347d-4f24-9eb8-217be294f867@github.com>
Message-ID: <Sa5XsY1SqvQlwkFjv1-7qiniWF54K9FGE_SGyU63zzs=.12402405-77b5-4a6f-b28c-5249a753897c@github.com>

On Wed, 4 Dec 2024 19:34:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The `hotspot_runtime_non_cds_mode` test group is for running jtreg tests with `-vmoptions:-Xshare:off`. Such a scenario doesn't make sense for the CDS tests, and could cause similar failures in the future.
> 
> We should remove all CDS tests from `hotspot_runtime_non_cds_mode`

Okay ... but why did this suddenly start failing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22558#issuecomment-2519761470

From dholmes at openjdk.org  Thu Dec  5 09:45:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 5 Dec 2024 09:45:41 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <dZiNe6a2ntA89b2Cl-zsGcp5UqwrZkQhCdYKvjVm80Q=.089cdc88-4f41-4f44-95e0-3a4f32c2f72c@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
 <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
 <dZiNe6a2ntA89b2Cl-zsGcp5UqwrZkQhCdYKvjVm80Q=.089cdc88-4f41-4f44-95e0-3a4f32c2f72c@github.com>
Message-ID: <v8aq2pqsKj8-EseQOpYdcpWsyVws1tLp8oW2x08iWhs=.364af2cf-d1b2-48c9-b1e6-22b7f22754b2@github.com>

On Wed, 4 Dec 2024 13:28:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I think the case for making the whole thing in a header depends on how much code there is, that's all.
>
> concurrentHashTable uses the trick of inlining a lot of methods in concurrentHashTable.inline.hpp and concurrentHashTableTasks.inline.hpp that are included in the .cpp callers.  This might work for this also.

FWIW this was a drive by comment and it just surprised me to see everything in the hpp file. I don't know GrowableArray enough to recognise it has a similar approach.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1871011459

From jwaters at openjdk.org  Thu Dec  5 09:58:41 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 5 Dec 2024 09:58:41 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
Message-ID: <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>

On Thu, 5 Dec 2024 09:26:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Apologies somehow the endif at line 292 was invisible
>
> Though now I am even more confused. For x64 where are the definitions for `float_sign_mask` etc??

x86 (And by extension x64) uses handwritten assembly to implement this, and as such simply doesn't use float_sign_mask and friends: https://github.com/openjdk/jdk/blob/3b7571d37812472a2152f9c8cbfd2a4abdb35016/src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp#L123

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1871034556

From rrich at openjdk.org  Thu Dec  5 11:06:38 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 5 Dec 2024 11:06:38 GMT
Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
 <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
Message-ID: <5jjuNmFeAe4qXCXJoklaxCIRgOQmjnKb3_y4iUdtvA8=.3aef9a17-8096-43c8-adad-d4964cac4dbc@github.com>

On Thu, 28 Nov 2024 21:33:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future.
>> VectorCastNodes are not yet implemented on PPC64. Power9 is recognized by the availability of the "darn" instruction.
>> 
>> Performance on Power9:
>> Before patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score     Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15     18.995 ?   0.156  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15     18.730 ?   0.331  ops/ms
>> 
>> 
>> After patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score      Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15    522.637 ?   11.274  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15    408.112 ?    9.069  ops/ms
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure interpreter entries are not called on Power8 or older.

Looks good.
Cheers, Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22433#pullrequestreview-2481337210

From lucy at openjdk.org  Thu Dec  5 12:02:37 2024
From: lucy at openjdk.org (Lutz Schmidt)
Date: Thu, 5 Dec 2024 12:02:37 GMT
Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
 <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
Message-ID: <fifObLW78-u6dSGvXuQx9RzZAA5UtAU99KkBb3D-_WE=.1c1867b8-aefe-4bf1-a1f5-28c7f5dc8bb0@github.com>

On Thu, 28 Nov 2024 21:33:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future.
>> VectorCastNodes are not yet implemented on PPC64. Power9 is recognized by the availability of the "darn" instruction.
>> 
>> Performance on Power9:
>> Before patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score     Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15     18.995 ?   0.156  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15     18.730 ?   0.331  ops/ms
>> 
>> 
>> After patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score      Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15    522.637 ?   11.274  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15    408.112 ?    9.069  ops/ms
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure interpreter entries are not called on Power8 or older.

LGTM.

-------------

Marked as reviewed by lucy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22433#pullrequestreview-2481473423

From mdoerr at openjdk.org  Thu Dec  5 12:06:48 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 5 Dec 2024 12:06:48 GMT
Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
 <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
Message-ID: <7-j0bpdYu0ytIwhE1_22zl_hf56iRVRTb8ks0z_7kr8=.13b8b1d3-b83c-4ceb-baa4-e30a8e0ad431@github.com>

On Thu, 28 Nov 2024 21:33:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future.
>> VectorCastNodes are not yet implemented on PPC64. Power9 is recognized by the availability of the "darn" instruction.
>> 
>> Performance on Power9:
>> Before patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score     Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15     18.995 ?   0.156  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15     18.730 ?   0.331  ops/ms
>> 
>> 
>> After patch:
>> 
>> Benchmark                                     (size)   Mode  Cnt      Score      Error   Units
>> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15    522.637 ?   11.274  ops/ms
>> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15    408.112 ?    9.069  ops/ms
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make sure interpreter entries are not called on Power8 or older.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22433#issuecomment-2520130374

From mdoerr at openjdk.org  Thu Dec  5 12:06:49 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 5 Dec 2024 12:06:49 GMT
Subject: Integrated: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats
In-Reply-To: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
Message-ID: <iRmQ6Vmv2iMeSoT0T1cOlaOO1ZNDEC2CTjwsoyDoA6M=.51eb06b2-e302-498c-8489-a1b83d239e59@github.com>

On Thu, 28 Nov 2024 11:21:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64 implementation of [JDK-8289552](https://bugs.openjdk.org/browse/JDK-8289552). I've implemented some more instructions which may be useful in the future.
> VectorCastNodes are not yet implemented on PPC64. Power9 is recognized by the availability of the "darn" instruction.
> 
> Performance on Power9:
> Before patch:
> 
> Benchmark                                     (size)   Mode  Cnt      Score     Error   Units
> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15     18.995 ?   0.156  ops/ms
> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15     18.730 ?   0.331  ops/ms
> 
> 
> After patch:
> 
> Benchmark                                     (size)   Mode  Cnt      Score      Error   Units
> Fp16ConversionBenchmark.float16ToFloat          2048  thrpt   15    522.637 ?   11.274  ops/ms
> Fp16ConversionBenchmark.floatToFloat16          2048  thrpt   15    408.112 ?    9.069  ops/ms

This pull request has now been integrated.

Changeset: b42d79eb
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b42d79eb6a6d497dc63718c2854609bebca4498c
Stats:     182 lines in 15 files changed: 179 ins; 2 del; 1 mod

8345146: [PPC64] Make intrinsic conversions between bit representations of half precision values and floats

Reviewed-by: rrich, lucy

-------------

PR: https://git.openjdk.org/jdk/pull/22433

From rehn at openjdk.org  Thu Dec  5 12:06:59 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Dec 2024 12:06:59 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
Message-ID: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>

Hi, please consider these additional concurrent tests.

(this will not go into 24)

There are two concurrent counter versions:
- Each thread is exclusively responsible for an certain increment steps
- Each thread plainly tries to CAS increment by one

I refactored the code, so these concurrent versions can reuse the generated CAS functions.


[ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
[       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
[ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
[       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
[ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
[       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
[ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
[       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
[ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
[       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
[ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
[       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
[ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
[       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
[ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
[       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
[ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
[       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
[ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
[       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
[ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
[       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
[ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
[       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
[ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
[       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
[ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
[       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
[ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
[       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
[ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
[       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)


Execute with +UseZacas, and without on BPI-F3.

Thanks, Robbin

-------------

Commit messages:
 - Concurrent

Changes: https://git.openjdk.org/jdk/pull/22574/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345322
  Stats: 359 lines in 1 file changed: 269 ins; 13 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22574/head:pull/22574

PR: https://git.openjdk.org/jdk/pull/22574

From alanb at openjdk.org  Thu Dec  5 12:12:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 12:12:40 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v5]
In-Reply-To: <pRqo0j2VErcSwhdtYNy7pgvVAJ25vHJC0jrNqpjYnKI=.7e936038-4e55-48af-a327-9c6c9a30eb83@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <pRqo0j2VErcSwhdtYNy7pgvVAJ25vHJC0jrNqpjYnKI=.7e936038-4e55-48af-a327-9c6c9a30eb83@github.com>
Message-ID: <5Sj7OU-s_kafL1NE2pidQXN5Zr6UxmkZH35A-KSEdP8=.8c66f022-4fe0-4b27-9909-582a561203dd@github.com>

On Thu, 5 Dec 2024 03:08:36 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt review feedback

Update ebed0185 looks okay, much cleaner now.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 262:

> 260: vendor-vm.description=\
> 261: Override the vendor string baked into the build, if any.\n\
> 262: The value of the system property "java.vm.vendor" will be <vendor>.

This is a copy of vendor.description, I assume it should be adjusted to say vendor VM. Same comment in vendor-vm.usage.

test/jdk/tools/jlink/plugins/VendorInfoPluginsTest.java line 2:

> 1: /*
> 2:  * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

This should be "2019, 2014,"

Also you can bump the date on the module-info.java.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21964#pullrequestreview-2481502468
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1871266352
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1871267713

From stuefe at openjdk.org  Thu Dec  5 14:11:30 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 14:11:30 GMT
Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
 [v2]
In-Reply-To: <q0CajI0h92_WhFgxyQSDnRXDzJoJsEzlWozHVqueIZ4=.255e935c-453b-4ad9-a70e-510b2217e7d5@github.com>
References: <q0CajI0h92_WhFgxyQSDnRXDzJoJsEzlWozHVqueIZ4=.255e935c-453b-4ad9-a70e-510b2217e7d5@github.com>
Message-ID: <vXeUotNoukSoCkPE-e7kcVXl_PAH8J1hSE8d5CgsWpg=.821b6910-6963-41f7-82d4-36fc3305801f@github.com>

> In `MacroAssembler::klass_decode_mode(),` there is a subtle bug in the xor part.
> 
> 
>   if (operand_valid_for_logical_immediate(
>         /*is32*/false, (uint64_t)CompressedKlassPointers::base())) {
> (1) const size_t range = CompressedKlassPointers::klass_range_end() - CompressedKlassPointers::base();
> (2) const uint64_t range_mask = (1ULL << log2i(range)) - 1;
> (3) if (((uint64_t)CompressedKlassPointers::base() & range_mask) == 0) {
>       log_debug(metaspace)("MacroAssembler::klass_decode_mode xor");
>       return (_klass_decode_mode = KlassDecodeXor);
>     }
>   }
> 
> 
> We first determine if the encoding base is encodable as immediate. If it is, then we check if it intersects with the value range of a narrow Klass ID.
> 
> (Note: the code ignores encoding shift since the XOR will be applied to the pre-shifted narrow Klass value later.)
> 
> The test is done by
> 1) calculating the range the encoding needs to cover
> 2) calculating a corresponding bit mask
> 3) checking that this mask does not intersect with the encoding base.
> 
> (2) contains a wrongness: `range_mask = (1ULL << log2i(range)) - 1` . `log2i` returns the largest log2 value *smaller* or equal to input. So, for `range` values that are not a pow2 value, the resulting mask will be one bit too short. As an effect, the code may chose XOR for cases where the lowest encoding base bit can intersect the highest narrow Klass ID bit, thus making the xor lossy.
> 
> ----
> 
> Example:
> 
> Let range be 80MB (`-XX:CompressedClassSpaceSize=80m -Xshare:off`).
> 
> Then, range_mask = `1 << log2i(80m) - 1` => `(1 << 26) - 1` => `0x3ff_ffff`
> The largest possible nKlass value, however, sits just below 80MB => `0x500_0000`. As we see, the mask does not cover the full extent of the narrow Klass ID value range (bit 26 is not covered).
> Hence, if we have a base with bit 26 set, its bit 26 intersects a possible bit 26 in high-value narrow Klass ID. The xor would not be lossless.
> 
> ----
> 
> The error is very unlikely because
> - we try to reserve the klass range at addresses that are guaranteed not to intersect with the narrow Klass range. Only if that fails - very unlikely - we use whatever address the OS gives us. Only then could we end up with such an address.
> - The class space is rarely filled so high that the highest bit of a narrowKlass ID is `1`.
> 
> ----
> 
> Reproduce:
> 
> 
> java -XX:CompressedClassSpaceBaseAddress=0x1Fc000000 -XX:CompressedClassSpaceSize=80m -Xlog:metaspace* -Xshare:off
> 
> 
> it does not reproduce an error, but causes the JVM to start in XOR mode with an enc...

Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode
 - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode
 - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode
 - JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21932/files
  - new: https://git.openjdk.org/jdk/pull/21932/files/2e9cccab..1803a934

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21932&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21932&range=00-01

  Stats: 301913 lines in 5184 files changed: 142473 ins; 137515 del; 21925 mod
  Patch: https://git.openjdk.org/jdk/pull/21932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21932/head:pull/21932

PR: https://git.openjdk.org/jdk/pull/21932

From stuefe at openjdk.org  Thu Dec  5 14:11:31 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 14:11:31 GMT
Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
 [v2]
In-Reply-To: <tiUEO7CTFZZikGBwNpbIK4L8loDMSKkaNjwCN0KlWP8=.7b9d4cb5-8477-4af8-9697-5e734007b85a@github.com>
References: <q0CajI0h92_WhFgxyQSDnRXDzJoJsEzlWozHVqueIZ4=.255e935c-453b-4ad9-a70e-510b2217e7d5@github.com>
 <tiUEO7CTFZZikGBwNpbIK4L8loDMSKkaNjwCN0KlWP8=.7b9d4cb5-8477-4af8-9697-5e734007b85a@github.com>
Message-ID: <yMQVZmgut_2moST78oK3QMD2iJ97JPp7Bra6mREiO54=.04212e81-bbc2-47e9-be48-2be893352bef@github.com>

On Fri, 15 Nov 2024 13:44:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode
>>  - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode
>>  - Merge branch 'openjdk:master' into JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode
>>  - JDK-8343699-aarch64-Bug-in-MacroAssembler-klass_decode_mode
>
> Thank you for figuring this out.  I'll merge with your code in my PR.

Thanks @coleenp and @adinn !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21932#issuecomment-2520422981

From stuefe at openjdk.org  Thu Dec  5 14:11:32 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 14:11:32 GMT
Subject: Integrated: 8343699: [aarch64] Bug in
 MacroAssembler::klass_decode_mode()
In-Reply-To: <q0CajI0h92_WhFgxyQSDnRXDzJoJsEzlWozHVqueIZ4=.255e935c-453b-4ad9-a70e-510b2217e7d5@github.com>
References: <q0CajI0h92_WhFgxyQSDnRXDzJoJsEzlWozHVqueIZ4=.255e935c-453b-4ad9-a70e-510b2217e7d5@github.com>
Message-ID: <7CdghgJKGFqzIsdGjsa6AiSUd9Ru2yMzhaJBCtWUp-g=.36134295-eb61-40b3-a03f-804b3c7e7bfd@github.com>

On Wed, 6 Nov 2024 15:34:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> In `MacroAssembler::klass_decode_mode(),` there is a subtle bug in the xor part.
> 
> 
>   if (operand_valid_for_logical_immediate(
>         /*is32*/false, (uint64_t)CompressedKlassPointers::base())) {
> (1) const size_t range = CompressedKlassPointers::klass_range_end() - CompressedKlassPointers::base();
> (2) const uint64_t range_mask = (1ULL << log2i(range)) - 1;
> (3) if (((uint64_t)CompressedKlassPointers::base() & range_mask) == 0) {
>       log_debug(metaspace)("MacroAssembler::klass_decode_mode xor");
>       return (_klass_decode_mode = KlassDecodeXor);
>     }
>   }
> 
> 
> We first determine if the encoding base is encodable as immediate. If it is, then we check if it intersects with the value range of a narrow Klass ID.
> 
> (Note: the code ignores encoding shift since the XOR will be applied to the pre-shifted narrow Klass value later.)
> 
> The test is done by
> 1) calculating the range the encoding needs to cover
> 2) calculating a corresponding bit mask
> 3) checking that this mask does not intersect with the encoding base.
> 
> (2) contains a wrongness: `range_mask = (1ULL << log2i(range)) - 1` . `log2i` returns the largest log2 value *smaller* or equal to input. So, for `range` values that are not a pow2 value, the resulting mask will be one bit too short. As an effect, the code may chose XOR for cases where the lowest encoding base bit can intersect the highest narrow Klass ID bit, thus making the xor lossy.
> 
> ----
> 
> Example:
> 
> Let range be 80MB (`-XX:CompressedClassSpaceSize=80m -Xshare:off`).
> 
> Then, range_mask = `1 << log2i(80m) - 1` => `(1 << 26) - 1` => `0x3ff_ffff`
> The largest possible nKlass value, however, sits just below 80MB => `0x500_0000`. As we see, the mask does not cover the full extent of the narrow Klass ID value range (bit 26 is not covered).
> Hence, if we have a base with bit 26 set, its bit 26 intersects a possible bit 26 in high-value narrow Klass ID. The xor would not be lossless.
> 
> ----
> 
> The error is very unlikely because
> - we try to reserve the klass range at addresses that are guaranteed not to intersect with the narrow Klass range. Only if that fails - very unlikely - we use whatever address the OS gives us. Only then could we end up with such an address.
> - The class space is rarely filled so high that the highest bit of a narrowKlass ID is `1`.
> 
> ----
> 
> Reproduce:
> 
> 
> java -XX:CompressedClassSpaceBaseAddress=0x1Fc000000 -XX:CompressedClassSpaceSize=80m -Xlog:metaspace* -Xshare:off
> 
> 
> it does not reproduce an error, but causes the JVM to start in XOR mode with an enc...

This pull request has now been integrated.

Changeset: 456c71d1
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/456c71d1ff64d31445b68d792fdaa9887f3499da
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()

Reviewed-by: adinn, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/21932

From stuefe at openjdk.org  Thu Dec  5 14:13:45 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 5 Dec 2024 14:13:45 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v9]
In-Reply-To: <T4RxnXT-3OkAf_areEU3od_XqdTEVzhR9XyB0GADLGo=.67ef7d88-3797-484f-a32f-82a60e885a90@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <T4RxnXT-3OkAf_areEU3od_XqdTEVzhR9XyB0GADLGo=.67ef7d88-3797-484f-a32f-82a60e885a90@github.com>
Message-ID: <LtjO6fxK8o5KOwclJ8U6c7vkBIFZ-DHbdbx7JmOn9-8=.531284a9-3d4e-49b4-9597-6c89b7948570@github.com>

On Wed, 4 Dec 2024 18:44:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Recalculate decode mode if OS picks a different encoding.

Okay. Thank you for tackling this. I pushed https://github.com/openjdk/jdk/pull/21932.

Cheers, Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21695#pullrequestreview-2481819960

From luhenry at openjdk.org  Thu Dec  5 14:18:38 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Thu, 5 Dec 2024 14:18:38 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
Message-ID: <8NC6j_0aH6FFZeusCKEuYb93SdYUqllk-09mI1HL-zw=.425c1f66-be45-4934-b0e4-5ed7e30d0da5@github.com>

On Mon, 2 Dec 2024 13:54:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
>> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some background description

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22475#pullrequestreview-2481835181

From alanb at openjdk.org  Thu Dec  5 14:54:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 14:54:43 GMT
Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
 [v2]
In-Reply-To: <yMQVZmgut_2moST78oK3QMD2iJ97JPp7Bra6mREiO54=.04212e81-bbc2-47e9-be48-2be893352bef@github.com>
References: <q0CajI0h92_WhFgxyQSDnRXDzJoJsEzlWozHVqueIZ4=.255e935c-453b-4ad9-a70e-510b2217e7d5@github.com>
 <tiUEO7CTFZZikGBwNpbIK4L8loDMSKkaNjwCN0KlWP8=.7b9d4cb5-8477-4af8-9697-5e734007b85a@github.com>
 <yMQVZmgut_2moST78oK3QMD2iJ97JPp7Bra6mREiO54=.04212e81-bbc2-47e9-be48-2be893352bef@github.com>
Message-ID: <i92VujLyyeK4npSHlEeif5Grq3iZZ980VpwEAEQfIRI=.8ace7f98-ff53-4ed5-943e-b5f07e8b0034@github.com>

On Thu, 5 Dec 2024 14:07:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Thank you for figuring this out.  I'll merge with your code in my PR.
>
> Thanks @coleenp and @adinn !

@tstuefe We have a build break on both linux-aarch64 and macosx-aarch64. Local example, with Xcode14.3.1+1.0

/XXX/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp:5308:46: error: use of undeclared identifier 'ceil_log2'
    const uint64_t range_mask = right_n_bits(ceil_log2(range));

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21932#issuecomment-2520535272

From syan at openjdk.org  Thu Dec  5 15:00:42 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Dec 2024 15:00:42 GMT
Subject: RFR: 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
 [v2]
In-Reply-To: <yMQVZmgut_2moST78oK3QMD2iJ97JPp7Bra6mREiO54=.04212e81-bbc2-47e9-be48-2be893352bef@github.com>
References: <q0CajI0h92_WhFgxyQSDnRXDzJoJsEzlWozHVqueIZ4=.255e935c-453b-4ad9-a70e-510b2217e7d5@github.com>
 <tiUEO7CTFZZikGBwNpbIK4L8loDMSKkaNjwCN0KlWP8=.7b9d4cb5-8477-4af8-9697-5e734007b85a@github.com>
 <yMQVZmgut_2moST78oK3QMD2iJ97JPp7Bra6mREiO54=.04212e81-bbc2-47e9-be48-2be893352bef@github.com>
Message-ID: <WemXSdZkp8ougjW-EN2fJTGduKU37IDfpBNBvv3kPrA=.9fa6497c-1371-4618-bfe8-37a26db34bc1@github.com>

On Thu, 5 Dec 2024 14:07:00 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Thank you for figuring this out.  I'll merge with your code in my PR.
>
> Thanks @coleenp and @adinn !

> @tstuefe We have a build break on both linux-aarch64 and macosx-aarch64. Local example, with Xcode14.3.1+1.0

I have created a jbs issue [JDK-8345591](https://bugs.openjdk.org/browse/JDK-8345591) to record this build failure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21932#issuecomment-2520551716

From rehn at openjdk.org  Thu Dec  5 15:13:40 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Dec 2024 15:13:40 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
Message-ID: <XuxbnhQnDlIJFB63Oi8z9GPpxyY1AKODlqWyD9gVLsg=.8301bf81-c673-409b-a4ee-b1b9d70c6248@github.com>

On Mon, 2 Dec 2024 13:54:18 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
>> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>> also run tests found by: `grep -lRi crc32 test/* | grep -v bench`
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add some background description

src/hotspot/cpu/riscv/vm_version_riscv.cpp line 360:

> 358:   // UseZvbc (depends on RVV).
> 359:   if (UseZvbc && !UseRVV) {
> 360:     FLAG_SET_DEFAULT(UseZvbc, false);

If Zvbc is picked up via hwprobe and user uses:
`java -XX:-UseRVV ...`
wouldn't they get the warning forcing them to add -UseZvbc?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1871556621

From mli at openjdk.org  Thu Dec  5 15:13:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 5 Dec 2024 15:13:38 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <JjlPrCLwOREOP8nn_tuEOTqMrdPHwBYEUaX2kI92W7o=.bad5a9c6-512a-48ea-81a6-ee585e222fb5@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <JjlPrCLwOREOP8nn_tuEOTqMrdPHwBYEUaX2kI92W7o=.bad5a9c6-512a-48ea-81a6-ee585e222fb5@github.com>
Message-ID: <f54o6fFChdpgScbnLdZS1lASAXSBe5XmF5G_ny_3Z8s=.b8c3a494-813a-4f3f-b46e-1cd144a57a62@github.com>

On Thu, 5 Dec 2024 09:27:58 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> There is a bunch of more tests you can run. I see around 40, e.g. test/jdk/java/util/zip/ZipFile/TestZipFile.java.

Thanks Robbin for suggestion and running the tests!
I also ran them locally, it passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22475#issuecomment-2520578566

From coleenp at openjdk.org  Thu Dec  5 15:28:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Dec 2024 15:28:11 GMT
Subject: RFR: 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails
 ceil_log2 not declared
In-Reply-To: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
References: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
Message-ID: <gjzyc5uhFeVb1vAw4UH5HGmEXpP-FIhf4TNUrHi5KLQ=.05213ee7-9d4e-4248-94a0-de34d04d969e@github.com>

On Thu, 5 Dec 2024 15:16:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to fix the name of a function in a call.
> This change:
> JDK-8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
> used the name ceil_log2, but that function was recently renamed to log2i_ceil by
> JDK-8344568.
> 
> Testing: mach5 tier1 for linux-aarch64

Looks good thanks for the quick fix.

Agree trivial.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22579#pullrequestreview-2482025747
PR Comment: https://git.openjdk.org/jdk/pull/22579#issuecomment-2520605780

From kbarrett at openjdk.org  Thu Dec  5 15:28:11 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 5 Dec 2024 15:28:11 GMT
Subject: RFR: 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails
 ceil_log2 not declared
Message-ID: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>

Please review this trivial change to fix the name of a function in a call.
This change:
JDK-8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
used the name ceil_log2, but that function was recently renamed to log2i_ceil by
JDK-8344568.

Testing: mach5 tier1 for linux-aarch64

-------------

Commit messages:
 - fix function name

Changes: https://git.openjdk.org/jdk/pull/22579/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22579&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345591
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22579.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22579/head:pull/22579

PR: https://git.openjdk.org/jdk/pull/22579

From alanb at openjdk.org  Thu Dec  5 15:28:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Dec 2024 15:28:12 GMT
Subject: RFR: 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails
 ceil_log2 not declared
In-Reply-To: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
References: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
Message-ID: <wZ4qXdFmQGcwPZ95mcH6CjE2SuthbDf2cmcx_uaHhlY=.c826848b-d336-499c-a642-c564b6fa47ba@github.com>

On Thu, 5 Dec 2024 15:16:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to fix the name of a function in a call.
> This change:
> JDK-8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
> used the name ceil_log2, but that function was recently renamed to log2i_ceil by
> JDK-8344568.
> 
> Testing: mach5 tier1 for linux-aarch64

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22579#pullrequestreview-2482037676

From syan at openjdk.org  Thu Dec  5 15:28:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Dec 2024 15:28:12 GMT
Subject: RFR: 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails
 ceil_log2 not declared
In-Reply-To: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
References: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
Message-ID: <Bb1IPnDXPFgkQilZQuA05kkH5NcyNxR41d7CabCxx04=.ac0d762d-c780-47ca-8980-1685569c29a4@github.com>

On Thu, 5 Dec 2024 15:16:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to fix the name of a function in a call.
> This change:
> JDK-8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
> used the name ceil_log2, but that function was recently renamed to log2i_ceil by
> JDK-8344568.
> 
> Testing: mach5 tier1 for linux-aarch64

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22579#pullrequestreview-2482043705

From gziemski at openjdk.org  Thu Dec  5 15:31:45 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 5 Dec 2024 15:31:45 GMT
Subject: Integrated: 8328944: NMT reports "unknown" memory
In-Reply-To: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
References: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
Message-ID: <xR7Sn0gare20a8_S1-ZabW1ZuqzjLfa2saK7GER35b8=.ac31de9f-5c9f-42a7-a4a1-de6151937d45@github.com>

On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> We use `mtNone` value in several functions default parameters, which may show up in NMT reports.
> 
> We address this, by avoiding using `mtNone`.
> 
> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that.
> 
> Testing: passes MARCH5 tier1-5

This pull request has now been integrated.

Changeset: 7513b137
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7513b1378de4fc2270d8e144a9c3b75859e6fe5f
Stats:     72 lines in 15 files changed: 3 ins; 23 del; 46 mod

8328944: NMT reports "unknown" memory

Reviewed-by: jsjolen, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/21843

From rehn at openjdk.org  Thu Dec  5 15:32:40 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 5 Dec 2024 15:32:40 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <XuxbnhQnDlIJFB63Oi8z9GPpxyY1AKODlqWyD9gVLsg=.8301bf81-c673-409b-a4ee-b1b9d70c6248@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <XuxbnhQnDlIJFB63Oi8z9GPpxyY1AKODlqWyD9gVLsg=.8301bf81-c673-409b-a4ee-b1b9d70c6248@github.com>
Message-ID: <dMC7qfg4vGH0ftLlbGiagtHidn3CXD7F0aGIcIrLA2w=.9f9d3770-d479-40ab-86bd-0e0da67aeff4@github.com>

On Thu, 5 Dec 2024 15:10:24 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add some background description
>
> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 360:
> 
>> 358:   // UseZvbc (depends on RVV).
>> 359:   if (UseZvbc && !UseRVV) {
>> 360:     FLAG_SET_DEFAULT(UseZvbc, false);
> 
> If Zvbc is picked up via hwprobe and user uses:
> `java -XX:-UseRVV ...`
> wouldn't they get the warning forcing them to add -UseZvbc?

I tested:

qemu-riscv64 -cpu "rv64,v=true,vext_spec=v1.0,zvbc=true" java -XX:-UseRVV -version

Gives me this warning about zvcb.

I think if zvcb is default, just turn it off if rvv is off.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1871591614

From kbarrett at openjdk.org  Thu Dec  5 15:34:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 5 Dec 2024 15:34:42 GMT
Subject: RFR: 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails
 ceil_log2 not declared
In-Reply-To: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
References: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
Message-ID: <mpM0CH70WqYrI9Ab52KEqAIXmYlI2WIpokjkfgMVoss=.b4723923-0fca-4f41-ae61-2910eeb41c77@github.com>

On Thu, 5 Dec 2024 15:16:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to fix the name of a function in a call.
> This change:
> JDK-8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
> used the name ceil_log2, but that function was recently renamed to log2i_ceil by
> JDK-8344568.
> 
> Testing: mach5 tier1 for linux-aarch64

Thanks for fast reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22579#issuecomment-2520636465

From kbarrett at openjdk.org  Thu Dec  5 15:34:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 5 Dec 2024 15:34:42 GMT
Subject: Integrated: 8345591: [aarch64] macroAssembler_aarch64.cpp compile
 fails ceil_log2 not declared
In-Reply-To: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
References: <mDtO14jYuWJUgE-2VmbMzRkxior3iVlaxFT_BMuFue8=.e6d22189-6be5-4891-b368-3d8ef9e9d088@github.com>
Message-ID: <GBewT2KjFaU96kbuiCJwo9T2_AknGLyJf4v89lxYc3U=.068b42bc-0cee-4995-898a-daa008f474c3@github.com>

On Thu, 5 Dec 2024 15:16:38 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to fix the name of a function in a call.
> This change:
> JDK-8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
> used the name ceil_log2, but that function was recently renamed to log2i_ceil by
> JDK-8344568.
> 
> Testing: mach5 tier1 for linux-aarch64

This pull request has now been integrated.

Changeset: ef8da284
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef8da28487f918c38fab3096eaeed572d5ea5b90
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8345591: [aarch64] macroAssembler_aarch64.cpp compile fails ceil_log2 not declared

Reviewed-by: coleenp, alanb, syan

-------------

PR: https://git.openjdk.org/jdk/pull/22579

From coleenp at openjdk.org  Thu Dec  5 16:51:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Dec 2024 16:51:21 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into decode-mode
 - Recalculate decode mode if OS picks a different encoding.
 - Only calculate klass-decode-mode in one place.
 - Missed one. Another good reason to not copy code.
 - Rename ceil_log2 to log2i_ceil
 - Merge branch 'master' into decode-mode
 - Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932
 - Merge branch 'master' into decode-mode
 - include formatBuffer.hpp
 - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

-------------

Changes: https://git.openjdk.org/jdk/pull/21695/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=09
  Stats: 113 lines in 8 files changed: 94 ins; 7 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From mdoerr at openjdk.org  Thu Dec  5 16:51:45 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 5 Dec 2024 16:51:45 GMT
Subject: RFR: 8345146: [PPC64] Make intrinsic conversions between bit
 representations of half precision values and floats [v3]
In-Reply-To: <wm-Ort3SOYMA07meBfDVV6iiszp5pjODEVs98yiuRWE=.89e712c3-6274-4402-b339-7d40464b0a90@github.com>
References: <IaRiTdguI_xfsaPE57_qgBr0U8pckUcHI97lkcEOrbE=.bba36367-45ff-480c-a612-104791097b31@github.com>
 <IDAtPCdhNeDURfA8CWx-89WifrQ2nqUu6khHoOjC7Ek=.85d0ab15-f0d7-4def-a81d-e536ecd9e5ee@github.com>
 <Inumu1CRB7VCFi9ffJuUqpVXVy0vOvpsSeCeLQ9SHzc=.8e629955-c4a9-4abf-950e-254136d87c20@github.com>
 <gitDDrqHWO7iACpVRrZ7ehFs1mOc-IC8z8VIAMgnnxg=.652da708-cadb-4924-b614-4f47daf9aa23@github.com>
 <wm-Ort3SOYMA07meBfDVV6iiszp5pjODEVs98yiuRWE=.89e712c3-6274-4402-b339-7d40464b0a90@github.com>
Message-ID: <9xd5MaK4x1fUw_-a5KkENOmXOtWieEkoM13fXe8SP48=.5659476c-3897-46f7-a9b8-cc5fc7604e98@github.com>

On Thu, 5 Dec 2024 09:25:11 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> I'm trying to understand this. Wouldn't `_floatToFloat16` naturally be modeled as a `LIR_Op1`? `LIR_Op1` cannot currently accomodate a tmp. That's why `LIR_Op2` is used. Is that correct?
>> If so, wouldn't it be best to add a tmp to `LIR_Op1`? 
>> And if we don't want to do that then we could still use `LIR_O2::_tmp1`, can't we? This is a [little experiment](https://github.com/reinrich/jdk/commit/c34ef322c7eb9708afb804e08fec6bc4933260e5) which does so. Binary16Conversion.java succeeds with it.
>> And if we don't want to change shared code then we could have one float scratch register that's not allocated by linear scan.
>
>> I'm trying to understand this. Wouldn't `_floatToFloat16` naturally be modeled as a `LIR_Op1`? `LIR_Op1` cannot currently accomodate a tmp. That's why `LIR_Op2` is used. Is that correct?
> 
> I didn't write that code, but I believe that this is correct.
> 
>> If so, wouldn't it be best to add a tmp to LIR_Op1?
> And if we don't want to do that then we could still use LIR_O2::_tmp1, can't we? This is a [little experiment](https://github.com/reinrich/jdk/commit/c34ef322c7eb9708afb804e08fec6bc4933260e5) which does so. Binary16Conversion.java succeeds with it.
> 
> I like this proposal. But I prefer doing that in a separate RFE for all affected platforms.
> 
>> And if we don't want to change shared code then we could have one float scratch register that's not allocated by linear scan.
> 
> I strongly prefer the solution above.

Filed [JDK-8345609](https://bugs.openjdk.org/browse/JDK-8345609).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22433#discussion_r1871746751

From mli at openjdk.org  Thu Dec  5 17:07:32 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 5 Dec 2024 17:07:32 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v4]
In-Reply-To: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
Message-ID: <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>

> Hi,
> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
> Thanks!
> 
> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
> 
> 
> ## Test
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
> test/jdk/java/util/zip/TestCRC32.java
> also run tests found by: `grep -lRi crc32 test/* | grep -v bench`

Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:

  fix flag warning

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22475/files
  - new: https://git.openjdk.org/jdk/pull/22475/files/b6b87943..ceb4a72b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22475&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22475&range=02-03

  Stats: 4 lines in 1 file changed: 3 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22475.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22475/head:pull/22475

PR: https://git.openjdk.org/jdk/pull/22475

From mli at openjdk.org  Thu Dec  5 17:07:34 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 5 Dec 2024 17:07:34 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v3]
In-Reply-To: <dMC7qfg4vGH0ftLlbGiagtHidn3CXD7F0aGIcIrLA2w=.9f9d3770-d479-40ab-86bd-0e0da67aeff4@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <Xj3SrAfW_m1VgfzeexIGeYjIwNo4WdV86LgrrgnEqqY=.e5c7a579-c7df-4e49-8465-6af1d4da6ee4@github.com>
 <XuxbnhQnDlIJFB63Oi8z9GPpxyY1AKODlqWyD9gVLsg=.8301bf81-c673-409b-a4ee-b1b9d70c6248@github.com>
 <dMC7qfg4vGH0ftLlbGiagtHidn3CXD7F0aGIcIrLA2w=.9f9d3770-d479-40ab-86bd-0e0da67aeff4@github.com>
Message-ID: <O26W8pZ3EupCOVZF9yVH4RW3wM8z1gHkoiCn--2Oin0=.57132396-ddec-4f10-99bd-54233ebdf54d@github.com>

On Thu, 5 Dec 2024 15:27:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/vm_version_riscv.cpp line 360:
>> 
>>> 358:   // UseZvbc (depends on RVV).
>>> 359:   if (UseZvbc && !UseRVV) {
>>> 360:     FLAG_SET_DEFAULT(UseZvbc, false);
>> 
>> If Zvbc is picked up via hwprobe and user uses:
>> `java -XX:-UseRVV ...`
>> wouldn't they get the warning forcing them to add -UseZvbc?
>
> I tested:
> 
> qemu-riscv64 -cpu "rv64,v=true,vext_spec=v1.0,zvbc=true" java -XX:-UseRVV -version
> 
> Gives me this warning about zvcb.
> 
> I think if zvcb is default, just turn it off if rvv is off.

Thanks for the suggestion!
It makes sense to me, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1871768650

From aph at openjdk.org  Thu Dec  5 17:22:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 5 Dec 2024 17:22:40 GMT
Subject: RFR: 8337251: C1: Improve Class.isInstance intrinsic [v2]
In-Reply-To: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
References: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
Message-ID: <hsA7VXvmSPMtMVeZEgZ5Tra1kAleCo8EpgRHUSMS9us=.f3d6c081-b1ab-4b92-a743-c67cc03dd4c1@github.com>

> This replaces a runtime call to `Runtime1::is_instance_of()` by a platform-dependent C1 intrinsic.
> 
> This improves overall performance significantly. and it minimizes icache footprint.
> 
> The original commit contains this comment:
> 
> 
>   // TODO could try to substitute this node with an equivalent InstanceOf
>   // if clazz is known to be a constant Class. This will pick up newly found
>   // constants after HIR construction. I'll leave this to a future change.
> 
> 
> 
> However, there's little performance to be gained by restricting this optimization to constant Class instances, and after this this patch, C1 `Class.isInstance()` compares favorably with the current platform-dependent `instanceof` intrinsic.
> 
> It's not strictly necessary for other platforms to implement this optimization.
> 
> Performance:
> 
> Xeon-E5 2430, before and after::
> 
> 
> Benchmark                               Score    Error       Score     Error  Units
> SecondarySupersLookup.testNegative00   11.783 ?  0.491      10.459 ?   0.183  ns/op
> SecondarySupersLookup.testNegative01   11.757 ?  0.127      10.475 ?   0.661  ns/op
> SecondarySupersLookup.testNegative02   11.771 ?  0.700      10.479 ?   0.357  ns/op
> SecondarySupersLookup.testNegative55   23.997 ?  1.816      16.854 ?   1.034  ns/op
> SecondarySupersLookup.testNegative60   29.598 ?  1.326      26.828 ?   0.637  ns/op
> SecondarySupersLookup.testNegative63   74.528 ?  3.157      69.431 ?   0.357  ns/op
> SecondarySupersLookup.testNegative64   75.936 ?  1.805      70.124 ?   0.397  ns/op
> 
> SecondarySupersLookup.testPositive01   15.257 ?  1.179       9.722 ?   0.326  ns/op
> SecondarySupersLookup.testPositive02   15.164 ?  1.383       9.737 ?   0.708  ns/op
> SecondarySupersLookup.testPositive03   15.166 ?  0.934       9.726 ?   0.184  ns/op
> SecondarySupersLookup.testPositive40   20.384 ?  0.530      12.805 ?   0.778  ns/op
> SecondarySupersLookup.testPositive50   15.118 ?  0.140       9.735 ?   0.555  ns/op
> SecondarySupersLookup.testPositive60   20.415 ?  3.083      11.603 ?   0.106  ns/op
> SecondarySupersLookup.testPositive63   65.478 ?  8.484      58.507 ?   2.837  ns/op
> SecondarySupersLookup.testPositive64   75.880 ?  1.047      68.667 ?   1.347  ns/op
> 
> 
> AArch64 (Apple M1)
> 
> 
> Benchmark                              Score   Error   Score   Error  Units
> SecondarySupersLookup.testNegative00   4.139 ? 0.005   2.815 ? 0.014  ns/op
> SecondarySupersLookup.testNegative01   4.071 ? 0.153   2.826 ? 0.291  ns/op
> SecondarySupersLookup.testNegative02   4.089 ? 0.752   2.817 ? 0.028  ns/...

Andrew Haley has updated the pull request incrementally with seven additional commits since the last revision:

 - Windows fix, maybe.
 - Update
 - Update
 - Test fix/
 - Test fix/
 - Fix test failure
 - Reorganize C1 is_instance_of stub handling

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22491/files
  - new: https://git.openjdk.org/jdk/pull/22491/files/ae6e2355..cf55fdd9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22491&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22491&range=00-01

  Stats: 35 lines in 5 files changed: 20 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/22491.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22491/head:pull/22491

PR: https://git.openjdk.org/jdk/pull/22491

From azafari at openjdk.org  Thu Dec  5 17:55:44 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 5 Dec 2024 17:55:44 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <smjKgcMFaWdOoyn6XR9VjzC6nHP1PXQE5ZgHBf3yqF0=.bb68526f-4119-46a7-829f-b311447ecbb9@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <smjKgcMFaWdOoyn6XR9VjzC6nHP1PXQE5ZgHBf3yqF0=.bb68526f-4119-46a7-829f-b311447ecbb9@github.com>
Message-ID: <GwWeDoQxybfDftG4pX_4ewoXvkYmBCsEbFynTjGPHiU=.8cf9f7ef-a5ec-497c-bec5-41bfd9677384@github.com>

On Tue, 3 Dec 2024 12:51:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed nmt tag

test/hotspot/gtest/utilities/test_rbtree.cpp line 313:

> 311:     for (int i = 0; i < size; i++) {
> 312:       int r = os::random() % size;
> 313:       allocations.append(r % size);

`... % size` is already done in previous line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1871855177

From mchung at openjdk.org  Thu Dec  5 17:56:44 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Dec 2024 17:56:44 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url [v5]
In-Reply-To: <pRqo0j2VErcSwhdtYNy7pgvVAJ25vHJC0jrNqpjYnKI=.7e936038-4e55-48af-a327-9c6c9a30eb83@github.com>
References: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>
 <pRqo0j2VErcSwhdtYNy7pgvVAJ25vHJC0jrNqpjYnKI=.7e936038-4e55-48af-a327-9c6c9a30eb83@github.com>
Message-ID: <XTQI5dAZDFklGoG6ZFVwskZmFWr06qrbi_GsE5pKN80=.d3bd9b0c-b0a6-400c-97a9-50a90c1ec8ca@github.com>

On Thu, 5 Dec 2024 03:08:36 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.
>> 
>> The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.
>> 
>> To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adapt review feedback

Need to bump the copyright end year of VersionProps.java.template, plugins.properties and module-info.java

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 262:

> 260: vendor-vm.description=\
> 261: Override the vendor string baked into the build, if any.\n\
> 262: The value of the system property "java.vm.vendor" will be <vendor>.

Suggestion:

Override the vendor VM string baked into the build, if any.\n\
The value of the system property "java.vm.vendor" will be <vendor-vm>.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins.properties line 268:

> 266: \                            Override the vendor string baked into the build,\n\
> 267: \                            if any. The value of the system property\n\
> 268: \                            "java.vm.vendor" will be <vendor>.

Suggestion:

\  --vendor-vm <vendor-vm>\n\
\                            Override the vendor VM string baked into the build,\n\
\                            if any. The value of the system property\n\
\                            "java.vm.vendor" will be <vendor-vm>.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21964#pullrequestreview-2482487949
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1871848891
PR Review Comment: https://git.openjdk.org/jdk/pull/21964#discussion_r1871850330

From azafari at openjdk.org  Thu Dec  5 18:05:43 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 5 Dec 2024 18:05:43 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <smjKgcMFaWdOoyn6XR9VjzC6nHP1PXQE5ZgHBf3yqF0=.bb68526f-4119-46a7-829f-b311447ecbb9@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <smjKgcMFaWdOoyn6XR9VjzC6nHP1PXQE5ZgHBf3yqF0=.bb68526f-4119-46a7-829f-b311447ecbb9@github.com>
Message-ID: <oldmS640a_t3Gyps-qSEr8quIXJWDJE28fO-TyPxgyA=.97497ebe-c1c2-4471-acce-0458c135a5fb@github.com>

On Tue, 3 Dec 2024 12:51:18 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed nmt tag

Thank you for the nice implementation. The code is so neat and clean.
One point I want to bring here is testing the RBTree if it is really balanced or not. This is the main characteristic of the RBTree. It can be done, for example, by a new API as `RBTree.get_max_depth()` which is expected to be $\approx log_2(n)$ if the tree has $n$ nodes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22360#pullrequestreview-2482515114

From coleenp at openjdk.org  Thu Dec  5 18:05:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Dec 2024 18:05:42 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
Message-ID: <pjU8sCwZpMqvCkCO8-PHPrXhOn1aAZbzehwg-DmQPKo=.56ccd733-0c3a-4186-915d-f51b0e069764@github.com>

On Thu, 5 Dec 2024 16:51:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into decode-mode
>  - Recalculate decode mode if OS picks a different encoding.
>  - Only calculate klass-decode-mode in one place.
>  - Missed one. Another good reason to not copy code.
>  - Rename ceil_log2 to log2i_ceil
>  - Merge branch 'master' into decode-mode
>  - Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932
>  - Merge branch 'master' into decode-mode
>  - include formatBuffer.hpp
>  - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

Thanks Thomas for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2521075365

From coleenp at openjdk.org  Thu Dec  5 18:07:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Dec 2024 18:07:38 GMT
Subject: RFR: 8345405: Add JMH showing the regression in 8341649
In-Reply-To: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>
References: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>
Message-ID: <MARa7PUbmDxB4Ij8K00KpRCeSwCc3MNOaKRW9NfehDM=.a02437dd-6e03-42fb-9bfd-3b8475d2f420@github.com>

On Wed, 4 Dec 2024 18:55:23 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> This JMH using MethodHandles shows the regression in 8341649, for example comparing 24-b25, which included the regression to today's head. It was an interaction between the runtime and C2 rather than a change in MethodHandles.
> 
> Here are example results from an Ampere platform:
> jdk-24-b25 before the fix:
> Benchmark                (classes)  (instances)   Mode  Cnt   Score   Error   Units
> MethodHandleStress.work       1000          100  thrpt   20  33.423 ? 7.678  ops/ms
> 
> Today's head with the fix:
> Benchmark                (classes)  (instances)   Mode  Cnt    Score    Error   Units
> MethodHandleStress.work       1000          100  thrpt   20  709.249 ? 50.575  ops/ms

Thank you for adding this test. Looks good to me.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22556#pullrequestreview-2482518334

From coleenp at openjdk.org  Thu Dec  5 19:02:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 5 Dec 2024 19:02:38 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v3]
In-Reply-To: <v8aq2pqsKj8-EseQOpYdcpWsyVws1tLp8oW2x08iWhs=.364af2cf-d1b2-48c9-b1e6-22b7f22754b2@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <Ymd-_08CMI3G5cBDlXgfDrtK4azO3yHdBg8bKLujCPw=.3c234a70-de4b-4f59-9d72-074335bab953@github.com>
 <Mh6uOkHIuZWtzMOFLI6a7Y78CKuCJ-vx7jJrrcuzPpg=.e58ff970-f230-4ea2-befb-188fa207a1a2@github.com>
 <8Ij7YVl_MU3bsJxegwfJbsjFKsTpYUxQV2s_tjMJlyk=.3255f01d-3d57-47aa-89b9-51c3fd620154@github.com>
 <IwhPt_WFfVe1Qpxy6GwK66zuGK9cVErf7Qguoo0kC0c=.0172b297-d922-4801-ab8b-a34d9d5ee7da@github.com>
 <CIaz-g_AJv1gmw6j3JLr13FKc50M0rBzi5KI7ihxZ0I=.3cca8a0e-648e-45b5-8df3-ad14affbd9fd@github.com>
 <542KGOQYAEG9N6611xTUJ3DR8YHf6v_2oF496WT_bpY=.c0ef76a7-8306-4ede-84a0-c80d62e5b83a@github.com>
 <dZiNe6a2ntA89b2Cl-zsGcp5UqwrZkQhCdYKvjVm80Q=.089cdc88-4f41-4f44-95e0-3a4f32c2f72c@github.com>
 <v8aq2pqsKj8-EseQOpYdcpWsyVws1tLp8oW2x08iWhs=.364af2cf-d1b2-48c9-b1e6-22b7f22754b2@github.com>
Message-ID: <_ylC_lMP2M8q1HMkCj48POaCzw4FYkjpF4E1x0pluYg=.1d22ced7-739b-49d9-a6f5-4a7b2af09083@github.com>

On Thu, 5 Dec 2024 09:42:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> concurrentHashTable uses the trick of inlining a lot of methods in concurrentHashTable.inline.hpp and concurrentHashTableTasks.inline.hpp that are included in the .cpp callers.  This might work for this also.
>
> FWIW this was a drive by comment and it just surprised me to see everything in the hpp file. I don't know GrowableArray enough to recognise it has a similar approach.

Also one advantage of putting much of the implementation in the .inline.hpp file is that it's easy to see how to use this if only a small number of lines of code are in the hpp file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1871936346

From psandoz at openjdk.org  Thu Dec  5 20:40:41 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 5 Dec 2024 20:40:41 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>
 <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
Message-ID: <5NjY5B87PIM5jIaPEQrlsz8tNPoKU14iNsqyTQwmxA8=.ea336100-b4d0-4d7d-8721-8e9e4efb64b8@github.com>

On Tue, 26 Nov 2024 18:11:59 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java line 870:
>> 
>>> 868:         @Override
>>> 869:         public final Int256Shuffle rearrange(VectorShuffle<Integer> shuffle) {
>>> 870:             return (Int256Shuffle) toBitsVector().rearrange(((Int256Shuffle) shuffle)
>> 
>> I think the cast is redundant for all vector kinds. Similarly the explicit cast is redundant for the integral vectors, perhaps in the template separate out the expressions to avoid it where not needed?
>> 
>> We could also refer to `VSPECIES` directly rather than calling `vspecies()`, same applies in other methods in the concrete vector classes.
>
> The cast is added so that we have the concrete type of the shuffle, the result of `toShuffle` is only `VectorShuffle<Integer>`

Ah i see now, you want to ensure an invocation to the final/concrete method. (The IDE's highlighting of the redundant cast is misleading)

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java line 908:
>> 
>>> 906:         }
>>> 907: 
>>> 908:         private static boolean indicesInRange(int[] indices) {
>> 
>> Since this method is only called from an assert statement in the constructor we could avoid the clever checking that assertions are enabled and the explicit throwing on an AssertionError by using a second expression that produces an error message when the assertion fails : e.g.,
>> 
>>             assert indicesInRange(indices) : outOfBoundsAssertMessage(indices);
>
> Yes you are right, since this method is only called in `assert` I think we can just remove the `assert` trick inside instead.

That's fine too.

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java line 2473:
>> 
>>> 2471:     final <F>
>>> 2472:     VectorShuffle<F> toShuffle(AbstractSpecies<F> dsp, boolean wrap) {
>>> 2473:         assert(dsp.elementSize() == vspecies().elementSize());
>> 
>> Even though we force inline I cannot quite decide if it is better to forego the assert since it unduly increases method size. Regardless it may be useful to place the partial wrapping logic in a separate method, given it is less likely to be used.
>
> You don't have to worry too much about inlining of Vector API methods since it is done during late inlining and we have a pretty huge budget there.

Ok, my comment was motivated by some feedback on the FFM API where IIRC forced inline limits were reached.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1872036603
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1872037914
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1872037711

From liach at openjdk.org  Thu Dec  5 20:44:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 20:44:59 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
 - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

-------------

Changes: https://git.openjdk.org/jdk/pull/22420/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22420&range=01
  Stats: 634 lines in 360 files changed: 2 ins; 555 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22420.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22420/head:pull/22420

PR: https://git.openjdk.org/jdk/pull/22420

From psandoz at openjdk.org  Thu Dec  5 20:50:41 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 5 Dec 2024 20:50:41 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>
 <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
Message-ID: <07FzsRmVOfdZW51Pif18Dsb0gvWjVIfUswT2Eljm4IY=.852007f6-e3bf-492d-b7ad-9330656edd6a@github.com>

On Tue, 26 Nov 2024 18:15:47 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 228:
>> 
>>> 226:         }
>>> 227: 
>>> 228:         AbstractVector<?> iota = vspecies().asIntegral().iota();
>> 
>> I suspect the non-power of two code is more efficient. (Even better if the MUL could be transformed to a shift for power of two values.)
>> 
>> Separately, it makes me wonder if we should revisit the shuffle factories if it is now much more efficient to construct a shuffle from a vector.
>
> `shuffleFromOp` is a slow path op so I don't think it is. Additionally, our vector multiplication is against a scalar, too. So we can optimize it if `step` is a constant.

I incorrectly read `!=` as `==` :-) as that is the more common pattern used in the code base, so i was thinking the power of two code path was using `shuffleFromOp`. Could you invert the check to be more consistent?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1872048156

From mchung at openjdk.org  Thu Dec  5 22:02:40 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Dec 2024 22:02:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

The change looks okay to me except `ParameterAnnotations.java`.   This task is part of JEP 484 and test-only.   It seems good to backport to 24.

test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:

> 641: 
> 642:         Task.Result result = new JavacTask(tb)
> 643:                 .processors(new TestAP())

I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483057967
PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872207964

From liach at openjdk.org  Thu Dec  5 22:29:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 22:29:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
 <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
Message-ID: <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>

On Thu, 5 Dec 2024 21:54:19 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714
>
> test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:
> 
>> 641: 
>> 642:         Task.Result result = new JavacTask(tb)
>> 643:                 .processors(new TestAP())
> 
> I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.

It is required.  If we use the command line and FQN to specify a processor like in the current code without preview, this test fails with some classpath error.

> Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java

>Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.

I should attach the exact error message:


test: testInnerClass
[DIRECT]:
- compiler.err.proc.processor.not.found: ParameterAnnotations$TestAP
- compiler.err.proc.no.explicit.annotation.processing.requested: T$I
2 errors
Exception running test testInnerClass: toolbox.Task$TaskError: Task javac failed: rc=1
toolbox.Task$TaskError: Task javac failed: rc=1
        at toolbox.AbstractTask.checkExit(AbstractTask.java:154)
        at toolbox.JavacTask.run(JavacTask.java:381)
        at toolbox.AbstractTask.run(AbstractTask.java:102)
        at toolbox.JavacTask.run(JavacTask.java:52)
        at toolbox.JavacTask.run(JavacTask.java:321)
        at ParameterAnnotations.doTest(ParameterAnnotations.java:650)
        at ParameterAnnotations.testInnerClass(ParameterAnnotations.java:151)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at toolbox.TestRunner.runTests(TestRunner.java:91)
        at ParameterAnnotations.runTests(ParameterAnnotations.java:82)
        at ParameterAnnotations.main(ParameterAnnotations.java:73)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
        at java.base/java.lang.Thread.run(Thread.java:1447)


Same for all 5 tests in this file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872240998

From liach at openjdk.org  Thu Dec  5 22:39:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 5 Dec 2024 22:39:38 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
 <blFJd96UzcOMH9VRX2YpVsHddN_aI95D5_hD5nC2D9U=.fbe0beea-699c-473a-a53f-268429b94926@github.com>
 <0UU_yVYVqg3FQpCHy7i7hQYidoMigQtXKbTJdNIUMbQ=.d46b4331-cd85-4199-bac3-9b48454e9add@github.com>
Message-ID: <YGI23OMLvPmZm9gfhhWUYJBV33J8XNfmEgNxr_BqDNc=.b0bb0f88-7494-433e-81f7-bddfc90039aa@github.com>

On Thu, 5 Dec 2024 22:26:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java line 643:
>> 
>>> 641: 
>>> 642:         Task.Result result = new JavacTask(tb)
>>> 643:                 .processors(new TestAP())
>> 
>> I assume this fix does not require this change, right?  If so, better to keep the original code and do this cleanup as a separate issue.
>
> It is required.  If we use the command line and FQN to specify a processor like in the current code without preview, this test fails with some classpath error.
> 
>> Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>>Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> I should attach the exact error message:
> 
> 
> test: testInnerClass
> [DIRECT]:
> - compiler.err.proc.processor.not.found: ParameterAnnotations$TestAP
> - compiler.err.proc.no.explicit.annotation.processing.requested: T$I
> 2 errors
> Exception running test testInnerClass: toolbox.Task$TaskError: Task javac failed: rc=1
> toolbox.Task$TaskError: Task javac failed: rc=1
>         at toolbox.AbstractTask.checkExit(AbstractTask.java:154)
>         at toolbox.JavacTask.run(JavacTask.java:381)
>         at toolbox.AbstractTask.run(AbstractTask.java:102)
>         at toolbox.JavacTask.run(JavacTask.java:52)
>         at toolbox.JavacTask.run(JavacTask.java:321)
>         at ParameterAnnotations.doTest(ParameterAnnotations.java:650)
>         at ParameterAnnotations.testInnerClass(ParameterAnnotations.java:151)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at toolbox.TestRunner.runTests(TestRunner.java:91)
>         at ParameterAnnotations.runTests(ParameterAnnotations.java:82)
>         at ParameterAnnotations.main(ParameterAnnotations.java:73)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333)
>         at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> 
> Same for all 5 tests in this file.

Filed https://bugs.openjdk.org/browse/JDK-8345622. There is no similar issues that happen as a conjunction of preview and annotation processing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22420#discussion_r1872252558

From mchung at openjdk.org  Thu Dec  5 23:04:40 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 5 Dec 2024 23:04:40 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <maLFwsbZ7sM2p1lT95sryUOcy-Np0ltOALkqtOi2V14=.50a73592-c116-467e-8b01-de69d690acc4@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Thanks for filing the issue to follow up.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483183112

From lmesnik at openjdk.org  Fri Dec  6 01:35:52 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 6 Dec 2024 01:35:52 GMT
Subject: Integrated: 8345435: Eliminate tier1_compiler_not_xcomp group
In-Reply-To: <Ij9wJgt4dUiHjJcU6PZ3Oz7YtqXGhsBFnOItxKfiGew=.096ff918-f850-445c-821e-52f7af644936@github.com>
References: <Ij9wJgt4dUiHjJcU6PZ3Oz7YtqXGhsBFnOItxKfiGew=.096ff918-f850-445c-821e-52f7af644936@github.com>
Message-ID: <aZUIRDtigKFg1y2KwjyGQj65lc19FIp00k2pm2OpN44=.4ba89c6e-3c93-484c-b77a-308ebe25b43d@github.com>

On Wed, 4 Dec 2024 22:01:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix remove tier1_compiler_not_xcomp group. All profiling tests are marked as non Xcomp and added to tier1.
> 
> Verified that :tier1_compiler_3 contains them and that tier1 passed.

This pull request has now been integrated.

Changeset: aa382844
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa3828447c4cbc1aae32c1b96d0d1831c5fb1cca
Stats:     31 lines in 13 files changed: 14 ins; 8 del; 9 mod

8345435: Eliminate tier1_compiler_not_xcomp group

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/jdk/pull/22563

From kbarrett at openjdk.org  Fri Dec  6 02:55:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Dec 2024 02:55:39 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <1hUKJ4vkHTnO0BWKSmjvK1iwXeGhwCp62iPxT27och4=.7b3d02c8-09fc-4650-8a38-a0240112f190@github.com>

On Mon, 2 Dec 2024 07:36:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

Looks good, except for some const issues.  I'm approving as is if you decide not to
address those in this PR.

src/hotspot/share/runtime/frame.cpp line 1566:

> 1564:  * @returns an invalid frame (i.e. fr.pc() === 0) if the caller cannot be obtained
> 1565:  */
> 1566: frame frame::next_frame(frame fr, Thread* t) {

`frame` is a non-trivial type to copy, so it seems like it would be better to pass it by const-ref rather
than by value.  That might trip over lots of const-correctness issues when accessing it though.  If
pulling that thread looks like an excessive tangle then clean this up as a followup.

src/hotspot/share/utilities/nativeStackPrinter.cpp line 44:

> 42: }
> 43: 
> 44: void NativeStackPrinter::print_stack_from_frame(outputStream* st, frame& fr,

Why is `frame` passed by non-const reference?  This doesn't seem like a function that should be modifying
it?  Though changing this might also run afoul of const-correctness issues when accessing the frame, so
feel free to defer to a followup if that's a problem.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22472#pullrequestreview-2483484677
PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1872487666
PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1872497196

From dholmes at openjdk.org  Fri Dec  6 04:21:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Dec 2024 04:21:37 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <1hUKJ4vkHTnO0BWKSmjvK1iwXeGhwCp62iPxT27och4=.7b3d02c8-09fc-4650-8a38-a0240112f190@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <1hUKJ4vkHTnO0BWKSmjvK1iwXeGhwCp62iPxT27och4=.7b3d02c8-09fc-4650-8a38-a0240112f190@github.com>
Message-ID: <knZNMIR3Y1UszP-x7m2MMGq24_iztY6sl_-Q7J3-W9c=.37284ab0-0776-4946-9cae-0880bfa1b2fd@github.com>

On Fri, 6 Dec 2024 02:39:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
>> 
>> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
>> 
>> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
>> 
>> Testing:
>>  - tiers 1 - 4
>> 
>> Some frame management code was also moved from `VMError` to the `frame` class.
>
> src/hotspot/share/runtime/frame.cpp line 1566:
> 
>> 1564:  * @returns an invalid frame (i.e. fr.pc() === 0) if the caller cannot be obtained
>> 1565:  */
>> 1566: frame frame::next_frame(frame fr, Thread* t) {
> 
> `frame` is a non-trivial type to copy, so it seems like it would be better to pass it by const-ref rather
> than by value.  That might trip over lots of const-correctness issues when accessing it though.  If
> pulling that thread looks like an excessive tangle then clean this up as a followup.

It seems we often pass frames around rather than pointers or references to them, but I don't know why. So I would not want to be changing any existing signatures in case there is some nuance I am not aware of.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1872548335

From dholmes at openjdk.org  Fri Dec  6 04:25:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Dec 2024 04:25:42 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <1hUKJ4vkHTnO0BWKSmjvK1iwXeGhwCp62iPxT27och4=.7b3d02c8-09fc-4650-8a38-a0240112f190@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <1hUKJ4vkHTnO0BWKSmjvK1iwXeGhwCp62iPxT27och4=.7b3d02c8-09fc-4650-8a38-a0240112f190@github.com>
Message-ID: <3NCgyPJqf-3odeDcqGk9EidRsdN7trV4lmJT3q06V7E=.935a1cd7-3784-4819-b55b-20a49e4ca9de@github.com>

On Fri, 6 Dec 2024 02:53:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
>> 
>> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
>> 
>> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
>> 
>> Testing:
>>  - tiers 1 - 4
>> 
>> Some frame management code was also moved from `VMError` to the `frame` class.
>
> Looks good, except for some const issues.  I'm approving as is if you decide not to
> address those in this PR.

Thanks for the review @kimbarrett !

> src/hotspot/share/utilities/nativeStackPrinter.cpp line 44:
> 
>> 42: }
>> 43: 
>> 44: void NativeStackPrinter::print_stack_from_frame(outputStream* st, frame& fr,
> 
> Why is `frame` passed by non-const reference?  This doesn't seem like a function that should be modifying
> it?  Though changing this might also run afoul of const-correctness issues when accessing the frame, so
> feel free to defer to a followup if that's a problem.

I passed by reference here just to avoid adding in an additional level of copying in the new code as I was unsure if an additional copy might have an adverse impact. I never considered applying const and I also suspect it will have a significant flow-on effect if I try.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22472#issuecomment-2522093608
PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1872551599

From dholmes at openjdk.org  Fri Dec  6 06:17:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Dec 2024 06:17:41 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
Message-ID: <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>

On Thu, 5 Dec 2024 09:55:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Though now I am even more confused. For x64 where are the definitions for `float_sign_mask` etc??
>
> x86 (And by extension x64) uses handwritten assembly to implement this, and as such simply doesn't use float_sign_mask and friends: https://github.com/openjdk/jdk/blob/3b7571d37812472a2152f9c8cbfd2a4abdb35016/src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp#L123

Sorry still struggling to understand what os+cpu combinations will cause this code to be compiled. If not ARM64 and not x64 then where are the definitions for things like `float_sign_mask` used by this seemingly shared code?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1872657985

From kbarrett at openjdk.org  Fri Dec  6 06:29:47 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Dec 2024 06:29:47 GMT
Subject: RFR: 8345589: Simplify Windows definition of strtok_r
Message-ID: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>

Please review this change to move the Windows-specific definition of strtok_r
to globalDefinitions_visCPP.hpp.  In addition, the unused S_ISCHR macro is
removed and the S_ISFIFO macro is also moved.

Testing: mach5 tier1

-------------

Commit messages:
 - move definitions

Changes: https://git.openjdk.org/jdk/pull/22597/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22597&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345589
  Stats: 23 lines in 2 files changed: 14 ins; 8 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22597.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22597/head:pull/22597

PR: https://git.openjdk.org/jdk/pull/22597

From kbarrett at openjdk.org  Fri Dec  6 06:33:01 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Dec 2024 06:33:01 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code [v2]
In-Reply-To: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
Message-ID: <l7JdpAZj_vD8ILatSPZTwC2A3taGtny1_JUwx9KrTg4=.00c081e8-db80-4916-ad4e-41caf0b6cb65@github.com>

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in s390 code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into fix-s390-zero-null
 - simple s390 fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22469/files
  - new: https://git.openjdk.org/jdk/pull/22469/files/14501652..dc4985cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22469&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22469&range=00-01

  Stats: 53702 lines in 917 files changed: 43846 ins; 6935 del; 2921 mod
  Patch: https://git.openjdk.org/jdk/pull/22469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22469/head:pull/22469

PR: https://git.openjdk.org/jdk/pull/22469

From kbarrett at openjdk.org  Fri Dec  6 06:33:27 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Dec 2024 06:33:27 GMT
Subject: RFR: 8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc
 code [v2]
In-Reply-To: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
References: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
Message-ID: <cPRkfHs9EZPMZWFsAIttm51cJZyUqy8rxKIX72vv0eI=.730cad53-6ef8-404a-b708-4b59c3d403b9@github.com>

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in ppc code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Removed some unused Address constructors that had a default address argument
> with literal 0 as the default value.  These could have been changed to use
> nullptr as the default value, but since they aren't used...
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into fix-ppc-zero-null
 - Merge branch 'master' into fix-ppc-zero-null
 - simple ppc fixes
 - remove unneeded Address ctors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22466/files
  - new: https://git.openjdk.org/jdk/pull/22466/files/31047fc7..a3941e41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22466&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22466&range=00-01

  Stats: 85531 lines in 1263 files changed: 69427 ins; 11000 del; 5104 mod
  Patch: https://git.openjdk.org/jdk/pull/22466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22466/head:pull/22466

PR: https://git.openjdk.org/jdk/pull/22466

From dholmes at openjdk.org  Fri Dec  6 06:46:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Dec 2024 06:46:36 GMT
Subject: RFR: 8345589: Simplify Windows definition of strtok_r
In-Reply-To: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
References: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
Message-ID: <dzGMW2apkcK9sMbzZnkQdTPUO0NpaoAmGxFSD9t_Kdo=.3d973462-0031-4c37-afc5-2964c470053e@github.com>

On Fri, 6 Dec 2024 06:25:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to move the Windows-specific definition of strtok_r
> to globalDefinitions_visCPP.hpp.  In addition, the unused S_ISCHR macro is
> removed and the S_ISFIFO macro is also moved.
> 
> Testing: mach5 tier1

Looks good.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22597#pullrequestreview-2483774811

From asotona at openjdk.org  Fri Dec  6 07:01:45 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 6 Dec 2024 07:01:45 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <cYKI7KfuddHlzINClbgrqWQuLJPTw5rYBUurMV61Gbg=.a84e6ec5-b489-44be-ad12-65bbb954aab8@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Looks good to me, thanks.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22420#pullrequestreview-2483795644

From rehn at openjdk.org  Fri Dec  6 07:52:39 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 6 Dec 2024 07:52:39 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v4]
In-Reply-To: <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
Message-ID: <ZuFVW7K37Do5bQjJ1qaXnWiCqIC7cfkpNPqSWm-HKsQ=.5a76d75a-e7ac-4d87-909b-7e004a14d51a@github.com>

On Thu, 5 Dec 2024 17:07:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
>> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>> also run tests found by: `grep -lRi crc32 test/* | grep -v bench`
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix flag warning

Thanks for the work, seems fine to me.

-------------

Marked as reviewed by rehn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22475#pullrequestreview-2483894532

From stefank at openjdk.org  Fri Dec  6 07:57:38 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 07:57:38 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <LKMXCt1u5hkWFPmVKA-3N1-xVU8Qtas6Tf2lqJBUvVY=.366d4113-eb03-41fb-bb6f-53d044605f0a@github.com>

On Mon, 2 Dec 2024 07:36:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

Changes requested by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22472#pullrequestreview-2483901630

From stefank at openjdk.org  Fri Dec  6 07:57:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 07:57:39 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <3NCgyPJqf-3odeDcqGk9EidRsdN7trV4lmJT3q06V7E=.935a1cd7-3784-4819-b55b-20a49e4ca9de@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <1hUKJ4vkHTnO0BWKSmjvK1iwXeGhwCp62iPxT27och4=.7b3d02c8-09fc-4650-8a38-a0240112f190@github.com>
 <3NCgyPJqf-3odeDcqGk9EidRsdN7trV4lmJT3q06V7E=.935a1cd7-3784-4819-b55b-20a49e4ca9de@github.com>
Message-ID: <yLgs-Y6UvfUqK_OCVykekDxOBJoILWy6Rinz6HZ-v24=.d4087437-66e4-4a61-8b20-cece9267b359@github.com>

On Fri, 6 Dec 2024 04:23:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/utilities/nativeStackPrinter.cpp line 44:
>> 
>>> 42: }
>>> 43: 
>>> 44: void NativeStackPrinter::print_stack_from_frame(outputStream* st, frame& fr,
>> 
>> Why is `frame` passed by non-const reference?  This doesn't seem like a function that should be modifying
>> it?  Though changing this might also run afoul of const-correctness issues when accessing the frame, so
>> feel free to defer to a followup if that's a problem.
>
> I passed by reference here just to avoid adding in an additional level of copying in the new code as I was unsure if an additional copy might have an adverse impact. I never considered applying const and I also suspect it will have a significant flow-on effect if I try.

Note that the contents in fr is overwritten in this function. All callers of this function must be careful because of that. I vote for fixing it before pushing this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1872747826

From jwaters at openjdk.org  Fri Dec  6 08:03:41 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 6 Dec 2024 08:03:41 GMT
Subject: RFR: 8345589: Simplify Windows definition of strtok_r
In-Reply-To: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
References: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
Message-ID: <5-ubUGlCOdWH4X19N0V1SP36rzpckOC7Tl2oDhJZB50=.14ef42bb-fc0d-40b4-8cc0-5b109e9078ad@github.com>

On Fri, 6 Dec 2024 06:25:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to move the Windows-specific definition of strtok_r
> to globalDefinitions_visCPP.hpp.  In addition, the unused S_ISCHR macro is
> removed and the S_ISFIFO macro is also moved.
> 
> Testing: mach5 tier1

Marked as reviewed by jwaters (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22597#pullrequestreview-2483923797

From jwaters at openjdk.org  Fri Dec  6 08:10:37 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 6 Dec 2024 08:10:37 GMT
Subject: RFR: 8345589: Simplify Windows definition of strtok_r
In-Reply-To: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
References: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
Message-ID: <tJ3nqrhudfg3Xa5RqnBldlTjyezLwD6YLN4XvnbfrZA=.c8145c45-2a37-4a28-9e91-cffece777d74@github.com>

On Fri, 6 Dec 2024 06:25:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to move the Windows-specific definition of strtok_r
> to globalDefinitions_visCPP.hpp.  In addition, the unused S_ISCHR macro is
> removed and the S_ISFIFO macro is also moved.
> 
> Testing: mach5 tier1

This moves it to a place inaccessible to my port, but it's a small change and I can handle it rather easily, so I'm ok with this.

src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 89:

> 87: // under the name strtok_s_l.  Make strtok_r a synonym so we can use that name
> 88: // in shared code.
> 89: const auto strtok_r = strtok_s;

Just 1 question, is strtok_r in this VC definition a function pointer? I don't think I've ever seen code do this before. Also, I think Annex K is C11, not C99

-------------

PR Review: https://git.openjdk.org/jdk/pull/22597#pullrequestreview-2483949516
PR Review Comment: https://git.openjdk.org/jdk/pull/22597#discussion_r1872778245

From jwaters at openjdk.org  Fri Dec  6 08:19:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 6 Dec 2024 08:19:39 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
 <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
Message-ID: <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>

On Fri, 6 Dec 2024 06:14:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> x86 (And by extension x64) uses handwritten assembly to implement this, and as such simply doesn't use float_sign_mask and friends: https://github.com/openjdk/jdk/blob/3b7571d37812472a2152f9c8cbfd2a4abdb35016/src/hotspot/cpu/x86/stubGenerator_x86_64_fmod.cpp#L123
>
> Sorry still struggling to understand what os+cpu combinations will cause this code to be compiled. If not ARM64 and not x64 then where are the definitions for things like `float_sign_mask` used by this seemingly shared code?

float_sign_mask and friends are only used by Windows ARM64, in the workaround for the Windows CRT bug (I do wish we could get rid of it though!). If looked at closely, the workaround that uses float_sign_mask and friends is only compiled when !X86 && _WIN64, which means Windows ARM64. To simplify:

- All x86 platforms, including x64, use handwritten assembly, so doesn't use float_sign_mask and friends
- Windows ARM64 uses float_sign_mask and friends, as it has to use the workaround
- All other platforms simply directly call fmod without using float_sign_mask and friends at all, so there is no definition for those platforms

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1872793460

From mli at openjdk.org  Fri Dec  6 09:10:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 6 Dec 2024 09:10:39 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v4]
In-Reply-To: <ZuFVW7K37Do5bQjJ1qaXnWiCqIC7cfkpNPqSWm-HKsQ=.5a76d75a-e7ac-4d87-909b-7e004a14d51a@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
 <ZuFVW7K37Do5bQjJ1qaXnWiCqIC7cfkpNPqSWm-HKsQ=.5a76d75a-e7ac-4d87-909b-7e004a14d51a@github.com>
Message-ID: <MKnNf8iqQfNo7WIBpVZ_mtDBn3ntpH0Q0Xon3SvpAJE=.a97cce8a-d35a-4b80-885d-c44bae9cba45@github.com>

On Fri, 6 Dec 2024 07:50:17 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Thanks for the work, seems fine to me.

Thank you Robbin!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22475#issuecomment-2522589378

From qamai at openjdk.org  Fri Dec  6 09:16:41 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Dec 2024 09:16:41 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <07FzsRmVOfdZW51Pif18Dsb0gvWjVIfUswT2Eljm4IY=.852007f6-e3bf-492d-b7ad-9330656edd6a@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>
 <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
 <07FzsRmVOfdZW51Pif18Dsb0gvWjVIfUswT2Eljm4IY=.852007f6-e3bf-492d-b7ad-9330656edd6a@github.com>
Message-ID: <2z1gcZ6s7rIbNJvgJkShmTZRx6Qsbjr5iXphL3I7vgw=.a873603a-ab40-40df-b862-c88a44767454@github.com>

On Thu, 5 Dec 2024 20:48:07 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> `shuffleFromOp` is a slow path op so I don't think it is. Additionally, our vector multiplication is against a scalar, too. So we can optimize it if `step` is a constant.
>
> I incorrectly read `!=` as `==` :-) as that is the more common pattern used in the code base, so i was thinking the power of two code path was using `shuffleFromOp`. Could you invert the check to be more consistent?

This piece of code follows the pattern:

    if (uncommonCondition) {
        return uncommonPath();
    }
    // Continue the common path

So I think it is better to keep it as it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1872901230

From stefank at openjdk.org  Fri Dec  6 10:04:16 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 10:04:16 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
Message-ID: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>

I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.

Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

-------------

Commit messages:
 - 8345656: Move os alignment functions out of ReservedSpace

Changes: https://git.openjdk.org/jdk/pull/22600/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22600&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345656
  Stats: 59 lines in 12 files changed: 29 ins; 15 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/22600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22600/head:pull/22600

PR: https://git.openjdk.org/jdk/pull/22600

From stefank at openjdk.org  Fri Dec  6 10:13:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 10:13:12 GMT
Subject: RFR: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
Message-ID: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>

This functions is called after an previous calls to WB_NMTReserveMemory and WB_NMTAttemptReserveMemoryAt, which both already registered an NMT tag. So, explicitly recording an NMT tag for this memory is redundant and slightly confusing.

The HotSpot JVM code does not record NMT tags when committing memory (except in a special case on Windows when mapping file memory).

Tested with tier1-3.

-------------

Commit messages:
 - 8345658: WB_NMTCommitMemory redundantly records an NMT tag

Changes: https://git.openjdk.org/jdk/pull/22601/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22601&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345658
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22601/head:pull/22601

PR: https://git.openjdk.org/jdk/pull/22601

From jwaters at openjdk.org  Fri Dec  6 10:22:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 6 Dec 2024 10:22:38 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <y-2Gg7NnYrhf7eeMGeNjrsphZ0Nwv9n4hth-CMNeD2g=.6119d2bf-3573-4151-a095-b3dfcbf67e63@github.com>

On Mon, 2 Dec 2024 07:36:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

*Cries in merge conflicts galore

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22472#pullrequestreview-2484288095

From jwaters at openjdk.org  Fri Dec  6 10:39:03 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 6 Dec 2024 10:39:03 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v12]
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <AkGNiZr0L2gYN1d6mkuqloY1V4GK-Y-UU03yeTiD79s=.525729d9-46a4-44c4-87be-633d9ce36959@github.com>

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:

 - Merge branch 'openjdk:master' into hotspot
 - fmod_winarm64 in sharedRuntime.cpp
 - fmod_winarm64 in sharedRuntimeRem.cpp
 - fmod_winarm64 in sharedRuntime.hpp
 - Typo in sharedRuntimeRem.cpp
 - Comment in sharedRuntimeRem.cpp
 - Merge branch 'openjdk:master' into hotspot
 - Reintroduce ifdef removed in the nuking of the Windows 32 bit x86 port in sharedRuntimeRem.cpp
 - fmod_win64 in sharedRuntime.cpp
 - Should only declare fmod_win64 on Windows/ARM64 sharedRuntime.hpp
 - ... and 12 more: https://git.openjdk.org/jdk/compare/4f5aa6c0...027d494b

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21627/files
  - new: https://git.openjdk.org/jdk/pull/21627/files/37e0e4d7..027d494b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=10-11

  Stats: 121630 lines in 1840 files changed: 90091 ins; 23082 del; 8457 mod
  Patch: https://git.openjdk.org/jdk/pull/21627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627

PR: https://git.openjdk.org/jdk/pull/21627

From jwaters at openjdk.org  Fri Dec  6 10:42:22 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 6 Dec 2024 10:42:22 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v13]
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <xx0dVb0s9QbJ5EC2Gpkys3AdqlbaeCh55DJT-KpzQGg=.b84d92f8-1a8c-4c48-8b39-b9f9204694bd@github.com>

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  CAST_FROM_FN_PTR in os_windows.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21627/files
  - new: https://git.openjdk.org/jdk/pull/21627/files/027d494b..54930315

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627

PR: https://git.openjdk.org/jdk/pull/21627

From fbredberg at openjdk.org  Fri Dec  6 10:55:41 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 6 Dec 2024 10:55:41 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <9kPe9D6lUjHUwm66KHkeaYK5P3ao0wCuENPlcZYJRmw=.570c7b40-e617-4cdc-97a5-cc49ba287412@github.com>

On Mon, 2 Dec 2024 07:36:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

src/hotspot/share/runtime/frame.cpp line 1566:

> 1564:  * @returns an invalid frame (i.e. fr.pc() === 0) if the caller cannot be obtained
> 1565:  */
> 1566: frame frame::next_frame(frame fr, Thread* t) {

I think `next_frame` is a bit ambiguous, like are we talking next up, or next down the stack?
I'm no fan of the Smalltalkish sender notation, so I don't want that. But since the comment says "gets the caller frame", why not call it `get_caller_frame`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1873048197

From stefank at openjdk.org  Fri Dec  6 11:08:11 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 11:08:11 GMT
Subject: RFR: 8345661: Simplify page size alignment in code heap reservation
Message-ID: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>

While working on a prototype to clean up ReservedSpace ([JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) I noticed that the code that reserves the code heap first aligns the committed memory size towards small pages and then aligns it against the page size that was set up for the ReservedSpace. I suggest that just align to the latter immediately.

I also inlined the one usage of `os::vm_allocation_granularity`.

Testing tier1-3

-------------

Commit messages:
 - 8345661: Simplify page size alignment in code heap reservation

Changes: https://git.openjdk.org/jdk/pull/22604/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22604&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345661
  Stats: 10 lines in 2 files changed: 1 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22604.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22604/head:pull/22604

PR: https://git.openjdk.org/jdk/pull/22604

From mli at openjdk.org  Fri Dec  6 11:45:10 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 6 Dec 2024 11:45:10 GMT
Subject: RFR: 8345669: RISC-V: fix client build failure due to AlignVector
 after JDK-8343827
Message-ID: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>

Hi,
Can you help to review this simple fix?
Thanks!

Previously in JDK-8343827, AlignVector was enabled conditionally, but the code was put in common path (shared with non-C2 code), but in fact this flag is only for C2.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/22605/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22605&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345669
  Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22605.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22605/head:pull/22605

PR: https://git.openjdk.org/jdk/pull/22605

From qamai at openjdk.org  Fri Dec  6 12:07:52 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Dec 2024 12:07:52 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v5]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <40Uaer7ZKwGk5kOiEnHSYlyJy74QRzciHspy5CKfM54=.8c37f555-ac4a-4811-bdff-4e4d459f984a@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into shufflerefactor
 - fix asserts
 - whitespace
 - Merge branch 'master' into shufflerefactor
 - [vectorapi] Refactor VectorShuffle implementation

-------------

Changes: https://git.openjdk.org/jdk/pull/21042/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=04
  Stats: 4919 lines in 64 files changed: 2609 ins; 1066 del; 1244 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

PR: https://git.openjdk.org/jdk/pull/21042

From mli at openjdk.org  Fri Dec  6 12:48:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 6 Dec 2024 12:48:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <Uo29WtdvnfdxbPs5XiW-SAL89N9t1HjhwX-bVgMKDT4=.13c071fb-59f8-4027-90ee-4820242fa557@github.com>

On Thu, 5 Dec 2024 11:49:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

Nice tests, Thanks!
The code looks good, just some minor comments about the name.

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 279:

> 277:   int num_threads = 4;
> 278:   CmpxchgTester<TESTSIZE, ASMSIZE> cmpxchg(0, false); // variant 0, not bool ret
> 279:   auto incThread = [&](Thread* _current, int _id) {

By checking the test framework code, seems passed-in `_id` starts from `0` for the first thread in thread group and increment `1` for every other thread?
It might be good have some comment here to state it explicitly to help read the code in the future.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22574#pullrequestreview-2484741825
PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1873277720

From mli at openjdk.org  Fri Dec  6 12:48:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 6 Dec 2024 12:48:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <Uo29WtdvnfdxbPs5XiW-SAL89N9t1HjhwX-bVgMKDT4=.13c071fb-59f8-4027-90ee-4820242fa557@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Uo29WtdvnfdxbPs5XiW-SAL89N9t1HjhwX-bVgMKDT4=.13c071fb-59f8-4027-90ee-4820242fa557@github.com>
Message-ID: <X6lQIqCwWusjPKxi9ltWduHYY4MErAUgL4yo1gLLT1g=.efa26ffe-e24d-4cde-bd85-1189bd7e30f1@github.com>

On Fri, 6 Dec 2024 12:44:29 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 279:
> 
>> 277:   int num_threads = 4;
>> 278:   CmpxchgTester<TESTSIZE, ASMSIZE> cmpxchg(0, false); // variant 0, not bool ret
>> 279:   auto incThread = [&](Thread* _current, int _id) {
> 
> By checking the test framework code, seems passed-in `_id` starts from `0` for the first thread in thread group and increment `1` for every other thread?
> It might be good have some comment here to state it explicitly to help read the code in the future.

And same for other `_id`s below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1873278824

From rehn at openjdk.org  Fri Dec  6 12:52:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 6 Dec 2024 12:52:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <X6lQIqCwWusjPKxi9ltWduHYY4MErAUgL4yo1gLLT1g=.efa26ffe-e24d-4cde-bd85-1189bd7e30f1@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Uo29WtdvnfdxbPs5XiW-SAL89N9t1HjhwX-bVgMKDT4=.13c071fb-59f8-4027-90ee-4820242fa557@github.com>
 <X6lQIqCwWusjPKxi9ltWduHYY4MErAUgL4yo1gLLT1g=.efa26ffe-e24d-4cde-bd85-1189bd7e30f1@github.com>
Message-ID: <kCG7GmUkybmbxbCXaZU8A5BTPMjO1IZntJiyQr9SdTo=.6ab71a9b-6f8f-42d8-a443-86e9b50067fb@github.com>

On Fri, 6 Dec 2024 12:45:35 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 279:
>> 
>>> 277:   int num_threads = 4;
>>> 278:   CmpxchgTester<TESTSIZE, ASMSIZE> cmpxchg(0, false); // variant 0, not bool ret
>>> 279:   auto incThread = [&](Thread* _current, int _id) {
>> 
>> By checking the test framework code, seems passed-in `_id` starts from `0` for the first thread in thread group and increment `1` for every other thread?
>> It might be good have some comment here to state it explicitly to help read the code in the future.
>
> And same for other `_id`s below.

Yes, sure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1873285327

From dholmes at openjdk.org  Fri Dec  6 13:08:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Dec 2024 13:08:40 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <yLgs-Y6UvfUqK_OCVykekDxOBJoILWy6Rinz6HZ-v24=.d4087437-66e4-4a61-8b20-cece9267b359@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <1hUKJ4vkHTnO0BWKSmjvK1iwXeGhwCp62iPxT27och4=.7b3d02c8-09fc-4650-8a38-a0240112f190@github.com>
 <3NCgyPJqf-3odeDcqGk9EidRsdN7trV4lmJT3q06V7E=.935a1cd7-3784-4819-b55b-20a49e4ca9de@github.com>
 <yLgs-Y6UvfUqK_OCVykekDxOBJoILWy6Rinz6HZ-v24=.d4087437-66e4-4a61-8b20-cece9267b359@github.com>
Message-ID: <NndcECWcU6m5QL4CQS_svbrmFEBEWyVICxVEt-Jfn6I=.2571ec6d-c46d-4bb1-9dde-14b9b4e79cae@github.com>

On Fri, 6 Dec 2024 07:54:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I passed by reference here just to avoid adding in an additional level of copying in the new code as I was unsure if an additional copy might have an adverse impact. I never considered applying const and I also suspect it will have a significant flow-on effect if I try.
>
> Note that the contents in fr is overwritten in this function. All callers of this function must be careful because of that. I vote for fixing it before pushing this.

@stefank - yes you are right. I think I introduced the reference in an earlier version of the code to avoid introducing an intermediary frame object, but as it stands the frame is passed in directly whereas the original code made a copy. I will fix it. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1873307215

From dholmes at openjdk.org  Fri Dec  6 13:15:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Dec 2024 13:15:38 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <y-2Gg7NnYrhf7eeMGeNjrsphZ0Nwv9n4hth-CMNeD2g=.6119d2bf-3573-4151-a095-b3dfcbf67e63@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <y-2Gg7NnYrhf7eeMGeNjrsphZ0Nwv9n4hth-CMNeD2g=.6119d2bf-3573-4151-a095-b3dfcbf67e63@github.com>
Message-ID: <wZyfYMnIqBxKrPuSbvXwte7jotbzWUfLpj3llUZy3-w=.9dace09c-79b7-436f-a982-74e7ac918b6b@github.com>

On Fri, 6 Dec 2024 10:20:14 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> *Cries in merge conflicts galore

??? Sorry that was too cryptic for me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22472#issuecomment-2523229903

From dholmes at openjdk.org  Fri Dec  6 13:15:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 6 Dec 2024 13:15:39 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <9kPe9D6lUjHUwm66KHkeaYK5P3ao0wCuENPlcZYJRmw=.570c7b40-e617-4cdc-97a5-cc49ba287412@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <9kPe9D6lUjHUwm66KHkeaYK5P3ao0wCuENPlcZYJRmw=.570c7b40-e617-4cdc-97a5-cc49ba287412@github.com>
Message-ID: <ZPjiprVgvhEOncz5boSxExs0QE3qFaVCGf9-tb_fO9Y=.5c62c6cd-cd1b-4ca5-96c8-a5381c582dd0@github.com>

On Fri, 6 Dec 2024 10:52:48 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
>> 
>> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
>> 
>> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
>> 
>> Testing:
>>  - tiers 1 - 4
>> 
>> Some frame management code was also moved from `VMError` to the `frame` class.
>
> src/hotspot/share/runtime/frame.cpp line 1566:
> 
>> 1564:  * @returns an invalid frame (i.e. fr.pc() === 0) if the caller cannot be obtained
>> 1565:  */
>> 1566: frame frame::next_frame(frame fr, Thread* t) {
> 
> I think `next_frame` is a bit ambiguous, like are we talking next up, or next down the stack?
> I'm no fan of the Smalltalkish sender notation, so I don't want that. But since the comment says "gets the caller frame", why not call it `get_caller_frame`?

@fbredber  thanks for looking at this. I'm not trying to change anything here, all I did was move the code from VMError into frame. Terminology gets complex with frames and we already have the notion of "sender" rather than caller in this code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1873313979

From azafari at openjdk.org  Fri Dec  6 13:20:37 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 6 Dec 2024 13:20:37 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <K6PpmxV6vsLOp2_oO04hptICBFWBdKPFzRrObBxDjAE=.e187d8a7-2221-4514-a243-c84fd8f4583b@github.com>

On Fri, 6 Dec 2024 09:58:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

Thanks for cleaning up the Reserved Space stuff. I found that Copyright years are not up-to-date for these files:

gc/g1/g1CardTable.cpp
gc/g1/g1CardTable.hpp
gc/shared/markBitMap.cpp
gc/shenandoah/shenandoahMarkBitMap.cpp

-------------

PR Review: https://git.openjdk.org/jdk/pull/22600#pullrequestreview-2484821614

From coleenp at openjdk.org  Fri Dec  6 14:10:46 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Dec 2024 14:10:46 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
Message-ID: <NyrRTVpieppOelRqOcaOI642VXRL38gCmQuofdjaqp4=.0eca2df1-956f-4f09-98ca-c10a3d278a51@github.com>

On Thu, 5 Dec 2024 16:51:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into decode-mode
>  - Recalculate decode mode if OS picks a different encoding.
>  - Only calculate klass-decode-mode in one place.
>  - Missed one. Another good reason to not copy code.
>  - Rename ceil_log2 to log2i_ceil
>  - Merge branch 'master' into decode-mode
>  - Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932
>  - Merge branch 'master' into decode-mode
>  - include formatBuffer.hpp
>  - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

@adinn  Can you review this too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2523330642

From liach at openjdk.org  Fri Dec  6 14:27:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 14:27:46 GMT
Subject: Integrated: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714
In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
Message-ID: <lC5dc_Tdirtuqzeo_Owzx7FAERGLPn3zxVToCnmFrVc=.37555c56-eae5-4674-812f-cf8c4c666c16@github.com>

On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
> 
> To reviewers, there are some redundant changes and notes:
> 
> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>   - `BoundAttribute::payloadLen` for javac attribute tests
>   - Annotation reading/writing for javac annotation tests
> - Line number changes to:
>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>   - test/langtools/tools/javac/NoStringToLower.java and 
>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
> 
>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
> 
> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.

This pull request has now been integrated.

Changeset: 49664195
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/496641955041c5e48359e6256a4a61812653d900
Stats:     634 lines in 360 files changed: 2 ins; 555 del; 77 mod

8334733: Remove obsolete @enablePreview from tests after JDK-8334714

Reviewed-by: mchung, asotona

-------------

PR: https://git.openjdk.org/jdk/pull/22420

From liach at openjdk.org  Fri Dec  6 14:27:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 14:27:45 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <NFMYqK-YAR0M4ogdKPBJCDErb0InxSmKB1-4xAwM4m4=.b208051b-f553-41e3-b365-6fe0b48f4e68@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2523362333

From stefank at openjdk.org  Fri Dec  6 14:54:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 14:54:13 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22600/files
  - new: https://git.openjdk.org/jdk/pull/22600/files/326f32f7..2da8bade

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22600&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22600&range=00-01

  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22600/head:pull/22600

PR: https://git.openjdk.org/jdk/pull/22600

From stefank at openjdk.org  Fri Dec  6 14:54:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 14:54:13 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <K6PpmxV6vsLOp2_oO04hptICBFWBdKPFzRrObBxDjAE=.e187d8a7-2221-4514-a243-c84fd8f4583b@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <K6PpmxV6vsLOp2_oO04hptICBFWBdKPFzRrObBxDjAE=.e187d8a7-2221-4514-a243-c84fd8f4583b@github.com>
Message-ID: <sGff5lGLIdIpzYLS11fXJzjEnPtfLt9RiR1XbbuLWLU=.3a972edb-7a8c-4d49-a80f-783310528b6a@github.com>

On Fri, 6 Dec 2024 13:17:44 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright
>
> Thanks for cleaning up the Reserved Space stuff. I found that Copyright years are not up-to-date for these files:
> 
> gc/g1/g1CardTable.cpp
> gc/g1/g1CardTable.hpp
> gc/shared/markBitMap.cpp
> gc/shenandoah/shenandoahMarkBitMap.cpp

Thanks @afshin-zafari for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22600#issuecomment-2523420791

From liach at openjdk.org  Fri Dec  6 15:08:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 15:08:47 GMT
Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714 [v2]
In-Reply-To: <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com>
 <K1wkrQxNtVranKTRTU1gbdxQ9u9VpJhYBHwr1c6HlTI=.4244232a-7468-4b26-a888-7adee835f325@github.com>
Message-ID: <UbEObYZrmrSyDOgIKSYDiGuI4DJ5xs-oooevsmtRw3Q=.e2fbe36e-0d43-4ab1-9044-2a203019ffaa@github.com>

On Thu, 5 Dec 2024 20:44:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests.  The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself.  Now there is fewer than 100 `@enablePreview` in the `test` directory.
>> 
>> To reviewers, there are some redundant changes and notes:
>> 
>> - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API.
>> - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are:
>>   - `BoundAttribute::payloadLen` for javac attribute tests
>>   - Annotation reading/writing for javac annotation tests
>> - Line number changes to:
>>   - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java
>>   - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java
>> - Move from legacy jdk.internal.classfile to java.lang.classfile in:
>>   - test/langtools/tools/javac/NoStringToLower.java and 
>>   - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java
>> - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java
>> 
>>   - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview.
>> 
>> Testing: tier 1-5.  Please inform me if any of these tests belong to higher tiers.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/cf-preview
>  - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714

>From internal discussion, this task is logically associated with the finalization of ClassFile API and is best done for the same release 24.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2523450991

From liach at openjdk.org  Fri Dec  6 15:17:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 6 Dec 2024 15:17:26 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests after
 JDK-8334714
Message-ID: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>

Hi all,

This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.

The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.

Thanks!

-------------

Commit messages:
 - Backport 496641955041c5e48359e6256a4a61812653d900

Changes: https://git.openjdk.org/jdk/pull/22607/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22607&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8334733
  Stats: 634 lines in 360 files changed: 2 ins; 555 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22607/head:pull/22607

PR: https://git.openjdk.org/jdk/pull/22607

From psandoz at openjdk.org  Fri Dec  6 16:18:47 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Dec 2024 16:18:47 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <2z1gcZ6s7rIbNJvgJkShmTZRx6Qsbjr5iXphL3I7vgw=.a873603a-ab40-40df-b862-c88a44767454@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>
 <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
 <07FzsRmVOfdZW51Pif18Dsb0gvWjVIfUswT2Eljm4IY=.852007f6-e3bf-492d-b7ad-9330656edd6a@github.com>
 <2z1gcZ6s7rIbNJvgJkShmTZRx6Qsbjr5iXphL3I7vgw=.a873603a-ab40-40df-b862-c88a44767454@github.com>
Message-ID: <SS_KQBG8aRlYPSiKLMS_IjjPKISJTDOhwj8IZl2umIc=.4b72eb3e-6723-44c0-86d7-4681ba44b4ff@github.com>

On Fri, 6 Dec 2024 09:14:07 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> I incorrectly read `!=` as `==` :-) as that is the more common pattern used in the code base, so i was thinking the power of two code path was using `shuffleFromOp`. Could you invert the check to be more consistent?
>
> This piece of code follows the pattern:
> 
>     if (uncommonCondition) {
>         return uncommonPath();
>     }
>     // Continue the common path
> 
> So I think it is better to keep it as it is.

Ok, but since it deviates from the pattern applied in other areas for POT checks and caught me out would you mind adding a comment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1873634643

From psandoz at openjdk.org  Fri Dec  6 16:23:40 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Dec 2024 16:23:40 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <5NjY5B87PIM5jIaPEQrlsz8tNPoKU14iNsqyTQwmxA8=.ea336100-b4d0-4d7d-8721-8e9e4efb64b8@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>
 <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
 <5NjY5B87PIM5jIaPEQrlsz8tNPoKU14iNsqyTQwmxA8=.ea336100-b4d0-4d7d-8721-8e9e4efb64b8@github.com>
Message-ID: <75oGPIIsnaNawGwF2IPmHoXf6YsP_E1QbhDwOkDjplU=.bd3b14a2-72fe-45c4-b932-3d1c6972f432@github.com>

On Thu, 5 Dec 2024 20:36:48 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> The cast is added so that we have the concrete type of the shuffle, the result of `toShuffle` is only `VectorShuffle<Integer>`
>
> Ah i see now, you want to ensure an invocation to the final/concrete method. (The IDE's highlighting of the redundant cast is misleading)

The common way we tend to do this in other areas is assign to a local variable with the sharper type. This makes it a littler clearer on the intent. Could you do that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1873652324

From duke at openjdk.org  Fri Dec  6 16:32:49 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 6 Dec 2024 16:32:49 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
Message-ID: <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>

On Mon, 2 Dec 2024 15:27:39 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>>  - Adding a runtime flag for selecting the old or new version can be added later.
>>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   a missed change in a shenandoah file.

Hi @afshin-zafari I left a few more comments and questions. Thanks!

src/hotspot/share/nmt/regionsTree.hpp line 57:

> 55:       inline void clear_node() { _node = nullptr; }
> 56:       inline VMATree::position position() { return _node->key(); }
> 57:       inline bool is_committed_begin() { return ((uint8_t)out_state() & (uint8_t)VMATree::StateType::Committed) >= 2; }

This allows a region to be committed but not reserved?

src/hotspot/share/nmt/regionsTree.hpp line 94:

> 92:   template<typename F>
> 93:   void visit_committed_regions(position start, size_t size, F func) {
> 94:     size_t end = start + size + 1;

> Yes it is missed.
In the visit_range_in_order code, the variable cmp_to is never checked against 0 (cmp_to == 0).

You are referring to [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/nmt/nmtTreap.hpp#L380) right? I think that is actually ok without the +1. The upper boundary, "end", is outside of the range of the region, so probably should not be checked. For example if the region's starting address is 0 and has a size of 10, the last address within the region is 9. "End" in this case is 10 (0+10), and is out of bounds. If we made "end" = 0 + 10 + 1 = 11, then we would be including 10 in the checked range, which isn't right.

src/hotspot/share/nmt/regionsTree.hpp line 105:

> 103:         if (prev.is_committed_begin()) {
> 104:           comm_size += curr.distance_from(prev);
> 105:           if (!curr.is_committed_begin()) {

Shouldn't it be impossible to have 2 back-to-back committed regions? Wouldn't they already be coalesced by `VMATree::register_mapping`?

src/hotspot/share/nmt/regionsTree.hpp line 135:

> 133:       }
> 134:       prev = curr;
> 135:       if (curr.is_released_begin() || begin_node.out_tag() != curr.out_tag()) {

It looks like you are running `func(ReservedMemoryRegion)` on partial reserved memory regions, so long as `begin_node.out_tag() != curr.out_tag()`. For example you may run `func(ReservedMemoryRegion)` on a slice of a reserved region, or a single committed region. Isn't the intention to instead find where each whole reserved region starts and ends, then run  `func(ReservedMemoryRegion)` on the entire reserved region?

src/hotspot/share/nmt/regionsTree.hpp line 137:

> 135:       if (curr.is_released_begin() || begin_node.out_tag() != curr.out_tag()) {
> 136:         auto st = stack(curr);
> 137:         size_t r_size = curr.distance_from(begin_node);

Why is `r_size` never used?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2483028458
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1872189753
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1873544134
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1873390207
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1873539712
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1873510959

From qamai at openjdk.org  Fri Dec  6 17:00:15 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Dec 2024 17:00:15 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v6]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <6YeHbHlrPoV9obcfC7g1PtFdMKfanhnsKxqwTZovts4=.f5743961-07e2-4325-b8f5-270edd342e11@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  add comment, extract cast into local variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21042/files
  - new: https://git.openjdk.org/jdk/pull/21042/files/c851d133..a2f59007

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=04-05

  Stats: 68 lines in 32 files changed: 6 ins; 0 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

PR: https://git.openjdk.org/jdk/pull/21042

From qamai at openjdk.org  Fri Dec  6 17:00:15 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Dec 2024 17:00:15 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <SS_KQBG8aRlYPSiKLMS_IjjPKISJTDOhwj8IZl2umIc=.4b72eb3e-6723-44c0-86d7-4681ba44b4ff@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>
 <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
 <07FzsRmVOfdZW51Pif18Dsb0gvWjVIfUswT2Eljm4IY=.852007f6-e3bf-492d-b7ad-9330656edd6a@github.com>
 <2z1gcZ6s7rIbNJvgJkShmTZRx6Qsbjr5iXphL3I7vgw=.a873603a-ab40-40df-b862-c88a44767454@github.com>
 <SS_KQBG8aRlYPSiKLMS_IjjPKISJTDOhwj8IZl2umIc=.4b72eb3e-6723-44c0-86d7-4681ba44b4ff@github.com>
Message-ID: <D6lHwKhDXaUKX8j6QcJSWTcq8mXNFeW4MZX3_WzRXws=.b9b7bf15-9e58-4b12-9d09-d718b775304e@github.com>

On Fri, 6 Dec 2024 16:16:04 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This piece of code follows the pattern:
>> 
>>     if (uncommonCondition) {
>>         return uncommonPath();
>>     }
>>     // Continue the common path
>> 
>> So I think it is better to keep it as it is.
>
> Ok, but since it deviates from the pattern applied in other areas for POT checks and caught me out would you mind adding a comment?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1873698256

From qamai at openjdk.org  Fri Dec  6 17:00:15 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Dec 2024 17:00:15 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <75oGPIIsnaNawGwF2IPmHoXf6YsP_E1QbhDwOkDjplU=.bd3b14a2-72fe-45c4-b932-3d1c6972f432@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <xrUobkYtIXWjYCX6G_dUXK_KkYR8eIwwuA7gj7KJbKs=.e3bd2d08-e7f9-44c7-969c-213ca79eefb6@github.com>
 <DT0F2VBDtqqUE2CRdK-lANKtNOEQLdqzfO6-9DFgXg0=.392bb7d9-0b69-452b-a0fc-4e469914a611@github.com>
 <5NjY5B87PIM5jIaPEQrlsz8tNPoKU14iNsqyTQwmxA8=.ea336100-b4d0-4d7d-8721-8e9e4efb64b8@github.com>
 <75oGPIIsnaNawGwF2IPmHoXf6YsP_E1QbhDwOkDjplU=.bd3b14a2-72fe-45c4-b932-3d1c6972f432@github.com>
Message-ID: <L9jOS5aQgwpfDjkDLIVj9K0FECNfdURbm_iOmj4865w=.cdd51ced-9f2d-4b45-b350-e616478d02ab@github.com>

On Fri, 6 Dec 2024 16:20:55 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Ah i see now, you want to ensure an invocation to the final/concrete method. (The IDE's highlighting of the redundant cast is misleading)
>
> The common way we tend to do this in other areas is assign to a local variable with the sharper type. This makes it a littler clearer on the intent. Could you do that?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1873698414

From kim.barrett at oracle.com  Fri Dec  6 17:16:22 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Fri, 6 Dec 2024 12:16:22 -0500
Subject: RFR: 8345589: Simplify Windows definition of strtok_r
In-Reply-To: <tJ3nqrhudfg3Xa5RqnBldlTjyezLwD6YLN4XvnbfrZA=.c8145c45-2a37-4a28-9e91-cffece777d74@github.com>
References: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
 <tJ3nqrhudfg3Xa5RqnBldlTjyezLwD6YLN4XvnbfrZA=.c8145c45-2a37-4a28-9e91-cffece777d74@github.com>
Message-ID: <e9d05459-0087-4a22-81f9-4aff91bbce63@oracle.com>

On 12/6/24 3:10 AM, Julian Waters wrote:
> On Fri, 6 Dec 2024 06:25:12 GMT, Kim Barrett<kbarrett at openjdk.org> wrote:
>
>> Please review this change to move the Windows-specific definition of strtok_r
>> to globalDefinitions_visCPP.hpp.  In addition, the unused S_ISCHR macro is
>> removed and the S_ISFIFO macro is also moved.
>>
>> Testing: mach5 tier1
> This moves it to a place inaccessible to my port, but it's a small change and I can handle it rather easily, so I'm ok with this.

I suspected that might happen.? But this new location seems like a 
better place for it than where it was.

I'm assuming you're going to have some non-trivial rearrangement of 
things in the globalDefinitions vicinity.

> src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 89:
>
>> 87: // under the name strtok_s_l.  Make strtok_r a synonym so we can use that name
>> 88: // in shared code.
>> 89: const auto strtok_r = strtok_s;
> Just 1 question, is strtok_r in this VC definition a function pointer?
Yes.
>   I don't think I've ever seen code do this before. Also, I think Annex K is C11, not C99
Oops. I thought I had C99 open when I was looking at Annex K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241206/64dfe516/attachment-0001.htm>

From psandoz at openjdk.org  Fri Dec  6 17:20:40 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Dec 2024 17:20:40 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v6]
In-Reply-To: <6YeHbHlrPoV9obcfC7g1PtFdMKfanhnsKxqwTZovts4=.f5743961-07e2-4325-b8f5-270edd342e11@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <6YeHbHlrPoV9obcfC7g1PtFdMKfanhnsKxqwTZovts4=.f5743961-07e2-4325-b8f5-270edd342e11@github.com>
Message-ID: <AdPi3hmpMHncptzv1G-7c_OsHxhhgp5QTpq813PSSq0=.f2f6329c-14ee-45db-b472-e5640664c4bf@github.com>

On Fri, 6 Dec 2024 17:00:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment, extract cast into local variable

Java changes look good. Needs a HotSpot review.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2485451835

From psandoz at openjdk.org  Fri Dec  6 17:25:39 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 6 Dec 2024 17:25:39 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <HUxyGfmcjDzyr34iIP6-SopdTFEKrUA_k2umYczKjK8=.91eec0f2-1a99-4a98-bb57-a8d77670eec5@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>
 <eRnXECROJ99v9esircLUm1e8qhm71sJDHEWaR3dgbTo=.8e13b46c-0e57-4fcc-be9c-45b9daef12a3@github.com>
 <HUxyGfmcjDzyr34iIP6-SopdTFEKrUA_k2umYczKjK8=.91eec0f2-1a99-4a98-bb57-a8d77670eec5@github.com>
Message-ID: <R_wVwvHqD5kN17FnPKrPQo6LbmwTvUOHpQkHeUxg8_I=.2c2dc56d-e8d4-4cc8-9ce7-2b36953841d5@github.com>

On Tue, 26 Nov 2024 18:17:05 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> @merykitty Could you please merge with the latest and resolve conflicts?
>
> @sviswa7 @PaulSandoz @eme64 @jatin-bhateja Thanks for taking a look, I have merged the PR with a more recent master and resolved the sematic difference with newly added intrinsics, too.

@merykitty do you want me to initiate tier 1 to 3 tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2523785970

From ecaspole at openjdk.org  Fri Dec  6 17:37:03 2024
From: ecaspole at openjdk.org (Eric Caspole)
Date: Fri, 6 Dec 2024 17:37:03 GMT
Subject: RFR: 8345405: Add JMH showing the regression in 8341649 [v2]
In-Reply-To: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>
References: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>
Message-ID: <HWQ7PXEiZOJEszrgcRSxLdK_oc7aKuxuD2zyirpr6CM=.b09101cc-5f38-4e63-b2d7-8e8660024100@github.com>

> This JMH using MethodHandles shows the regression in 8341649, for example comparing 24-b25, which included the regression to today's head. It was an interaction between the runtime and C2 rather than a change in MethodHandles.
> 
> Here are example results from an Ampere platform:
> jdk-24-b25 before the fix:
> Benchmark                (classes)  (instances)   Mode  Cnt   Score   Error   Units
> MethodHandleStress.work       1000          100  thrpt   20  33.423 ? 7.678  ops/ms
> 
> Today's head with the fix:
> Benchmark                (classes)  (instances)   Mode  Cnt    Score    Error   Units
> MethodHandleStress.work       1000          100  thrpt   20  709.249 ? 50.575  ops/ms

Eric Caspole has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Code cleanups suggested by Claes
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8345405
 - 8345405: Add JMH showing the regression in 8341649

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22556/files
  - new: https://git.openjdk.org/jdk/pull/22556/files/4c7ee932..977d1e8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22556&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22556&range=00-01

  Stats: 6671 lines in 258 files changed: 3254 ins; 2397 del; 1020 mod
  Patch: https://git.openjdk.org/jdk/pull/22556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22556/head:pull/22556

PR: https://git.openjdk.org/jdk/pull/22556

From qamai at openjdk.org  Fri Dec  6 17:37:52 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 6 Dec 2024 17:37:52 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <R_wVwvHqD5kN17FnPKrPQo6LbmwTvUOHpQkHeUxg8_I=.2c2dc56d-e8d4-4cc8-9ce7-2b36953841d5@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>
 <eRnXECROJ99v9esircLUm1e8qhm71sJDHEWaR3dgbTo=.8e13b46c-0e57-4fcc-be9c-45b9daef12a3@github.com>
 <HUxyGfmcjDzyr34iIP6-SopdTFEKrUA_k2umYczKjK8=.91eec0f2-1a99-4a98-bb57-a8d77670eec5@github.com>
 <R_wVwvHqD5kN17FnPKrPQo6LbmwTvUOHpQkHeUxg8_I=.2c2dc56d-e8d4-4cc8-9ce7-2b36953841d5@github.com>
Message-ID: <7todhQ5vEpyMrDa9XkNhJRpZmny4NfgqNgPgY_INZZE=.2e1875cb-9b69-46d2-8790-171caa75b795@github.com>

On Fri, 6 Dec 2024 17:22:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @sviswa7 @PaulSandoz @eme64 @jatin-bhateja Thanks for taking a look, I have merged the PR with a more recent master and resolved the sematic difference with newly added intrinsics, too.
>
> @merykitty do you want me to initiate tier 1 to 3 tests?

@PaulSandoz Yes, please. Thanks a lot for your help.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2523819523

From lmesnik at openjdk.org  Fri Dec  6 18:44:48 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 6 Dec 2024 18:44:48 GMT
Subject: Integrated: 8340969: jdk/jfr/startupargs/TestStartDuration.java should
 be marked as flagless
In-Reply-To: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
References: <EMMkv51fvrvPboatnwUqMUQ1a8FcwjRLiN9qw9ziR2o=.0c65a609-f668-4b6a-afd4-42184cc9452f@github.com>
Message-ID: <rpdIGnWlqfAJdv2_BrwQPt892gv7XHhjqfmEl_Mir_M=.af60a8ee-6baf-4673-b647-f220518e8177@github.com>

On Sat, 28 Sep 2024 01:02:12 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Test jdk/jfr/startupargs/TestStartDuration.java
> checks duration, the time might be too small for stress options like Xcomp.
> So it makes sense to mark it as flaglesss.

This pull request has now been integrated.

Changeset: 470701f0
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/470701f0bb269834cc0e1cb40f7d34e92226454b
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless

Reviewed-by: syan, egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/21237

From lmesnik at openjdk.org  Fri Dec  6 20:19:10 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 6 Dec 2024 20:19:10 GMT
Subject: RFR: 8345700: tier{1,2,3}_compiler doesn't cover all compiler tests
Message-ID: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>

Hi, 
could you please review following fix that update
tier3_compiler test group
so :hotspot_compiler is always a sum of
tier1_compiler, tier2_compiler, tier3_compiler
This is natural splitting of tests into 3 layers. 
The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.

The new group
` tier2_ctw`
was introduced for ctw testing. 
It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.

I moved id from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.

@shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

-------------

Commit messages:
 - 8345700: tier{1,2,3}_compiler doesn't cover all compiler tests

Changes: https://git.openjdk.org/jdk/pull/22614/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22614&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345700
  Stats: 16 lines in 1 file changed: 4 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22614/head:pull/22614

PR: https://git.openjdk.org/jdk/pull/22614

From coleenp at openjdk.org  Fri Dec  6 22:06:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 6 Dec 2024 22:06:11 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
Message-ID: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>

This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.

Tested with jck:vm and tier1-4.

-------------

Commit messages:
 - 8345678: compute_modifiers should not be in create_mirror

Changes: https://git.openjdk.org/jdk/pull/22618/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345678
  Stats: 39 lines in 8 files changed: 19 ins; 16 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22618/head:pull/22618

PR: https://git.openjdk.org/jdk/pull/22618

From kbarrett at openjdk.org  Fri Dec  6 23:33:26 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 6 Dec 2024 23:33:26 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState
Message-ID: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>

Please review this change that introduces two new helper classes to simplify
the usage of PartialArrayStates to manage splitting the processing of large
object arrays into parallelizable chunks.  G1 and Parallel young GCs are
changed to use this new mechanism.

PartialArrayTaskStats is used to collect and report statistics related to
array splitting.  It replaces the direct implementation in PSPromotionManager,
and is now also used by G1 young GCs.

PartialArraySplitter packages up most of the work involved in splitting and
processing tasks. It provides task allocation and release, enqueuing, chunk
claiming, and statistics tracking. It does this by encapsulating existing
objects and functionality. Using array splitting is mostly reduced to calling
the splitter's start function and then calling it's step function to process
partial states. This substantially reduces the amount of code for each client
to perform this work.

Testing: mach5 tier1-5

Manually ran some test programs with each of G1 and Parallel, with taskqueue
stats logging enabled, and checked that the logged statistics looked okay.

-------------

Commit messages:
 - parallel uses PartialArraySplitter
 - g1 uses PartialArraySplitter
 - add PartialArraySplitter
 - add PartialArrayTaskStats

Changes: https://git.openjdk.org/jdk/pull/22622/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22622&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345732
  Stats: 667 lines in 13 files changed: 496 ins; 109 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/22622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22622/head:pull/22622

PR: https://git.openjdk.org/jdk/pull/22622

From vlivanov at openjdk.org  Sat Dec  7 02:08:45 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 7 Dec 2024 02:08:45 GMT
Subject: RFR: 8337251: C1: Improve Class.isInstance intrinsic [v2]
In-Reply-To: <hsA7VXvmSPMtMVeZEgZ5Tra1kAleCo8EpgRHUSMS9us=.f3d6c081-b1ab-4b92-a743-c67cc03dd4c1@github.com>
References: <CGWGE9cbKO5_I-xA652DLz6h9shAx2qlaSEawK3jkSI=.98dcd4a6-c87f-4b01-a1ee-df29e275bba9@github.com>
 <hsA7VXvmSPMtMVeZEgZ5Tra1kAleCo8EpgRHUSMS9us=.f3d6c081-b1ab-4b92-a743-c67cc03dd4c1@github.com>
Message-ID: <ADGO5WDOiH7-zetRRvXnypGz0ReBp8g21aYi0j4eug4=.96bcfb3f-0862-4d15-9a6c-5f96cb3d0adc@github.com>

On Thu, 5 Dec 2024 17:22:40 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This replaces a runtime call to `Runtime1::is_instance_of()` by a platform-dependent C1 intrinsic.
>> 
>> This improves overall performance significantly. and it minimizes icache footprint.
>> 
>> The original commit contains this comment:
>> 
>> 
>>   // TODO could try to substitute this node with an equivalent InstanceOf
>>   // if clazz is known to be a constant Class. This will pick up newly found
>>   // constants after HIR construction. I'll leave this to a future change.
>> 
>> 
>> 
>> However, there's little performance to be gained by restricting this optimization to constant Class instances, and after this this patch, C1 `Class.isInstance()` compares favorably with the current platform-dependent `instanceof` intrinsic.
>> 
>> It's not strictly necessary for other platforms to implement this optimization.
>> 
>> Performance:
>> 
>> Xeon-E5 2430, before and after::
>> 
>> 
>> Benchmark                               Score    Error       Score     Error  Units
>> SecondarySupersLookup.testNegative00   11.783 ?  0.491      10.459 ?   0.183  ns/op
>> SecondarySupersLookup.testNegative01   11.757 ?  0.127      10.475 ?   0.661  ns/op
>> SecondarySupersLookup.testNegative02   11.771 ?  0.700      10.479 ?   0.357  ns/op
>> SecondarySupersLookup.testNegative55   23.997 ?  1.816      16.854 ?   1.034  ns/op
>> SecondarySupersLookup.testNegative60   29.598 ?  1.326      26.828 ?   0.637  ns/op
>> SecondarySupersLookup.testNegative63   74.528 ?  3.157      69.431 ?   0.357  ns/op
>> SecondarySupersLookup.testNegative64   75.936 ?  1.805      70.124 ?   0.397  ns/op
>> 
>> SecondarySupersLookup.testPositive01   15.257 ?  1.179       9.722 ?   0.326  ns/op
>> SecondarySupersLookup.testPositive02   15.164 ?  1.383       9.737 ?   0.708  ns/op
>> SecondarySupersLookup.testPositive03   15.166 ?  0.934       9.726 ?   0.184  ns/op
>> SecondarySupersLookup.testPositive40   20.384 ?  0.530      12.805 ?   0.778  ns/op
>> SecondarySupersLookup.testPositive50   15.118 ?  0.140       9.735 ?   0.555  ns/op
>> SecondarySupersLookup.testPositive60   20.415 ?  3.083      11.603 ?   0.106  ns/op
>> SecondarySupersLookup.testPositive63   65.478 ?  8.484      58.507 ?   2.837  ns/op
>> SecondarySupersLookup.testPositive64   75.880 ?  1.047      68.667 ?   1.347  ns/op
>> 
>> 
>> AArch64 (Apple M1)
>> 
>> 
>> Benchmark                              Score   Error   Score   Error  Units
>> SecondarySupersLookup.testNegative00   4.139 ? 0.005   2.815 ? 0.014  ns/op
>> SecondarySupersLookup.testNegative01   4.071 ? 0.153   ...
>
> Andrew Haley has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Windows fix, maybe.
>  - Update
>  - Update
>  - Test fix/
>  - Test fix/
>  - Fix test failure
>  - Reorganize C1 is_instance_of stub handling

Overall, looks good.

src/hotspot/share/c1/c1_LIRGenerator.cpp line 1247:

> 1245:   }
> 1246: 
> 1247: #ifdef HAVE_PD_C1_IS_INSTANCE_OF_STUB

Is it the first occurrence of optional stub on C1? Alternatively, you could provide a default implementation on all other platforms which simply calls into `Runtime1::is_instance_of`.

Also, the macro doesn't look pretty here. `c1_Defs_*.hpp` promote a different pattern (a constant). I understand that it requires changing all `c1_Defs_*.hpp` files, but it would definitely look cleaner here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22491#pullrequestreview-2486257442
PR Review Comment: https://git.openjdk.org/jdk/pull/22491#discussion_r1874217487

From fyang at openjdk.org  Sat Dec  7 03:01:38 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 7 Dec 2024 03:01:38 GMT
Subject: RFR: 8345669: RISC-V: fix client build failure due to AlignVector
 after JDK-8343827
In-Reply-To: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
References: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
Message-ID: <of-0fm8-0Y6-mSkNvhRDtPWhNAQC9VbmohNJYoqmjQ8=.7f986ed7-5780-47a4-b2fb-9a5554b917fb@github.com>

On Fri, 6 Dec 2024 11:39:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple fix?
> Thanks!
> 
> Previously in JDK-8343827, AlignVector was enabled conditionally, but the code was put in common path (shared with non-C2 code), but in fact this flag is only for C2.

Thanks. Seems this should be fixed for jdk24 as well.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22605#pullrequestreview-2486273069

From lmesnik at openjdk.org  Sat Dec  7 03:40:11 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 7 Dec 2024 03:40:11 GMT
Subject: RFR: 8345746: Remove :resourcehogs/compiler from
 :hotspot_slow_compiler
Message-ID: <FwDCA82Hak0z63SHjmPUUhmWyma3YhzD3V81OWk9wa0=.8c2706f1-e82b-4d55-a009-195852804741@github.com>

The test group
:resourcehogs/compiler
contains tests that should not be executed concurrently with *any* tests.

They might use a lot of resources and cause unexplained sporadic failures of other tests.

So it should be removed from :hotspot_slow_compiler.

-------------

Commit messages:
 - 8345746: Remove :resourcehogs/compiler from :hotspot_slow_compiler

Changes: https://git.openjdk.org/jdk/pull/22626/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22626&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345746
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22626/head:pull/22626

PR: https://git.openjdk.org/jdk/pull/22626

From jwaters at openjdk.org  Sat Dec  7 04:17:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 7 Dec 2024 04:17:48 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code
In-Reply-To: <wZyfYMnIqBxKrPuSbvXwte7jotbzWUfLpj3llUZy3-w=.9dace09c-79b7-436f-a982-74e7ac918b6b@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <y-2Gg7NnYrhf7eeMGeNjrsphZ0Nwv9n4hth-CMNeD2g=.6119d2bf-3573-4151-a095-b3dfcbf67e63@github.com>
 <wZyfYMnIqBxKrPuSbvXwte7jotbzWUfLpj3llUZy3-w=.9dace09c-79b7-436f-a982-74e7ac918b6b@github.com>
Message-ID: <d-PTfEOGtvLyZDzJycSYWFsJa7bIt9MtOHN_rgkySdE=.c9b907cf-8cc4-483f-8652-5cf80e340d77@github.com>

On Fri, 6 Dec 2024 13:12:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > *Cries in merge conflicts galore
> 
> ??? Sorry that was too cryptic for me.

Oh, it was just a joke about how it would conflict with what I do downstream to use print_native_stack instead of the Windows platform_print_native_stack, although I just checked my port and it seems like this change doesn't actually conflict with it :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22472#issuecomment-2524859858

From lmesnik at openjdk.org  Sat Dec  7 04:19:18 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 7 Dec 2024 04:19:18 GMT
Subject: RFR: 8345746: Remove :resourcehogs/compiler from
 :hotspot_slow_compiler [v2]
In-Reply-To: <FwDCA82Hak0z63SHjmPUUhmWyma3YhzD3V81OWk9wa0=.8c2706f1-e82b-4d55-a009-195852804741@github.com>
References: <FwDCA82Hak0z63SHjmPUUhmWyma3YhzD3V81OWk9wa0=.8c2706f1-e82b-4d55-a009-195852804741@github.com>
Message-ID: <Cu_zWGdaVEvyzXlNBQcf8LZvj_Dppvh_Op16O3_DyIk=.c20874f0-149a-417d-ba58-c34bcbfcf32e@github.com>

> The test group
> :resourcehogs/compiler
> contains tests that should not be executed concurrently with *any* tests.
> 
> They might use a lot of resources and cause unexplained sporadic failures of other tests.
> 
> So it should be removed from :hotspot_slow_compiler.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  hogs group added.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22626/files
  - new: https://git.openjdk.org/jdk/pull/22626/files/9c9e3b83..ca3150d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22626&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22626&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22626.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22626/head:pull/22626

PR: https://git.openjdk.org/jdk/pull/22626

From gcao at openjdk.org  Sat Dec  7 07:40:20 2024
From: gcao at openjdk.org (Gui Cao)
Date: Sat, 7 Dec 2024 07:40:20 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v2]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <5y-XC8I1__gYYbf5_PLT5ZRrfrhFANxDfN8vTSBUcis=.b17cb216-bce5-45e7-a9a0-c0c348f32fec@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

-------------

Changes: https://git.openjdk.org/jdk/pull/21922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=01
  Stats: 375 lines in 5 files changed: 300 ins; 23 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/21922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922

PR: https://git.openjdk.org/jdk/pull/21922

From gcao at openjdk.org  Sat Dec  7 07:59:15 2024
From: gcao at openjdk.org (Gui Cao)
Date: Sat, 7 Dec 2024 07:59:15 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v3]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <4hskHg1hsixh0JYzUplQmBGs_Zt3gsU267vDyzbi2zE=.4d1dac90-fb5f-4031-a946-1f8eb4799a2e@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

-------------

Changes: https://git.openjdk.org/jdk/pull/21922/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=02
  Stats: 375 lines in 5 files changed: 300 ins; 23 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/21922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922

PR: https://git.openjdk.org/jdk/pull/21922

From mli at openjdk.org  Sat Dec  7 09:59:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 7 Dec 2024 09:59:38 GMT
Subject: RFR: 8345669: RISC-V: fix client build failure due to AlignVector
 after JDK-8343827
In-Reply-To: <of-0fm8-0Y6-mSkNvhRDtPWhNAQC9VbmohNJYoqmjQ8=.7f986ed7-5780-47a4-b2fb-9a5554b917fb@github.com>
References: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
 <of-0fm8-0Y6-mSkNvhRDtPWhNAQC9VbmohNJYoqmjQ8=.7f986ed7-5780-47a4-b2fb-9a5554b917fb@github.com>
Message-ID: <RPHEZC2D57VAunuvdW8Uxm2_J-UNm49ZSrTI9T22Bas=.ed26140f-299f-4377-a9bc-28b55633c40e@github.com>

On Sat, 7 Dec 2024 02:59:13 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Thanks. Seems this should be fixed for jdk24 as well.

Yes, I think so. I just found this issue when I work on another task.
I think this pr will not get into 24 automatically, maybe a backport is needed? I'll backport it later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22605#issuecomment-2525055636

From mli at openjdk.org  Sat Dec  7 09:59:49 2024
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 7 Dec 2024 09:59:49 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v4]
In-Reply-To: <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
Message-ID: <l8k5tlnzVGip0k_eeYW9jxL-_rUWBll71BznFXcVE5E=.d017b7b5-822b-4fdb-9cbb-9ade43dcfa45@github.com>

On Thu, 5 Dec 2024 17:07:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
>> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>> also run tests found by: `grep -lRi crc32 test/* | grep -v bench`
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix flag warning

Thank for your reivews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22475#issuecomment-2525055256

From mli at openjdk.org  Sat Dec  7 09:59:50 2024
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 7 Dec 2024 09:59:50 GMT
Subject: Integrated: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication
In-Reply-To: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
Message-ID: <Dtf4BdXvPea_IUy1mMGuzTrAWBbKbpnWAcQ6OyQm1qk=.c7834a25-00f3-4e76-b81a-d954fefdb97b@github.com>

On Mon, 2 Dec 2024 10:00:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
> Thanks!
> 
> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
> 
> 
> ## Test
> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
> test/jdk/java/util/zip/TestCRC32.java
> also run tests found by: `grep -lRi crc32 test/* | grep -v bench`

This pull request has now been integrated.

Changeset: c517ffba
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c517ffba7d9388e75b5d7bba77e565e71c0a7d76
Stats:     407 lines in 7 files changed: 404 ins; 0 del; 3 mod

8339910: RISC-V: crc32 intrinsic with carry-less multiplication

Reviewed-by: rehn, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/22475

From kvn at openjdk.org  Sun Dec  8 19:11:41 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Sun, 8 Dec 2024 19:11:41 GMT
Subject: RFR: 8345746: Remove :resourcehogs/compiler from
 :hotspot_slow_compiler [v2]
In-Reply-To: <Cu_zWGdaVEvyzXlNBQcf8LZvj_Dppvh_Op16O3_DyIk=.c20874f0-149a-417d-ba58-c34bcbfcf32e@github.com>
References: <FwDCA82Hak0z63SHjmPUUhmWyma3YhzD3V81OWk9wa0=.8c2706f1-e82b-4d55-a009-195852804741@github.com>
 <Cu_zWGdaVEvyzXlNBQcf8LZvj_Dppvh_Op16O3_DyIk=.c20874f0-149a-417d-ba58-c34bcbfcf32e@github.com>
Message-ID: <-SbhlJxWpaW1GOF4i-hSe7k7nUQ_KCRiqIFW5WnyPhs=.c1670b00-8d28-4810-a6ef-e42cc2b5136e@github.com>

On Sat, 7 Dec 2024 04:19:18 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The test group
>> :resourcehogs/compiler
>> contains tests that should not be executed concurrently with *any* tests.
>> 
>> They might use a lot of resources and cause unexplained sporadic failures of other tests.
>> 
>> So it should be removed from :hotspot_slow_compiler.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   hogs group added.

Marked as reviewed by kvn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22626#pullrequestreview-2487246566

From dholmes at openjdk.org  Sun Dec  8 23:41:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 8 Dec 2024 23:41:58 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v2]
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <pY9_2PBNV7kfCKOT5nXJdrFJOo3UY_WCnjpIKDMi4xA=.082ccad4-9980-4118-888e-d458b0ca42a4@github.com>

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Change from frame& parameter back to frame to ensure we match pre-existing logic for copying frames
 - Merge branch 'master' into 8311542-native-stack
 - Remove unused constructor
 - Missing file header
 - 8311542: Consolidate the native stack printing code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22472/files
  - new: https://git.openjdk.org/jdk/pull/22472/files/29dbd620..3228fb48

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=00-01

  Stats: 85777 lines in 1272 files changed: 69632 ins; 11002 del; 5143 mod
  Patch: https://git.openjdk.org/jdk/pull/22472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22472/head:pull/22472

PR: https://git.openjdk.org/jdk/pull/22472

From dholmes at openjdk.org  Mon Dec  9 00:17:18 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 00:17:18 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v3]
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <QkxM1u2196IfDH93XHc5GdaNwKLQNWBs3Jj0ASbMh1k=.a783a3de-8ca5-4ba1-89eb-0493cdcc9d37@github.com>

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into 8311542-native-stack
 - Change from frame& parameter back to frame to ensure we match pre-existing logic for copying frames
 - Merge branch 'master' into 8311542-native-stack
 - Remove unused constructor
 - Missing file header
 - 8311542: Consolidate the native stack printing code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22472/files
  - new: https://git.openjdk.org/jdk/pull/22472/files/3228fb48..a65a1452

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=01-02

  Stats: 1192 lines in 385 files changed: 443 ins; 627 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/22472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22472/head:pull/22472

PR: https://git.openjdk.org/jdk/pull/22472

From dholmes at openjdk.org  Mon Dec  9 01:03:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 01:03:51 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <fcqv06JN2gRvxz86jrnkYuOYSGcLKxzrd7mRectmda0=.46ea9155-e74a-4978-b23e-1f3f974282e9@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved id from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

@lmesnik  so this is now going to run all the slow tests in tier3?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22614#issuecomment-2526569595

From dholmes at openjdk.org  Mon Dec  9 02:05:52 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 02:05:52 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
 <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
 <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-
 ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>
Message-ID: <Cvgn6yeSuONcQSud1mgZA2D3OoHvDUmVcHwjKrvI02I=.a8cb3e2c-7624-4ba7-92a3-ee81e07df042@github.com>

On Fri, 6 Dec 2024 08:16:31 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Sorry still struggling to understand what os+cpu combinations will cause this code to be compiled. If not ARM64 and not x64 then where are the definitions for things like `float_sign_mask` used by this seemingly shared code?
>
> float_sign_mask and friends are only used by Windows ARM64, in the workaround for the Windows CRT bug (I do wish we could get rid of it though!). If looked at closely, the workaround that uses float_sign_mask and friends is only compiled when !X86 && _WIN64, which means Windows ARM64. To simplify:
> 
> - All x86 platforms, including x64, use handwritten assembly, so doesn't use float_sign_mask and friends
> - Windows ARM64 uses float_sign_mask and friends, as it has to use the workaround
> - All other platforms simply directly call fmod without using float_sign_mask and friends at all, so there is no definition for those platforms

So why does the _M_ARM64 block  not cover all of this code instead of it appearing to be used by other platforms, when it isn't?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1875173544

From lmesnik at openjdk.org  Mon Dec  9 02:22:40 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 9 Dec 2024 02:22:40 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <GNGWHjY2tsS2XVTJvhxG0X_QJz08flyZzRFmEjnkytE=.503d303b-c394-4e99-9455-e8eef27b655f@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved id from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

The
 :hotspot_slow_compiler  
is already in tier3.

The are only few groups has been added ad I wrote in description. They are not slow.
The problem is that currently for hotspot compiler tier1 + tier2 + tier3 are not all tests and there is no tier4_compiler.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22614#issuecomment-2526662694

From dholmes at openjdk.org  Mon Dec  9 02:38:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 02:38:38 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
Message-ID: <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>

On Fri, 6 Dec 2024 14:54:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
>> 
>> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

I don't see the removal of the "moved" functions from ./share/memory/virtualspace.cpp ??

src/hotspot/share/runtime/os.hpp line 408:

> 406:   static size_t vm_page_size() { return OSInfo::vm_page_size(); }
> 407: 
> 408:   static size_t align_up_vm_page_size(size_t size)   { return align_up  (size, os::vm_page_size()); }

Style Nit: please don't add extra whitespace before the opening function parenthesis.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22600#pullrequestreview-2487519426
PR Review Comment: https://git.openjdk.org/jdk/pull/22600#discussion_r1875194126

From fyang at openjdk.org  Mon Dec  9 02:56:39 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 9 Dec 2024 02:56:39 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>

On Thu, 5 Dec 2024 11:49:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 479:

> 477:   ttg.doit();
> 478:   ttg.join();
> 479:   ASSERT_EQ(data, (TESTSIZE)(num_threads*10000));

Seems there is an integer overflow issue for the narrow tests? `num_threads*10000` is 40000 here which is much larger than allowed for `int8_t` and `int16_t` types.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1874601972

From fyang at openjdk.org  Mon Dec  9 02:57:44 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 9 Dec 2024 02:57:44 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v4]
In-Reply-To: <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
Message-ID: <vGSOVNxTKbhtzzPOkFQD85qjUbJklWRigaXao8KwmS0=.2451f450-3c2c-4a81-8c1a-6f508c2164e5@github.com>

On Thu, 5 Dec 2024 17:07:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you review this patch to implement CRC32 with `vclmul` (Zvbc)?
>> Thanks!
>> 
>> For more details of the algorithm, please check the paper: "Fast CRC Computation for Generic Polynomials Using PCLMULQDQ Instruction - Intel", please also refer to the corresponding code in aarch64 or x86 ones.
>> As the riscv carry-less multiplication instructions are a bit different from the other platforms, so the implementation itself is also a bit different from others.
>> 
>> 
>> ## Test
>> test/hotspot/jtreg/compiler/intrinsics/zip/TestCRC32.java, 
>> test/jdk/java/util/zip/TestCRC32.java
>> also run tests found by: `grep -lRi crc32 test/* | grep -v bench`
>
> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix flag warning

src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 182:

> 180:   }
> 181:   if (is_set(RISCV_HWPROBE_KEY_IMA_EXT_0, RISCV_HWPROBE_EXT_ZVBC)) {
> 182:     VM_Version::ext_Zvbc.enable_feature();

Are we auto-enabling this experimental feature?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1874599791

From gcao at openjdk.org  Mon Dec  9 03:01:16 2024
From: gcao at openjdk.org (Gui Cao)
Date: Mon, 9 Dec 2024 03:01:16 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <ddqQyT7Z-5bWnf6gyLLxFcyDP8lCEHCp5EBcJCpxmM0=.fb1fb665-4f2e-4db4-8c05-f0d41bec056a@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8342881
 - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21922/files
  - new: https://git.openjdk.org/jdk/pull/21922/files/deaed30c..1ee5b6d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=02-03

  Stats: 504 lines in 16 files changed: 424 ins; 69 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922

PR: https://git.openjdk.org/jdk/pull/21922

From dholmes at openjdk.org  Mon Dec  9 04:05:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 04:05:42 GMT
Subject: RFR: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
In-Reply-To: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
References: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
Message-ID: <ooh-xV0gSobAY2SBSotQZLpWAEUwLhIcO5eI6AAFOdM=.a697897e-258d-4c52-b96d-1cca6e37943d@github.com>

On Fri, 6 Dec 2024 10:09:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This functions is called after an previous calls to WB_NMTReserveMemory and WB_NMTAttemptReserveMemoryAt, which both already registered an NMT tag. So, explicitly recording an NMT tag for this memory is redundant and slightly confusing.
> 
> The HotSpot JVM code does not record NMT tags when committing memory (except in a special case on Windows when mapping file memory).
> 
> Tested with tier1-3.

This seems consistent with the conclusion in [JDK-8331539](https://bugs.openjdk.org/browse/JDK-8331539) that tags for commit/uncommit are optional and up to the callers. So in that sense it is up to the caller of `WB_NMTCommitMemory` to decide whether an explicit tag is necessary.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22601#pullrequestreview-2487674522

From dholmes at openjdk.org  Mon Dec  9 04:12:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 04:12:36 GMT
Subject: RFR: 8345661: Simplify page size alignment in code heap
 reservation
In-Reply-To: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
References: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
Message-ID: <fnX9HjdeljMOJcfBFZcFuFX29crriP49dlfSwoTmYgw=.db1fa7fe-0b43-44f9-a36b-a94108aabb16@github.com>

On Fri, 6 Dec 2024 11:03:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While working on a prototype to clean up ReservedSpace ([JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) I noticed that the code that reserves the code heap first aligns the committed memory size towards small pages and then aligns it against the page size that was set up for the ReservedSpace. I suggest that just align to the latter immediately.
> 
> I also inlined the one usage of `os::vm_allocation_granularity`.
> 
> Testing tier1-3

Seems reasonable. None of the arguments to `CodeHeap::reserve` are documented anyway and there is only a single caller.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22604#pullrequestreview-2487684624

From dholmes at openjdk.org  Mon Dec  9 04:31:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 04:31:38 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>

On Fri, 6 Dec 2024 22:00:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

This seems reasonable, but I wonder if we can simplify things further for arrays - see below.

Future RFE: I also think we need to cleanup terminology i.e. "modifier flags" versus "access flags".

Thanks

src/hotspot/share/classfile/javaClasses.cpp line 1119:

> 1117:   // to support Class.getModifiers().  Instance classes recalculate
> 1118:   // the cached flags after the class file is parsed, but before the
> 1119:   // class is put into the system dictionary.

Is this comment already out-of-date? I'm trying to see where the flags are recomputed after parsing.

src/hotspot/share/oops/typeArrayKlass.hpp line 76:

> 74:   void  copy_array(arrayOop s, int src_pos, arrayOop d, int dst_pos, int length, TRAPS);
> 75: 
> 76:   // jvm support

"jvm support" for what? I'm not even sure why we need `compute_modifier_flags` for array types when they have a fixed value. Can't we just hardwire them and only call `compute_modifier_flags` for instanceKlasses?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2487697138
PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875323314
PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875322865

From dholmes at openjdk.org  Mon Dec  9 04:53:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 04:53:37 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <GNGWHjY2tsS2XVTJvhxG0X_QJz08flyZzRFmEjnkytE=.503d303b-c394-4e99-9455-e8eef27b655f@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
 <GNGWHjY2tsS2XVTJvhxG0X_QJz08flyZzRFmEjnkytE=.503d303b-c394-4e99-9455-e8eef27b655f@github.com>
Message-ID: <tDBNUqKv6IssytH204ifCCp9_aznx2bIyCWfXVcHv18=.12084d98-f413-4939-b6a5-c615b839c44d@github.com>

On Mon, 9 Dec 2024 02:19:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The :hotspot_slow_compiler is already in tier3.

Sorry I misread things.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22614#issuecomment-2526886559

From dholmes at openjdk.org  Mon Dec  9 05:02:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 05:02:37 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <fPmIJ-QUnS-eAb4JnFGFz9EB0uyDv0niUM66s5aRJgQ=.e9f2106b-6797-4292-8d54-dda572d2fd75@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved id from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

I don't think the ctw tests should be moved up to tier2. IIUC these are quite heavyweight tests and they will run too often in tier2 compared to tier3.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22614#pullrequestreview-2487731782

From lmesnik at openjdk.org  Mon Dec  9 05:20:36 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 9 Dec 2024 05:20:36 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <fPmIJ-QUnS-eAb4JnFGFz9EB0uyDv0niUM66s5aRJgQ=.e9f2106b-6797-4292-8d54-dda572d2fd75@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
 <fPmIJ-QUnS-eAb4JnFGFz9EB0uyDv0niUM66s5aRJgQ=.e9f2106b-6797-4292-8d54-dda572d2fd75@github.com>
Message-ID: <FckArTgw_rNCw-JIy6xe_QWuEEuV1tFgPB9bHzVP_Zg=.e7864584-2c31-4399-bdc9-193a19e9f6c7@github.com>

On Mon, 9 Dec 2024 04:59:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't think the ctw tests should be moved up to tier2. IIUC these are quite heavyweight tests and they will run too often in tier2 compared to tier3.

Sorry, it was a typo in description:
`I moved id from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. `
updated to
`I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. `

So fix just align ctw tier to current state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22614#issuecomment-2526933897

From dholmes at openjdk.org  Mon Dec  9 05:30:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 05:30:37 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <d4QP-H0859xKYeJ03NC34YYo412h6WA2IkIor2oVsyc=.6aafa545-72d1-442e-b09e-e0528b55b585@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

Okay - from Oracle perspective changes seem fine as they align with our existing testing.

Need to see how this impacts others.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22614#pullrequestreview-2487768942

From jwaters at openjdk.org  Mon Dec  9 07:07:40 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 9 Dec 2024 07:07:40 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <Cvgn6yeSuONcQSud1mgZA2D3OoHvDUmVcHwjKrvI02I=.a8cb3e2c-7624-4ba7-92a3-ee81e07df042@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
 <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
 <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-
 ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>
 <Cvgn6yeSuONcQSud1mgZA2D3OoHvDUmVcHwjKrvI02I=.a8cb3e2c-7624-4ba7-92a3-ee81e07df042@github.com>
Message-ID: <M6xkFGips-BPJMQ7E1IzPV0Cn_aEOcz8CsHZc9n4fCE=.eb8fa987-c09a-4800-a153-8240656e2b25@github.com>

On Mon, 9 Dec 2024 02:03:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> float_sign_mask and friends are only used by Windows ARM64, in the workaround for the Windows CRT bug (I do wish we could get rid of it though!). If looked at closely, the workaround that uses float_sign_mask and friends is only compiled when !X86 && _WIN64, which means Windows ARM64. To simplify:
>> 
>> - All x86 platforms, including x64, use handwritten assembly, so doesn't use float_sign_mask and friends
>> - Windows ARM64 uses float_sign_mask and friends, as it has to use the workaround
>> - All other platforms simply directly call fmod without using float_sign_mask and friends at all, so there is no definition for those platforms
>
> So why does the _M_ARM64 block  not cover all of this code instead of it appearing to be used by other platforms, when it isn't?

I'm not really sure what you mean, if you mean why the _M_ARM64 ifdef doesn't guard the frem and drem implementations in sharedRuntime.cpp here, it's because the Windows/ARM64 implementation with the workaround in it and the implementation for the rest of the platforms (minus x86) are squashed right next to each other. Which implementation is compiled into HotSpot is then determined by the #ifdef _WIN64 check on line 296. If the _M_ARM64 ifdef covered the frem and drem implementation here then the implementation for all non Windows/ARM64 and non x86 platforms would not be defined, and HotSpot wouldn't link at all. Well, that's if I understood you correctly, at least

It might be possible to split the Windows/ARM64 implementation specifically into another file to reduce the confusion, but I feel like that is more trouble than it's worth, and may just cause more issues if not done right. I'd prefer not to do that to avoid all those problems

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1875468053

From dholmes at openjdk.org  Mon Dec  9 07:39:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 07:39:40 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <M6xkFGips-BPJMQ7E1IzPV0Cn_aEOcz8CsHZc9n4fCE=.eb8fa987-c09a-4800-a153-8240656e2b25@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
 <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
 <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-
 ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>
 <Cvgn6yeSuONcQSud1mgZA2D3OoHvDUmVcHwjKrvI02I=.a8cb3e2c-7624-4ba7-92a3-ee81e07df042@github.com>
 <M6xkFGips-BPJMQ7E1IzPV0Cn_aEOcz8CsHZc9n4fCE=.eb8fa987-c09a-4800-a153-8240656e2b25@github.com>
Message-ID: <Wmb7dzm_GcZoJ9L8woV04MIV3Td70GpXU_8JbPG7rEM=.d7859a33-534c-423d-8952-24abbc65f2a6@github.com>

On Mon, 9 Dec 2024 07:05:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> So why does the _M_ARM64 block  not cover all of this code instead of it appearing to be used by other platforms, when it isn't?
>
> I'm not really sure what you mean, if you mean why the _M_ARM64 ifdef doesn't guard the frem and drem implementations in sharedRuntime.cpp here, it's because the Windows/ARM64 implementation with the workaround in it and the implementation for the rest of the platforms (minus x86) are squashed right next to each other. Which implementation is compiled into HotSpot is then determined by the #ifdef _WIN64 check on line 296. If the _M_ARM64 ifdef covered the frem and drem implementation here then the implementation for all non Windows/ARM64 and non x86 platforms would not be defined, and HotSpot wouldn't link at all. Well, that's if I understood you correctly, at least
> 
> It might be possible to split the Windows/ARM64 implementation specifically into another file to reduce the confusion, but I feel like that is more trouble than it's worth, and may just cause more issues if not done right. I'd prefer not to do that to avoid all those problems

Sorry I'm doing a really bad job of pretending to be the preprocessor. :)

So the block at  line 287 defines some constants for all ARM64, even though they are only needed on Windows.

The block at line 294 provides function definitions for all CPUs other the x86. Then within that we have one version for WIN64 (which really means Windows/Aarch64) and a regular version for all other non-x86 CPUS and non-Windows Aarch64.

So I guess what I'm suggesting is that it would be clearer to use `if defined(_M_ARM64) && defined(WINDOWS)` at lines 287, 294 and 321, to be clear the special code is only for Windows/Aarch64. 

Second I think it would be clearer to just have two blocks: one for windows/aarch64 and the other for all other non-x86, rather than interleaving things the way they have been done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1875502824

From rehn at openjdk.org  Mon Dec  9 08:18:39 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 9 Dec 2024 08:18:39 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
Message-ID: <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>

On Sun, 8 Dec 2024 03:00:03 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 479:
> 
>> 477:   ttg.doit();
>> 478:   ttg.join();
>> 479:   ASSERT_EQ(data, (TESTSIZE)(num_threads*10000));
> 
> Seems there is an integer overflow issue for the narrow tests? `num_threads*10000` is 40000 here which is much larger than allowed for `int8_t` and `int16_t` types.

Strictly speaking the first overflow happens here:
`TESTSIZE newvalue = oldvalue + 1;`
As '1' is an integer, oldvalue is promoted to an integer and as 128 is not in range of int8_t.
This is implementation defined, but de facto we know this will wrap around.

The casting of 40000 to TESTIZE the same thing happens, but first the higher bits are truncated and then it may wrap around depending on the MSB.

AFIACT it always produces the same result.

If we don't trust the wrap around as it's outside the spec both cases should be handled.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1875546653

From shade at openjdk.org  Mon Dec  9 08:20:37 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 9 Dec 2024 08:20:37 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <wV7-9p8MFu4ZfZml9pBSvIlTj0xHGTdKsbdig0dS8v8=.f66a080c-2df0-4c47-b933-b93ed2570e1e@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

A good test for these changes is looking at GHA usages and see how well the tests are balanced between the groups. See for example here: https://github.com/lmesnik/jdk/actions/runs/12205347403/usage. I am not sure if this is pre-existing or not, but it looks like `hs/tier1 compiler part 3` is twice as long as `part 1` or `part 2`. We would ideally like all parts to take roughly the same time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22614#issuecomment-2527231121

From epeter at openjdk.org  Mon Dec  9 08:21:45 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 9 Dec 2024 08:21:45 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v6]
In-Reply-To: <6YeHbHlrPoV9obcfC7g1PtFdMKfanhnsKxqwTZovts4=.f5743961-07e2-4325-b8f5-270edd342e11@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <6YeHbHlrPoV9obcfC7g1PtFdMKfanhnsKxqwTZovts4=.f5743961-07e2-4325-b8f5-270edd342e11@github.com>
Message-ID: <UFG2L64wIRWrNb91hA5yHVAX1P6OyqhglhFQqHDmwpg=.28256995-8ae7-43aa-a2ae-1c82cf8617d7@github.com>

On Fri, 6 Dec 2024 17:00:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comment, extract cast into local variable

@merykitty looks quite reasonable, though I only looked at the VM changes, only scanned the Java library code.

src/hotspot/cpu/x86/x86.ad line 2215:

> 2213: 
> 2214: // Return true if Vector::rearrange needs preparation of the shuffle argument
> 2215: bool Matcher::vector_needs_load_shuffle(BasicType elem_bt, int vlen) {

I commented on this before. This needs to have a more expressive name. Is it just about rearrange? Because now it sounds like maybe all vectors may need a shuffle. Or just all loads? Confusing.

src/hotspot/share/opto/vectorIntrinsics.cpp line 1757:

> 1755: 
> 1756:   int num_elem = vlen->get_con();
> 1757:   bool need_load_shuffle = Matcher::vector_needs_load_shuffle(shuffle_bt, num_elem);

Maybe it could be renamed to `vector_rearrange_requires_load_shuffle`?

src/hotspot/share/opto/vectorIntrinsics.cpp line 1800:

> 1798:   Node* v1 = unbox_vector(argument(5), vbox_type, elem_bt, num_elem);
> 1799:   Node* shuffle = unbox_vector(argument(6), shbox_type, shuffle_bt, num_elem);
> 1800:   const TypeVect* vt = TypeVect::make(elem_bt, num_elem);

Is this one used?

src/hotspot/share/opto/vectornode.hpp line 1694:

> 1692: // we can transform the rearrange into a different element type. For example, on x86 before AVX512,
> 1693: // there is no rearrange instruction for short elements, what we will then do is to transform the
> 1694: // shuffle vector into 1 that we can do byte rearrange such that it would provide the same result.

Suggestion:

// shuffle vector into one that we can do byte rearrange such that it would provide the same result.

src/hotspot/share/opto/vectornode.hpp line 1696:

> 1694: // shuffle vector into 1 that we can do byte rearrange such that it would provide the same result.
> 1695: // This can be done in VectorRearrangeNode during code emission but we eagerly expand out this
> 1696: // because it is often the case that an index vector is reused in many rearrange operations.

Thanks for this explanation!

`This can be done in VectorRearrangeNode` -> **could have** be done, because we now don't do it, right?
What do you mean by `expand out this`? Do you mean we have a separate dedicated node, so that it could possibly fold away with other nodes, such as index vector?

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2487987908
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875503753
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875517727
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875519134
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875537761
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875540023

From epeter at openjdk.org  Mon Dec  9 08:21:45 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 9 Dec 2024 08:21:45 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v6]
In-Reply-To: <UFG2L64wIRWrNb91hA5yHVAX1P6OyqhglhFQqHDmwpg=.28256995-8ae7-43aa-a2ae-1c82cf8617d7@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <6YeHbHlrPoV9obcfC7g1PtFdMKfanhnsKxqwTZovts4=.f5743961-07e2-4325-b8f5-270edd342e11@github.com>
 <UFG2L64wIRWrNb91hA5yHVAX1P6OyqhglhFQqHDmwpg=.28256995-8ae7-43aa-a2ae-1c82cf8617d7@github.com>
Message-ID: <WLaBr7vuAPYGRctUTa12uxwhmYbr7QmxoAcoPArb9MA=.c700d57a-f9a2-4aef-936e-f9e9c2c97eba@github.com>

On Mon, 9 Dec 2024 07:37:55 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comment, extract cast into local variable
>
> src/hotspot/cpu/x86/x86.ad line 2215:
> 
>> 2213: 
>> 2214: // Return true if Vector::rearrange needs preparation of the shuffle argument
>> 2215: bool Matcher::vector_needs_load_shuffle(BasicType elem_bt, int vlen) {
> 
> I commented on this before. This needs to have a more expressive name. Is it just about rearrange? Because now it sounds like maybe all vectors may need a shuffle. Or just all loads? Confusing.

Maybe it coud be named `vector_rearrange_requires_load_shuffle`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875542286

From jwaters at openjdk.org  Mon Dec  9 08:26:40 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 9 Dec 2024 08:26:40 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <Wmb7dzm_GcZoJ9L8woV04MIV3Td70GpXU_8JbPG7rEM=.d7859a33-534c-423d-8952-24abbc65f2a6@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
 <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
 <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-
 ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>
 <Cvgn6yeSuONcQSud1mgZA2D3OoHvDUmVcHwjKrvI02I=.a8cb3e2c-7624-4ba7-92a3-ee81e07df042@github.com>
 <M6xkFGips-BPJMQ7E1IzPV0Cn_aEOcz8CsHZc9n4fCE=.eb8fa987-c09a-4800-a153-8240656e2b25@github.com>
 <Wmb7dzm_GcZoJ9L8woV04MIV3Td70GpXU_8JbPG7rEM=.d7859a33-534c-423d-8952-24abbc65f2a6@github.com>
Message-ID: <u3LSCur-Em1mhttj_6b6RiuHqmBZOeTztQKGWxJKa2w=.9fb680c2-7d95-45b1-8d6d-f48c679ef935@github.com>

On Mon, 9 Dec 2024 07:36:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I'm not really sure what you mean, if you mean why the _M_ARM64 ifdef doesn't guard the frem and drem implementations in sharedRuntime.cpp here, it's because the Windows/ARM64 implementation with the workaround in it and the implementation for the rest of the platforms (minus x86) are squashed right next to each other. Which implementation is compiled into HotSpot is then determined by the #ifdef _WIN64 check on line 296. If the _M_ARM64 ifdef covered the frem and drem implementation here then the implementation for all non Windows/ARM64 and non x86 platforms would not be defined, and HotSpot wouldn't link at all. Well, that's if I understood you correctly, at least
>> 
>> It might be possible to split the Windows/ARM64 implementation specifically into another file to reduce the confusion, but I feel like that is more trouble than it's worth, and may just cause more issues if not done right. I'd prefer not to do that to avoid all those problems
>
> Sorry I'm doing a really bad job of pretending to be the preprocessor. :)
> 
> So the block at  line 287 defines some constants for all ARM64, even though they are only needed on Windows.
> 
> The block at line 294 provides function definitions for all CPUs other the x86. Then within that we have one version for WIN64 (which really means Windows/Aarch64) and a regular version for all other non-x86 CPUS and non-Windows Aarch64.
> 
> So I guess what I'm suggesting is that it would be clearer to use `if defined(_M_ARM64) && defined(WINDOWS)` at lines 287, 294 and 321, to be clear the special code is only for Windows/Aarch64. 
> 
> Second I think it would be clearer to just have two blocks: one for windows/aarch64 and the other for all other non-x86, rather than interleaving things the way they have been done.

Ah, I see what you mean. There's just a small change I would make, which is to check whether defined(_WINDOWS) and defined(AARCH64) instead. Checking for both _M_ARM64 and _WINDOWS is redundant; _M_ARM64 is a Windows only define, so checking for _M_ARM64 == checking for AARCH64 && _WINDOWS. Would you be ok with that instead?

I think(?) I get what you mean by having 2 blocks, I'll try to do that

> Sorry I'm doing a really bad job of pretending to be the preprocessor. :)

Haha, it happens

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1875557388

From mli at openjdk.org  Mon Dec  9 09:26:44 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 9 Dec 2024 09:26:44 GMT
Subject: RFR: 8339910: RISC-V: crc32 intrinsic with carry-less
 multiplication [v4]
In-Reply-To: <vGSOVNxTKbhtzzPOkFQD85qjUbJklWRigaXao8KwmS0=.2451f450-3c2c-4a81-8c1a-6f508c2164e5@github.com>
References: <FYH-AmY1xLBTrDCndudFWCURwFIWWcAeATAd2qiQm1o=.6d22ec78-c084-4849-9a44-9470d3193ce5@github.com>
 <x9C-j-C1J_UJutnFgRoD2itoex_JGeIg4inTl7NobK0=.6b28943c-306e-4dd0-a4a7-167f425bf4d6@github.com>
 <vGSOVNxTKbhtzzPOkFQD85qjUbJklWRigaXao8KwmS0=.2451f450-3c2c-4a81-8c1a-6f508c2164e5@github.com>
Message-ID: <DfWwW9YIJmY4qe7MtqXvbbkQXU4S9Dje4sMJnHMvVZ4=.d596c77f-3d1d-4a71-9249-0e9543b642b6@github.com>

On Sun, 8 Dec 2024 02:35:56 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hamlin Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix flag warning
>
> src/hotspot/os_cpu/linux_riscv/riscv_hwprobe.cpp line 182:
> 
>> 180:   }
>> 181:   if (is_set(RISCV_HWPROBE_KEY_IMA_EXT_0, RISCV_HWPROBE_EXT_ZVBC)) {
>> 182:     VM_Version::ext_Zvbc.enable_feature();
> 
> Are we auto-enabling this experimental feature?

Ah, thanks for catching. I'll fix this later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22475#discussion_r1875639227

From aph at openjdk.org  Mon Dec  9 09:41:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 9 Dec 2024 09:41:40 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <u3LSCur-Em1mhttj_6b6RiuHqmBZOeTztQKGWxJKa2w=.9fb680c2-7d95-45b1-8d6d-f48c679ef935@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
 <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
 <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-
 ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>
 <Cvgn6yeSuONcQSud1mgZA2D3OoHvDUmVcHwjKrvI02I=.a8cb3e2c-7624-4ba7-92a3-ee81e07df042@github.com>
 <M6xkFGips-BPJMQ7E1IzPV0Cn_aEOcz8CsHZc9n4fCE=.eb8fa987-c09a-4800-a153-8240656e2b25@github.com>
 <Wmb7dzm_GcZoJ9L8woV04MIV3Td70GpXU_8JbPG7rEM=.d7859a33-534c-423d-8952-24abbc65f2a6@github.com>
 <u3LSCur-Em1mhttj_6b6RiuHqmBZOeTztQKGWxJKa2w=.9fb680c2-7d95-45b1-8d6d-f48c679ef935@github.com>
Message-ID: <AbxvNiIurm6uI7Ha_wdL6ebaBuKD1PGR7F9fpOWz8U0=.57f5dac2-8270-4176-ac23-3a69a60dfff2@github.com>

On Mon, 9 Dec 2024 08:24:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Ah, I see what you mean. There's just a small change I would make, which is to check whether defined(_WINDOWS) and defined(AARCH64) instead. Checking for both _M_ARM64 and _WINDOWS is redundant; _M_ARM64 is a Windows only define, so checking for _M_ARM64 == checking for AARCH64 && _WINDOWS.

Checking for `AARCH64 && _WINDOWS` is much easier to understand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1875662049

From azafari at openjdk.org  Mon Dec  9 10:19:50 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 9 Dec 2024 10:19:50 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
Message-ID: <RfIjTEurTj_uv-HsOORUcfvi-YcBjbRIPuIJM9J9n2Y=.fe982bbd-c29c-4652-965e-b6d332feebed@github.com>

On Thu, 5 Dec 2024 21:38:25 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a missed change in a shenandoah file.
>
> src/hotspot/share/nmt/regionsTree.hpp line 57:
> 
>> 55:       inline void clear_node() { _node = nullptr; }
>> 56:       inline VMATree::position position() { return _node->key(); }
>> 57:       inline bool is_committed_begin() { return ((uint8_t)out_state() & (uint8_t)VMATree::StateType::Committed) >= 2; }
> 
> This allows a region to be committed but not reserved?

`StateType::Committed` is `3` and `StateType::Reserved` is `1`. So, `committed` means `reserved and committed`. The above predicate checks the bit 1 of the `state` if it is set or not.

> src/hotspot/share/nmt/regionsTree.hpp line 105:
> 
>> 103:         if (prev.is_committed_begin()) {
>> 104:           comm_size += curr.distance_from(prev);
>> 105:           if (!curr.is_committed_begin()) {
> 
> Shouldn't it be impossible to have 2 back-to-back committed regions? Wouldn't they already be coalesced by `VMATree::register_mapping`?

Only regions with the same `MemTag` can be merged into one. It is possible to have two adjacent committed regions with different `MemTag`s.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1875719211
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1875721040

From azafari at openjdk.org  Mon Dec  9 10:25:49 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 9 Dec 2024 10:25:49 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
Message-ID: <FDT2stTOYtaFczrl_tj6w2RHzi967eae4OLUlNCNRb4=.283f75e7-6cc9-4386-bfd9-60d0b0aa9f56@github.com>

On Fri, 6 Dec 2024 15:47:31 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a missed change in a shenandoah file.
>
> src/hotspot/share/nmt/regionsTree.hpp line 135:
> 
>> 133:       }
>> 134:       prev = curr;
>> 135:       if (curr.is_released_begin() || begin_node.out_tag() != curr.out_tag()) {
> 
> It looks like you are running `func(ReservedMemoryRegion)` on partial reserved memory regions, so long as `begin_node.out_tag() != curr.out_tag()`. For example you may run `func(ReservedMemoryRegion)` on a slice of a reserved region, or a single committed region. Isn't the intention to instead find where each whole reserved region starts and ends, then run  `func(ReservedMemoryRegion)` on the entire reserved region?

inline bool is_released_begin() { return out_state() == VMATree::StateType::Released; }

Released means neither reserved nor committed.
In case two different regions are adjacent with different `MemTag`, the `out_tag()` comparison will catch it.

> src/hotspot/share/nmt/regionsTree.hpp line 137:
> 
>> 135:       if (curr.is_released_begin() || begin_node.out_tag() != curr.out_tag()) {
>> 136:         auto st = stack(curr);
>> 137:         size_t r_size = curr.distance_from(begin_node);
> 
> Why is `r_size` never used?

Good catch. It was used in debug checks. No use any more. Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1875729264
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1875725956

From fyang at openjdk.org  Mon Dec  9 10:31:38 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 9 Dec 2024 10:31:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
Message-ID: <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>

On Mon, 9 Dec 2024 08:15:59 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 479:
>> 
>>> 477:   ttg.doit();
>>> 478:   ttg.join();
>>> 479:   ASSERT_EQ(data, (TESTSIZE)(num_threads*10000));
>> 
>> Seems there is an integer overflow issue for the narrow tests? `num_threads*10000` is 40000 here which is much larger than allowed for `int8_t` and `int16_t` types.
>
> Strictly speaking the first overflow happens here:
> `TESTSIZE newvalue = oldvalue + 1;`
> As '1' is an integer, oldvalue is promoted to an integer and as 128 is not in range of int8_t.
> This is implementation defined, but de facto we know this will wrap around.
> 
> The casting of 40000 to TESTIZE the same thing happens, but first the higher bits are truncated and then it may wrap around depending on the MSB.
> 
> AFIACT it always produces the same result.
> 
> If we don't trust the wrap around as it's outside the spec both cases should be handled.

Yeah. But seems avoidable if we make the loop count smaller for the narrow cases? I think it will be simpler and more readable for people then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1875736843

From azafari at openjdk.org  Mon Dec  9 10:45:34 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 9 Dec 2024 10:45:34 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v9]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <es4dw7RYkRF421IZHMv1tCe_jWSQbfzlJ-EyW4Qn4qY=.e333b6cc-f193-4876-a456-ad893777e629@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  removed unused local var.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/fd77057b..b5e6d268

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

PR: https://git.openjdk.org/jdk/pull/20425

From azafari at openjdk.org  Mon Dec  9 10:45:36 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 9 Dec 2024 10:45:36 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
Message-ID: <-amsFPnNKUzW0EH2d7gYiW0jYU3m8E8QUAVJL6ZC5tQ=.377d5a5a-26e9-41bc-b28f-8e6b46231481@github.com>

On Fri, 6 Dec 2024 15:50:57 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   a missed change in a shenandoah file.
>
> src/hotspot/share/nmt/regionsTree.hpp line 94:
> 
>> 92:   template<typename F>
>> 93:   void visit_committed_regions(position start, size_t size, F func) {
>> 94:     size_t end = start + size + 1;
> 
>> Yes it is missed.
> In the visit_range_in_order code, the variable cmp_to is never checked against 0 (cmp_to == 0).
> 
> You are referring to [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/nmt/nmtTreap.hpp#L380) right? I think that is actually ok without the +1. The upper boundary, "end", is outside of the range of the region, so probably should not be checked. For example if the region's starting address is 0 and has a size of 10, the last address within the region is 9. "End" in this case is 10 (0+10), and is out of bounds. If we made "end" = 0 + 10 + 1 = 11, then we would be including 10 in the checked range, which isn't right.

The `VMATree` holds the region `[A,B)` as two nodes with `A` and `B`. So, in your example the nodes in the tree are `0` and `10`. Looking for `< 10` does not find `B`, but `< 11` does..
The case with `end == 11` has no problem also when two regions are adjacent. If the next region has size `10`, for example,  then the nodes are `0`, `10` and `20`. `< 11` will find `10( = B)` and not `20`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1875752513

From rehn at openjdk.org  Mon Dec  9 11:15:37 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 9 Dec 2024 11:15:37 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
 <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
Message-ID: <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>

On Mon, 9 Dec 2024 10:28:53 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Strictly speaking the first overflow happens here:
>> `TESTSIZE newvalue = oldvalue + 1;`
>> As '1' is an integer, oldvalue is promoted to an integer and as 128 is not in range of int8_t.
>> This is implementation defined, but de facto we know this will wrap around.
>> 
>> The casting of 40000 to TESTIZE the same thing happens, but first the higher bits are truncated and then it may wrap around depending on the MSB.
>> 
>> AFIACT it always produces the same result.
>> 
>> If we don't trust the wrap around as it's outside the spec both cases should be handled.
>
> Yeah. But seems avoidable if we make the loop count smaller for the narrow cases? I think it will be simpler and more readable for people then.

Yes, but doing just 127 incs there, then it is big chance of the threads not running at the same time.
The point is that they should run parallel a period of time.

I can nest loops?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1875797641

From ihse at openjdk.org  Mon Dec  9 12:17:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:17:44 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files where
 it was missed
Message-ID: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

-------------

Commit messages:
 - 8345795: Update copyright year to 2024 for hotspot in files where it was missed

Changes: https://git.openjdk.org/jdk/pull/22637/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22637&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345795
  Stats: 844 lines in 844 files changed: 0 ins; 0 del; 844 mod
  Patch: https://git.openjdk.org/jdk/pull/22637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22637/head:pull/22637

PR: https://git.openjdk.org/jdk/pull/22637

From ihse at openjdk.org  Mon Dec  9 12:41:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:41:45 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add more hotspot files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22637/files
  - new: https://git.openjdk.org/jdk/pull/22637/files/0605277d..0166c68e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22637&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22637&range=00-01

  Stats: 77 lines in 82 files changed: 0 ins; 0 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/22637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22637/head:pull/22637

PR: https://git.openjdk.org/jdk/pull/22637

From ihse at openjdk.org  Mon Dec  9 12:48:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:48:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <QAwIZoxKKlbCIi_y4S8m9-u90W07cOngKe20_eEa7i8=.e9705ec8-2461-4805-80c5-a59a411f773e@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

Apologies for the force push; I accidentally pushed a commit that belonged to another branch here, and I just rolled back that commit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22637#issuecomment-2527832604

From coleenp at openjdk.org  Mon Dec  9 13:05:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 13:05:42 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
Message-ID: <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>

On Mon, 9 Dec 2024 04:22:54 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> src/hotspot/share/classfile/javaClasses.cpp line 1119:
> 
>> 1117:   // to support Class.getModifiers().  Instance classes recalculate
>> 1118:   // the cached flags after the class file is parsed, but before the
>> 1119:   // class is put into the system dictionary.
> 
> Is this comment already out-of-date? I'm trying to see where the flags are recomputed after parsing.

I thought the comment was referring to this code below that recalculates the modifier flags.  Don't know why system dictionary was called out though.

> src/hotspot/share/oops/typeArrayKlass.hpp line 76:
> 
>> 74:   void  copy_array(arrayOop s, int src_pos, arrayOop d, int dst_pos, int length, TRAPS);
>> 75: 
>> 76:   // jvm support
> 
> "jvm support" for what? I'm not even sure why we need `compute_modifier_flags` for array types when they have a fixed value. Can't we just hardwire them and only call `compute_modifier_flags` for instanceKlasses?

ObjArrayKlass computes the modifier flags based on the bottom_klass, and there is a place that calls compute_modifier_flags in an assert that requires the virtual function, albeit for an assert, otherwise I would have made it not a virtual function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875946187
PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875948835

From ihse at openjdk.org  Mon Dec  9 13:06:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 13:06:50 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where it
 was missed
Message-ID: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

-------------

Commit messages:
 - 8345805: Update copyright year to 2024 for other files where it was missed

Changes: https://git.openjdk.org/jdk/pull/22645/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345805
  Stats: 107 lines in 108 files changed: 0 ins; 0 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/22645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22645/head:pull/22645

PR: https://git.openjdk.org/jdk/pull/22645

From stefank at openjdk.org  Mon Dec  9 13:07:55 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Dec 2024 13:07:55 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v3]
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Remove functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22600/files
  - new: https://git.openjdk.org/jdk/pull/22600/files/2da8bade..b0f91bfe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22600&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22600&range=01-02

  Stats: 18 lines in 2 files changed: 0 ins; 18 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22600.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22600/head:pull/22600

PR: https://git.openjdk.org/jdk/pull/22600

From coleenp at openjdk.org  Mon Dec  9 13:08:41 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 13:08:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <2XYWkmFgJ5-7Vhk5-GpOe-YNP_JbeLsRepbpnVV6S2s=.be92ebb7-faa6-4734-97fe-255d71f33aec@github.com>

On Fri, 6 Dec 2024 22:00:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

The JVM call is Class.getModifiers() and there are compiler intrinsics because I guess performance matters for this call.  Although maybe a future RFE could be to add this field to java.lang.Class and have the JVM set it instead and remove the intrinsic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22618#issuecomment-2527876290

From dnsimon at openjdk.org  Mon Dec  9 13:08:41 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 9 Dec 2024 13:08:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <oJRwVuQi7noeBJd-Rdac4oj_L6vLi70y7_Ciac8FkPM=.730ca59e-2dfe-4918-aec3-b1bcf287204b@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

JVMCI changes looks good.

-------------

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2488753749

From stefank at openjdk.org  Mon Dec  9 13:11:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Dec 2024 13:11:40 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
 <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>
Message-ID: <GhOOeqWMkuK0VixIQvaxHfjNtiS9L9FRAtWeeM9N00w=.fcb068b4-bdab-4bd2-af55-ebadb411cca9@github.com>

On Mon, 9 Dec 2024 02:36:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't see the removal of the "moved" functions from ./share/memory/virtualspace.cpp ??

Good point. That got lost in the split-out from my other rewrites.

> src/hotspot/share/runtime/os.hpp line 408:
> 
>> 406:   static size_t vm_page_size() { return OSInfo::vm_page_size(); }
>> 407: 
>> 408:   static size_t align_up_vm_page_size(size_t size)   { return align_up  (size, os::vm_page_size()); }
> 
> Style Nit: please don't add extra whitespace before the opening function parenthesis.

I find that it makes the code easier to read and the rest of the code uses various extra whitespace to make the code clearer. Is this a strong request?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22600#issuecomment-2527880191
PR Review Comment: https://git.openjdk.org/jdk/pull/22600#discussion_r1875955997

From coleenp at openjdk.org  Mon Dec  9 13:12:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 13:12:39 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
Message-ID: <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>

On Mon, 9 Dec 2024 13:00:49 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 1119:
>> 
>>> 1117:   // to support Class.getModifiers().  Instance classes recalculate
>>> 1118:   // the cached flags after the class file is parsed, but before the
>>> 1119:   // class is put into the system dictionary.
>> 
>> Is this comment already out-of-date? I'm trying to see where the flags are recomputed after parsing.
>
> I thought the comment was referring to this code below that late calculates the modifier flags.  Don't know why system dictionary was called out though.

And they're not the same as access flags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1875957344

From qamai at openjdk.org  Mon Dec  9 13:33:11 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 9 Dec 2024 13:33:11 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v7]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  address reviews

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21042/files
  - new: https://git.openjdk.org/jdk/pull/21042/files/a2f59007..85208df1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=05-06

  Stats: 16 lines in 10 files changed: 1 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

PR: https://git.openjdk.org/jdk/pull/21042

From qamai at openjdk.org  Mon Dec  9 13:33:12 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 9 Dec 2024 13:33:12 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v6]
In-Reply-To: <UFG2L64wIRWrNb91hA5yHVAX1P6OyqhglhFQqHDmwpg=.28256995-8ae7-43aa-a2ae-1c82cf8617d7@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <6YeHbHlrPoV9obcfC7g1PtFdMKfanhnsKxqwTZovts4=.f5743961-07e2-4325-b8f5-270edd342e11@github.com>
 <UFG2L64wIRWrNb91hA5yHVAX1P6OyqhglhFQqHDmwpg=.28256995-8ae7-43aa-a2ae-1c82cf8617d7@github.com>
Message-ID: <TR8f7ms7ccmLnYfbgb6dax0Jc-BY-Wv8hm2scYthSgk=.a73bd805-6ebc-4a11-9ce3-1d006c07428d@github.com>

On Mon, 9 Dec 2024 08:10:20 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comment, extract cast into local variable
>
> src/hotspot/share/opto/vectornode.hpp line 1696:
> 
>> 1694: // shuffle vector into 1 that we can do byte rearrange such that it would provide the same result.
>> 1695: // This can be done in VectorRearrangeNode during code emission but we eagerly expand out this
>> 1696: // because it is often the case that an index vector is reused in many rearrange operations.
> 
> Thanks for this explanation!
> 
> `This can be done in VectorRearrangeNode` -> **could have** be done, because we now don't do it, right?
> What do you mean by `expand out this`? Do you mean we have a separate dedicated node, so that it could possibly fold away with other nodes, such as index vector?

Thanks for the reviews, I have added another comment sentence. Basically, by separating into a dedicated node, the preparation of the index vector can be GVN-ed across multiple rearrange operations as well as hoisted out of loops if the index vector is a loop invariant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875985223

From jbhateja at openjdk.org  Mon Dec  9 13:42:40 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 9 Dec 2024 13:42:40 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <R_wVwvHqD5kN17FnPKrPQo6LbmwTvUOHpQkHeUxg8_I=.2c2dc56d-e8d4-4cc8-9ce7-2b36953841d5@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>
 <eRnXECROJ99v9esircLUm1e8qhm71sJDHEWaR3dgbTo=.8e13b46c-0e57-4fcc-be9c-45b9daef12a3@github.com>
 <HUxyGfmcjDzyr34iIP6-SopdTFEKrUA_k2umYczKjK8=.91eec0f2-1a99-4a98-bb57-a8d77670eec5@github.com>
 <R_wVwvHqD5kN17FnPKrPQo6LbmwTvUOHpQkHeUxg8_I=.2c2dc56d-e8d4-4cc8-9ce7-2b36953841d5@github.com>
Message-ID: <s6LHJ0sjTy7QNwZEVkbkdzvMkNiqLpKGpwoAIeuXiFU=.7ab997ed-1bec-4fa7-ad5c-3af14e63b83d@github.com>

On Fri, 6 Dec 2024 17:22:33 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> @sviswa7 @PaulSandoz @eme64 @jatin-bhateja Thanks for taking a look, I have merged the PR with a more recent master and resolved the sematic difference with newly added intrinsics, too.
>
> @merykitty do you want me to initiate tier 1 to 3 tests?

> @PaulSandoz @sviswa7 Thanks for your advice, I have made the PR ready for review
> 
> @iwanowww Could you take another look at this, please?
> 
> @jatin-bhateja Could you verify that [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) does not occur?

Hi @merykitty , I am in process of reviewing, its a big change, allow me couple of days time.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2527985893

From mli at openjdk.org  Mon Dec  9 13:43:37 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 9 Dec 2024 13:43:37 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
 <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
 <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>
Message-ID: <4ZhZOdUYgTbwMUzYqsjjjyWAeoNddQxfTsV9TQRUNJs=.54087dda-d704-40d5-9e57-ce5d743da97e@github.com>

On Mon, 9 Dec 2024 11:12:11 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Yeah. But seems avoidable if we make the loop count smaller for the narrow cases? I think it will be simpler and more readable for people then.
>
> Yes, but doing just 127 incs there, then it is big chance of the threads not running at the same time.
> The point is that they should run parallel a period of time.
> 
> I can nest loops?

Seems to me overflow is fine, it won't affect the test correctness? maybe we could add some comment to state it clearly.
Or maybe we could use something like barrier or phaser in java API to sync the real starting of different threads in the thread group? But I'm not sure if there are such utilities in hotspot test framework.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1875999765

From epeter at openjdk.org  Mon Dec  9 13:49:43 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 9 Dec 2024 13:49:43 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v7]
In-Reply-To: <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>
Message-ID: <JnbmEAUxTP9oePQbQKpGQKU3At9bv-vgI62ZJRjW7KE=.6ec58c45-59a6-4ed8-a858-db67b209871a@github.com>

On Mon, 9 Dec 2024 13:33:11 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address reviews

Ok, looks better.

I've thought about this a little. And I am wondering if we cannot make the use of Rearrange generally easier.

What if we want to use the `VectorRearrangeNode` elsewhere?
One would assume that one could just check
`arch_supports_vector(Op_VectorRearrange, ...elem_bt)`
And then one could emit a `VectorRearrangeNode` for the given `elem_bt`. But that is not the case, the user would have to also check for `Matcher::vector_rearrange_requires_load_shuffle(shuffle_bt, num_elem)`, and possibly add a `VectorLoadShuffleNode`.
I don't like this - it makes the use quite cumbersome.

I have an idea for an alternative:
You add a `VectorRearrangeNode::Ideal`, which then transforms itself if we have `Matcher::vector_rearrange_requires_load_shuffle`.

I have not thought this through to the end, but it just seems it would be easier to use Rearrange in the future this way. But maybe we know that we will never use Rearrange in any other way, then I'm fine with this implementation. What do you think @PaulSandoz ?

src/hotspot/share/opto/vectornode.hpp line 1696:

> 1694: // shuffle vector into one that we can do byte rearrange such that it would provide the same
> 1695: // result. This could have been done in VectorRearrangeNode during code emission but we eagerly
> 1696: // expand out this because it is often the case that an index vector is reused in many rearrange

Suggestion:

// expand this out because it is often the case that an index vector is reused in many rearrange

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2488817071
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1875989393

From kbarrett at openjdk.org  Mon Dec  9 13:57:44 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 9 Dec 2024 13:57:44 GMT
Subject: RFR: 8345589: Simplify Windows definition of strtok_r
In-Reply-To: <dzGMW2apkcK9sMbzZnkQdTPUO0NpaoAmGxFSD9t_Kdo=.3d973462-0031-4c37-afc5-2964c470053e@github.com>
References: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
 <dzGMW2apkcK9sMbzZnkQdTPUO0NpaoAmGxFSD9t_Kdo=.3d973462-0031-4c37-afc5-2964c470053e@github.com>
Message-ID: <Tcg4sbsPaU_-2RKM6uJkjpwn-Dv7tqLWW6-ZjuRsdPI=.96f8c63b-1f5b-4081-aa0d-58bd853789bb@github.com>

On Fri, 6 Dec 2024 06:44:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to move the Windows-specific definition of strtok_r
>> to globalDefinitions_visCPP.hpp.  In addition, the unused S_ISCHR macro is
>> removed and the S_ISFIFO macro is also moved.
>> 
>> Testing: mach5 tier1
>
> Looks good.
> 
> Thanks

Thanks for reviews @dholmes-ora and @TheShermanTanker

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22597#issuecomment-2528017538

From kbarrett at openjdk.org  Mon Dec  9 13:57:45 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 9 Dec 2024 13:57:45 GMT
Subject: Integrated: 8345589: Simplify Windows definition of strtok_r
In-Reply-To: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
References: <UI8ULaxmxUyd5X0MPKFmn53MSLgu13zeTNWt5RQTQj8=.5da18915-1df3-4267-ac61-3265e9b29fd3@github.com>
Message-ID: <CbK9Vs86c3UYQVKlcKthjvt2e7nEkCiY4aKAgtxi1Ck=.433b3738-9d1d-4840-be4f-40c04bc15625@github.com>

On Fri, 6 Dec 2024 06:25:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to move the Windows-specific definition of strtok_r
> to globalDefinitions_visCPP.hpp.  In addition, the unused S_ISCHR macro is
> removed and the S_ISFIFO macro is also moved.
> 
> Testing: mach5 tier1

This pull request has now been integrated.

Changeset: e821d599
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e821d599c8a715af54374218ab285a8d061b174e
Stats:     23 lines in 2 files changed: 14 ins; 8 del; 1 mod

8345589: Simplify Windows definition of strtok_r

Reviewed-by: dholmes, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/22597

From qamai at openjdk.org  Mon Dec  9 13:58:41 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 9 Dec 2024 13:58:41 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v7]
In-Reply-To: <JnbmEAUxTP9oePQbQKpGQKU3At9bv-vgI62ZJRjW7KE=.6ec58c45-59a6-4ed8-a858-db67b209871a@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>
 <JnbmEAUxTP9oePQbQKpGQKU3At9bv-vgI62ZJRjW7KE=.6ec58c45-59a6-4ed8-a858-db67b209871a@github.com>
Message-ID: <-V1kImS-457WoqS_2Qc7jqY4_iAUo-3-PXheVLc_T84=.64706c04-289b-4cf2-9cfc-b95fbd2656bb@github.com>

On Mon, 9 Dec 2024 13:47:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address reviews
>
> Ok, looks better.
> 
> I've thought about this a little. And I am wondering if we cannot make the use of Rearrange generally easier.
> 
> What if we want to use the `VectorRearrangeNode` elsewhere?
> One would assume that one could just check
> `arch_supports_vector(Op_VectorRearrange, ...elem_bt)`
> And then one could emit a `VectorRearrangeNode` for the given `elem_bt`. But that is not the case, the user would have to also check for `Matcher::vector_rearrange_requires_load_shuffle(shuffle_bt, num_elem)`, and possibly add a `VectorLoadShuffleNode`.
> I don't like this - it makes the use quite cumbersome.
> 
> I have an idea for an alternative:
> You add a `VectorRearrangeNode::Ideal`, which then transforms itself if we have `Matcher::vector_rearrange_requires_load_shuffle`.
> 
> I have not thought this through to the end, but it just seems it would be easier to use Rearrange in the future this way. But maybe we know that we will never use Rearrange in any other way, then I'm fine with this implementation. What do you think @PaulSandoz ?

@eme64 Yes I have thought about that. My idea is that once phase lowering is ready we will move the expansion there (#21599) . This removes the need to have a standalone method that checks if `LoadShuffleNode` is needed. The current situation is that `VectorRearrangeNode` is expected to come with `VectorLoadShuffleNode` so you cannot easily work with `VectorRearrangeNode`, either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2528023981

From epeter at openjdk.org  Mon Dec  9 14:01:43 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 9 Dec 2024 14:01:43 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v7]
In-Reply-To: <-V1kImS-457WoqS_2Qc7jqY4_iAUo-3-PXheVLc_T84=.64706c04-289b-4cf2-9cfc-b95fbd2656bb@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>
 <JnbmEAUxTP9oePQbQKpGQKU3At9bv-vgI62ZJRjW7KE=.6ec58c45-59a6-4ed8-a858-db67b209871a@github.com>
 <-V1kImS-457WoqS_2Qc7jqY4_iAUo-3-PXheVLc_T84=.64706c04-289b-4cf2-9cfc-b95fbd2656bb@github.com>
Message-ID: <fy9zsrOecHBh5GYKmBnMW49KttYtNuj8sJaNHQKOTuw=.df0dc9ce-fc01-4197-8f2c-24566a31c9f8@github.com>

On Mon, 9 Dec 2024 13:55:46 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Ok, looks better.
>> 
>> I've thought about this a little. And I am wondering if we cannot make the use of Rearrange generally easier.
>> 
>> What if we want to use the `VectorRearrangeNode` elsewhere?
>> One would assume that one could just check
>> `arch_supports_vector(Op_VectorRearrange, ...elem_bt)`
>> And then one could emit a `VectorRearrangeNode` for the given `elem_bt`. But that is not the case, the user would have to also check for `Matcher::vector_rearrange_requires_load_shuffle(shuffle_bt, num_elem)`, and possibly add a `VectorLoadShuffleNode`.
>> I don't like this - it makes the use quite cumbersome.
>> 
>> I have an idea for an alternative:
>> You add a `VectorRearrangeNode::Ideal`, which then transforms itself if we have `Matcher::vector_rearrange_requires_load_shuffle`.
>> 
>> I have not thought this through to the end, but it just seems it would be easier to use Rearrange in the future this way. But maybe we know that we will never use Rearrange in any other way, then I'm fine with this implementation. What do you think @PaulSandoz ?
>
> @eme64 Yes I have thought about that. My idea is that once phase lowering is ready we will move the expansion there (#21599) . This removes the need to have a standalone method that checks if `LoadShuffleNode` is needed. The current situation is that `VectorRearrangeNode` is expected to come with `VectorLoadShuffleNode` so you cannot easily work with `VectorRearrangeNode`, either.

@merykitty Ok. Is there a chance we could wait for that additional phase to arrive then, and only do this refactor here afterward? I'd also be ok with a follow up RFE - it would just have to be filed and be clear who will take care of it ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2528038627

From qamai at openjdk.org  Mon Dec  9 14:12:19 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 9 Dec 2024 14:12:19 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  adverb order

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21042/files
  - new: https://git.openjdk.org/jdk/pull/21042/files/85208df1..5cfac5ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

PR: https://git.openjdk.org/jdk/pull/21042

From qamai at openjdk.org  Mon Dec  9 14:17:41 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 9 Dec 2024 14:17:41 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v7]
In-Reply-To: <fy9zsrOecHBh5GYKmBnMW49KttYtNuj8sJaNHQKOTuw=.df0dc9ce-fc01-4197-8f2c-24566a31c9f8@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>
 <JnbmEAUxTP9oePQbQKpGQKU3At9bv-vgI62ZJRjW7KE=.6ec58c45-59a6-4ed8-a858-db67b209871a@github.com>
 <-V1kImS-457WoqS_2Qc7jqY4_iAUo-3-PXheVLc_T84=.64706c04-289b-4cf2-9cfc-b95fbd2656bb@github.com>
 <fy9zsrOecHBh5GYKmBnMW49KttYtNuj8sJaNHQKOTuw=.df0dc9ce-fc01-4197-8f2c-24566a31c9f8@github.com>
Message-ID: <k7B2ACZKDbl6GJ7EhJBkW0J7xh2g19o6QaVO4GD491Q=.2666cd3e-c921-40f3-bac5-db48e196ec0a@github.com>

On Mon, 9 Dec 2024 13:59:29 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 Yes I have thought about that. My idea is that once phase lowering is ready we will move the expansion there (#21599) . This removes the need to have a standalone method that checks if `LoadShuffleNode` is needed. The current situation is that `VectorRearrangeNode` is expected to come with `VectorLoadShuffleNode` so you cannot easily work with `VectorRearrangeNode`, either.
>
> @merykitty Ok. Is there a chance we could wait for that additional phase to arrive then, and only do this refactor here afterward? I'd also be ok with a follow up RFE - it would just have to be filed and be clear who will take care of it ;)

@eme64 I think this PR is orthogonal to the concern you are having. Either we need to refactor the expansion to lowering, then modify this PR to match the semantics, or we integrate this PR first, then do the lowering refactor on the resulting code. I would prefer the latter then I can take the task to move `VectorLoadShuffle` creation to lowering afterwards.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2528080973

From epeter at openjdk.org  Mon Dec  9 14:41:41 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 9 Dec 2024 14:41:41 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v7]
In-Reply-To: <k7B2ACZKDbl6GJ7EhJBkW0J7xh2g19o6QaVO4GD491Q=.2666cd3e-c921-40f3-bac5-db48e196ec0a@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>
 <JnbmEAUxTP9oePQbQKpGQKU3At9bv-vgI62ZJRjW7KE=.6ec58c45-59a6-4ed8-a858-db67b209871a@github.com>
 <-V1kImS-457WoqS_2Qc7jqY4_iAUo-3-PXheVLc_T84=.64706c04-289b-4cf2-9cfc-b95fbd2656bb@github.com>
 <fy9zsrOecHBh5GYKmBnMW49KttYtNuj8sJaNHQKOTuw=.df0dc9ce-fc01-4197-8f2c-24566a31c9f8@github.com>
 <k7B2ACZKDbl6GJ7EhJBkW0J7xh2g19o6QaVO4GD491Q=.2666cd3e-c921-40f3-bac5-db48e196ec0a@github.com>
Message-ID: <gL4Nsf1WMH7JEMY6UFHV9Rga1-zPjYrtlJ3WxplTwAg=.450e552f-6b72-43fc-a464-f0e4b8f58df4@github.com>

On Mon, 9 Dec 2024 14:15:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> @merykitty Ok. Is there a chance we could wait for that additional phase to arrive then, and only do this refactor here afterward? I'd also be ok with a follow up RFE - it would just have to be filed and be clear who will take care of it ;)
>
> @eme64 I think this PR is orthogonal to the concern you are having. Either we need to refactor the expansion to lowering, then modify this PR to match the semantics, or we integrate this PR first, then do the lowering refactor on the resulting code. I would prefer the latter then I can take the task to move `VectorLoadShuffle` creation to lowering afterwards.

@merykitty 
> we integrate this PR first, then do the lowering refactor on the resulting code

That is fine with me - I just need to see follow-up RFE filed, and know that it will be taken care of by someone ;)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2528141393

From redestad at openjdk.org  Mon Dec  9 14:44:43 2024
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 9 Dec 2024 14:44:43 GMT
Subject: RFR: 8345405: Add JMH showing the regression in 8341649 [v2]
In-Reply-To: <HWQ7PXEiZOJEszrgcRSxLdK_oc7aKuxuD2zyirpr6CM=.b09101cc-5f38-4e63-b2d7-8e8660024100@github.com>
References: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>
 <HWQ7PXEiZOJEszrgcRSxLdK_oc7aKuxuD2zyirpr6CM=.b09101cc-5f38-4e63-b2d7-8e8660024100@github.com>
Message-ID: <3VsDwVostq5kSjbxGdwSpYq76lI-RJmi3XCA6_XHhTQ=.cf189014-ab90-4010-9a23-8ce9e0846e10@github.com>

On Fri, 6 Dec 2024 17:37:03 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> This JMH using MethodHandles shows the regression in 8341649, for example comparing 24-b25, which included the regression to today's head. It was an interaction between the runtime and C2 rather than a change in MethodHandles.
>> 
>> Here are example results from an Ampere platform:
>> jdk-24-b25 before the fix:
>> Benchmark                (classes)  (instances)   Mode  Cnt   Score   Error   Units
>> MethodHandleStress.work       1000          100  thrpt   20  33.423 ? 7.678  ops/ms
>> 
>> Today's head with the fix:
>> Benchmark                (classes)  (instances)   Mode  Cnt    Score    Error   Units
>> MethodHandleStress.work       1000          100  thrpt   20  709.249 ? 50.575  ops/ms
>
> Eric Caspole has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Code cleanups suggested by Claes
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8345405
>  - 8345405: Add JMH showing the regression in 8341649

Marked as reviewed by redestad (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22556#pullrequestreview-2488998391

From qamai at openjdk.org  Mon Dec  9 14:49:40 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 9 Dec 2024 14:49:40 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v7]
In-Reply-To: <gL4Nsf1WMH7JEMY6UFHV9Rga1-zPjYrtlJ3WxplTwAg=.450e552f-6b72-43fc-a464-f0e4b8f58df4@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <KkEybQfers6SD3O5bVCAXmhNYOsj1zGuR7Dm0q7S9lE=.9abfb443-0f77-413e-9cc4-0d7dcd471e81@github.com>
 <JnbmEAUxTP9oePQbQKpGQKU3At9bv-vgI62ZJRjW7KE=.6ec58c45-59a6-4ed8-a858-db67b209871a@github.com>
 <-V1kImS-457WoqS_2Qc7jqY4_iAUo-3-PXheVLc_T84=.64706c04-289b-4cf2-9cfc-b95fbd2656bb@github.com>
 <fy9zsrOecHBh5GYKmBnMW49KttYtNuj8sJaNHQKOTuw=.df0dc9ce-fc01-4197-8f2c-24566a31c9f8@github.com>
 <k7B2ACZKDbl6GJ7EhJBkW0J7xh2g19o6QaVO4GD491Q=.2666cd3e-c921-40f3-bac5-db48e196ec0a@github.com>
 <gL4Nsf1WMH7JEMY6UFHV9Rga1-zPjYrtlJ3WxplTwAg=.450e552f-6b72-43fc-a464-f0e4b8f58df4@github.com>
Message-ID: <V3wFDhr-r2mAQoWLUVDr3QjuRNC3_ErWBunbHbLGEh4=.bdc4053c-97dd-4ef1-9dec-c7c50e6b28d2@github.com>

On Mon, 9 Dec 2024 14:39:25 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> @eme64 I think this PR is orthogonal to the concern you are having. Either we need to refactor the expansion to lowering, then modify this PR to match the semantics, or we integrate this PR first, then do the lowering refactor on the resulting code. I would prefer the latter then I can take the task to move `VectorLoadShuffle` creation to lowering afterwards.
>
> @merykitty 
>> we integrate this PR first, then do the lowering refactor on the resulting code
> 
> That is fine with me - I just need to see follow-up RFE filed, and know that it will be taken care of by someone ;)

@eme64 Created https://bugs.openjdk.org/browse/JDK-8345812

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2528176181

From ecaspole at openjdk.org  Mon Dec  9 15:01:46 2024
From: ecaspole at openjdk.org (Eric Caspole)
Date: Mon, 9 Dec 2024 15:01:46 GMT
Subject: Integrated: 8345405: Add JMH showing the regression in 8341649
In-Reply-To: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>
References: <yDczndSwmItsrK-_yuWywiy-RmfIwbaPe_2fNEC5BdM=.c85a0cd7-dd25-4d33-8a80-a260c11ffcf6@github.com>
Message-ID: <6pqjcDAztddLEK3l8iGErCNgcayfQEGVtS4HhFZaozw=.9b6ec69b-17c8-4ab4-be5b-0f690a971b24@github.com>

On Wed, 4 Dec 2024 18:55:23 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> This JMH using MethodHandles shows the regression in 8341649, for example comparing 24-b25, which included the regression to today's head. It was an interaction between the runtime and C2 rather than a change in MethodHandles.
> 
> Here are example results from an Ampere platform:
> jdk-24-b25 before the fix:
> Benchmark                (classes)  (instances)   Mode  Cnt   Score   Error   Units
> MethodHandleStress.work       1000          100  thrpt   20  33.423 ? 7.678  ops/ms
> 
> Today's head with the fix:
> Benchmark                (classes)  (instances)   Mode  Cnt    Score    Error   Units
> MethodHandleStress.work       1000          100  thrpt   20  709.249 ? 50.575  ops/ms

This pull request has now been integrated.

Changeset: 35c00532
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/35c00532a1dd2a6df5fc3d5173ca692517675d38
Stats:     175 lines in 1 file changed: 175 ins; 0 del; 0 mod

8345405: Add JMH showing the regression in 8341649

Reviewed-by: redestad, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/22556

From duke at openjdk.org  Mon Dec  9 15:47:48 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 9 Dec 2024 15:47:48 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v9]
In-Reply-To: <es4dw7RYkRF421IZHMv1tCe_jWSQbfzlJ-EyW4Qn4qY=.e333b6cc-f193-4876-a456-ad893777e629@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <es4dw7RYkRF421IZHMv1tCe_jWSQbfzlJ-EyW4Qn4qY=.e333b6cc-f193-4876-a456-ad893777e629@github.com>
Message-ID: <kvWzH5MUxF-Ak0lobf9wUw3VYIUThnSHNq9VrMWNoMU=.674d3ad5-1427-4e7d-98a4-d5abb834e70d@github.com>

On Mon, 9 Dec 2024 10:45:34 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>>  - Adding a runtime flag for selecting the old or new version can be added later.
>>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.
>
> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused local var.

src/hotspot/share/nmt/regionsTree.hpp line 124:

> 122:     size_t rgn_size = 0;
> 123:     size_t comm_size = 0;
> 124:     size_t base = 0;

I think `base` and `comm_size` are unused.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1876223683

From rehn at openjdk.org  Mon Dec  9 16:17:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 9 Dec 2024 16:17:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <4ZhZOdUYgTbwMUzYqsjjjyWAeoNddQxfTsV9TQRUNJs=.54087dda-d704-40d5-9e57-ce5d743da97e@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
 <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
 <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>
 <4ZhZOdUYgTbwMUzYqsjjjyWAeoNddQxfTsV9TQRUNJs=.54087dda-d704-40d5-9e57-ce5d743da97e@github.com>
Message-ID: <ZTcT0Pr8yyd67EMC9lTMlvkbZfEC9q3cLJyLRt3LIOQ=.0ca6f933-bd7e-4972-8c96-d3ae9210621a@github.com>

On Mon, 9 Dec 2024 13:40:52 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Yes, but doing just 127 incs there, then it is big chance of the threads not running at the same time.
>> The point is that they should run parallel a period of time.
>> 
>> I can nest loops?
>
> Seems to me overflow is fine, it won't affect the test correctness? maybe we could add some comment to state it clearly.
> Or maybe we could use something like barrier or phaser in java API to sync the real starting of different threads in the thread group? But I'm not sure if there are such utilities in hotspot test framework.

Those have the same issue, it may take several ms to schedule a thread after it have been release form a barrier thus a short loop taking a few hundreds of nanos have a big chance of not running in parallel.
If you do busy-wait you risk running out of run-quote thus prempted instead.

Perfably one should record the CAS failure and when all threads have had failures we know that they did run concurrently.

So maybe:
Run loops from TESTSIZE min to max, re-run this loop until we record CAS failures or something like that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1876270764

From duke at openjdk.org  Mon Dec  9 16:41:49 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 9 Dec 2024 16:41:49 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <RfIjTEurTj_uv-HsOORUcfvi-YcBjbRIPuIJM9J9n2Y=.fe982bbd-c29c-4652-965e-b6d332feebed@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
 <RfIjTEurTj_uv-HsOORUcfvi-YcBjbRIPuIJM9J9n2Y=.fe982bbd-c29c-4652-965e-b6d332feebed@github.com>
Message-ID: <xDR7XMBE2oKXnAJ6YrlTTATuJ1Kxi8g821CIepdDQtU=.204c132c-db57-4e8e-8a7c-87e7a75a7927@github.com>

On Mon, 9 Dec 2024 10:17:27 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/regionsTree.hpp line 105:
>> 
>>> 103:         if (prev.is_committed_begin()) {
>>> 104:           comm_size += curr.distance_from(prev);
>>> 105:           if (!curr.is_committed_begin()) {
>> 
>> Shouldn't it be impossible to have 2 back-to-back committed regions? Wouldn't they already be coalesced by `VMATree::register_mapping`?
>
> Only regions with the same `MemTag` can be merged into one. It is possible to have two adjacent committed regions with different `MemTag`s.

Ok I see. Thank you for clarifying.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1876311697

From duke at openjdk.org  Mon Dec  9 16:56:47 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 9 Dec 2024 16:56:47 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <-amsFPnNKUzW0EH2d7gYiW0jYU3m8E8QUAVJL6ZC5tQ=.377d5a5a-26e9-41bc-b28f-8e6b46231481@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
 <-amsFPnNKUzW0EH2d7gYiW0jYU3m8E8QUAVJL6ZC5tQ=.377d5a5a-26e9-41bc-b28f-8e6b46231481@github.com>
Message-ID: <D4hYAJcJNfO-V9ILEVnhBDgoEvfETvimDInyw6DZRIM=.89823608-6797-4949-8f98-83f3af38d9b5@github.com>

On Mon, 9 Dec 2024 10:40:03 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/regionsTree.hpp line 94:
>> 
>>> 92:   template<typename F>
>>> 93:   void visit_committed_regions(position start, size_t size, F func) {
>>> 94:     size_t end = start + size + 1;
>> 
>>> Yes it is missed.
>> In the visit_range_in_order code, the variable cmp_to is never checked against 0 (cmp_to == 0).
>> 
>> You are referring to [here](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/nmt/nmtTreap.hpp#L380) right? I think that is actually ok without the +1. The upper boundary, "end", is outside of the range of the region, so probably should not be checked. For example if the region's starting address is 0 and has a size of 10, the last address within the region is 9. "End" in this case is 10 (0+10), and is out of bounds. If we made "end" = 0 + 10 + 1 = 11, then we would be including 10 in the checked range, which isn't right.
>
> The `VMATree` holds the region `[A,B)` as two nodes with `A` and `B`. So, in your example the nodes in the tree are `0` and `10`. Looking for `< 10` does not find `B`, but `< 11` does..
> The case with `end == 11` has no problem also when two regions are adjacent. If the next region has size `10`, for example,  then the nodes are `0`, `10` and `20`. `< 11` will find `10( = B)` and not `20`.

ok I understand. It's because you need to visit both the lower and upper bounds. Thank you for clarifying.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1876341468

From iklam at openjdk.org  Mon Dec  9 17:32:42 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 9 Dec 2024 17:32:42 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
Message-ID: <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>

On Thu, 5 Dec 2024 16:51:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into decode-mode
>  - Recalculate decode mode if OS picks a different encoding.
>  - Only calculate klass-decode-mode in one place.
>  - Missed one. Another good reason to not copy code.
>  - Rename ceil_log2 to log2i_ceil
>  - Merge branch 'master' into decode-mode
>  - Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932
>  - Merge branch 'master' into decode-mode
>  - include formatBuffer.hpp
>  - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

Changes requested by iklam (Reviewer).

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5328:

> 5326: 
> 5327: // Check if one of the above decoding modes will work for given base, shift and range.
> 5328: bool MacroAssembler::check_klass_decode_mode(address base, int shift, const size_t range) {

Can we refactor the code so that `check_klass_decode_mode()` only does the checking and have no side effects?

This code is called from CDS, which sometimes will unmap the archive and retry at an os-assigned random address, so updating the actual base/shift here will be problematic.

src/hotspot/share/cds/metaspaceShared.cpp line 1496:

> 1494:                   p2i(base_address), precomputed_narrow_klass_shift);
> 1495:     use_archive_base_addr = false;
> 1496:   }

It seems there's no easy way of testing this code, as the `base_address` need to come from a CDS archive, but the CDS archive cannot contain invalid base addresses.

Maybe we should change this to `log_error()`, or even `fatal()`

test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 87:

> 85: 
> 86:         // We ignore cases where we were not able to map at the force address
> 87:         if (!output.contains("Successfully forced class space address to " + forceAddressString)) {

"Successfully forced class space address" seems misleading. Can we change the code in metaspace.cpp to say something like "reserved class space at ...."?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21695#pullrequestreview-2489481553
PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876384125
PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876392335
PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876389280

From coleenp at openjdk.org  Mon Dec  9 17:43:40 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 17:43:40 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
Message-ID: <-8rQ3Ts0YquVyoNrW_SAOS_oqjdF9vmmrYmh1qqDcks=.2e6b9a7e-2cc0-4a02-974c-29b942331fcf@github.com>

On Thu, 5 Dec 2024 16:51:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into decode-mode
>  - Recalculate decode mode if OS picks a different encoding.
>  - Only calculate klass-decode-mode in one place.
>  - Missed one. Another good reason to not copy code.
>  - Rename ceil_log2 to log2i_ceil
>  - Merge branch 'master' into decode-mode
>  - Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932
>  - Merge branch 'master' into decode-mode
>  - include formatBuffer.hpp
>  - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

Thanks for your comments Ioi.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21695#pullrequestreview-2489526410

From coleenp at openjdk.org  Mon Dec  9 17:43:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 17:43:42 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
 <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>
Message-ID: <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>

On Mon, 9 Dec 2024 17:21:59 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into decode-mode
>>  - Recalculate decode mode if OS picks a different encoding.
>>  - Only calculate klass-decode-mode in one place.
>>  - Missed one. Another good reason to not copy code.
>>  - Rename ceil_log2 to log2i_ceil
>>  - Merge branch 'master' into decode-mode
>>  - Merge with incoming change for PR https://github.com/openjdk/jdk/pull/21932
>>  - Merge branch 'master' into decode-mode
>>  - include formatBuffer.hpp
>>  - 8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5328:
> 
>> 5326: 
>> 5327: // Check if one of the above decoding modes will work for given base, shift and range.
>> 5328: bool MacroAssembler::check_klass_decode_mode(address base, int shift, const size_t range) {
> 
> Can we refactor the code so that `check_klass_decode_mode()` only does the checking and have no side effects?
> 
> This code is called from CDS, which sometimes will unmap the archive and retry at an os-assigned random address, so updating the actual base/shift here will be problematic.

My first patch did that, but it had to copy the code to see if the encoding could use Movk.  I think I do like that better to not have side effects since the code has to be called again to have the correct decode mode after allocation succeeds.

> src/hotspot/share/cds/metaspaceShared.cpp line 1496:
> 
>> 1494:                   p2i(base_address), precomputed_narrow_klass_shift);
>> 1495:     use_archive_base_addr = false;
>> 1496:   }
> 
> It seems there's no easy way of testing this code, as the `base_address` need to come from a CDS archive, but the CDS archive cannot contain invalid base addresses.
> 
> Maybe we should change this to `log_error()`, or even `fatal()`

If this is a log-error or fatal, then maybe we should give an error for an invalid SharedBaseAddress, as with Thomas's suggested patch.  We generally try to get SharedBaseAddress and that fails, let the OS code pick one.  If we want to give an error for invalid SharedBaseAddress, I could fix the test that fails to not try for an invalid address.  But the validity of the address is only for aarch64 so I don't know if we want to do this.

> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 87:
> 
>> 85: 
>> 86:         // We ignore cases where we were not able to map at the force address
>> 87:         if (!output.contains("Successfully forced class space address to " + forceAddressString)) {
> 
> "Successfully forced class space address" seems misleading. Can we change the code in metaspace.cpp to say something like "reserved class space at ...."?

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876410676
PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876414312
PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876415087

From duke at openjdk.org  Mon Dec  9 17:48:47 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 9 Dec 2024 17:48:47 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <xDR7XMBE2oKXnAJ6YrlTTATuJ1Kxi8g821CIepdDQtU=.204c132c-db57-4e8e-8a7c-87e7a75a7927@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
 <RfIjTEurTj_uv-HsOORUcfvi-YcBjbRIPuIJM9J9n2Y=.fe982bbd-c29c-4652-965e-b6d332feebed@github.com>
 <xDR7XMBE2oKXnAJ6YrlTTATuJ1Kxi8g821CIepdDQtU=.204c132c-db57-4e8e-8a7c-87e7a75a7927@github.com>
Message-ID: <S1qAIxpYogPn-wxPX4ZW2TDs3DEUlQTUBbjvYG_8dCs=.75cc3985-72d0-4fff-8c8c-5c9e604a2970@github.com>

On Mon, 9 Dec 2024 16:38:48 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Only regions with the same `MemTag` can be merged into one. It is possible to have two adjacent committed regions with different `MemTag`s.
>
> Ok I see. Thank you for clarifying.

I have a couple more questions about this function:

Why bother keeping the variable `base`. It's updated whenever `prev` is updated, so why not just use `prev`?

Why do you allow for grouping two adjacent committed regions w/ diff `MemTags` together when creating `CommittedMemoryRegion`? Shouldn't they be treated as separate committed regions?  And if we are supposed to be grouping adjacent regions, shouldn't we be using the address of the first region, not the current one, when creating `CommittedMemoryRegion` (since we've been incrementing `comm_size`)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1876423806

From iklam at openjdk.org  Mon Dec  9 17:54:38 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 9 Dec 2024 17:54:38 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
 <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>
 <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
Message-ID: <4yR7HVddjw91l2mQbH__YMCb5zOYLx5vmbPYkOeM9HQ=.dbbe4d6d-7e57-4e27-8f99-a4a5cedd9ce4@github.com>

On Mon, 9 Dec 2024 17:40:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/cds/metaspaceShared.cpp line 1496:
>> 
>>> 1494:                   p2i(base_address), precomputed_narrow_klass_shift);
>>> 1495:     use_archive_base_addr = false;
>>> 1496:   }
>> 
>> It seems there's no easy way of testing this code, as the `base_address` need to come from a CDS archive, but the CDS archive cannot contain invalid base addresses.
>> 
>> Maybe we should change this to `log_error()`, or even `fatal()`
>
> If this is a log-error or fatal, then maybe we should give an error for an invalid SharedBaseAddress, as with Thomas's suggested patch.  We generally try to get SharedBaseAddress and that fails, let the OS code pick one.  If we want to give an error for invalid SharedBaseAddress, I could fix the test that fails to not try for an invalid address.  But the validity of the address is only for aarch64 so I don't know if we want to do this.

`base_address` here is not from user input. It is something produced by the JVM after validity checks. So if we have an error it, we JVM has done something wrong. I think a fatal() would be apropriate.

In contract, SharedBaseAddress can be specified by the user, and we usually do not use fatal() to report such errors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876435288

From mchung at openjdk.org  Mon Dec  9 18:01:37 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 9 Dec 2024 18:01:37 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <SReh6u2czEgXid48w9XheeErSgeSc3O2_NKZFcl3nCc=.7c7f1e0e-cc65-4344-900d-e6e2fde25358@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22607#pullrequestreview-2489586744

From psandoz at openjdk.org  Mon Dec  9 18:23:41 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 9 Dec 2024 18:23:41 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
Message-ID: <zw5O8guzTleaK0c2TFaq-3En-S-OPWT_qe_JwZmtkh8=.a86c4720-590e-4e1e-81ca-8a77ff7f65eb@github.com>

On Mon, 9 Dec 2024 14:12:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adverb order

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2489632745

From liach at openjdk.org  Mon Dec  9 18:37:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 18:37:42 GMT
Subject: [jdk24] RFR: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <-vHUTV6ABJZEaxVGeZ2FytzgMEIx-Cdcgm_I5TIuxo4=.5f76bd21-9378-4e52-949b-06ad59192bab@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22607#issuecomment-2529047739

From liach at openjdk.org  Mon Dec  9 18:37:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Dec 2024 18:37:43 GMT
Subject: [jdk24] Integrated: 8334733: Remove obsolete @enablePreview from tests
 after JDK-8334714
In-Reply-To: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
References: <nIq__4-5O-FUhciTk3r1NgxDQjdDmF6xib3MKvB2CBY=.b88642c6-9389-4c9a-957a-cec148435a6c@github.com>
Message-ID: <pKY85AZzy2hqc6ksUGd7oUO5wOaRP9FPj4dS5pha6k4=.f8a0d57a-a0c4-46cc-994e-844867b88e09@github.com>

On Fri, 6 Dec 2024 15:11:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [49664195](https://github.com/openjdk/jdk/commit/496641955041c5e48359e6256a4a61812653d900) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> This is a test-only change so it is eligible for backport; in addition, this change is logically part of the Class-File API finalized in JDK 24.
> 
> The commit being backported was authored by Chen Liang on 6 Dec 2024 and was reviewed by Mandy Chung and Adam Sotona.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a8132543
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a81325433d7da6b73abb37ea3e33489d0a3afbae
Stats:     634 lines in 360 files changed: 2 ins; 555 del; 77 mod

8334733: Remove obsolete @enablePreview from tests after JDK-8334714

Reviewed-by: mchung
Backport-of: 496641955041c5e48359e6256a4a61812653d900

-------------

PR: https://git.openjdk.org/jdk/pull/22607

From aph at redhat.com  Mon Dec  9 18:51:21 2024
From: aph at redhat.com (Andrew Haley)
Date: Mon, 9 Dec 2024 18:51:21 +0000
Subject: RFD: Enhance crash log output when disassembler is not present
Message-ID: <64f29c94-8191-4a0b-99d4-7b5e675fef7e@redhat.com>

Several times recently I have received a HotSpot error log from a user
who did not have hsdis installed. Which, in practice, means most end users.
The trouble it that the disassembly is unreadable.

The disassembly printed, when hsdis is not present, looks like this:

[MachCode]
[Instructions begin]
   ;; N526: #	out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
    0x00007f0c40564c20: 9090 448b | 5608 443b

    0x00007f0c40564c28: ;   {runtime_call Shared Runtime ic_miss_blob}
    0x00007f0c40564c28: 5008 0f85 | b0d4 9aff
[Verified Entry Point]
   ;; B1: #	out( B34 B2 ) <- BLOCK HEAD IS JUNK  Freq: 1
    0x00007f0c40564c30: 8984 2400 | 80fe ff55 | 4883 ec60 | 4181 7f20 | 0100 0000 | 0f85 d806

    0x00007f0c40564c48: ;*synchronization entry
                        ; - java.lang.StringBuilder::append at -1 (line 246)
    0x00007f0c40564c48: 0000 8954 | 2410 488b | de4d 33c0 | 450f be00

    0x00007f0c40564c58: ;*getfield value {reexecute=0 rethrow=0 return_oop=0}
                        ; - java.lang.AbstractStringBuilder::ensureCapacityInternal at 1 (line 244)
                        ; - java.lang.AbstractStringBuilder::append at 7 (line 804)
                        ; - java.lang.StringBuilder::append at 2 (line 246)
    0x00007f0c40564c58: 448b 4614

    0x00007f0c40564c5c: ; implicit exception: dispatches to 0x00007f0c405651a8
    0x00007f0c40564c5c: 478b 4cc4

I'd like to change it in the following ways:

- Replace the ";" with a platform-defined comment character
- Replace the address with a comment
- Replace the hex format with a line parseable by an assembler, in a platform-defined format
- A few other minor things

So we end up with something which is like this: not quite as nice, but legal assembler
syntax, retaining all comments:

# [MachCode]
# [Instructions begin]
      .text
      .org 0x4c20
  ## N526: #	out( B1 ) <- BLOCK HEAD IS JUNK  Freq: 1
   /* 00007f0c40564c20: */ .byte 0x90, 0x90,  0x44, 0x8b,  0x56, 0x08,  0x44, 0x3b

   /* 00007f0c40564c28: */ #   {runtime_call Shared Runtime ic_miss_blob}
   /* 00007f0c40564c28: */ .byte 0x50, 0x08,  0x0f, 0x85,  0xb0, 0xd4,  0x9a, 0xff
# [Verified Entry Point]
  ## B1: #	out( B34 B2 ) <- BLOCK HEAD IS JUNK  Freq: 1
   /* 00007f0c40564c30: */ .byte 0x89, 0x84,  0x24, 0x00,  0x80, 0xfe,  0xff, 0x55,  0x48, 0x83,  0xec, 0x60,  0x41, 0x81,  0x7f, 0x20,  0x01, 0x00,  0x00, 0x00,  0x0f, 0x85,  0xd8, 0x06

   /* 00007f0c40564c48: */ #*synchronization entry
                           # - java.lang.StringBuilder::append at -1 (line 246)
   /* 00007f0c40564c48: */ .byte 0x00, 0x00, 0x89, 0x54, 0x24, 0x10, 0x48, 0x8b, 0x4d, 0xde, 0x33, 0xc0, 0x0f, 0x45, 0xbe, 0x00

And it can then be assembled with a platform assembler, requiring no other tools:

     4c20:	90                   	nop
     4c21:	90                   	nop
     4c22:	44 8b 56 08          	mov    0x8(%rsi),%r10d
     4c26:	44 3b 50 08          	cmp    0x8(%rax),%r10d
     4c2a:	0f 85 b0 d4 9a ff    	jne    0xffffffffff9b20e0
     4c30:	89 84 24 00 80 fe ff 	mov    %eax,-0x18000(%rsp)
     4c37:	55                   	push   %rbp
     4c38:	48 83 ec 60          	sub    $0x60,%rsp
     ...

Obviously this is a little scrappy at present, and needs a good deal of tidying
up to be suitable for mainline. I'm asking for an "in principle" answer here:
if I could do a neat job, maintaining readability but making sure that in the
absence of hsdis we can print something that a maintenance programmer can easily
assemble and dump, would people be interested?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From lmesnik at openjdk.org  Mon Dec  9 19:11:41 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 9 Dec 2024 19:11:41 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <Uq7cEcm2q_x2J5-PyN8TMmorCceBVtWO5YgVfK44Hrg=.ce9b48ca-d26e-4897-9bf1-a3be09f2a7a4@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

Thanks, Alexey. I filed https://bugs.openjdk.org/browse/JDK-8345824 to re-balance tier1 parts.
However, it is not related to current issue that fix tier2/3 testing only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22614#issuecomment-2529135568

From sspitsyn at openjdk.org  Mon Dec  9 20:04:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 9 Dec 2024 20:04:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <qHJoOG-oixqaOUOjQwxGRYPzhlrzp_7Q5QzaSvDkeqE=.7f469a1b-946e-4da9-8efa-0a8bf222ceab@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

I've looked at the Serviceability related copyright updates (prims, SA, debugger and tests). They are good.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2489952883

From mullan at openjdk.org  Mon Dec  9 20:22:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 9 Dec 2024 20:22:37 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <lXCn1OYDxgZvEIA8zkPNEwV271_hrS4AOtnWHYmAbWk=.fca579b0-1483-4157-8ff5-c7363f62cb86@github.com>

On Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

The security related files look fine.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22645#pullrequestreview-2489994087

From eirbjo at openjdk.org  Mon Dec  9 20:40:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Dec 2024 20:40:37 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <XFdVBCbvENDsRKeUsEO5KeGz9wc_s3IKe9ljxibLTB8=.58247179-46c9-478c-8908-c4a800e4a4c4@github.com>

On Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/favicon.ico line 1:


This file should probably not be included?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22645#discussion_r1876722968

From coleenp at openjdk.org  Mon Dec  9 20:47:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 20:47:04 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v11]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <-8PgpcNg6sV8Dbwxbcicc9S2Cj0A646BsLr5UtQnE1I=.fb9faa0a-1850-43cc-9c1d-cbd204fb15d0@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Ioi's refactoring idea.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21695/files
  - new: https://git.openjdk.org/jdk/pull/21695/files/a6567d66..9c810609

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=09-10

  Stats: 25 lines in 5 files changed: 12 ins; 1 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From coleenp at openjdk.org  Mon Dec  9 20:54:41 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 20:54:41 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <4yR7HVddjw91l2mQbH__YMCb5zOYLx5vmbPYkOeM9HQ=.dbbe4d6d-7e57-4e27-8f99-a4a5cedd9ce4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
 <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>
 <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
 <4yR7HVddjw91l2mQbH__YMCb5zOYLx5vmbPYkOeM9HQ=.dbbe4d6d-7e57-4e27-8f99-a4a5cedd9ce4@github.com>
Message-ID: <vU2q42QKFd6HPm0S83Nbghqb8wqO2vwMk9xFz0j0XiM=.2bf8691e-cda6-4cef-8007-62152392cfb0@github.com>

On Mon, 9 Dec 2024 17:51:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> If this is a log-error or fatal, then maybe we should give an error for an invalid SharedBaseAddress, as with Thomas's suggested patch.  We generally try to get SharedBaseAddress and that fails, let the OS code pick one.  If we want to give an error for invalid SharedBaseAddress, I could fix the test that fails to not try for an invalid address.  But the validity of the address is only for aarch64 so I don't know if we want to do this.
>
> `base_address` here is not from user input. It is something produced by the JVM after validity checks. So if we have an error it, we JVM has done something wrong. I think a fatal() would be apropriate.
> 
> In contract, SharedBaseAddress can be specified by the user, and we usually do not use fatal() to report such errors.

SharedBaseAddress comes through here also.  It was valid at one point but UseCompactObjectHeaders forces the shift to be 10 so on using the shared archive, it might not be correct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876734231

From coleenp at openjdk.org  Mon Dec  9 20:54:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 20:54:42 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
 <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>
 <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
Message-ID: <JtNp0sg7J6FXpQrgNxljXH7wG87Eg5TQ_OT8H1PIrq0=.0998c5eb-0d33-4023-a2a1-c3f7ad1785a3@github.com>

On Mon, 9 Dec 2024 17:40:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointersEncodingScheme.java line 87:
>> 
>>> 85: 
>>> 86:         // We ignore cases where we were not able to map at the force address
>>> 87:         if (!output.contains("Successfully forced class space address to " + forceAddressString)) {
>> 
>> "Successfully forced class space address" seems misleading. Can we change the code in metaspace.cpp to say something like "reserved class space at ...."?
>
> Ok.

Oh the "forced" was because it was using CompressedClassSpaceBaseAddress which does force it to use this address (or else it exits).  So it is accurate.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876737139

From ihse at openjdk.org  Mon Dec  9 21:02:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:02:03 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert mistaken changes to binary file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22645/files
  - new: https://git.openjdk.org/jdk/pull/22645/files/01702dae..edbc3fbb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22645&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22645&range=00-01

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22645/head:pull/22645

PR: https://git.openjdk.org/jdk/pull/22645

From ihse at openjdk.org  Mon Dec  9 21:02:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:02:03 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <XFdVBCbvENDsRKeUsEO5KeGz9wc_s3IKe9ljxibLTB8=.58247179-46c9-478c-8908-c4a800e4a4c4@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
 <XFdVBCbvENDsRKeUsEO5KeGz9wc_s3IKe9ljxibLTB8=.58247179-46c9-478c-8908-c4a800e4a4c4@github.com>
Message-ID: <QclRpS3TYbQDX84ps89kmFxTvOIDXdp-RrgAtPb3-9w=.5912b974-1011-41dd-9695-bc367b63cc81@github.com>

On Mon, 9 Dec 2024 20:38:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert mistaken changes to binary file
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/favicon.ico line 1:
> 
> 
> This file should probably not be included?

Correct, that is a mistake. Reverted the change now.

My script had a bug which made some binary files be "converted" from CRLF to LF format, making unintended changes. I've verified that there are no more such issues in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22645#discussion_r1876748379

From ihse at openjdk.org  Mon Dec  9 21:09:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:09:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert mistaken changes to binary files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22637/files
  - new: https://git.openjdk.org/jdk/pull/22637/files/0166c68e..5610a605

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22637&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22637&range=01-02

  Stats: 0 lines in 5 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22637.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22637/head:pull/22637

PR: https://git.openjdk.org/jdk/pull/22637

From coleenp at openjdk.org  Mon Dec  9 23:11:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 23:11:08 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v12]
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <6HkfR42LT1I19LZ22OxrHj5TFa0vmp8Pp25U0UkJJwk=.94d9fdb1-27d3-4b31-805c-df572e2932e3@github.com>

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Comment why shared_base_valid() can't actually check for us whether the shared base is valid.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21695/files
  - new: https://git.openjdk.org/jdk/pull/21695/files/9c810609..36eae88c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21695&range=10-11

  Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21695.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21695/head:pull/21695

PR: https://git.openjdk.org/jdk/pull/21695

From coleenp at openjdk.org  Mon Dec  9 23:11:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 23:11:08 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
 <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>
 <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
Message-ID: <tJu-sUaAFW7HT1muWE3rxNUAj9huIHqlWwDHqLqen_c=.aead161b-5c39-4b16-83a0-eab03471d62a@github.com>

On Mon, 9 Dec 2024 17:38:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5328:
>> 
>>> 5326: 
>>> 5327: // Check if one of the above decoding modes will work for given base, shift and range.
>>> 5328: bool MacroAssembler::check_klass_decode_mode(address base, int shift, const size_t range) {
>> 
>> Can we refactor the code so that `check_klass_decode_mode()` only does the checking and have no side effects?
>> 
>> This code is called from CDS, which sometimes will unmap the archive and retry at an os-assigned random address, so updating the actual base/shift here will be problematic.
>
> My first patch did that, but it had to copy the code to see if the encoding could use Movk.  I think I do like that better to not have side effects since the code has to be called again to have the correct decode mode after allocation succeeds.

Yes, refactored.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876885586

From coleenp at openjdk.org  Mon Dec  9 23:11:08 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 9 Dec 2024 23:11:08 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v10]
In-Reply-To: <vU2q42QKFd6HPm0S83Nbghqb8wqO2vwMk9xFz0j0XiM=.2bf8691e-cda6-4cef-8007-62152392cfb0@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <JIKkX8SQAa2ifuiSfrIFZ9t0DJZ0sBN-X5hJoOw4eOc=.4cd5bcd5-da02-418b-a920-7d4890a1be6f@github.com>
 <VaOqGf9TEABbd75JRv_m1n8MstMoWcsZ--R1HS0ZlmM=.1df5d544-14f6-4651-8824-8d9d75a8fd75@github.com>
 <jgYd_Erb3JQKB9jdQvdA3vfwUJ4XH8jfS-R3isaIFJo=.0f1bdb49-decb-44fe-80ce-2877bc119351@github.com>
 <4yR7HVddjw91l2mQbH__YMCb5zOYLx5vmbPYkOeM9HQ=.dbbe4d6d-7e57-4e27-8f99-a4a5cedd9ce4@github.com>
 <vU2q42QKFd6HPm0S83Nbghqb8wqO2vwMk9xFz0j0XiM=.2bf8691e-cda6-4cef-8007-62152392cfb0@github.com>
Message-ID: <nnY-pwG2g2FdOaAEUgLsNYKKEyXwalsRvPqJGhz4sqw=.25f1d32b-4b5f-4597-8df2-3679e4ce7eba@github.com>

On Mon, 9 Dec 2024 20:48:01 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> `base_address` here is not from user input. It is something produced by the JVM after validity checks. So if we have an error it, we JVM has done something wrong. I think a fatal() would be apropriate.
>> 
>> In contract, SharedBaseAddress can be specified by the user, and we usually do not use fatal() to report such errors.
>
> SharedBaseAddress comes through here also.  It was valid at one point but UseCompactObjectHeaders forces the shift to be 10 so on using the shared archive, it might not be correct.

I added a comment why the validity check in -Xshare:dump doesn't actually check this and doesn't really have the full reservation size so it can check it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21695#discussion_r1876887124

From iklam at openjdk.org  Tue Dec 10 00:03:38 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 10 Dec 2024 00:03:38 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v12]
In-Reply-To: <6HkfR42LT1I19LZ22OxrHj5TFa0vmp8Pp25U0UkJJwk=.94d9fdb1-27d3-4b31-805c-df572e2932e3@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <6HkfR42LT1I19LZ22OxrHj5TFa0vmp8Pp25U0UkJJwk=.94d9fdb1-27d3-4b31-805c-df572e2932e3@github.com>
Message-ID: <TyTd4EkEVEykl1jeDF9tDbDybDjIpYPQcGq-l9gBBJM=.0800025c-0364-4d6b-b715-8c07fc03db26@github.com>

On Mon, 9 Dec 2024 23:11:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment why shared_base_valid() can't actually check for us whether the shared base is valid.

LGTM

-------------

Marked as reviewed by iklam (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21695#pullrequestreview-2490422711

From jwaters at openjdk.org  Tue Dec 10 00:47:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 00:47:04 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v14]
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <JFVUhIS0rqMcrnSYlBGN79EMEFcySJoMp3fF44Bn0t8=.52d9fd70-4422-473a-af32-cd49bdbb4a9b@github.com>

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - _WINDOWS && AARCH64 in sharedRuntime.hpp
 - AARCH64 in sharedRuntimeRem.cpp
 - Refactor sharedRuntime.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21627/files
  - new: https://git.openjdk.org/jdk/pull/21627/files/54930315..9ecb1d3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=12-13

  Stats: 19 lines in 3 files changed: 6 ins; 8 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627

PR: https://git.openjdk.org/jdk/pull/21627

From jwaters at openjdk.org  Tue Dec 10 00:49:46 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 00:49:46 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v9]
In-Reply-To: <AbxvNiIurm6uI7Ha_wdL6ebaBuKD1PGR7F9fpOWz8U0=.57f5dac2-8270-4176-ac23-3a69a60dfff2@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <YU0PDdMIMQQY3rjz0AkSMcl21Uq17Bay3vGTMrKVvOQ=.b3dd9566-7c63-4164-9381-1ca49243bbb7@github.com>
 <be92SHlPie5VD6ipLlTVrsUsaGx6DbLyODlLdmZDrBY=.28f9d32c-2f26-4661-b880-616bc9bc4a16@github.com>
 <1RZ35U_xZFsOsgdYo3gM3ft_EbcmkeA83kiGw4-uHLc=.d6e06d25-e5a1-413a-a208-ced180e2104d@github.com>
 <nQwm3HnT8Z5GBiL_h2bWgHdbLqamXs0F5LDhFKmMtDU=.fcee4d05-3ea3-4cd9-b35d-253cb8d9b276@github.com>
 <KRb9WJdrf7x7kYNXW3KqqIiMPBFrL7jU-57ouEp3diQ=.cd9e7363-cfa4-495e-85a3-a40f1f932304@github.com>
 <lwS7tQIfEkodI-q-jUhwS0ZkJCdBQpDLszjZEmKL470=.f5a09a1a-b83c-4e2a-8032-c923b37b6469@github.com>
 <e14qFKNLo0MrdSiecAHCZdPfn9PGuBDOio0RqimwIcc=.24e33262-f2e9-45ef-95f0-6f6b4c235115@github.com>
 <oB-MXKx5SA3JklBtrLrsyPO7DO4Zvdyp4XM1sczX7E4=.82935b1a-b030-4ab5-9cb6-4bd095153ce5@github.com>
 <tgH4gmDfrqW3jyjZ93Wh7pOSZ5Snqrfbkg4QSKmpwMo=.e0fee72a-0ad2-455b-ba5f-e77e308fad99@github.com>
 <zmEUYIbYsKzzMLPP4xRCwtcymdehGz-MnS-
 ZR0nygm8=.1e5e7d57-5c71-49c1-b5ee-1fefab59260f@github.com>
 <Cvgn6yeSuONcQSud1mgZA2D3OoHvDUmVcHwjKrvI02I=.a8cb3e2c-7624-4ba7-92a3-ee81e07df042@github.com>
 <M6xkFGips-BPJMQ7E1IzPV0Cn_aEOcz8CsHZc9n4fCE=.eb8fa987-c09a-4800-a153-8240656e2b25@github.com>
 <Wmb7dzm_GcZoJ9L8woV04MIV3Td70GpXU_8JbPG7rEM=.d7859a33-534c-423d-8952-24abbc65f2a6@github.com>
 <u3LSCur-Em1mhttj_6b6RiuHqmBZOeTztQKGWxJKa2w=.9fb680c2-7d95-45b1-8d6d-f48c679ef935@github.com>
 <AbxvNiIurm6uI7Ha_wdL6ebaBuKD1PGR7F9fpOWz8U0=.57f5dac2-8270-4176-ac23-3a69a60dfff2@github.com>
Message-ID: <33hzdYbUbFv5GPV-U480-WlxxJ-OHB5lm3hPhzG6ynE=.3e2e1bbe-a3ff-44f3-9dab-0aed77c2da01@github.com>

On Mon, 9 Dec 2024 09:38:33 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Ah, I see what you mean. There's just a small change I would make, which is to check whether defined(_WINDOWS) and defined(AARCH64) instead. Checking for both _M_ARM64 and _WINDOWS is redundant; _M_ARM64 is a Windows only define, so checking for _M_ARM64 == checking for AARCH64 && _WINDOWS. Would you be ok with that instead?
>> 
>> I think(?) I get what you mean by having 2 blocks, I'll try to do that
>> 
>>> Sorry I'm doing a really bad job of pretending to be the preprocessor. :)
>> 
>> Haha, it happens
>
>> Ah, I see what you mean. There's just a small change I would make, which is to check whether defined(_WINDOWS) and defined(AARCH64) instead. Checking for both _M_ARM64 and _WINDOWS is redundant; _M_ARM64 is a Windows only define, so checking for _M_ARM64 == checking for AARCH64 && _WINDOWS.
> 
> Checking for `AARCH64 && _WINDOWS` is much easier to understand.

Andrew and David, are the latest changes what you had in mind?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1876992308

From kim.barrett at oracle.com  Tue Dec 10 00:56:55 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Mon, 9 Dec 2024 19:56:55 -0500
Subject: Poisoning in HotSpot
In-Reply-To: <048a76f8-38b5-454e-b427-5bdadeae702d@oracle.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
 <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
 <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>
 <e6474fe1-8f0d-494f-b06b-31d816f26c86@oracle.com>
 <bbc1d875-0a34-4789-b96b-e5fe14cc6b6a@oracle.com>
 <337d3e32-57c0-45b7-81bb-6ce6f8174ad2@oracle.com>
 <048a76f8-38b5-454e-b427-5bdadeae702d@oracle.com>
Message-ID: <aae37bc2-6a48-4e48-b1e3-910995254a42@oracle.com>

On 12/4/24 7:42 AM, Kim Barrett wrote:
> On 12/1/24 7:09 PM, David Holmes wrote:
>>
>> Somewhat crude but couldn't gtests #define USING_GTEST before 
>> including our headers and then we could make the forbidden stuff 
>> conditional on ifndef USING_GTEST. ?? 
>
> Things are more complicated than that, unfortunately.
>
> I think I might have a way forward, in part using that kind of thing.? 
> But it might interfere with other future work.
>
>
I have something very sketchy that "works", using the namespace 
manipulation.
That's in the sense that I can build with all three of gcc, clang, and 
VS, and
get build failures if the permission mechanism isn't used where needed.
However, I think it's very fragile, and I'm not happy with it.

The fundamental problem is that there isn't a way to turn it off over some
non-local region. This leads to problems when header that isn't ours but is
included by us uses any of the names we want to poison. It means such 
headers
must be included before the poisoning. We haven't run into this problem much
because glibc takes great pains to not be affected by outside 
definitions, via
all the leading underscores in that code. Other libraries, not so much. For
example, several names that we poison are referenced by the <new> header 
from
clang/Xcode.

This could be worked around to some extent by putting wrappers around 3rd
party headers that provide names we poison, and including those wrappers
instead of directly including the 3rd party headers.? Those wrappers could
contain the poisoning of names from the wrapped header, and before that
include any other using 3rd party headers.? But this is pretty clumsy, with
lots of overinclusions where not needed if not for the poisoning. It also
seems very fragile.

I might still consider that route if there wasn't another alternative.
Fortunately, I think there is.

I think I've figured out how to get the "add deprecation attributes" 
approach
to work with all three compilers.? In particular, I've figured out how to
augment declarations in MSVC++, which had previously eluded me.

This also runs into problems with our inclusion of 3rd party headers 
that use
names we want to poison. But unlike the namespace manipulation approach, 
this
approach has a way to suppress the poisoning over a non-local region, e.g.
using appropriate pragmas in a pragma-push/pop range. So to solve a problem
like clang's <new>, we add a wrapper that disables deprecation warnings 
around
inclusion of that header, and we include the wrapper rather than <new>
directly.

I've done a bit of prototyping in this direction, and I think I've come up
with a pretty good approach.? It's not completely bullet-proof, but 
neither is
the current mechanism, nor the namespace manipulation mechanism. But I think
this 3rd approach has better usage features and is easier to maintain.? I'll
describe it in more detail once I've got something more fully worked out.



From dholmes at openjdk.org  Tue Dec 10 02:23:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 02:23:23 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v4]
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <1hr5aKPCvZvhyOH9l6UEEfOLD87WafveqEnkfD1IYZI=.b78570d3-0c55-412c-bbd8-97cc1afaca1a@github.com>

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix missing multiple-include guards
  Added explicit includes instead of forward decls (trying to track down unrelated Windows build failure)
  Fixed indent of assertion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22472/files
  - new: https://git.openjdk.org/jdk/pull/22472/files/a65a1452..cfdb7da0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=02-03

  Stats: 13 lines in 1 file changed: 7 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22472/head:pull/22472

PR: https://git.openjdk.org/jdk/pull/22472

From fyang at openjdk.org  Tue Dec 10 02:32:43 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 10 Dec 2024 02:32:43 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <ZTcT0Pr8yyd67EMC9lTMlvkbZfEC9q3cLJyLRt3LIOQ=.0ca6f933-bd7e-4972-8c96-d3ae9210621a@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
 <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
 <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>
 <4ZhZOdUYgTbwMUzYqsjjjyWAeoNddQxfTsV9TQRUNJs=.54087dda-d704-40d5-9e57-ce5d743da97e@github.com>
 <ZTcT0Pr8yyd67EMC9lTMlvkbZfEC9q3cLJyLRt3LIOQ=.0ca6f933-bd7e-4972-8c96-d3ae9210621a@github.com>
Message-ID: <kGKF6qqQdyKLh8HvwWk3jb7-Tp66vgD6KRi0r5tuheA=.50f5f50b-5ac2-4090-82c7-53f220afbcbe@github.com>

On Mon, 9 Dec 2024 16:14:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> So maybe: Run loops from TESTSIZE min to max, re-run this loop until we record CAS failures or something like that?

Seens to me that would be very similar with the current approach. How about we make the wrap around here explicit? Say, when the `oldvalue` reaches TESTSIZE max, we set the `newvalue` to TESTSIZE min. And we set the final expect value in `data` accordingly instead of doing a type truncation. Then we don't depend on the implementation of the compiler.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1877117033

From fyang at openjdk.org  Tue Dec 10 03:44:39 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 10 Dec 2024 03:44:39 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <ddqQyT7Z-5bWnf6gyLLxFcyDP8lCEHCp5EBcJCpxmM0=.fb1fb665-4f2e-4db4-8c05-f0d41bec056a@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <ddqQyT7Z-5bWnf6gyLLxFcyDP8lCEHCp5EBcJCpxmM0=.fb1fb665-4f2e-4db4-8c05-f0d41bec056a@github.com>
Message-ID: <1Djm3z7LkJf843xFS7SYig0sxaad1m4KaUyLFg7FxUI=.75cbe0d8-45de-4438-9f37-6eaecf0ca762@github.com>

On Mon, 9 Dec 2024 03:01:16 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>  - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter

src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp line 892:

> 890:                                          nullptr, /*L_success*/
> 891:                                          &miss    /*L_failure*/);
> 892: 

Could you please add a code comment about extra regsiters used for table lookup? We reserve several more in `MacroAssembler::check_klass_subtype_slow_path_table`.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 2882:

> 2880:   assert_different_registers(src, tmp);
> 2881: 
> 2882:   li(tmp, 64);

Suggestion: `mv(tmp, 64);`

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4350:

> 4348:   tmp3_reg = allocate_if_noreg(tmp3_reg, available_regs, pushed_regs);
> 4349:   tmp4_reg = allocate_if_noreg(tmp4_reg, available_regs, pushed_regs);
> 4350:   tmp5_reg = allocate_if_noreg(tmp5_reg, available_regs, pushed_regs);

`tmp5_reg` allocated but not used here?

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 3018:

> 3016:     __ lookup_secondary_supers_table_const(r_sub_klass, r_super_klass, result,
> 3017:                                            r_array_base, r_array_length, r_array_index,
> 3018:                                            r_bitmap, super_klass_index, true);

Maybe add some code comment the final param, like: `/*stub_is_near*/true`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1877233295
PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1875334741
PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1877229921
PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1877183603

From vladimir.x.ivanov at oracle.com  Tue Dec 10 03:56:50 2024
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 9 Dec 2024 19:56:50 -0800
Subject: RFD: Enhance crash log output when disassembler is not present
In-Reply-To: <64f29c94-8191-4a0b-99d4-7b5e675fef7e@redhat.com>
References: <64f29c94-8191-4a0b-99d4-7b5e675fef7e@redhat.com>
Message-ID: <7956c9e1-fe84-4e1a-a257-278a4b4c3cdd@oracle.com>

Personally, I like your proposal to make the output of abstract 
disassembler trivially parseable by existing platform tools.

In absense of hsdis library, it's already cryptic enough not to be 
negatively affected by extra formatting being proposed. And it would be 
very convenient to just feed a block into an assembler tool and get a 
readable assembly back.

Alternatively, an hsdis-based tool to parse existing output format can 
be introduced, but just relying on platform assembler looks like a 
simpler solution (both from usability and maintenance perspective).

Best regards,
Vladimir Ivanov

On 12/9/24 10:51, Andrew Haley wrote:
> Several times recently I have received a HotSpot error log from a user
> who did not have hsdis installed. Which, in practice, means most end users.
> The trouble it that the disassembly is unreadable.
> 
> The disassembly printed, when hsdis is not present, looks like this:
> 
> [MachCode]
> [Instructions begin]
>  ? ;; N526: #??? out( B1 ) <- BLOCK HEAD IS JUNK? Freq: 1
>  ?? 0x00007f0c40564c20: 9090 448b | 5608 443b
> 
>  ?? 0x00007f0c40564c28: ;?? {runtime_call Shared Runtime ic_miss_blob}
>  ?? 0x00007f0c40564c28: 5008 0f85 | b0d4 9aff
> [Verified Entry Point]
>  ? ;; B1: #??? out( B34 B2 ) <- BLOCK HEAD IS JUNK? Freq: 1
>  ?? 0x00007f0c40564c30: 8984 2400 | 80fe ff55 | 4883 ec60 | 4181 7f20 | 
> 0100 0000 | 0f85 d806
> 
>  ?? 0x00007f0c40564c48: ;*synchronization entry
>  ?????????????????????? ; - java.lang.StringBuilder::append at -1 (line 246)
>  ?? 0x00007f0c40564c48: 0000 8954 | 2410 488b | de4d 33c0 | 450f be00
> 
>  ?? 0x00007f0c40564c58: ;*getfield value {reexecute=0 rethrow=0 
> return_oop=0}
>  ?????????????????????? ; - 
> java.lang.AbstractStringBuilder::ensureCapacityInternal at 1 (line 244)
>  ?????????????????????? ; - java.lang.AbstractStringBuilder::append at 7 
> (line 804)
>  ?????????????????????? ; - java.lang.StringBuilder::append at 2 (line 246)
>  ?? 0x00007f0c40564c58: 448b 4614
> 
>  ?? 0x00007f0c40564c5c: ; implicit exception: dispatches to 
> 0x00007f0c405651a8
>  ?? 0x00007f0c40564c5c: 478b 4cc4
> 
> I'd like to change it in the following ways:
> 
> - Replace the ";" with a platform-defined comment character
> - Replace the address with a comment
> - Replace the hex format with a line parseable by an assembler, in a 
> platform-defined format
> - A few other minor things
> 
> So we end up with something which is like this: not quite as nice, but 
> legal assembler
> syntax, retaining all comments:
> 
> # [MachCode]
> # [Instructions begin]
>  ???? .text
>  ???? .org 0x4c20
>  ?## N526: #??? out( B1 ) <- BLOCK HEAD IS JUNK? Freq: 1
>  ? /* 00007f0c40564c20: */ .byte 0x90, 0x90,? 0x44, 0x8b,? 0x56, 0x08,  
> 0x44, 0x3b
> 
>  ? /* 00007f0c40564c28: */ #?? {runtime_call Shared Runtime ic_miss_blob}
>  ? /* 00007f0c40564c28: */ .byte 0x50, 0x08,? 0x0f, 0x85,? 0xb0, 0xd4,  
> 0x9a, 0xff
> # [Verified Entry Point]
>  ?## B1: #??? out( B34 B2 ) <- BLOCK HEAD IS JUNK? Freq: 1
>  ? /* 00007f0c40564c30: */ .byte 0x89, 0x84,? 0x24, 0x00,? 0x80, 0xfe,  
> 0xff, 0x55,? 0x48, 0x83,? 0xec, 0x60,? 0x41, 0x81,? 0x7f, 0x20,? 0x01, 
> 0x00,? 0x00, 0x00,? 0x0f, 0x85,? 0xd8, 0x06
> 
>  ? /* 00007f0c40564c48: */ #*synchronization entry
>  ????????????????????????? # - java.lang.StringBuilder::append at -1 (line 
> 246)
>  ? /* 00007f0c40564c48: */ .byte 0x00, 0x00, 0x89, 0x54, 0x24, 0x10, 
> 0x48, 0x8b, 0x4d, 0xde, 0x33, 0xc0, 0x0f, 0x45, 0xbe, 0x00
> 
> And it can then be assembled with a platform assembler, requiring no 
> other tools:
> 
>  ??? 4c20:??? 90?????????????????????? nop
>  ??? 4c21:??? 90?????????????????????? nop
>  ??? 4c22:??? 44 8b 56 08????????????? mov??? 0x8(%rsi),%r10d
>  ??? 4c26:??? 44 3b 50 08????????????? cmp??? 0x8(%rax),%r10d
>  ??? 4c2a:??? 0f 85 b0 d4 9a ff??????? jne??? 0xffffffffff9b20e0
>  ??? 4c30:??? 89 84 24 00 80 fe ff???? mov??? %eax,-0x18000(%rsp)
>  ??? 4c37:??? 55?????????????????????? push?? %rbp
>  ??? 4c38:??? 48 83 ec 60????????????? sub??? $0x60,%rsp
>  ??? ...
> 
> Obviously this is a little scrappy at present, and needs a good deal of 
> tidying
> up to be suitable for mainline. I'm asking for an "in principle" answer 
> here:
> if I could do a neat job, maintaining readability but making sure that 
> in the
> absence of hsdis we can print something that a maintenance programmer 
> can easily
> assemble and dump, would people be interested?
> 


From dholmes at openjdk.org  Tue Dec 10 04:01:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 04:01:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <FQqaRMK8sCtC8DH4iJZXU2jWhNYIWiDtVgT0DTyN1jQ=.3df4d81c-39ef-4496-8ba5-ee17cb00e606@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

I scanned the full diff and also did some random checks. Looks good. Thanks for fixing.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2490894140

From dholmes at openjdk.org  Tue Dec 10 05:19:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 05:19:48 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v14]
In-Reply-To: <JFVUhIS0rqMcrnSYlBGN79EMEFcySJoMp3fF44Bn0t8=.52d9fd70-4422-473a-af32-cd49bdbb4a9b@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <JFVUhIS0rqMcrnSYlBGN79EMEFcySJoMp3fF44Bn0t8=.52d9fd70-4422-473a-af32-cd49bdbb4a9b@github.com>
Message-ID: <UiD5aeFFmA1Y_R_asw_n8oH2Fi1pLCFwKrI-d5Q8yPg=.5f3d71f6-99a0-4902-8371-b2898994cca1@github.com>

On Tue, 10 Dec 2024 00:47:04 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - _WINDOWS && AARCH64 in sharedRuntime.hpp
>  - AARCH64 in sharedRuntimeRem.cpp
>  - Refactor sharedRuntime.cpp

That seems a lot clearer to me now - thanks.

Just one query below.

src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:

> 26: #include "runtime/sharedRuntime.hpp"
> 27: 
> 28: #ifdef AARCH64

Shouldn't this also be

#if defined(_WINDOWS) && defined(AARCH64)

?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21627#pullrequestreview-2490993838
PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1877321284

From jwaters at openjdk.org  Tue Dec 10 06:10:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 06:10:28 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v15]
In-Reply-To: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
Message-ID: <V6_HK5nJ3toWNn4G3tC0vbnuGSh-3H9GvJmbsNNcW58=.fc7dc3ce-dd04-4e2f-8750-f17e00864764@github.com>

> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:

 - Merge branch 'openjdk:master' into hotspot
 - _WINDOWS && AARCH64 in sharedRuntime.hpp
 - AARCH64 in sharedRuntimeRem.cpp
 - Refactor sharedRuntime.cpp
 - CAST_FROM_FN_PTR in os_windows.cpp
 - Merge branch 'openjdk:master' into hotspot
 - fmod_winarm64 in sharedRuntime.cpp
 - fmod_winarm64 in sharedRuntimeRem.cpp
 - fmod_winarm64 in sharedRuntime.hpp
 - Typo in sharedRuntimeRem.cpp
 - ... and 17 more: https://git.openjdk.org/jdk/compare/7fc50104...ff1c4664

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21627/files
  - new: https://git.openjdk.org/jdk/pull/21627/files/9ecb1d3c..ff1c4664

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21627&range=13-14

  Stats: 1741 lines in 514 files changed: 721 ins; 760 del; 260 mod
  Patch: https://git.openjdk.org/jdk/pull/21627.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21627/head:pull/21627

PR: https://git.openjdk.org/jdk/pull/21627

From jwaters at openjdk.org  Tue Dec 10 06:10:28 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 06:10:28 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v14]
In-Reply-To: <UiD5aeFFmA1Y_R_asw_n8oH2Fi1pLCFwKrI-d5Q8yPg=.5f3d71f6-99a0-4902-8371-b2898994cca1@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <JFVUhIS0rqMcrnSYlBGN79EMEFcySJoMp3fF44Bn0t8=.52d9fd70-4422-473a-af32-cd49bdbb4a9b@github.com>
 <UiD5aeFFmA1Y_R_asw_n8oH2Fi1pLCFwKrI-d5Q8yPg=.5f3d71f6-99a0-4902-8371-b2898994cca1@github.com>
Message-ID: <8W5NN1uVKKL3oEG0rEwa_LvW9pA9lbwU2LQysnOnNqs=.df33d029-1f2d-4a27-b8cf-15612cc71483@github.com>

On Tue, 10 Dec 2024 05:13:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - _WINDOWS && AARCH64 in sharedRuntime.hpp
>>  - AARCH64 in sharedRuntimeRem.cpp
>>  - Refactor sharedRuntime.cpp
>
> src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:
> 
>> 26: #include "runtime/sharedRuntime.hpp"
>> 27: 
>> 28: #ifdef AARCH64
> 
> Shouldn't this also be
> 
> #if defined(_WINDOWS) && defined(AARCH64)
> 
> ?

sharedRuntimeRem.cpp is a Windows only file - Checking for _WINDOWS for a file under os/windows is somewhat redundant

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1877403199

From tschatzl at openjdk.org  Tue Dec 10 07:20:38 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Dec 2024 07:20:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <46K2W9LUIv9jOu7TEtm4Js4TfgzBRyfwhntnqdaQTUY=.f4c7b046-942b-4fc9-9bb5-8690b1f33391@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

lgtm, looked at gc files in both shared and cpu and os specific directories.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2491237029

From dholmes at openjdk.org  Tue Dec 10 07:31:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 07:31:44 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v3]
In-Reply-To: <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
Message-ID: <954m7aVM_NrvlBuiYfZnDyb3uQkzTZ8G9s3MqQ8ggYE=.96c4002a-19c5-40e4-ae14-886459154b45@github.com>

On Mon, 9 Dec 2024 13:07:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
>> 
>> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove functions

Looks good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22600#pullrequestreview-2491269342

From dholmes at openjdk.org  Tue Dec 10 07:31:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 07:31:45 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <GhOOeqWMkuK0VixIQvaxHfjNtiS9L9FRAtWeeM9N00w=.fcb068b4-bdab-4bd2-af55-ebadb411cca9@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
 <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>
 <GhOOeqWMkuK0VixIQvaxHfjNtiS9L9FRAtWeeM9N00w=.fcb068b4-bdab-4bd2-af55-ebadb411cca9@github.com>
Message-ID: <FkXy9ZnN_MN_E0b9lZjvxh0rndeGy54eOYO6k-V5cQk=.41aaf05b-ee97-4335-868e-c630fdb6b4b5@github.com>

On Mon, 9 Dec 2024 13:08:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 408:
>> 
>>> 406:   static size_t vm_page_size() { return OSInfo::vm_page_size(); }
>>> 407: 
>>> 408:   static size_t align_up_vm_page_size(size_t size)   { return align_up  (size, os::vm_page_size()); }
>> 
>> Style Nit: please don't add extra whitespace before the opening function parenthesis.
>
> I find that it makes the code easier to read and the rest of the code uses various extra whitespace to make the code clearer. Is this a strong request?

No not a strong request. I see there is precedent for this already in the file - though in some cases it isn't even needed for alignment purposes. I find extra whitespace between a function name and the opening parenthesis to be visually jarring and it makes me have to re-read to ensure I'm not mis-reading something. YMMV.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22600#discussion_r1877485988

From epeter at openjdk.org  Tue Dec 10 07:41:48 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 10 Dec 2024 07:41:48 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
Message-ID: <1o7SVdc2O38FfuDSOK7eyuQaAtdQIwwa3K5LLWVQI6I=.ee0eb00c-e6f0-4b78-bedf-eafb52269968@github.com>

On Mon, 9 Dec 2024 14:12:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adverb order

Nice Work @merykitty !

The hpp/cpp VM changes look good to me.
I guess you now only have 1 review for Java changes, and 1 review for C++ changes, not sure if that means you need someone more to review, maybe just a sanity check.

I linked the other two issues on JBS for tracking purposes.

I have heard that you might want to backport this to JDK24. For that it would be very important that this patch has gone through thorough testing, including our internal stress-testing.

-------------

Marked as reviewed by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2491298320

From epeter at openjdk.org  Tue Dec 10 07:47:40 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 10 Dec 2024 07:47:40 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
Message-ID: <H6-U0lq2-vTlUvzRQJpfklU4PHEfK8TMcHKj7pY0UlM=.499d8d26-b56e-46f8-8628-db6ffb75b584@github.com>

On Mon, 9 Dec 2024 14:12:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adverb order

FYI: I launched tier1-4 + stress-testing. Please check that it completes and passes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2530695581

From jbhateja at openjdk.org  Tue Dec 10 07:50:46 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Dec 2024 07:50:46 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
Message-ID: <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>

On Mon, 9 Dec 2024 14:12:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adverb order

Hi @merykitty ,

Nice work!,  over all looks good to me with some mincro comments.

Kindly address.

src/hotspot/share/opto/library_call.hpp line 358:

> 356:   bool inline_vector_shuffle_to_vector();
> 357:   bool inline_vector_wrap_shuffle_indexes();
> 358:   bool inline_vector_shuffle_iota();

FTR, x86 ISA does not support a direct byte multiplier instruction, so we first unpack to a short vector, multiply at a short granularity, and then pack it back to byte vector. This was somewhat costly since now shuffle backing storage matches the lane size of the corresponding vector. Hence, computation with a non-unit scalar should improve.

src/hotspot/share/opto/vectornode.hpp line 1691:

> 1689: };
> 1690: 
> 1691: // The machine may not directly support the rearrange operation of an element type. In those cases,

``
Suggestion:

// The target may not directly support the rearrange operation for an element type. In those cases,

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 822:

> 820:         static final Class<Byte> ETYPE = byte.class; // used by the JVM
> 821: 
> 822:         Byte128Shuffle(byte[] indices) {

We still cannot accommodate all the indexes for the 2048 bit scalable vector for ARM SVE. Max index accommodable is 127 since byte is a signed type with value range b/w [-128 , 127].

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java line 1046:

> 1044:                     String msg = ("index "+si+"out of range ["+length+"] in "+
> 1045:                                   java.util.Arrays.toString(indices));
> 1046:                     throw new AssertionError(msg);

Why not directly throw IndexOutOfBoundsException here?

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java line 859:

> 857:                         .reinterpretAsInts()
> 858:                         .intoArray(a, offset);
> 859:                 default -> {

These cases for length() = 4, 8, and 16 looks redundant for 128-bit DeoubleVector.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2491206953
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877513236
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877491672
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877459622
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877452008
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877466991

From dholmes at openjdk.org  Tue Dec 10 07:53:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 07:53:47 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v14]
In-Reply-To: <8W5NN1uVKKL3oEG0rEwa_LvW9pA9lbwU2LQysnOnNqs=.df33d029-1f2d-4a27-b8cf-15612cc71483@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <JFVUhIS0rqMcrnSYlBGN79EMEFcySJoMp3fF44Bn0t8=.52d9fd70-4422-473a-af32-cd49bdbb4a9b@github.com>
 <UiD5aeFFmA1Y_R_asw_n8oH2Fi1pLCFwKrI-d5Q8yPg=.5f3d71f6-99a0-4902-8371-b2898994cca1@github.com>
 <8W5NN1uVKKL3oEG0rEwa_LvW9pA9lbwU2LQysnOnNqs=.df33d029-1f2d-4a27-b8cf-15612cc71483@github.com>
Message-ID: <XuMZL9KaOSJTSBLxGAy76aBcilIRUiecicXH4WaTSVA=.f0bb65bf-bc0a-4ad6-ba89-107f6f19e943@github.com>

On Tue, 10 Dec 2024 06:06:49 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/hotspot/os/windows/sharedRuntimeRem.cpp line 28:
>> 
>>> 26: #include "runtime/sharedRuntime.hpp"
>>> 27: 
>>> 28: #ifdef AARCH64
>> 
>> Shouldn't this also be
>> 
>> #if defined(_WINDOWS) && defined(AARCH64)
>> 
>> ?
>
> sharedRuntimeRem.cpp is a Windows only file - Checking for _WINDOWS for a file under os/windows is somewhat redundant

Sorry, missed that. Please ignore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21627#discussion_r1877520557

From gcao at openjdk.org  Tue Dec 10 07:53:54 2024
From: gcao at openjdk.org (Gui Cao)
Date: Tue, 10 Dec 2024 07:53:54 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v4]
In-Reply-To: <1Djm3z7LkJf843xFS7SYig0sxaad1m4KaUyLFg7FxUI=.75cbe0d8-45de-4438-9f37-6eaecf0ca762@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <ddqQyT7Z-5bWnf6gyLLxFcyDP8lCEHCp5EBcJCpxmM0=.fb1fb665-4f2e-4db4-8c05-f0d41bec056a@github.com>
 <1Djm3z7LkJf843xFS7SYig0sxaad1m4KaUyLFg7FxUI=.75cbe0d8-45de-4438-9f37-6eaecf0ca762@github.com>
Message-ID: <iW2rUv0WL_DPIk8LujwJEIoLEK0P_oLLqkbfSm4o05A=.0d6c8c42-ff5a-4ab3-a16f-68c26e197b88@github.com>

On Tue, 10 Dec 2024 03:41:28 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Gui Cao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8342881
>>  - 8342881: RISC-V: secondary_super_cache does not scale well: C1 and interpreter
>
> src/hotspot/cpu/riscv/c1_Runtime1_riscv.cpp line 892:
> 
>> 890:                                          nullptr, /*L_success*/
>> 891:                                          &miss    /*L_failure*/);
>> 892: 
> 
> Could you please add a code comment about extra regsiters used for table lookup? We reserve several more in `MacroAssembler::check_klass_subtype_slow_path_table`.

Thanks for your review, and all comments related have been fixed!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1877520645

From gcao at openjdk.org  Tue Dec 10 07:53:52 2024
From: gcao at openjdk.org (Gui Cao)
Date: Tue, 10 Dec 2024 07:53:52 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v5]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <uX8kCHNAjMzAEUV_yeXdISy9UegzPDCY6YLMDTDk_iw=.a4fce981-2c68-4426-8a76-a6a0909a5de9@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request incrementally with one additional commit since the last revision:

  Update for RealFYang's comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21922/files
  - new: https://git.openjdk.org/jdk/pull/21922/files/1ee5b6d9..f9ca53a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=03-04

  Stats: 5 lines in 3 files changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922

PR: https://git.openjdk.org/jdk/pull/21922

From dholmes at openjdk.org  Tue Dec 10 07:53:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 07:53:46 GMT
Subject: RFR: 8342769: HotSpot Windows/gcc port is broken [v15]
In-Reply-To: <V6_HK5nJ3toWNn4G3tC0vbnuGSh-3H9GvJmbsNNcW58=.fc7dc3ce-dd04-4e2f-8750-f17e00864764@github.com>
References: <nZ1O5wnRDCVpx03U-q6TLHKxjoP5fwT4VPNchHwO1_w=.fcc5381a-e2c9-48eb-8656-aa3cd2a06300@github.com>
 <V6_HK5nJ3toWNn4G3tC0vbnuGSh-3H9GvJmbsNNcW58=.fc7dc3ce-dd04-4e2f-8750-f17e00864764@github.com>
Message-ID: <lcISi5drFGOjRM3zI_54UTjIQlmo8mv27NGfj5Zq5i4=.adf0acb9-39ca-40f4-a316-3418d3a8fdb4@github.com>

On Tue, 10 Dec 2024 06:10:28 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several areas in HotSpot are broken in the gcc port. These, with the exception of 1 rather big oversight within SharedRuntime::frem and SharedRuntime::drem, are all minor correctness issues within the code. These mostly can be fixed with simple changes to the code. Note that I am not sure whether the SharedRuntime::frem and SharedRuntime::drem fix is correct. It may be that they can be removed entirely
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into hotspot
>  - _WINDOWS && AARCH64 in sharedRuntime.hpp
>  - AARCH64 in sharedRuntimeRem.cpp
>  - Refactor sharedRuntime.cpp
>  - CAST_FROM_FN_PTR in os_windows.cpp
>  - Merge branch 'openjdk:master' into hotspot
>  - fmod_winarm64 in sharedRuntime.cpp
>  - fmod_winarm64 in sharedRuntimeRem.cpp
>  - fmod_winarm64 in sharedRuntime.hpp
>  - Typo in sharedRuntimeRem.cpp
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/9e1f0f31...ff1c4664

Marked as reviewed by dholmes (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21627#pullrequestreview-2491326474

From jbhateja at openjdk.org  Tue Dec 10 07:57:43 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Dec 2024 07:57:43 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
 <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
Message-ID: <WWecPHcDsjY89X1j-0BxH82gI1gRzVxxc6tHNIpNctk=.31ff2f74-cfe8-43f0-8441-5538c870ead2@github.com>

On Tue, 10 Dec 2024 07:09:33 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adverb order
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 822:
> 
>> 820:         static final Class<Byte> ETYPE = byte.class; // used by the JVM
>> 821: 
>> 822:         Byte128Shuffle(byte[] indices) {
> 
> We still cannot accommodate all the indexes for the 2048 bit scalable vector for ARM SVE. Max index accommodable is 127 since byte is a signed type with value range b/w [-128 , 127].

This is a limitation and not a blocker for this re-factor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877524772

From qamai at openjdk.org  Tue Dec 10 08:16:19 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 08:16:19 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v9]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <RY9M6wF5zoDq8QdBVH-HaFwXtpvGqB1tutZJFzYf4GM=.87e0e5c5-e691-46b3-814b-3f5ecc53b02e@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  Change wording on VectorLoadShuffleNode
  
  Co-authored-by: Jatin Bhateja <jatin.bhateja at intel.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21042/files
  - new: https://git.openjdk.org/jdk/pull/21042/files/5cfac5ad..146c8cea

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

PR: https://git.openjdk.org/jdk/pull/21042

From qamai at openjdk.org  Tue Dec 10 08:16:20 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 08:16:20 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <WWecPHcDsjY89X1j-0BxH82gI1gRzVxxc6tHNIpNctk=.31ff2f74-cfe8-43f0-8441-5538c870ead2@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
 <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
 <WWecPHcDsjY89X1j-0BxH82gI1gRzVxxc6tHNIpNctk=.31ff2f74-cfe8-43f0-8441-5538c870ead2@github.com>
Message-ID: <G_RMrJ1_kUYsKQZIQzyElnItZ583bkZkeJI-WkPOZR8=.51791050-692f-4fe2-9bb3-de9d24583a85@github.com>

On Tue, 10 Dec 2024 07:54:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 822:
>> 
>>> 820:         static final Class<Byte> ETYPE = byte.class; // used by the JVM
>>> 821: 
>>> 822:         Byte128Shuffle(byte[] indices) {
>> 
>> We still cannot accommodate all the indexes for the 2048 bit scalable vector for ARM SVE. Max index accommodable is 127 since byte is a signed type with value range b/w [-128 , 127].
>
> This is a limitation and not a blocker for this re-factor.

A byte is just a bunch of bits, the signness of the value depends on how it is used. As a result, I believe there is nothing preventing us from treating this index as unsigned for 2048-bit SVE (with some modifications such as the Java implementation being `int ei = Integer.remainderUnsigned(Byte.toUnsignedInt(s_.laneSource(i)), v1.length())`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877545203

From qamai at openjdk.org  Tue Dec 10 08:26:50 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 08:26:50 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <s6LHJ0sjTy7QNwZEVkbkdzvMkNiqLpKGpwoAIeuXiFU=.7ab997ed-1bec-4fa7-ad5c-3af14e63b83d@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>
 <eRnXECROJ99v9esircLUm1e8qhm71sJDHEWaR3dgbTo=.8e13b46c-0e57-4fcc-be9c-45b9daef12a3@github.com>
 <HUxyGfmcjDzyr34iIP6-SopdTFEKrUA_k2umYczKjK8=.91eec0f2-1a99-4a98-bb57-a8d77670eec5@github.com>
 <R_wVwvHqD5kN17FnPKrPQo6LbmwTvUOHpQkHeUxg8_I=.2c2dc56d-e8d4-4cc8-9ce7-2b36953841d5@github.com>
 <s6LHJ0sjTy7QNwZEVkbkdzvMkNiqLpKGpwoAIeuXiFU=.7ab997ed-1bec-4fa7-ad5c-3af14e63b83d@github.com>
Message-ID: <6whsrtGFBfphNcz96T31a4qxDtGCUjLPV_eQDu1rPY8=.8b25ab50-580e-4420-826f-a8c4dbd84fb6@github.com>

On Mon, 9 Dec 2024 13:40:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> @merykitty do you want me to initiate tier 1 to 3 tests?
>
>> @PaulSandoz @sviswa7 Thanks for your advice, I have made the PR ready for review
>> 
>> @iwanowww Could you take another look at this, please?
>> 
>> @jatin-bhateja Could you verify that [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) does not occur?
> 
> Hi @merykitty , I am in process of reviewing, its a big change, allow me couple of days time.

@jatin-bhateja Thanks a lot for your review and suggestions, I hope I have addressed all of them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2530777876

From qamai at openjdk.org  Tue Dec 10 08:26:51 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 08:26:51 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v9]
In-Reply-To: <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
 <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
Message-ID: <mvhCpfU-99ZIVck8LO7qjjMGUCtbQEmwzFv8kzjFjmE=.594e7d61-b510-48fc-a3e1-8e216e87f635@github.com>

On Tue, 10 Dec 2024 07:44:57 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change wording on VectorLoadShuffleNode
>>   
>>   Co-authored-by: Jatin Bhateja <jatin.bhateja at intel.com>
>
> src/hotspot/share/opto/library_call.hpp line 358:
> 
>> 356:   bool inline_vector_shuffle_to_vector();
>> 357:   bool inline_vector_wrap_shuffle_indexes();
>> 358:   bool inline_vector_shuffle_iota();
> 
> FTR, x86 ISA does not support a direct byte multiplier instruction, so we first unpack to a short vector, multiply at a short granularity, and then pack it back to byte vector. This was somewhat costly since now shuffle backing storage matches the lane size of the corresponding vector. Hence, the perofmance of iota computation with a non-unit scalar should improve.

I believe with the type information of vector elements this optimization should be trivial.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877566967

From qamai at openjdk.org  Tue Dec 10 08:26:53 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 08:26:53 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
 <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
Message-ID: <6yhvabADaFjfg6DLQXTXSyOapN45WsW5vbSgdu7ZpXM=.e0ef06b5-5ba3-4f7e-b364-fb95909a9acd@github.com>

On Tue, 10 Dec 2024 07:01:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adverb order
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java line 1046:
> 
>> 1044:                     String msg = ("index "+si+"out of range ["+length+"] in "+
>> 1045:                                   java.util.Arrays.toString(indices));
>> 1046:                     throw new AssertionError(msg);
> 
> Why not directly throw IndexOutOfBoundsException here?

This is called in an `assert` so I think throwing `AssertionError` seems more reasonable, the original implementation also throws `AssertionError`

> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java line 859:
> 
>> 857:                         .reinterpretAsInts()
>> 858:                         .intoArray(a, offset);
>> 859:                 default -> {
> 
> These cases for length() = 4, 8, and 16 looks redundant for 128-bit DeoubleVector.

You are right, but this switch is needed for `DoubleMaxVector`, and using it for the other species simplifies the template. The compiler will eliminate all wrong cases so there should be no runtime concern.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877563187
PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877559527

From jbhateja at openjdk.org  Tue Dec 10 08:38:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Dec 2024 08:38:44 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v9]
In-Reply-To: <RY9M6wF5zoDq8QdBVH-HaFwXtpvGqB1tutZJFzYf4GM=.87e0e5c5-e691-46b3-814b-3f5ecc53b02e@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <RY9M6wF5zoDq8QdBVH-HaFwXtpvGqB1tutZJFzYf4GM=.87e0e5c5-e691-46b3-814b-3f5ecc53b02e@github.com>
Message-ID: <zGoA72-poI1HxF1sGcVwB1iezPeODYc3s1bOQJctAs4=.39153bb0-5ce7-4823-bea6-1fb14922d173@github.com>

On Tue, 10 Dec 2024 08:16:19 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change wording on VectorLoadShuffleNode
>   
>   Co-authored-by: Jatin Bhateja <jatin.bhateja at intel.com>

I am observing some performance drops in slice / unslice benchmarks,  I have just completed this run and not got a chance to root cause.
![image](https://github.com/user-attachments/assets/ecb686b6-c3b0-47e9-9325-40341c19ff9d)

Can you kindly verify once at your end.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2530801116

From rehn at openjdk.org  Tue Dec 10 08:42:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 10 Dec 2024 08:42:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <kGKF6qqQdyKLh8HvwWk3jb7-Tp66vgD6KRi0r5tuheA=.50f5f50b-5ac2-4090-82c7-53f220afbcbe@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
 <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
 <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>
 <4ZhZOdUYgTbwMUzYqsjjjyWAeoNddQxfTsV9TQRUNJs=.54087dda-d704-40d5-9e57-ce5d743da97e@github.com>
 <ZTcT0Pr8yyd67EMC9lTMlvkbZfEC9q3cLJyLRt3LIOQ=.0ca6f933-bd7e-4972-8c96-d3ae9210621a@github.com>
 <kGKF6qqQdyKLh8HvwWk3jb7-Tp66vgD6KRi0r5tuheA=.50f5f50b-5ac2-4090-82c7-53f220afbcbe@github.com>
Message-ID: <XYP-pbmnLPO6nA622KZ2TNXNNCQG72fxIrFwe2GajHM=.89f5d13e-5016-417f-bd3e-3fe0fd78dc98@github.com>

On Tue, 10 Dec 2024 02:29:31 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Those have the same issue, it may take several ms to schedule a thread after it have been release form a barrier thus a short loop taking a few hundreds of nanos have a big chance of not running in parallel.
>> If you do busy-wait you risk running out of run-quote thus prempted instead.
>> 
>> Perfably one should record the CAS failure and when all threads have had failures we know that they did run concurrently.
>> 
>> So maybe:
>> Run loops from TESTSIZE min to max, re-run this loop until we record CAS failures or something like that?
>
>> So maybe: Run loops from TESTSIZE min to max, re-run this loop until we record CAS failures or something like that?
> 
> Seens to me that would be very similar with the current approach. How about we make the wrap around here explicit? Say, when the `oldvalue` reaches TESTSIZE max, we set the `newvalue` to TESTSIZE min. And we set the final expect value in `data` accordingly instead of doing a type truncation. Then we don't depend on the implementation of the compiler.

The truncation is well defined, it's just signess overflow that is not spec.
As TESTSIZE may be 64 bits and we don't simply increase by one that check itself will overflow.

Note that even if compiler do something else than wrap around, it would do the same in both cases so it should produce the same result.

Also note that this cast is no worse than doing (signed char)0xff.

Anyhow I tested trying to add max and min, the code just becomes very ugly and complicated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1877594494

From jbhateja at openjdk.org  Tue Dec 10 08:44:42 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Dec 2024 08:44:42 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <6yhvabADaFjfg6DLQXTXSyOapN45WsW5vbSgdu7ZpXM=.e0ef06b5-5ba3-4f7e-b364-fb95909a9acd@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
 <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
 <6yhvabADaFjfg6DLQXTXSyOapN45WsW5vbSgdu7ZpXM=.e0ef06b5-5ba3-4f7e-b364-fb95909a9acd@github.com>
Message-ID: <lientezaxNEwiguaTreKt2usigE4FjqqXgSF3GpWmHk=.60a64cad-d296-4183-81f4-8035d749c276@github.com>

On Tue, 10 Dec 2024 08:17:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java line 859:
>> 
>>> 857:                         .reinterpretAsInts()
>>> 858:                         .intoArray(a, offset);
>>> 859:                 default -> {
>> 
>> These cases for length() = 4, 8, and 16 looks redundant for 128-bit DeoubleVector.
>
> You are right, but this switch is needed for `DoubleMaxVector`, and using it for the other species simplifies the template. The compiler will eliminate all wrong cases so there should be no runtime concern.

I see, so you want to avoid special handling in template files at the expense of redundant Java code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877599127

From ihse at openjdk.org  Tue Dec 10 08:51:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Dec 2024 08:51:45 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <cxbGNoeWXFNqKVFrQM26GTNE3i40jFwyXPW87pUXSjU=.cdcf3cec-99a6-45ad-aabc-9569a19ac46c@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

Thanks for all reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22637#issuecomment-2530834262

From ihse at openjdk.org  Tue Dec 10 08:51:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Dec 2024 08:51:46 GMT
Subject: Integrated: 8345795: Update copyright year to 2024 for hotspot in
 files where it was missed
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <L5e5EQstNUh6-uYcJ2g3fXB4YlyVbBVqorjQlw4f6ms=.7a58b6dd-6b71-432d-b2c5-d93fa998b3c9@github.com>

On Mon, 9 Dec 2024 12:11:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

Changeset: 2979806c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2979806c72561cb4d4e8ac3d44dbcea347ace966
Stats:     921 lines in 921 files changed: 0 ins; 0 del; 921 mod

8345795: Update copyright year to 2024 for hotspot in files where it was missed

Reviewed-by: dholmes, tschatzl, dnsimon, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/22637

From dholmes at openjdk.org  Tue Dec 10 09:05:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 09:05:44 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>
Message-ID: <NEpXEJiQtQQ2AuQdfPS_943vxLyGp-xLZI6x8bC7oLk=.0006f301-3a18-4340-8fa2-74dc9f7e1249@github.com>

On Mon, 9 Dec 2024 13:09:50 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I thought the comment was referring to this code below that late calculates the modifier flags.  Don't know why system dictionary was called out though.
>
> And they're not the same as access flags.

The "recalculate" is what is throwing me - that suggests the flags were already "calculated" somewhere. Does it really mean just "calculate" and that we do it between parsing and adding to SD? (Not that I know what the significance of that placement is meant to be.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1877642184

From jbhateja at openjdk.org  Tue Dec 10 09:07:46 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Dec 2024 09:07:46 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <6yhvabADaFjfg6DLQXTXSyOapN45WsW5vbSgdu7ZpXM=.e0ef06b5-5ba3-4f7e-b364-fb95909a9acd@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
 <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
 <6yhvabADaFjfg6DLQXTXSyOapN45WsW5vbSgdu7ZpXM=.e0ef06b5-5ba3-4f7e-b364-fb95909a9acd@github.com>
Message-ID: <nvHwVZ7GYRfTiGNRyoSIiRJ-Ufo-QFBxIZg4ii-cECw=.29212e93-eb46-439b-855b-182cfedee37b@github.com>

On Tue, 10 Dec 2024 08:18:36 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java line 1046:
>> 
>>> 1044:                     String msg = ("index "+si+"out of range ["+length+"] in "+
>>> 1045:                                   java.util.Arrays.toString(indices));
>>> 1046:                     throw new AssertionError(msg);
>> 
>> Why not directly throw IndexOutOfBoundsException here?
>
> This is called in an `assert` so I think throwing `AssertionError` seems more reasonable, the original implementation also throws `AssertionError`

I see, you want to throw an error here and not just use an assert statement that reports an assertion failure with -ea flag.  This is a newly added routine, why don't you simply return a false and let the assertion invoking this routine do the rest?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1877642371

From duke at openjdk.org  Tue Dec 10 09:10:43 2024
From: duke at openjdk.org (duke)
Date: Tue, 10 Dec 2024 09:10:43 GMT
Subject: RFR: 8335367: [s390] Add support for load immediate on condition
 instructions. [v3]
In-Reply-To: <1-wsaZp9KA0i0Vgvft2lMWPQVnKXvDuM90VSDrYZl4A=.800872c6-5ec4-4a17-97e1-e55514e3b8a3@github.com>
References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com>
 <1-wsaZp9KA0i0Vgvft2lMWPQVnKXvDuM90VSDrYZl4A=.800872c6-5ec4-4a17-97e1-e55514e3b8a3@github.com>
Message-ID: <6VM1dGI0sY0uny8BD6nC2sctCohpmdISyqgqZuEJB2o=.9899bfa1-d4f5-4915-a5fa-871f6d70397c@github.com>

On Mon, 2 Dec 2024 04:55:15 GMT, Manjunath S Matti. <duke at openjdk.org> wrote:

>> Add support for load immediate on condition instructions.
>
> Manjunath S Matti. has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments from Lutz.

@mmatti-sw 
Your change (at version 9f5f39675892a335f5426ed528d5c4182d291d6f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22058#issuecomment-2530888245

From stefan.johansson at oracle.com  Tue Dec 10 09:10:51 2024
From: stefan.johansson at oracle.com (Stefan Johansson)
Date: Tue, 10 Dec 2024 10:10:51 +0100
Subject: CFV: New HotSpot Group Member: Axel Boldt-Christmas
In-Reply-To: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
References: <bb01d5cd-202d-483f-9dad-52844cf7cad6@oracle.com>
Message-ID: <9c90d6a7-4768-4aa0-85d8-9a64a508f29c@oracle.com>

Vote: yes


On 2024-11-27 12:26, Stefan Karlsson wrote:
> I hereby nominate Axel Boldt-Christmas to Membership in the HotSpot 
> Group.
>
> Axel is a member of Oracle's HotSpot GC team and has been contributing 
> to various parts of the JVM for over two years now.
>
> Votes are due by 2024-12-11T12:24+01:00.
>
> Only current Members of the HotSpot Group [1] are eligible
> to vote on this nomination.? Votes must be cast in the open by
> replying to this mailing list
>
> For Lazy Consensus voting instructions, see [2].
>
> Stefan Karlsson
>
> [1] https://openjdk.org/census
> [2] https://openjdk.org/groups/#member-vote
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20241210/60dedac9/attachment.htm>

From dholmes at openjdk.org  Tue Dec 10 09:11:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 09:11:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
Message-ID: <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>

On Mon, 9 Dec 2024 13:02:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/typeArrayKlass.hpp line 76:
>> 
>>> 74:   void  copy_array(arrayOop s, int src_pos, arrayOop d, int dst_pos, int length, TRAPS);
>>> 75: 
>>> 76:   // jvm support
>> 
>> "jvm support" for what? I'm not even sure why we need `compute_modifier_flags` for array types when they have a fixed value. Can't we just hardwire them and only call `compute_modifier_flags` for instanceKlasses?
>
> ObjArrayKlass computes the modifier flags based on the bottom_klass, and there is a place that calls compute_modifier_flags in an assert that requires the virtual function, albeit for an assert, otherwise I would have made it not a virtual function.

Okay I see now - the access modifier part of the modifiers for a reference array comes from the element type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1877650366

From dholmes at openjdk.org  Tue Dec 10 09:11:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 09:11:43 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>
Message-ID: <7bLc1iVbmC-Hzj047_ZgfsjGmbAeXxE9_g2QZ33_oXs=.7ea0b562-c089-411c-a5ba-abcc9d281d46@github.com>

On Tue, 10 Dec 2024 09:08:07 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> ObjArrayKlass computes the modifier flags based on the bottom_klass, and there is a place that calls compute_modifier_flags in an assert that requires the virtual function, albeit for an assert, otherwise I would have made it not a virtual function.
>
> Okay I see now - the access modifier part of the modifiers for a reference array comes from the element type.

But still "jvm support" in the comment really doesn't explain anything.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1877652152

From galder at openjdk.org  Tue Dec 10 09:13:41 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 10 Dec 2024 09:13:41 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
Message-ID: <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>

On Thu, 7 Nov 2024 10:18:14 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> Overall, looks fine.
>> 
>> So, there will be `inline_min_max`, `inline_fp_min_max`, and `inline_long_min_max` which slightly vary. I'd prefer to see them unified. (Or, at least, enhance `inline_min_max` to cover `minL`/maxL` cases).
>> 
>> Also, it's a bit confusing to see int variants names w/o basic type (`_min`/`_minL` vs `_minI`/`_minL`).  Please, clean it up along the way. (FTR I'm also fine handling the renaming as a separate change.)
>
>> Overall, looks fine.
>> 
>> So, there will be `inline_min_max`, `inline_fp_min_max`, and `inline_long_min_max` which slightly vary. I'd prefer to see them unified. (Or, at least, enhance `inline_min_max` to cover `minL`/maxL` cases).
>> 
>> Also, it's a bit confusing to see int variants names w/o basic type (`_min`/`_minL` vs `_minI`/`_minL`). Please, clean it up along the way. (FTR I'm also fine handling the renaming as a separate change.)
> 
> @iwanowww I applied the changes you suggested. Could you review them?

> @galderz Thanks for taking this task on! Had a quick look at it. So auto-vectorization in SuperWord should now be working, right? If yes:
> 
> It would be nice if you tested both for `IRNode.MIN_VL` and `IRNode.MIN_REDUCTION_V`, the same for max.
> 
> You may want to look at these existing tests, to see what other tests there are for the `int` version: `test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Int.java` `test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java` `test/hotspot/jtreg/compiler/vectorization/TestAutoVecIntMinMax.java` `test/hotspot/jtreg/compiler/c2/TestMinMaxSubword.java` There may be some duplicates already here... not sure. 

+1 to adding such tests. I'm looking into it right now. It's a bit confusing how the tests are spread around (and duplication?) but I'm currently leaning towards adding a `compiler/loopopts/superword/MinMaxRed_Long.java`.

> And maybe you need to check what to do about probabilities as well.

I will add probabilities logic (50, 80, 100) to control data, but you can already see that from https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872 that with the patch in an AVX512 system min/max reduction nodes will appear in all probabilities.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2530905728

From galder at openjdk.org  Tue Dec 10 09:13:47 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 10 Dec 2024 09:13:47 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <qEK_fgwN0K-S9tyXH1apALwn06b64fb7th4UjMCOtIM=.ff6446be-4fb5-432a-af23-049296232d3e@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
 <qEK_fgwN0K-S9tyXH1apALwn06b64fb7th4UjMCOtIM=.ff6446be-4fb5-432a-af23-049296232d3e@github.com>
Message-ID: <yH8M6qrzO8rKztPiLKrq_FyNmlzPv0gzYr2GWhxJGDE=.a21b6af8-a1fd-453f-9929-5ff2d8dc3746@github.com>

On Fri, 29 Nov 2024 11:27:01 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:
>> 
>>  - Use same default size as in other vector reduction benchmarks
>>  - Renamed benchmark class
>>  - Double/Float tests only when avx enabled
>>  - Make state class non-final
>>  - Restore previous benchmark iterations and default param size
>>  - Add clipping range benchmark that uses min/max
>>  - Encapsulate benchmark state within an inner class
>>  - Avoid creating result array in benchmark method
>>  - Merge branch 'master' into topic.intrinsify-max-min-long
>>  - Revert "Implement cmovL as a jump+mov branch"
>>    
>>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>>  - ... and 20 more: https://git.openjdk.org/jdk/compare/b713ae85...0a8718e1
>
> test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxInlining.java line 108:
> 
>> 106:     @Test
>> 107:     @Arguments(values = { Argument.NUMBER_MINUS_42, Argument.NUMBER_42 })
>> 108:     @IR(counts = { IRNode.MIN_F, "1" }, applyIfCPUFeatureOr = {"avx", "true"})
> 
> Is this not supported by `asimd`? Same question for the other cases.

Good point. I'll look into that aarch64 environments to see how things behave.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1877657011

From shade at openjdk.org  Tue Dec 10 09:16:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Dec 2024 09:16:40 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <qXRiCoJy8LGW3kwDBLs7eJOzhlj1QczxzNeopkEZBA4=.e2b3c539-d6bc-4a7d-b859-7f40868add97@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

OK, thanks. I'll approve once I see clean GHA run. I think you have already fixed the Xcomp failure, so just pull from master and see what happens?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22614#issuecomment-2530919318

From aph at redhat.com  Tue Dec 10 09:38:06 2024
From: aph at redhat.com (Andrew Haley)
Date: Tue, 10 Dec 2024 09:38:06 +0000
Subject: RFD: Enhance crash log output when disassembler is not present
In-Reply-To: <7956c9e1-fe84-4e1a-a257-278a4b4c3cdd@oracle.com>
References: <64f29c94-8191-4a0b-99d4-7b5e675fef7e@redhat.com>
 <7956c9e1-fe84-4e1a-a257-278a4b4c3cdd@oracle.com>
Message-ID: <6ea5c56d-1a63-403d-871e-de9084541943@redhat.com>

On 12/10/24 03:56, Vladimir Ivanov wrote:
> Personally, I like your proposal to make the output of abstract
> disassembler trivially parseable by existing platform tools.
> 
> In absense of hsdis library, it's already cryptic enough not to be
> negatively affected by extra formatting being proposed. And it would be
> very convenient to just feed a block into an assembler tool and get a
> readable assembly back.
> 
> Alternatively, an hsdis-based tool to parse existing output format can
> be introduced, but just relying on platform assembler looks like a
> simpler solution (both from usability and maintenance perspective).

Thanks. My reasoning about using the platform assembler is that, for every
additional tool and utility you have to find, we'll lose about 50% of
people.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From chagedorn at openjdk.org  Tue Dec 10 09:39:48 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 10 Dec 2024 09:39:48 GMT
Subject: RFR: 8345801: C2: Clean up include statements to speed up compilation
 when touching type.hpp
Message-ID: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>

I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.

In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:

... more C1 files
  #include "c1/c1_Compilation.hpp"
    #include "compiler/compilerDefinitions.inline.hpp"
      #include "opto/c2compiler.hpp"
        #include "opto/output.hpp"    <------------ Problematic include
          #include "opto/c2_CodeStubs.hpp"
            #include "opto/compile.hpp"
              ... more opto files and eventually type.hpp

This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.

The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:

- Mainline: ~1min -> ~40s (1.5 times faster)
- Valhalla: ~7min -> ~40s (10.5 times faster)

I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.

Testing:
- Oracle CI
- GHA

Maybe some 

Thanks,
Christian

-------------

Commit messages:
 - C2: Clean up include statements to speed up compilation when touching type.hpp

Changes: https://git.openjdk.org/jdk/pull/22658/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22658&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345801
  Stats: 86 lines in 31 files changed: 15 ins; 69 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22658.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22658/head:pull/22658

PR: https://git.openjdk.org/jdk/pull/22658

From stefank at openjdk.org  Tue Dec 10 09:43:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 10 Dec 2024 09:43:39 GMT
Subject: RFR: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
In-Reply-To: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
References: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
Message-ID: <60DTijBzfTnhRoC9xd9ru2uXdkR5lVJrpVCvcQQhCHQ=.edf02782-48aa-4c95-be97-2f6496ef640d@github.com>

On Fri, 6 Dec 2024 10:09:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This functions is called after an previous calls to WB_NMTReserveMemory and WB_NMTAttemptReserveMemoryAt, which both already registered an NMT tag. So, explicitly recording an NMT tag for this memory is redundant and slightly confusing.
> 
> The HotSpot JVM code does not record NMT tags when committing memory (except in a special case on Windows when mapping file memory).
> 
> Tested with tier1-3.

Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22601#issuecomment-2531022554

From jsjolen at openjdk.org  Tue Dec 10 09:51:38 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 10 Dec 2024 09:51:38 GMT
Subject: RFR: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
In-Reply-To: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
References: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
Message-ID: <rpg16DVsTadwIh9JgzXIDhmtXRYrNNGxHDf58w_aMLc=.7ad2a77f-ec89-4ffd-9ba4-a0e80e662aa0@github.com>

On Fri, 6 Dec 2024 10:09:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This functions is called after an previous calls to WB_NMTReserveMemory and WB_NMTAttemptReserveMemoryAt, which both already registered an NMT tag. So, explicitly recording an NMT tag for this memory is redundant and slightly confusing.
> 
> The HotSpot JVM code does not record NMT tags when committing memory (except in a special case on Windows when mapping file memory).
> 
> Tested with tier1-3.

Seems correct to me.

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22601#pullrequestreview-2491711205

From azafari at openjdk.org  Tue Dec 10 09:57:47 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 10 Dec 2024 09:57:47 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <S1qAIxpYogPn-wxPX4ZW2TDs3DEUlQTUBbjvYG_8dCs=.75cc3985-72d0-4fff-8c8c-5c9e604a2970@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
 <RfIjTEurTj_uv-HsOORUcfvi-YcBjbRIPuIJM9J9n2Y=.fe982bbd-c29c-4652-965e-b6d332feebed@github.com>
 <xDR7XMBE2oKXnAJ6YrlTTATuJ1Kxi8g821CIepdDQtU=.204c132c-db57-4e8e-8a7c-87e7a75a7927@github.com>
 <S1qAIxpYogPn-wxPX4ZW2TDs3DEUlQTUBbjvYG_8dCs=.75cc3985-72d0-4fff-8c8c-5c9e604a2970@github.com>
Message-ID: <g2118MI7I4x3jOuBOakTrfWs9ew7F6P6IzaYNfYvnkI=.ae4d00e5-402a-467b-af1a-905726d78662@github.com>

On Mon, 9 Dec 2024 17:45:38 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Ok I see. Thank you for clarifying.
>
> I have a couple more questions about this function:
> 
> Why bother keeping the variable `base`. It's updated whenever `prev` is updated, so why not just use `prev`?
> 
> Why do you allow for grouping two adjacent committed regions with different `MemTags` together when creating `CommittedMemoryRegion`? Shouldn't they be treated as separate committed regions?  And if we are supposed to be grouping adjacent regions, shouldn't we be using the address of the first region, not the current one, as the base address when creating `CommittedMemoryRegion` (since we've been incrementing `comm_size`)?

Your point on `base` is correct. `prev.position` can be used instead.

I agree that there is ambiguity in the method name and its args. This method SHOULD be called for a `ReservedMemoryRegion [base, base + size)`. This is implicitly assumed. The signature as `visit_committed_regions(ReservedMemoryRegion& rgn, F func)` is more declarative then.

With the above assumption, if two committed regions are adjacent with different `MemTag`, they certainly belong to different `ReservedMemoryRegion`s, one for CDS with `mtClassShared` and another for stack with `mtThreadStack` MemTag. This method doesn't care the `MemTag`s because all the sub-regions within the `ReservedMemoryRegion [base, base + size)` are assumed to have the same `MemTag`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1877756397

From azafari at openjdk.org  Tue Dec 10 10:11:08 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 10 Dec 2024 10:11:08 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v10]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <IQxwuzJPG5iplDgk7ajJjIJVyJUMbMPun6zIDvyWdTk=.b7876dfc-8f03-43c3-9ef7-8367ec688171@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  visit_committed_regions signature changed.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/b5e6d268..316d9a11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=08-09

  Stats: 17 lines in 5 files changed: 1 ins; 6 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

PR: https://git.openjdk.org/jdk/pull/20425

From azafari at openjdk.org  Tue Dec 10 10:11:08 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 10 Dec 2024 10:11:08 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v9]
In-Reply-To: <kvWzH5MUxF-Ak0lobf9wUw3VYIUThnSHNq9VrMWNoMU=.674d3ad5-1427-4e7d-98a4-d5abb834e70d@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <es4dw7RYkRF421IZHMv1tCe_jWSQbfzlJ-EyW4Qn4qY=.e333b6cc-f193-4876-a456-ad893777e629@github.com>
 <kvWzH5MUxF-Ak0lobf9wUw3VYIUThnSHNq9VrMWNoMU=.674d3ad5-1427-4e7d-98a4-d5abb834e70d@github.com>
Message-ID: <zl4oIcWxESY8fzXLTK38RxQrNrYJItZYi7O4MXqj_L0=.101b2ed0-b166-42b4-9710-95db2c3fa959@github.com>

On Mon, 9 Dec 2024 15:44:37 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed unused local var.
>
> src/hotspot/share/nmt/regionsTree.hpp line 124:
> 
>> 122:     size_t rgn_size = 0;
>> 123:     size_t comm_size = 0;
>> 124:     size_t base = 0;
> 
> I think `base` and `comm_size` are unused.

Yes, they were. Removed. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1877772750

From fyang at openjdk.org  Tue Dec 10 10:11:41 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 10 Dec 2024 10:11:41 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
In-Reply-To: <XYP-pbmnLPO6nA622KZ2TNXNNCQG72fxIrFwe2GajHM=.89f5d13e-5016-417f-bd3e-3fe0fd78dc98@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
 <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
 <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>
 <4ZhZOdUYgTbwMUzYqsjjjyWAeoNddQxfTsV9TQRUNJs=.54087dda-d704-40d5-9e57-ce5d743da97e@github.com>
 <ZTcT0Pr8yyd67EMC9lTMlvkbZfEC9q3cLJyLRt3LIOQ=.0ca6f933-bd7e-4972-8c96-d3ae9210621a@github.com>
 <kGKF6qqQdyKLh8HvwWk3jb7-Tp66vgD6KRi0r5tuheA=.50f5f50b-5ac2-4090-82c7-53f220afbcbe@github.com>
 <XYP-pbmnLPO6nA622KZ2TNXNNCQG72fxIrFwe2GajHM=.89f5d13e-5016-417f-bd3e-3fe0fd78dc98@github.com>
Message-ID: <nzTFDBPV7XsB-cnOANrP-QVFhyiaB68QTkPcdJxTknc=.da447303-4adf-44b6-b42d-05fe4b794641@github.com>

On Tue, 10 Dec 2024 08:39:34 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> The truncation is well defined, it's just signess overflow that is not spec. As TESTSIZE may be 64 bits and we don't simply increase by one that check itself will overflow.

Ah, I was considering TESTSIZE int8_t or int16_t.

> Note that even if compiler do something else than wrap around, it would do the same in both cases so it should produce the same result.

That makes sense to me. Thanks.

> Also note that this cast is no worse than doing (signed char)0xff.
> 
> Anyhow I tested trying to add max and min, the code just becomes very ugly and complicated.

All right then. Could you please add some code comment about what we are doing here to help understand?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1877778325

From fyang at openjdk.org  Tue Dec 10 10:15:37 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 10 Dec 2024 10:15:37 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v5]
In-Reply-To: <uX8kCHNAjMzAEUV_yeXdISy9UegzPDCY6YLMDTDk_iw=.a4fce981-2c68-4426-8a76-a6a0909a5de9@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <uX8kCHNAjMzAEUV_yeXdISy9UegzPDCY6YLMDTDk_iw=.a4fce981-2c68-4426-8a76-a6a0909a5de9@github.com>
Message-ID: <1oL3cROLnrmysZynYU6Lokjvw5S6GZCNzJkf3QzioIQ=.23ad3434-132a-4578-81fe-72928159f8e2@github.com>

On Tue, 10 Dec 2024 07:53:52 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for RealFYang's comment

Thanks for the update! Will take another look. BTW: Did you try this JMH to see the benefit?
`make test TEST="micro:vm.compiler.SecondarySuperCacheInterContention"`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21922#issuecomment-2531105435

From gcao at openjdk.org  Tue Dec 10 11:09:37 2024
From: gcao at openjdk.org (Gui Cao)
Date: Tue, 10 Dec 2024 11:09:37 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v5]
In-Reply-To: <1oL3cROLnrmysZynYU6Lokjvw5S6GZCNzJkf3QzioIQ=.23ad3434-132a-4578-81fe-72928159f8e2@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <uX8kCHNAjMzAEUV_yeXdISy9UegzPDCY6YLMDTDk_iw=.a4fce981-2c68-4426-8a76-a6a0909a5de9@github.com>
 <1oL3cROLnrmysZynYU6Lokjvw5S6GZCNzJkf3QzioIQ=.23ad3434-132a-4578-81fe-72928159f8e2@github.com>
Message-ID: <i63GJZltaXWRTkBNhJ8tqBoObEi1wlCAfi966BsQQn4=.afb378cc-a1b2-47b8-8bc3-fe67a4c6fdc5@github.com>

On Tue, 10 Dec 2024 10:12:50 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Thanks for the update! Will take another look. BTW: Did you try this JMH to see the benefit?

Yes, I have performed this JMH.

Without this patch:

Benchmark                                   Mode  Cnt     Score     Error  Units
SecondarySuperCacheInterContention.test     avgt   15  5904.968 ?  36.829  ns/op
SecondarySuperCacheInterContention.test:t1  avgt   15  5938.559 ? 201.657  ns/op
SecondarySuperCacheInterContention.test:t2  avgt   15  5871.377 ? 176.948  ns/op
Finished running test 'micro:vm.compiler.SecondarySuperCacheInterContention'


Apply this patch:

Benchmark                                   Mode  Cnt   Score   Error  Units
SecondarySuperCacheInterContention.test     avgt   15  52.563 ? 5.843  ns/op
SecondarySuperCacheInterContention.test:t1  avgt   15  52.781 ? 5.336  ns/op
SecondarySuperCacheInterContention.test:t2  avgt   15  52.344 ? 6.431  ns/op
Finished running test 'micro:vm.compiler.SecondarySuperCacheInterContention'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21922#issuecomment-2531257812

From coleenp at openjdk.org  Tue Dec 10 12:30:50 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 12:30:50 GMT
Subject: RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
 [v12]
In-Reply-To: <6HkfR42LT1I19LZ22OxrHj5TFa0vmp8Pp25U0UkJJwk=.94d9fdb1-27d3-4b31-805c-df572e2932e3@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
 <6HkfR42LT1I19LZ22OxrHj5TFa0vmp8Pp25U0UkJJwk=.94d9fdb1-27d3-4b31-805c-df572e2932e3@github.com>
Message-ID: <QChCZC1yxq6F4jY0KM7fs9eblGr4UUYDrp3_nul9d6g=.a99d0898-a113-4227-8758-7e4c3b745f86@github.com>

On Mon, 9 Dec 2024 23:11:08 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
>> 
>> Tested with tier1-7.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment why shared_base_valid() can't actually check for us whether the shared base is valid.

Thanks Ioi for the offline discussion of how this works for CDS and thanks Thomas for your review.

I also retested tier1-4 and it passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2531500201
PR Comment: https://git.openjdk.org/jdk/pull/21695#issuecomment-2531502345

From coleenp at openjdk.org  Tue Dec 10 12:30:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 12:30:51 GMT
Subject: Integrated: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
In-Reply-To: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
References: <h4pLWXaxvt6W6Lw5LSsJepAk1pRjNhWcJ-0Iz5AGtCo=.cf4c8055-68bb-4cce-820e-a50cfddabfd4@github.com>
Message-ID: <KaQxQfF7dR9nqq07noIfOsTKWG7ptVrKtKcdTw6IAMM=.c1beb208-718e-4045-b594-7aec4c709145@github.com>

On Thu, 24 Oct 2024 20:49:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Added checks to verify that the given compressed class base or shared base address and shift given will be decodable for aarch64.  This code is moved in PR https://github.com/openjdk/jdk/pull/20677 so this would be moved to the new place once that's integrated.
> 
> Tested with tier1-7.

This pull request has now been integrated.

Changeset: a6277bb5
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a6277bb521e07e569cd75a4641b2a05a26f47b0a
Stats:     130 lines in 8 files changed: 106 ins; 7 del; 17 mod

8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

Co-authored-by: Thomas Stuefe <stuefe at openjdk.org>
Reviewed-by: iklam, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/21695

From rehn at openjdk.org  Tue Dec 10 13:28:56 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 10 Dec 2024 13:28:56 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v2]
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <SYMLRwRqushrU_T_krYlVGjoGDl_JX-xOLEsrSHUO0I=.1335b7e7-e5ca-42db-84d5-8543e68ecb75@github.com>

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Code share
 - Overflow
 - Merge branch 'master' into 8345322
 - Concurrent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22574/files
  - new: https://git.openjdk.org/jdk/pull/22574/files/8c62fc97..5c7d9f93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=00-01

  Stats: 10628 lines in 701 files changed: 8780 ins; 1256 del; 592 mod
  Patch: https://git.openjdk.org/jdk/pull/22574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22574/head:pull/22574

PR: https://git.openjdk.org/jdk/pull/22574

From rehn at openjdk.org  Tue Dec 10 13:28:57 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Tue, 10 Dec 2024 13:28:57 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v2]
In-Reply-To: <nzTFDBPV7XsB-cnOANrP-QVFhyiaB68QTkPcdJxTknc=.da447303-4adf-44b6-b42d-05fe4b794641@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <Jk5oWrcfHzvSHQjKLalwOY5fQazzHEfNiuKrzd9AXDw=.ccbfad1e-76bb-4d5c-9f2a-ea70f77938a4@github.com>
 <k7tV2YCSQhIrN7t1y7-DJ1iNm40T6A_dBSBlpue0DU8=.ee678a47-00c4-4651-8b4c-8fd2eaa9d837@github.com>
 <SHZobnAADd-6mHifLzb3WU0lNlP9mjM3JDwMDqQ7gZo=.575557ea-ca59-4f24-a5f7-e13d6408f7ee@github.com>
 <7qdlNSld28ytF7l_csZamKmFAb5LY1EsDcjwVNUr8rA=.de83fd3b-181d-472d-98a9-fd23ab42b62c@github.com>
 <4ZhZOdUYgTbwMUzYqsjjjyWAeoNddQxfTsV9TQRUNJs=.54087dda-d704-40d5-9e57-ce5d743da97e@github.com>
 <ZTcT0Pr8yyd67EMC9lTMlvkbZfEC9q3cLJyLRt3LIOQ=.0ca6f933-bd7e-4972-8c96-d3ae9210621a@github.com>
 <kGKF6qqQdyKLh8HvwWk3jb7-Tp66vgD6KRi0r5tuheA=.50f5f50b-5ac2-4090-82c7-53f220afbcbe@github.com>
 <XYP-pbmnLPO6nA622KZ2TNXNNCQG72fxIrFwe2GajHM=.89f5d13e-5016-417f-bd3e-3fe0fd78dc98@github.com>
 <nzTFDBPV7XsB-cnOANrP-QVFhyiaB68QTkPcdJxTknc=.da447303-4adf-44b6-b42d-05fe4b794641@github.com>
Message-ID: <c3rFWD20zHnb22PWhExlbs5gYcwuXW-XT26OAgbqd4M=.e25c8718-3e1a-4165-9808-c2f9fda6bd79@github.com>

On Tue, 10 Dec 2024 10:08:40 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> The truncation is well defined, it's just signess overflow that is not spec.
>> As TESTSIZE may be 64 bits and we don't simply increase by one that check itself will overflow.
>> 
>> Note that even if compiler do something else than wrap around, it would do the same in both cases so it should produce the same result.
>> 
>> Also note that this cast is no worse than doing (signed char)0xff.
>> 
>> Anyhow I tested trying to add max and min, the code just becomes very ugly and complicated.
>
>> The truncation is well defined, it's just signess overflow that is not spec. As TESTSIZE may be 64 bits and we don't simply increase by one that check itself will overflow.
> 
> Ah, I was considering TESTSIZE int8_t or int16_t.
> 
>> Note that even if compiler do something else than wrap around, it would do the same in both cases so it should produce the same result.
> 
> That makes sense to me. Thanks.
> 
>> Also note that this cast is no worse than doing (signed char)0xff.
>> 
>> Anyhow I tested trying to add max and min, the code just becomes very ugly and complicated.
> 
> All right then. Could you please add some code comment about what we are doing here to help understand?

I tried to fix it, let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1878091425

From coleenp at openjdk.org  Tue Dec 10 13:29:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 13:29:21 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  remove "jvm support"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22618/files
  - new: https://git.openjdk.org/jdk/pull/22618/files/4d546b58..5d87b61a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22618/head:pull/22618

PR: https://git.openjdk.org/jdk/pull/22618

From coleenp at openjdk.org  Tue Dec 10 13:29:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 13:29:21 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <NEpXEJiQtQQ2AuQdfPS_943vxLyGp-xLZI6x8bC7oLk=.0006f301-3a18-4340-8fa2-74dc9f7e1249@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <ZUfi34BFUNJtWVCrp6ltf1RbySRc1pNca0ygRpApM3I=.60e6fa81-ce4c-4fe0-b8c1-5b3fcada42a9@github.com>
 <NEpXEJiQtQQ2AuQdfPS_943vxLyGp-xLZI6x8bC7oLk=.0006f301-3a18-4340-8fa2-74dc9f7e1249@github.com>
Message-ID: <MJ3NWA3ZmU-nJwMNhdsQM9NlaErywXeVbpXfD0mDMDA=.43a99efe-1b51-403d-a5a4-71ac2d6256f7@github.com>

On Tue, 10 Dec 2024 09:02:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> And they're not the same as access flags.
>
> The "recalculate" is what is throwing me - that suggests the flags were already "calculated" somewhere. Does it really mean just "calculate" and that we do it between parsing and adding to SD? (Not that I know what the significance of that placement is meant to be.)

So I did some old code reading.  We used to create the mirror when creating InstanceKlass, then later in ClassFileParser, we recalculated the modifier flags after the inner class attributes are added to the InstanceKlass.  Now we create the mirror after all of this.  Adding to the SystemDictionary is the point where the class is published so they have to be correct for that, which is what that part of the comment meant.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878089439

From coleenp at openjdk.org  Tue Dec 10 13:29:21 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 13:29:21 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <7bLc1iVbmC-Hzj047_ZgfsjGmbAeXxE9_g2QZ33_oXs=.7ea0b562-c089-411c-a5ba-abcc9d281d46@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <h6wel9Lm77ZYxn_sMsR_HbSQySpDI8ute7x7xprCkhA=.2dbede33-96a4-4177-9642-a627dcff0616@github.com>
 <hMOR4oms0v51Yt6OpZMTP0LVoXAyDLB8ycvlC_O1lS4=.d24d1401-2828-4bf7-8d39-665554c30de7@github.com>
 <Wm5mwjwg5cm1huB9v64CNkRv5e1zdZ57_Cp09IqsafU=.3f26be07-204a-43a1-9fec-62269f9d6124@github.com>
 <7bLc1iVbmC-Hzj047_ZgfsjGmbAeXxE9_g2QZ33_oXs=.7ea0b562-c089-411c-a5ba-abcc9d281d46@github.com>
Message-ID: <Fu_oEZrD4HZmLswKMNrB_g1SRuZR7hSB577VtdPA-K8=.bbb4a14e-7314-4ed9-b917-2c29198935d4@github.com>

On Tue, 10 Dec 2024 09:08:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Okay I see now - the access modifier part of the modifiers for a reference array comes from the element type.
>
> But still "jvm support" in the comment really doesn't explain anything.

I think it means for Class.getModifiers but I can remove it.  But I don't think I'm going to push this anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878090566

From jwaters at openjdk.org  Tue Dec 10 13:30:41 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 13:30:41 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code [v2]
In-Reply-To: <l7JdpAZj_vD8ILatSPZTwC2A3taGtny1_JUwx9KrTg4=.00c081e8-db80-4916-ad4e-41caf0b6cb65@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
 <l7JdpAZj_vD8ILatSPZTwC2A3taGtny1_JUwx9KrTg4=.00c081e8-db80-4916-ad4e-41caf0b6cb65@github.com>
Message-ID: <j8NqWzBcyDdrb3u3Mc9YQiVZ6AkNQg4gM5A040DzjDc=.bdcf82db-12af-40c8-8e62-73a751ad2529@github.com>

On Fri, 6 Dec 2024 06:33:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> in s390 code.
>> 
>> Most places involve just changing literal 0 to nullptr.
>> 
>> Removed a dead return after ShouldNotReachHere() that is no longer needed.
>> 
>> Testing:
>> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
>> I don't have the capability to run tests for this platform, so hoping someone
>> from the aix-ppc maintainers can do more testing.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into fix-s390-zero-null
>  - simple s390 fixes

Looks good

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22469#pullrequestreview-2492322394

From jwaters at openjdk.org  Tue Dec 10 13:30:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 13:30:42 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code
In-Reply-To: <E-gzafwASr2UGNpQR6Zh0fKNFzqPzPnjCprQ2hZ-OfI=.6ebfafc9-c67c-4666-9ead-72c31c1a6244@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
 <E-gzafwASr2UGNpQR6Zh0fKNFzqPzPnjCprQ2hZ-OfI=.6ebfafc9-c67c-4666-9ead-72c31c1a6244@github.com>
Message-ID: <1tgNIcP8D_s96blqkNLcCGJO4F80VYbbSe4zg2mRGfg=.0c6cfb7e-3147-43e6-a184-2eab358b23bb@github.com>

On Wed, 4 Dec 2024 13:03:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > hi @kimbarrett,
> > I tried to build it on s390x with these changes:
> > ```diff
> > diff --git a/make/autoconf/flags-cflags.m4 b/make/autoconf/flags-cflags.m4
> > index 57654514eb6..ce3077e7d38 100644
> > --- a/make/autoconf/flags-cflags.m4
> > +++ b/make/autoconf/flags-cflags.m4
> > ```
> 
> [snip]
> 
> > is that correct way to test it ?
> 
> That's too general, affecting the entire JDK. The rule we're trying to enforce (don't use literal 0 as a null pointer constant) is specific to HotSpot.
> 
> For testing, I've been adding the warning to the list here:
> 
> https://github.com/openjdk/jdk/blob/e13206d3a16a67a604076faecded88cbed85db1a/make/autoconf/flags-cflags.m4#L785
> 
> I've not verified with the build team that this is the right place ultimately. And I suspect it's not, since your log listed warnings in adlc. I'm not seeing any warnings there, even though (looking at the code) there clearly should be.

Do we also want ADLC to have nulls cleaned up? I thought it was just HotSpot that the cleanups were aimed at, not including the tools used while building it

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22469#issuecomment-2531639314

From luhenry at openjdk.org  Tue Dec 10 13:43:39 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Tue, 10 Dec 2024 13:43:39 GMT
Subject: RFR: 8345669: RISC-V: fix client build failure due to AlignVector
 after JDK-8343827
In-Reply-To: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
References: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
Message-ID: <UUekkBPZ8p35NcavdCiCTpyedupkSwFRqT5rAuE5lJs=.16138481-9bf3-47a9-9408-d0f3c1666f35@github.com>

On Fri, 6 Dec 2024 11:39:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple fix?
> Thanks!
> 
> Previously in JDK-8343827, AlignVector was enabled conditionally, but the code was put in common path (shared with non-C2 code), but in fact this flag is only for C2.

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22605#pullrequestreview-2492360760

From aph at openjdk.org  Tue Dec 10 13:55:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 10 Dec 2024 13:55:39 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code [v2]
In-Reply-To: <l7JdpAZj_vD8ILatSPZTwC2A3taGtny1_JUwx9KrTg4=.00c081e8-db80-4916-ad4e-41caf0b6cb65@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
 <l7JdpAZj_vD8ILatSPZTwC2A3taGtny1_JUwx9KrTg4=.00c081e8-db80-4916-ad4e-41caf0b6cb65@github.com>
Message-ID: <TDYz7wLBljuWgGSaXscxyKTvRDQ7N7pEgll4oSW0AsU=.0db1365f-0602-4881-b113-5f5fedd6005e@github.com>

On Fri, 6 Dec 2024 06:33:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> in s390 code.
>> 
>> Most places involve just changing literal 0 to nullptr.
>> 
>> Removed a dead return after ShouldNotReachHere() that is no longer needed.
>> 
>> Testing:
>> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
>> I don't have the capability to run tests for this platform, so hoping someone
>> from the aix-ppc maintainers can do more testing.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into fix-s390-zero-null
>  - simple s390 fixes

Marked as reviewed by aph (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22469#pullrequestreview-2492394768

From duke at openjdk.org  Tue Dec 10 14:17:46 2024
From: duke at openjdk.org (Manjunath S Matti.)
Date: Tue, 10 Dec 2024 14:17:46 GMT
Subject: Integrated: 8335367: [s390] Add support for load immediate on
 condition instructions.
In-Reply-To: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com>
References: <2oJIrDqMf4MYKGz_s1K8D2aNjGwJJ75PY-gUOZwVEU0=.af1d8092-a680-4ea2-adf7-a9c3432509a3@github.com>
Message-ID: <uIYC25bUk3gMmbAjOk-5OT1BEpikD1_3VTV0qkiFsLY=.32b7d8b5-1528-45a0-9ad2-f7b7bbbb3b17@github.com>

On Wed, 13 Nov 2024 06:16:23 GMT, Manjunath S Matti. <duke at openjdk.org> wrote:

> Add support for load immediate on condition instructions.

This pull request has now been integrated.

Changeset: 25d9deb1
Author:    Manjunath Matti <manjunath.matti at ibm.com>
URL:       https://git.openjdk.org/jdk/commit/25d9deb1a350925dbd7e469ac5779b3c38d1f318
Stats:     18 lines in 3 files changed: 15 ins; 0 del; 3 mod

8335367: [s390] Add support for load immediate on condition instructions.

Reviewed-by: lucy, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/22058

From mli at openjdk.org  Tue Dec 10 14:42:43 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 10 Dec 2024 14:42:43 GMT
Subject: RFR: 8345669: RISC-V: fix client build failure due to AlignVector
 after JDK-8343827
In-Reply-To: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
References: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
Message-ID: <47PvJbZssaZkmo13bDIJpKJPHi2wuml3QhSyIzBIWr8=.05bf08b3-c848-4fb6-8c04-50ccb6561a15@github.com>

On Fri, 6 Dec 2024 11:39:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple fix?
> Thanks!
> 
> Previously in JDK-8343827, AlignVector was enabled conditionally, but the code was put in common path (shared with non-C2 code), but in fact this flag is only for C2.

Thanks for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22605#issuecomment-2531818542

From mli at openjdk.org  Tue Dec 10 14:42:43 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 10 Dec 2024 14:42:43 GMT
Subject: Integrated: 8345669: RISC-V: fix client build failure due to
 AlignVector after JDK-8343827
In-Reply-To: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
References: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
Message-ID: <3rrpONLWhfyRBXuoVCEAPDoXJC91L86PQ2hi2cdK2f8=.e9dea8f6-286c-4380-bdca-9b315926a856@github.com>

On Fri, 6 Dec 2024 11:39:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this simple fix?
> Thanks!
> 
> Previously in JDK-8343827, AlignVector was enabled conditionally, but the code was put in common path (shared with non-C2 code), but in fact this flag is only for C2.

This pull request has now been integrated.

Changeset: a24b08fc
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a24b08fcb0b3784181096f5c669e57e110600056
Stats:     8 lines in 1 file changed: 4 ins; 4 del; 0 mod

8345669: RISC-V: fix client build failure due to AlignVector after JDK-8343827

Reviewed-by: fyang, luhenry

-------------

PR: https://git.openjdk.org/jdk/pull/22605

From duke at openjdk.org  Tue Dec 10 14:52:49 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 10 Dec 2024 14:52:49 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <g2118MI7I4x3jOuBOakTrfWs9ew7F6P6IzaYNfYvnkI=.ae4d00e5-402a-467b-af1a-905726d78662@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
 <RfIjTEurTj_uv-HsOORUcfvi-YcBjbRIPuIJM9J9n2Y=.fe982bbd-c29c-4652-965e-b6d332feebed@github.com>
 <xDR7XMBE2oKXnAJ6YrlTTATuJ1Kxi8g821CIepdDQtU=.204c132c-db57-4e8e-8a7c-87e7a75a7927@github.com>
 <S1qAIxpYogPn-wxPX4ZW2TDs3DEUlQTUBbjvYG_8dCs=.75cc3985-72d0-4fff-8c8c-5c9e604a2970@github.com>
 <g2118MI7I4x3jOuBOakTrfWs9ew7F6P6IzaYNfYvnkI=.ae4d00e5-402a-467b-af1a-905726d78662@github.com>
Message-ID: <5tovgP_StYnZHV6kmjIyZWQboxlvMbS-NkaZW8kIVl8=.c9f9f1f2-d136-45c5-ab24-cc7bf36cbc16@github.com>

On Tue, 10 Dec 2024 09:55:28 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> I have a couple more questions about this function:
>> 
>> Why bother keeping the variable `base`. It's updated whenever `prev` is updated, so why not just use `prev`?
>> 
>> Why do you allow for grouping two adjacent committed regions with different `MemTags` together when creating `CommittedMemoryRegion`? Shouldn't they be treated as separate committed regions?  And if we are supposed to be grouping adjacent regions, shouldn't we be using the address of the first region, not the current one, as the base address when creating `CommittedMemoryRegion` (since we've been incrementing `comm_size`)?
>
> Your point on `base` is correct. `prev.position` can be used instead.
> 
> I agree that there is ambiguity in the method name and its args. This method SHOULD be called for a `ReservedMemoryRegion [base, base + size)`. This is implicitly assumed. The signature as `visit_committed_regions(ReservedMemoryRegion& rgn, F func)` is more declarative then.
> 
> With the above assumption, if two committed regions are adjacent with different `MemTag`, they certainly belong to different `ReservedMemoryRegion`s, one for CDS with `mtClassShared` and another for stack with `mtThreadStack` MemTag. This method doesn't care the `MemTag`s because all the sub-regions within the `ReservedMemoryRegion [base, base + size)` are assumed to have the same `MemTag`.

Ok that makes sense to me if `visit_committed_regions` is only ever called on a single ReservedRegion.  But if that assumption is true, then isn't it also true that we should never encounter two adjacent committed regions (they should already be coalesced)? 

So then maybe you don't need the extra handling such as tracking `comm_size` or checking `if (!curr.is_committed_begin())`. Maybe you could just directly have something like:

if (prev.is_valid() && prev.is_committed_begin()) {
    CommittedMemoryRegion cmr((address) prev.position(), curr.distance_from(prev), st);
...
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1878235516

From szaldana at openjdk.org  Tue Dec 10 15:01:13 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 10 Dec 2024 15:01:13 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
Message-ID: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>

Hi all, 

This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 

I verified where those uses are with: 
`git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`

The relevant output: 

File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
9:-  // No need for post barrier if storing NULL
File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
9:-    // must be either an oop or NULL
12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)


Changes affect comments only. 

Thanks, 
Sonia

-------------

Commit messages:
 - 8345647: Fix recent NULL usage backsliding in Shenandoah

Changes: https://git.openjdk.org/jdk/pull/22647/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22647&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345647
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22647.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22647/head:pull/22647

PR: https://git.openjdk.org/jdk/pull/22647

From shade at openjdk.org  Tue Dec 10 15:01:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Dec 2024 15:01:13 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <7Ni9wGl0-v-mm2CxhsfWrZxLeqtyGJsPxkfdMRenqSY=.bb67598a-7c69-4fe5-a258-8d28f2b64c6e@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Well, it is not technically a `NULL -> nullptr` changes we handle with PRs like these, but I guess it is good to have a consistent wording.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22647#pullrequestreview-2491632690

From jwaters at openjdk.org  Tue Dec 10 15:01:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 15:01:13 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <5I1bO6M3SO1HZWjEh5vPL0sxBFjfMX036OoulYxWWvg=.4228977a-7b82-4c75-a850-b00af55150b8@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Not really sure if just a comment change warrants a Pull Request, but since it is already done and is trivial why not

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22647#pullrequestreview-2492312867

From kbarrett at openjdk.org  Tue Dec 10 15:26:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Dec 2024 15:26:38 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code
In-Reply-To: <1tgNIcP8D_s96blqkNLcCGJO4F80VYbbSe4zg2mRGfg=.0c6cfb7e-3147-43e6-a184-2eab358b23bb@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
 <E-gzafwASr2UGNpQR6Zh0fKNFzqPzPnjCprQ2hZ-OfI=.6ebfafc9-c67c-4666-9ead-72c31c1a6244@github.com>
 <1tgNIcP8D_s96blqkNLcCGJO4F80VYbbSe4zg2mRGfg=.0c6cfb7e-3147-43e6-a184-2eab358b23bb@github.com>
Message-ID: <y1zqYB9va6lUoBaRxCJyygPkcgQo6LnvbkfQrRhH8wg=.731a0a3c-244d-4c66-be3d-071ffcb5caf0@github.com>

On Tue, 10 Dec 2024 13:27:49 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> > I've not verified with the build team that this is the right place ultimately. And I suspect it's not, since your log listed warnings in adlc. I'm not seeing any warnings there, even though (looking at the code) there clearly should be.
> 
> Do we also want ADLC to have nulls cleaned up? I thought it was just HotSpot that the cleanups were aimed at, not including the tools used while building it

That depends on whether one thinks the HotSpot Style Guide should apply to
adlc. I think it should (though I know there are violations, such as C++
Standard Library usage, that perhaps should be documented). But I'm probably
not the right person to make that call. I'll try to remember to discuss with
@vnkozlov.

I think avoiding literal 0 as a null pointer constant is generally good for
readability. Avoidance of NULL in adlc (which is not addressed here)
simplifies the proposed prevention mechanism (JDK-8343802). Otherwise we would
need to exclude the adlc source directory from the scan, and probably ensure
the adlc-generated code didn't include it either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22469#issuecomment-2532028845

From lmesnik at openjdk.org  Tue Dec 10 15:43:01 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 10 Dec 2024 15:43:01 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests [v2]
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <AWbgAUguj-TmZcmCy3zQezCUsXl3tMlm1BVEsmQ8qew=.49e8b85b-6e15-4785-b85c-ecf40e2e998f@github.com>

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into 8345700
 - 8345700: tier{1,2,3}_compiler doesn't cover all compiler tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22614/files
  - new: https://git.openjdk.org/jdk/pull/22614/files/3a6cf638..27d324cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22614&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22614&range=00-01

  Stats: 2447 lines in 1094 files changed: 940 ins; 330 del; 1177 mod
  Patch: https://git.openjdk.org/jdk/pull/22614.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22614/head:pull/22614

PR: https://git.openjdk.org/jdk/pull/22614

From lmesnik at openjdk.org  Tue Dec 10 15:56:41 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 10 Dec 2024 15:56:41 GMT
Subject: Integrated: 8345746: Remove :resourcehogs/compiler from
 :hotspot_slow_compiler
In-Reply-To: <FwDCA82Hak0z63SHjmPUUhmWyma3YhzD3V81OWk9wa0=.8c2706f1-e82b-4d55-a009-195852804741@github.com>
References: <FwDCA82Hak0z63SHjmPUUhmWyma3YhzD3V81OWk9wa0=.8c2706f1-e82b-4d55-a009-195852804741@github.com>
Message-ID: <1R6YdXZ5N5nqEDrnQEqQaqm6mXWgFoR3VK3nUfs9muo=.8ea2af68-b6ce-4cb1-92b2-d23bec012901@github.com>

On Sat, 7 Dec 2024 03:33:34 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The test group
> :resourcehogs/compiler
> contains tests that should not be executed concurrently with *any* tests.
> 
> They might use a lot of resources and cause unexplained sporadic failures of other tests.
> 
> So it should be removed from :hotspot_slow_compiler.

This pull request has now been integrated.

Changeset: d6b5264c
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6b5264c3f7d0c4157ebd73b2f1a98dd15273c61
Stats:     4 lines in 1 file changed: 3 ins; 1 del; 0 mod

8345746: Remove :resourcehogs/compiler from :hotspot_slow_compiler

Reviewed-by: kvn

-------------

PR: https://git.openjdk.org/jdk/pull/22626

From qamai at openjdk.org  Tue Dec 10 16:10:09 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 16:10:09 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v10]
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <i9LjwNLi8i0Id6Q2AbPuE13MvA21KQKBDZjBDkfBEIo=.a6e9a3e3-ff91-4bd1-85e5-7c4a4e62618e@github.com>

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  optimize slice/unslice

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21042/files
  - new: https://git.openjdk.org/jdk/pull/21042/files/146c8cea..a933d466

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21042&range=08-09

  Stats: 134 lines in 8 files changed: 34 ins; 0 del; 100 mod
  Patch: https://git.openjdk.org/jdk/pull/21042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21042/head:pull/21042

PR: https://git.openjdk.org/jdk/pull/21042

From qamai at openjdk.org  Tue Dec 10 16:10:10 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 16:10:10 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v9]
In-Reply-To: <zGoA72-poI1HxF1sGcVwB1iezPeODYc3s1bOQJctAs4=.39153bb0-5ce7-4823-bea6-1fb14922d173@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <RY9M6wF5zoDq8QdBVH-HaFwXtpvGqB1tutZJFzYf4GM=.87e0e5c5-e691-46b3-814b-3f5ecc53b02e@github.com>
 <zGoA72-poI1HxF1sGcVwB1iezPeODYc3s1bOQJctAs4=.39153bb0-5ce7-4823-bea6-1fb14922d173@github.com>
Message-ID: <PT14j-YUu9Yevim-jO-gBV_ujXKbGNdZnyr8RzuAf08=.e3b5acd4-68ca-48b5-ac3d-d54ddeab5cc1@github.com>

On Tue, 10 Dec 2024 08:34:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change wording on VectorLoadShuffleNode
>>   
>>   Co-authored-by: Jatin Bhateja <jatin.bhateja at intel.com>
>
> I am observing some performance drops in slice / unslice benchmarks,  I have just completed this run and not got a chance to root cause.
> ![image](https://github.com/user-attachments/assets/ecb686b6-c3b0-47e9-9325-40341c19ff9d)
> 
> Can you kindly verify once at your end.

@jatin-bhateja Thanks for the performance notice, it was due to the failure to inline `VectorSupport::convert` which I believe is similar to [JDK-8302459](https://bugs.openjdk.org/browse/JDK-8302459) because the `convert` sequence is pretty complex. For now, I refactor the `slice/unslice` routines to take advantage of `toBitsVector`, could you verify if the change fixes the regression on your side?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2532158271

From qamai at openjdk.org  Tue Dec 10 16:10:10 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 10 Dec 2024 16:10:10 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v8]
In-Reply-To: <nvHwVZ7GYRfTiGNRyoSIiRJ-Ufo-QFBxIZg4ii-cECw=.29212e93-eb46-439b-855b-182cfedee37b@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NNYslPgYIRyODBZwq-v3QvSJhZ2_piTirymOR9vzj88=.3d9f5b2a-e931-431e-a2d5-57e88d16d5b5@github.com>
 <vlM5leVl6RBZXcU_D3vW1wnBLkwA5NNM_Dha04KFsEY=.bbd25aa4-5b55-4784-a133-e5107d46f9d6@github.com>
 <6yhvabADaFjfg6DLQXTXSyOapN45WsW5vbSgdu7ZpXM=.e0ef06b5-5ba3-4f7e-b364-fb95909a9acd@github.com>
 <nvHwVZ7GYRfTiGNRyoSIiRJ-Ufo-QFBxIZg4ii-cECw=.29212e93-eb46-439b-855b-182cfedee37b@github.com>
Message-ID: <QNvpzCRs_fGUY5EqlkEvxlVqAWhZBL8Inbop0CSxhDo=.ee9c31bf-1f6c-47ab-bbd2-0b35797bd773@github.com>

On Tue, 10 Dec 2024 09:02:40 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This is called in an `assert` so I think throwing `AssertionError` seems more reasonable, the original implementation also throws `AssertionError`
>
> I see, you want to throw an error here and not just use an assert statement that reports an assertion failure with -ea flag.  This is a newly added routine, why don't you simply return a false and let the assertion invoking this routine do the rest?

This routine is moved from `AbstractShuffle` where it was implemented when all shuffle types share the same constructor  there. Throwing here allows easier construction of the error message.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21042#discussion_r1878383065

From kbarrett at openjdk.org  Tue Dec 10 16:16:57 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Dec 2024 16:16:57 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code [v3]
In-Reply-To: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
Message-ID: <Oe0K6s_ZVAykK4QRkKHo-dX06pPtWSyBZEUOjoJ469c=.18fb7570-5e2f-4cca-8b3f-3546d81c79c7@github.com>

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in s390 code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into fix-s390-zero-null
 - Merge branch 'master' into fix-s390-zero-null
 - simple s390 fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22469/files
  - new: https://git.openjdk.org/jdk/pull/22469/files/dc4985cd..22374e45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22469&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22469&range=01-02

  Stats: 3117 lines in 1457 files changed: 960 ins; 887 del; 1270 mod
  Patch: https://git.openjdk.org/jdk/pull/22469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22469/head:pull/22469

PR: https://git.openjdk.org/jdk/pull/22469

From kbarrett at openjdk.org  Tue Dec 10 16:19:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Dec 2024 16:19:39 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code [v3]
In-Reply-To: <Oe0K6s_ZVAykK4QRkKHo-dX06pPtWSyBZEUOjoJ469c=.18fb7570-5e2f-4cca-8b3f-3546d81c79c7@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
 <Oe0K6s_ZVAykK4QRkKHo-dX06pPtWSyBZEUOjoJ469c=.18fb7570-5e2f-4cca-8b3f-3546d81c79c7@github.com>
Message-ID: <CM7-qZwUVRL7b21hTzcDGTh3L9oa5uJ8DJPFCDsdf84=.46df7d70-4887-4e32-beb4-a7e9a862a80e@github.com>

On Tue, 10 Dec 2024 16:16:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> in s390 code.
>> 
>> Most places involve just changing literal 0 to nullptr.
>> 
>> Removed a dead return after ShouldNotReachHere() that is no longer needed.
>> 
>> Testing:
>> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
>> I don't have the capability to run tests for this platform, so hoping someone
>> from the aix-ppc maintainers can do more testing.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into fix-s390-zero-null
>  - Merge branch 'master' into fix-s390-zero-null
>  - simple s390 fixes

I'd like a review from an s390 porter.  But it's a simple enough change that I'm not going to wait indefinitely.
I'll give it another day.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22469#issuecomment-2532189894

From kbarrett at openjdk.org  Tue Dec 10 16:21:22 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Dec 2024 16:21:22 GMT
Subject: RFR: 8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc
 code [v3]
In-Reply-To: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
References: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
Message-ID: <sQVh3k5jr2dLtffrO4lQc_ArREntkyv-9FkXnUwFxB0=.f13117b2-3783-4075-9247-ea742d68e61a@github.com>

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in ppc code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Removed some unused Address constructors that had a default address argument
> with literal 0 as the default value.  These could have been changed to use
> nullptr as the default value, but since they aren't used...
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into fix-ppc-zero-null
 - Merge branch 'master' into fix-ppc-zero-null
 - Merge branch 'master' into fix-ppc-zero-null
 - simple ppc fixes
 - remove unneeded Address ctors

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22466/files
  - new: https://git.openjdk.org/jdk/pull/22466/files/a3941e41..2a35f20d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22466&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22466&range=01-02

  Stats: 3117 lines in 1457 files changed: 960 ins; 887 del; 1270 mod
  Patch: https://git.openjdk.org/jdk/pull/22466.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22466/head:pull/22466

PR: https://git.openjdk.org/jdk/pull/22466

From shade at openjdk.org  Tue Dec 10 16:23:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Dec 2024 16:23:43 GMT
Subject: RFR: 8345700: tier{1, 2,
 3}_compiler don't cover all compiler tests [v2]
In-Reply-To: <AWbgAUguj-TmZcmCy3zQezCUsXl3tMlm1BVEsmQ8qew=.49e8b85b-6e15-4785-b85c-ecf40e2e998f@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
 <AWbgAUguj-TmZcmCy3zQezCUsXl3tMlm1BVEsmQ8qew=.49e8b85b-6e15-4785-b85c-ecf40e2e998f@github.com>
Message-ID: <eocaggbMfqszQVR3l71LTyljEY3OdDFgSkvRT8LvFIs=.63b38af5-f539-4de4-8ab6-da5947022d17@github.com>

On Tue, 10 Dec 2024 15:43:01 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Hi, 
>> could you please review following fix that update
>> tier3_compiler test group
>> so :hotspot_compiler is always a sum of
>> tier1_compiler, tier2_compiler, tier3_compiler
>> This is natural splitting of tests into 3 layers. 
>> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
>> 
>> New tests in tier3:
>> 9 tests in compiler/ccp/
>> 22 test in ompiler/predicates/
>> 8 tests in compiler/splitif/
>> So the number is not increased significantly.
>> 
>> The new group
>> ` tier2_ctw`
>> was introduced for ctw testing. 
>> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
>> 
>> I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
>> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
>> 
>> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.
>
> Leonid Mesnik has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8345700
>  - 8345700: tier{1,2,3}_compiler doesn't cover all compiler tests

Looks fine, assuming GHA turns out green.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22614#pullrequestreview-2492859848

From kbarrett at openjdk.org  Tue Dec 10 16:23:45 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 10 Dec 2024 16:23:45 GMT
Subject: RFR: 8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc
 code [v2]
In-Reply-To: <cPRkfHs9EZPMZWFsAIttm51cJZyUqy8rxKIX72vv0eI=.730cad53-6ef8-404a-b708-4b59c3d403b9@github.com>
References: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
 <cPRkfHs9EZPMZWFsAIttm51cJZyUqy8rxKIX72vv0eI=.730cad53-6ef8-404a-b708-4b59c3d403b9@github.com>
Message-ID: <ec26p2paTGaFod1lvkTwU4Xw2rWGW-pl91_YDZDWhNY=.c101c8f1-e7d9-4a86-844c-fb5041f64bf9@github.com>

On Fri, 6 Dec 2024 06:33:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> in ppc code.
>> 
>> Most places involve just changing literal 0 to nullptr.
>> 
>> Removed a dead return after ShouldNotReachHere() that is no longer needed.
>> 
>> Removed some unused Address constructors that had a default address argument
>> with literal 0 as the default value.  These could have been changed to use
>> nullptr as the default value, but since they aren't used...
>> 
>> Testing:
>> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
>> I don't have the capability to run tests for this platform, so hoping someone
>> from the aix-ppc maintainers can do more testing.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into fix-ppc-zero-null
>  - Merge branch 'master' into fix-ppc-zero-null
>  - simple ppc fixes
>  - remove unneeded Address ctors

Anyone?  Especially somebody from the aix-ppc folks?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22466#issuecomment-2532199014

From jbhateja at openjdk.org  Tue Dec 10 16:55:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Dec 2024 16:55:44 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v10]
In-Reply-To: <i9LjwNLi8i0Id6Q2AbPuE13MvA21KQKBDZjBDkfBEIo=.a6e9a3e3-ff91-4bd1-85e5-7c4a4e62618e@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <i9LjwNLi8i0Id6Q2AbPuE13MvA21KQKBDZjBDkfBEIo=.a6e9a3e3-ff91-4bd1-85e5-7c4a4e62618e@github.com>
Message-ID: <zNzbGi_NpOFIK1ANbxKDJYtTposaKpaYDvYTOhfmZ2o=.7a970245-dece-4a9e-a7d8-9d26c00ad381@github.com>

On Tue, 10 Dec 2024 16:10:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize slice/unslice

Marked as reviewed by jbhateja (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2492970106

From jbhateja at openjdk.org  Tue Dec 10 16:55:46 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 10 Dec 2024 16:55:46 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v9]
In-Reply-To: <zGoA72-poI1HxF1sGcVwB1iezPeODYc3s1bOQJctAs4=.39153bb0-5ce7-4823-bea6-1fb14922d173@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <RY9M6wF5zoDq8QdBVH-HaFwXtpvGqB1tutZJFzYf4GM=.87e0e5c5-e691-46b3-814b-3f5ecc53b02e@github.com>
 <zGoA72-poI1HxF1sGcVwB1iezPeODYc3s1bOQJctAs4=.39153bb0-5ce7-4823-bea6-1fb14922d173@github.com>
Message-ID: <EAZ5FjzAj2qnU58YH0lBQDYRxeV7JGIBd1g8N-JrtaA=.48ec8701-13e1-4e61-91c3-792588ee2dda@github.com>

On Tue, 10 Dec 2024 08:34:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change wording on VectorLoadShuffleNode
>>   
>>   Co-authored-by: Jatin Bhateja <jatin.bhateja at intel.com>
>
> I am observing some performance drops in slice / unslice benchmarks,  I have just completed this run and not got a chance to root cause.
> ![image](https://github.com/user-attachments/assets/ecb686b6-c3b0-47e9-9325-40341c19ff9d)
> 
> Can you kindly verify once at your end.

> @jatin-bhateja Thanks for the performance notice, it was due to the failure to inline `VectorSupport::convert` which I believe is similar to [JDK-8302459](https://bugs.openjdk.org/browse/JDK-8302459) because the `convert` sequence is pretty complex. For now, I refactor the `slice/unslice` routines to take advantage of `toBitsVector`, could you verify if the change fixes the regres
sion on your side?

![image](https://github.com/user-attachments/assets/3a3b309c-1361-4c7d-8435-b837cfaa3333)


Thanks @merykitty, your latest commit fixed the performance drop. LGTM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2532276493

From psandoz at openjdk.org  Tue Dec 10 17:27:43 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 10 Dec 2024 17:27:43 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v10]
In-Reply-To: <i9LjwNLi8i0Id6Q2AbPuE13MvA21KQKBDZjBDkfBEIo=.a6e9a3e3-ff91-4bd1-85e5-7c4a4e62618e@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <i9LjwNLi8i0Id6Q2AbPuE13MvA21KQKBDZjBDkfBEIo=.a6e9a3e3-ff91-4bd1-85e5-7c4a4e62618e@github.com>
Message-ID: <KPD7-lCEv5OyI6fAgvVvFKOxG2IwYSND5GG1k4MTJdk=.a4a57858-ec9f-4593-aeb0-2d1b9116e23d@github.com>

On Tue, 10 Dec 2024 16:10:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize slice/unslice

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21042#pullrequestreview-2493047392

From lmesnik at openjdk.org  Tue Dec 10 17:42:44 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 10 Dec 2024 17:42:44 GMT
Subject: Integrated: 8345700: tier{1,2,3}_compiler don't cover all compiler
 tests
In-Reply-To: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
References: <LC3_beFUYkNe_GDmXCQ9eO9TJ-9gCsw9I8ZkifVZ-Ow=.654931ee-0dcd-42dc-b629-73a7dc444e42@github.com>
Message-ID: <GX5Pjmj_L-i4RqMHkl6f5W-vqvvKFbcGwjuRBMSqXBU=.2eba1daa-39e3-4303-acec-2c641266076a@github.com>

On Fri, 6 Dec 2024 20:10:08 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Hi, 
> could you please review following fix that update
> tier3_compiler test group
> so :hotspot_compiler is always a sum of
> tier1_compiler, tier2_compiler, tier3_compiler
> This is natural splitting of tests into 3 layers. 
> The fix is done to execution :hotspot_compiler into 3 tiers with corresponding group names.
> 
> New tests in tier3:
> 9 tests in compiler/ccp/
> 22 test in ompiler/predicates/
> 8 tests in compiler/splitif/
> So the number is not increased significantly.
> 
> The new group
> ` tier2_ctw`
> was introduced for ctw testing. 
> It is different from tests in hotspot_compiler, and usually executed separately, So I added it as separate sub-test of tier2.
> 
> I moved ctw from tier3 to tier2 to correspond current tiers of Hotspot CI in our system. 
> If anyone thinks it should be part of tier3 - we can discuss in PR comments how do deal with it.
> 
> @shipilev, could you please take a look and check if these changes are ok to you since you the author of tier2/tier3.

This pull request has now been integrated.

Changeset: 1def2d82
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1def2d82ac003a974759048c6cc0a173b1fc692f
Stats:     16 lines in 1 file changed: 4 ins; 11 del; 1 mod

8345700: tier{1,2,3}_compiler don't cover all compiler tests

Reviewed-by: dholmes, shade

-------------

PR: https://git.openjdk.org/jdk/pull/22614

From kvn at openjdk.org  Tue Dec 10 19:56:37 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 10 Dec 2024 19:56:37 GMT
Subject: RFR: 8345801: C2: Clean up include statements to speed up
 compilation when touching type.hpp
In-Reply-To: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
References: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
Message-ID: <oy5tV7IKhqjY6p6d4Q-LhoTY2-uqNmqHzd-EWT2yGt0=.68a6ed68-663d-4b55-843a-6d420491a876@github.com>

On Tue, 10 Dec 2024 09:31:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.
> 
> In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:
> 
> ... more C1 files
>   #include "c1/c1_Compilation.hpp"
>     #include "compiler/compilerDefinitions.inline.hpp"
>       #include "opto/c2compiler.hpp"
>         #include "opto/output.hpp"    <------------ Problematic include
>           #include "opto/c2_CodeStubs.hpp"
>             #include "opto/compile.hpp"
>               ... more opto files and eventually type.hpp
> 
> This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.
> 
> The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:
> 
> - Mainline: ~1min -> ~40s (1.5 times faster)
> - Valhalla: ~7min -> ~40s (10.5 times faster)
> 
> I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.
> 
> Testing:
> - Oracle CI
> - GHA
> 
> Thanks,
> Christian

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22658#pullrequestreview-2493434167

From dholmes at openjdk.org  Tue Dec 10 20:39:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 20:39:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
Message-ID: <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>

On Tue, 10 Dec 2024 13:29:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove "jvm support"

src/hotspot/share/oops/arrayKlass.hpp line 123:

> 121: 
> 122:   // jvm support
> 123:   jint compute_modifier_flags() const;

I would have expected this to be defined as a virtual function here and then overridden as needed by the various subclasses.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878813713

From coleenp at openjdk.org  Tue Dec 10 21:55:41 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 10 Dec 2024 21:55:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
Message-ID: <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>

On Tue, 10 Dec 2024 20:36:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove "jvm support"
>
> src/hotspot/share/oops/arrayKlass.hpp line 123:
> 
>> 121: 
>> 122:   // jvm support
>> 123:   jint compute_modifier_flags() const;
> 
> I would have expected this to be defined as a virtual function here and then overridden as needed by the various subclasses.

I moved the TypeArrayKlass modifiers to apply to TypeArrayKlass, so they're not accidentally used for ObjArrayKlass, or any other new ArrayKlass that should have different modifiers.  I made the virtual function be defined for the most specific class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1878922185

From dholmes at openjdk.org  Tue Dec 10 23:15:03 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 23:15:03 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v5]
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <WFoGahhLtyNm0WmBSWtg6YpLGvDjh6o--Z9VjKuMXhA=.4b430ea0-a674-43d0-8113-fe5bcc8d82f1@github.com>

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright notice to reflect file where code was copied from

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22472/files
  - new: https://git.openjdk.org/jdk/pull/22472/files/cfdb7da0..0d0a54fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22472/head:pull/22472

PR: https://git.openjdk.org/jdk/pull/22472

From vpaprotski at openjdk.org  Wed Dec 11 01:23:11 2024
From: vpaprotski at openjdk.org (Volodymyr Paprotski)
Date: Wed, 11 Dec 2024 01:23:11 GMT
Subject: RFR: 8344802: Crash in StubRoutines::verify_mxcsr with
 -XX:+EnableX86ECoreOpts and -Xcheck:jni
Message-ID: <AtjB3_WeHJRd2ICTDbCEPFV3rPT8-OeCSwHUqxrcBv8=.187a30ed-89db-4572-9a22-efe549b39079@github.com>

@TobiHartmann  There are still some unanswered questions I have, but committing this since we need to work around vacation schedules.

**This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This fix fixes the crash but I don't understand entirely why the crash happens in the first place.

The issue fixed here are all the CheckJNI warnings:

OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall


Crash has nothing to do with String.indexOf work, but was introduced by my `8319429: Resetting MXCSR flags degrades ecore` change. I was able to get HelloWorld to crash on Windows (`-Xcheck:jni -XX:+EnableX86ECoreOpts`). Same command on linux produces hundreds of CheckJNI warnings. Is it odd that its only being found now, no other CheckJNI tests?

I would appreciate some help/reviews from somebody more aware of the Java-to-C linkage. I think I got the masks fixed, but there is one specific place (see the 'FIXME' question in the diff) for Windows I am not certain about. (@sviswa7 is on vacation for few more weeks)

Note: Crash on windows (if I have the Windows debugger actually correct), happens on:

0x000001f2525f13c1:   fxrstor64 (%rsp)
Stack:
0x00000088f1bfe060:   00007ff8b4384310 0000025bfaeb2200


`00007ff8` _seems_ like a valid mxcsr value, only way it should crash is if top 2 bytes weren't zeroes, which they are.

-------------

Commit messages:
 - whitespace
 - fix mxcsr JNI checks

Changes: https://git.openjdk.org/jdk/pull/22673/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344802
  Stats: 42 lines in 8 files changed: 15 ins; 19 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22673/head:pull/22673

PR: https://git.openjdk.org/jdk/pull/22673

From dlong at openjdk.org  Wed Dec 11 02:13:37 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 11 Dec 2024 02:13:37 GMT
Subject: RFR: 8345801: C2: Clean up include statements to speed up
 compilation when touching type.hpp
In-Reply-To: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
References: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
Message-ID: <vLRHFD3ubHQzZi3YMQ5EjJXn735O4wE0cOZmD2CYqsk=.8d2e86c5-be11-4d5d-88bb-a4003b6e74f1@github.com>

On Tue, 10 Dec 2024 09:31:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.
> 
> In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:
> 
> ... more C1 files
>   #include "c1/c1_Compilation.hpp"
>     #include "compiler/compilerDefinitions.inline.hpp"
>       #include "opto/c2compiler.hpp"
>         #include "opto/output.hpp"    <------------ Problematic include
>           #include "opto/c2_CodeStubs.hpp"
>             #include "opto/compile.hpp"
>               ... more opto files and eventually type.hpp
> 
> This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.
> 
> The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:
> 
> - Mainline: ~1min -> ~40s (1.5 times faster)
> - Valhalla: ~7min -> ~40s (10.5 times faster)
> 
> I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.
> 
> Testing:
> - Oracle CI
> - GHA
> 
> Thanks,
> Christian

Looks good, as long as you tested w/ and w/o precompiled headers.

src/hotspot/share/opto/node.hpp line 2003:

> 2001: }
> 2002: 
> 2003: inline Node_Notes* Compile::node_notes_at(int idx) {

It seems weird to have these inlined Compile methods in node.hpp.  Could we clean this up separately, maybe by moving them to compile.inline.hpp?

-------------

Marked as reviewed by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22658#pullrequestreview-2494128348
PR Review Comment: https://git.openjdk.org/jdk/pull/22658#discussion_r1879215004

From dholmes at openjdk.org  Wed Dec 11 02:52:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Dec 2024 02:52:48 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
 <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
Message-ID: <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>

On Tue, 10 Dec 2024 21:53:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/oops/arrayKlass.hpp line 123:
>> 
>>> 121: 
>>> 122:   // jvm support
>>> 123:   jint compute_modifier_flags() const;
>> 
>> I would have expected this to be defined as a virtual function here and then overridden as needed by the various subclasses.
>
> I moved the TypeArrayKlass modifiers to apply to TypeArrayKlass, so they're not accidentally used for ObjArrayKlass, or any other new ArrayKlass that should have different modifiers.  I made the virtual function be defined for the most specific class.

To be clear I would expect arrayKlass to define a pure virtual function for this, and then each subclass overrides as required. Otherwise you can't generally operate on an arrayKlass but must always know what subtype you are dealing with.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1879248142

From amitkumar at openjdk.org  Wed Dec 11 03:07:56 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 11 Dec 2024 03:07:56 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code [v3]
In-Reply-To: <Oe0K6s_ZVAykK4QRkKHo-dX06pPtWSyBZEUOjoJ469c=.18fb7570-5e2f-4cca-8b3f-3546d81c79c7@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
 <Oe0K6s_ZVAykK4QRkKHo-dX06pPtWSyBZEUOjoJ469c=.18fb7570-5e2f-4cca-8b3f-3546d81c79c7@github.com>
Message-ID: <9d-OwOhGFX4ul6CVBMTb6qHp20mFsbVyMZt4jPRUid4=.0eddca01-e1ec-4dd8-9edb-f3e99db9f522@github.com>

On Tue, 10 Dec 2024 16:16:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> in s390 code.
>> 
>> Most places involve just changing literal 0 to nullptr.
>> 
>> Removed a dead return after ShouldNotReachHere() that is no longer needed.
>> 
>> Testing:
>> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
>> I don't have the capability to run tests for this platform, so hoping someone
>> from the aix-ppc maintainers can do more testing.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into fix-s390-zero-null
>  - Merge branch 'master' into fix-s390-zero-null
>  - simple s390 fixes

Sorry for kept you waiting. LGTM

-------------

Marked as reviewed by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22469#pullrequestreview-2494191347

From fyang at openjdk.org  Wed Dec 11 03:25:49 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 11 Dec 2024 03:25:49 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v2]
In-Reply-To: <SYMLRwRqushrU_T_krYlVGjoGDl_JX-xOLEsrSHUO0I=.1335b7e7-e5ca-42db-84d5-8543e68ecb75@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <SYMLRwRqushrU_T_krYlVGjoGDl_JX-xOLEsrSHUO0I=.1335b7e7-e5ca-42db-84d5-8543e68ecb75@github.com>
Message-ID: <5v2RqjrCPtq-4O2KE8qE18lt7vlG2nTOTjGV3S6Tmkk=.6e0118c6-881e-4aa4-9a71-3f477ac791b0@github.com>

On Tue, 10 Dec 2024 13:28:56 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Code share
>  - Overflow
>  - Merge branch 'master' into 8345322
>  - Concurrent

Thanks for the update. Two comments remain.

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 355:

> 353:   TESTSIZE diff = std::numeric_limits<TESTSIZE>::max() - now;
> 354:   add -= diff;
> 355:   return std::numeric_limits<TESTSIZE>::min() + add;

`next_count(127, 1)` returns -127. Is this expected? Shouldn't we get -128 after the wrap around?

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 375:

> 373: template<>
> 374: constexpr int64_t result_count<int64_t>() {
> 375:     return std::numeric_limits<int64_t>::min() + TOTAL_ITERATIONS;

There is an indentation issue for this line. Maybe we can specialize `int32_t` as well?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22574#pullrequestreview-2494194962
PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1879261321
PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1879269786

From kbarrett at openjdk.org  Wed Dec 11 04:50:46 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 04:50:46 GMT
Subject: RFR: 8345273: Fix -Wzero-as-null-pointer-constant warnings in s390
 code [v3]
In-Reply-To: <TDYz7wLBljuWgGSaXscxyKTvRDQ7N7pEgll4oSW0AsU=.0db1365f-0602-4881-b113-5f5fedd6005e@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
 <l7JdpAZj_vD8ILatSPZTwC2A3taGtny1_JUwx9KrTg4=.00c081e8-db80-4916-ad4e-41caf0b6cb65@github.com>
 <TDYz7wLBljuWgGSaXscxyKTvRDQ7N7pEgll4oSW0AsU=.0db1365f-0602-4881-b113-5f5fedd6005e@github.com>
Message-ID: <w6FHL7gFvAIE20p82_MjTUsm19C6zJ9HujG6koWRKeM=.547c28b5-7685-4143-b00c-61fe41cad823@github.com>

On Tue, 10 Dec 2024 13:52:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into fix-s390-zero-null
>>  - Merge branch 'master' into fix-s390-zero-null
>>  - simple s390 fixes
>
> Marked as reviewed by aph (Reviewer).

Thanks for reviews @theRealAph , @TheShermanTanker , and @offamitkumar

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22469#issuecomment-2533622521

From kbarrett at openjdk.org  Wed Dec 11 04:50:46 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 04:50:46 GMT
Subject: Integrated: 8345273: Fix -Wzero-as-null-pointer-constant warnings in
 s390 code
In-Reply-To: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
References: <wTLRlWNhm4G070txkxopVMpextCT6i1Lfe9GZVpFF0Q=.009f3b08-006d-41c9-ac95-2a07b35e29f3@github.com>
Message-ID: <zkO9idF7_QErViZ3YaFeUTYvMsKdZOD8vEYEgZSrhqQ=.b6ff1e51-35a0-4d7d-9fc6-8938bdbf4f5c@github.com>

On Sun, 1 Dec 2024 16:23:35 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in s390 code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

This pull request has now been integrated.

Changeset: 1e9204fa
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e9204fa43e0c1e22c69dc140829ddf3af750a95
Stats:     13 lines in 6 files changed: 0 ins; 1 del; 12 mod

8345273: Fix -Wzero-as-null-pointer-constant warnings in s390 code

Reviewed-by: jwaters, aph, amitkumar

-------------

PR: https://git.openjdk.org/jdk/pull/22469

From dholmes at openjdk.org  Wed Dec 11 05:03:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Dec 2024 05:03:40 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
 <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
Message-ID: <ojoMiAhvTCH92wf77IgjQsbzdaO_V2zGk3hilJ04sUE=.32475376-0293-4b87-a967-4a92e786963b@github.com>

On Mon, 9 Dec 2024 21:02:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>> 
>> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary file

Looks fine. Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22645#pullrequestreview-2494322540

From jwaters at openjdk.org  Wed Dec 11 05:38:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 11 Dec 2024 05:38:39 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v5]
In-Reply-To: <WFoGahhLtyNm0WmBSWtg6YpLGvDjh6o--Z9VjKuMXhA=.4b430ea0-a674-43d0-8113-fe5bcc8d82f1@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <WFoGahhLtyNm0WmBSWtg6YpLGvDjh6o--Z9VjKuMXhA=.4b430ea0-a674-43d0-8113-fe5bcc8d82f1@github.com>
Message-ID: <DRhf25VJES65UVr8jvrF4q2viGj8a7hpaY_0wI6EVCg=.f5a0050b-b5d9-4991-921d-057f091a8ee5@github.com>

On Tue, 10 Dec 2024 23:15:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
>> 
>> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
>> 
>> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
>> 
>> Testing:
>>  - tiers 1 - 4
>> 
>> Some frame management code was also moved from `VMError` to the `frame` class.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright notice to reflect file where code was copied from

src/hotspot/share/utilities/debug.cpp line 653:

> 651:   NativeStackPrinter nsp(Thread::current_or_null());
> 652:   nsp.print_stack_from_frame(tty, fr, buf, sizeof(buf),
> 653:                   false /* print_source_info */, -1 /* max stack */);

Should this be aligned with tty or is the current formatting preferred? Alternatively it seems like this could all fit on one line, but it's up to you

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1879374137

From jwaters at openjdk.org  Wed Dec 11 05:43:48 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 11 Dec 2024 05:43:48 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v5]
In-Reply-To: <WFoGahhLtyNm0WmBSWtg6YpLGvDjh6o--Z9VjKuMXhA=.4b430ea0-a674-43d0-8113-fe5bcc8d82f1@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <WFoGahhLtyNm0WmBSWtg6YpLGvDjh6o--Z9VjKuMXhA=.4b430ea0-a674-43d0-8113-fe5bcc8d82f1@github.com>
Message-ID: <gwwpXRYCy4ZjLw4KHjuvObuXYtGNEDqqXUqmgAUBwXQ=.234cd215-771c-4b2d-8e7a-50f7cbae4057@github.com>

On Tue, 10 Dec 2024 23:15:03 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
>> 
>> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
>> 
>> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
>> 
>> Testing:
>>  - tiers 1 - 4
>> 
>> Some frame management code was also moved from `VMError` to the `frame` class.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright notice to reflect file where code was copied from

Looks good

src/hotspot/share/runtime/frame.cpp line 1564:

> 1562:  * Gets the caller frame of `fr` for thread `t`.
> 1563:  *
> 1564:  * @returns an invalid frame (i.e. fr.pc() === 0) if the caller cannot be obtained

I got a bit of a chuckle looking at this, the triple equals reminds me of the wonky JavaScript equality checking. Not a review, I just found it funny :)

src/hotspot/share/runtime/frame.hpp line 443:

> 441:   void print_on_error(outputStream* st, char* buf, int buflen, bool verbose = false) const;
> 442:   static void print_C_frame(outputStream* st, char* buf, int buflen, address pc);
> 443:   static frame next_frame(frame fr, Thread* t); // For native stack walking

A thought: Does it make more sense to have next_frame implemented in vmError or nativeStackPrinter and made available through their respective headers rather than as a member of the frame class? Just thinking out loud, I'm fine with it as is

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22472#pullrequestreview-2494367141
PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1879377777
PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1879376735

From dholmes at openjdk.org  Wed Dec 11 05:51:24 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Dec 2024 05:51:24 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v6]
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <HjI8QQqqL_jR0wU8LYF6RlqsASZD6IoKeEh7VlXr7-Y=.caec0436-4770-475e-95d8-6baa34bef6c1@github.com>

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Fix indent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22472/files
  - new: https://git.openjdk.org/jdk/pull/22472/files/0d0a54fb..e0dac873

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22472&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22472.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22472/head:pull/22472

PR: https://git.openjdk.org/jdk/pull/22472

From dholmes at openjdk.org  Wed Dec 11 05:51:25 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Dec 2024 05:51:25 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v5]
In-Reply-To: <gwwpXRYCy4ZjLw4KHjuvObuXYtGNEDqqXUqmgAUBwXQ=.234cd215-771c-4b2d-8e7a-50f7cbae4057@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <WFoGahhLtyNm0WmBSWtg6YpLGvDjh6o--Z9VjKuMXhA=.4b430ea0-a674-43d0-8113-fe5bcc8d82f1@github.com>
 <gwwpXRYCy4ZjLw4KHjuvObuXYtGNEDqqXUqmgAUBwXQ=.234cd215-771c-4b2d-8e7a-50f7cbae4057@github.com>
Message-ID: <h_bmqxpPG8yYJLc1BoN9EkxIPL-0h5sr91jRt70xQSo=.49ffcd7a-fb52-4027-bfd9-3bec8de980d8@github.com>

On Wed, 11 Dec 2024 05:41:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright notice to reflect file where code was copied from
>
> src/hotspot/share/runtime/frame.cpp line 1564:
> 
>> 1562:  * Gets the caller frame of `fr` for thread `t`.
>> 1563:  *
>> 1564:  * @returns an invalid frame (i.e. fr.pc() === 0) if the caller cannot be obtained
> 
> I got a bit of a chuckle looking at this, the triple equals reminds me of the wonky JavaScript equality checking. Not a review, I just found it funny :)

I never noticed the triple :)

> src/hotspot/share/runtime/frame.hpp line 443:
> 
>> 441:   void print_on_error(outputStream* st, char* buf, int buflen, bool verbose = false) const;
>> 442:   static void print_C_frame(outputStream* st, char* buf, int buflen, address pc);
>> 443:   static frame next_frame(frame fr, Thread* t); // For native stack walking
> 
> A thought: Does it make more sense to have next_frame implemented in vmError or nativeStackPrinter and made available through their respective headers rather than as a member of the frame class? Just thinking out loud, I'm fine with it as is

I figured the only class that should know that much about how to walk frames should the frame class. In addition it would look strange for either of the other classes to export that kind of API for other classes to use.

Thanks for re-reviewing. Of course it needs another review now I fixed the indentation issue.

> src/hotspot/share/utilities/debug.cpp line 653:
> 
>> 651:   NativeStackPrinter nsp(Thread::current_or_null());
>> 652:   nsp.print_stack_from_frame(tty, fr, buf, sizeof(buf),
>> 653:                   false /* print_source_info */, -1 /* max stack */);
> 
> Should this be aligned with tty or is the current formatting preferred? Alternatively it seems like this could all fit on one line, but it's up to you

Fixed - thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1879383236
PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1879382577
PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1879381123

From jwaters at openjdk.org  Wed Dec 11 05:57:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 11 Dec 2024 05:57:38 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v6]
In-Reply-To: <HjI8QQqqL_jR0wU8LYF6RlqsASZD6IoKeEh7VlXr7-Y=.caec0436-4770-475e-95d8-6baa34bef6c1@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <HjI8QQqqL_jR0wU8LYF6RlqsASZD6IoKeEh7VlXr7-Y=.caec0436-4770-475e-95d8-6baa34bef6c1@github.com>
Message-ID: <HZ2c8uM0UYfrKobtCmfsSdCJXkkPL9KuylUKKlYE-hw=.1683d7ab-b8eb-4e47-a671-1c585ea93204@github.com>

On Wed, 11 Dec 2024 05:51:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
>> 
>> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
>> 
>> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
>> 
>> Testing:
>>  - tiers 1 - 4
>> 
>> Some frame management code was also moved from `VMError` to the `frame` class.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Marked as reviewed by jwaters (Committer).

Thanks for the fixes!

-------------

PR Review: https://git.openjdk.org/jdk/pull/22472#pullrequestreview-2494382297
PR Comment: https://git.openjdk.org/jdk/pull/22472#issuecomment-2533703749

From jwaters at openjdk.org  Wed Dec 11 05:57:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 11 Dec 2024 05:57:39 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v5]
In-Reply-To: <h_bmqxpPG8yYJLc1BoN9EkxIPL-0h5sr91jRt70xQSo=.49ffcd7a-fb52-4027-bfd9-3bec8de980d8@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <WFoGahhLtyNm0WmBSWtg6YpLGvDjh6o--Z9VjKuMXhA=.4b430ea0-a674-43d0-8113-fe5bcc8d82f1@github.com>
 <gwwpXRYCy4ZjLw4KHjuvObuXYtGNEDqqXUqmgAUBwXQ=.234cd215-771c-4b2d-8e7a-50f7cbae4057@github.com>
 <h_bmqxpPG8yYJLc1BoN9EkxIPL-0h5sr91jRt70xQSo=.49ffcd7a-fb52-4027-bfd9-3bec8de980d8@github.com>
Message-ID: <euwsj71SDwyfN4w5bH8Dhi80BrbVgiuxsTiIJUCHy-c=.c29d48fa-3b93-4e6f-a685-d69e978c3330@github.com>

On Wed, 11 Dec 2024 05:47:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/frame.hpp line 443:
>> 
>>> 441:   void print_on_error(outputStream* st, char* buf, int buflen, bool verbose = false) const;
>>> 442:   static void print_C_frame(outputStream* st, char* buf, int buflen, address pc);
>>> 443:   static frame next_frame(frame fr, Thread* t); // For native stack walking
>> 
>> A thought: Does it make more sense to have next_frame implemented in vmError or nativeStackPrinter and made available through their respective headers rather than as a member of the frame class? Just thinking out loud, I'm fine with it as is
>
> I figured the only class that should know that much about how to walk frames should the frame class. In addition it would look strange for either of the other classes to export that kind of API for other classes to use.
> 
> Thanks for re-reviewing. Of course it needs another review now I fixed the indentation issue.

Ah, I was talking about having it as a top level extern method in either nativeStackPrinter or vmError, and declared in their headers for other code to use, not as a member of any of their classes, but I guess it doesn't matter. Thanks for your patience

I don't think my review would've mattered anyway even if you hadn't changed anything since I'm not a Reviewer, but for the sake of it I'll re-approve :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22472#discussion_r1879387999

From fyang at openjdk.org  Wed Dec 11 07:16:38 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 11 Dec 2024 07:16:38 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v5]
In-Reply-To: <uX8kCHNAjMzAEUV_yeXdISy9UegzPDCY6YLMDTDk_iw=.a4fce981-2c68-4426-8a76-a6a0909a5de9@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <uX8kCHNAjMzAEUV_yeXdISy9UegzPDCY6YLMDTDk_iw=.a4fce981-2c68-4426-8a76-a6a0909a5de9@github.com>
Message-ID: <VwTHC0IRUz5FW-XqXldyN5GzPXVKDiTEf2Ugt9pqIOo=.eb8ca114-98f9-4398-92e7-f647f3af0a57@github.com>

On Tue, 10 Dec 2024 07:53:52 GMT, Gui Cao <gcao at openjdk.org> wrote:

>> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
>> 
>> ### Testing
>> - [x] Run tier1-3 tests on SOPHON SG2042 (release)
>
> Gui Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update for RealFYang's comment

Overall LGTM modulo two minor comments. Maybe we can get a review from the original author of the work? @theRealAph

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 4360:

> 4358:                                     tmp4_reg, nullptr);
> 4359: 
> 4360:   // We will Unspill the tmp registers, so we should mark the result_reg to t1.

Suggestion about the code comment: `// Move the result to t1 as we are about to unspill the tmp registers.`

src/hotspot/cpu/riscv/riscv.ad line 2367:

> 2365:     Label done;
> 2366:     __ check_klass_subtype_slow_path(sub_reg, super_reg, temp_reg, result_reg,
> 2367:                                      nullptr, &miss, true /*set_cond_codes:*/);

Suggestion about the code comment: `nullptr, &miss, /*set_cond_codes*/ true);`

-------------

PR Review: https://git.openjdk.org/jdk/pull/21922#pullrequestreview-2494453862
PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1879460539
PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1879434221

From gcao at openjdk.org  Wed Dec 11 07:23:18 2024
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 11 Dec 2024 07:23:18 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v6]
In-Reply-To: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
Message-ID: <vQqj01yERuZXYKDqyu9OOJnRaKQUJ_jQfePafsRTgvo=.877c8fb5-249e-4804-8d17-ad0ff3151d7e@github.com>

> Follow this patch https://github.com/openjdk/jdk/pull/19989, The fix for [JDK-8332587](https://bugs.openjdk.org/browse/JDK-8332587) was for C2 only. Implement the same fix for C1 and the interpreter.
> 
> ### Testing
> - [x] Run tier1-3 tests on SOPHON SG2042 (release)

Gui Cao has updated the pull request incrementally with one additional commit since the last revision:

  Update code comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21922/files
  - new: https://git.openjdk.org/jdk/pull/21922/files/f9ca53a3..66619993

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21922&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21922.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21922/head:pull/21922

PR: https://git.openjdk.org/jdk/pull/21922

From gcao at openjdk.org  Wed Dec 11 07:23:19 2024
From: gcao at openjdk.org (Gui Cao)
Date: Wed, 11 Dec 2024 07:23:19 GMT
Subject: RFR: 8342881: RISC-V: secondary_super_cache does not scale well:
 C1 and interpreter [v5]
In-Reply-To: <VwTHC0IRUz5FW-XqXldyN5GzPXVKDiTEf2Ugt9pqIOo=.eb8ca114-98f9-4398-92e7-f647f3af0a57@github.com>
References: <hdzhDVLJc_BUripSknrhSPGUc9C3fb7ENkNGnb3Vzi8=.3cd66cb9-ee07-4e50-9536-b03d06bd443d@github.com>
 <uX8kCHNAjMzAEUV_yeXdISy9UegzPDCY6YLMDTDk_iw=.a4fce981-2c68-4426-8a76-a6a0909a5de9@github.com>
 <VwTHC0IRUz5FW-XqXldyN5GzPXVKDiTEf2Ugt9pqIOo=.eb8ca114-98f9-4398-92e7-f647f3af0a57@github.com>
Message-ID: <VtNMd4VTfzawkMogK3DKD3xR5YBDq3MnhgQL3di3crc=.50a5dd60-1dd0-436d-8185-f94596b831d1@github.com>

On Wed, 11 Dec 2024 07:06:45 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Suggestion about the code comment: `// Move the result to t1 as we are about to unspill the tmp registers.`

Fixed.

> Suggestion about the code comment: `nullptr, &miss, /*set_cond_codes*/ true);`

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1879474518
PR Review Comment: https://git.openjdk.org/jdk/pull/21922#discussion_r1879474383

From rehn at openjdk.org  Wed Dec 11 07:44:41 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 11 Dec 2024 07:44:41 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v2]
In-Reply-To: <5v2RqjrCPtq-4O2KE8qE18lt7vlG2nTOTjGV3S6Tmkk=.6e0118c6-881e-4aa4-9a71-3f477ac791b0@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <SYMLRwRqushrU_T_krYlVGjoGDl_JX-xOLEsrSHUO0I=.1335b7e7-e5ca-42db-84d5-8543e68ecb75@github.com>
 <5v2RqjrCPtq-4O2KE8qE18lt7vlG2nTOTjGV3S6Tmkk=.6e0118c6-881e-4aa4-9a71-3f477ac791b0@github.com>
Message-ID: <4sXdnKSzK-nyDq7Q0avPSPYPx1ueWK7-XuNATv3BuxI=.1fbc7ef7-880e-44af-9cba-2e86c0c9a04c@github.com>

On Wed, 11 Dec 2024 03:09:25 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Code share
>>  - Overflow
>>  - Merge branch 'master' into 8345322
>>  - Concurrent
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 355:
> 
>> 353:   TESTSIZE diff = std::numeric_limits<TESTSIZE>::max() - now;
>> 354:   add -= diff;
>> 355:   return std::numeric_limits<TESTSIZE>::min() + add;
> 
> For int8_t, `next_count(127, 1)` returns -127. Is this expected? Shouldn't we get -128 after the wrap around?

Yes, you are correct. Forgot to subtract one for the wrap around count.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1879513125

From rehn at openjdk.org  Wed Dec 11 09:20:14 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 11 Dec 2024 09:20:14 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v3]
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <Ja-4QrIXrl7MCG8xZMny0pQX9XLiHBipQit4-pOudHo=.71fec019-ff43-493e-88a8-b11473838f44@github.com>

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Reviews comments, added uint32

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22574/files
  - new: https://git.openjdk.org/jdk/pull/22574/files/5c7d9f93..a7a6c413

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=01-02

  Stats: 58 lines in 1 file changed: 44 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/22574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22574/head:pull/22574

PR: https://git.openjdk.org/jdk/pull/22574

From rehn at openjdk.org  Wed Dec 11 09:20:16 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 11 Dec 2024 09:20:16 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v2]
In-Reply-To: <5v2RqjrCPtq-4O2KE8qE18lt7vlG2nTOTjGV3S6Tmkk=.6e0118c6-881e-4aa4-9a71-3f477ac791b0@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <SYMLRwRqushrU_T_krYlVGjoGDl_JX-xOLEsrSHUO0I=.1335b7e7-e5ca-42db-84d5-8543e68ecb75@github.com>
 <5v2RqjrCPtq-4O2KE8qE18lt7vlG2nTOTjGV3S6Tmkk=.6e0118c6-881e-4aa4-9a71-3f477ac791b0@github.com>
Message-ID: <GaiMZvwx0cdjidDS-Y6iP1jtjJuNJuYW4bplD7AFbJY=.df6729ab-fdaf-4420-8557-d5edb1d950c4@github.com>

On Wed, 11 Dec 2024 03:17:06 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Code share
>>  - Overflow
>>  - Merge branch 'master' into 8345322
>>  - Concurrent
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 375:
> 
>> 373: template<>
>> 374: constexpr int64_t result_count<int64_t>() {
>> 375:     return std::numeric_limits<int64_t>::min() + TOTAL_ITERATIONS;
> 
> There is an indentation issue for this line. Maybe we can specialize `int32_t` as well?

I wanted to cover when adding uint32.
Used enbaled if instead and added uint32.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1879674532

From rehn at openjdk.org  Wed Dec 11 09:26:13 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 11 Dec 2024 09:26:13 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:

  Inclusive case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22574/files
  - new: https://git.openjdk.org/jdk/pull/22574/files/a7a6c413..1b127e08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22574/head:pull/22574

PR: https://git.openjdk.org/jdk/pull/22574

From mli at openjdk.org  Wed Dec 11 09:33:37 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 11 Dec 2024 09:33:37 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <xBKuMroVJrlcdbXhx5iSzGF0DQn0G5K2Ur0OPNBAQOk=.5f5d06ce-efbd-4a26-8513-e65c0e883412@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22647#pullrequestreview-2494906046

From mli at openjdk.org  Wed Dec 11 09:34:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 11 Dec 2024 09:34:39 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
 <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
Message-ID: <7Bia437IpuiRbqBsYiwM2WQIAAxn0bTbUuRNNw1LNTw=.d8ce64de-67ad-4f6c-ba28-81571b5b2f68@github.com>

On Mon, 9 Dec 2024 21:02:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>> 
>> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary file

Nice batch cleanup!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22645#pullrequestreview-2494911355

From rrich at openjdk.org  Wed Dec 11 10:07:10 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 11 Dec 2024 10:07:10 GMT
Subject: RFR: 8345975: Update SAP SE copyright year to 2024 where it was missed
Message-ID: <FCAc314K5DwyuixHEQa6cVENP8mNKTuLbC5CUpw7LT8=.de37687f-06b5-4208-a50a-07d91e7e1045@github.com>

This pr updates the SAP SE copyright year in files that where changed in 2024 but the update was forgotten.

I used the following command to find the files


git log '--since=Jan 1' --name-only --pretty=format:    \
    --author asteiner                                   \
    --author azeller                                    \
    --author clanger                                    \
    --author goetz                                      \
    --author jbechberger                                \
    --author jkern                                      \
    --author lucy                                       \
    --author mdoerr                                     \
    --author mbaesken                                   \
    --author rrich                                      \
    --author rschmelter                                 \
    --author andrewlu                                   \
    --author ashi                                       \
     | sort -u | xargs grep -l 'SAP SE'

-------------

Commit messages:
 - Update SAP SE copyright year

Changes: https://git.openjdk.org/jdk/pull/22677/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22677&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345975
  Stats: 24 lines in 24 files changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/22677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22677/head:pull/22677

PR: https://git.openjdk.org/jdk/pull/22677

From mdoerr at openjdk.org  Wed Dec 11 10:14:37 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Dec 2024 10:14:37 GMT
Subject: RFR: 8345975: Update SAP SE copyright year to 2024 where it was
 missed
In-Reply-To: <FCAc314K5DwyuixHEQa6cVENP8mNKTuLbC5CUpw7LT8=.de37687f-06b5-4208-a50a-07d91e7e1045@github.com>
References: <FCAc314K5DwyuixHEQa6cVENP8mNKTuLbC5CUpw7LT8=.de37687f-06b5-4208-a50a-07d91e7e1045@github.com>
Message-ID: <D_Nh6IGle4IjOuss07Zc7a1uBlxxWv1UsYl0etgK6ek=.2ba3af12-d0fb-4c1a-81d8-51a3f3a7d916@github.com>

On Wed, 11 Dec 2024 09:55:30 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr updates the SAP SE copyright year in files that where changed in 2024 but the update was forgotten.
> 
> I used the following command to find the files
> 
> 
> git log '--since=Jan 1' --name-only --pretty=format:    \
>     --author asteiner                                   \
>     --author azeller                                    \
>     --author clanger                                    \
>     --author goetz                                      \
>     --author jbechberger                                \
>     --author jkern                                      \
>     --author lucy                                       \
>     --author mdoerr                                     \
>     --author mbaesken                                   \
>     --author rrich                                      \
>     --author rschmelter                                 \
>     --author andrewlu                                   \
>     --author ashi                                       \
>      | sort -u | xargs grep -l 'SAP SE'

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22677#pullrequestreview-2495024644

From ihse at openjdk.org  Wed Dec 11 10:41:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 10:41:43 GMT
Subject: Integrated: 8345805: Update copyright year to 2024 for other files
 where it was missed
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <B1VOMT0QB3nHgSvFhmdcK6A-fMRTPmOsLW-eg-Wnz64=.e713db53-1cd1-481a-a882-afa18a97ec61@github.com>

On Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

This pull request has now been integrated.

Changeset: 8e0f929e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e0f929ecfc1d8de1c2a78e608bcabc45ff6b6af
Stats:     107 lines in 107 files changed: 0 ins; 0 del; 107 mod

8345805: Update copyright year to 2024 for other files where it was missed

Reviewed-by: dholmes, mli, mullan

-------------

PR: https://git.openjdk.org/jdk/pull/22645

From fyang at openjdk.org  Wed Dec 11 11:22:44 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 11 Dec 2024 11:22:44 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
Message-ID: <yYxyjZ528jFZwNIL8BE1fuNUgJjosk5THXbaw2lKfGg=.886fb17e-8ad2-4bea-9ad9-666d6c80c3a1@github.com>

On Wed, 11 Dec 2024 09:26:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inclusive case

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 296:

> 294:   bool zacas = UseZacas;
> 295:   UseZacas = false;
> 296:   run_plain_cmpxchg_tests<uint32_t, Assembler::uint32>();

Not quite sure if we should cover `uint32` type here. `lr.w` used to implement the CAS operation loads a 32-bit word and sign-extend it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1879886196

From clanger at openjdk.org  Wed Dec 11 11:36:36 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 11 Dec 2024 11:36:36 GMT
Subject: RFR: 8345975: Update SAP SE copyright year to 2024 where it was
 missed
In-Reply-To: <FCAc314K5DwyuixHEQa6cVENP8mNKTuLbC5CUpw7LT8=.de37687f-06b5-4208-a50a-07d91e7e1045@github.com>
References: <FCAc314K5DwyuixHEQa6cVENP8mNKTuLbC5CUpw7LT8=.de37687f-06b5-4208-a50a-07d91e7e1045@github.com>
Message-ID: <m50QYalcaA30M-4Xa9vOAft9oEbiGEp3Gy8g-NFifH0=.f23b974e-3f67-45e1-97fd-cd2de1190402@github.com>

On Wed, 11 Dec 2024 09:55:30 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr updates the SAP SE copyright year in files that where changed in 2024 but the update was forgotten.
> 
> I used the following command to find the files
> 
> 
> git log '--since=Jan 1' --name-only --pretty=format:    \
>     --author asteiner                                   \
>     --author azeller                                    \
>     --author clanger                                    \
>     --author goetz                                      \
>     --author jbechberger                                \
>     --author jkern                                      \
>     --author lucy                                       \
>     --author mdoerr                                     \
>     --author mbaesken                                   \
>     --author rrich                                      \
>     --author rschmelter                                 \
>     --author andrewlu                                   \
>     --author ashi                                       \
>      | sort -u | xargs grep -l 'SAP SE'

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22677#pullrequestreview-2495289504

From qamai at openjdk.org  Wed Dec 11 11:47:45 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 11 Dec 2024 11:47:45 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v10]
In-Reply-To: <i9LjwNLi8i0Id6Q2AbPuE13MvA21KQKBDZjBDkfBEIo=.a6e9a3e3-ff91-4bd1-85e5-7c4a4e62618e@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <i9LjwNLi8i0Id6Q2AbPuE13MvA21KQKBDZjBDkfBEIo=.a6e9a3e3-ff91-4bd1-85e5-7c4a4e62618e@github.com>
Message-ID: <yK-shqBcMjMjQdJCi8w6trKJXoYZBfB7J8OqbD8-m7k=.42bbc3ca-323b-4f70-9e0a-d50e76e39a50@github.com>

On Tue, 10 Dec 2024 16:10:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
>> 
>> Regarding the related issues:
>> 
>> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
>> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
>> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
>> 
>> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
>> 
>> Please take a look and leave reviews. Thanks a lot.
>> 
>> The description of the original PR:
>> 
>> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
>> 
>> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
>> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
>> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
>> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
>> Upon these changes, a `rearrange` can emit more efficient code:
>> 
>>     var species = IntVector.SPECIES_128;
>>     var v1 = IntVector.fromArray(species, SRC1, 0);
>>     var v2 = IntVector.fromArray(species, SRC2, 0);
>>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
>> 
>>     Before:
>>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>>     vmovdqu 0x10(%r10),%xmm2
>>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>>     vmovdqu 0x10(%r10),%xmm1
>>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>>     vmovdqu 0x10(%r10),%xmm0
>>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byt...
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   optimize slice/unslice

Thanks a lot for your reviews, I really appreciate it. I will integrate this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2535708384

From stefank at openjdk.org  Wed Dec 11 11:52:41 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 11:52:41 GMT
Subject: RFR: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
In-Reply-To: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
References: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
Message-ID: <ZZsApqgoSMWbjFD9NCGJ_2VEG_CyNXsyv75KEyHI8rk=.f2cff66b-eecb-4abb-8325-1ccc73160b99@github.com>

On Fri, 6 Dec 2024 10:09:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This functions is called after an previous calls to WB_NMTReserveMemory and WB_NMTAttemptReserveMemoryAt, which both already registered an NMT tag. So, explicitly recording an NMT tag for this memory is redundant and slightly confusing.
> 
> The HotSpot JVM code does not record NMT tags when committing memory (except in a special case on Windows when mapping file memory).
> 
> Tested with tier1-3.

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22601#issuecomment-2535724794

From stefank at openjdk.org  Wed Dec 11 11:52:41 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 11:52:41 GMT
Subject: Integrated: 8345658: WB_NMTCommitMemory redundantly records an NMT tag
In-Reply-To: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
References: <BeUh2RzzpK2dARPSkUi55EWOCoSav6MNgv9FuCEbt48=.61c0e6fa-c46e-417a-9bb4-f34dfbb432d0@github.com>
Message-ID: <2uxc6pyFRfEfd3CxsydVEZyLg5rDVo72L4n2Klb6_K8=.06d09c86-cea7-4fb7-8f6f-06e58c75bf44@github.com>

On Fri, 6 Dec 2024 10:09:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> This functions is called after an previous calls to WB_NMTReserveMemory and WB_NMTAttemptReserveMemoryAt, which both already registered an NMT tag. So, explicitly recording an NMT tag for this memory is redundant and slightly confusing.
> 
> The HotSpot JVM code does not record NMT tags when committing memory (except in a special case on Windows when mapping file memory).
> 
> Tested with tier1-3.

This pull request has now been integrated.

Changeset: 28268383
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2826838389ff0ce909289e3a804228226a2a6ab0
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8345658: WB_NMTCommitMemory redundantly records an NMT tag

Reviewed-by: dholmes, jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/22601

From stefank at openjdk.org  Wed Dec 11 11:55:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 11:55:43 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v3]
In-Reply-To: <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
Message-ID: <anpQYvgRmsvKVLHBuQUFsbgyMXHO7EvA8ThpcngK3Ek=.c65f371c-20cb-4223-9cf7-1bf8fb67f328@github.com>

On Mon, 9 Dec 2024 13:07:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
>> 
>> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove functions

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22600#issuecomment-2535755486

From stefank at openjdk.org  Wed Dec 11 11:55:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 11:55:43 GMT
Subject: Integrated: 8345656: Move os alignment functions out of ReservedSpace
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <LdeXgZEdp1Gr0heKcIHpvkTZJw2ZkZZvSDunkRELo4M=.57fc50c8-5a97-49a8-82e7-7745bb3f00d3@github.com>

On Fri, 6 Dec 2024 09:58:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

This pull request has now been integrated.

Changeset: 076bfa68
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/076bfa688c8ee19fa5eea1d18cfa84a3504af762
Stats:     79 lines in 14 files changed: 29 ins; 33 del; 17 mod

8345656: Move os alignment functions out of ReservedSpace

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22600

From thartmann at openjdk.org  Wed Dec 11 12:17:37 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 11 Dec 2024 12:17:37 GMT
Subject: RFR: 8345661: Simplify page size alignment in code heap
 reservation
In-Reply-To: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
References: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
Message-ID: <PRx4JrZhz4L6PkQQNashw0G7_79dE29csKo49NvZf88=.1a15ec40-f450-4750-a9e5-1c9792e0d75e@github.com>

On Fri, 6 Dec 2024 11:03:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While working on a prototype to clean up ReservedSpace ([JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) I noticed that the code that reserves the code heap first aligns the committed memory size towards small pages and then aligns it against the page size that was set up for the ReservedSpace. I suggest that just align to the latter immediately.
> 
> I also inlined the one usage of `os::vm_allocation_granularity`.
> 
> Testing tier1-3

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22604#pullrequestreview-2495499534

From stefank at openjdk.org  Wed Dec 11 12:24:47 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 12:24:47 GMT
Subject: RFR: 8345661: Simplify page size alignment in code heap
 reservation
In-Reply-To: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
References: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
Message-ID: <jW7PD8YcPKlqwnbyiipgJo--DJitIeiE-HDXHNsaS68=.f020dccc-5d04-454d-a768-d8945c65035b@github.com>

On Fri, 6 Dec 2024 11:03:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While working on a prototype to clean up ReservedSpace ([JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) I noticed that the code that reserves the code heap first aligns the committed memory size towards small pages and then aligns it against the page size that was set up for the ReservedSpace. I suggest that just align to the latter immediately.
> 
> I also inlined the one usage of `os::vm_allocation_granularity`.
> 
> Testing tier1-3

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22604#issuecomment-2535841462

From stefank at openjdk.org  Wed Dec 11 12:24:48 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 12:24:48 GMT
Subject: Integrated: 8345661: Simplify page size alignment in code heap
 reservation
In-Reply-To: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
References: <HwaprSMkLfYqpvyfS8987zZI5ph8gkoPKR9viMmE4hY=.9fbe256a-93f0-45b5-a800-6a5ef06a9f65@github.com>
Message-ID: <RxEKajYqj_EDGjUpEFVyfRhtF06DJbPeh8O71g54GVA=.123292f9-6340-4bb7-a9d4-79aae38b36bf@github.com>

On Fri, 6 Dec 2024 11:03:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While working on a prototype to clean up ReservedSpace ([JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) I noticed that the code that reserves the code heap first aligns the committed memory size towards small pages and then aligns it against the page size that was set up for the ReservedSpace. I suggest that just align to the latter immediately.
> 
> I also inlined the one usage of `os::vm_allocation_granularity`.
> 
> Testing tier1-3

This pull request has now been integrated.

Changeset: 2382a2de
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2382a2de964aa9b3a8e1ec2500f6337eeeb94706
Stats:     10 lines in 2 files changed: 1 ins; 5 del; 4 mod

8345661: Simplify page size alignment in code heap reservation

Reviewed-by: dholmes, thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/22604

From chagedorn at openjdk.org  Wed Dec 11 12:35:41 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 11 Dec 2024 12:35:41 GMT
Subject: RFR: 8345801: C2: Clean up include statements to speed up
 compilation when touching type.hpp
In-Reply-To: <oy5tV7IKhqjY6p6d4Q-LhoTY2-uqNmqHzd-EWT2yGt0=.68a6ed68-663d-4b55-843a-6d420491a876@github.com>
References: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
 <oy5tV7IKhqjY6p6d4Q-LhoTY2-uqNmqHzd-EWT2yGt0=.68a6ed68-663d-4b55-843a-6d420491a876@github.com>
Message-ID: <QE8OidGTFEuCYnzGpdTcwYl-6UYbcOizNJSVrmBsHP8=.aa6ecabe-a028-4e2d-9310-96570a997bfb@github.com>

On Tue, 10 Dec 2024 19:53:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.
>> 
>> In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:
>> 
>> ... more C1 files
>>   #include "c1/c1_Compilation.hpp"
>>     #include "compiler/compilerDefinitions.inline.hpp"
>>       #include "opto/c2compiler.hpp"
>>         #include "opto/output.hpp"    <------------ Problematic include
>>           #include "opto/c2_CodeStubs.hpp"
>>             #include "opto/compile.hpp"
>>               ... more opto files and eventually type.hpp
>> 
>> This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.
>> 
>> The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:
>> 
>> - Mainline: ~1min -> ~40s (1.5 times faster)
>> - Valhalla: ~7min -> ~40s (10.5 times faster)
>> 
>> I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.
>> 
>> Testing:
>> - Oracle CI
>> - GHA
>> 
>> Thanks,
>> Christian
>
> Good.

Thanks @vnkozlov and @dean-long for your reviews!

> as long as you tested w/ and w/o precompiled headers.

That's a good point. I thought it was covered by our CI but I've run now a separate testing with `--disable-precompiled-headers` which looked good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22658#issuecomment-2535869467

From chagedorn at openjdk.org  Wed Dec 11 12:35:43 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 11 Dec 2024 12:35:43 GMT
Subject: RFR: 8345801: C2: Clean up include statements to speed up
 compilation when touching type.hpp
In-Reply-To: <vLRHFD3ubHQzZi3YMQ5EjJXn735O4wE0cOZmD2CYqsk=.8d2e86c5-be11-4d5d-88bb-a4003b6e74f1@github.com>
References: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
 <vLRHFD3ubHQzZi3YMQ5EjJXn735O4wE0cOZmD2CYqsk=.8d2e86c5-be11-4d5d-88bb-a4003b6e74f1@github.com>
Message-ID: <RPjNRorvcSyrklKaUkLDMpm3gWdSLf9Gladcbtp5DXo=.e8e06d44-e48d-4419-8ede-0e3627cd1e4d@github.com>

On Wed, 11 Dec 2024 02:10:13 GMT, Dean Long <dlong at openjdk.org> wrote:

>> I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.
>> 
>> In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:
>> 
>> ... more C1 files
>>   #include "c1/c1_Compilation.hpp"
>>     #include "compiler/compilerDefinitions.inline.hpp"
>>       #include "opto/c2compiler.hpp"
>>         #include "opto/output.hpp"    <------------ Problematic include
>>           #include "opto/c2_CodeStubs.hpp"
>>             #include "opto/compile.hpp"
>>               ... more opto files and eventually type.hpp
>> 
>> This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.
>> 
>> The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:
>> 
>> - Mainline: ~1min -> ~40s (1.5 times faster)
>> - Valhalla: ~7min -> ~40s (10.5 times faster)
>> 
>> I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.
>> 
>> Testing:
>> - Oracle CI
>> - GHA
>> 
>> Thanks,
>> Christian
>
> src/hotspot/share/opto/node.hpp line 2003:
> 
>> 2001: }
>> 2002: 
>> 2003: inline Node_Notes* Compile::node_notes_at(int idx) {
> 
> It seems weird to have these inlined Compile methods in node.hpp.  Could we clean this up separately, maybe by moving them to compile.inline.hpp?

I was confused about that as well. There is currently no `compile.inline.hpp` but maybe we should introduce one for such cases. I can file an RFE to clean this up separately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22658#discussion_r1880115791

From jwaters at openjdk.org  Wed Dec 11 13:10:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 11 Dec 2024 13:10:38 GMT
Subject: RFR: 8345801: C2: Clean up include statements to speed up
 compilation when touching type.hpp
In-Reply-To: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
References: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
Message-ID: <7qfOP2-q-3rAgSv1HopwqcUwxGpvzTHkdR6mePsE7IU=.6ca1e945-1aea-4087-bc0a-0f7a235c1874@github.com>

On Tue, 10 Dec 2024 09:31:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.
> 
> In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:
> 
> ... more C1 files
>   #include "c1/c1_Compilation.hpp"
>     #include "compiler/compilerDefinitions.inline.hpp"
>       #include "opto/c2compiler.hpp"
>         #include "opto/output.hpp"    <------------ Problematic include
>           #include "opto/c2_CodeStubs.hpp"
>             #include "opto/compile.hpp"
>               ... more opto files and eventually type.hpp
> 
> This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.
> 
> The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:
> 
> - Mainline: ~1min -> ~40s (1.5 times faster)
> - Valhalla: ~7min -> ~40s (10.5 times faster)
> 
> I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.
> 
> Testing:
> - Oracle CI
> - GHA
> 
> Thanks,
> Christian

It takes just 7 minutes to compile and link HotSpot for you? If only I had that kind of luxury...

-------------

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22658#pullrequestreview-2495622649

From chagedorn at openjdk.org  Wed Dec 11 13:21:37 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 11 Dec 2024 13:21:37 GMT
Subject: RFR: 8345801: C2: Clean up include statements to speed up
 compilation when touching type.hpp
In-Reply-To: <7qfOP2-q-3rAgSv1HopwqcUwxGpvzTHkdR6mePsE7IU=.6ca1e945-1aea-4087-bc0a-0f7a235c1874@github.com>
References: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
 <7qfOP2-q-3rAgSv1HopwqcUwxGpvzTHkdR6mePsE7IU=.6ca1e945-1aea-4087-bc0a-0f7a235c1874@github.com>
Message-ID: <d7sz25oewUzNPQFdGh3AqRGJMaPeeQdiEEx2Z4nDJhk=.292ee8c4-94d5-4875-ad26-0bebddf5d106@github.com>

On Wed, 11 Dec 2024 13:08:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.
>> 
>> In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:
>> 
>> ... more C1 files
>>   #include "c1/c1_Compilation.hpp"
>>     #include "compiler/compilerDefinitions.inline.hpp"
>>       #include "opto/c2compiler.hpp"
>>         #include "opto/output.hpp"    <------------ Problematic include
>>           #include "opto/c2_CodeStubs.hpp"
>>             #include "opto/compile.hpp"
>>               ... more opto files and eventually type.hpp
>> 
>> This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.
>> 
>> The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:
>> 
>> - Mainline: ~1min -> ~40s (1.5 times faster)
>> - Valhalla: ~7min -> ~40s (10.5 times faster)
>> 
>> I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.
>> 
>> Testing:
>> - Oracle CI
>> - GHA
>> 
>> Thanks,
>> Christian
>
> It takes just 7 minutes to compile and link HotSpot for you? If only I had that kind of luxury...

Thanks @TheShermanTanker for your review! The measured numbers are only when starting a hotspot build again after touching `type.hpp`. It takes slightly longer for a full `make hotspot` in Valhalla.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22658#issuecomment-2535972320

From coleenp at openjdk.org  Wed Dec 11 14:12:42 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Dec 2024 14:12:42 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
 <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
 <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>
Message-ID: <NlZJYRC1oDRxwkTVWF4oJVuQNfSLPPA3nuL71r25MfA=.c8e524a8-a8ee-412d-a6a9-e2ff5ec0e81a@github.com>

On Wed, 11 Dec 2024 02:49:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I moved the TypeArrayKlass modifiers to apply to TypeArrayKlass, so they're not accidentally used for ObjArrayKlass, or any other new ArrayKlass that should have different modifiers.  I made the virtual function be defined for the most specific class.
>
> To be clear I would expect arrayKlass to define a pure virtual function for this, and then each subclass overrides as required. Otherwise you can't generally operate on an arrayKlass but must always know what subtype you are dealing with.

Klass has a pure virtual function for this, so ArrayKlass is abstract.  There isn't a reason to redeclare it in ArrayKlass.

     virtual jint compute_modifier_flags() const = 0;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1880266526

From rehn at openjdk.org  Wed Dec 11 14:23:39 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 11 Dec 2024 14:23:39 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <yYxyjZ528jFZwNIL8BE1fuNUgJjosk5THXbaw2lKfGg=.886fb17e-8ad2-4bea-9ad9-666d6c80c3a1@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
 <yYxyjZ528jFZwNIL8BE1fuNUgJjosk5THXbaw2lKfGg=.886fb17e-8ad2-4bea-9ad9-666d6c80c3a1@github.com>
Message-ID: <M0wruVfKxWv8ug89qboi0_hS7YNXzWYf3C25tnizyFo=.3156905d-6799-4676-ba5e-67c187b4d7fd@github.com>

On Wed, 11 Dec 2024 11:20:05 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Inclusive case
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 296:
> 
>> 294:   bool zacas = UseZacas;
>> 295:   UseZacas = false;
>> 296:   run_plain_cmpxchg_tests<uint32_t, Assembler::uint32>();
> 
> Not quite sure if we should cover `uint32` type here. `lr.w` used to implement the CAS operation loads a 32-bit word and sign-extend it.

As passing uint32 as operand size is supported and done by compareAndSwapNNode.
So we should test it ?

Which also says we should add test with max and min size of TESTSIZE, fixing that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1880286352

From szaldana at openjdk.org  Wed Dec 11 14:50:14 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 11 Dec 2024 14:50:14 GMT
Subject: Integrated: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <9bywElNShJzZIwGpmwpdD1hefpWszNwoQr7wLc79PrU=.a3a5fe85-b4c2-4788-b768-27a532d27832@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

This pull request has now been integrated.

Changeset: e2948991
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e2948991544d50a901be509fbc6406c2a16849ec
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8345647: Fix recent NULL usage backsliding in Shenandoah

Reviewed-by: shade, jwaters, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22647

From kbarrett at openjdk.org  Wed Dec 11 15:04:54 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:04:54 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <7Ni9wGl0-v-mm2CxhsfWrZxLeqtyGJsPxkfdMRenqSY=.bb67598a-7c69-4fe5-a258-8d28f2b64c6e@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
 <7Ni9wGl0-v-mm2CxhsfWrZxLeqtyGJsPxkfdMRenqSY=.bb67598a-7c69-4fe5-a258-8d28f2b64c6e@github.com>
Message-ID: <gVa2Sd7boIugLNRXDNXXV11b6UDIo19fYZ1XVt4TWWc=.13aab68a-8902-42a0-a7e6-3d362d487bf1@github.com>

On Tue, 10 Dec 2024 09:28:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Well, it is not technically a `NULL -> nullptr` changes we handle with PRs like these, but I guess it is good to have a consistent wording.

We've also been changing "NULL" in comments and strings.  This avoids having an identifier in those that isn't actually
present in code.  Perhaps more importantly, it prepares for JDK-8343802.  In comments and strings we sometimes use
"null" and sometimes use "nullptr", depending on whether the context code-like or not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536242322

From kbarrett at openjdk.org  Wed Dec 11 15:04:54 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:04:54 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <5I1bO6M3SO1HZWjEh5vPL0sxBFjfMX036OoulYxWWvg=.4228977a-7b82-4c75-a850-b00af55150b8@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
 <5I1bO6M3SO1HZWjEh5vPL0sxBFjfMX036OoulYxWWvg=.4228977a-7b82-4c75-a850-b00af55150b8@github.com>
Message-ID: <ptSdI5eaf3btdbMkSkXRJ3tpZ8Vkb8JyZPOmt3JZWkE=.aa2ff0d0-a027-4933-9416-1b36b806d516@github.com>

On Tue, 10 Dec 2024 13:22:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Not really sure if just a comment change warrants a Pull Request, but since it is already done and is trivial why not

*Any* change requires a JBS issue and a PR.  Sometimes something simple like this can be folded into another change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536247617

From kbarrett at openjdk.org  Wed Dec 11 15:12:14 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:12:14 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <ugDcpsY9uL9lqnDNLplnrh6cEtUKxLGq4C0NVfT-J18=.70e68690-3151-4352-96cb-f1ba10259ac3@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Unfortunately, this change was incomplete.  It missed these:

./share/gc/shenandoah/shenandoahFreeSet.cpp:  // Overwrite with non-zero (non-NULL) values only if necessary for allocation bookkeeping.
./share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp:      assert(obj->klass() != nullptr, "klass should not be NULL");

In both of those lines, s/NULL/null/

Sorry I didn't point this out before this PR was integrated.  I only noticed the PR this morning. Guess we'll need
another JBS issue and PR...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536264494

From kbarrett at openjdk.org  Wed Dec 11 15:17:19 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:17:19 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <O1g478Sj9KWm55u7TfcPHuWIxAmZ08tIJuWmr30qM4k=.d1e0c68c-fdeb-4997-a1dc-78f4344af404@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

New JBS issue for the missed cases:
https://bugs.openjdk.org/browse/JDK-8346008

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536277486

From coleenp at openjdk.org  Wed Dec 11 15:22:23 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Dec 2024 15:22:23 GMT
Subject: [jdk24] RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
Message-ID: <5zEFdNFvNevt7JJnIzQj5GFQ7UHX_aqee34nYQF2Rlo=.35d170cd-ea6e-4c51-b2d2-740cc002cabb@github.com>

This is an automatic, clean backport.

-------------

Commit messages:
 - Backport a6277bb521e07e569cd75a4641b2a05a26f47b0a

Changes: https://git.openjdk.org/jdk/pull/22682/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340212
  Stats: 130 lines in 8 files changed: 106 ins; 7 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/22682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22682/head:pull/22682

PR: https://git.openjdk.org/jdk/pull/22682

From mdoerr at openjdk.org  Wed Dec 11 15:29:14 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 11 Dec 2024 15:29:14 GMT
Subject: RFR: 8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc
 code [v3]
In-Reply-To: <sQVh3k5jr2dLtffrO4lQc_ArREntkyv-9FkXnUwFxB0=.f13117b2-3783-4075-9247-ea742d68e61a@github.com>
References: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
 <sQVh3k5jr2dLtffrO4lQc_ArREntkyv-9FkXnUwFxB0=.f13117b2-3783-4075-9247-ea742d68e61a@github.com>
Message-ID: <ETbFehT84-CsW0zJ55wKuh8lfbC0AshSl21uyxZH5WQ=.d9b78a43-5d65-43c8-979b-dc34b62cc445@github.com>

On Tue, 10 Dec 2024 16:21:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> in ppc code.
>> 
>> Most places involve just changing literal 0 to nullptr.
>> 
>> Removed a dead return after ShouldNotReachHere() that is no longer needed.
>> 
>> Removed some unused Address constructors that had a default address argument
>> with literal 0 as the default value.  These could have been changed to use
>> nullptr as the default value, but since they aren't used...
>> 
>> Testing:
>> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
>> I don't have the capability to run tests for this platform, so hoping someone
>> from the aix-ppc maintainers can do more testing.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into fix-ppc-zero-null
>  - Merge branch 'master' into fix-ppc-zero-null
>  - Merge branch 'master' into fix-ppc-zero-null
>  - simple ppc fixes
>  - remove unneeded Address ctors

Thanks for fixing it! LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22466#pullrequestreview-2496027577

From rehn at openjdk.org  Wed Dec 11 15:55:13 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Wed, 11 Dec 2024 15:55:13 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <M0wruVfKxWv8ug89qboi0_hS7YNXzWYf3C25tnizyFo=.3156905d-6799-4676-ba5e-67c187b4d7fd@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
 <yYxyjZ528jFZwNIL8BE1fuNUgJjosk5THXbaw2lKfGg=.886fb17e-8ad2-4bea-9ad9-666d6c80c3a1@github.com>
 <M0wruVfKxWv8ug89qboi0_hS7YNXzWYf3C25tnizyFo=.3156905d-6799-4676-ba5e-67c187b4d7fd@github.com>
Message-ID: <nvmV0f0ukj6Df_3TKS1PvfaTUILefuCqjHbvo8Xe_5c=.dc28c28b-ad4a-4289-a83d-7dd98f59ed65@github.com>

On Wed, 11 Dec 2024 14:20:31 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 296:
>> 
>>> 294:   bool zacas = UseZacas;
>>> 295:   UseZacas = false;
>>> 296:   run_plain_cmpxchg_tests<uint32_t, Assembler::uint32>();
>> 
>> Not quite sure if we should cover `uint32` type here. `lr.w` used to implement the CAS operation loads a 32-bit word and sign-extend it.
>
> As passing uint32 as operand size is supported and done by compareAndSwapNNode.
> So we should test it ?
> 
> Which also says we should add test with max and min size of TESTSIZE, fixing that.

So one case is shenandoah CAS:ing a narrow oop.
Narrow oop are zero extended (MASM::set_narrow_oop) which means expected, exchange values should be zero extended. Hence I think we have yet another cmpxchg bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1880456441

From szaldana at openjdk.org  Wed Dec 11 16:08:21 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 11 Dec 2024 16:08:21 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <O1g478Sj9KWm55u7TfcPHuWIxAmZ08tIJuWmr30qM4k=.d1e0c68c-fdeb-4997-a1dc-78f4344af404@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
 <O1g478Sj9KWm55u7TfcPHuWIxAmZ08tIJuWmr30qM4k=.d1e0c68c-fdeb-4997-a1dc-78f4344af404@github.com>
Message-ID: <fkpsEeGTrCCaL6xISp6w2T6bdfl-8xsHlL2yNpOT134=.d94f6052-8c65-4ed4-99b1-034bc0d520ee@github.com>

On Wed, 11 Dec 2024 15:14:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
>> 
>> I verified where those uses are with: 
>> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
>> 
>> The relevant output: 
>> 
>> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
>> 9:-  // No need for post barrier if storing NULL
>> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
>> 9:-    // must be either an oop or NULL
>> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
>> 
>> 
>> Changes affect comments only. 
>> 
>> Thanks, 
>> Sonia
>
> New JBS issue for the missed cases:
> https://bugs.openjdk.org/browse/JDK-8346008

Hi @kimbarrett, thanks for taking a look. Apologies for missing those. I can follow up with a PR for the remaining changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536415158

From jiangli at openjdk.org  Wed Dec 11 16:33:20 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 11 Dec 2024 16:33:20 GMT
Subject: RFR: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
Message-ID: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>

Please review this simple fix that changes JVM_IsStaticallyLinked from JVM_ENTRY_NO_ENV to JVM_LEAF. Please see context in https://bugs.openjdk.org/browse/JDK-8345959, thanks.

-------------

Commit messages:
 - Make JVM_IsStaticallyLinked JVM_LEAF.

Changes: https://git.openjdk.org/jdk/pull/22685/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22685&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345959
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22685.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22685/head:pull/22685

PR: https://git.openjdk.org/jdk/pull/22685

From jiangli at openjdk.org  Wed Dec 11 16:33:21 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 11 Dec 2024 16:33:21 GMT
Subject: RFR: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
In-Reply-To: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
References: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
Message-ID: <OX3R6kgGvLQtFvnW-ATj5m1I-4lndWLrlZZXeLK4GX8=.8884460b-9ea1-48f7-9d40-97b3615b5f16@github.com>

On Wed, 11 Dec 2024 16:26:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this simple fix that changes JVM_IsStaticallyLinked from JVM_ENTRY_NO_ENV to JVM_LEAF. Please see context in https://bugs.openjdk.org/browse/JDK-8345959, thanks.

@magicus You added `JVM_IsStaticallyLinked JVM_LEAF`. Would you want to review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22685#issuecomment-2536487685

From coleenp at openjdk.org  Wed Dec 11 17:19:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Dec 2024 17:19:16 GMT
Subject: [jdk24] RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
In-Reply-To: <5zEFdNFvNevt7JJnIzQj5GFQ7UHX_aqee34nYQF2Rlo=.35d170cd-ea6e-4c51-b2d2-740cc002cabb@github.com>
References: <5zEFdNFvNevt7JJnIzQj5GFQ7UHX_aqee34nYQF2Rlo=.35d170cd-ea6e-4c51-b2d2-740cc002cabb@github.com>
Message-ID: <qr7xmY534ffK8bKtkXfW75swU-ErqcpaeUgJixgtKCc=.8b04821c-1c0d-44f4-b313-a0138514b76d@github.com>

On Wed, 11 Dec 2024 14:40:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is an automatic, clean backport.

Thanks Ioi!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22682#issuecomment-2536595003

From iklam at openjdk.org  Wed Dec 11 17:19:15 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 11 Dec 2024 17:19:15 GMT
Subject: [jdk24] RFR: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
In-Reply-To: <5zEFdNFvNevt7JJnIzQj5GFQ7UHX_aqee34nYQF2Rlo=.35d170cd-ea6e-4c51-b2d2-740cc002cabb@github.com>
References: <5zEFdNFvNevt7JJnIzQj5GFQ7UHX_aqee34nYQF2Rlo=.35d170cd-ea6e-4c51-b2d2-740cc002cabb@github.com>
Message-ID: <vqPNgVk6fOwSdMeTy7aFSku7KKnaSiBtjasFbkPhG7c=.fd3dc580-9f33-4c91-84c0-a92a3dbbd0e8@github.com>

On Wed, 11 Dec 2024 14:40:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is an automatic, clean backport.

Marked as reviewed by iklam (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22682#pullrequestreview-2496323918

From coleenp at openjdk.org  Wed Dec 11 17:19:16 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Dec 2024 17:19:16 GMT
Subject: [jdk24] Integrated: 8340212: -Xshare:off
 -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64
In-Reply-To: <5zEFdNFvNevt7JJnIzQj5GFQ7UHX_aqee34nYQF2Rlo=.35d170cd-ea6e-4c51-b2d2-740cc002cabb@github.com>
References: <5zEFdNFvNevt7JJnIzQj5GFQ7UHX_aqee34nYQF2Rlo=.35d170cd-ea6e-4c51-b2d2-740cc002cabb@github.com>
Message-ID: <XsDvJ7jHWbdJz6S_Agr97OWn4qLuwov3tq1HdHHS5aI=.01dabf56-af47-4e58-86c6-369fedc0eca1@github.com>

On Wed, 11 Dec 2024 14:40:52 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is an automatic, clean backport.

This pull request has now been integrated.

Changeset: 950c8adf
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/950c8adfd7a19c1de3d0e36afdc17e5dad15bc30
Stats:     130 lines in 8 files changed: 106 ins; 7 del; 17 mod

8340212: -Xshare:off -XX:CompressedClassSpaceBaseAddress=0x40001000000 crashes on macos-aarch64

Reviewed-by: iklam
Backport-of: a6277bb521e07e569cd75a4641b2a05a26f47b0a

-------------

PR: https://git.openjdk.org/jdk/pull/22682

From mbaesken at openjdk.org  Wed Dec 11 17:52:15 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 11 Dec 2024 17:52:15 GMT
Subject: RFR: 8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc
 code [v3]
In-Reply-To: <sQVh3k5jr2dLtffrO4lQc_ArREntkyv-9FkXnUwFxB0=.f13117b2-3783-4075-9247-ea742d68e61a@github.com>
References: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
 <sQVh3k5jr2dLtffrO4lQc_ArREntkyv-9FkXnUwFxB0=.f13117b2-3783-4075-9247-ea742d68e61a@github.com>
Message-ID: <kkWMEvmIBPt-keRl7exrXldICk931tHCkiVmUYyo0lY=.bedc802b-244a-46bb-98aa-83c6fff78952@github.com>

On Tue, 10 Dec 2024 16:21:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to remove -Wzero-as-null-pointer-constant warnings
>> in ppc code.
>> 
>> Most places involve just changing literal 0 to nullptr.
>> 
>> Removed a dead return after ShouldNotReachHere() that is no longer needed.
>> 
>> Removed some unused Address constructors that had a default address argument
>> with literal 0 as the default value.  These could have been changed to use
>> nullptr as the default value, but since they aren't used...
>> 
>> Testing:
>> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
>> I don't have the capability to run tests for this platform, so hoping someone
>> from the aix-ppc maintainers can do more testing.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into fix-ppc-zero-null
>  - Merge branch 'master' into fix-ppc-zero-null
>  - Merge branch 'master' into fix-ppc-zero-null
>  - simple ppc fixes
>  - remove unneeded Address ctors

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22466#pullrequestreview-2496422912

From kbarrett at openjdk.org  Wed Dec 11 19:28:51 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 19:28:51 GMT
Subject: RFR: 8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc
 code [v3]
In-Reply-To: <kkWMEvmIBPt-keRl7exrXldICk931tHCkiVmUYyo0lY=.bedc802b-244a-46bb-98aa-83c6fff78952@github.com>
References: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
 <sQVh3k5jr2dLtffrO4lQc_ArREntkyv-9FkXnUwFxB0=.f13117b2-3783-4075-9247-ea742d68e61a@github.com>
 <kkWMEvmIBPt-keRl7exrXldICk931tHCkiVmUYyo0lY=.bedc802b-244a-46bb-98aa-83c6fff78952@github.com>
Message-ID: <y4ZZUDzon1BZDROojKWUDie3B-S2osTOITijausqoPA=.f8a48960-9be4-41d9-908f-46e51a04027c@github.com>

On Wed, 11 Dec 2024 17:49:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into fix-ppc-zero-null
>>  - Merge branch 'master' into fix-ppc-zero-null
>>  - Merge branch 'master' into fix-ppc-zero-null
>>  - simple ppc fixes
>>  - remove unneeded Address ctors
>
> Marked as reviewed by mbaesken (Reviewer).

Thanks for reviews @MBaesken and @TheRealMDoerr

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22466#issuecomment-2536929011

From kbarrett at openjdk.org  Wed Dec 11 19:41:15 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 19:41:15 GMT
Subject: Integrated: 8345269: Fix -Wzero-as-null-pointer-constant warnings in
 ppc code
In-Reply-To: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
References: <wXfRP009yl99MiAEXPna7L7NsLNiLrGtApdumoWSz_g=.b4caa23a-59fb-43b2-84ce-94d03f4f2aa6@github.com>
Message-ID: <FCXV6GJcX_cxIOrsOEqTLEtCPcUFrlFadabFhB3CUNU=.5345c02f-6f16-4071-ad75-7c54e0b041ec@github.com>

On Sat, 30 Nov 2024 17:15:17 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to remove -Wzero-as-null-pointer-constant warnings
> in ppc code.
> 
> Most places involve just changing literal 0 to nullptr.
> 
> Removed a dead return after ShouldNotReachHere() that is no longer needed.
> 
> Removed some unused Address constructors that had a default address argument
> with literal 0 as the default value.  These could have been changed to use
> nullptr as the default value, but since they aren't used...
> 
> Testing:
> GHA sanity test build, with and without -Wzero-as-null-pointer-constant enabled.
> I don't have the capability to run tests for this platform, so hoping someone
> from the aix-ppc maintainers can do more testing.

This pull request has now been integrated.

Changeset: 08bdeedf
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08bdeedfd355b61f7cdabbe943657691e5af2c82
Stats:     43 lines in 9 files changed: 0 ins; 9 del; 34 mod

8345269: Fix -Wzero-as-null-pointer-constant warnings in ppc code

Reviewed-by: mdoerr, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/22466

From ihse at openjdk.org  Wed Dec 11 21:00:42 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:00:42 GMT
Subject: RFR: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
In-Reply-To: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
References: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
Message-ID: <JsgdgEAifDvsNFhrnFqD4ZdQeVJI-4IgFGpGEMQXwS0=.a47d3d24-8eab-4380-a100-418c397d06d6@github.com>

On Wed, 11 Dec 2024 16:26:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this simple fix that changes JVM_IsStaticallyLinked from JVM_ENTRY_NO_ENV to JVM_LEAF. Please see context in https://bugs.openjdk.org/browse/JDK-8345959, thanks.

This is likely fine. I must admit I am not aware of the differences between JVM_ENTRY_NO_ENV and JVM_LEAF, and just picked one that seemed reasonable to me given context and other usages.

-------------

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22685#pullrequestreview-2496961731

From ecaspole at openjdk.org  Wed Dec 11 21:57:12 2024
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 11 Dec 2024 21:57:12 GMT
Subject: [jdk24] RFR: 8345405: Add JMH showing the regression in 8341649
Message-ID: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>

8345405: Add JMH showing the regression in 8341649

-------------

Commit messages:
 - Backport 35c00532a1dd2a6df5fc3d5173ca692517675d38

Changes: https://git.openjdk.org/jdk/pull/22686/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22686&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345405
  Stats: 175 lines in 1 file changed: 175 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22686/head:pull/22686

PR: https://git.openjdk.org/jdk/pull/22686

From coleenp at openjdk.org  Wed Dec 11 22:04:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Dec 2024 22:04:36 GMT
Subject: [jdk24] RFR: 8345405: Add JMH showing the regression in 8341649
In-Reply-To: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
References: <4jj7o_PlrKiOAEJrJ1Gu1Xov04T7HN3AW96kHGfTXdU=.ee096740-7fe4-4a38-a902-28a7bb57615d@github.com>
Message-ID: <JPZt71L9k1XVr6kadFxjVLx0Qb4ShbnSFvfI38f67_Y=.cca051c4-9833-49c8-89dd-fc4344b1b1bc@github.com>

On Wed, 11 Dec 2024 17:10:55 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> 8345405: Add JMH showing the regression in 8341649

Marked as reviewed by coleenp (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22686#pullrequestreview-2497108261

From coleenp at openjdk.org  Wed Dec 11 22:07:25 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 11 Dec 2024 22:07:25 GMT
Subject: RFR: 8346040: Zero interpreter build on Linux Aarch64 is broken
Message-ID: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>

This fixes the zero build for aarch64.
Mach5 tier1 testing on Oracle platforms (including aarch64) in progress.

-------------

Commit messages:
 - Fix comments
 - 8346040: Zero interpreter build on Linux Aarch64 is broken

Changes: https://git.openjdk.org/jdk/pull/22692/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22692&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346040
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22692.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22692/head:pull/22692

PR: https://git.openjdk.org/jdk/pull/22692

From jiangli at openjdk.org  Wed Dec 11 23:48:38 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 11 Dec 2024 23:48:38 GMT
Subject: RFR: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
In-Reply-To: <JsgdgEAifDvsNFhrnFqD4ZdQeVJI-4IgFGpGEMQXwS0=.a47d3d24-8eab-4380-a100-418c397d06d6@github.com>
References: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
 <JsgdgEAifDvsNFhrnFqD4ZdQeVJI-4IgFGpGEMQXwS0=.a47d3d24-8eab-4380-a100-418c397d06d6@github.com>
Message-ID: <TrjeYJFfcSo_DNUPzzCcKwtGniXX9EkKu9miECD3_Kg=.32bad3e4-90e2-4a31-902f-572b33325c8b@github.com>

On Wed, 11 Dec 2024 20:58:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Please review this simple fix that changes JVM_IsStaticallyLinked from JVM_ENTRY_NO_ENV to JVM_LEAF. Please see context in https://bugs.openjdk.org/browse/JDK-8345959, thanks.
>
> This is likely fine. I must admit I am not aware of the differences between JVM_ENTRY_NO_ENV and JVM_LEAF, and just picked one that seemed reasonable to me given context and other usages.

Thanks for the quick review, @magicus!

I didn't catch this details while reviewing https://github.com/openjdk/jdk/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5 either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22685#issuecomment-2537427994

From jiangli at openjdk.org  Wed Dec 11 23:48:39 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 11 Dec 2024 23:48:39 GMT
Subject: Integrated: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
In-Reply-To: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
References: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
Message-ID: <8hfle6PtGiLOlZpVZDttoKTqEcswBttnJrKEGrWD1LU=.685f5497-8acd-41b8-a696-25b4ebd1b8c4@github.com>

On Wed, 11 Dec 2024 16:26:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please review this simple fix that changes JVM_IsStaticallyLinked from JVM_ENTRY_NO_ENV to JVM_LEAF. Please see context in https://bugs.openjdk.org/browse/JDK-8345959, thanks.

This pull request has now been integrated.

Changeset: 05c56788
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05c5678886f99290093bf7ad9fb589ee40bb5d29
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8345959: Make JVM_IsStaticallyLinked JVM_LEAF

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/jdk/pull/22685

From fyang at openjdk.org  Thu Dec 12 01:26:43 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 12 Dec 2024 01:26:43 GMT
Subject: RFR: 8345669: RISC-V: fix client build failure due to AlignVector
 after JDK-8343827
In-Reply-To: <RPHEZC2D57VAunuvdW8Uxm2_J-UNm49ZSrTI9T22Bas=.ed26140f-299f-4377-a9bc-28b55633c40e@github.com>
References: <_RhBM0BXO4t3hshmxBBZrseB3x0XM3J2hNafUKnGePc=.7deeecc8-0991-4532-9c4f-d7a06a06e97d@github.com>
 <of-0fm8-0Y6-mSkNvhRDtPWhNAQC9VbmohNJYoqmjQ8=.7f986ed7-5780-47a4-b2fb-9a5554b917fb@github.com>
 <RPHEZC2D57VAunuvdW8Uxm2_J-UNm49ZSrTI9T22Bas=.ed26140f-299f-4377-a9bc-28b55633c40e@github.com>
Message-ID: <n2l9vxJZYcVbCybCF2O1yy-mww3ybW8TcR9nnHANWF4=.1ab114f8-98f0-4e2a-ac6b-91fc49077365@github.com>

On Sat, 7 Dec 2024 09:56:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

> > Thanks. Seems this should be fixed for jdk24 as well.
> 
> Yes, I think so. I just found this issue when I work on another task. I think this pr will not get into 24 automatically, maybe a backport is needed? I'll backport it later.

Yes, I think we should do a backport. And the repo is there: https://github.com/openjdk/jdk24u

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22605#issuecomment-2537541907

From fyang at openjdk.org  Thu Dec 12 02:11:37 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 12 Dec 2024 02:11:37 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <nvmV0f0ukj6Df_3TKS1PvfaTUILefuCqjHbvo8Xe_5c=.dc28c28b-ad4a-4289-a83d-7dd98f59ed65@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
 <yYxyjZ528jFZwNIL8BE1fuNUgJjosk5THXbaw2lKfGg=.886fb17e-8ad2-4bea-9ad9-666d6c80c3a1@github.com>
 <M0wruVfKxWv8ug89qboi0_hS7YNXzWYf3C25tnizyFo=.3156905d-6799-4676-ba5e-67c187b4d7fd@github.com>
 <nvmV0f0ukj6Df_3TKS1PvfaTUILefuCqjHbvo8Xe_5c=.dc28c28b-ad4a-4289-a83d-7dd98f59ed65@github.com>
Message-ID: <lCdcHm8j0yLBPzynH9z9C5QuqI4ae2wvgoAqlQsYraw=.0ba55571-ccba-450e-9ca6-016b7789632b@github.com>

On Wed, 11 Dec 2024 15:52:38 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> As passing uint32 as operand size is supported and done by compareAndSwapNNode.
>> So we should test it ?
>> 
>> Which also says we should add test with max and min size of TESTSIZE, fixing that.
>
> So one case is shenandoah CAS:ing a narrow oop.
> Narrow oop are zero extended (MASM::set_narrow_oop) which means expected, exchange values should be zero extended. Hence I think we have yet another cmpxchg bug.

Sorry, I withdraw my previous comment. I think we are fine here.
I double checked and found that the the zero-extension is there in `MacroAssembler::load_reserved` for `uint32` type [1].

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L3693

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1881265779

From fyang at openjdk.org  Thu Dec 12 02:32:43 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 12 Dec 2024 02:32:43 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
Message-ID: <CSoU_ZjZpId1Gao4M_TtyB34vtRXUJpqqr2sXcMSEZg=.83259432-5eb4-414e-816a-c7f49418ceb6@github.com>

On Wed, 11 Dec 2024 09:26:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inclusive case

Latest version looks good to me. Nice work!

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22574#pullrequestreview-2497465917

From qamai at openjdk.org  Thu Dec 12 03:11:47 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 12 Dec 2024 03:11:47 GMT
Subject: Integrated: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation
In-Reply-To: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
Message-ID: <kUqJUUSj7xB7VLZ08YEzFEfP_jEgUicNd-LQYP_BHr4=.523663c3-40ca-46ad-a226-1e070fa12141@github.com>

On Tue, 17 Sep 2024 16:13:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This is just a redo of https://github.com/openjdk/jdk/pull/13093. mostly just the revert of the backout.
> 
> Regarding the related issues:
> 
> - [JDK-8306008](https://bugs.openjdk.org/browse/JDK-8306008) and [JDK-8309531](https://bugs.openjdk.org/browse/JDK-8309531) have been fixed before the backout.
> - [JDK-8309373](https://bugs.openjdk.org/browse/JDK-8309373) was due to missing `ForceInline` on `AbstractVector::toBitsVectorTemplate`
> - [JDK-8306592](https://bugs.openjdk.org/browse/JDK-8306592), I have not been able to find the root causes. I'm not sure if this is a blocker, now I cannot even build x86-32 tests.
> 
> Finally, I moved some implementation of public methods and methods that call into intrinsics to the concrete class as that may help the compiler know the correct types of the variables.
> 
> Please take a look and leave reviews. Thanks a lot.
> 
> The description of the original PR:
> 
> This patch reimplements `VectorShuffle` implementations to be a vector of the bit type. Currently, `VectorShuffle` is stored as a byte array, and would be expanded upon usage. This poses several drawbacks:
> 
> Inefficient conversions between a shuffle and its corresponding vector. This hinders the performance when the shuffle indices are not constant and are loaded or computed dynamically.
> Redundant expansions in `rearrange` operations. On all platforms, it seems that a shuffle index vector is always expanded to the correct type before executing the `rearrange` operations.
> Some redundant intrinsics are needed to support this handling as well as special considerations in the C2 compiler.
> Range checks are performed using `VectorShuffle::toVector`, which is inefficient for FP types since both FP conversions and FP comparisons are more expensive than the integral ones.
> Upon these changes, a `rearrange` can emit more efficient code:
> 
>     var species = IntVector.SPECIES_128;
>     var v1 = IntVector.fromArray(species, SRC1, 0);
>     var v2 = IntVector.fromArray(species, SRC2, 0);
>     v1.rearrange(v2.toShuffle()).intoArray(DST, 0);
> 
>     Before:
>     movabs $0x751589fa8,%r10            ;   {oop([I{0x0000000751589fa8})}
>     vmovdqu 0x10(%r10),%xmm2
>     movabs $0x7515a0d08,%r10            ;   {oop([I{0x00000007515a0d08})}
>     vmovdqu 0x10(%r10),%xmm1
>     movabs $0x75158afb8,%r10            ;   {oop([I{0x000000075158afb8})}
>     vmovdqu 0x10(%r10),%xmm0
>     vpand  -0xddc12(%rip),%xmm0,%xmm0        # Stub::vector_int_to_byte_mask
>                                                             ;   {ex...

This pull request has now been integrated.

Changeset: 75cfb640
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/75cfb640a6bbdb714321107bceedb39913ee6e1f
Stats:     5051 lines in 64 files changed: 2649 ins; 1066 del; 1336 mod

8310691: [REDO] [vectorapi] Refactor VectorShuffle implementation

Reviewed-by: psandoz, jbhateja, epeter

-------------

PR: https://git.openjdk.org/jdk/pull/21042

From kbarrett at openjdk.org  Thu Dec 12 04:55:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 12 Dec 2024 04:55:35 GMT
Subject: RFR: 8346040: Zero interpreter build on Linux Aarch64 is broken
In-Reply-To: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
References: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
Message-ID: <8PB4zhGb71BE2-LvkC4cpyUqMpxFQm2N7NnTDv2ccKo=.b8f09e4c-e6a6-4d04-8f08-342bd43b5a60@github.com>

On Wed, 11 Dec 2024 22:00:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This fixes the zero build for aarch64.
> Mach5 tier1 testing on Oracle platforms (including aarch64) in progress.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22692#pullrequestreview-2497603419

From dholmes at openjdk.org  Thu Dec 12 05:30:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 05:30:12 GMT
Subject: RFR: 8345911: Enhance error message when IncompatibleClassChangeError
 is thrown for sealed class loading failures
Message-ID: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>

When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:

java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass

as inspection of the class sources will show the expected `permits` and `extends` clauses.

This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.

The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.

The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.

Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".

The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the querie
 s - but we could do it for convenience).

Other testing:
- tiers 1-3

Thanks.

-------------

Commit messages:
 - Remove debugging code from test
 - Fixed copyright
 - 8345911: Enhance error message when IncompatibleClassChangeError is thrown for sealed class loading failures

Changes: https://git.openjdk.org/jdk/pull/22703/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345911
  Stats: 132 lines in 13 files changed: 93 ins; 3 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/22703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22703/head:pull/22703

PR: https://git.openjdk.org/jdk/pull/22703

From dholmes at openjdk.org  Thu Dec 12 05:36:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 05:36:34 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures
In-Reply-To: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
Message-ID: <3IneNNVurqrTuGh8BrRN2sunolfexWpGgxmOzHgpcZ4=.ae6dac89-b6b8-450c-b584-1ca9ec1ad765@github.com>

On Thu, 12 Dec 2024 05:25:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
> 
> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
> 
> as inspection of the class sources will show the expected `permits` and `extends` clauses.
> 
> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
> 
> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
> 
> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
> 
> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
> 
> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the quer
 ies - but we could do it for conveni...

The updated tests need some refinement as when run by jtreg in the CI the classloaders are not as expected ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22703#issuecomment-2537855257

From dholmes at openjdk.org  Thu Dec 12 05:40:01 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 05:40:01 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v2]
In-Reply-To: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
Message-ID: <Qq-cGC5h5GoGxhdiDiUvejWagibSaXvkN59ZZ8_ys-U=.28c09bee-455e-4eb0-a0d8-cd277a3fe756@github.com>

> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
> 
> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
> 
> as inspection of the class sources will show the expected `permits` and `extends` clauses.
> 
> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
> 
> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
> 
> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
> 
> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
> 
> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the quer
 ies - but we could do it for conveni...

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Run tests as othervm to get expected classloader

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22703/files
  - new: https://git.openjdk.org/jdk/pull/22703/files/5e3cd20b..cdc014e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22703/head:pull/22703

PR: https://git.openjdk.org/jdk/pull/22703

From dholmes at openjdk.org  Thu Dec 12 06:24:56 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 06:24:56 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v3]
In-Reply-To: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
Message-ID: <EJCkbTXhm71BcGaXl63Bkc3PzwoD3oL-TVF9TxdPBOc=.f120921c-722b-42f9-a84f-4fd9bb913ae4@github.com>

> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
> 
> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
> 
> as inspection of the class sources will show the expected `permits` and `extends` clauses.
> 
> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
> 
> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
> 
> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
> 
> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
> 
> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the quer
 ies - but we could do it for conveni...

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Updated additional tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22703/files
  - new: https://git.openjdk.org/jdk/pull/22703/files/cdc014e8..87c21f5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=01-02

  Stats: 14 lines in 2 files changed: 8 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22703/head:pull/22703

PR: https://git.openjdk.org/jdk/pull/22703

From dholmes at openjdk.org  Thu Dec 12 06:45:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 06:45:40 GMT
Subject: RFR: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
In-Reply-To: <TrjeYJFfcSo_DNUPzzCcKwtGniXX9EkKu9miECD3_Kg=.32bad3e4-90e2-4a31-902f-572b33325c8b@github.com>
References: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
 <JsgdgEAifDvsNFhrnFqD4ZdQeVJI-4IgFGpGEMQXwS0=.a47d3d24-8eab-4380-a100-418c397d06d6@github.com>
 <TrjeYJFfcSo_DNUPzzCcKwtGniXX9EkKu9miECD3_Kg=.32bad3e4-90e2-4a31-902f-572b33325c8b@github.com>
Message-ID: <0vBDGlgJw1F599UrZDwxF1kzOUMtUNtB1Fy-wMcjP_Q=.aab39274-fcfa-47f8-87ab-26d07003c512@github.com>

On Wed, 11 Dec 2024 23:44:46 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is likely fine. I must admit I am not aware of the differences between JVM_ENTRY_NO_ENV and JVM_LEAF, and just picked one that seemed reasonable to me given context and other usages.
>
> Thanks for the quick review, @magicus!
> 
> I didn't catch this details while reviewing https://github.com/openjdk/jdk/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5 either.

@jianglizhou please remember the two reviewer rule for hotspot changes and the 24 hour rule for non-trivial changes. When Magnus admits to not knowing the significance of leaf versus non-leaf his one review hardly seems sufficient in any case.

The change to leaf is of course fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22685#issuecomment-2537944214

From dholmes at openjdk.org  Thu Dec 12 07:48:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 07:48:40 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
Message-ID: <5hg27Hnzf2dbEZbYxyJoVFxBSvrrO9a36DjjWN4A5Zw=.d7b55ac2-db43-4d22-b14f-fcd5b4720a7b@github.com>

On Tue, 10 Dec 2024 13:29:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove "jvm support"

LGTM. Sorry for the  "red herrings".

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2498127779

From dholmes at openjdk.org  Thu Dec 12 07:48:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 07:48:41 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v2]
In-Reply-To: <NlZJYRC1oDRxwkTVWF4oJVuQNfSLPPA3nuL71r25MfA=.c8e524a8-a8ee-412d-a6a9-e2ff5ec0e81a@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <u6kJF4AR9RS1zSsmKoDJfpCS3E13Kg1XAea8dcOEJhw=.ae51b9be-62d2-4336-add3-35d5b2b7088a@github.com>
 <ncl1tsg5LehchrAjf2SDFv_LGZW_lFepwqG1gcm7VqM=.883bdf97-4eda-4399-bc00-bc996ae3f8cd@github.com>
 <ihVOybWm3-KpAyNpLIt_Wj72RvhEU7oA773JGjy2GSk=.8d1aa458-4a65-45ac-bec4-e5524d49f936@github.com>
 <ObrgOxECu35xjUbYW15ul1SeeF2GwVqP9sOxiasbyiw=.dd2d89de-1d47-4ce6-8b66-bf8d99b0f498@github.com>
 <NlZJYRC1oDRxwkTVWF4oJVuQNfSLPPA3nuL71r25MfA=.c8e524a8-a8ee-412d-a6a9-e2ff5ec0e81a@github.com>
Message-ID: <03PAzWTc7UJmXroMZvBvW-xEZITKyaAOnfQLkswxMOo=.2ddea14d-825d-413c-8759-47d879cd98fe@github.com>

On Wed, 11 Dec 2024 14:10:27 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> To be clear I would expect arrayKlass to define a pure virtual function for this, and then each subclass overrides as required. Otherwise you can't generally operate on an arrayKlass but must always know what subtype you are dealing with.
>
> Klass has a pure virtual function for this, so ArrayKlass is abstract.  There isn't a reason to redeclare it in ArrayKlass.
> 
>      virtual jint compute_modifier_flags() const = 0;

Sorry I didn't realize that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22618#discussion_r1881532974

From dholmes at openjdk.org  Thu Dec 12 07:59:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 07:59:36 GMT
Subject: RFR: 8346040: Zero interpreter build on Linux Aarch64 is broken
In-Reply-To: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
References: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
Message-ID: <VzGzEs58XMmZrNjwbL_WX1hhkVXE1bXtEAwkgjokl9Y=.2e10799b-7a24-41d7-8844-282b6d864445@github.com>

On Wed, 11 Dec 2024 22:00:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This fixes the zero build for aarch64.
> Mach5 tier1 testing on Oracle platforms (including aarch64) in progress.

This appears to fix the immediate problem, but I'm unclear why we need a special API for one architecture, or why it resides in shared code. ??

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22692#pullrequestreview-2498167807

From mbaesken at openjdk.org  Thu Dec 12 09:47:10 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Dec 2024 09:47:10 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files
Message-ID: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>

We should output more information about the JVMTI agents in the hserr file.

-------------

Commit messages:
 - JDK-8346082

Changes: https://git.openjdk.org/jdk/pull/22706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346082
  Stats: 44 lines in 3 files changed: 44 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22706/head:pull/22706

PR: https://git.openjdk.org/jdk/pull/22706

From mli at openjdk.org  Thu Dec 12 09:49:41 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 12 Dec 2024 09:49:41 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
Message-ID: <xl6AXujqlnKrt7SnPj5J2U6_7iWbcIaHSHB1K4vMO74=.36e0c189-d044-4543-8e1d-cdfbf97fba53@github.com>

On Wed, 11 Dec 2024 09:26:13 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inclusive case

Nice work. Thanks!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22574#pullrequestreview-2498661788

From galder at openjdk.org  Thu Dec 12 10:21:34 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 12 Dec 2024 10:21:34 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v5]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <VbKPGtuz29kyKSggLbStioW7xXyaJZ6KHj9y7VkGneQ=.159543fc-b1b1-46d9-b06b-0781c2c90a06@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 31 additional commits since the last revision:

 - Merge branch 'master' into topic.intrinsify-max-min-long
 - Use same default size as in other vector reduction benchmarks
 - Renamed benchmark class
 - Double/Float tests only when avx enabled
 - Make state class non-final
 - Restore previous benchmark iterations and default param size
 - Add clipping range benchmark that uses min/max
 - Encapsulate benchmark state within an inner class
 - Avoid creating result array in benchmark method
 - Merge branch 'master' into topic.intrinsify-max-min-long
 - ... and 21 more: https://git.openjdk.org/jdk/compare/3c126865...aca09222

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/0a8718e1..aca09222

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=03-04

  Stats: 592212 lines in 9243 files changed: 324831 ins; 214673 del; 52708 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From dholmes at openjdk.org  Thu Dec 12 11:37:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 11:37:39 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <YIiokWQv-sch2QvtCga56M3_3rVOkSMM0Z2r1sEkNMc=.0cc66ada-4c49-46a5-8b6e-811f983f6523@github.com>

On Thu, 12 Dec 2024 09:42:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should output more information about the JVMTI agents in the hserr file.

src/hotspot/share/runtime/os.cpp line 1153:

> 1151: #else
> 1152:   st->print_cr("JVMTI support not included in this JVM.");
> 1153: #endif

This is unreachable given the caller is already guarded. It is also unnecessary to report this.

src/hotspot/share/utilities/vmError.cpp line 1279:

> 1277: 
> 1278: #if INCLUDE_JVMTI
> 1279:   STEP_IF("printing jvmti agent infos", _verbose)

Suggestion:

  STEP_IF("printing jvmti agent info", _verbose)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1881898451
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1881898831

From epeter at openjdk.org  Thu Dec 12 12:05:42 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Thu, 12 Dec 2024 12:05:42 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
Message-ID: <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>

On Tue, 10 Dec 2024 09:10:04 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>>> Overall, looks fine.
>>> 
>>> So, there will be `inline_min_max`, `inline_fp_min_max`, and `inline_long_min_max` which slightly vary. I'd prefer to see them unified. (Or, at least, enhance `inline_min_max` to cover `minL`/maxL` cases).
>>> 
>>> Also, it's a bit confusing to see int variants names w/o basic type (`_min`/`_minL` vs `_minI`/`_minL`). Please, clean it up along the way. (FTR I'm also fine handling the renaming as a separate change.)
>> 
>> @iwanowww I applied the changes you suggested. Could you review them?
>
>> @galderz Thanks for taking this task on! Had a quick look at it. So auto-vectorization in SuperWord should now be working, right? If yes:
>> 
>> It would be nice if you tested both for `IRNode.MIN_VL` and `IRNode.MIN_REDUCTION_V`, the same for max.
>> 
>> You may want to look at these existing tests, to see what other tests there are for the `int` version: `test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Int.java` `test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java` `test/hotspot/jtreg/compiler/vectorization/TestAutoVecIntMinMax.java` `test/hotspot/jtreg/compiler/c2/TestMinMaxSubword.java` There may be some duplicates already here... not sure. 
> 
> +1 to adding such tests. I'm looking into it right now. It's a bit confusing how the tests are spread around (and duplication?) but I'm currently leaning towards adding a `compiler/loopopts/superword/MinMaxRed_Long.java`.
> 
>> And maybe you need to check what to do about probabilities as well.
> 
> I will add probabilities logic (50, 80, 100) to control data, but you can already see that from https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872 that with the patch in an AVX512 system min/max reduction nodes will appear in all probabilities.

@galderz Yes, there is significant duplication, sadly. Often there were old tests there, but then one comes along and sees that one wants to have more comprehensive tests. So one adds it, but does not feel 100% comfortable removing old tests. A little bit of duplication is probably ok. Often, there are still subtle differences, and sometimes those end up mattering.

`compiler/loopopts/superword/MinMaxRed_Long.java` sounds like a good idea.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2538713997

From mbaesken at openjdk.org  Thu Dec 12 12:37:14 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Dec 2024 12:37:14 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v2]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <pMZ0CbwhuRAWfniGyV2NQii9pLkfICbSakT8Nqn0kJQ=.1d78fba4-e067-4409-bec1-c5bb6db67b41@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  remove unneeded code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/b6be8ec3..738dd8f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22706/head:pull/22706

PR: https://git.openjdk.org/jdk/pull/22706

From mbaesken at openjdk.org  Thu Dec 12 12:41:28 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 12 Dec 2024 12:41:28 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v3]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  infos -> info

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/738dd8f0..fa422ce3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22706/head:pull/22706

PR: https://git.openjdk.org/jdk/pull/22706

From coleenp at openjdk.org  Thu Dec 12 12:50:44 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 12:50:44 GMT
Subject: RFR: 8346040: Zero interpreter build on Linux Aarch64 is broken
In-Reply-To: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
References: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
Message-ID: <OWRVEGPD5w76R-ny8NVvEYPzrZURwWfMP8yeTEp03IY=.c9272f6d-4929-49c5-81ed-96108a998057@github.com>

On Wed, 11 Dec 2024 22:00:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This fixes the zero build for aarch64.
> Mach5 tier1 testing on Oracle platforms (including aarch64) in progress.

There's an optimization/bug fix in aarch64 macroAssembly code that reduces the number of instructions in encoding and decoding klass pointers: JDK-8234794.  The constraints it adds are not in shared code.
Thanks for reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22692#issuecomment-2538810668

From coleenp at openjdk.org  Thu Dec 12 12:50:44 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 12:50:44 GMT
Subject: Integrated: 8346040: Zero interpreter build on Linux Aarch64 is broken
In-Reply-To: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
References: <ks6anmgLjEKoK3lN6U0LpFZGD33ENhylBU-QyNcGtzA=.712d0e7f-eac3-4174-8463-cb9fcdcc3467@github.com>
Message-ID: <4lQrToWOBl2Nx4sEfMDvP_-FrpZLtIPOzrtq9jLVqcE=.d8afc766-2435-4585-a7ab-52fd4c84fe9b@github.com>

On Wed, 11 Dec 2024 22:00:11 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This fixes the zero build for aarch64.
> Mach5 tier1 testing on Oracle platforms (including aarch64) in progress.

This pull request has now been integrated.

Changeset: ef6e987a
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef6e987a006ef81fb0cc6c12a88ee954738ec5d0
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8346040: Zero interpreter build on Linux Aarch64 is broken

Reviewed-by: kbarrett, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22692

From rehn at openjdk.org  Thu Dec 12 13:42:29 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 12 Dec 2024 13:42:29 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v5]
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <0lNEWMLaI7okBDC99caEXqqGTqwUVa-oYEv448jU6R0=.e509bb6e-d317-4957-a143-59f35bd930b6@github.com>

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into 8345322
 - Fixed tests for uint32 and added edges cases
 - Inclusive case
 - Reviews comments, added uint32
 - Code share
 - Overflow
 - Merge branch 'master' into 8345322
 - Concurrent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22574/files
  - new: https://git.openjdk.org/jdk/pull/22574/files/1b127e08..5b91eead

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=03-04

  Stats: 13565 lines in 2541 files changed: 7181 ins; 1697 del; 4687 mod
  Patch: https://git.openjdk.org/jdk/pull/22574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22574/head:pull/22574

PR: https://git.openjdk.org/jdk/pull/22574

From rehn at openjdk.org  Thu Dec 12 13:45:37 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 12 Dec 2024 13:45:37 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <xl6AXujqlnKrt7SnPj5J2U6_7iWbcIaHSHB1K4vMO74=.36e0c189-d044-4543-8e1d-cdfbf97fba53@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
 <xl6AXujqlnKrt7SnPj5J2U6_7iWbcIaHSHB1K4vMO74=.36e0c189-d044-4543-8e1d-cdfbf97fba53@github.com>
Message-ID: <7UbnVUK0Ea-iat1sZb3nJTvGExxPPW8IhPb73I_v8iY=.89e24c7d-bf47-4d12-9aaa-bc466369c3f9@github.com>

On Thu, 12 Dec 2024 09:46:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Inclusive case
>
> Nice work. Thanks!

Thanks @Hamlin-Li @RealFYang 

But I wanted to add the edge cases, so I found an issue in the gtest.

Fixed! Please have another look!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22574#issuecomment-2538985120

From rehn at openjdk.org  Thu Dec 12 13:45:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Thu, 12 Dec 2024 13:45:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <lCdcHm8j0yLBPzynH9z9C5QuqI4ae2wvgoAqlQsYraw=.0ba55571-ccba-450e-9ca6-016b7789632b@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
 <yYxyjZ528jFZwNIL8BE1fuNUgJjosk5THXbaw2lKfGg=.886fb17e-8ad2-4bea-9ad9-666d6c80c3a1@github.com>
 <M0wruVfKxWv8ug89qboi0_hS7YNXzWYf3C25tnizyFo=.3156905d-6799-4676-ba5e-67c187b4d7fd@github.com>
 <nvmV0f0ukj6Df_3TKS1PvfaTUILefuCqjHbvo8Xe_5c=.dc28c28b-ad4a-4289-a83d-7dd98f59ed65@github.com>
 <lCdcHm8j0yLBPzynH9z9C5QuqI4ae2wvgoAqlQsYraw=.0ba55571-ccba-450e-9ca6-016b7789632b@github.com>
Message-ID: <0xauupyvFyIhuLmLDq-JTh0A0O5_HpgVxr3rgIEVzn8=.d4a974e9-e6a1-4076-8d95-ebda3fd85ad6@github.com>

On Thu, 12 Dec 2024 02:08:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> So one case is shenandoah CAS:ing a narrow oop.
>> Narrow oop are zero extended (MASM::set_narrow_oop) which means expected, exchange values should be zero extended. Hence I think we have yet another cmpxchg bug.
>
> Sorry, I withdraw my previous comment. I think we are fine here.
> I double checked and found that the the zero-extension is there in `MacroAssembler::load_reserved` for `uint32` type [1].
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L3693

I found an issue in the gtest using uint32_t.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1882135012

From alanb at openjdk.org  Thu Dec 12 13:46:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Dec 2024 13:46:36 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v3]
In-Reply-To: <EJCkbTXhm71BcGaXl63Bkc3PzwoD3oL-TVF9TxdPBOc=.f120921c-722b-42f9-a84f-4fd9bb913ae4@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <EJCkbTXhm71BcGaXl63Bkc3PzwoD3oL-TVF9TxdPBOc=.f120921c-722b-42f9-a84f-4fd9bb913ae4@github.com>
Message-ID: <7hNUkirFaGdTEBv7DiTnTsPOsFLAiDDSrbD6JqQEePs=.dd37fa59-4401-4ea3-ae7c-f8a3a9ec238f@github.com>

On Thu, 12 Dec 2024 06:24:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
>> 
>> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
>> 
>> as inspection of the class sources will show the expected `permits` and `extends` clauses.
>> 
>> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
>> 
>> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
>> 
>> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
>> 
>> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
>> 
>> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the que
 ries - ...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated additional tests

src/hotspot/share/oops/instanceKlass.cpp line 234:

> 232:              "and sealed class %s is in module \"%s\" for loader %s",
> 233:              k->external_name(), k->module()->name_as_C_string(), k->module()->loader_data()->loader_name_and_id(),
> 234:              this->external_name(), this->module()->name_as_C_string(), this->module()->loader_data()->loader_name_and_id());

This looks quite good except that the word "for" in "for loader %s" looks a bit strange.  In API docs we speak of "the ClassLoader for a module", not the other way around. Class loaders optionally have a name so I suppose the "loader %s" should put quotes around the name like it does for the module name.

src/hotspot/share/oops/instanceKlass.cpp line 240:

> 238: 
> 239:   if (!k->is_public() && !is_same_class_package(k)) {
> 240:     ss.print("Failed same run-time package check: non-public subclass %s is in package \"%s\" with classloader %s,"

Since we paste the same module check at this point then it might be simpler to say that it fails the same package check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1882141892
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1882144307

From stefank at openjdk.org  Thu Dec 12 13:51:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 12 Dec 2024 13:51:54 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
Message-ID: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>

The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.

See the first comment for the full description:

-------------

Commit messages:
 - 8345655: Move reservation code out of ReservedSpace

Changes: https://git.openjdk.org/jdk/pull/22712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345655
  Stats: 2107 lines in 59 files changed: 1182 ins; 806 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/22712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22712/head:pull/22712

PR: https://git.openjdk.org/jdk/pull/22712

From stefank at openjdk.org  Thu Dec 12 13:51:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 12 Dec 2024 13:51:54 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <PyVpptUQ7h-jDOalpYvXbGOFsNtu1n9fdu7TOpTn0Cc=.277baa16-ef60-464b-823a-ad4a4ee9725e@github.com>

On Thu, 12 Dec 2024 13:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

The dual functionality of `ReservedSpace` makes the code hard to read and it is hard to see / realize that the constructors reserve memory. However, this is not the only reason to try to take a step back and clean up `ReservedSpace`. So while doing a restructure here I also want to clean up things like:

1) Move the `_noaccess_prefix` and related code out from `ReservedSpace` into `ReservedHeapSpace`.
2) Move `_fd_for_heap` out out of `ReservedSpace`.
3) Clearer requirements and asserts w.r.t. the input arguments size, alignment, and page_size. 
4) ... and some more along the way while creating the patch. See the items below.

When reviewing this I would suggest that you compare the old code in virtualspace.cpp with the code in reservedSpace.cpp.

A guide to changes in the diff:

a) Whether memory reservation is for executable memory is confined to a limited number of places: The top-level memory reservation function and the function that reserves code. There's no need for other reservation places to pass in !ExecMem (or false), that is hidden from most callers.

b) The old code had shared helpers to handled the case when we map anonymous memory and the case when we mapped the heap to a file. I separated the two paths. This adds a small amount of code duplication, but IMHO it makes the code easier to read and it removes a bunch of dispatch if-statements in the lower level functions.

c) When starting with this patch I wanted to cleanup so that it would be slightly cleaner to pass down NMT MemTags, but I backed off because we need to make a couple of changes and fixes to NMT and CDS before that will be possible. Therefore you can see places where we don't pass down MemTags and you can see `mtNone` default values. My intention for this patch is to try to not change any of the places where NMT is called. Hopefully, we can get rid of the `mtNone` in the time frame of JDK 25.

d) G1 and Shenandoah used to call one `ReservedSpace` constructor that also changed the size of the requested memory. I've removed that convenience and let the GC fix the parameters themselves before calling the code that reserves memory. This allows us to have stricter argument validation checks. It also makes the reservation functions that we have left more consistent and therefore easier to understand also to call the right function.

e) As a future change, I would like to remove the memory reservation overload that helps the caller guess if they want large pages or not. There's a lot of confusion around that functionality, and I would prefer to let the callers that want to set up explicit large pages make that request explicitly instead. In fact, if you check the code today you could find a place where the GC code says that it doesn't want large pages, but if you follow the code you see that it still gets it. For now I have left this "capability" as-is.

f) I removed `MemRegion* ReservedSpace::region()`, since `HeapWords*` are so tied to the GC / Heap. An alternative could have been to move it to `ReservedHeapSpace`, but I don't think it is worth keeping that function.

g) You will see a few changes to the include files as a result of code moving.

h) I've stopped allowing 0 as an alignment argument. The required minimum alignment is `os::vm_allocation_granularity()`. Note, that we still have an overload for those who don't want to care about the alignment. That functions uses `os::vm_allocation_granularity()` under the hood. This allows for stricter checks and removes the code that changed alignment inside the reservation code.

i) `ReservedSpace::release()` used to clear the members of the `Reservedspace` instance. Since I have decoupled reserving/releasing from `ReservedSpace`. Code that want's to clear the `ReservedSpace` will do it explicitly.

j) I've somewhat restructured the compressed heap space reservation code. The previous code used its instance variables to keep track of previous attempts and didn't release failed reservation memory until the next attempt to reserve memory. I've moved the code to release the memory to be explicit instead. The code that reserves memory is now responsible to check if the returned `ReservedSpace` is good enough to use. Instead of repeatedly changing the instance members of `ReservedHeapSpace`, I let the code keep track of a local `ReservedSpace` that contain the latest reservation attempt. When all memory reservation attempts are done a noaccess prefix is created if needed and a `ResevedHeapSpace` is created and returned.

I've tested this by running the full tier1-7

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2539001078

From cnorrbin at openjdk.org  Thu Dec 12 14:03:15 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 12 Dec 2024 14:03:15 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v4]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <i5cbiYl-dOrNeDkUJlV3cqa1NARCMgNFF1K5U0d5JTI=.00c2826d-0321-44b2-80d2-8f30a19a4c16@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  feedback fixes + moved functions to inline file

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/5bf6082a..6e67b5d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=02-03

  Stats: 954 lines in 3 files changed: 520 ins; 395 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From cnorrbin at openjdk.org  Thu Dec 12 14:22:44 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 12 Dec 2024 14:22:44 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v4]
In-Reply-To: <i5cbiYl-dOrNeDkUJlV3cqa1NARCMgNFF1K5U0d5JTI=.00c2826d-0321-44b2-80d2-8f30a19a4c16@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <i5cbiYl-dOrNeDkUJlV3cqa1NARCMgNFF1K5U0d5JTI=.00c2826d-0321-44b2-80d2-8f30a19a4c16@github.com>
Message-ID: <ILMGbYaV9EQ5rgbWozhKTP5msztMDYYQuwGj_qGIpp8=.09fd3091-d86d-4a46-a64e-d25882f4217e@github.com>

On Thu, 12 Dec 2024 14:03:15 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback fixes + moved functions to inline file

Thank you everyone for the comments!

I split the tree into `rbTree.hpp` and `rbTree.inline.hpp`, which is similar to how `concurrentHashTable` works. The original file is now much more readable, with some additional added comments to the public functions. All the internal functions is hidden away in the inline file.

I also added a check to `verify_self()` which ensures that the tree is balanced, i.e. the upper bound of $2log_2(n+1)$ is never exceeded, which should have been checked for previously. Thanks @afshin-zafari for pointing it out.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22360#issuecomment-2539087965

From coleenp at openjdk.org  Thu Dec 12 14:51:02 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 14:51:02 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v3]
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <b_hkazVsdRadA51RvK2rKb7VLslf9CHyVOD5T_-JGJ8=.6ffb6eb4-695c-438c-b18c-f9abe04b66b8@github.com>

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into modifiers
 - remove "jvm support"
 - 8345678: compute_modifiers should not be in create_mirror

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22618/files
  - new: https://git.openjdk.org/jdk/pull/22618/files/5d87b61a..a0792dff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=01-02

  Stats: 14988 lines in 2730 files changed: 7860 ins; 2341 del; 4787 mod
  Patch: https://git.openjdk.org/jdk/pull/22618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22618/head:pull/22618

PR: https://git.openjdk.org/jdk/pull/22618

From jiangli at openjdk.org  Thu Dec 12 16:17:45 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 12 Dec 2024 16:17:45 GMT
Subject: RFR: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
In-Reply-To: <TrjeYJFfcSo_DNUPzzCcKwtGniXX9EkKu9miECD3_Kg=.32bad3e4-90e2-4a31-902f-572b33325c8b@github.com>
References: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
 <JsgdgEAifDvsNFhrnFqD4ZdQeVJI-4IgFGpGEMQXwS0=.a47d3d24-8eab-4380-a100-418c397d06d6@github.com>
 <TrjeYJFfcSo_DNUPzzCcKwtGniXX9EkKu9miECD3_Kg=.32bad3e4-90e2-4a31-902f-572b33325c8b@github.com>
Message-ID: <rjBSdEkKN54Zp65OBQgi13nw315u5oKlXEXYrhT6We4=.c46a81ae-0df0-4f06-8f6a-882242a8fd0a@github.com>

On Wed, 11 Dec 2024 23:44:46 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This is likely fine. I must admit I am not aware of the differences between JVM_ENTRY_NO_ENV and JVM_LEAF, and just picked one that seemed reasonable to me given context and other usages.
>
> Thanks for the quick review, @magicus!
> 
> I didn't catch this details while reviewing https://github.com/openjdk/jdk/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5 either.

> @jianglizhou please remember the two reviewer rule for hotspot changes and the 24 hour rule for non-trivial changes. When Magnus admits to not knowing the significance of leaf versus non-leaf his one review hardly seems sufficient in any case.
> 
> The change to leaf is of course fine.

@dholmes-ora Thanks for the notes. I handled the change as trivial change. I will observe&follow the hotspot change rule more strictly moving forward.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22685#issuecomment-2539402256

From jsjolen at openjdk.org  Thu Dec 12 16:32:41 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 12 Dec 2024 16:32:41 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v4]
In-Reply-To: <i5cbiYl-dOrNeDkUJlV3cqa1NARCMgNFF1K5U0d5JTI=.00c2826d-0321-44b2-80d2-8f30a19a4c16@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <i5cbiYl-dOrNeDkUJlV3cqa1NARCMgNFF1K5U0d5JTI=.00c2826d-0321-44b2-80d2-8f30a19a4c16@github.com>
Message-ID: <NxJIt3-y69z6plstXbPWJmBT-ai-CDoNMN0OXAI1HD8=.21e2daf8-e598-4bda-abbe-827b3eb40fea@github.com>

On Thu, 12 Dec 2024 14:03:15 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   feedback fixes + moved functions to inline file

src/hotspot/share/utilities/rbTree.inline.hpp line 34:

> 32: // ----------------
> 33: // RBNode functions
> 34: // ----------------

No need for fancy comment

src/hotspot/share/utilities/rbTree.inline.hpp line 490:

> 488: // ------------------
> 489: // Iterator functions
> 490: // ------------------

No need for fancy comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1882485866
PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1882486463

From cnorrbin at openjdk.org  Thu Dec 12 16:42:17 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 12 Dec 2024 16:42:17 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v5]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <himFotak2VpDTbfvE694ozquoDEeyrFZveTNI9TaVy0=.7bf175cd-cf56-4740-9646-b2864eaa1700@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  removed some comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/6e67b5d3..f0a50a85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=03-04

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From cnorrbin at openjdk.org  Thu Dec 12 16:42:18 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Thu, 12 Dec 2024 16:42:18 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v4]
In-Reply-To: <NxJIt3-y69z6plstXbPWJmBT-ai-CDoNMN0OXAI1HD8=.21e2daf8-e598-4bda-abbe-827b3eb40fea@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <i5cbiYl-dOrNeDkUJlV3cqa1NARCMgNFF1K5U0d5JTI=.00c2826d-0321-44b2-80d2-8f30a19a4c16@github.com>
 <NxJIt3-y69z6plstXbPWJmBT-ai-CDoNMN0OXAI1HD8=.21e2daf8-e598-4bda-abbe-827b3eb40fea@github.com>
Message-ID: <mVR7MCRwICy0qY2w70hdvpme8J_I7kAKYSKw0bVAJY0=.d5c0f28f-189f-45ec-ad5b-2c9ba3f84106@github.com>

On Thu, 12 Dec 2024 16:29:48 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   feedback fixes + moved functions to inline file
>
> src/hotspot/share/utilities/rbTree.inline.hpp line 34:
> 
>> 32: // ----------------
>> 33: // RBNode functions
>> 34: // ----------------
> 
> No need for fancy comment

Removed them :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1882501160

From jsjolen at openjdk.org  Thu Dec 12 18:37:43 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 12 Dec 2024 18:37:43 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v5]
In-Reply-To: <himFotak2VpDTbfvE694ozquoDEeyrFZveTNI9TaVy0=.7bf175cd-cf56-4740-9646-b2864eaa1700@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
 <himFotak2VpDTbfvE694ozquoDEeyrFZveTNI9TaVy0=.7bf175cd-cf56-4740-9646-b2864eaa1700@github.com>
Message-ID: <xhVbvjRLEIRbWyaI9ZZ3vK7AtWrqEjRV13BYpCv4cX4=.2939bb5c-e3aa-4324-ae17-397a11cb1f13@github.com>

On Thu, 12 Dec 2024 16:42:17 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
>> 
>> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
>> 
>> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
>> 
>> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.
>
> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed some comments

src/hotspot/share/utilities/rbTree.hpp line 262:

> 260: private:
> 261:   template<bool Forward>
> 262:   class IteratorImpl : public StackObj {

Make it `NONCOPYABLE` as a safety measure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22360#discussion_r1882689118

From aph at openjdk.org  Thu Dec 12 18:52:09 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 12 Dec 2024 18:52:09 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <l1_kxwJTQc2Kt7WqmxEOD7oI6awLtRCHNprZ65TOMmA=.d0d6ddf5-ae87-461c-95b2-7fa6e58ab104@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

Perhaps I'm missing something here, but isn't the main problem immediate offsets that are not constant when HotSpot itself is compiled by a C++ compiler? Or is your intention to find all the uses of offsetted immediate that are non-constant?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2535455202

From duke at openjdk.org  Thu Dec 12 18:52:09 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 12 Dec 2024 18:52:09 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
Message-ID: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>

[JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)

Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

-------------

Commit messages:
 - Fix whitespace
 - Add compile time check for ldr/str

Changes: https://git.openjdk.org/jdk/pull/22623/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344880
  Stats: 345 lines in 24 files changed: 32 ins; 1 del; 312 mod
  Patch: https://git.openjdk.org/jdk/pull/22623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22623/head:pull/22623

PR: https://git.openjdk.org/jdk/pull/22623

From duke at openjdk.org  Thu Dec 12 18:52:09 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 12 Dec 2024 18:52:09 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

I think all immediate offsets should be safe (constant or non-constant) and this addresses the constants.

You're correct the non-constants are the main problem. As for those [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736) can be to go through remaining instructions and update. My opinion is that providing a temp register should be required for all non-constant in the event of an overflow. This will guarantee the size always gets checked. Compile when possible and runtime if not.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2539768611

From kbarrett at openjdk.org  Thu Dec 12 19:43:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 12 Dec 2024 19:43:39 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v6]
In-Reply-To: <HjI8QQqqL_jR0wU8LYF6RlqsASZD6IoKeEh7VlXr7-Y=.caec0436-4770-475e-95d8-6baa34bef6c1@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <HjI8QQqqL_jR0wU8LYF6RlqsASZD6IoKeEh7VlXr7-Y=.caec0436-4770-475e-95d8-6baa34bef6c1@github.com>
Message-ID: <fXtzKnvUnOmMB9lLe5BG0q-RhoQzm-dPGSaXP7D_NI4=.60dafe68-3cca-4668-b079-8afcba27f0cb@github.com>

On Wed, 11 Dec 2024 05:51:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
>> 
>> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
>> 
>> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
>> 
>> Testing:
>>  - tiers 1 - 4
>> 
>> Some frame management code was also moved from `VMError` to the `frame` class.
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22472#pullrequestreview-2500626123

From stuefe at openjdk.org  Thu Dec 12 19:54:43 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Dec 2024 19:54:43 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <tZYSTEcJTgBwpkZDwaTjGK1FEjujk1c8ZInrKF7GQ70=.9a3e8920-4a29-4875-a860-e85e82bcc2a6@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

Some drive-by comments. Using sizeof class is a smart workaround that is fine as long as we don't use `create_imm_offset`  to check offsets that are beyond sizeof its class. E.g. things like InstanceKlass::start_of_itable().

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 675:

> 673:   }
> 674: 
> 675:   #define create_imm_offset(klass, field_offset_func) \

I would avoid "klass" as name, since it is usually implied to mean an object of class `Klass`.

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 680:

> 678:     static_assert(Address::offset_ok_for_immed_compile_time<max_possible_offset, 0>(), "must fit in instruction"); \
> 679:     return klass::field_offset_func(); \
> 680:   }())

This could be done without a Lambda, which subjectively would be a bit simpler, by using the comma operator like this:


  template <class K> static void class_size_check() {
    constexpr size_t max_possible_offset = sizeof(K); \
    static_assert(Address::offset_ok_for_immed_compile_time<max_possible_offset, 0>(), "must fit in instruction"); \
  }
  #define create_imm_offset(klass, field_offset_func) \
    (Address::class_size_check<klass>(), klass::field_offset_func())

-------------

PR Review: https://git.openjdk.org/jdk/pull/22623#pullrequestreview-2500588169
PR Review Comment: https://git.openjdk.org/jdk/pull/22623#discussion_r1882758934
PR Review Comment: https://git.openjdk.org/jdk/pull/22623#discussion_r1882778201

From dholmes at openjdk.org  Thu Dec 12 20:44:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 20:44:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v3]
In-Reply-To: <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
Message-ID: <WhHwLyr5V_dFU4Vw2270rfXYLolud7ZzdDVnxzHEMpU=.4eb9c6b4-52a5-4e82-abd8-2fe3ad02bb54@github.com>

On Thu, 12 Dec 2024 12:41:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   infos -> info

Seems okay. Someone from serviceability should give their opinion on the content.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2500741205

From duke at openjdk.org  Thu Dec 12 21:45:36 2024
From: duke at openjdk.org (Larry Cable)
Date: Thu, 12 Dec 2024 21:45:36 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v3]
In-Reply-To: <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
Message-ID: <hbPhJk2jeL0OKKF6WdalXRx7BLc5QpUpgw--Q85vucg=.43238ade-3c14-4a5b-a232-a3931c54d987@github.com>

On Thu, 12 Dec 2024 12:41:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   infos -> info

I do not understand the use case that this additional information solves for, nor does the bug provide any further enlightenment, I think this ER requires more rationale to motivate its inclusion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2540071738

From coleenp at openjdk.org  Thu Dec 12 22:07:46 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 22:07:46 GMT
Subject: [jdk24] RFR: 8346040: Zero interpreter build on Linux Aarch64 is
 broken
Message-ID: <42PPtvsLqtHn2-_EvK4ZwWnHFST_RckF5z4pbYsKDPc=.d5dcb600-bbc9-4834-a2c0-ac220a5e29a9@github.com>

This is a clean backport to JDK 24.

-------------

Commit messages:
 - Backport ef6e987a006ef81fb0cc6c12a88ee954738ec5d0

Changes: https://git.openjdk.org/jdk/pull/22722/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22722&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346040
  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22722.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22722/head:pull/22722

PR: https://git.openjdk.org/jdk/pull/22722

From kbarrett at openjdk.org  Thu Dec 12 22:12:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 12 Dec 2024 22:12:35 GMT
Subject: [jdk24] RFR: 8346040: Zero interpreter build on Linux Aarch64 is
 broken
In-Reply-To: <42PPtvsLqtHn2-_EvK4ZwWnHFST_RckF5z4pbYsKDPc=.d5dcb600-bbc9-4834-a2c0-ac220a5e29a9@github.com>
References: <42PPtvsLqtHn2-_EvK4ZwWnHFST_RckF5z4pbYsKDPc=.d5dcb600-bbc9-4834-a2c0-ac220a5e29a9@github.com>
Message-ID: <ZKw-TdpjsG1D2WWhbOWYrs7mwkez9HW39Kj_kYzssCI=.78a5f588-c0da-43af-94d3-010059182445@github.com>

On Thu, 12 Dec 2024 22:02:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a clean backport to JDK 24.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22722#pullrequestreview-2500875722

From coleenp at openjdk.org  Thu Dec 12 22:27:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 22:27:38 GMT
Subject: [jdk24] RFR: 8346040: Zero interpreter build on Linux Aarch64 is
 broken
In-Reply-To: <42PPtvsLqtHn2-_EvK4ZwWnHFST_RckF5z4pbYsKDPc=.d5dcb600-bbc9-4834-a2c0-ac220a5e29a9@github.com>
References: <42PPtvsLqtHn2-_EvK4ZwWnHFST_RckF5z4pbYsKDPc=.d5dcb600-bbc9-4834-a2c0-ac220a5e29a9@github.com>
Message-ID: <UfU6VXBeKUyp0eVAXoKRzE1j3j0-mDwJ_f28YZpgC84=.da49de60-3650-4165-86d6-e96670a800a3@github.com>

On Thu, 12 Dec 2024 22:02:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a clean backport to JDK 24.

Thank you Kim for reviewing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22722#issuecomment-2540131772

From coleenp at openjdk.org  Thu Dec 12 22:27:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 12 Dec 2024 22:27:38 GMT
Subject: [jdk24] Integrated: 8346040: Zero interpreter build on Linux Aarch64
 is broken
In-Reply-To: <42PPtvsLqtHn2-_EvK4ZwWnHFST_RckF5z4pbYsKDPc=.d5dcb600-bbc9-4834-a2c0-ac220a5e29a9@github.com>
References: <42PPtvsLqtHn2-_EvK4ZwWnHFST_RckF5z4pbYsKDPc=.d5dcb600-bbc9-4834-a2c0-ac220a5e29a9@github.com>
Message-ID: <Zcv8eo1fbmuzR0xnfL75xNDk353mBues3-wEvjuSqKU=.866a4201-6dc6-4d30-9117-f3b4e27db66c@github.com>

On Thu, 12 Dec 2024 22:02:45 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a clean backport to JDK 24.

This pull request has now been integrated.

Changeset: 897a8abe
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/897a8abecc672b35d4c0b3a46785a413cbfe70cf
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8346040: Zero interpreter build on Linux Aarch64 is broken

Reviewed-by: kbarrett
Backport-of: ef6e987a006ef81fb0cc6c12a88ee954738ec5d0

-------------

PR: https://git.openjdk.org/jdk/pull/22722

From ihse at openjdk.org  Thu Dec 12 22:37:38 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Dec 2024 22:37:38 GMT
Subject: RFR: 8345959: Make JVM_IsStaticallyLinked JVM_LEAF
In-Reply-To: <rjBSdEkKN54Zp65OBQgi13nw315u5oKlXEXYrhT6We4=.c46a81ae-0df0-4f06-8f6a-882242a8fd0a@github.com>
References: <fvrSTShvvDNh8mSsKZmAaY6mD_NdHszVdgdvRBPvesk=.9b8cd8dc-5e3c-4f11-849a-50f02f9778cd@github.com>
 <JsgdgEAifDvsNFhrnFqD4ZdQeVJI-4IgFGpGEMQXwS0=.a47d3d24-8eab-4380-a100-418c397d06d6@github.com>
 <TrjeYJFfcSo_DNUPzzCcKwtGniXX9EkKu9miECD3_Kg=.32bad3e4-90e2-4a31-902f-572b33325c8b@github.com>
 <rjBSdEkKN54Zp65OBQgi13nw315u5oKlXEXYrhT6We4=.c46a81ae-0df0-4f06-8f6a-882242a8fd0a@github.com>
Message-ID: <AcX1fSPXMvOsvVHq7Cx5tPBdqihCvOzKx8Bo_gT7KfU=.0ae3e286-4f15-4c0f-b60c-0a4426e3a45b@github.com>

On Thu, 12 Dec 2024 16:14:31 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Thanks for the quick review, @magicus!
>> 
>> I didn't catch this details while reviewing https://github.com/openjdk/jdk/commit/a136a85b6f5bbc92727883693c1ce31c37a82fd5 either.
>
>> @jianglizhou please remember the two reviewer rule for hotspot changes and the 24 hour rule for non-trivial changes. When Magnus admits to not knowing the significance of leaf versus non-leaf his one review hardly seems sufficient in any case.
>> 
>> The change to leaf is of course fine.
> 
> @dholmes-ora Thanks for the notes. I handled the change as trivial change. I will observe&follow the hotspot change rule more strictly moving forward.

@jianglizhou For a change to be trivial, you need a reviewer to say so.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22685#issuecomment-2540145436

From dholmes at openjdk.org  Thu Dec 12 23:18:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 23:18:43 GMT
Subject: RFR: 8311542: Consolidate the native stack printing code [v6]
In-Reply-To: <fXtzKnvUnOmMB9lLe5BG0q-RhoQzm-dPGSaXP7D_NI4=.60dafe68-3cca-4668-b079-8afcba27f0cb@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
 <HjI8QQqqL_jR0wU8LYF6RlqsASZD6IoKeEh7VlXr7-Y=.caec0436-4770-475e-95d8-6baa34bef6c1@github.com>
 <fXtzKnvUnOmMB9lLe5BG0q-RhoQzm-dPGSaXP7D_NI4=.60dafe68-3cca-4668-b079-8afcba27f0cb@github.com>
Message-ID: <Jgqge9XhlrJYDiOa3yqjuEo2_cl3MGurOlnLYorLZr8=.3cb40a6f-bbbb-4ba1-ab8f-2021d3daa187@github.com>

On Thu, 12 Dec 2024 19:41:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indent
>
> Looks good.

Thanks @kimbarrett !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22472#issuecomment-2540196278

From dholmes at openjdk.org  Thu Dec 12 23:18:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 12 Dec 2024 23:18:44 GMT
Subject: Integrated: 8311542: Consolidate the native stack printing code
In-Reply-To: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
References: <UmBmXSHu7E5beg4BLKjMW9KWx7Nh6Ww81fmlFkxKfXg=.3d2e6251-f17f-43f2-b1f2-355c92f75212@github.com>
Message-ID: <US36AIxAxqlJfLSGPJRQAEHKdNNgWsAU01oG6JBqNoQ=.48767629-14c7-42f6-90ad-e3d534b15e8b@github.com>

On Mon, 2 Dec 2024 07:36:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> We now print native stacks in a number of contexts, not just VMError reporting, and we have to try `os::platform_print_native_stack` else fall back to `VMError::print_native stack`. 
> 
> The refactoring adds a new `NativeStackPrinter` (NSP) helper class which can be constructed with some of the context information for the printing that will follow. This avoids the need for the print functions to have a large number of parameters. We have to expose both the top-level printing functionality and the "lower-level" frame-based stack walk as the error reporter needs access to that directly. To maintain the exact same format of output the NSP has to be aware of some error reporter usage requirements.
> 
> I also had to expose a direct `frame` taking print function for the Debug.cpp `pns` case.
> 
> Testing:
>  - tiers 1 - 4
> 
> Some frame management code was also moved from `VMError` to the `frame` class.

This pull request has now been integrated.

Changeset: db9eab3f
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db9eab3f29e9cb26a8c0a7c31c55aaf140f21bed
Stats:     352 lines in 9 files changed: 234 ins; 96 del; 22 mod

8311542: Consolidate the native stack printing code

Reviewed-by: kbarrett, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/22472

From amenkov at openjdk.org  Thu Dec 12 23:36:37 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 12 Dec 2024 23:36:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information is hserr files [v3]
In-Reply-To: <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
Message-ID: <TLPWKQb93hgLMUpup_8UIOI57t9FWsLdwHhKMUQBLvQ=.fda44abd-a727-4943-9264-161e3a1ba693@github.com>

On Thu, 12 Dec 2024 12:41:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   infos -> info

src/hotspot/share/runtime/os.cpp line 1128:

> 1126: #if INCLUDE_JVMTI
> 1127:   // should return all kinds of JVMTI agents, but no xrun agents
> 1128:   const JvmtiAgentList::Iterator it =JvmtiAgentList::agents();

Suggestion:

  const JvmtiAgentList::Iterator it = JvmtiAgentList::agents();

src/hotspot/share/runtime/os.cpp line 1141:

> 1139:       const char* optionsinfo = agent->options();
> 1140:       const char* pathinfo = agent->os_lib_path();
> 1141:       if (agent->is_dynamic()) dyninfo = "dynamic";

maybe just initialize it as

      const char* dyninfo = agent->is_dynamic() ? "dynamic" : "";

(and the same for instrumentinfo/loadinfo/initinfo)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1883027329
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1883030064

From kbarrett at openjdk.org  Fri Dec 13 01:29:13 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 01:29:13 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v2]
In-Reply-To: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
Message-ID: <yayealnBQIb714t6VI3b-Rsqybnln2uXkdB_DIHM1Mc=.b073ef90-eabb-4388-b06e-c3549b0d22f7@github.com>

> Please review this change that introduces two new helper classes to simplify
> the usage of PartialArrayStates to manage splitting the processing of large
> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
> changed to use this new mechanism.
> 
> PartialArrayTaskStats is used to collect and report statistics related to
> array splitting.  It replaces the direct implementation in PSPromotionManager,
> and is now also used by G1 young GCs.
> 
> PartialArraySplitter packages up most of the work involved in splitting and
> processing tasks. It provides task allocation and release, enqueuing, chunk
> claiming, and statistics tracking. It does this by encapsulating existing
> objects and functionality. Using array splitting is mostly reduced to calling
> the splitter's start function and then calling it's step function to process
> partial states. This substantially reduces the amount of code for each client
> to perform this work.
> 
> Testing: mach5 tier1-5
> 
> Manually ran some test programs with each of G1 and Parallel, with taskqueue
> stats logging enabled, and checked that the logged statistics looked okay.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into pa-splitter
 - parallel uses PartialArraySplitter
 - g1 uses PartialArraySplitter
 - add PartialArraySplitter
 - add PartialArrayTaskStats

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22622/files
  - new: https://git.openjdk.org/jdk/pull/22622/files/7da8b4b0..b0ea3f51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22622&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22622&range=00-01

  Stats: 15644 lines in 2681 files changed: 8811 ins; 1996 del; 4837 mod
  Patch: https://git.openjdk.org/jdk/pull/22622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22622/head:pull/22622

PR: https://git.openjdk.org/jdk/pull/22622

From vaivanov at openjdk.org  Fri Dec 13 02:17:33 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 13 Dec 2024 02:17:33 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
Message-ID: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>

> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.

Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8341481
 - 8341481: [perf] vframeStreamCommon constructor may be optimized
 - 8341481 [Perf] vframeStreamCommon constructor may be optimized

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22173/files
  - new: https://git.openjdk.org/jdk/pull/22173/files/55466835..ba234c59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22173&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22173&range=00-01

  Stats: 530558 lines in 8910 files changed: 288054 ins; 192740 del; 49764 mod
  Patch: https://git.openjdk.org/jdk/pull/22173.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22173/head:pull/22173

PR: https://git.openjdk.org/jdk/pull/22173

From dholmes at openjdk.org  Fri Dec 13 02:37:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 13 Dec 2024 02:37:38 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v3]
In-Reply-To: <7hNUkirFaGdTEBv7DiTnTsPOsFLAiDDSrbD6JqQEePs=.dd37fa59-4401-4ea3-ae7c-f8a3a9ec238f@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <EJCkbTXhm71BcGaXl63Bkc3PzwoD3oL-TVF9TxdPBOc=.f120921c-722b-42f9-a84f-4fd9bb913ae4@github.com>
 <7hNUkirFaGdTEBv7DiTnTsPOsFLAiDDSrbD6JqQEePs=.dd37fa59-4401-4ea3-ae7c-f8a3a9ec238f@github.com>
Message-ID: <43e-elAJ2JPVymZtKm1-SmjMqj1WuOzs9kNyo3ifLas=.3ce75757-07b9-4b4e-8b66-64a342136746@github.com>

On Thu, 12 Dec 2024 13:43:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated additional tests
>
> src/hotspot/share/oops/instanceKlass.cpp line 234:
> 
>> 232:              "and sealed class %s is in module \"%s\" for loader %s",
>> 233:              k->external_name(), k->module()->name_as_C_string(), k->module()->loader_data()->loader_name_and_id(),
>> 234:              this->external_name(), this->module()->name_as_C_string(), this->module()->loader_data()->loader_name_and_id());
> 
> This looks quite good except that the word "for" in "for loader %s" looks a bit strange.  In API docs we speak of "the ClassLoader for a module", not the other way around. Class loaders optionally have a name so I suppose the "loader %s" should put quotes around the name like it does for the module name.

I will change to "with loader %s".

Note that `loader_name_and_id()` already puts (single) quotes around the name of the loader. I will use single-quotes for the module name too.

> src/hotspot/share/oops/instanceKlass.cpp line 240:
> 
>> 238: 
>> 239:   if (!k->is_public() && !is_same_class_package(k)) {
>> 240:     ss.print("Failed same run-time package check: non-public subclass %s is in package \"%s\" with classloader %s,"
> 
> Since the checking is past the same module check at this point then it might be simpler to say that it fails the same package check.

Ah I see what you are saying. As they are known to be in the same module then they are known to have the same loader. But "runtime package" is only significant for different loaders with the same package name - which can't be the case here. So it is simply not the same package. Will fix.

Thanks for looking at this @AlanBateman !

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1883162736
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1883164193

From kbarrett at openjdk.org  Fri Dec 13 03:40:06 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 03:40:06 GMT
Subject: RFR: 8345505: Fix -Wzero-as-null-pointer-constant warnings in zero
 code
Message-ID: <rszeVeAYs3v8j66Ds1V-UQ2narcwndTq8c1r3Os0lAs=.febd9fd6-8656-4fdf-a639-2134a9472080@github.com>

Please review this trivial change to remove some -Wzero-as-null-pointer-constant
warnings in zero code.  Just replaced two literal 0's with nullptr.

Testing: mach5 tier1, GHA sanity tests

-------------

Commit messages:
 - fix warnings in zero

Changes: https://git.openjdk.org/jdk/pull/22728/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22728&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345505
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22728.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22728/head:pull/22728

PR: https://git.openjdk.org/jdk/pull/22728

From dholmes at openjdk.org  Fri Dec 13 04:22:20 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 13 Dec 2024 04:22:20 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
Message-ID: <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>

> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
> 
> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
> 
> as inspection of the class sources will show the expected `permits` and `extends` clauses.
> 
> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
> 
> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
> 
> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
> 
> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
> 
> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the quer
 ies - but we could do it for conveni...

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Update messages per feedback from Alan

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22703/files
  - new: https://git.openjdk.org/jdk/pull/22703/files/87c21f5e..9f3c618d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=02-03

  Stats: 27 lines in 6 files changed: 0 ins; 0 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/22703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22703/head:pull/22703

PR: https://git.openjdk.org/jdk/pull/22703

From dholmes at openjdk.org  Fri Dec 13 04:35:54 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 13 Dec 2024 04:35:54 GMT
Subject: RFR: 8345505: Fix -Wzero-as-null-pointer-constant warnings in zero
 code
In-Reply-To: <rszeVeAYs3v8j66Ds1V-UQ2narcwndTq8c1r3Os0lAs=.febd9fd6-8656-4fdf-a639-2134a9472080@github.com>
References: <rszeVeAYs3v8j66Ds1V-UQ2narcwndTq8c1r3Os0lAs=.febd9fd6-8656-4fdf-a639-2134a9472080@github.com>
Message-ID: <0sNxTNNQ63oP2U8EhBaE9xkBGpzeKIGRT3akYsTpP8I=.00fd7efb-a9a9-49e3-8030-a9f6cc996d4a@github.com>

On Fri, 13 Dec 2024 03:35:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove some -Wzero-as-null-pointer-constant
> warnings in zero code.  Just replaced two literal 0's with nullptr.
> 
> Testing: mach5 tier1, GHA sanity tests

Looks good and trivial.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22728#pullrequestreview-2501274483

From kbarrett at openjdk.org  Fri Dec 13 04:51:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 04:51:38 GMT
Subject: RFR: 8345505: Fix -Wzero-as-null-pointer-constant warnings in zero
 code
In-Reply-To: <0sNxTNNQ63oP2U8EhBaE9xkBGpzeKIGRT3akYsTpP8I=.00fd7efb-a9a9-49e3-8030-a9f6cc996d4a@github.com>
References: <rszeVeAYs3v8j66Ds1V-UQ2narcwndTq8c1r3Os0lAs=.febd9fd6-8656-4fdf-a639-2134a9472080@github.com>
 <0sNxTNNQ63oP2U8EhBaE9xkBGpzeKIGRT3akYsTpP8I=.00fd7efb-a9a9-49e3-8030-a9f6cc996d4a@github.com>
Message-ID: <Lm_r8HF3eMhNVMS-lD-WxzowCwH1gJJ2VDYJ2Jjl5nM=.26a66582-db84-43a9-a961-b8d2f961517e@github.com>

On Fri, 13 Dec 2024 04:33:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this trivial change to remove some -Wzero-as-null-pointer-constant
>> warnings in zero code.  Just replaced two literal 0's with nullptr.
>> 
>> Testing: mach5 tier1, GHA sanity tests
>
> Looks good and trivial.
> 
> Thanks

Thanks for the review @dholmes-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22728#issuecomment-2540545454

From kbarrett at openjdk.org  Fri Dec 13 04:51:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 04:51:39 GMT
Subject: Integrated: 8345505: Fix -Wzero-as-null-pointer-constant warnings in
 zero code
In-Reply-To: <rszeVeAYs3v8j66Ds1V-UQ2narcwndTq8c1r3Os0lAs=.febd9fd6-8656-4fdf-a639-2134a9472080@github.com>
References: <rszeVeAYs3v8j66Ds1V-UQ2narcwndTq8c1r3Os0lAs=.febd9fd6-8656-4fdf-a639-2134a9472080@github.com>
Message-ID: <LpIDG0PTI1GhSfKKwnvRCZTa1218UHyf4DE1u5BJLWo=.41d7dd95-e180-478d-8c30-20993a300800@github.com>

On Fri, 13 Dec 2024 03:35:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial change to remove some -Wzero-as-null-pointer-constant
> warnings in zero code.  Just replaced two literal 0's with nullptr.
> 
> Testing: mach5 tier1, GHA sanity tests

This pull request has now been integrated.

Changeset: 28e49e97
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28e49e978a40f3fdff08c5e309cea739ecc870dc
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8345505: Fix -Wzero-as-null-pointer-constant warnings in zero code

Reviewed-by: dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22728

From fyang at openjdk.org  Fri Dec 13 07:03:39 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 13 Dec 2024 07:03:39 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v5]
In-Reply-To: <0lNEWMLaI7okBDC99caEXqqGTqwUVa-oYEv448jU6R0=.e509bb6e-d317-4957-a143-59f35bd930b6@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <0lNEWMLaI7okBDC99caEXqqGTqwUVa-oYEv448jU6R0=.e509bb6e-d317-4957-a143-59f35bd930b6@github.com>
Message-ID: <KTzqvYHXdDg308IK0VAOTybMlX7llidD23LQ71G5DT4=.c2fb1eab-a657-4ffa-95d2-bf183e59c8be@github.com>

On Thu, 12 Dec 2024 13:42:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8345322
>  - Fixed tests for uint32 and added edges cases
>  - Inclusive case
>  - Reviews comments, added uint32
>  - Code share
>  - Overflow
>  - Merge branch 'master' into 8345322
>  - Concurrent

Changes requested by fyang (Reviewer).

test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 201:

> 199: static void run_plain_cmpxchg_tests() {
> 200:   TESTSIZE max = std::numeric_limits<TESTSIZE>::max();
> 201:   TESTSIZE min = std::numeric_limits<TESTSIZE>::max();

Should this be: `TESTSIZE min = std::numeric_limits<TESTSIZE>::min();`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22574#pullrequestreview-2501281580
PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1883278336

From rehn at openjdk.org  Fri Dec 13 08:05:14 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 13 Dec 2024 08:05:14 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v6]
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <WYzkJld_ZB-n0_eGkgvUmm9eFHmiwI4vFcjmF6VRWnA=.96e31d4f-6450-4602-b8ae-2e14fb4bdc63@github.com>

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Fixed max->min
 - Merge branch 'master' into 8345322
 - Merge branch 'master' into 8345322
 - Fixed tests for uint32 and added edges cases
 - Inclusive case
 - Reviews comments, added uint32
 - Code share
 - Overflow
 - Merge branch 'master' into 8345322
 - Concurrent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22574/files
  - new: https://git.openjdk.org/jdk/pull/22574/files/5b91eead..9c06591f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22574&range=04-05

  Stats: 1485 lines in 57 files changed: 1031 ins; 266 del; 188 mod
  Patch: https://git.openjdk.org/jdk/pull/22574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22574/head:pull/22574

PR: https://git.openjdk.org/jdk/pull/22574

From rehn at openjdk.org  Fri Dec 13 08:05:14 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 13 Dec 2024 08:05:14 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v6]
In-Reply-To: <KTzqvYHXdDg308IK0VAOTybMlX7llidD23LQ71G5DT4=.c2fb1eab-a657-4ffa-95d2-bf183e59c8be@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <0lNEWMLaI7okBDC99caEXqqGTqwUVa-oYEv448jU6R0=.e509bb6e-d317-4957-a143-59f35bd930b6@github.com>
 <KTzqvYHXdDg308IK0VAOTybMlX7llidD23LQ71G5DT4=.c2fb1eab-a657-4ffa-95d2-bf183e59c8be@github.com>
Message-ID: <3UDy4xIBVPQ_rFl3VdPLWq4r8fzK9WJU_jTOPYASBF8=.90d00e6b-4660-4880-bcaf-4a6933ae4061@github.com>

On Fri, 13 Dec 2024 04:36:39 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Fixed max->min
>>  - Merge branch 'master' into 8345322
>>  - Merge branch 'master' into 8345322
>>  - Fixed tests for uint32 and added edges cases
>>  - Inclusive case
>>  - Reviews comments, added uint32
>>  - Code share
>>  - Overflow
>>  - Merge branch 'master' into 8345322
>>  - Concurrent
>
> test/hotspot/gtest/riscv/test_assembler_riscv.cpp line 201:
> 
>> 199: static void run_plain_cmpxchg_tests() {
>> 200:   TESTSIZE max = std::numeric_limits<TESTSIZE>::max();
>> 201:   TESTSIZE min = std::numeric_limits<TESTSIZE>::max();
> 
> Should this be: `TESTSIZE min = std::numeric_limits<TESTSIZE>::min();`?

Yes! Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22574#discussion_r1883516378

From mbaesken at openjdk.org  Fri Dec 13 08:37:36 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 08:37:36 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v3]
In-Reply-To: <hbPhJk2jeL0OKKF6WdalXRx7BLc5QpUpgw--Q85vucg=.43238ade-3c14-4a5b-a232-a3931c54d987@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <nWIf8VR697ulNC6M1NxRUSQWsDAYtnoIZeDpNdWsZ0s=.73ed6eff-1d73-4773-a5a8-c33fa1792a8d@github.com>
 <hbPhJk2jeL0OKKF6WdalXRx7BLc5QpUpgw--Q85vucg=.43238ade-3c14-4a5b-a232-a3931c54d987@github.com>
Message-ID: <N4TJrgjUK4Ry0RNCdLq7Epjyu3Am43VJ3IaU2NTLtCA=.c2d2ef67-12d3-44b8-a213-2ad756f9c8b2@github.com>

On Thu, 12 Dec 2024 21:43:12 GMT, Larry Cable <duke at openjdk.org> wrote:

> I do not understand the use case that this additional information solves for, nor does the bug provide any further enlightenment, I think this ER requires more rationale to motivate its inclusion.

Currently the info about the JVMTI agents in the hserr/hsinfo is not good. You might see them in the so/dll list any maybe command-line output but this is far from ideal.  A little separate section gives more clarity.
Bad JVMTI agents (and even good ones) can influence what is going on at runtime so that info should be present.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2540873155

From tschatzl at openjdk.org  Fri Dec 13 08:53:38 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Dec 2024 08:53:38 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v2]
In-Reply-To: <yayealnBQIb714t6VI3b-Rsqybnln2uXkdB_DIHM1Mc=.b073ef90-eabb-4388-b06e-c3549b0d22f7@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <yayealnBQIb714t6VI3b-Rsqybnln2uXkdB_DIHM1Mc=.b073ef90-eabb-4388-b06e-c3549b0d22f7@github.com>
Message-ID: <xK6_IgxPgz8ob0HnV4P6-mlB0jImP3jZNASMMlbqZSk=.9795658e-234d-45a0-b644-4d55001228a3@github.com>

On Fri, 13 Dec 2024 01:29:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - parallel uses PartialArraySplitter
>  - g1 uses PartialArraySplitter
>  - add PartialArraySplitter
>  - add PartialArrayTaskStats

Apart from these comments not being in the right place, seems good.

src/hotspot/share/gc/shared/partialArraySplitter.inline.hpp line 45:

> 43:   PartialArrayTaskStepper::Step step = _stepper.start(length);
> 44:   // Push any needed partial scan tasks.  Pushed before processing the initial
> 45:   // chunk to allow other workers to steal while we're processing.

This comment (last two lines) now imo better belongs to where this method is called. Same with similar comment in `step()`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22622#pullrequestreview-2501736071
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1883567632

From iwalulya at openjdk.org  Fri Dec 13 09:35:38 2024
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 13 Dec 2024 09:35:38 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v2]
In-Reply-To: <yayealnBQIb714t6VI3b-Rsqybnln2uXkdB_DIHM1Mc=.b073ef90-eabb-4388-b06e-c3549b0d22f7@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <yayealnBQIb714t6VI3b-Rsqybnln2uXkdB_DIHM1Mc=.b073ef90-eabb-4388-b06e-c3549b0d22f7@github.com>
Message-ID: <nOS654TAftz8wrWlq4ncdGtbuUV-0iBm05fWSm6Yp50=.86e3db6c-c4e6-49da-b715-dee771b46dd7@github.com>

On Fri, 13 Dec 2024 01:29:13 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - parallel uses PartialArraySplitter
>  - g1 uses PartialArraySplitter
>  - add PartialArraySplitter
>  - add PartialArrayTaskStats

LGTM!

Minor nit:

src/hotspot/share/gc/shared/partialArraySplitter.inline.hpp line 62:

> 60: template<typename Queue>
> 61: PartialArraySplitter::Step
> 62: PartialArraySplitter::step(PartialArrayState* state, Queue* queue, bool stolen) {

Probably easier to read if we rename to `claim`,  step is used as noun in many other places

-------------

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22622#pullrequestreview-2501832505
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1883630926

From cnorrbin at openjdk.org  Fri Dec 13 09:38:14 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Fri, 13 Dec 2024 09:38:14 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v6]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <Zyb5qCwTF4r1G2Ykts9Yvtg81AJZkcDWN6PdynT14D8=.102c30d5-2227-47e1-a8e0-540411685f30@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  made iterator non-copyable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/f0a50a85..3705c1ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=04-05

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From fyang at openjdk.org  Fri Dec 13 10:09:16 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 13 Dec 2024 10:09:16 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v5]
In-Reply-To: <0lNEWMLaI7okBDC99caEXqqGTqwUVa-oYEv448jU6R0=.e509bb6e-d317-4957-a143-59f35bd930b6@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <0lNEWMLaI7okBDC99caEXqqGTqwUVa-oYEv448jU6R0=.e509bb6e-d317-4957-a143-59f35bd930b6@github.com>
Message-ID: <GL_129Gt3w0jWp2bWO2KpUfKq0DI6n57J4nOEB_Sfn8=.f14212ad-0328-4b27-bffc-3f70d1fbe5af@github.com>

On Thu, 12 Dec 2024 13:42:29 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into 8345322
>  - Fixed tests for uint32 and added edges cases
>  - Inclusive case
>  - Reviews comments, added uint32
>  - Code share
>  - Overflow
>  - Merge branch 'master' into 8345322
>  - Concurrent

Still good. It is passing on my P550 SBC.

-------------

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22574#pullrequestreview-2501910950

From azafari at openjdk.org  Fri Dec 13 10:15:05 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 13 Dec 2024 10:15:05 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v11]
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <kyLg6OuxA4kESqijeQ-s2KwYPZtU3oEp2-3ubMSftKc=.feb1c28c-4dce-4369-a825-a36afdabcb61@github.com>

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  visit committed regions refined.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20425/files
  - new: https://git.openjdk.org/jdk/pull/20425/files/316d9a11..7b0c427b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=09-10

  Stats: 11 lines in 1 file changed: 0 ins; 7 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

PR: https://git.openjdk.org/jdk/pull/20425

From rehn at openjdk.org  Fri Dec 13 10:17:36 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 13 Dec 2024 10:17:36 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v5]
In-Reply-To: <GL_129Gt3w0jWp2bWO2KpUfKq0DI6n57J4nOEB_Sfn8=.f14212ad-0328-4b27-bffc-3f70d1fbe5af@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <0lNEWMLaI7okBDC99caEXqqGTqwUVa-oYEv448jU6R0=.e509bb6e-d317-4957-a143-59f35bd930b6@github.com>
 <GL_129Gt3w0jWp2bWO2KpUfKq0DI6n57J4nOEB_Sfn8=.f14212ad-0328-4b27-bffc-3f70d1fbe5af@github.com>
Message-ID: <eyE3HjKWZB9b2eJqZU4RrTxVl0HMRUuCtHtBb6M6lL4=.7f07097f-911e-44ba-a125-1e3209e58c37@github.com>

On Fri, 13 Dec 2024 10:05:38 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Still good. It is passing on my P550 SBC.

Great thanks!

@Hamlin-Li still happy about this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22574#issuecomment-2541087858

From aph at openjdk.org  Fri Dec 13 10:27:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 13 Dec 2024 10:27:39 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
 <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
Message-ID: <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>

On Thu, 12 Dec 2024 18:47:53 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> I think all immediate offsets should be safe (constant or non-constant) and this addresses the constants.

We should not do this. In the overwhelming majority of cases a maintainer does not (and should not have to) care whether an address will fit in an immediate or not. It is purely an encoding issue, not a semantic one, and should be handled internally by the assembler.

If instead of this PR we were to use some variant of `form_address()` on register+offset addresses, we wouldn't need to care about whether the offsets were compile-time constants or not, we wouldn't need this extra code, and  the result would be easier to read and maintain.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2541107157

From aph at openjdk.org  Fri Dec 13 12:06:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 13 Dec 2024 12:06:40 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
 <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
 <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
Message-ID: <sxk7vgsL2MGEuZdkGiCEDuzDbI1PlIva1AyfKgDY8yo=.1cd85be4-482d-407b-9a64-72dcae32352a@github.com>

On Fri, 13 Dec 2024 10:24:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> If instead of this PR we were to use some variant of `form_address()` on register+offset addresses, we wouldn't need to care about whether the offsets were compile-time constants or not, we wouldn't need this extra code, and the result would be easier to read and maintain.

e.g. a new `Address` constructor that takes an extra register and (optionally) an operand size.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2541299635

From mbaesken at openjdk.org  Fri Dec 13 12:18:13 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 12:18:13 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  simplify coding

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/fa422ce3..fa960c86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=02-03

  Stats: 9 lines in 1 file changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22706/head:pull/22706

PR: https://git.openjdk.org/jdk/pull/22706

From jsjolen at openjdk.org  Fri Dec 13 12:50:37 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 13 Dec 2024 12:50:37 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>

On Thu, 12 Dec 2024 13:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

src/hotspot/share/memory/memoryReserver.cpp line 238:

> 236: }
> 237: 
> 238: bool MemoryReserver::release(const ReservedSpace& reserved) {

Should `release(release(R)) == release(R)` and should `release(R& r)` do `r = {}`? Then `release({})` is no-op.

In other words, instead of this:

```c++
if (rs.is_reserved()) {
  MemoryReserver::release(rs);
  rs = {};
}


we can have

```c++
MemoryReserver::release(rs);


which to me seems like a good simplification when using the API.

src/hotspot/share/memory/reservedSpace.hpp line 137:

> 135: };
> 136: 
> 137: // Class encapsulating behavior specific of memory space reserved for Java heap.

"of the", "for the"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883745379
PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883865400

From jsjolen at openjdk.org  Fri Dec 13 12:50:37 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 13 Dec 2024 12:50:37 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
Message-ID: <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>

On Fri, 13 Dec 2024 10:51:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> src/hotspot/share/memory/memoryReserver.cpp line 238:
> 
>> 236: }
>> 237: 
>> 238: bool MemoryReserver::release(const ReservedSpace& reserved) {
> 
> Should `release(release(R)) == release(R)` and should `release(R& r)` do `r = {}`? Then `release({})` is no-op.
> 
> In other words, instead of this:
> 
> ```c++
> if (rs.is_reserved()) {
>   MemoryReserver::release(rs);
>   rs = {};
> }
> 
> 
> we can have
> 
> ```c++
> MemoryReserver::release(rs);
> 
> 
> which to me seems like a good simplification when using the API.

It seems like you've explicitly decided against this in the new API, is there a particular reason for that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883886748

From alanb at openjdk.org  Fri Dec 13 12:55:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Dec 2024 12:55:39 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v3]
In-Reply-To: <43e-elAJ2JPVymZtKm1-SmjMqj1WuOzs9kNyo3ifLas=.3ce75757-07b9-4b4e-8b66-64a342136746@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <EJCkbTXhm71BcGaXl63Bkc3PzwoD3oL-TVF9TxdPBOc=.f120921c-722b-42f9-a84f-4fd9bb913ae4@github.com>
 <7hNUkirFaGdTEBv7DiTnTsPOsFLAiDDSrbD6JqQEePs=.dd37fa59-4401-4ea3-ae7c-f8a3a9ec238f@github.com>
 <43e-elAJ2JPVymZtKm1-SmjMqj1WuOzs9kNyo3ifLas=.3ce75757-07b9-4b4e-8b66-64a342136746@github.com>
Message-ID: <UE30hnQU-B70W31pEblldK0JajDYKp4Qr2jw-C0Pmxk=.f938a0f4-f5e7-4e06-ab8c-9db49633cecc@github.com>

On Fri, 13 Dec 2024 02:32:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 234:
>> 
>>> 232:              "and sealed class %s is in module \"%s\" for loader %s",
>>> 233:              k->external_name(), k->module()->name_as_C_string(), k->module()->loader_data()->loader_name_and_id(),
>>> 234:              this->external_name(), this->module()->name_as_C_string(), this->module()->loader_data()->loader_name_and_id());
>> 
>> This looks quite good except that the word "for" in "for loader %s" looks a bit strange.  In API docs we speak of "the ClassLoader for a module", not the other way around. Class loaders optionally have a name so I suppose the "loader %s" should put quotes around the name like it does for the module name.
>
> I will change to "with loader %s".
> 
> Note that `loader_name_and_id()` already puts (single) quotes around the name of the loader. I will use single-quotes for the module name too.

This looks good, I hadn't spotted that loader_name_and_id() returns the quotes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1883875589

From alanb at openjdk.org  Fri Dec 13 12:55:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Dec 2024 12:55:41 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
Message-ID: <x9JKnTjoSODICfjpURAGaaFmDwJY3P7QZ_7N8CD2rCs=.f82850ad-2128-4b75-838e-83bfbfd07a81@github.com>

On Fri, 13 Dec 2024 04:22:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
>> 
>> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
>> 
>> as inspection of the class sources will show the expected `permits` and `extends` clauses.
>> 
>> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
>> 
>> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
>> 
>> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
>> 
>> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
>> 
>> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the que
 ries - ...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update messages per feedback from Alan

src/hotspot/share/oops/instanceKlass.cpp line 246:

> 244:              this->external_name(), this->package() != nullptr ? this->package()->name()->as_C_string() : "unnamed",
> 245:              this->module()->loader_data()->loader_name_and_id());
> 246:     log_trace(class, sealed)(" - %s", ss.as_string());

I'm a bit puzzled by the check so I'm not commenting on the log/exception message just yet.

If the super class (this) is in an unnamed module then the permitted subclass (k) must be in the same package.

If the super class is in a named module then permitted subclass can be in a different package but both need to be public in order.

I'm just trying to see how this maps to the check because it doesn't appear to take named vs. unnamed module into account, e.g. the subclass k might be public but in a different package of the same unnamed module. It's possible that I've mis-read this but it to goes to what the exception message is for these cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1883895233

From stefank at openjdk.org  Fri Dec 13 13:13:36 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Dec 2024 13:13:36 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
 <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
Message-ID: <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>

On Fri, 13 Dec 2024 12:45:28 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/memory/memoryReserver.cpp line 238:
>> 
>>> 236: }
>>> 237: 
>>> 238: bool MemoryReserver::release(const ReservedSpace& reserved) {
>> 
>> Should `release(release(R)) == release(R)` and should `release(R& r)` do `r = {}`? Then `release({})` is no-op.
>> 
>> In other words, instead of this:
>> 
>> ```c++
>> if (rs.is_reserved()) {
>>   MemoryReserver::release(rs);
>>   rs = {};
>> }
>> 
>> 
>> we can have
>> 
>> ```c++
>> MemoryReserver::release(rs);
>> 
>> 
>> which to me seems like a good simplification when using the API.
>
> It seems like you've explicitly decided against this in the new API, is there a particular reason for that?

My reasoning was that MemoryReserver does not have the ownership of the ReservedSpace instance, so I didn't want it to be the one clearing the members. If others feel the same way as you do, then I would prefer to add a function release_and_clear to make it clearer (:)) what's going on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883916256

From stefank at openjdk.org  Fri Dec 13 13:23:14 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Dec 2024 13:23:14 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'upstream/master' into reserved_space_rewrite
 - Fix comment
 - 8345655: Move reservation code out of ReservedSpace

-------------

Changes: https://git.openjdk.org/jdk/pull/22712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22712&range=01
  Stats: 2107 lines in 59 files changed: 1182 ins; 806 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/22712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22712/head:pull/22712

PR: https://git.openjdk.org/jdk/pull/22712

From jsjolen at openjdk.org  Fri Dec 13 13:38:40 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 13 Dec 2024 13:38:40 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
 <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
 <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>
Message-ID: <0DIQXJDLaUvtZOhwOROXFP4YPhDIfTEJZ1v7ib-_6_s=.3c84c791-d338-4e18-a4ba-a7f0a2b984e2@github.com>

On Fri, 13 Dec 2024 13:10:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> It seems like you've explicitly decided against this in the new API, is there a particular reason for that?
>
> My reasoning was that MemoryReserver does not have the ownership of the ReservedSpace instance, so I didn't want it to be the one clearing the members. If others feel the same way as you do, then I would prefer to add a function release_and_clear to make it clearer (:)) what's going on.

`release_and_clear`does sound clearer :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883947587

From mdoerr at openjdk.org  Fri Dec 13 14:57:39 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Dec 2024 14:57:39 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <fm74HN47N2DVPU-gGlXJLaaX_MpZDj0dCJOf5HDmrJY=.15884507-b2ff-4a1c-89bb-9a78edfd8855@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

Nice enhancement! Could you add an example output to the description, please?

src/hotspot/share/runtime/os.cpp line 1144:

> 1142:       if (pathinfo == nullptr) pathinfo = "none";
> 1143:       // jplis output too?
> 1144:       st->print_cr("%s path:%s, %s, %s %s %s options:%s", agent->name(), pathinfo, loadinfo, initinfo, dyninfo, instrumentinfo, optionsinfo);

I think the spaces can be improved by removing them between the "%s"s and added them to the Strings above.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2502484830
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1884056284

From aph at openjdk.org  Fri Dec 13 15:32:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 13 Dec 2024 15:32:39 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <ZJKxX1cjMX7aZTne9bSNOHNDgn93wGdUHtOze18VSLs=.ee4d5fa7-605f-4311-af3f-4aaf7bc27fde@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

We could instead add a few static_asserts that the size of a native structure which is accessed by the runtime code (there are not many of these, and we know what they are) is less than an `ldr`/`str` will reach. It's a simple-enough thing to do, and such a change has a much smaller blast radius than this PR would have.
It really would be useful to make sure we can generate correct code for variable-sized field offsets, as is the case for Java statics at some offset from the Klass base. C2 is already fine, C1 might need a few more calls to `form_address()`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2541704444

From stuefe at openjdk.org  Fri Dec 13 15:40:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 13 Dec 2024 15:40:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <mSjWLLsXo-jg442n7pnlh3VTeaCAPTWqEcNVAtvqXzs=.985396b3-415d-400d-a532-70ce2e5beccf@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

Looks fine, two bikeshedding nits.

I approve now, up to you if you take my suggestions.

src/hotspot/share/runtime/os.cpp line 1133:

> 1131:     const JvmtiAgent* agent = it.next();
> 1132:     if (agent != nullptr) {
> 1133:       if (first_agent) st->print_cr("JVMTI agents:");

if no agents are loaded, I would print "JVMTI agents: none" unconditionally. Makes it more obvious than just a missing entry; that could be also an error.

src/hotspot/share/runtime/os.cpp line 1138:

> 1136:       const char* instrumentinfo = agent->is_instrument_lib() ? "instrumentlib" : "";
> 1137:       const char* loadinfo = agent->is_loaded() ? "loaded" : "not loaded";
> 1138:       const char* initinfo = agent->is_initialized() ? "initialized" : "not initialized";

I would just print these as flags, its clearer and simpler to print. E.g.

"myagent path:  mylib.so dynamic:1 loaded:1 instrument_lib:0 initialized:1 xxx options xxx"

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2502573370
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1884116576
PR Review Comment: https://git.openjdk.org/jdk/pull/22706#discussion_r1884113414

From mbaesken at openjdk.org  Fri Dec 13 15:54:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 15:54:41 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <fm74HN47N2DVPU-gGlXJLaaX_MpZDj0dCJOf5HDmrJY=.15884507-b2ff-4a1c-89bb-9a78edfd8855@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
 <fm74HN47N2DVPU-gGlXJLaaX_MpZDj0dCJOf5HDmrJY=.15884507-b2ff-4a1c-89bb-9a78edfd8855@github.com>
Message-ID: <ITylSpVnpF0aasfmCu0CdC2dkbVZRAYMFKvZ6TjXnEo=.624504e0-83c5-4eb2-83e6-dfd3f76b8621@github.com>

On Fri, 13 Dec 2024 14:54:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Nice enhancement! Could you add an example output to the description, please?

Currently it looks like this


JVMTI agents:
asyncProfiler path:none, loaded, initialized   options:start,flat=10000,interval=50us,traces=1,event=wall,loglevel=none


(example is from a JVM started with async-profiler   :  `images/jdk/bin/java -agentlib:asyncProfiler=start,flat=10000,interval=50us,traces=1,event=wall,loglevel=none   ....`  )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2541746148

From mbaesken at openjdk.org  Fri Dec 13 16:00:37 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 13 Dec 2024 16:00:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <aPDmyKTsRWH5rz_PlQ3x3WLcpsiEVoTqLGVUEQ7x4vk=.8472c6f9-7a2f-4d6e-9a79-4e51ec704777@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

>if no agents are loaded, I would print "JVMTI agents: none" unconditionally. Makes it more obvious than just a missing entry; >that could be also an error.

Maybe after the while loop something like this ?


  bool first_agent = true;
  while (it.has_next()) {
      ...
  }
  **if (first_agent) st->print_cr("JVMTI agents: none");**

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2541756666

From kbarrett at openjdk.org  Fri Dec 13 17:27:44 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 17:27:44 GMT
Subject: RFR: 8346160: Fix -Wzero-as-null-pointer-constant warnings from
 explicit casts
Message-ID: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>

Please review this change that removes -Wzero-as-null-pointer-constant
warnings from explicit casts of a literal 0 to a pointer type.  Different
versions of gcc seem to warn about different cases changed here, but all of
these showed up as a warning in some testing, whether Oracle CI, GHA sanity
tests, or local cross-builds using Oracle's devkits for that.

Some of the changes simply replace a cast of 0 with nullptr.

The UNIX_PATH_MAX macro definitions in attachListener_{aix,posix}.cpp is
changed to use a C++11 feature for obtaining the size of a non-static data
member without requiring an instance.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html
I guess I need to propose an update to the style guide to mention this feature.

In CompressedKlassPointers::initialize, casting
CompressedClassSpaceBaseAddress to a pointer type was triggering the warning
in release builds for some reason. That's not a literal 0, even though it *is*
a constant 0 in a release build. Changed to avoid that cast rather than trying
to argue with some versions of the compiler.

Although different gcc versions on different platforms seemed to vary whether
warning about each of these, this actually seems to be all of the explict
casts of a literal 0 to a pointer in HotSpot.  Though because of the varied
behaviors, new ones might slip in later.

Testing: mach5 tier1, GHA sanity tests, both with and without the warning enabled.

-------------

Commit messages:
 - fix some casts of literal 0

Changes: https://git.openjdk.org/jdk/pull/22740/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22740&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346160
  Stats: 6 lines in 5 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22740.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22740/head:pull/22740

PR: https://git.openjdk.org/jdk/pull/22740

From stefank at openjdk.org  Fri Dec 13 17:41:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Dec 2024 17:41:49 GMT
Subject: RFR: 8346160: Fix -Wzero-as-null-pointer-constant warnings from
 explicit casts
In-Reply-To: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>
References: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>
Message-ID: <STI7ifvhkEzUPtCOQGDxF1RiU0HXdKYGGNsh2kMc6Xw=.ca963299-aa57-48db-bfa6-f9f68769ca3a@github.com>

On Fri, 13 Dec 2024 17:23:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that removes -Wzero-as-null-pointer-constant
> warnings from explicit casts of a literal 0 to a pointer type.  Different
> versions of gcc seem to warn about different cases changed here, but all of
> these showed up as a warning in some testing, whether Oracle CI, GHA sanity
> tests, or local cross-builds using Oracle's devkits for that.
> 
> Some of the changes simply replace a cast of 0 with nullptr.
> 
> The UNIX_PATH_MAX macro definitions in attachListener_{aix,posix}.cpp is
> changed to use a C++11 feature for obtaining the size of a non-static data
> member without requiring an instance.
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html
> I guess I need to propose an update to the style guide to mention this feature.
> 
> In CompressedKlassPointers::initialize, casting
> CompressedClassSpaceBaseAddress to a pointer type was triggering the warning
> in release builds for some reason. That's not a literal 0, even though it *is*
> a constant 0 in a release build. Changed to avoid that cast rather than trying
> to argue with some versions of the compiler.
> 
> Although different gcc versions on different platforms seemed to vary whether
> warning about each of these, this actually seems to be all of the explict
> casts of a literal 0 to a pointer in HotSpot.  Though because of the varied
> behaviors, new ones might slip in later.
> 
> Testing: mach5 tier1, GHA sanity tests, both with and without the warning enabled.

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22740#pullrequestreview-2502818364

From azafari at openjdk.org  Fri Dec 13 18:45:37 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 13 Dec 2024 18:45:37 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>
Message-ID: <LNu02wrDFHOXfRFGMvEcRXkU63l0oa1euAK27HQq9cw=.22f2eb3e-11d0-4272-906f-8ecc319b21cf@github.com>

On Fri, 13 Dec 2024 13:23:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into reserved_space_rewrite
>  - Fix comment
>  - 8345655: Move reservation code out of ReservedSpace

Thanks for this work.
I found no problem in logic and replacements. However, some Copyright years have to be updated:

- New files should have only one year in Copyright text:
`memoryReserver.?pp`
`reservedSpace.?pp`

- Changed files:
`cds/dynamicArchive.hpp`
`gc/g1/g1PageBasedVirtualSpace.hpp`
`gc/parallel/psVirtualspace.hpp`
`gc/shared/generationCounters.cpp` + `.hpp`
`memory/metaspace/virtualSpaceNode.hpp`

-------------

PR Review: https://git.openjdk.org/jdk/pull/22712#pullrequestreview-2502915973

From kbarrett at openjdk.org  Fri Dec 13 19:32:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 19:32:37 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v2]
In-Reply-To: <xK6_IgxPgz8ob0HnV4P6-mlB0jImP3jZNASMMlbqZSk=.9795658e-234d-45a0-b644-4d55001228a3@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <yayealnBQIb714t6VI3b-Rsqybnln2uXkdB_DIHM1Mc=.b073ef90-eabb-4388-b06e-c3549b0d22f7@github.com>
 <xK6_IgxPgz8ob0HnV4P6-mlB0jImP3jZNASMMlbqZSk=.9795658e-234d-45a0-b644-4d55001228a3@github.com>
Message-ID: <iU5mq50WA6iYrZMLZu2Nby3UWG3sN52mpyJ4Q3FFEj4=.9bdc1024-0134-48c5-a4bb-610ea7488483@github.com>

On Fri, 13 Dec 2024 08:44:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pa-splitter
>>  - parallel uses PartialArraySplitter
>>  - g1 uses PartialArraySplitter
>>  - add PartialArraySplitter
>>  - add PartialArrayTaskStats
>
> src/hotspot/share/gc/shared/partialArraySplitter.inline.hpp line 45:
> 
>> 43:   PartialArrayTaskStepper::Step step = _stepper.start(length);
>> 44:   // Push any needed partial scan tasks.  Pushed before processing the initial
>> 45:   // chunk to allow other workers to steal while we're processing.
> 
> This comment (last two lines) now imo better belongs to where this method is called. Same with similar comment in `step()`.

I was going to suggest the comment does belong here, but could perhaps be
written more clearly. But on further consideration, I don't think this comment
is needed at all. That behavior is the whole point of the splitter class, as
somewhat discussed in the comments in the header. I've expanded the comments
there to be more explicit.

Also, I really don't want to need to be adding comments about this to each
current and future caller. Part of the point of this class is to minimize the
amount of duplication among clients, and needing (near) duplicated comments
would count against that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1884397894

From kbarrett at openjdk.org  Fri Dec 13 19:37:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 19:37:39 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v2]
In-Reply-To: <nOS654TAftz8wrWlq4ncdGtbuUV-0iBm05fWSm6Yp50=.86e3db6c-c4e6-49da-b715-dee771b46dd7@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <yayealnBQIb714t6VI3b-Rsqybnln2uXkdB_DIHM1Mc=.b073ef90-eabb-4388-b06e-c3549b0d22f7@github.com>
 <nOS654TAftz8wrWlq4ncdGtbuUV-0iBm05fWSm6Yp50=.86e3db6c-c4e6-49da-b715-dee771b46dd7@github.com>
Message-ID: <hMOLMgaVUSL3dD9eVOuR5zUUcaBZef5BkZOA8X3SzPc=.a61b5a6f-1d86-4bdb-af1e-ee449cac5071@github.com>

On Fri, 13 Dec 2024 09:31:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pa-splitter
>>  - parallel uses PartialArraySplitter
>>  - g1 uses PartialArraySplitter
>>  - add PartialArraySplitter
>>  - add PartialArrayTaskStats
>
> src/hotspot/share/gc/shared/partialArraySplitter.inline.hpp line 62:
> 
>> 60: template<typename Queue>
>> 61: PartialArraySplitter::Step
>> 62: PartialArraySplitter::step(PartialArrayState* state, Queue* queue, bool stolen) {
> 
> Probably easier to read if we rename to `claim`,  step is used as noun in many other places

I like the suggested name change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1884408963

From fparain at openjdk.org  Fri Dec 13 20:31:42 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Fri, 13 Dec 2024 20:31:42 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v3]
In-Reply-To: <b_hkazVsdRadA51RvK2rKb7VLslf9CHyVOD5T_-JGJ8=.6ffb6eb4-695c-438c-b18c-f9abe04b66b8@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <b_hkazVsdRadA51RvK2rKb7VLslf9CHyVOD5T_-JGJ8=.6ffb6eb4-695c-438c-b18c-f9abe04b66b8@github.com>
Message-ID: <GYNIY0E_RAnMEZ4BR6qdKmOnGBTg8IxTKmEY4ihul2I=.fe725660-c358-4ef0-8185-8ddb985c65e4@github.com>

On Thu, 12 Dec 2024 14:51:02 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into modifiers
>  - remove "jvm support"
>  - 8345678: compute_modifiers should not be in create_mirror

LGTM

-------------

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2503199455

From sspitsyn at openjdk.org  Fri Dec 13 20:57:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 13 Dec 2024 20:57:46 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases
Message-ID: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>

New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.

The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
[8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes

CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases

Testing:
 - mach5 tiers 1-6 were run to make sure this fix caused no regressions
 - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

-------------

Commit messages:
 - fixed trailing space in jvmtiEnvBase.hpp
 - 8346143: add ClearAllFramePops function to speedup debugger single stepping in some cases

Changes: https://git.openjdk.org/jdk/pull/22744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346143
  Stats: 132 lines in 10 files changed: 116 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

PR: https://git.openjdk.org/jdk/pull/22744

From dholmes at openjdk.org  Fri Dec 13 21:04:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 13 Dec 2024 21:04:36 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <x9JKnTjoSODICfjpURAGaaFmDwJY3P7QZ_7N8CD2rCs=.f82850ad-2128-4b75-838e-83bfbfd07a81@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
 <x9JKnTjoSODICfjpURAGaaFmDwJY3P7QZ_7N8CD2rCs=.f82850ad-2128-4b75-838e-83bfbfd07a81@github.com>
Message-ID: <n0VKLxdUwIRMnMDdBpPQ981TnQIkYTqSS_nTLJwQN7M=.e4755555-110f-4916-b8dc-dcae8ec2a322@github.com>

On Fri, 13 Dec 2024 12:52:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update messages per feedback from Alan
>
> src/hotspot/share/oops/instanceKlass.cpp line 246:
> 
>> 244:              this->external_name(), this->package() != nullptr ? this->package()->name()->as_C_string() : "unnamed",
>> 245:              this->module()->loader_data()->loader_name_and_id());
>> 246:     log_trace(class, sealed)(" - %s", ss.as_string());
> 
> I'm a bit puzzled by the check so I'm not commenting on the log/exception message just yet.
> 
> If the super class (this) is in an unnamed module then the permitted subclass (k) must be in the same package.
> 
> If the super class is in a named module then permitted subclass can be in a different package but both need to be public in order.
> 
> I'm just trying to see how this maps to the check because it doesn't appear to take named vs. unnamed module into account, e.g. the subclass k might be public but in a different package of the same unnamed module. It's possible that I've mis-read this but it to goes to what the exception message is for these cases.

Those are not the rules in JVMS (at least not obviously so). We get ICCE if any of the following are violated:

- The superclass is in a different run-time module than C (?5.3.6).
- C does not have its ACC_PUBLIC flag set (?4.1) and the superclass is in a different run-time package than C (?5.3).
- No entry in the classes array of the superclass's PermittedSubclasses attribute refers to a class or interface with the name N. 

We already determined both classes are in the same module, so now we just do the public/same-package check. Whether the module is un-named or not doesn't come into it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1884538725

From amenkov at openjdk.org  Fri Dec 13 21:22:37 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 13 Dec 2024 21:22:37 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <aPDmyKTsRWH5rz_PlQ3x3WLcpsiEVoTqLGVUEQ7x4vk=.8472c6f9-7a2f-4d6e-9a79-4e51ec704777@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
 <aPDmyKTsRWH5rz_PlQ3x3WLcpsiEVoTqLGVUEQ7x4vk=.8472c6f9-7a2f-4d6e-9a79-4e51ec704777@github.com>
Message-ID: <sGeS9qupzQg4RfWCZcXSPaMixW7Q1SgcOZ0QBMlApXc=.8998bf58-f753-4246-ac39-b000ff806c86@github.com>

On Fri, 13 Dec 2024 15:57:31 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > if no agents are loaded, I would print "JVMTI agents: none" unconditionally. Makes it more obvious than just a missing entry; >that could be also an error.
> 
> Maybe after the while loop something like this ?
> 
> ```
>   bool first_agent = true;
>   while (it.has_next()) {
>       ...
>   }
>   **if (first_agent) st->print_cr("JVMTI agents: none");**
> ```

You can do it before the loop:

if (it.has_next()) {
  st->print_cr("JVMTI agents:");
} else {
  st->print_cr("JVMTI agents: none");
}

and get rid of `first_agent` variable

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2542400056

From coleenp at openjdk.org  Fri Dec 13 21:37:55 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 13 Dec 2024 21:37:55 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v4]
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Removed comment about compute_modifiers().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22618/files
  - new: https://git.openjdk.org/jdk/pull/22618/files/a0792dff..ef393005

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22618&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22618.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22618/head:pull/22618

PR: https://git.openjdk.org/jdk/pull/22618

From kbarrett at openjdk.org  Fri Dec 13 22:24:07 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 13 Dec 2024 22:24:07 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v3]
In-Reply-To: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
Message-ID: <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>

> Please review this change that introduces two new helper classes to simplify
> the usage of PartialArrayStates to manage splitting the processing of large
> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
> changed to use this new mechanism.
> 
> PartialArrayTaskStats is used to collect and report statistics related to
> array splitting.  It replaces the direct implementation in PSPromotionManager,
> and is now also used by G1 young GCs.
> 
> PartialArraySplitter packages up most of the work involved in splitting and
> processing tasks. It provides task allocation and release, enqueuing, chunk
> claiming, and statistics tracking. It does this by encapsulating existing
> objects and functionality. Using array splitting is mostly reduced to calling
> the splitter's start function and then calling it's step function to process
> partial states. This substantially reduces the amount of code for each client
> to perform this work.
> 
> Testing: mach5 tier1-5
> 
> Manually ran some test programs with each of G1 and Parallel, with taskqueue
> stats logging enabled, and checked that the logged statistics looked okay.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into pa-splitter
 - rename splitter.step() => claim()
 - simplify comments
 - Merge branch 'master' into pa-splitter
 - parallel uses PartialArraySplitter
 - g1 uses PartialArraySplitter
 - add PartialArraySplitter
 - add PartialArrayTaskStats

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22622/files
  - new: https://git.openjdk.org/jdk/pull/22622/files/b0ea3f51..cb70d7b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22622&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22622&range=01-02

  Stats: 265 lines in 36 files changed: 116 ins; 64 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/22622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22622/head:pull/22622

PR: https://git.openjdk.org/jdk/pull/22622

From ccheung at openjdk.org  Sat Dec 14 00:04:46 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Sat, 14 Dec 2024 00:04:46 GMT
Subject: RFR: 8345838: Remove the appcds/javaldr/AnonVmClassesDuringDump.java
 test
Message-ID: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>

Please review this simple change for removing a test.

Testing:

- [x]      tier1
- [x]      all CDS tests on linux-x64

-------------

Commit messages:
 - 8345838: Remove the appcds/javaldr/AnonVmClassesDuringDump.java test

Changes: https://git.openjdk.org/jdk/pull/22747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345838
  Stats: 165 lines in 4 files changed: 0 ins; 165 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22747/head:pull/22747

PR: https://git.openjdk.org/jdk/pull/22747

From iklam at openjdk.org  Sat Dec 14 00:16:34 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 14 Dec 2024 00:16:34 GMT
Subject: RFR: 8345838: Remove the
 appcds/javaldr/AnonVmClassesDuringDump.java test
In-Reply-To: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>
References: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>
Message-ID: <3DLPlPNoDQFfxVh5dzhsHwKvfOeAvjx6UQVATPPO5bM=.b7ed1a8b-6e0b-4592-9644-190b197403c4@github.com>

On Sat, 14 Dec 2024 00:00:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this simple change for removing a test.
> 
> Testing:
> 
> - [x]      tier1
> - [x]      all CDS tests on linux-x64

Marked as reviewed by iklam (Reviewer).

Looks good.

This test was written before CDS had support for archived Lambda classes so it tried to assert that there are no Lambda classes in the CDS archive. Now we are storing Lambda classes in the archive, but there is a bug in the test so it couldn't find them (so the test is reporting "passed"). Since this test serves no purpose now, we should remove it.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22747#pullrequestreview-2503412212
PR Comment: https://git.openjdk.org/jdk/pull/22747#issuecomment-2542576731

From aph at openjdk.org  Sat Dec 14 10:05:47 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 14 Dec 2024 10:05:47 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
 <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
 <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
Message-ID: <Tr7TUZOufbH6KR6R_NzEtvmkMv_CjCRMfhBRONAh9FI=.5abcafd3-713d-43b6-962e-3457195416a0@github.com>

On Fri, 13 Dec 2024 10:24:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 
> If instead of this PR we were to use some variant of `form_address()` on register+offset addresses, we wouldn't need to care about whether the offsets were compile-time constants or not, we wouldn't need this extra code, and the result would be easier to read and maintain.

Note: we only should do that on register+offset addresses that we don't already know to be safe.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2543036787

From fyang at openjdk.org  Sun Dec 15 16:08:26 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sun, 15 Dec 2024 16:08:26 GMT
Subject: RFR: 8346235: RISC-V: Optimize bitwise AND with mask values [v2]
In-Reply-To: <U3OVcyfvBtipaipydZfDbp8H2rP5MyPjjC6DSmUImIk=.f6db6b77-1017-40fd-a26b-6759383401ae@github.com>
References: <_F34FB5KUiuDBWK3h7IOK5N5sDamvk-_kiYp59pljtI=.6c27d267-b7fa-4e5f-ba11-167fd8542e18@github.com>
 <U3OVcyfvBtipaipydZfDbp8H2rP5MyPjjC6DSmUImIk=.f6db6b77-1017-40fd-a26b-6759383401ae@github.com>
Message-ID: <_mrHPsQdluF5cqSFNoOAhw5BZeWYt1jaUMHHAA7E2Y0=.baa70143-0623-461a-8476-16219748e878@github.com>

On Sun, 15 Dec 2024 15:03:14 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5867:
> 
>> 5865: 
>> 5866:   if (bits == 8) {
>> 5867:     andi(dst, src, 0xFF);
> 
> Maybe we could move `andi` to here:
> https://github.com/openjdk/jdk/blob/6b022bb64b2109c8cd40ebd3b8b3226cf894544d/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L5855-L5859

Make sense. I just find that `zext_b(dst, src);` should not depend on `UseZbb`. So I just removed this check. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22752#discussion_r1885751106

From jbhateja at openjdk.org  Sun Dec 15 17:59:51 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 15 Dec 2024 17:59:51 GMT
Subject: Withdrawn: 8342103: C2 compiler support for Float16 type and
 associated operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <tyMZKJQjmFJq7Sqzk-qXJnm0OsgyFUkM9-_jvieC-j0=.d9aaa5b5-fd9b-4f56-92be-0403db9e360d@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21490

From zgu at openjdk.org  Sun Dec 15 18:14:35 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 15 Dec 2024 18:14:35 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v3]
In-Reply-To: <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
Message-ID: <OxSm_mjeVDgn2Zns07_5ye5ng_sAbAVTHrN6uYz5ZDw=.00ef61e9-5115-4255-be1f-ff52866ceec2@github.com>

On Fri, 13 Dec 2024 22:24:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - rename splitter.step() => claim()
>  - simplify comments
>  - Merge branch 'master' into pa-splitter
>  - parallel uses PartialArraySplitter
>  - g1 uses PartialArraySplitter
>  - add PartialArraySplitter
>  - add PartialArrayTaskStats

src/hotspot/share/utilities/macros.hpp line 375:

> 373: #define TASKQUEUE_STATS_ONLY(code)
> 374: #endif // TASKQUEUE_STATS
> 375: 

Duplicated definition in `TaskQueue.hpp`
https://github.com/openjdk/jdk/blob/ab1dbd4089a1a15bdf1b6b39994d5b1faacc40ab/src/hotspot/share/gc/shared/taskqueue.hpp#L39-51 should be removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1885792871

From jbhateja at openjdk.org  Sun Dec 15 18:19:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 15 Dec 2024 18:19:35 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations
Message-ID: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>

Hi All,

This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)

Following is the summary of changes included with this patch:-

1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
      -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
6. Auto-vectorization of newly supported scalar operations.
7. X86 and AARCH64 backend implementation for all supported intrinsics.
9. Functional and Performance validation tests.

Kindly review and share your feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - C2 compiler support for float16 scalar operations.

Changes: https://git.openjdk.org/jdk/pull/22754/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342103
  Stats: 2633 lines in 54 files changed: 2589 ins; 0 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Sun Dec 15 18:19:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 15 Dec 2024 18:19:35 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <5s62x13e3X2XmGxSwxY6zrtlSLVS7Y_uDdTHJpxNz1U=.2d5cf677-7af2-4483-8ff1-1f91fb26a5da@github.com>

On Sun, 15 Dec 2024 18:05:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Some FAQs on the newly added ideal type for half-float IR nodes:-

Q. Why do we not use existing TypeInt::SHORT instead of creating a new TypeH type?
A. Newly defined half float type named TypeH is special as its basic type is T_SHORT while its ideal type is RegF. Thus, the C2 type system views its associated IR node as a 16-bit short value while the register allocator assigns it a floating point register.

Q. Problem with ConF?
A. During Auto-Vectorization, ConF replication constrains the operational vector lane count to half of what can otherwise be used for regular Float16 operation i.e. only 16 floats can be accommodated into a 512-bit vector thereby limiting the lane count of vectors in its use-def chain, one possible way to address it is through a kludge in auto-vectorizer to cast them to a 16 bits constant by analyzing its context. Newly defined Float16 constant nodes 'ConH' are inherently 16-bit encoded IEEE 754 FP16 values and can be efficiently packed to leverage full target vector width.

All Float16 IR nodes now carry newly defined Type::HALF_FLOAT type instead of Type::FLOAT, thus we no longer need special handling in auto-vectorizer to prune their container type to short.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2543982577

From dholmes at openjdk.org  Sun Dec 15 21:31:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 15 Dec 2024 21:31:35 GMT
Subject: RFR: 8346160: Fix -Wzero-as-null-pointer-constant warnings from
 explicit casts
In-Reply-To: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>
References: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>
Message-ID: <vXJJ23sYz3-mT3HBb5UMGtYM0JzIthi3cTJbGH_yQ-s=.5340e25e-0d05-462d-8c55-3f5c0b839665@github.com>

On Fri, 13 Dec 2024 17:23:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that removes -Wzero-as-null-pointer-constant
> warnings from explicit casts of a literal 0 to a pointer type.  Different
> versions of gcc seem to warn about different cases changed here, but all of
> these showed up as a warning in some testing, whether Oracle CI, GHA sanity
> tests, or local cross-builds using Oracle's devkits for that.
> 
> Some of the changes simply replace a cast of 0 with nullptr.
> 
> The UNIX_PATH_MAX macro definitions in attachListener_{aix,posix}.cpp is
> changed to use a C++11 feature for obtaining the size of a non-static data
> member without requiring an instance.
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html
> I guess I need to propose an update to the style guide to mention this feature.
> 
> In CompressedKlassPointers::initialize, casting
> CompressedClassSpaceBaseAddress to a pointer type was triggering the warning
> in release builds for some reason. That's not a literal 0, even though it *is*
> a constant 0 in a release build. Changed to avoid that cast rather than trying
> to argue with some versions of the compiler.
> 
> Although different gcc versions on different platforms seemed to vary whether
> warning about each of these, this actually seems to be all of the explict
> casts of a literal 0 to a pointer in HotSpot.  Though because of the varied
> behaviors, new ones might slip in later.
> 
> Testing: mach5 tier1, GHA sanity tests, both with and without the warning enabled.

That all seem fine. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22740#pullrequestreview-2504720140

From kbarrett at openjdk.org  Sun Dec 15 22:32:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 15 Dec 2024 22:32:36 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v3]
In-Reply-To: <OxSm_mjeVDgn2Zns07_5ye5ng_sAbAVTHrN6uYz5ZDw=.00ef61e9-5115-4255-be1f-ff52866ceec2@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
 <OxSm_mjeVDgn2Zns07_5ye5ng_sAbAVTHrN6uYz5ZDw=.00ef61e9-5115-4255-be1f-ff52866ceec2@github.com>
Message-ID: <UNp3Hrs9XPQJYmQJ_iX8NfbmsONKS36vxjMJYLws_FQ=.1011afa9-b79d-49f5-b890-55dd6173cc00@github.com>

On Sun, 15 Dec 2024 18:12:20 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pa-splitter
>>  - rename splitter.step() => claim()
>>  - simplify comments
>>  - Merge branch 'master' into pa-splitter
>>  - parallel uses PartialArraySplitter
>>  - g1 uses PartialArraySplitter
>>  - add PartialArraySplitter
>>  - add PartialArrayTaskStats
>
> src/hotspot/share/utilities/macros.hpp line 375:
> 
>> 373: #define TASKQUEUE_STATS_ONLY(code)
>> 374: #endif // TASKQUEUE_STATS
>> 375: 
> 
> Duplicated definition in `TaskQueue.hpp`
> https://github.com/openjdk/jdk/blob/ab1dbd4089a1a15bdf1b6b39994d5b1faacc40ab/src/hotspot/share/gc/shared/taskqueue.hpp#L39-51 should be removed.

Oops.  Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1885908376

From kbarrett at openjdk.org  Mon Dec 16 04:27:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Dec 2024 04:27:39 GMT
Subject: RFR: 8346160: Fix -Wzero-as-null-pointer-constant warnings from
 explicit casts
In-Reply-To: <STI7ifvhkEzUPtCOQGDxF1RiU0HXdKYGGNsh2kMc6Xw=.ca963299-aa57-48db-bfa6-f9f68769ca3a@github.com>
References: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>
 <STI7ifvhkEzUPtCOQGDxF1RiU0HXdKYGGNsh2kMc6Xw=.ca963299-aa57-48db-bfa6-f9f68769ca3a@github.com>
Message-ID: <Z5JSYrnauSSV-jKcnaTtW-oa6QdMbG9KFZHqPOKqlI4=.f154949a-5a15-4a61-a04f-ec9bd1726f15@github.com>

On Fri, 13 Dec 2024 17:39:19 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Please review this change that removes -Wzero-as-null-pointer-constant
>> warnings from explicit casts of a literal 0 to a pointer type.  Different
>> versions of gcc seem to warn about different cases changed here, but all of
>> these showed up as a warning in some testing, whether Oracle CI, GHA sanity
>> tests, or local cross-builds using Oracle's devkits for that.
>> 
>> Some of the changes simply replace a cast of 0 with nullptr.
>> 
>> The UNIX_PATH_MAX macro definitions in attachListener_{aix,posix}.cpp is
>> changed to use a C++11 feature for obtaining the size of a non-static data
>> member without requiring an instance.
>> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html
>> I guess I need to propose an update to the style guide to mention this feature.
>> 
>> In CompressedKlassPointers::initialize, casting
>> CompressedClassSpaceBaseAddress to a pointer type was triggering the warning
>> in release builds for some reason. That's not a literal 0, even though it *is*
>> a constant 0 in a release build. Changed to avoid that cast rather than trying
>> to argue with some versions of the compiler.
>> 
>> Although different gcc versions on different platforms seemed to vary whether
>> warning about each of these, this actually seems to be all of the explict
>> casts of a literal 0 to a pointer in HotSpot.  Though because of the varied
>> behaviors, new ones might slip in later.
>> 
>> Testing: mach5 tier1, GHA sanity tests, both with and without the warning enabled.
>
> Marked as reviewed by stefank (Reviewer).

Thanks for reviews @stefank and @dholmes-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22740#issuecomment-2544564921

From kbarrett at openjdk.org  Mon Dec 16 04:27:40 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Dec 2024 04:27:40 GMT
Subject: Integrated: 8346160: Fix -Wzero-as-null-pointer-constant warnings from
 explicit casts
In-Reply-To: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>
References: <bdcuFLSXxu9w1b5Mw50nLNqSGpswsR3vyMWPxwt2xRQ=.23587395-e3b7-40a3-ab00-65abd819514e@github.com>
Message-ID: <KsFl5U5ki8CGyWaBr3DY7sZT6Hb1Q1qlQQqoe07lCUk=.18e52db3-ea28-478c-b265-a6d93f3375b1@github.com>

On Fri, 13 Dec 2024 17:23:05 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that removes -Wzero-as-null-pointer-constant
> warnings from explicit casts of a literal 0 to a pointer type.  Different
> versions of gcc seem to warn about different cases changed here, but all of
> these showed up as a warning in some testing, whether Oracle CI, GHA sanity
> tests, or local cross-builds using Oracle's devkits for that.
> 
> Some of the changes simply replace a cast of 0 with nullptr.
> 
> The UNIX_PATH_MAX macro definitions in attachListener_{aix,posix}.cpp is
> changed to use a C++11 feature for obtaining the size of a non-static data
> member without requiring an instance.
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2253.html
> I guess I need to propose an update to the style guide to mention this feature.
> 
> In CompressedKlassPointers::initialize, casting
> CompressedClassSpaceBaseAddress to a pointer type was triggering the warning
> in release builds for some reason. That's not a literal 0, even though it *is*
> a constant 0 in a release build. Changed to avoid that cast rather than trying
> to argue with some versions of the compiler.
> 
> Although different gcc versions on different platforms seemed to vary whether
> warning about each of these, this actually seems to be all of the explict
> casts of a literal 0 to a pointer in HotSpot.  Though because of the varied
> behaviors, new ones might slip in later.
> 
> Testing: mach5 tier1, GHA sanity tests, both with and without the warning enabled.

This pull request has now been integrated.

Changeset: c88e081a
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c88e081a6a0a00d7e7e5f2337f942a1d6c3b5110
Stats:     6 lines in 5 files changed: 0 ins; 0 del; 6 mod

8346160: Fix -Wzero-as-null-pointer-constant warnings from explicit casts

Reviewed-by: stefank, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22740

From dholmes at openjdk.org  Mon Dec 16 05:39:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Dec 2024 05:39:41 GMT
Subject: RFR: 8345838: Remove the
 appcds/javaldr/AnonVmClassesDuringDump.java test
In-Reply-To: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>
References: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>
Message-ID: <5ImxxQ0xmX7hNCaNVYp-3xjUygGWKeE618M5kahJuYw=.4bfdccd3-10c6-4af0-a089-4ebde8efcb97@github.com>

On Sat, 14 Dec 2024 00:00:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this simple change for removing a test.
> 
> Testing:
> 
> - [x]      tier1
> - [x]      all CDS tests on linux-x64

Ok

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22747#pullrequestreview-2505191335

From rrich at openjdk.org  Mon Dec 16 07:19:41 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 16 Dec 2024 07:19:41 GMT
Subject: Integrated: 8345975: Update SAP SE copyright year to 2024 where it was
 missed
In-Reply-To: <FCAc314K5DwyuixHEQa6cVENP8mNKTuLbC5CUpw7LT8=.de37687f-06b5-4208-a50a-07d91e7e1045@github.com>
References: <FCAc314K5DwyuixHEQa6cVENP8mNKTuLbC5CUpw7LT8=.de37687f-06b5-4208-a50a-07d91e7e1045@github.com>
Message-ID: <Qw_apkTeivlNCQCYM4LF6goFi5H52nYxnnbw-vXQWmk=.9f951e52-416c-4d17-89bb-7b8f82d9e2e1@github.com>

On Wed, 11 Dec 2024 09:55:30 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

> This pr updates the SAP SE copyright year in files that where changed in 2024 but the update was forgotten.
> 
> I used the following command to find the files
> 
> 
> git log '--since=Jan 1' --name-only --pretty=format:    \
>     --author asteiner                                   \
>     --author azeller                                    \
>     --author clanger                                    \
>     --author goetz                                      \
>     --author jbechberger                                \
>     --author jkern                                      \
>     --author lucy                                       \
>     --author mdoerr                                     \
>     --author mbaesken                                   \
>     --author rrich                                      \
>     --author rschmelter                                 \
>     --author andrewlu                                   \
>     --author ashi                                       \
>      | sort -u | xargs grep -l 'SAP SE'

This pull request has now been integrated.

Changeset: ee1c5ad8
Author:    Richard Reingruber <rrich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee1c5ad8fe99ec427604773a6f04baa0ad765c9e
Stats:     24 lines in 24 files changed: 0 ins; 0 del; 24 mod

8345975: Update SAP SE copyright year to 2024 where it was missed

Reviewed-by: mdoerr, clanger

-------------

PR: https://git.openjdk.org/jdk/pull/22677

From epeter at openjdk.org  Mon Dec 16 07:24:36 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 16 Dec 2024 07:24:36 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>

On Sun, 15 Dec 2024 18:05:02 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Can you quickly summarize what tests you have, and what they test?

test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 49:

> 47:         counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
> 48:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "zvfh", "true"},
> 49:         counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})

Looks like this is having vector changes?
And this is pre-existing: but why are we using `VECTOR_SIZE_ANY` here? Can we not know the vector size? Maybe we can introduce a new tag `max_float16` or `max_hf`. And do something like this:
`IRNode.VECTOR_SIZE + "min(max_float, max_hf)", "> 0"`

The downside with using `ANY` is that the exact size is not tested, and that might mean that the size is much smaller than ideal.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2505332519
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1886290546

From mbaesken at openjdk.org  Mon Dec 16 07:57:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 07:57:54 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v32]
In-Reply-To: <x4Hx6VRHiYwGLud9kCoVV1xpR6qlgIN5sMsEjrUokJg=.560d6eda-5cde-4c78-94f5-c978bfb08804@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
 <x4Hx6VRHiYwGLud9kCoVV1xpR6qlgIN5sMsEjrUokJg=.560d6eda-5cde-4c78-94f5-c978bfb08804@github.com>
Message-ID: <MmQ4RBAKvMs-qXb5N9BmZOpIxYaNpw4l5NuFw-4_i-g=.72422349-e78f-490d-b7be-b41cda285dee@github.com>

On Wed, 27 Nov 2024 11:31:31 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP draft: CPU Time based profiling for JFR].
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

TestCPUTimeClassUnloading coming with this change fails on our Linux aarch64 test machine ~ every second or third day with
java.lang.AssertionError: Not enough events
	at jdk.jfr.event.profiling.TestCPUTimeClassUnloading.main(TestCPUTimeClassUnloading.java:87)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20752#issuecomment-2544843553

From fyang at openjdk.org  Mon Dec 16 08:07:37 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 16 Dec 2024 08:07:37 GMT
Subject: RFR: 8346235: RISC-V: Optimize bitwise AND with mask values [v2]
In-Reply-To: <Lxv9_yeE_jByYm2sKFgRTV9H-Rc14_SzrZpRfdQFfgs=.b9675df9-eb62-4717-9816-98fe3a26bdb4@github.com>
References: <_F34FB5KUiuDBWK3h7IOK5N5sDamvk-_kiYp59pljtI=.6c27d267-b7fa-4e5f-ba11-167fd8542e18@github.com>
 <LnDx_08Bjp1vSyknUoB1KGINdwVP5cZCUJk5QKMfbtM=.fc58658c-8f5d-4628-94ca-5f05e56c4639@github.com>
 <Lxv9_yeE_jByYm2sKFgRTV9H-Rc14_SzrZpRfdQFfgs=.b9675df9-eb62-4717-9816-98fe3a26bdb4@github.com>
Message-ID: <3eEJZMxk4l0fThx3b4jBhH51VUzjUKnVBwAKp2mwOwA=.65af3ad8-70d2-49ee-b6da-883a7e174928@github.com>

On Mon, 16 Dec 2024 03:17:16 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment
>
> Marked as reviewed by fjiang (Committer).

@feilongjiang @zifeihan : Thanks for having a look!

Since this removes one `UseZbb` check [1] which was introduced by https://bugs.openjdk.org/browse/JDK-8320069, @robehn : could you please confirm?

[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/riscv/macroAssembler_riscv.cpp#L5856

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22752#issuecomment-2544861520

From mbaesken at openjdk.org  Mon Dec 16 08:16:40 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 08:16:40 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v4]
In-Reply-To: <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <S3aTt5bdCSnox91ZsvWG1sva8_5CN3-f_s2WEKVVu3s=.216b4fb0-1f7f-459a-91ce-0ad77e274f55@github.com>
Message-ID: <MY-t3kg0dmnROtWTNAEhiXKrXCUuozmHD3-L8aCkRyw=.a953e805-1dcb-461c-b104-f6b5757e819e@github.com>

On Fri, 13 Dec 2024 12:18:13 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   simplify coding

When printing  'JVMTI agents: none' , should I maybe better iterate  `JvmtiAgentList::all() `  to get the xrun agents as well and be sure that there are  _really_ none ?
Unfortunately `JvmtiAgentList::all() `  is private , any objections making it public ?  Otherwise we probably need to call  2 iterations (agents() and xrun_agents()).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2544878498

From jbhateja at openjdk.org  Mon Dec 16 08:35:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Dec 2024 08:35:31 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v2]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <tIpOEBhxrR8pKz_ga0jP4HPFGl1ydLeudrrYoMQMcJE=.bded950c-6ea3-4062-b9d5-6e61aa775006@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Adding missed check in container type detection.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/c215eac7..7cb694fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Mon Dec 16 08:35:33 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Dec 2024 08:35:33 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v2]
In-Reply-To: <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
Message-ID: <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>

On Mon, 16 Dec 2024 07:22:04 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> Can you quickly summarize what tests you have, and what they test?

Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation.  Let me know if you see any gaps.

> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 49:
> 
>> 47:         counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
>> 48:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "zvfh", "true"},
>> 49:         counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
> 
> Looks like this is having vector changes?
> And this is pre-existing: but why are we using `VECTOR_SIZE_ANY` here? Can we not know the vector size? Maybe we can introduce a new tag `max_float16` or `max_hf`. And do something like this:
> `IRNode.VECTOR_SIZE + "min(max_float, max_hf)", "> 0"`
> 
> The downside with using `ANY` is that the exact size is not tested, and that might mean that the size is much smaller than ideal.

Hi @eme64 , Test modification looks ok to me, we intend to trigger these IR rules on non AVX512-FP16 targets.
On AVX512-FP16 target compiler will infer scalar float16 add operation which will not get auto-vectorized.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2544914959
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1886373922

From rehn at openjdk.org  Mon Dec 16 08:46:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 16 Dec 2024 08:46:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v4]
In-Reply-To: <xl6AXujqlnKrt7SnPj5J2U6_7iWbcIaHSHB1K4vMO74=.36e0c189-d044-4543-8e1d-cdfbf97fba53@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <eDa_V-V6eW_Suod-vIavza8KWoLPTCrvW8ze-PY-tso=.d0d97aad-48e5-47cb-89df-ff1f0b8932a5@github.com>
 <xl6AXujqlnKrt7SnPj5J2U6_7iWbcIaHSHB1K4vMO74=.36e0c189-d044-4543-8e1d-cdfbf97fba53@github.com>
Message-ID: <gJrFBh2QBpsXsoNBYDq6nbMaz0LOLr_WjRz7OzUNGWc=.8dc36cc2-a5c3-4c8c-8c93-9327f24d0ec4@github.com>

On Thu, 12 Dec 2024 09:46:46 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Inclusive case
>
> Nice work. Thanks!

Ping @Hamlin-Li

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22574#issuecomment-2544947505

From epeter at openjdk.org  Mon Dec 16 09:06:36 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 16 Dec 2024 09:06:36 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v2]
In-Reply-To: <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
 <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>
Message-ID: <xCmBgJGY_IQMTbqFxlT3WKxI4ZQ9x4kgryTmUX8w3xU=.acbcba77-a4d3-4feb-87f2-2e12ea2477bc@github.com>

On Mon, 16 Dec 2024 08:32:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> > Can you quickly summarize what tests you have, and what they test?
> 
> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.

I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2544992852

From mli at openjdk.org  Mon Dec 16 09:15:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Mon, 16 Dec 2024 09:15:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v6]
In-Reply-To: <WYzkJld_ZB-n0_eGkgvUmm9eFHmiwI4vFcjmF6VRWnA=.96e31d4f-6450-4602-b8ae-2e14fb4bdc63@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <WYzkJld_ZB-n0_eGkgvUmm9eFHmiwI4vFcjmF6VRWnA=.96e31d4f-6450-4602-b8ae-2e14fb4bdc63@github.com>
Message-ID: <3B3Xu2BbeO7jjbF-3i_90qExcAGBkWJgorfpU_iiBVU=.10918d05-c3b8-4bf5-8727-7a09495c8b45@github.com>

On Fri, 13 Dec 2024 08:05:14 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hi, please consider these additional concurrent tests.
>> 
>> (this will not go into 24)
>> 
>> There are two concurrent counter versions:
>> - Each thread is exclusively responsible for an certain increment steps
>> - Each thread plainly tries to CAS increment by one
>> 
>> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
>> 
>> 
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
>> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
>> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
>> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
>> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
>> 
>> 
>> Execute with +UseZacas, and without on BPI-F3.
>> 
>> Thanks, Robbin
>
> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Fixed max->min
>  - Merge branch 'master' into 8345322
>  - Merge branch 'master' into 8345322
>  - Fixed tests for uint32 and added edges cases
>  - Inclusive case
>  - Reviews comments, added uint32
>  - Code share
>  - Overflow
>  - Merge branch 'master' into 8345322
>  - Concurrent

Sorry for the late reply.
Yes, still good. Thanks!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22574#pullrequestreview-2505578882

From rehn at openjdk.org  Mon Dec 16 09:15:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 16 Dec 2024 09:15:38 GMT
Subject: RFR: 8345322: RISC-V: Add concurrent gtests for cmpxchg variants
 [v6]
In-Reply-To: <3B3Xu2BbeO7jjbF-3i_90qExcAGBkWJgorfpU_iiBVU=.10918d05-c3b8-4bf5-8727-7a09495c8b45@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
 <WYzkJld_ZB-n0_eGkgvUmm9eFHmiwI4vFcjmF6VRWnA=.96e31d4f-6450-4602-b8ae-2e14fb4bdc63@github.com>
 <3B3Xu2BbeO7jjbF-3i_90qExcAGBkWJgorfpU_iiBVU=.10918d05-c3b8-4bf5-8727-7a09495c8b45@github.com>
Message-ID: <Z6Fa6-vGauf2rVx2FzErHLGsRzYcbTf5Z_lxbo-si3Y=.eef25226-b25a-47ba-8d7e-8370097a98f6@github.com>

On Mon, 16 Dec 2024 09:11:11 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Robbin Ehn has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Fixed max->min
>>  - Merge branch 'master' into 8345322
>>  - Merge branch 'master' into 8345322
>>  - Fixed tests for uint32 and added edges cases
>>  - Inclusive case
>>  - Reviews comments, added uint32
>>  - Code share
>>  - Overflow
>>  - Merge branch 'master' into 8345322
>>  - Concurrent
>
> Sorry for the late reply.
> Yes, still good. Thanks!

Thanks @Hamlin-Li !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22574#issuecomment-2545015247

From rehn at openjdk.org  Mon Dec 16 09:50:45 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Mon, 16 Dec 2024 09:50:45 GMT
Subject: Integrated: 8345322: RISC-V: Add concurrent gtests for cmpxchg
 variants
In-Reply-To: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
References: <BLu-Kpy9Czgq6qPHYseoNj0trfdzrpNOPggncPP94rw=.86715019-8309-4a32-8a3e-e26385cac786@github.com>
Message-ID: <_GCMVuhZ9s1nwlKFT-CojD8Zkd0xFX2N7teQzqQlRHs=.ac4bbefc-ecff-49f1-8bfa-ba5a0a6c7d4e@github.com>

On Thu, 5 Dec 2024 11:49:47 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hi, please consider these additional concurrent tests.
> 
> (this will not go into 24)
> 
> There are two concurrent counter versions:
> - Each thread is exclusively responsible for an certain increment steps
> - Each thread plainly tries to CAS increment by one
> 
> I refactored the code, so these concurrent versions can reuse the generated CAS functions.
> 
> 
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_lr_sc_vm (24 ms)
> [ RUN      ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int64_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int32_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_lr_sc_vm (14 ms)
> [ RUN      ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.cmpxchg_int8_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int64_concurrent_maybe_zacas_vm (11 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_lr_sc_vm (15 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int32_concurrent_maybe_zacas_vm (12 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int16_concurrent_maybe_zacas_vm (14 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_lr_sc_vm (13 ms)
> [ RUN      ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm
> [       OK ] RiscV.weak_cmpxchg_int8_concurrent_maybe_zacas_vm (15 ms)
> 
> 
> Execute with +UseZacas, and without on BPI-F3.
> 
> Thanks, Robbin

This pull request has now been integrated.

Changeset: 92860186
Author:    Robbin Ehn <rehn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92860186ec72dd5de55b310700a6b4f03d8b64fd
Stats:     507 lines in 1 file changed: 309 ins; 23 del; 175 mod

8345322: RISC-V: Add concurrent gtests for cmpxchg variants

Reviewed-by: mli, fyang

-------------

PR: https://git.openjdk.org/jdk/pull/22574

From chagedorn at openjdk.org  Mon Dec 16 09:56:42 2024
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 16 Dec 2024 09:56:42 GMT
Subject: Integrated: 8345801: C2: Clean up include statements to speed up
 compilation when touching type.hpp
In-Reply-To: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
References: <QmVlKla1jLOGztyP0VpIw5wEY_Zxx51zsDiVpBsdR4Q=.ecf250a0-ebb0-4bc2-9013-e907b69ce709@github.com>
Message-ID: <PtZhXKR5qEvWbWb7SZxD5337e2kMvZREvyCoYEa4Dg0=.5ba8c7d9-8058-4f0c-b4bb-b780e778bf25@github.com>

On Tue, 10 Dec 2024 09:31:27 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

> I've noticed that after touching `type.hpp` in Valhalla, it requires more than 7 minutes to build hotspot again on my machine. I would have suspected that we mostly recompile C2/opto source files. But that is far from the truth: A lot of unrelated source files must be recompiled, including, for example, C1, JFR, or runtime files.
> 
> In mainline, the impact is not that severe. But it still requires around 1 minute to build hotspot again on my machine after touching `type.hpp`. I've had a look at the include chains and removed quite a lot of unused includes. For the active includes, the most impact had including `output.hpp` inside `c2compiler.hpp`. This set up the following dependency chain:
> 
> ... more C1 files
>   #include "c1/c1_Compilation.hpp"
>     #include "compiler/compilerDefinitions.inline.hpp"
>       #include "opto/c2compiler.hpp"
>         #include "opto/output.hpp"    <------------ Problematic include
>           #include "opto/c2_CodeStubs.hpp"
>             #include "opto/compile.hpp"
>               ... more opto files and eventually type.hpp
> 
> This means that a lot of C1 files also need to be re-compiled as well as some more source file that include `compiler/compilerDefinitions.inline.hpp`. I cut this dependency chain by removing the include of `opto/output.hpp` in `opto/c2compiler.hpp` and moved the constant `initial_const_capacity` from `output.hpp` to `c2Compiler.hpp` which seemed to be the only reason why we have the include in place. After this change, I was required to add some missing includes that were included transitively before.
> 
> The final mainline patch could also be applied to the current Valhalla repository (with some small tweaks). The results were quite promising. I could bring the compilation time on my machine significantly down in mainline and especially in Valhalla after touching `type.hpp`:
> 
> - Mainline: ~1min -> ~40s (1.5 times faster)
> - Valhalla: ~7min -> ~40s (10.5 times faster)
> 
> I've only focused on `type.hpp` here but I guess other includes in the JIT compiler area or other parts of hotspot could also be revisited to possibly speed up the compilation after touching some header files.
> 
> Testing:
> - Oracle CI
> - GHA
> 
> Thanks,
> Christian

This pull request has now been integrated.

Changeset: 32c8195c
Author:    Christian Hagedorn <chagedorn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32c8195c3acce2d220829bf5b81e3cef907fff3c
Stats:     86 lines in 31 files changed: 15 ins; 69 del; 2 mod

8345801: C2: Clean up include statements to speed up compilation when touching type.hpp

Reviewed-by: kvn, dlong, jwaters

-------------

PR: https://git.openjdk.org/jdk/pull/22658

From syan at openjdk.org  Mon Dec 16 09:57:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 16 Dec 2024 09:57:45 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails build
 with clang17
Message-ID: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>

Hi all,
Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.

Here is the example explain the "dead code" elimination.

1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.


> cat demo.c 
int main() { char *t = 0; *t = 'c'; return 0; }
> clang -O0 demo.c && ./a.out ; echo $?
Segmentation fault (core dumped)
139
> clang -O1 demo.c && ./a.out ; echo $?
0


2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.

> cat demo.c 
int main() { volatile char *t = 0; *t = 'c'; return 0; }
> clang -O0 demo.c && ./a.out ; echo $?
Segmentation fault (core dumped)
139
> clang -O1 demo.c && ./a.out ; echo $?
Segmentation fault (core dumped)
139

-------------

Commit messages:
 - 8346193: Test runtime/ErrorHandling/TestDwarf.java fails build with clang17

Changes: https://git.openjdk.org/jdk/pull/22757/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22757&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346193
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22757/head:pull/22757

PR: https://git.openjdk.org/jdk/pull/22757

From azafari at openjdk.org  Mon Dec 16 10:09:46 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 16 Dec 2024 10:09:46 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree [v8]
In-Reply-To: <5tovgP_StYnZHV6kmjIyZWQboxlvMbS-NkaZW8kIVl8=.c9f9f1f2-d136-45c5-ab24-cc7bf36cbc16@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <WfF6MlyHiYq8BjnfbpcezOkJrCS7xEAjMb1epiygFH4=.2df7ed0c-1bbe-4ddc-bf27-33320a4e70b2@github.com>
 <lo5eSVeNnY0jtGq8EozEN2PZ85h1S7WLnZzXIAzxp0Y=.2695c475-c072-4dfa-888b-18cb14bef907@github.com>
 <RfIjTEurTj_uv-HsOORUcfvi-YcBjbRIPuIJM9J9n2Y=.fe982bbd-c29c-4652-965e-b6d332feebed@github.com>
 <xDR7XMBE2oKXnAJ6YrlTTATuJ1Kxi8g821CIepdDQtU=.204c132c-db57-4e8e-8a7c-87e7a75a7927@github.com>
 <S1qAIxpYogPn-wxPX4ZW2TDs3DEUlQTUBbjvYG_8dCs=.75cc3985-72d0-4fff-8c8c-5c9e604a2970@github.com>
 <g2118MI7I4x3jOuBOakTrfWs9ew7F6P6IzaYNfYvnkI=.ae4d00e5-402a-467b-af1a-905726d78662@github.com>
 <5tovgP_StYnZHV6kmjIyZWQboxlvMbS-NkaZW8kIVl8=.c9f9f1f2-d136-45c5-ab24-cc7bf36cbc16@github.com>
Message-ID: <poe835unrSwm_kD4oGOsWqrOFUGbHCI7szITkLmPK7s=.23865341-9c16-464d-ae0d-6b225854d2f4@github.com>

On Tue, 10 Dec 2024 14:46:34 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> Your point on `base` is correct. `prev.position` can be used instead.
>> 
>> I agree that there is ambiguity in the method name and its args. This method SHOULD be called for a `ReservedMemoryRegion [base, base + size)`. This is implicitly assumed. The signature as `visit_committed_regions(ReservedMemoryRegion& rgn, F func)` is more declarative then.
>> 
>> With the above assumption, if two committed regions are adjacent with different `MemTag`, they certainly belong to different `ReservedMemoryRegion`s, one for CDS with `mtClassShared` and another for stack with `mtThreadStack` MemTag. This method doesn't care the `MemTag`s because all the sub-regions within the `ReservedMemoryRegion [base, base + size)` are assumed to have the same `MemTag`.
>
> Ok that makes sense to me if `visit_committed_regions` is only ever called on a single ReservedRegion.  But if that assumption is true, then isn't it also true that we should never encounter two adjacent committed regions (they should already be coalesced)? 
> 
> So then maybe you don't need the extra handling such as tracking `comm_size` or checking `if (!curr.is_committed_begin())`. Maybe you could just directly have something like:
> 
> if (prev.is_valid() && prev.is_committed_begin()) {
>     CommittedMemoryRegion cmr((address) prev.position(), curr.distance_from(prev), st);
> ...
> }

Very good comment. Thanks. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1886533184

From stefank at openjdk.org  Mon Dec 16 10:39:17 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 10:39:17 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22712/files
  - new: https://git.openjdk.org/jdk/pull/22712/files/7b053084..c936bd44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22712&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22712&range=01-02

  Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22712/head:pull/22712

PR: https://git.openjdk.org/jdk/pull/22712

From stefank at openjdk.org  Mon Dec 16 10:39:17 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 10:39:17 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <LNu02wrDFHOXfRFGMvEcRXkU63l0oa1euAK27HQq9cw=.22f2eb3e-11d0-4272-906f-8ecc319b21cf@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>
 <LNu02wrDFHOXfRFGMvEcRXkU63l0oa1euAK27HQq9cw=.22f2eb3e-11d0-4272-906f-8ecc319b21cf@github.com>
Message-ID: <WCpMVbxiH3jtb5Q9Vuw4MLXo94xwvm2wojs81Hqa6hs=.c08ac4c4-4211-43cf-b683-a422f0a105be@github.com>

On Fri, 13 Dec 2024 18:42:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Thanks for this work.
> I found no problem in logic and replacements.

Thanks for reviewing!

> New files should have only one year in Copyright text:
> memoryReserver.?pp
> reservedSpace.?pp

I don't think this is correct. Code was copied from other files, so I transferred the copyright from those files. When I previously have asked around about this situation, the guidance I've been given the guidance that this is preferred over only using the current year.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2545208396

From fyang at openjdk.org  Mon Dec 16 10:45:38 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 16 Dec 2024 10:45:38 GMT
Subject: RFR: 8346235: RISC-V: Optimize bitwise AND with mask values [v3]
In-Reply-To: <mGRdr3ZThrwjTb7lk_lMBo2TqwA3D6vF4kezacfi9cU=.a21c1496-ac4a-4e7b-8193-f080e539fcc0@github.com>
References: <_F34FB5KUiuDBWK3h7IOK5N5sDamvk-_kiYp59pljtI=.6c27d267-b7fa-4e5f-ba11-167fd8542e18@github.com>
 <hEibU1qySCR8E-_DuTzRcF7bxS-kkm9HOuorTvNWBSI=.e81af3a4-06f2-4139-802a-c90b824c90bb@github.com>
 <mGRdr3ZThrwjTb7lk_lMBo2TqwA3D6vF4kezacfi9cU=.a21c1496-ac4a-4e7b-8193-f080e539fcc0@github.com>
Message-ID: <RsCkDk0pq5U1gK1zw-faUOdKqtOsqSMzaVQ_KYtqVoQ=.9a6db0c8-6c59-46b7-b29d-bb5ccffdf157@github.com>

On Mon, 16 Dec 2024 10:37:40 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Sorry, maybe you don't need to :)

I don't think reviewers without OpenJDK IDs will be listed in the git commit message. So we should be fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22752#issuecomment-2545229009

From mbaesken at openjdk.org  Mon Dec 16 12:45:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 12:45:54 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v5]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <vHGv_TCzR2kDTP-m-UCTmWckLLf_I1gK_FcE9fAWZMo=.28b9a379-f9a5-4a91-8767-c3a02435c8c4@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust output a bit, print xrun agents  too

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/fa960c86..48b04980

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=03-04

  Stats: 11 lines in 2 files changed: 4 ins; 4 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22706/head:pull/22706

PR: https://git.openjdk.org/jdk/pull/22706

From mbaesken at openjdk.org  Mon Dec 16 12:53:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 12:53:52 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v6]
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>

> We should output more information about the JVMTI agents in the hserr file.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust spaces in output

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22706/files
  - new: https://git.openjdk.org/jdk/pull/22706/files/48b04980..3bf026ad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22706&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22706/head:pull/22706

PR: https://git.openjdk.org/jdk/pull/22706

From mbaesken at openjdk.org  Mon Dec 16 13:10:12 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 13:10:12 GMT
Subject: RFR: 8342893: Highlight special values in hserr file printing [v6]
In-Reply-To: <gEpvEImd6tws0jOwuD__eYO-MVnaE1YLLZdR1v_pTYk=.d23898a2-d4b4-4e6c-9400-eb38a5635beb@github.com>
References: <gEpvEImd6tws0jOwuD__eYO-MVnaE1YLLZdR1v_pTYk=.d23898a2-d4b4-4e6c-9400-eb38a5635beb@github.com>
Message-ID: <gfcQhKAK2UJ3Q600ZANHykAjYsUerJSD8kfyARM5GN4=.f6cb3f83-34d0-4378-b151-ec22d0dcc3d0@github.com>

> There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations),

Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8342893
 - Merge master
 - Merge remote-tracking branch 'origin/master' into JDK-8342893
 - Introduce badResourceValueWord variable
 - compile error on Linux x86 and arm 32bit
 - do checks in debug
 - JDK-8342893

-------------

Changes: https://git.openjdk.org/jdk/pull/21811/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=05
  Stats: 224 lines in 10 files changed: 60 ins; 69 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/21811.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21811/head:pull/21811

PR: https://git.openjdk.org/jdk/pull/21811

From mbaesken at openjdk.org  Mon Dec 16 13:21:53 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 13:21:53 GMT
Subject: RFR: 8342893: Highlight special values in hserr file printing [v7]
In-Reply-To: <gEpvEImd6tws0jOwuD__eYO-MVnaE1YLLZdR1v_pTYk=.d23898a2-d4b4-4e6c-9400-eb38a5635beb@github.com>
References: <gEpvEImd6tws0jOwuD__eYO-MVnaE1YLLZdR1v_pTYk=.d23898a2-d4b4-4e6c-9400-eb38a5635beb@github.com>
Message-ID: <sCy_PgtzdKjFW8jM_-WnvNNyDM2YHG8_yuN6onCou6o=.464cabba-3596-4f70-96c0-1867e0de33fc@github.com>

> There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations),

Matthias Baesken has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into JDK-8342893
 - Merge remote-tracking branch 'origin/master' into JDK-8342893
 - Merge master
 - Merge remote-tracking branch 'origin/master' into JDK-8342893
 - Introduce badResourceValueWord variable
 - compile error on Linux x86 and arm 32bit
 - do checks in debug
 - JDK-8342893

-------------

Changes: https://git.openjdk.org/jdk/pull/21811/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21811&range=06
  Stats: 226 lines in 10 files changed: 61 ins; 69 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/21811.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21811/head:pull/21811

PR: https://git.openjdk.org/jdk/pull/21811

From mbaesken at openjdk.org  Mon Dec 16 13:21:54 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 13:21:54 GMT
Subject: Withdrawn: 8342893: Highlight special values in hserr file printing
In-Reply-To: <gEpvEImd6tws0jOwuD__eYO-MVnaE1YLLZdR1v_pTYk=.d23898a2-d4b4-4e6c-9400-eb38a5635beb@github.com>
References: <gEpvEImd6tws0jOwuD__eYO-MVnaE1YLLZdR1v_pTYk=.d23898a2-d4b4-4e6c-9400-eb38a5635beb@github.com>
Message-ID: <KPA2MOWPNBG4hzNVu2Ar_FRbCmhVvt5SFkBvj7-39o4=.741b93a1-85de-4328-b695-72d4f064d1d3@github.com>

On Thu, 31 Oct 2024 16:34:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are some special values indicating memory corruption or problematic states. Those should be highlighted / pointed out in some way when printing parts of the hserr / hsinfo file (like register values or locations),

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21811

From alanb at openjdk.org  Mon Dec 16 14:04:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Dec 2024 14:04:36 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
Message-ID: <sNCKLLotiA4UDvFJtexnPctLLrUxJ129hEvpRdKeYc4=.6913d51c-0d62-4550-bbf1-937ecba315d6@github.com>

On Fri, 13 Dec 2024 04:22:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
>> 
>> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
>> 
>> as inspection of the class sources will show the expected `permits` and `extends` clauses.
>> 
>> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
>> 
>> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
>> 
>> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
>> 
>> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
>> 
>> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the que
 ries - ...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update messages per feedback from Alan

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22703#pullrequestreview-2506274187

From alanb at openjdk.org  Mon Dec 16 14:04:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Dec 2024 14:04:37 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <n0VKLxdUwIRMnMDdBpPQ981TnQIkYTqSS_nTLJwQN7M=.e4755555-110f-4916-b8dc-dcae8ec2a322@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
 <x9JKnTjoSODICfjpURAGaaFmDwJY3P7QZ_7N8CD2rCs=.f82850ad-2128-4b75-838e-83bfbfd07a81@github.com>
 <n0VKLxdUwIRMnMDdBpPQ981TnQIkYTqSS_nTLJwQN7M=.e4755555-110f-4916-b8dc-dcae8ec2a322@github.com>
Message-ID: <qGbN3PTBBAnaQjqEo0pMKNbCdeWFga06YG0zveg9-dQ=.a4d11130-82ef-4ea3-8270-0571c835ac0d@github.com>

On Fri, 13 Dec 2024 21:01:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/oops/instanceKlass.cpp line 246:
>> 
>>> 244:              this->external_name(), this->package() != nullptr ? this->package()->name()->as_C_string() : "unnamed",
>>> 245:              this->module()->loader_data()->loader_name_and_id());
>>> 246:     log_trace(class, sealed)(" - %s", ss.as_string());
>> 
>> I'm a bit puzzled by the check so I'm not commenting on the log/exception message just yet.
>> 
>> If the super class (this) is in an unnamed module then the permitted subclass (k) must be in the same package.
>> 
>> If the super class is in a named module then permitted subclass can be in a different package but both need to be public in order.
>> 
>> I'm just trying to see how this maps to the check because it doesn't appear to take named vs. unnamed module into account, e.g. the subclass k might be public but in a different package of the same unnamed module. It's possible that I've mis-read this but it to goes to what the exception message is for these cases.
>
> Those are not the rules in JVMS (at least not obviously so). We get ICCE if any of the following are violated:
> 
> - The superclass is in a different run-time module than C (?5.3.6).
> - C does not have its ACC_PUBLIC flag set (?4.1) and the superclass is in a different run-time package than C (?5.3).
> - No entry in the classes array of the superclass's PermittedSubclasses attribute refers to a class or interface with the name N. 
> 
> We already determined both classes are in the same module, so now we just do the public/same-package check. Whether the module is un-named or not doesn't come into it.

Okay, I initially missed the difference between compile-time and run-time behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1886870750

From jbhateja at openjdk.org  Mon Dec 16 14:23:16 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Dec 2024 14:23:16 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Adding more test points

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/7cb694fa..3a6697e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=01-02

  Stats: 56 lines in 3 files changed: 54 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Mon Dec 16 14:23:16 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 16 Dec 2024 14:23:16 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <xCmBgJGY_IQMTbqFxlT3WKxI4ZQ9x4kgryTmUX8w3xU=.acbcba77-a4d3-4feb-87f2-2e12ea2477bc@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
 <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>
 <xCmBgJGY_IQMTbqFxlT3WKxI4ZQ9x4kgryTmUX8w3xU=.acbcba77-a4d3-4feb-87f2-2e12ea2477bc@github.com>
Message-ID: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>

On Mon, 16 Dec 2024 09:03:38 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> > > Can you quickly summarize what tests you have, and what they test?
> > 
> > 
> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
> 
> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.


Validations details:-

A) x86 backend changes
   - new assembler instruction
   - macro assembly routines. 
    Test point:-  test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java
         - This test is based on a testng framework and includes new DataProviders to generate test vectors.
         -  Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) 
B) GVN transformations:-
     -  Value Transforms
        Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
              -  Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch.
              -  It also tests special case scenarios for each operation as specified by Java language specification.
    -   identity Transforms
        Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
               -  Covers identity transformation for  ReinterpretS2HFNode,  DivHFNode
    -  idealization Transforms
        Test points:-  test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java
                                :-   test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
            - Contains test point for the following transform 
                         MulHF idealization i.e. MulHF * 2 => AddHF  
           -  Contains test point for the following transform
                         DivHF SRC ,  PoT(constant) =>  MulHF SRC * reciprocal (constant) 
            - Contains idealization test points for the following transform 
                   ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) =>
                           ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y)))

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2545754021

From mdoerr at openjdk.org  Mon Dec 16 14:29:38 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Dec 2024 14:29:38 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v6]
In-Reply-To: <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
Message-ID: <Q_sb6J3ISEIgzdyBWCrxFKRHC42WgcuXXMkB1p33X2w=.0c2bf0bb-2ad9-4c5e-9a47-f0e7bcb90fc3@github.com>

On Mon, 16 Dec 2024 12:53:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust spaces in output

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22706#pullrequestreview-2506344138

From mbaesken at openjdk.org  Mon Dec 16 14:35:41 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 14:35:41 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files [v6]
In-Reply-To: <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <AZg1rN303_YMlf0s--zBaPcdrdwB_iUMaarEPTZEkrk=.43f42a76-9fa4-4c5e-89e8-f378c77401ba@github.com>
Message-ID: <LyH4vwK3twWbE1WpUSSF4vkG9wNOlXPunvMmjkdFiz8=.42f16bc9-42df-4bfb-99a6-7deda9a6b494@github.com>

On Mon, 16 Dec 2024 12:53:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust spaces in output

Hi Martin, David, Thomas, thanks for the reviews !

(should we consider adding the JVMTI agent output to jcmd too as a separate command/option?  (but  not in this change) )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2545786871

From mdoerr at openjdk.org  Mon Dec 16 16:45:48 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Dec 2024 16:45:48 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <527a5a53-b33d-40c8-ae2f-9c97ac30102c@oracle.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <527a5a53-b33d-40c8-ae2f-9c97ac30102c@oracle.com>
Message-ID: <qgeA2eXkaOqycu4ifjSfj1v2oMEAHah3Bqt-uEreotw=.a57be82b-c1d8-43f0-bab7-bbc6438e5c29@github.com>

On Mon, 16 Dec 2024 16:28:29 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

> again what's the use case?

Assume a customer uses a tool like the async profiler and causes a JVM crash by doing that. A supporter looks at the hs_err file and wonders about what might have happened. Such a hint would be very helpful.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2546123339

From ccheung at openjdk.org  Mon Dec 16 16:57:51 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 16 Dec 2024 16:57:51 GMT
Subject: Integrated: 8345838: Remove the
 appcds/javaldr/AnonVmClassesDuringDump.java test
In-Reply-To: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>
References: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>
Message-ID: <xTfAodykYSoz3yPwb3dDL-xDAGzrBP6RKyTkEqh_7qw=.74fa2eec-fe49-47db-87e0-c2a59ba85c02@github.com>

On Sat, 14 Dec 2024 00:00:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this simple change for removing a test.
> 
> Testing:
> 
> - [x]      tier1
> - [x]      all CDS tests on linux-x64

This pull request has now been integrated.

Changeset: f8974ba7
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f8974ba718b3a631abafa8987d3fb98164fb35e5
Stats:     165 lines in 4 files changed: 0 ins; 165 del; 0 mod

8345838: Remove the appcds/javaldr/AnonVmClassesDuringDump.java test

Reviewed-by: iklam, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22747

From ccheung at openjdk.org  Mon Dec 16 16:57:50 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Mon, 16 Dec 2024 16:57:50 GMT
Subject: RFR: 8345838: Remove the
 appcds/javaldr/AnonVmClassesDuringDump.java test
In-Reply-To: <3DLPlPNoDQFfxVh5dzhsHwKvfOeAvjx6UQVATPPO5bM=.b7ed1a8b-6e0b-4592-9644-190b197403c4@github.com>
References: <1EcLU5WNrBgtRxbNTk3LPK7LK2gRwU27XTGt5DMghZs=.bca1366d-0b24-4824-80d2-231090438a98@github.com>
 <3DLPlPNoDQFfxVh5dzhsHwKvfOeAvjx6UQVATPPO5bM=.b7ed1a8b-6e0b-4592-9644-190b197403c4@github.com>
Message-ID: <4knwy68nRuEg84aFJwTY-na5VkJFWWGzN6UMOt-87dw=.9e70f0b9-584a-4eb9-8756-69837607f8d4@github.com>

On Sat, 14 Dec 2024 00:13:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this simple change for removing a test.
>> 
>> Testing:
>> 
>> - [x]      tier1
>> - [x]      all CDS tests on linux-x64
>
> Looks good.
> 
> This test was written before CDS had support for archived Lambda classes so it tried to assert that there are no Lambda classes in the CDS archive. Now we are storing Lambda classes in the archive, but there is a bug in the test so it couldn't find them (so the test is reporting "passed"). Since this test serves no purpose now, we should remove it.

Thanks @iklam, @dholmes-ora for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22747#issuecomment-2546148026

From cjplummer at openjdk.org  Mon Dec 16 17:29:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Dec 2024 17:29:35 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <PsTTQuovDQLsIOo5asQg4qz7Ye7JdXCHM3oIwdoVE4U=.7e237512-4ea4-4e99-bb61-b3869da1719a@github.com>

On Fri, 13 Dec 2024 20:50:37 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Are you going to add a test case?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2546224806

From coleenp at openjdk.org  Mon Dec 16 17:50:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 17:50:51 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v4]
In-Reply-To: <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
Message-ID: <-PbL_IeJhucqF87KZMJhkbf0BEVPSXErqzMUndM357Y=.1b101482-89a0-46a8-9a44-491d2f2d79ac@github.com>

On Fri, 13 Dec 2024 21:37:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed comment about compute_modifiers().

Thanks Fred and David.  If I make further changes to modifiers, it'll be in a different RFE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22618#issuecomment-2546263159

From fparain at openjdk.org  Mon Dec 16 17:50:51 2024
From: fparain at openjdk.org (Frederic Parain)
Date: Mon, 16 Dec 2024 17:50:51 GMT
Subject: RFR: 8345678: compute_modifiers should not be in create_mirror
 [v4]
In-Reply-To: <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
 <1LfGqjx-hIkmOSAV0uqd_sQMyo9IPhRH5KldKWhze-Q=.aa0a81da-f325-4f84-bb11-16c7e56b4aee@github.com>
Message-ID: <4LHbAZl6-8ShuvFIo4XCcx49xopBP3vbFFlrLiXlrsA=.f625ce76-9d9a-4eb5-91f7-15697a50b66e@github.com>

On Fri, 13 Dec 2024 21:37:55 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
>> 
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed comment about compute_modifiers().

Marked as reviewed by fparain (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22618#pullrequestreview-2506878474

From coleenp at openjdk.org  Mon Dec 16 17:50:52 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 17:50:52 GMT
Subject: Integrated: 8345678: compute_modifiers should not be in create_mirror
In-Reply-To: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
References: <80YO6Zo9vLKlbO_i09p7ioRBpkBeh-88uwbkjgNqqvY=.94e5600e-09db-40fa-b196-8b176d9bfb2b@github.com>
Message-ID: <cez9DLLN6m2jyY5KfWL-yCuU_McVUfpDfrulLB6q6d8=.0264aaa3-e268-485f-8200-27bbe9613251@github.com>

On Fri, 6 Dec 2024 22:00:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass and TypeArrayKlass are created.
> 
> Tested with jck:vm and tier1-4.

This pull request has now been integrated.

Changeset: d3359417
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3359417f3cb853b078041d07b8459b7b29a0a94
Stats:     39 lines in 8 files changed: 18 ins; 17 del; 4 mod

8345678: compute_modifiers should not be in create_mirror

Reviewed-by: fparain, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22618

From mbaesken at openjdk.org  Mon Dec 16 18:26:47 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 18:26:47 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <d80aa069-8b04-4d8e-ba46-94d73b7093b4@oracle.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <d80aa069-8b04-4d8e-ba46-94d73b7093b4@oracle.com>
Message-ID: <SElsGa-hkQj1Dk09H7wh-WArlN8mpUshLZINNxHo0kw=.11a07a41-e3d1-481e-88be-e59db7b459d5@github.com>

On Mon, 16 Dec 2024 18:11:29 GMT, Laurence Cable <larry.cable at oracle.com> wrote:

>  jcmd to emit agent info 

Okay, then avoid adding it to jcmd;  for hserr adding the info is more important.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2546336030

From mbaesken at openjdk.org  Mon Dec 16 18:26:47 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 16 Dec 2024 18:26:47 GMT
Subject: Integrated: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
Message-ID: <jzFB8BGV3rgc8_1Pqxjwnht23E2l2t7K7YTLVdT0BRI=.a7700910-1aa1-4ec5-bb56-a84879b9e217@github.com>

On Thu, 12 Dec 2024 09:42:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We should output more information about the JVMTI agents in the hserr file.

This pull request has now been integrated.

Changeset: c75b1d4b
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c75b1d4bf65d927e18b10ea6de263a331b78e13a
Stats:     40 lines in 4 files changed: 39 ins; 1 del; 0 mod

8346082: Output JVMTI agent information in hserr files

Reviewed-by: mdoerr, dholmes, stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/22706

From stuefe at openjdk.org  Mon Dec 16 18:41:46 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 16 Dec 2024 18:41:46 GMT
Subject: RFR: 8346082: Output JVMTI agent information in hserr files
In-Reply-To: <SElsGa-hkQj1Dk09H7wh-WArlN8mpUshLZINNxHo0kw=.11a07a41-e3d1-481e-88be-e59db7b459d5@github.com>
References: <69MCphnEzivblXTqytZaXciezdwQmvyLYrNGu9ZyYH8=.9f1563c4-45c9-41ca-8c67-09c3267011ca@github.com>
 <d80aa069-8b04-4d8e-ba46-94d73b7093b4@oracle.com>
 <SElsGa-hkQj1Dk09H7wh-WArlN8mpUshLZINNxHo0kw=.11a07a41-e3d1-481e-88be-e59db7b459d5@github.com>
Message-ID: <h2dcwfW-tdcqyYhsB_a4vy6IBKv-5OSW65ooy3VBqkw=.0d0ea0ee-921e-4ce1-a38c-d513f61ca447@github.com>

On Mon, 16 Dec 2024 18:22:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > jcmd to emit agent info
> 
> Okay, then let's avoid adding it to jcmd; for hserr/hsinfo adding the info is more important.
> 
> My idea was that currently we can do 'data dump' and 'load agents' with jcmd
> 
> ```
> JVMTI.agent_load
> JVMTI.data_dump
> ```
> 
> So for completeness, when you offer loading agents, it might be useful to be able to _**show**_ the current agents with the same tool jcmd. But on the other hand you are probably correct that this new option might not be used a lot so it is maybe not worth the effort.

Since we already have VM.info jcmd, which after your patch already shows jvmti info, a separate command would be redundant, no?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22706#issuecomment-2546367238

From darcy at openjdk.org  Mon Dec 16 18:45:39 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 16 Dec 2024 18:45:39 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
Message-ID: <wC8r8_HCDKkE79Wj1UBs5Sah5YVYOY57jlqyc3qfqow=.2b441f90-af39-4622-8cbd-fca750938eaf@github.com>

On Mon, 16 Dec 2024 14:23:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more test points

src/java.base/share/classes/jdk/internal/vm/vector/Float16Math.java line 35:

> 33:  * The class {@code Float16Math} constains intrinsic entry points corresponding
> 34:  * to scalar numeric operations defined in Float16 class.
> 35:  * @author

Please remove all author tags. We haven't used them in new code in the JDK for some time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1887325969

From darcy at openjdk.org  Mon Dec 16 18:50:42 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 16 Dec 2024 18:50:42 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
Message-ID: <Tebek-7-LFwPeELZTZnSWXGmKER0sVC7YiZm5kqfHM0=.d5ed31db-72bc-432c-9122-0a6eadbca57a@github.com>

On Mon, 16 Dec 2024 14:23:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more test points

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1415:

> 1413:         // double; not necessary to widen to double before the
> 1414:         // multiply.
> 1415:         short fa = float16ToRawShortBits(a);

The new implementations in fma and sqrt are comparatively long and obscure compared to the current versions. That might be the price of intrinsification, but it would be helpful to at least have a comment to the reader explaining why the more obvious code was not being used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1887333029

From vaivanov at openjdk.org  Mon Dec 16 19:18:44 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Mon, 16 Dec 2024 19:18:44 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <y3fTqfvJi8Yd9J0zhO19-CDX6CFSGjqhifF0Psc0N28=.42be9bbe-a060-4501-a4f8-72074536df9d@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

For the Xeon(R) 6972P scores for the specjvm::serial for current mainline looks as:
orig: 1T - 133.38 ops/m, 192T - 8950.13 ops/m
patched: 1T - 137.85 ops/m; 192T - 9745.03 ops/m

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2546435208

From duke at openjdk.org  Mon Dec 16 19:56:46 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 16 Dec 2024 19:56:46 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
Message-ID: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>

This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).

The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 


thread->register_thread_stack_with_NMT();
thread->initialize_thread_current();


in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 

To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 

I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.

I also removed the unused `_query_lock` variable in `MemTracker`.

Testing: 

- On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
- hotspot_nmt , gtest:VirtualSpace, tier1

-------------

Commit messages:
 - Fix concurrency issue. Add assertions. Update tests.
 - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"

Changes: https://git.openjdk.org/jdk/pull/22745/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346123
  Stats: 102 lines in 19 files changed: 54 ins; 24 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From coleenp at openjdk.org  Mon Dec 16 20:37:45 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 20:37:45 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags.
Message-ID: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>

Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

-------------

Commit messages:
 - 8346304: SA doesn't need a copy of getModifierFlags.

Changes: https://git.openjdk.org/jdk/pull/22772/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22772&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346304
  Stats: 78 lines in 5 files changed: 0 ins; 76 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22772.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22772/head:pull/22772

PR: https://git.openjdk.org/jdk/pull/22772

From sspitsyn at openjdk.org  Mon Dec 16 21:08:35 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 21:08:35 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags.
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <bwFL3Qhmkl5vSpGCJA_E5YmNkGlIu0ezxh9uVo13ZS8=.1577adcd-7193-4c64-b17c-2d99ec1fb31e@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Looks okay to me.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22772#pullrequestreview-2507360558

From sspitsyn at openjdk.org  Mon Dec 16 21:34:40 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 21:34:40 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <7kXOqKNvv9WRbSQfdbUBXqvFWx0dp2ZPEaRLPNtc31w=.b7b06c81-3f88-463f-a263-db0ace883eb3@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

Looks good to me.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22173#pullrequestreview-2507399979

From dholmes at openjdk.org  Mon Dec 16 21:36:08 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Dec 2024 21:36:08 GMT
Subject: RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java failed with
 'Cannot read the array length because "<local4>" is null'
Message-ID: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>

Please review this simple update to the strace tests that adds a check for a null entry.

Testing:
  - self
  - tiers 1-3 (sanity)

Thanks

-------------

Commit messages:
 - 8321818: vmTestbase/nsk/stress/strace/strace015.java failed with 'Cannot read the array length because "<local4>" is null'

Changes: https://git.openjdk.org/jdk/pull/22756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321818
  Stats: 53 lines in 9 files changed: 45 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22756/head:pull/22756

PR: https://git.openjdk.org/jdk/pull/22756

From kbarrett at openjdk.org  Mon Dec 16 22:28:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 16 Dec 2024 22:28:35 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>

On Fri, 13 Dec 2024 21:29:53 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Changes requested by kbarrett (Reviewer).

src/hotspot/share/nmt/memTracker.hpp line 281:

> 279:   // Same as MutexLocker but can be used during VM init while single threaded and before mutexes are ready or current thread has been assigned.
> 280:   // Performs no action during VM init.
> 281:   class NmtVirtualMemoryLocker: public ConditionalMutexLocker {

Should not derive from ConditionalMutexLocker - it's not designed to be a base class.
Either use has-a relationship, or just derive directly from MutexLockerImpl, since we don't need
the assert in ConditionalMutexLocker anyway.  And I'm surprised there isn't a constructor taking
the current thread, like all the other locker variants.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2507464880
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887650768

From coleenp at openjdk.org  Mon Dec 16 22:42:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 22:42:37 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
Message-ID: <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>

On Fri, 13 Dec 2024 04:22:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
>> 
>> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
>> 
>> as inspection of the class sources will show the expected `permits` and `extends` clauses.
>> 
>> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
>> 
>> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
>> 
>> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
>> 
>> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
>> 
>> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the que
 ries - ...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update messages per feedback from Alan

I just had a couple of stylistic requested changes.  The option you picked - passing in stringStream - is better than the other two options.  Also a question about ResourceMarks.

src/hotspot/share/classfile/classFileError.cpp line 97:

> 95: void ClassFileParser::classfile_icce_error(const char* msg,
> 96:                                            TRAPS) const {
> 97:   ResourceMark rm(THREAD);

I don't know what this ResourceMark does since you allocate resources in the caller, not here.

src/hotspot/share/classfile/classFileParser.cpp line 4068:

> 4066: 
> 4067:     if (super_ik->is_sealed()) {
> 4068:       stringStream ss;

Seems like the ResourceMark belongs here above the has_as_permitted_subclass call as the as_C_string() functions are called in there.  Not in the classfile_icce_error.

src/hotspot/share/classfile/moduleEntry.hpp line 191:

> 189:   const char* name_as_C_string() {
> 190:     return is_named() ? name()->as_C_string() : UNNAMED_MODULE;
> 191:   }

Maybe PackageEntry::name_as_C_string() should get the same helper function.

src/hotspot/share/oops/instanceKlass.cpp line 234:

> 232:              "and sealed class %s is in module '%s' with loader %s",
> 233:              k->external_name(), k->module()->name_as_C_string(), k->module()->loader_data()->loader_name_and_id(),
> 234:              this->external_name(), this->module()->name_as_C_string(), this->module()->loader_data()->loader_name_and_id());

I was going to suggest less verbosity by creating local variables above like this_loader_data and k_loader_data but maybe it's not that useful.  At any rate, could you put each of these long parameters on each line?

src/hotspot/share/oops/instanceKlass.cpp line 246:

> 244:              this->external_name(), this->package() != nullptr ? this->package()->name()->as_C_string() : "unnamed",
> 245:              this->module()->loader_data()->loader_name_and_id());
> 246:     log_trace(class, sealed)(" - %s", ss.as_string());

Same here - put each parameter on its own line.

-------------

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22703#pullrequestreview-2507486513
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887669639
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887668436
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887665877
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887664445
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887666645

From coleenp at openjdk.org  Mon Dec 16 22:43:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 22:43:35 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <y4grLaT32CZ0dlCUf__lCVyOCGfrv31mwVd8L9QVENg=.218d62b8-403c-48b1-908b-dee16fa57f84@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Do you agree it's trivial?  GHA almost complete/passed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2547015672

From sspitsyn at openjdk.org  Mon Dec 16 22:54:34 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 22:54:34 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases
In-Reply-To: <PsTTQuovDQLsIOo5asQg4qz7Ye7JdXCHM3oIwdoVE4U=.7e237512-4ea4-4e99-bb61-b3869da1719a@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <PsTTQuovDQLsIOo5asQg4qz7Ye7JdXCHM3oIwdoVE4U=.7e237512-4ea4-4e99-bb61-b3869da1719a@github.com>
Message-ID: <FgUm5T0lyw5haGPG94P6xpUWek0vOMSVyMNoqxS2DG0=.99e890ff-6f84-469c-80d0-d646bbfd0685@github.com>

On Mon, 16 Dec 2024 17:27:27 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> Are you going to add a test case?

You are right. While relying on the JDWP level of testing it is better to add a JVMTI test case for this fix as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2547039257

From sspitsyn at openjdk.org  Mon Dec 16 23:25:49 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 23:25:49 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  added extra check to post_method_exit_inner before clear_frame_pop to avoid assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/1080d282..b04f078f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=00-01

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

PR: https://git.openjdk.org/jdk/pull/22744

From sspitsyn at openjdk.org  Mon Dec 16 23:30:35 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 16 Dec 2024 23:30:35 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <y4grLaT32CZ0dlCUf__lCVyOCGfrv31mwVd8L9QVENg=.218d62b8-403c-48b1-908b-dee16fa57f84@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
 <y4grLaT32CZ0dlCUf__lCVyOCGfrv31mwVd8L9QVENg=.218d62b8-403c-48b1-908b-dee16fa57f84@github.com>
Message-ID: <iNTqcD6za043HtI7OIFMNa2Ze-9XkbajlBU4yUxcZYc=.e49809d6-beda-4c0e-937a-35e46f717e8e@github.com>

On Mon, 16 Dec 2024 22:41:23 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Do you agree it's trivial?

I'm not sure about it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2547114241

From coleenp at openjdk.org  Mon Dec 16 23:30:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Mon, 16 Dec 2024 23:30:36 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <f636GWo9Doff3fk7e6Hxdqxr06r_RhZwalwvcTMsI84=.89c989b5-72a8-436a-9bf0-d61aa1b748df@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

ok, I'll wait and see what @plummercj says.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2547117726

From cjplummer at openjdk.org  Mon Dec 16 23:59:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 16 Dec 2024 23:59:36 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <jOQq6p6fJQ8jZRtrNJOeE2Z_OZQijleQVyFaipOtcuI=.b53de9df-1cd5-48f8-b583-23b651ce0f24@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Looks good.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22772#pullrequestreview-2507583428

From lmesnik at openjdk.org  Mon Dec 16 23:59:37 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 16 Dec 2024 23:59:37 GMT
Subject: RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java failed
 with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
References: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
Message-ID: <XgbzMx7IaoryFw2dJCv7k6cSFCaefqvUPDxla5DQado=.7d77bd71-117c-4c95-a063-548d90204180@github.com>

On Mon, 16 Dec 2024 06:33:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the strace tests that adds a check for a null entry.
> 
> Testing:
>   - self
>   - tiers 1-3 (sanity)
> 
> Thanks

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22756#pullrequestreview-2507584365

From dholmes at openjdk.org  Tue Dec 17 00:14:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 00:14:47 GMT
Subject: RFR: 8346306: Unattached thread can cause crash during VM exit if it
 calls wait_if_vm_exited
Message-ID: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>

Please review this simple fix to account for unattached threads using RawMonitors which check if the VM has exited.

Testing:
 - tiers 1-3 (sanity)

Thanks

-------------

Commit messages:
 - 8346306: Unattached thread can cause crash during VM exit if it calls wait_if_vm_exited

Changes: https://git.openjdk.org/jdk/pull/22779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22779&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346306
  Stats: 13 lines in 2 files changed: 5 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22779/head:pull/22779

PR: https://git.openjdk.org/jdk/pull/22779

From psandoz at openjdk.org  Tue Dec 17 00:17:41 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 17 Dec 2024 00:17:41 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <Tebek-7-LFwPeELZTZnSWXGmKER0sVC7YiZm5kqfHM0=.d5ed31db-72bc-432c-9122-0a6eadbca57a@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <Tebek-7-LFwPeELZTZnSWXGmKER0sVC7YiZm5kqfHM0=.d5ed31db-72bc-432c-9122-0a6eadbca57a@github.com>
Message-ID: <G-ZyseOklWD77lkb-v3uPhCLI1IxNcLCw94j0Up31mU=.a9c654ef-a61d-4874-85c2-67b07b2ddea0@github.com>

On Mon, 16 Dec 2024 18:47:50 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more test points
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1415:
> 
>> 1413:         // double; not necessary to widen to double before the
>> 1414:         // multiply.
>> 1415:         short fa = float16ToRawShortBits(a);
> 
> The new implementations in fma and sqrt are comparatively long and obscure compared to the current versions. That might be the price of intrinsification, but it would be helpful to at least have a comment to the reader explaining why the more obvious code was not being used.

@jatin-bhateja could we change the intrinsic to declare the three Float16 values as additional parameters which are only ever passed to the lambda? I believe when intrinsic we will just drop those extra parameters.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1887733028

From dholmes at openjdk.org  Tue Dec 17 00:25:35 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 00:25:35 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
Message-ID: <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>

On Mon, 16 Dec 2024 22:15:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> src/hotspot/share/nmt/memTracker.hpp line 281:
> 
>> 279:   // Same as MutexLocker but can be used during VM init while single threaded and before mutexes are ready or current thread has been assigned.
>> 280:   // Performs no action during VM init.
>> 281:   class NmtVirtualMemoryLocker: public ConditionalMutexLocker {
> 
> Should not derive from ConditionalMutexLocker - it's not designed to be a base class.
> Either use has-a relationship, or just derive directly from MutexLockerImpl, since we don't need
> the assert in ConditionalMutexLocker anyway.  And I'm surprised there isn't a constructor taking
> the current thread, like all the other locker variants.

You should be able to use a ConditionalMutexLocker directly to handle this situation - it is one of the usecases that caused CML to be introduced.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887738017

From darcy at openjdk.org  Tue Dec 17 00:26:41 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 17 Dec 2024 00:26:41 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
Message-ID: <22UQZNt9TGIWmQ4rS7CAMSZg5zmxBeV71UiBIRd0t5E=.4db6389a-48aa-4f0c-b4fd-dd4e9a5238bd@github.com>

On Mon, 16 Dec 2024 14:23:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more test points

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 328:

> 326:     @ForceInline
> 327:     public static Float16 valueOf(float f) {
> 328:         short hf = floatToFloat16(f);

Does the VM need the explicit short variable here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1887738297

From dholmes at openjdk.org  Tue Dec 17 01:08:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 01:08:36 GMT
Subject: RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java failed
 with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <XgbzMx7IaoryFw2dJCv7k6cSFCaefqvUPDxla5DQado=.7d77bd71-117c-4c95-a063-548d90204180@github.com>
References: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
 <XgbzMx7IaoryFw2dJCv7k6cSFCaefqvUPDxla5DQado=.7d77bd71-117c-4c95-a063-548d90204180@github.com>
Message-ID: <caAvTFkHa9mhA41hBX7OQ_LfxjzSNNOwhPQEkeBogQU=.ddd8e791-a1d7-424e-b2e5-1ce812b81d40@github.com>

On Mon, 16 Dec 2024 23:57:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Please review this simple update to the strace tests that adds a check for a null entry.
>> 
>> Testing:
>>   - self
>>   - tiers 1-3 (sanity)
>> 
>> Thanks
>
> Marked as reviewed by lmesnik (Reviewer).

Thanks for the review @lmesnik !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22756#issuecomment-2547284445

From cjplummer at openjdk.org  Tue Dec 17 03:42:45 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 03:42:45 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
Message-ID: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>

On Mon, 16 Dec 2024 23:25:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added extra check to post_method_exit_inner before clear_frame_pop to avoid assert

All my debugger testing is passing now. A few comments inline.

src/hotspot/share/interpreter/interpreterRuntime.cpp line 580:

> 578:   // notify debugger of an exception catch
> 579:   // (this is good for exceptions caught in native methods as well)
> 580:   if (JvmtiExport::can_post_on_exceptions() || JvmtiExport::can_post_frame_pop()) {

This doesn't seem like it is related to ClearAllFramePops.

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1365:

> 1363:   if (ets->is_frame_pop(frame_number)) {
> 1364:     return JVMTI_ERROR_DUPLICATE;
> 1365:   }

It seems that this change is unrelated to ClearAllFramePops and perhaps deserves it's own CR, especially since it is a behavior change.

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:

> 261: #ifdef ASSERT
> 262:   Thread *current = Thread::current();
> 263: #endif

I think you can just get rid of these lines and inline the Thread.current() call below.

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 505:

> 503:   err = jvmti->NotifyFramePop(thread, 0);
> 504:   check_jvmti_status(jni, err, "VirtualThreadUnmount: error in JVMTI NotifyFramePop");
> 505: 

I assume this is needed as the result of your fix to return DUPLICATE for NotifyFramePop. Do we know that it always returns DUPLICATE for this particular call site?

-------------

Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2507765531
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887841702
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887845533
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887849471
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1887851575

From dholmes at openjdk.org  Tue Dec 17 04:01:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 04:01:40 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
 <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
Message-ID: <HPmqo6-xtzjFcUWevTncrF8hyp4PuTprWEvdIOPUHwM=.7dc4dce5-86d3-4bfc-9079-c3966a5e2e80@github.com>

On Mon, 16 Dec 2024 22:34:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update messages per feedback from Alan
>
> src/hotspot/share/classfile/moduleEntry.hpp line 191:
> 
>> 189:   const char* name_as_C_string() {
>> 190:     return is_named() ? name()->as_C_string() : UNNAMED_MODULE;
>> 191:   }
> 
> Maybe PackageEntry::name_as_C_string() should get the same helper function.

Can't do that. The un-named package means you have no PackageEntry and package() returns null.

> src/hotspot/share/oops/instanceKlass.cpp line 234:
> 
>> 232:              "and sealed class %s is in module '%s' with loader %s",
>> 233:              k->external_name(), k->module()->name_as_C_string(), k->module()->loader_data()->loader_name_and_id(),
>> 234:              this->external_name(), this->module()->name_as_C_string(), this->module()->loader_data()->loader_name_and_id());
> 
> I was going to suggest less verbosity by creating local variables above like this_loader_data and k_loader_data but maybe it's not that useful.  At any rate, could you put each of these long parameters on each line?

Done

> src/hotspot/share/oops/instanceKlass.cpp line 246:
> 
>> 244:              this->external_name(), this->package() != nullptr ? this->package()->name()->as_C_string() : "unnamed",
>> 245:              this->module()->loader_data()->loader_name_and_id());
>> 246:     log_trace(class, sealed)(" - %s", ss.as_string());
> 
> Same here - put each parameter on its own line.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887861438
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887861118
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887861633

From kbarrett at openjdk.org  Tue Dec 17 04:03:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 17 Dec 2024 04:03:42 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
Message-ID: <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>

On Tue, 17 Dec 2024 00:23:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/nmt/memTracker.hpp line 281:
>> 
>>> 279:   // Same as MutexLocker but can be used during VM init while single threaded and before mutexes are ready or current thread has been assigned.
>>> 280:   // Performs no action during VM init.
>>> 281:   class NmtVirtualMemoryLocker: public ConditionalMutexLocker {
>> 
>> Should not derive from ConditionalMutexLocker - it's not designed to be a base class.
>> Either use has-a relationship, or just derive directly from MutexLockerImpl, since we don't need
>> the assert in ConditionalMutexLocker anyway.  And I'm surprised there isn't a constructor taking
>> the current thread, like all the other locker variants.
>
> You should be able to use a ConditionalMutexLocker directly to handle this situation - it is one of the usecases that caused CML to be introduced.

CML could perhaps be used has-a (though that might be messy), but should not
be used is-a.  One of the basic rules for base classes is to have either a
public virtual destructor (don't do that here) or a non-public non-virtual
destructor, to prevent accidental slicing.  MutexLockerImpl has that - it was
designed to be a base class.  CML doesn't - it was not designed to be a base
class.  (There is a common (though not universal) opinion that classes should
either be base or concrete classes, not both.) I know we violate this rule all
over the place; that doesn't mean we should do so here.

But really, there's no benefit to using CML here. Deriving from
MutexLockerImpl is about the same number of characters, and seems clearer to
me because it's more direct.


class NmtVirtualMemoryLocker : public MutexLockerImpl {
public:
  NmtVirtualMemoryLocker()
    : MutexLockerImpl(_done_bootstrap ? NmtVirtualMemory_lock : nullptr,
                      Mutex::_no_safepoint_check_flag)
  {}
}


Related, I just noticed that MutexLockerImpl is copyable, but shouldn't be.
(I remember a discussion a long time ago about whether StackObj should be
noncopyable, which foundered on a combination of some significant number of
existing uses that violated that restriction, along with disagreement about
the meaning of deriving from StackObj.  So we're not getting noncopyable from
there.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887863262

From dholmes at openjdk.org  Tue Dec 17 04:04:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 04:04:39 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
 <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
Message-ID: <-u9QaEszmgT0tPCkoqRzVz8gSSiTR8kjBdCIfRPXRLM=.f33eb117-3ca7-467e-89cc-fcaed2ee2b5c@github.com>

On Mon, 16 Dec 2024 22:39:33 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update messages per feedback from Alan
>
> src/hotspot/share/classfile/classFileError.cpp line 97:
> 
>> 95: void ClassFileParser::classfile_icce_error(const char* msg,
>> 96:                                            TRAPS) const {
>> 97:   ResourceMark rm(THREAD);
> 
> I don't know what this ResourceMark does since you allocate resources in the caller, not here.

It follows the same pattern as all the other throwing methods - the RM is for the `_class_name->as_C_string()`. I think you may be right that it is the callers that should have the RM. Can I file a follow up RFE to look at that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887863344

From dholmes at openjdk.org  Tue Dec 17 04:10:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 04:10:38 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
 <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
Message-ID: <DNEwN8bUC_yGwin2IJbkuh0RE3byiWoSYFysG3EGWNo=.015962b5-1326-4ef0-9e09-de5f2e689876@github.com>

On Mon, 16 Dec 2024 22:39:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update messages per feedback from Alan
>
> I just had a couple of stylistic requested changes.  The option you picked - passing in stringStream - is better than the other two options.  Also a question about ResourceMarks.

Thanks for looking at this @coleenp !

> src/hotspot/share/classfile/classFileParser.cpp line 4068:
> 
>> 4066: 
>> 4067:     if (super_ik->is_sealed()) {
>> 4068:       stringStream ss;
> 
> Seems like the ResourceMark belongs here above the has_as_permitted_subclass call as the as_C_string() functions are called in there.  Not in the classfile_icce_error.

Ah yes, in this case that is true. Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22703#issuecomment-2547464179
PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887866863

From dholmes at openjdk.org  Tue Dec 17 04:10:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 04:10:39 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <-u9QaEszmgT0tPCkoqRzVz8gSSiTR8kjBdCIfRPXRLM=.f33eb117-3ca7-467e-89cc-fcaed2ee2b5c@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
 <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
 <-u9QaEszmgT0tPCkoqRzVz8gSSiTR8kjBdCIfRPXRLM=.f33eb117-3ca7-467e-89cc-fcaed2ee2b5c@github.com>
Message-ID: <oVtcA_bH5pES6QRvuQQZAraGhWwYJOVQlviAJ0V0uag=.29bcdba0-1484-43c3-8954-9c7c4cce6aff@github.com>

On Tue, 17 Dec 2024 04:01:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/classfile/classFileError.cpp line 97:
>> 
>>> 95: void ClassFileParser::classfile_icce_error(const char* msg,
>>> 96:                                            TRAPS) const {
>>> 97:   ResourceMark rm(THREAD);
>> 
>> I don't know what this ResourceMark does since you allocate resources in the caller, not here.
>
> It follows the same pattern as all the other throwing methods - the RM is for the `_class_name->as_C_string()`. I think you may be right that it is the callers that should have the RM. Can I file a follow up RFE to look at that?

Now I see what you mean. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1887866968

From dholmes at openjdk.org  Tue Dec 17 04:19:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 04:19:23 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v5]
In-Reply-To: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
Message-ID: <nQDwn2PlcSzhILUy5kBwLeLcx9AUxuysRAPDOZvJJ-4=.e02c92c3-b457-4724-9e9f-7c6f9dfc0dfe@github.com>

> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
> 
> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
> 
> as inspection of the class sources will show the expected `permits` and `extends` clauses.
> 
> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
> 
> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
> 
> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
> 
> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
> 
> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the quer
 ies - but we could do it for conveni...

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Coleen's suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22703/files
  - new: https://git.openjdk.org/jdk/pull/22703/files/9f3c618d..e7a826d7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22703&range=03-04

  Stats: 14 lines in 3 files changed: 9 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22703/head:pull/22703

PR: https://git.openjdk.org/jdk/pull/22703

From dholmes at openjdk.org  Tue Dec 17 07:00:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 07:00:48 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
 <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
Message-ID: <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>

On Tue, 17 Dec 2024 04:01:26 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> You should be able to use a ConditionalMutexLocker directly to handle this situation - it is one of the usecases that caused CML to be introduced.
>
> CML could perhaps be used has-a (though that might be messy), but should not
> be used is-a.  One of the basic rules for base classes is to have either a
> public virtual destructor (don't do that here) or a non-public non-virtual
> destructor, to prevent accidental slicing.  MutexLockerImpl has that - it was
> designed to be a base class.  CML doesn't - it was not designed to be a base
> class.  (There is a common (though not universal) opinion that classes should
> either be base or concrete classes, not both.) I know we violate this rule all
> over the place; that doesn't mean we should do so here.
> 
> But really, there's no benefit to using CML here. Deriving from
> MutexLockerImpl is about the same number of characters, and seems clearer to
> me because it's more direct.
> 
> 
> class NmtVirtualMemoryLocker : public MutexLockerImpl {
> public:
>   NmtVirtualMemoryLocker()
>     : MutexLockerImpl(_done_bootstrap ? NmtVirtualMemory_lock : nullptr,
>                       Mutex::_no_safepoint_check_flag)
>   {}
> }
> 
> 
> Related, I just noticed that MutexLockerImpl is copyable, but shouldn't be.
> (I remember a discussion a long time ago about whether StackObj should be
> noncopyable, which foundered on a combination of some significant number of
> existing uses that violated that restriction, along with disagreement about
> the meaning of deriving from StackObj.  So we're not getting noncopyable from
> there.)

`MutexLockerImpl` was not intended for external subclassing, but as the internal base class for `MutexLocker`, and `ConditionalMutexLocker`.  CML was provided for exactly this kind of situation: conditionally locking the mutex.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1887992575

From dholmes at openjdk.org  Tue Dec 17 07:09:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Dec 2024 07:09:39 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <qyEGVBwEWUAvOsStjROe2_eid-ouQ7fUtBv2HoIQLlg=.511ef1fd-d622-4ab8-89cb-7faf015aa6bb@github.com>

On Mon, 16 Dec 2024 09:53:08 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

src/hotspot/share/runtime/frame.cpp line 1166:

> 1164:   // simulate GC crash here to dump java thread in error report
> 1165:   if (CrashGCForDumpingJavaThread) {
> 1166:     volatile char *t = nullptr; // Use volatile modifier to make clang avoid 'dead code' elimination

Suggestion:

    volatile char* t = nullptr; // Use volatile to prevent compiler from optimising away the store

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1887999830

From epeter at openjdk.org  Tue Dec 17 07:50:04 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 07:50:04 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
Message-ID: <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>

On Mon, 16 Dec 2024 14:23:16 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding more test points

@jatin-bhateja I took 1h to go over this change. I left 15 comments, probably some of them you can just answer by a quick explanation / pointing to the relevant test.

src/hotspot/share/opto/convertnode.cpp line 282:

> 280:       return new ReinterpretHF2SNode(binop);
> 281:     }
> 282:   }

Where are the constant folding tests for this?

src/hotspot/share/opto/convertnode.cpp line 960:

> 958:   }
> 959:   return TypeInt::SHORT;
> 960: }

Do we have tests for these constant folding operations?

src/hotspot/share/opto/divnode.cpp line 815:

> 813:       !g_isnan(t1->getf()) && g_isfinite(t1->getf()) && t1->getf() != 0.0) { // could be negative ZERO or NaN
> 814:     return TypeH::ONE;
> 815:   }

Do we cover all cases here?

src/hotspot/share/opto/divnode.cpp line 821:

> 819:   }
> 820: 
> 821:   // If divisor is a constant and not zero, divide them numbers

Suggestion:

  // If divisor is a constant and not zero, divide the numbers

src/hotspot/share/opto/divnode.cpp line 826:

> 824:       t2->getf() != 0.0)  {
> 825:     // could be negative zero
> 826:     return TypeH::make(t1->getf()/t2->getf());

Suggestion:

    return TypeH::make(t1->getf() / t2->getf());

src/hotspot/share/opto/divnode.cpp line 840:

> 838:   if (g_isnan(t1->getf()) || g_isnan(t2->getf())) {
> 839:     return TypeH::make(NAN);
> 840:   }

I'm a little confused here. We are working with nodes that have type Float16, but we are asking for Float constants here. Why is that, how does it work?

src/hotspot/share/opto/subnode.cpp line 566:

> 564:     return t1;
> 565:   }
> 566:   else if(g_isnan(t2->getf())) {

General question: why are you using `getf` and not `geth` all over the code?

src/hotspot/share/opto/type.cpp line 1465:

> 1463: //------------------------------meet-------------------------------------------
> 1464: // Compute the MEET of two types.  It returns a new Type object.
> 1465: const Type *TypeH::xmeet( const Type *t ) const {

Please write `TypeH*` and not `TypeH *`

src/hotspot/share/opto/type.cpp line 1530:

> 1528: uint TypeH::hash(void) const {
> 1529:   return *(uint*)(&_f);
> 1530: }

I just saw that `_f` is a `short`, which I think is 16 bits, right? And the cast to `uint` would mean we take 32 bits. That looks a bit off, but maybe it is not. Can you explain, and maybe also put a comment in the code for that?

test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 275:

> 273:     @IR(counts = {IRNode.ADD_HF, " 0 ", IRNode.REINTERPRET_S2HF, " 0 ", IRNode.REINTERPRET_HF2S, " 0 "},
> 274:         applyIfCPUFeature = {"avx512_fp16", "true"})
> 275:     public void testAddConstantFolding() {

Ok, this is great. I'm missing some cases that check correct rounding. For that, it might be good to have one example with random constants, so 2 random Float16 values. You can generate them in static context, and also compute the result in static context, so it should be evaluated in the interpreter. That way, we can compare the result of interpreter to compiled code.

Do that for all operations.

test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 421:

> 419: 
> 420:         assertResult(divide(valueOf(2.0f), valueOf(2.0f)).floatValue(), 1.0f, "testDivConstantFolding");
> 421:     }

What about cases like `x/x`, where `x` is a variable, and then feed in all sorts of values, including NaN. I think there we must ensure that it does not fold to `1`. Could be a separate IR test.

But also `x/x` with all sorts of constants is relevant. It would test this section in the `Ideal` code:

  // x/x == 1, we ignore 0/0.
  // Note: if t1 and t2 are zero then result is NaN (JVMS page 213)
  // Does not work for variables because of NaN's
  if (in(1) == in(2) && t1->base() == Type::HalfFloatCon &&
      !g_isnan(t1->getf()) && g_isfinite(t1->getf()) && t1->getf() != 0.0) { // could be negative ZERO or NaN
    return TypeH::ONE;
  }

test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 494:

> 492:         assertResult(fma(valueOf(1.0f), valueOf(2.0f), valueOf(3.0f)).floatValue(), 1.0f * 2.0f + 3.0f, "testFMAConstantFolding");
> 493:     }
> 494: }

I am missing constant folding tests with `shortBitsToFloat16` etc.

-------------

Changes requested by epeter (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22754#pullrequestreview-2508020252
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888008209
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888009160
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888012154
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888027070
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888027339
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888038360
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888030240
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888013140
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888017396
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888005513
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888026278
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888021315

From epeter at openjdk.org  Tue Dec 17 07:50:04 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 07:50:04 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
Message-ID: <DiFSbHS-FHHYMWH8ukFlm8meO3bMSbt9EkQbM-MJTyQ=.fb7a9050-fa97-4d73-b4e8-862e511c2280@github.com>

On Tue, 17 Dec 2024 07:16:37 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more test points
>
> src/hotspot/share/opto/convertnode.cpp line 960:
> 
>> 958:   }
>> 959:   return TypeInt::SHORT;
>> 960: }
> 
> Do we have tests for these constant folding operations?

We would need all sorts of conversion with Float16 <-> short. With Float16 constant and variable values. And also with short constant and variable values.

> src/hotspot/share/opto/divnode.cpp line 826:
> 
>> 824:       t2->getf() != 0.0)  {
>> 825:     // could be negative zero
>> 826:     return TypeH::make(t1->getf()/t2->getf());
> 
> Suggestion:
> 
>     return TypeH::make(t1->getf() / t2->getf());

Are we sure that the rounding behaviour of float is the correct behaviour for Float16? I would like to see some examples where rounding matters.

> src/hotspot/share/opto/type.cpp line 1465:
> 
>> 1463: //------------------------------meet-------------------------------------------
>> 1464: // Compute the MEET of two types.  It returns a new Type object.
>> 1465: const Type *TypeH::xmeet( const Type *t ) const {
> 
> Please write `TypeH*` and not `TypeH *`

Do that everywhere in the code that you touch, except it breaks strongly with immediately surrounding code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888015077
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888033031
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888018364

From jbhateja at openjdk.org  Tue Dec 17 08:03:07 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Dec 2024 08:03:07 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <G-ZyseOklWD77lkb-v3uPhCLI1IxNcLCw94j0Up31mU=.a9c654ef-a61d-4874-85c2-67b07b2ddea0@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <Tebek-7-LFwPeELZTZnSWXGmKER0sVC7YiZm5kqfHM0=.d5ed31db-72bc-432c-9122-0a6eadbca57a@github.com>
 <G-ZyseOklWD77lkb-v3uPhCLI1IxNcLCw94j0Up31mU=.a9c654ef-a61d-4874-85c2-67b07b2ddea0@github.com>
Message-ID: <3ICo3LtSL6Lhx3AdPYpeUccUCYcMi25lqGb9pNsyEt0=.0c53bb8b-5387-46be-8790-f49023fd9230@github.com>

On Tue, 17 Dec 2024 00:14:39 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1415:
>> 
>>> 1413:         // double; not necessary to widen to double before the
>>> 1414:         // multiply.
>>> 1415:         short fa = float16ToRawShortBits(a);
>> 
>> The new implementations in fma and sqrt are comparatively long and obscure compared to the current versions. That might be the price of intrinsification, but it would be helpful to at least have a comment to the reader explaining why the more obvious code was not being used.
>
> @jatin-bhateja could we change the intrinsic to declare the three Float16 values as additional parameters which are only ever passed to the lambda? I believe when intrinsic we will just drop those extra parameters.

Our intent here is to explicitly unbox the float16 values in Java code to avoid complexifying unboxing by C2. In that case, the VM needs to be aware of the Float16 class and record its field offsets, as it did for the [VectorPayload class.](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/classfile/javaClasses.cpp#L5065) 

I have re-structured the code to remove unnecessary obfuscation introduced as a side effect of intrinsification. Let me know if we need to refine it further.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888053509

From jbhateja at openjdk.org  Tue Dec 17 08:03:07 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Dec 2024 08:03:07 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v4]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <_Xvwu4MCoc_tveXX-iDMB5nW9UNpEj3mZdOvlGDMVd0=.b4d97187-de30-4e95-a036-75f69ad5db3f@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Fixing obfuscation due to intrinsic entries

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/3a6697e3..246cb270

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=02-03

  Stats: 30 lines in 2 files changed: 13 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From stefank at openjdk.org  Tue Dec 17 09:57:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 17 Dec 2024 09:57:39 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <9vUxbGkHbRb3E6VJ75e_RdkjfqQPAcnXQogLbNu0qgc=.75e18df2-1ee7-455f-9242-818ac679d0b3@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

@jdksjolen @afshin-zafari Are you OK with me pushing the code as it is right now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2547992385

From stefank at openjdk.org  Tue Dec 17 09:57:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 17 Dec 2024 09:57:39 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <0DIQXJDLaUvtZOhwOROXFP4YPhDIfTEJZ1v7ib-_6_s=.3c84c791-d338-4e18-a4ba-a7f0a2b984e2@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
 <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
 <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>
 <0DIQXJDLaUvtZOhwOROXFP4YPhDIfTEJZ1v7ib-_6_s=.3c84c791-d338-4e18-a4ba-a7f0a2b984e2@github.com>
Message-ID: <EE5SvoPGjvyriMMJ8-tLrfOiYXxG60NRUEn7o2Rwxjg=.f662de8c-141d-4260-8f16-dc2f0767bcd9@github.com>

On Fri, 13 Dec 2024 13:36:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> My reasoning was that MemoryReserver does not have the ownership of the ReservedSpace instance, so I didn't want it to be the one clearing the members. If others feel the same way as you do, then I would prefer to add a function release_and_clear to make it clearer (:)) what's going on.
>
> `release_and_clear`does sound clearer :)

My preference is to stay with the current proposal and let code that requested reserve memory decide if and when the ReservedSpace should be cleared. I think it would be an easy thing to reevaluate in another RFE if we change our minds later on.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1888222021

From jsjolen at openjdk.org  Tue Dec 17 10:07:42 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 17 Dec 2024 10:07:42 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <2YJoDesdWv0qP6-wF0SEdUpK8EXoE3-c8PB_puxNEhw=.bd0b4600-d2b4-440c-b20c-218252bf46a3@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

I am okay with this, I wanted to defer an approval to see whether others would chime in. Thank you for this work.

-------------

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22712#pullrequestreview-2508408235

From mli at openjdk.org  Tue Dec 17 11:03:40 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 17 Dec 2024 11:03:40 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <FpkeIwcZ9nkepIbw-S5JLEmg166CgImqw5_OpYR9pBo=.a7c43da3-265f-4df7-a84c-17bf3004e1e7@github.com>

On Mon, 16 Dec 2024 09:53:08 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

Would `ShouldNotReachHere();` be more secure? although the function name seems strange to be used here. 
Or maybe there are other APIs in hotspot to ensure a crash?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22757#pullrequestreview-2508552776

From azafari at openjdk.org  Tue Dec 17 11:07:45 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 17 Dec 2024 11:07:45 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <glB1Z0sSyCh0gLVLYew9E9b2NwH7Biqp55FIt-yX5d8=.e071e756-b1ee-4e11-9ad5-06fa5519448a@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Thanks again for this work. No comments.

-------------

Marked as reviewed by azafari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22712#pullrequestreview-2508563728

From jbhateja at openjdk.org  Tue Dec 17 11:09:09 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Dec 2024 11:09:09 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v5]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <D_4mEsBrH8liSvrR0lAh7Skzgo0mcPwUdESsNS5MWvw=.04fe9276-82e7-49c1-b51f-7fc512cbd3a4@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Addressing review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/246cb270..ec0834a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=03-04

  Stats: 28 lines in 4 files changed: 6 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Tue Dec 17 11:09:11 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Dec 2024 11:09:11 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <DiFSbHS-FHHYMWH8ukFlm8meO3bMSbt9EkQbM-MJTyQ=.fb7a9050-fa97-4d73-b4e8-862e511c2280@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <DiFSbHS-FHHYMWH8ukFlm8meO3bMSbt9EkQbM-MJTyQ=.fb7a9050-fa97-4d73-b4e8-862e511c2280@github.com>
Message-ID: <PfwB5m-a0q5OUzeEqXCaw8qJU-aS7PQjwmcX8NAvgG8=.b94cf242-6b12-46dd-b944-6c86ff3487d1@github.com>

On Tue, 17 Dec 2024 07:22:45 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> src/hotspot/share/opto/convertnode.cpp line 960:
>> 
>>> 958:   }
>>> 959:   return TypeInt::SHORT;
>>> 960: }
>> 
>> Do we have tests for these constant folding operations?
>
> We would need all sorts of conversion with Float16 <-> short. With Float16 constant and variable values. And also with short constant and variable values.

Yes, there are multiple test points in newly added test which receive floating-point constant which goes through following IR logic before being constant folded 
ConF -> ConvF2HF -> ReinterpretS2HF

>> src/hotspot/share/opto/divnode.cpp line 826:
>> 
>>> 824:       t2->getf() != 0.0)  {
>>> 825:     // could be negative zero
>>> 826:     return TypeH::make(t1->getf()/t2->getf());
>> 
>> Suggestion:
>> 
>>     return TypeH::make(t1->getf() / t2->getf());
>
> Are we sure that the rounding behaviour of float is the correct behaviour for Float16? I would like to see some examples where rounding matters.

FP16 has 11 bits precision and FP32 has 24 bit precision, thus as per [2P rule ](https://dl.acm.org/doi/pdf/10.1145/221332.221334) the operation is innocuous to double rounding effects. In addition, fall back implementation of Float16.divide also takes the same route of performing the operation at FP32 granularity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888331298
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888330385

From jbhateja at openjdk.org  Tue Dec 17 11:09:10 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 17 Dec 2024 11:09:10 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
Message-ID: <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>

On Tue, 17 Dec 2024 07:15:35 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding more test points
>
> src/hotspot/share/opto/convertnode.cpp line 282:
> 
>> 280:       return new ReinterpretHF2SNode(binop);
>> 281:     }
>> 282:   }
> 
> Where are the constant folding tests for this?

This is the core idealization logic which infers FP16 IR. Every test point added in the test points added in test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java verifies this.

> src/hotspot/share/opto/divnode.cpp line 815:
> 
>> 813:       !g_isnan(t1->getf()) && g_isfinite(t1->getf()) && t1->getf() != 0.0) { // could be negative ZERO or NaN
>> 814:     return TypeH::ONE;
>> 815:   }
> 
> Do we cover all cases here?

Please refer to test point at https://github.com/openjdk/jdk/pull/22754/files#diff-3f8786f9f62662eda4b4a5c76c01fa04534c94d870d496501bfc20434ad45579R419

> src/hotspot/share/opto/divnode.cpp line 840:
> 
>> 838:   if (g_isnan(t1->getf()) || g_isnan(t2->getf())) {
>> 839:     return TypeH::make(NAN);
>> 840:   }
> 
> I'm a little confused here. We are working with nodes that have type Float16, but we are asking for Float constants here. Why is that, how does it work?

Please refer to PhaseIGVN::transform, we create constant IR for singleton types. 
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/phaseX.cpp#L721

> src/hotspot/share/opto/subnode.cpp line 566:
> 
>> 564:     return t1;
>> 565:   }
>> 566:   else if(g_isnan(t2->getf())) {
> 
> General question: why are you using `getf` and not `geth` all over the code?

getf is a routine that performs half float to float conversion for TypeH.

> src/hotspot/share/opto/type.cpp line 1530:
> 
>> 1528: uint TypeH::hash(void) const {
>> 1529:   return *(uint*)(&_f);
>> 1530: }
> 
> I just saw that `_f` is a `short`, which I think is 16 bits, right? And the cast to `uint` would mean we take 32 bits. That looks a bit off, but maybe it is not. Can you explain, and maybe also put a comment in the code for that?

This is to comply with Node::hash signature which returns uint value

> test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 275:
> 
>> 273:     @IR(counts = {IRNode.ADD_HF, " 0 ", IRNode.REINTERPRET_S2HF, " 0 ", IRNode.REINTERPRET_HF2S, " 0 "},
>> 274:         applyIfCPUFeature = {"avx512_fp16", "true"})
>> 275:     public void testAddConstantFolding() {
> 
> Ok, this is great. I'm missing some cases that check correct rounding. For that, it might be good to have one example with random constants, so 2 random Float16 values. You can generate them in static context, and also compute the result in static context, so it should be evaluated in the interpreter. That way, we can compare the result of interpreter to compiled code.
> 
> Do that for all operations.

Hey @eme64 , constant folding is done at FP32 granularity, so we first upcast FP16 to FP32 values using hf2f runtime helper, operate over FP32 values and then down cast it back to FP16 value using f2hf helper.  Thus both compiler value transformations and interpreter use the same runtime helper underneath.

Fallback implementation of each Float16 API is using Float.floatToFloat16 and Float.floa16ToFloat routines which are intrinsified at [interpreter level.](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/templateInterpreterGenerator.cpp#L488), these interpreter intrinsic invokes same leaf level macro assembly routine flt16_to_flt which is also called though runtime helpers. 

So it may not add much value to do interpreter vs compiler comparison in these cases.

> test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 421:
> 
>> 419: 
>> 420:         assertResult(divide(valueOf(2.0f), valueOf(2.0f)).floatValue(), 1.0f, "testDivConstantFolding");
>> 421:     }
> 
> What about cases like `x/x`, where `x` is a variable, and then feed in all sorts of values, including NaN. I think there we must ensure that it does not fold to `1`. Could be a separate IR test.
> 
> But also `x/x` with all sorts of constants is relevant. It would test this section in the `Ideal` code:
> 
>   // x/x == 1, we ignore 0/0.
>   // Note: if t1 and t2 are zero then result is NaN (JVMS page 213)
>   // Does not work for variables because of NaN's
>   if (in(1) == in(2) && t1->base() == Type::HalfFloatCon &&
>       !g_isnan(t1->getf()) && g_isfinite(t1->getf()) && t1->getf() != 0.0) { // could be negative ZERO or NaN
>     return TypeH::ONE;
>   }

The above predicate filters out the NaN dividend case. For the variable argument, we rely on the x86 floating point ISA specification, which complies with the IEEE 754 floating point specification.

Please refer to section 4.8.3.5 Operating on SNaNs and QNaNs for Intel Software Development Manual for more details. 

Note: Float16 to float conversion helpers preserve the NaN significand bits, but Java only deals in QNaN values.  I am adding a few test points for signaling NaN.

> test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 494:
> 
>> 492:         assertResult(fma(valueOf(1.0f), valueOf(2.0f), valueOf(3.0f)).floatValue(), 1.0f * 2.0f + 3.0f, "testFMAConstantFolding");
>> 493:     }
>> 494: }
> 
> I am missing constant folding tests with `shortBitsToFloat16` etc.

Added a few test points for the same

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888331413
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888331196
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888330121
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888330274
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888331089
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888331480
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888330506
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888330775

From mli at openjdk.org  Tue Dec 17 11:14:35 2024
From: mli at openjdk.org (Hamlin Li)
Date: Tue, 17 Dec 2024 11:14:35 GMT
Subject: RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java failed
 with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
References: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
Message-ID: <aKYELfXHU1bg-UAyZZivfJi5n_0SMzhptF_nDRVf4Xc=.6683c6f7-7ed6-455a-83a4-7ef912a36acb@github.com>

On Mon, 16 Dec 2024 06:33:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the strace tests that adds a check for a null entry.
> 
> Testing:
>   - self
>   - tiers 1-3 (sanity)
> 
> Thanks

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22756#pullrequestreview-2508579132

From coleenp at openjdk.org  Tue Dec 17 12:41:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 12:41:39 GMT
Subject: RFR: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <45Ov_nZh2_DHP2y4InccwhTH3oOmiDoN5UBPCUS2gBo=.514207f4-c3c2-4346-b606-e3038079175c@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

Thanks Chris and Serguei.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22772#issuecomment-2548346300

From coleenp at openjdk.org  Tue Dec 17 12:41:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 12:41:39 GMT
Subject: Integrated: 8346304: SA doesn't need a copy of getModifierFlags
In-Reply-To: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
References: <NSvDIqbuew2WKKrwKKphv0EhlzSsf1qAdMLXRxE8WmE=.3ceec08b-ab8e-4e0e-b698-4841c398f5a6@github.com>
Message-ID: <vOkjcmn86Hl2Iy27w-bb9g-r79HcovZ230-W7_foT_0=.ec44c4f5-3c83-493b-9e49-bde7a7e49d25@github.com>

On Mon, 16 Dec 2024 20:33:22 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this trivial change to remove unused SA code.  Ran serviceability/sa tests, tier1 testing in progress.

This pull request has now been integrated.

Changeset: baeb3d9a
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/baeb3d9ab889cddcce1c00728098ae5a5120eeb2
Stats:     78 lines in 5 files changed: 0 ins; 76 del; 2 mod

8346304: SA doesn't need a copy of getModifierFlags

Reviewed-by: sspitsyn, cjplummer

-------------

PR: https://git.openjdk.org/jdk/pull/22772

From coleenp at openjdk.org  Tue Dec 17 12:49:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 12:49:37 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v5]
In-Reply-To: <nQDwn2PlcSzhILUy5kBwLeLcx9AUxuysRAPDOZvJJ-4=.e02c92c3-b457-4724-9e9f-7c6f9dfc0dfe@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <nQDwn2PlcSzhILUy5kBwLeLcx9AUxuysRAPDOZvJJ-4=.e02c92c3-b457-4724-9e9f-7c6f9dfc0dfe@github.com>
Message-ID: <o1EJp1zNInvivhDsQ7DDGJi1BvTQWNo9wflsawxnXos=.b5b3f44e-ab7e-45dd-a658-55a91d5f27df@github.com>

On Tue, 17 Dec 2024 04:19:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
>> 
>> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
>> 
>> as inspection of the class sources will show the expected `permits` and `extends` clauses.
>> 
>> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
>> 
>> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
>> 
>> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
>> 
>> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
>> 
>> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the que
 ries - ...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's suggestions

Looks good, thank you for making the changes.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22703#pullrequestreview-2508790757

From coleenp at openjdk.org  Tue Dec 17 12:49:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 12:49:39 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v4]
In-Reply-To: <HPmqo6-xtzjFcUWevTncrF8hyp4PuTprWEvdIOPUHwM=.7dc4dce5-86d3-4bfc-9079-c3966a5e2e80@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <z-p1qZUt6K1EL39e2Wo8v7COBeRVi6XeNHsJwWsLQ2Y=.ad3cb678-8b3e-4706-8c4d-4ec55377b453@github.com>
 <aSeFfA25wQ_GWiHpBBuEpErouWfkw_63tXsG7q47TTc=.f646f10c-fa2d-4718-b55d-31c7c17f79b4@github.com>
 <HPmqo6-xtzjFcUWevTncrF8hyp4PuTprWEvdIOPUHwM=.7dc4dce5-86d3-4bfc-9079-c3966a5e2e80@github.com>
Message-ID: <Sm3IBCllk_VshZX-6vKC1hkx-FOBmPu0aG2kJ19bJLI=.48d811cb-7d7b-4a3c-b39b-29c6f5231407@github.com>

On Tue, 17 Dec 2024 03:58:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/classfile/moduleEntry.hpp line 191:
>> 
>>> 189:   const char* name_as_C_string() {
>>> 190:     return is_named() ? name()->as_C_string() : UNNAMED_MODULE;
>>> 191:   }
>> 
>> Maybe PackageEntry::name_as_C_string() should get the same helper function.
>
> Can't do that. The un-named package means you have no PackageEntry and package() returns null.

Ok.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22703#discussion_r1888462011

From stefank at openjdk.org  Tue Dec 17 13:16:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 17 Dec 2024 13:16:40 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <DPTT-_rvoLVJ5QsRuryH-E3dZ3J9liV8r0249loIxu8=.3ba7bc2a-7856-4142-b672-ffb33dadbb39@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

OK. Thanks. I'll give it one more day to let any reviewers get a chance to take a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2548430738

From duke at openjdk.org  Tue Dec 17 13:48:37 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 13:48:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical
In-Reply-To: <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
 <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
 <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>
Message-ID: <fW8-yqnaOsES3tHkgdos0fa_2B40OpkEzAfACv1VoI8=.7c1066e2-333c-4704-92de-f77522918e7e@github.com>

On Tue, 17 Dec 2024 06:57:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> CML could perhaps be used has-a (though that might be messy), but should not
>> be used is-a.  One of the basic rules for base classes is to have either a
>> public virtual destructor (don't do that here) or a non-public non-virtual
>> destructor, to prevent accidental slicing.  MutexLockerImpl has that - it was
>> designed to be a base class.  CML doesn't - it was not designed to be a base
>> class.  (There is a common (though not universal) opinion that classes should
>> either be base or concrete classes, not both.) I know we violate this rule all
>> over the place; that doesn't mean we should do so here.
>> 
>> But really, there's no benefit to using CML here. Deriving from
>> MutexLockerImpl is about the same number of characters, and seems clearer to
>> me because it's more direct.
>> 
>> 
>> class NmtVirtualMemoryLocker : public MutexLockerImpl {
>> public:
>>   NmtVirtualMemoryLocker()
>>     : MutexLockerImpl(_done_bootstrap ? NmtVirtualMemory_lock : nullptr,
>>                       Mutex::_no_safepoint_check_flag)
>>   {}
>> }
>> 
>> 
>> Related, I just noticed that MutexLockerImpl is copyable, but shouldn't be.
>> (I remember a discussion a long time ago about whether StackObj should be
>> noncopyable, which foundered on a combination of some significant number of
>> existing uses that violated that restriction, along with disagreement about
>> the meaning of deriving from StackObj.  So we're not getting noncopyable from
>> there.)
>
> `MutexLockerImpl` was not intended for external subclassing, but as the internal base class for `MutexLocker`, and `ConditionalMutexLocker`.  CML was provided for exactly this kind of situation: conditionally locking the mutex.

Ok I see. I will stop using `ConditionalMutexLocker` as a base class. Instead, I'll just get rid of `NmtVirtualMemoryLocker` and use `ConditionalMutexLocker` directly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1888546778

From coleenp at openjdk.org  Tue Dec 17 14:36:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 14:36:36 GMT
Subject: RFR: 8346306: Unattached thread can cause crash during VM exit if
 it calls wait_if_vm_exited
In-Reply-To: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
References: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
Message-ID: <NHQ44mT_t8faMvQRrby00HqGS8lWXjVqyDPIKZRv-HY=.e5457d3d-b5fc-47cc-a93a-ff675595739a@github.com>

On Tue, 17 Dec 2024 00:10:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple fix to account for unattached threads using RawMonitors which check if the VM has exited.
> 
> Testing:
>  - tiers 1-3 (sanity)
> 
> Thanks

This makes sense.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22779#pullrequestreview-2509061894

From jwaters at openjdk.org  Tue Dec 17 14:54:03 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 17 Dec 2024 14:54:03 GMT
Subject: RFR: 8345265: Fix gcc LTO without disabling LTO for
 g1ParScanThreadState.cpp [v2]
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>

> [JDK-8343698](https://bugs.openjdk.org/browse/JDK-8343698) fixed LTO for gcc when compiling for platforms where the FORBID_C_FUNCTION mechanism is active, however the fix does so by inhibiting LTO for a specific file. This can hinder optimization, which is the end goal if one is indeed doing an LTO build. Fix the issue in a different way by disabling FORBID_C_FUNCTION entirely for os.cpp, which is where the error originates. This has a wide downstream effect, as os.cpp contains a call to os::malloc which contains the forbidden malloc that causes errors that cannot be suppressed by ALLOW_C_FUNCTION in an LTO build. This is a stopgap fix until FORBID_C_FUNCTION is fixed to work properly with LTO on all platforms. While here, also fix a memory leak in jvmciEnv.cpp

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patch-16
 - -fno-omit-frame-pointer in JvmFeatures.gmk
 - Revert compilerWarnings_gcc.hpp
 - General LTO fixes JvmFeatures.gmk
 - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
 - Merge branch 'openjdk:master' into patch-16
 - Revert os.cpp
 - Fix memory leak in jvmciEnv.cpp
 - Stopgap fix in os.cpp
 - Declaration fix in compilerWarnings_gcc.hpp
 - ... and 2 more: https://git.openjdk.org/jdk/compare/00943376...9d05cb8e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22464/files
  - new: https://git.openjdk.org/jdk/pull/22464/files/a357017f..9d05cb8e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22464&range=00-01

  Stats: 77380 lines in 3812 files changed: 58525 ins; 10150 del; 8705 mod
  Patch: https://git.openjdk.org/jdk/pull/22464.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22464/head:pull/22464

PR: https://git.openjdk.org/jdk/pull/22464

From kbarrett at openjdk.org  Tue Dec 17 14:54:04 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 17 Dec 2024 14:54:04 GMT
Subject: RFR: 8345265: Fix gcc LTO without disabling LTO for
 g1ParScanThreadState.cpp [v2]
In-Reply-To: <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
Message-ID: <3mm__-GakqA16snm4lzhpehd9hcD_kC4yoiXWwSDvyM=.2015a13a-fd71-439e-b748-abc622327156@github.com>

On Tue, 17 Dec 2024 14:51:16 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> [JDK-8343698](https://bugs.openjdk.org/browse/JDK-8343698) fixed LTO for gcc when compiling for platforms where the FORBID_C_FUNCTION mechanism is active, however the fix does so by inhibiting LTO for a specific file. This can hinder optimization, which is the end goal if one is indeed doing an LTO build. Fix the issue in a different way by disabling FORBID_C_FUNCTION entirely for os.cpp, which is where the error originates. This has a wide downstream effect, as os.cpp contains a call to os::malloc which contains the forbidden malloc that causes errors that cannot be suppressed by ALLOW_C_FUNCTION in an LTO build. This is a stopgap fix until FORBID_C_FUNCTION is fixed to work properly with LTO on all platforms. While here, also fix a memory leak in jvmciEnv.cpp
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into patch-16
>  - -fno-omit-frame-pointer in JvmFeatures.gmk
>  - Revert compilerWarnings_gcc.hpp
>  - General LTO fixes JvmFeatures.gmk
>  - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp
>  - Merge branch 'openjdk:master' into patch-16
>  - Revert os.cpp
>  - Fix memory leak in jvmciEnv.cpp
>  - Stopgap fix in os.cpp
>  - Declaration fix in compilerWarnings_gcc.hpp
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/00943376...9d05cb8e

I only noticed this had been changed back to Draft after I was mostly done looking
at it.  But I don't think this should be done this way, esp. since it didn't seem to work
(as in suppressing warnings from LTO) for me.

src/hotspot/share/jvmci/jvmciEnv.cpp line 616:

> 614:     // The memory allocated in libjvmci was not allocated with os::malloc
> 615:     // so must not be freed with os::free.
> 616:     ALLOW_C_FUNCTION(::free, ::free((void*) _init_error_msg);)

Please do this bug fix change under a separate JBS issue & PR.  I've created a JBS issue for it:
https://bugs.openjdk.org/browse/JDK-8345267
Fix memory leak in JVMCIEnv dtor

src/hotspot/share/runtime/os.cpp line 26:

> 24: 
> 25: // Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
> 26: #define DISABLE_POISONING_STOPGAP

This isn't needed if not using LTO.

src/hotspot/share/runtime/os.cpp line 26:

> 24: 
> 25: // Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
> 26: #define DISABLE_POISONING_STOPGAP

So far as I can tell, this doesn't work.  I still get tons of `-Wattribute-warning`s when building
with LTO, because of similar problem from other files.

src/hotspot/share/runtime/os.cpp line 26:

> 24: 
> 25: // Stopgap fix until FORBID_C_FUNCTION can work properly with LTO
> 26: #define DISABLE_POISONING_STOPGAP

This prevents precompiled headers from being used for this file.  `-Winvalid-pch` will warn if enabled.

src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 89:

> 87: // forbidden warnings in such builds.
> 88: #define FORBID_C_FUNCTION(signature, alternative) \
> 89:   [[gnu::warning(alternative)]] signature noexcept;

Why are you making this change at all, let alone under this JBS issue?

Among other problems, `noexcept` is mostly irrelevant in HotSpot, since we build with
exceptions disabled.  (There are a few places where `noexcept` affects semantics, like for
`operator new`, but otherwise there is no point.)

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22464#pullrequestreview-2470757627
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864123170
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864170998
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864210214
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864215385
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1864125153

From jwaters at openjdk.org  Tue Dec 17 14:54:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 17 Dec 2024 14:54:04 GMT
Subject: RFR: 8345265: Fix gcc LTO without disabling LTO for
 g1ParScanThreadState.cpp [v2]
In-Reply-To: <3mm__-GakqA16snm4lzhpehd9hcD_kC4yoiXWwSDvyM=.2015a13a-fd71-439e-b748-abc622327156@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <C50iOooAvxUbMBxuEdHdlwt62orfR5a3pRMAGIF39f4=.1464c4e4-2009-4eee-a803-1ab85efd83fe@github.com>
 <3mm__-GakqA16snm4lzhpehd9hcD_kC4yoiXWwSDvyM=.2015a13a-fd71-439e-b748-abc622327156@github.com>
Message-ID: <X9WWdo8vw-p92m3NKkd-JtGrP0hW5RXjGxsr9AuYAuw=.67cd5e70-5cdd-4208-abde-4bd81f6ded03@github.com>

On Sat, 30 Nov 2024 10:54:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I only noticed this had been changed back to Draft after I was mostly done looking at it. But I don't think this should be done this way, esp. since it didn't seem to work (as in suppressing warnings from LTO) for me.

Yeah, I had noticed that it didn't work too, which is why I returned it to draft. It also causes VC to explode when compiling the Windows HotSpot, so that isn't ideal. I guess returning g1ParScanThreadState.cpp to LTO status will have to wait until FORBID_C_FUNCTION is properly fixed up to be LTO proof

> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 89:
> 
>> 87: // forbidden warnings in such builds.
>> 88: #define FORBID_C_FUNCTION(signature, alternative) \
>> 89:   [[gnu::warning(alternative)]] signature noexcept;
> 
> Why are you making this change at all, let alone under this JBS issue?
> 
> Among other problems, `noexcept` is mostly irrelevant in HotSpot, since we build with
> exceptions disabled.  (There are a few places where `noexcept` affects semantics, like for
> `operator new`, but otherwise there is no point.)

I was thinking about the extern "C" and I think it might not be needed. A method that was already declared extern "C" in a C library header will keep that linkage when it is declared again, even without extern "C". There's also the issue that this forbidding macro could declare methods that don't actually exist on the current platform, which I think(?) removing extern "C" helps prevent. There's also the strange case that not all platforms have C library methods that are extern "C" (Windows is a notable example), so this helps declaring things with conflicting linkages and causing an error. The noexcept was just to match the declarations in standard library headers, since they are supposed to be noexcept according to the Standard

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2509126800
PR Review Comment: https://git.openjdk.org/jdk/pull/22464#discussion_r1874614943

From jwaters at openjdk.org  Tue Dec 17 14:54:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 17 Dec 2024 14:54:04 GMT
Subject: RFR: 8345265: Fix gcc LTO without disabling LTO for
 g1ParScanThreadState.cpp
In-Reply-To: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
Message-ID: <MqaSWBd5kzYiQdL71qBMshhNf4GlBAzHbj3KPGYgu2w=.b1979302-23db-4402-a920-af7fa1c06781@github.com>

On Sat, 30 Nov 2024 00:35:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> [JDK-8343698](https://bugs.openjdk.org/browse/JDK-8343698) fixed LTO for gcc when compiling for platforms where the FORBID_C_FUNCTION mechanism is active, however the fix does so by inhibiting LTO for a specific file. This can hinder optimization, which is the end goal if one is indeed doing an LTO build. Fix the issue in a different way by disabling FORBID_C_FUNCTION entirely for os.cpp, which is where the error originates. This has a wide downstream effect, as os.cpp contains a call to os::malloc which contains the forbidden malloc that causes errors that cannot be suppressed by ALLOW_C_FUNCTION in an LTO build. This is a stopgap fix until FORBID_C_FUNCTION is fixed to work properly with LTO on all platforms. While here, also fix a memory leak in jvmciEnv.cpp

This needs a name and description change, I'll do so later. @MBaesken does this fix LTO on your end? Kim also reports that LTO hangs indefinitely alongside several warning messages, do you have similar issues when you try to enable LTO?

Reverted the change in compilerWarnings_gcc.hpp since it was causing problems like Matthias reported. This still needs a title and description change since it now tries to improve LTO for all compilers, will do that later

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2525421248
PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2548658789

From mbaesken at openjdk.org  Tue Dec 17 14:54:04 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 17 Dec 2024 14:54:04 GMT
Subject: RFR: 8345265: Fix gcc LTO without disabling LTO for
 g1ParScanThreadState.cpp
In-Reply-To: <MqaSWBd5kzYiQdL71qBMshhNf4GlBAzHbj3KPGYgu2w=.b1979302-23db-4402-a920-af7fa1c06781@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <MqaSWBd5kzYiQdL71qBMshhNf4GlBAzHbj3KPGYgu2w=.b1979302-23db-4402-a920-af7fa1c06781@github.com>
Message-ID: <ggHNf-ZHPwRIeL2kNehgNSOKEpUzYk94pMACSGFqedY=.f3e8bca2-db19-4f57-83d0-9bc6b3ededbf@github.com>

On Sun, 8 Dec 2024 05:07:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> This needs a name and description change, I'll do so later. @MBaesken does this fix LTO on your end? Kim also reports that LTO hangs indefinitely alongside several warning messages, do you have similar issues when you try to enable LTO?

When I try to build with this change  (with and without lto enabled) I run into  


/openjdk/tools/devkits/x86_64-linux-gnu-to-x86_64-linux-gnu-fedora27-gcc11.3.0/x86_64-linux-gnu/sysroot/usr/include/unistd.h:520:14: error: conflicting declaration of 'char* get_current_dir_name()' with 'C' linkage
  520 | extern char *get_current_dir_name (void) __THROW;
      |              ^~~~~~~~~~~~~~~~~~~~

(maybe it is related to the devkit, maybe to pch I don't know)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2527527380

From jwaters at openjdk.org  Tue Dec 17 14:54:04 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 17 Dec 2024 14:54:04 GMT
Subject: RFR: 8345265: Fix gcc LTO without disabling LTO for
 g1ParScanThreadState.cpp
In-Reply-To: <ggHNf-ZHPwRIeL2kNehgNSOKEpUzYk94pMACSGFqedY=.f3e8bca2-db19-4f57-83d0-9bc6b3ededbf@github.com>
References: <Iyjt4BUQDLEd9cL5J60NE47XON6t8qMb6m45e4pxsQc=.a82182a7-d5c9-4cef-a3bf-b3396277b499@github.com>
 <MqaSWBd5kzYiQdL71qBMshhNf4GlBAzHbj3KPGYgu2w=.b1979302-23db-4402-a920-af7fa1c06781@github.com>
 <ggHNf-ZHPwRIeL2kNehgNSOKEpUzYk94pMACSGFqedY=.f3e8bca2-db19-4f57-83d0-9bc6b3ededbf@github.com>
Message-ID: <aPYSQH6WgFhbqPxUNnJT0bAQBtAvr4_LVY1vhnXv0kQ=.f30c35bc-c615-4af7-88a1-34943df1e7fc@github.com>

On Mon, 9 Dec 2024 10:30:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > This needs a name and description change, I'll do so later. @MBaesken does this fix LTO on your end? Kim also reports that LTO hangs indefinitely alongside several warning messages, do you have similar issues when you try to enable LTO?
> 
> When I try to build with this change (with and without lto enabled) I run into
> 
> ```
> /openjdk/tools/devkits/x86_64-linux-gnu-to-x86_64-linux-gnu-fedora27-gcc11.3.0/x86_64-linux-gnu/sysroot/usr/include/unistd.h:520:14: error: conflicting declaration of 'char* get_current_dir_name()' with 'C' linkage
>   520 | extern char *get_current_dir_name (void) __THROW;
>       |              ^~~~~~~~~~~~~~~~~~~~
> ```
> 
> (maybe it is related to the devkit, maybe to pch I don't know)

It's related to the subtle change in FORBID_C_FUNCTION, I think unistd.h is being included before compilerWarnings.hpp somewhere. Well, at least I now know the current approach has this issue

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2527675965

From ayang at openjdk.org  Tue Dec 17 15:23:43 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 17 Dec 2024 15:23:43 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v3]
In-Reply-To: <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
Message-ID: <_jFMtUcubatsffT1v8RF6R26bBfv-l7fBjzmmQsfOFI=.7a9d462c-b767-44a7-ae6e-ab0df24eb022@github.com>

On Fri, 13 Dec 2024 22:24:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - rename splitter.step() => claim()
>  - simplify comments
>  - Merge branch 'master' into pa-splitter
>  - parallel uses PartialArraySplitter
>  - g1 uses PartialArraySplitter
>  - add PartialArraySplitter
>  - add PartialArrayTaskStats

src/hotspot/share/gc/shared/partialArraySplitter.hpp line 46:

> 44: 
> 45: public:
> 46:   explicit PartialArraySplitter(PartialArrayStateManager* manager,

Why `explicit` for a method that has two args.

src/hotspot/share/gc/shared/partialArrayTaskStats.hpp line 77:

> 75:   void inc_pushed(size_t n = 1) { _pushed += n; }
> 76:   void inc_stolen(size_t n = 1) { _stolen += n; }
> 77:   void inc_processed(size_t n = 1) { _processed += n; }

I skimmed through callers of these, but can't find a strong reason to use default-arg-value here. Will there be more call-sites that justify this usage?

src/hotspot/share/gc/shared/partialArrayTaskStats.hpp line 96:

> 94: 
> 95: template<typename StatsAccess>
> 96: void PartialArrayTaskStats::log_set(uint num_stats,

Can this be merged with its declaration? Seems kind of odd that these duplicates (method signature) are next to each other.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1888693312
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1888684891
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1888690919

From duke at openjdk.org  Tue Dec 17 15:30:54 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 15:30:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v2]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <BOOlQ28V2IxdNoDWMf_GuNi7b_K5gpjGwqCIixEofuY=.659c49d2-f51d-4eb3-835d-d99c355752a0@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  use ConditionalMutexLocker directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/e817cf1f..c169ff80

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=00-01

  Stats: 21 lines in 9 files changed: 0 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From duke at openjdk.org  Tue Dec 17 15:46:01 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 15:46:01 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  updates tests and remove old class

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/c169ff80..1d07d95a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=01-02

  Stats: 14 lines in 2 files changed: 1 ins; 9 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From vaivanov at openjdk.org  Tue Dec 17 16:14:40 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 17 Dec 2024 16:14:40 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <eOjx1HBvll6LUF5HsYb_IA5S06xxXRWyOmcSPeoxn2o=.1428f6c0-7352-4262-9fc4-b901e7d3e529@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

Thanks for your review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2548906472

From duke at openjdk.org  Tue Dec 17 16:14:40 2024
From: duke at openjdk.org (duke)
Date: Tue, 17 Dec 2024 16:14:40 GMT
Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be
 optimized [v2]
In-Reply-To: <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
 <p6tbI9mYeL3Jm1v9wNe1CiwnY19yGL4UtbeahBEdBRg=.dbb3c4dd-ce1c-4b81-bee2-1df28a03ade9@github.com>
Message-ID: <R3CmDBTcgtgqykxhszT7urbWfXGh-u2A2A0l5jqfp7Q=.b9348807-2624-4bcd-82a0-6f9c81a7fae7@github.com>

On Fri, 13 Dec 2024 02:17:33 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8341481
>  - 8341481: [perf] vframeStreamCommon constructor may be optimized
>  - 8341481 [Perf] vframeStreamCommon constructor may be optimized

@IvaVladimir 
Your change (at version ba234c592b976e8a3a8f1c1c2c66d9699c4ec265) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2548907410

From epeter at openjdk.org  Tue Dec 17 16:30:48 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 16:30:48 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>
Message-ID: <Lm1Jk5C0ljDdtZ966XOSq1s4KtOYeryjNm3Sgm7xxFw=.0025b761-fa3a-43f3-8dda-bb027345b340@github.com>

On Tue, 17 Dec 2024 11:06:17 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 275:
>> 
>>> 273:     @IR(counts = {IRNode.ADD_HF, " 0 ", IRNode.REINTERPRET_S2HF, " 0 ", IRNode.REINTERPRET_HF2S, " 0 "},
>>> 274:         applyIfCPUFeature = {"avx512_fp16", "true"})
>>> 275:     public void testAddConstantFolding() {
>> 
>> Ok, this is great. I'm missing some cases that check correct rounding. For that, it might be good to have one example with random constants, so 2 random Float16 values. You can generate them in static context, and also compute the result in static context, so it should be evaluated in the interpreter. That way, we can compare the result of interpreter to compiled code.
>> 
>> Do that for all operations.
>
> Hey @eme64 , constant folding is done at FP32 granularity, so we first upcast FP16 to FP32 values using hf2f runtime helper, operate over FP32 values and then down cast it back to FP16 value using f2hf helper.  Thus both compiler value transformations and interpreter use the same runtime helper underneath.
> 
> Fallback implementation of each Float16 API is using Float.floatToFloat16 and Float.floa16ToFloat routines which are intrinsified at [interpreter level.](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/interpreter/templateInterpreterGenerator.cpp#L488), these interpreter intrinsic invokes same leaf level macro assembly routine flt16_to_flt which is also called though runtime helpers. 
> 
> So it may not add much value to do interpreter vs compiler comparison in these cases.

Ah, yes, you are right, compiler vs interpreter comparison does not help as much as I thought, though we should still do it. What we need to do is compare interpreter and C2-constant-folded results with the results of the backend instructions, but we can also do that with variable values.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888838421

From galder at openjdk.org  Tue Dec 17 16:42:48 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 17 Dec 2024 16:42:48 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <qEK_fgwN0K-S9tyXH1apALwn06b64fb7th4UjMCOtIM=.ff6446be-4fb5-432a-af23-049296232d3e@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
 <qEK_fgwN0K-S9tyXH1apALwn06b64fb7th4UjMCOtIM=.ff6446be-4fb5-432a-af23-049296232d3e@github.com>
Message-ID: <9ReqLUCZ6XDaSQxgYw3NyZZdMv3SOHkCkzJ0DLAksas=.8cb29982-8cb8-4068-a251-59a189c83b93@github.com>

On Fri, 29 Nov 2024 11:26:10 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:
>> 
>>  - Use same default size as in other vector reduction benchmarks
>>  - Renamed benchmark class
>>  - Double/Float tests only when avx enabled
>>  - Make state class non-final
>>  - Restore previous benchmark iterations and default param size
>>  - Add clipping range benchmark that uses min/max
>>  - Encapsulate benchmark state within an inner class
>>  - Avoid creating result array in benchmark method
>>  - Merge branch 'master' into topic.intrinsify-max-min-long
>>  - Revert "Implement cmovL as a jump+mov branch"
>>    
>>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>>  - ... and 20 more: https://git.openjdk.org/jdk/compare/b290c6e3...0a8718e1
>
> test/hotspot/jtreg/compiler/intrinsics/math/TestMinMaxInlining.java line 80:
> 
>> 78:     @IR(phase = { CompilePhase.BEFORE_MACRO_EXPANSION }, counts = { IRNode.MIN_L, "1" })
>> 79:     @IR(phase = { CompilePhase.AFTER_MACRO_EXPANSION }, counts = { IRNode.MIN_L, "0" })
>> 80:     private static long testLongMin(long a, long b) {
> 
> Can you add a comment why it disappears after macro expansion?

Good question. On non-avx512 machines after macro expansion the min/max nodes become cmov nodes, but but that's not the full story because on avx512 machines, they become minV/maxV nodes. Would you tweak the `@IR` annotations to capture this? Or would you leave it just as a comment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1888858177

From epeter at openjdk.org  Tue Dec 17 16:43:39 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 16:43:39 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>
Message-ID: <mrYSgamNO4vK_No6T46HnvsF-RZ8yVW8nC7_rbTwwVY=.b0c27c0b-ea72-49f8-9276-f11025154e27@github.com>

On Tue, 17 Dec 2024 11:06:13 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/convertnode.cpp line 282:
>> 
>>> 280:       return new ReinterpretHF2SNode(binop);
>>> 281:     }
>>> 282:   }
>> 
>> Where are the constant folding tests for this?
>
> This is the core idealization logic which infers FP16 IR. Every test point added in the test points added in test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java verifies this.

Picking a random line from `testAddConstantFolding()`
` assertResult(add(Float16.POSITIVE_INFINITY, Float16.POSITIVE_INFINITY).floatValue(), Float.POSITIVE_INFINITY, "testAddConstantFolding");`

So this seems to do a FP16 -> FP16 add, then convert to float, so I don't immediately see the FP16 -> Float -> FP16 conversion.

Ah, how do we intrinsify this?

    public static Float16 add(Float16 addend, Float16 augend) {
        return valueOf(addend.floatValue() + augend.floatValue());
    }

Is it not the `add` that is intfinsified, but the `valueOf`, `floatValue` and Float `+`?

Why not intrinsify the `Float16.add` directly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888858048

From epeter at openjdk.org  Tue Dec 17 16:43:40 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 16:43:40 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <PfwB5m-a0q5OUzeEqXCaw8qJU-aS7PQjwmcX8NAvgG8=.b94cf242-6b12-46dd-b944-6c86ff3487d1@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <DiFSbHS-FHHYMWH8ukFlm8meO3bMSbt9EkQbM-MJTyQ=.fb7a9050-fa97-4d73-b4e8-862e511c2280@github.com>
 <PfwB5m-a0q5OUzeEqXCaw8qJU-aS7PQjwmcX8NAvgG8=.b94cf242-6b12-46dd-b944-6c86ff3487d1@github.com>
Message-ID: <Efd8UzwgOqpz162CU5S9fq16xZ7Zs7y2rJF--RoC5O4=.8697cfdb-b144-42fe-9b00-1a764b677815@github.com>

On Tue, 17 Dec 2024 11:06:07 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> We would need all sorts of conversion with Float16 <-> short. With Float16 constant and variable values. And also with short constant and variable values.
>
> Yes, there are multiple test points in newly added test which receive floating-point constant which goes through following IR logic before being constant folded 
> ConF -> ConvF2HF -> ReinterpretS2HF

Please show me an example.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888859046

From epeter at openjdk.org  Tue Dec 17 16:58:40 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 16:58:40 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <PfwB5m-a0q5OUzeEqXCaw8qJU-aS7PQjwmcX8NAvgG8=.b94cf242-6b12-46dd-b944-6c86ff3487d1@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <DiFSbHS-FHHYMWH8ukFlm8meO3bMSbt9EkQbM-MJTyQ=.fb7a9050-fa97-4d73-b4e8-862e511c2280@github.com>
 <PfwB5m-a0q5OUzeEqXCaw8qJU-aS7PQjwmcX8NAvgG8=.b94cf242-6b12-46dd-b944-6c86ff3487d1@github.com>
Message-ID: <hHq6Gc1AH3WrcY6Xaxn-3CXbkq3Xdq-L8L-tayGtNVs=.cb1dc2a6-0523-428d-a6df-15b5aaf257b5@github.com>

On Tue, 17 Dec 2024 11:05:27 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Are we sure that the rounding behaviour of float is the correct behaviour for Float16? I would like to see some examples where rounding matters.
>
> FP16 has 11 bits precision and FP32 has 24 bit precision, thus as per [2P rule ](https://dl.acm.org/doi/pdf/10.1145/221332.221334) the operation is innocuous to double rounding effects. In addition, fall back implementation of Float16.divide also takes the same route of performing the operation at FP32 granularity.

I understand. Thanks for the explanation. But the backend `Float16` instructions do not convert to float, right? So we need to be sure, and test that rounding works correctly in all cases. Can you point me to a test for that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888882880

From epeter at openjdk.org  Tue Dec 17 16:58:43 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 16:58:43 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>
Message-ID: <s4meC-JRcPc6DUTMi4iaByEemLz3H5jWW5yWw3BQs_c=.94e1f1ab-f18f-4275-91c2-f8662bcceecf@github.com>

On Tue, 17 Dec 2024 11:05:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/divnode.cpp line 840:
>> 
>>> 838:   if (g_isnan(t1->getf()) || g_isnan(t2->getf())) {
>>> 839:     return TypeH::make(NAN);
>>> 840:   }
>> 
>> I'm a little confused here. We are working with nodes that have type Float16, but we are asking for Float constants here. Why is that, how does it work?
>
> Please refer to PhaseIGVN::transform, we create constant IR for singleton types. 
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/phaseX.cpp#L721

That misses my question, I was again confused about float vs Float16. But I see from your previous answer that `getf` does the conversion from `Float16` -> `float`. So all good.

>> src/hotspot/share/opto/subnode.cpp line 566:
>> 
>>> 564:     return t1;
>>> 565:   }
>>> 566:   else if(g_isnan(t2->getf())) {
>> 
>> General question: why are you using `getf` and not `geth` all over the code?
>
> getf is a routine that performs half float to float conversion for TypeH.

Ah right, I see now. Thanks.

>> src/hotspot/share/opto/type.cpp line 1530:
>> 
>>> 1528: uint TypeH::hash(void) const {
>>> 1529:   return *(uint*)(&_f);
>>> 1530: }
>> 
>> I just saw that `_f` is a `short`, which I think is 16 bits, right? And the cast to `uint` would mean we take 32 bits. That looks a bit off, but maybe it is not. Can you explain, and maybe also put a comment in the code for that?
>
> This is to comply with Node::hash signature which returns uint value

But does that not mean that we have a 4-byte load, but the end of the object already happens after 2 bytes? If so, what are those 2 extra bytes? Is that safe and correct?

>> test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java line 494:
>> 
>>> 492:         assertResult(fma(valueOf(1.0f), valueOf(2.0f), valueOf(3.0f)).floatValue(), 1.0f * 2.0f + 3.0f, "testFMAConstantFolding");
>>> 493:     }
>>> 494: }
>> 
>> I am missing constant folding tests with `shortBitsToFloat16` etc.
>
> Added a few test points for the same

Oh, I was more hoping for a separate test with `shortBitsToFloat16`, not mixed in with `fma`.
And what about constant folding tests for `float16ToRawShortBits`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888887926
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888885400
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888869947
PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1888875984

From epeter at openjdk.org  Tue Dec 17 17:01:40 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 17 Dec 2024 17:01:40 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v5]
In-Reply-To: <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <JjyLFW_Pevx5K5qbb1e_3NVSVFsjYXxCLHvOW6r9Pz8=.090e1081-58c3-413e-bdfe-f0f652d7682a@github.com>
 <H_eWDODWEakhmBpbiL2apPxV9iJeeoTFBjSBsagytNI=.0efc7881-efbc-4609-8982-17eb13f3c56a@github.com>
 <xCmBgJGY_IQMTbqFxlT3WKxI4ZQ9x4kgryTmUX8w3xU=.acbcba77-a4d3-4feb-87f2-2e12ea2477bc@github.com>
 <03ozC1NfpoBMN8fyLJY6gt2_7GZQpDtTHEj8cgxD_dU=.dd851537-820d-4b72-acf9-b170aa756e4b@github.com>
Message-ID: <k659lSH-75NUznlaZn4iOeVR8snssetblmVSCVzvDSs=.088fefe2-95b6-43ae-b3e0-5730e314211e@github.com>

On Mon, 16 Dec 2024 14:19:49 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> > Can you quickly summarize what tests you have, and what they test?
>>> 
>>> Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
>
>> > > Can you quickly summarize what tests you have, and what they test?
>> > 
>> > 
>> > Patch includes functional and performance tests, as per your suggestions IR framework-based tests now cover various special cases for constant folding transformation. Let me know if you see any gaps.
>> 
>> I was hoping that you could make a list of all optimizations that are included here, and tell me where the tests are for it. That would significantly reduce the review time on my end. Otherwise I have to correlate everything myself, and that will take me hours.
> 
> 
> Validations details:-
> 
> A) x86 backend changes
>    - new assembler instruction
>    - macro assembly routines. 
>     Test point:-  test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java
>          - This test is based on a testng framework and includes new DataProviders to generate test vectors.
>          -  Test vectors cover the entire float16 value range and also special floating point values (NaN, +Int, -Inf, 0.0 and -0.0) 
> B) GVN transformations:-
>      -  Value Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>               -  Covers all the constant folding scenarios for add, sub, mul, div, sqrt, fma, min, and max operations addressed by this patch.
>               -  It also tests special case scenarios for each operation as specified by Java language specification.
>     -   identity Transforms
>         Test point:- test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>                -  Covers identity transformation for  ReinterpretS2HFNode,  DivHFNode
>     -  idealization Transforms
>         Test points:-  test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java
>                                 :-   test test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java
>             - Contains test point for the following transform 
>                          MulHF idealization i.e. MulHF * 2 => AddHF  
>            -  Contains test point for the following transform
>                          DivHF SRC ,  PoT(constant) =>  MulHF SRC * reciprocal (constant) 
>             - Contains idealization test points for the following transform 
>                    ConvF2HF(FP32BinOp(ConvHF2F(x), ConvHF2F(y))) =>
>                            ReinterpretHF2S(FP16BinOp(ReinterpretS2HF(x), ReinterpretS2HF(y)))

@jatin-bhateja thanks for all the updates and explanations.

I'm still missing some tests for rounding effects. It would be important to verify that the interpreter, constant folding, and backend instructions all lead to the same rounding for add/sub/div/mul/fma/... I propose that you pick random `short` values, reinterpet them as `Float16`, then do the calculation via interpreter, let it constant fold with C2, and put it in variables that cannot be constant folded, so that backend instructions are emitted for it.

Does that make sense?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22754#issuecomment-2549040374

From vaivanov at openjdk.org  Tue Dec 17 17:03:42 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 17 Dec 2024 17:03:42 GMT
Subject: Integrated: 8341481: [perf] vframeStreamCommon constructor may be
 optimized
In-Reply-To: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
References: <TZbNy9ywtBoI9nsfNLNhde3SqQZ_gbqGQuOo7_HWuOI=.0be7dc05-7ed6-4ff2-9374-b8f5fd106184@github.com>
Message-ID: <gXL6nsmjOPHe5TbJ1ujvorNh2N8cDQFbXl0g2YYq8Yc=.662e9ef7-1b99-4e42-ad37-2aa6347279ac@github.com>

On Sat, 16 Nov 2024 00:20:10 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement.

This pull request has now been integrated.

Changeset: 4f44cf6b
Author:    Vladimir Ivanov <vaivanov at openjdk.org>
Committer: Derek White <drwhite at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f44cf6bf2423a57a841be817f348e3b1e88f0eb
Stats:     31 lines in 5 files changed: 11 ins; 1 del; 19 mod

8341481: [perf] vframeStreamCommon constructor may be optimized

Reviewed-by: sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/22173

From kbarrett at openjdk.org  Tue Dec 17 17:15:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 17 Dec 2024 17:15:39 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v3]
In-Reply-To: <_jFMtUcubatsffT1v8RF6R26bBfv-l7fBjzmmQsfOFI=.7a9d462c-b767-44a7-ae6e-ab0df24eb022@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
 <_jFMtUcubatsffT1v8RF6R26bBfv-l7fBjzmmQsfOFI=.7a9d462c-b767-44a7-ae6e-ab0df24eb022@github.com>
Message-ID: <3hbk0a1HRqX-AE8_CrNfndkuJXzVMZGOMb8S1qDuP7M=.442b3022-4b98-4acc-a27c-9c8210779b04@github.com>

On Tue, 17 Dec 2024 15:18:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pa-splitter
>>  - rename splitter.step() => claim()
>>  - simplify comments
>>  - Merge branch 'master' into pa-splitter
>>  - parallel uses PartialArraySplitter
>>  - g1 uses PartialArraySplitter
>>  - add PartialArraySplitter
>>  - add PartialArrayTaskStats
>
> src/hotspot/share/gc/shared/partialArraySplitter.hpp line 46:
> 
>> 44: 
>> 45: public:
>> 46:   explicit PartialArraySplitter(PartialArrayStateManager* manager,
> 
> Why `explicit` for a method that has two args.

Forgot to remove when 2nd argument added.  Originally that number from the manager, but
a potentially long-lived and reused manager with dynamic selection of worker threads made
that wrong.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1888914756

From sspitsyn at openjdk.org  Tue Dec 17 17:35:44 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:35:44 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
Message-ID: <xYxm6MMDagLAKEg-e_cpEI-G3yq15D_6N95qi8qlzsM=.1f77524c-eb91-431f-a7d1-7308f50d2abd@github.com>

On Tue, 17 Dec 2024 03:27:16 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra check to post_method_exit_inner before clear_frame_pop to avoid assert
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1365:
> 
>> 1363:   if (ets->is_frame_pop(frame_number)) {
>> 1364:     return JVMTI_ERROR_DUPLICATE;
>> 1365:   }
> 
> It seems that this change is unrelated to ClearAllFramePops and perhaps deserves it's own CR, especially since it is a behavior change.

Okay. Removed the `JVMTI_ERROR_DUPLICATE` related changes. Will fix it separately including the CSR.

> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 263:
> 
>> 261: #ifdef ASSERT
>> 262:   Thread *current = Thread::current();
>> 263: #endif
> 
> I think you can just get rid of these lines and inline the Thread.current() call below.

Okay, fixed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 505:
> 
>> 503:   err = jvmti->NotifyFramePop(thread, 0);
>> 504:   check_jvmti_status(jni, err, "VirtualThreadUnmount: error in JVMTI NotifyFramePop");
>> 505: 
> 
> I assume this is needed as the result of your fix to return DUPLICATE for NotifyFramePop. Do we know that it always returns DUPLICATE for this particular call site?

Yes, it is related to the DUPLICATE change.
The test calls JVMTI `NotifyFramePop` in the `VirtualThreadMount`/`VirtualThreadUnmount` event handlers.
One of them is a dup for sure and not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888942395
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888940655
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888939839

From kbarrett at openjdk.org  Tue Dec 17 17:35:48 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 17 Dec 2024 17:35:48 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v3]
In-Reply-To: <_jFMtUcubatsffT1v8RF6R26bBfv-l7fBjzmmQsfOFI=.7a9d462c-b767-44a7-ae6e-ab0df24eb022@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
 <_jFMtUcubatsffT1v8RF6R26bBfv-l7fBjzmmQsfOFI=.7a9d462c-b767-44a7-ae6e-ab0df24eb022@github.com>
Message-ID: <abvIwsZICsGHQu_czKKUkWApdByGronbN_F429BPlE0=.87cf6809-6ced-40db-91da-9fac71ccffb0@github.com>

On Tue, 17 Dec 2024 15:17:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pa-splitter
>>  - rename splitter.step() => claim()
>>  - simplify comments
>>  - Merge branch 'master' into pa-splitter
>>  - parallel uses PartialArraySplitter
>>  - g1 uses PartialArraySplitter
>>  - add PartialArraySplitter
>>  - add PartialArrayTaskStats
>
> src/hotspot/share/gc/shared/partialArrayTaskStats.hpp line 96:
> 
>> 94: 
>> 95: template<typename StatsAccess>
>> 96: void PartialArrayTaskStats::log_set(uint num_stats,
> 
> Can this be merged with its declaration? Seems kind of odd that these duplicates (method signature) are next to each other.

That would implicitly declare it inline, which doesn't seem particularly
desirable here.  And it doesn't seem worth the overhead of splitting out into
a .inline.hpp file.  (That would let the logging includes be moved there,
rather than here in the .hpp file.  But that seems like a small benefit, since
I don't think there are going to be *that* many includes of this file.)

But the implicit inlining probably doesn't really matter after all, since the
access function is probably different in every use, so we'll so we'll have 1-1
uses to instantiations anyway.  So sure, merging.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1888942745

From sspitsyn at openjdk.org  Tue Dec 17 17:38:39 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:38:39 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
Message-ID: <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>

On Tue, 17 Dec 2024 03:20:20 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added extra check to post_method_exit_inner before clear_frame_pop to avoid assert
>
> src/hotspot/share/interpreter/interpreterRuntime.cpp line 580:
> 
>> 578:   // notify debugger of an exception catch
>> 579:   // (this is good for exceptions caught in native methods as well)
>> 580:   if (JvmtiExport::can_post_on_exceptions() || JvmtiExport::can_post_frame_pop()) {
> 
> This doesn't seem like it is related to ClearAllFramePops.

Yes, it does not relate to the `ClearAllFramePops` directly. But it is needed for correctness of the `NotifyFramePop`. I do not feel it is worth to separate this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1888946592

From sspitsyn at openjdk.org  Tue Dec 17 17:49:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:49:14 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v3]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <CBHcijvQXSeEw2V2123sC_VgX9I6ng0hcZ90MdzYM5s=.e6f53453-1491-4fff-8480-1ea615ea9e5a@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: removed DUPLICATE related changes; a minor tweak for ASSERT line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/b04f078f..0e4ddcc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=01-02

  Stats: 15 lines in 4 files changed: 3 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

PR: https://git.openjdk.org/jdk/pull/22744

From sspitsyn at openjdk.org  Tue Dec 17 17:49:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 17:49:14 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
Message-ID: <gu9agh3DzqgKju97KTUM48V2JrHqXawCpkNpXK9yLPk=.ac946420-0141-46d8-97ac-5cd5962e9cc9@github.com>

On Tue, 17 Dec 2024 03:39:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> All my debugger testing is passing now. A few comments inline.

Thank you for testing my update in the debugging environment!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2549152190

From kbarrett at openjdk.org  Tue Dec 17 18:08:23 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 17 Dec 2024 18:08:23 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
Message-ID: <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>

> Please review this change that introduces two new helper classes to simplify
> the usage of PartialArrayStates to manage splitting the processing of large
> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
> changed to use this new mechanism.
> 
> PartialArrayTaskStats is used to collect and report statistics related to
> array splitting.  It replaces the direct implementation in PSPromotionManager,
> and is now also used by G1 young GCs.
> 
> PartialArraySplitter packages up most of the work involved in splitting and
> processing tasks. It provides task allocation and release, enqueuing, chunk
> claiming, and statistics tracking. It does this by encapsulating existing
> objects and functionality. Using array splitting is mostly reduced to calling
> the splitter's start function and then calling it's step function to process
> partial states. This substantially reduces the amount of code for each client
> to perform this work.
> 
> Testing: mach5 tier1-5
> 
> Manually ran some test programs with each of G1 and Parallel, with taskqueue
> stats logging enabled, and checked that the logged statistics looked okay.

Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Merge branch 'master' into pa-splitter
 - merge log_set decl/defn
 - remove default counts for stats incrementers
 - remove uneeded 'explicit'
 - cleanup unneeded includes
 - remove moved-from macro defines
 - Merge branch 'master' into pa-splitter
 - rename splitter.step() => claim()
 - simplify comments
 - Merge branch 'master' into pa-splitter
 - ... and 4 more: https://git.openjdk.org/jdk/compare/b7c9006e...54c37988

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22622/files
  - new: https://git.openjdk.org/jdk/pull/22622/files/cb70d7b3..54c37988

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22622&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22622&range=02-03

  Stats: 7934 lines in 322 files changed: 5981 ins; 859 del; 1094 mod
  Patch: https://git.openjdk.org/jdk/pull/22622.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22622/head:pull/22622

PR: https://git.openjdk.org/jdk/pull/22622

From galder at openjdk.org  Tue Dec 17 18:12:24 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 17 Dec 2024 18:12:24 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v6]
In-Reply-To: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
Message-ID: <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>

> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
> 
> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
> 
> 
> VLoop::check_preconditions: failed: control flow in loop not allowed
> 
> 
> The control flow is due to the java implementation for these methods, e.g.
> 
> 
> public static long max(long a, long b) {
>     return (a >= b) ? a : b;
> }
> 
> 
> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
> E.g.
> 
> 
> SuperWord::transform_loop:
>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
> 
> 
> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1155
> long max   1173
> 
> 
> After the patch, on darwin/aarch64 (M1):
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>                                                          1     1     0     0
> ==============================
> TEST SUCCESS
> 
> long min   1042
> long max   1042
> 
> 
> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
> Therefore, it still relies on the macro expansion to transform those into CMoveL.
> 
> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/hotspot/jtreg:tier1                     2500  2500     0     0
>>> jtreg:test/jdk:tier1                     ...

Galder Zamarre?o has updated the pull request incrementally with five additional commits since the last revision:

 - Added comment around the assertions
 - Adjust min/max identity IR test expectations after changes
 - Fix style
 - Add max reduction test
 - Add empty line

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20098/files
  - new: https://git.openjdk.org/jdk/pull/20098/files/aca09222..130b4755

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20098&range=04-05

  Stats: 169 lines in 5 files changed: 162 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/20098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20098/head:pull/20098

PR: https://git.openjdk.org/jdk/pull/20098

From kbarrett at openjdk.org  Tue Dec 17 17:19:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 17 Dec 2024 17:19:38 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v3]
In-Reply-To: <_jFMtUcubatsffT1v8RF6R26bBfv-l7fBjzmmQsfOFI=.7a9d462c-b767-44a7-ae6e-ab0df24eb022@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <OdSO8C3g3sDqmxz4akIkMYiPTHGBLOOLbJmQ_elfPBo=.14059573-15a3-4883-bd5c-f8ab3ba19aef@github.com>
 <_jFMtUcubatsffT1v8RF6R26bBfv-l7fBjzmmQsfOFI=.7a9d462c-b767-44a7-ae6e-ab0df24eb022@github.com>
Message-ID: <eijIKHiHbzRGYy6F7K0-dWdnpIqRu2fq4tpjIw4aWNg=.a1ca1c52-1ab6-404f-8014-f2d4cc3de14a@github.com>

On Tue, 17 Dec 2024 15:13:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pa-splitter
>>  - rename splitter.step() => claim()
>>  - simplify comments
>>  - Merge branch 'master' into pa-splitter
>>  - parallel uses PartialArraySplitter
>>  - g1 uses PartialArraySplitter
>>  - add PartialArraySplitter
>>  - add PartialArrayTaskStats
>
> src/hotspot/share/gc/shared/partialArrayTaskStats.hpp line 77:
> 
>> 75:   void inc_pushed(size_t n = 1) { _pushed += n; }
>> 76:   void inc_stolen(size_t n = 1) { _stolen += n; }
>> 77:   void inc_processed(size_t n = 1) { _processed += n; }
> 
> I skimmed through callers of these, but can't find a strong reason to use default-arg-value here. Will there be more call-sites that justify this usage?

Currently, inc_pushed needs an argument while others don't.  Given this stats object is likely
mostly encapsulated in and modified by the splitter object, that might always be the case for these
functions.  Though consistency has some benefit, maybe not here?  I'll wire in the usage, and we
can adjust later if needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1888919697

From galder at openjdk.org  Tue Dec 17 18:23:39 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Tue, 17 Dec 2024 18:23:39 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
Message-ID: <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>

On Thu, 12 Dec 2024 12:03:11 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> @galderz Thanks for taking this task on! Had a quick look at it. So auto-vectorization in SuperWord should now be working, right? If yes:
>>> 
>>> It would be nice if you tested both for `IRNode.MIN_VL` and `IRNode.MIN_REDUCTION_V`, the same for max.
>>> 
>>> You may want to look at these existing tests, to see what other tests there are for the `int` version: `test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Int.java` `test/hotspot/jtreg/compiler/c2/irTests/TestIfMinMax.java` `test/hotspot/jtreg/compiler/vectorization/TestAutoVecIntMinMax.java` `test/hotspot/jtreg/compiler/c2/TestMinMaxSubword.java` There may be some duplicates already here... not sure. 
>> 
>> +1 to adding such tests. I'm looking into it right now. It's a bit confusing how the tests are spread around (and duplication?) but I'm currently leaning towards adding a `compiler/loopopts/superword/MinMaxRed_Long.java`.
>> 
>>> And maybe you need to check what to do about probabilities as well.
>> 
>> I will add probabilities logic (50, 80, 100) to control data, but you can already see that from https://github.com/openjdk/jdk/pull/20098#issuecomment-2379386872 that with the patch in an AVX512 system min/max reduction nodes will appear in all probabilities.
>
> @galderz Yes, there is significant duplication, sadly. Often there were old tests there, but then one comes along and sees that one wants to have more comprehensive tests. So one adds it, but does not feel 100% comfortable removing old tests. A little bit of duplication is probably ok. Often, there are still subtle differences, and sometimes those end up mattering.
> 
> `compiler/loopopts/superword/MinMaxRed_Long.java` sounds like a good idea.

@eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further.

@jaskarth FYI I've adjusted the expectations in `TestMinMaxIdentities` after this change (thx for adding the test!). Check if there's any comments/changes you'd like.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2549259008

From duke at openjdk.org  Tue Dec 17 19:42:36 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Tue, 17 Dec 2024 19:42:36 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
Message-ID: <6dxe83dysekshNnBGeuYdGrsHdGIg4rayXM4van3KD8=.9e9f027a-7ec1-48d1-b6c0-cae7499a6d4c@github.com>

On Tue, 17 Dec 2024 15:46:01 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates tests and remove old class

The GHA test `windows-x64 / test (hs/tier1 gc)` is failing with: 

#  Internal Error (d:\a\jdk\jdk\src\hotspot\share\gc\shenandoah\shenandoahGeneration.cpp:1029), pid=2620, tid=4892
#  assert(ShenandoahHeap::heap()->is_full_gc_in_progress() || (_affiliated_region_count * ShenandoahHeapRegion::region_size_bytes() <= _max_capacity)) failed: Cannot use more than capacity

I don't think this is related to the changes in this PR. The same problem seems to have been reported a week ago here: [JDK-8345895](https://bugs.openjdk.org/browse/JDK-8345895)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2549451242

From ayang at openjdk.org  Tue Dec 17 20:14:42 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 17 Dec 2024 20:14:42 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
Message-ID: <XZ-XU1c0qP6cP2ctLQnfc4UebY_02W7ZbLZTnD-Vz4Y=.14943f82-945b-40d1-a389-5d690f2ed1d4@github.com>

On Tue, 17 Dec 2024 18:08:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - merge log_set decl/defn
>  - remove default counts for stats incrementers
>  - remove uneeded 'explicit'
>  - cleanup unneeded includes
>  - remove moved-from macro defines
>  - Merge branch 'master' into pa-splitter
>  - rename splitter.step() => claim()
>  - simplify comments
>  - Merge branch 'master' into pa-splitter
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/999d9cc9...54c37988

Some minor suggestion.

src/hotspot/share/gc/shared/partialArraySplitter.hpp line 81:

> 79:   // Result type for claim(), carrying multiple values.  Provides the claimed
> 80:   // chunk's start and end array indices.
> 81:   struct Claim {

I feel `Chunk` is a better name.

src/hotspot/share/gc/shared/partialArraySplitter.inline.hpp line 63:

> 61: PartialArraySplitter::claim(PartialArrayState* state, Queue* queue, bool stolen) {
> 62: #if TASKQUEUE_STATS
> 63:   if (stolen) _stats.inc_stolen();

Breaking it into multiple lines make the control flow more explicit.

src/hotspot/share/gc/shared/partialArrayTaskStats.cpp line 49:

> 47: 
> 48: void PartialArrayTaskStats::reset() {
> 49:   *this = PartialArrayTaskStats();

Can we do sth like `static_assert(std::is_trivially_copyable<PartialArrayTaskStats>::value)` here?

src/hotspot/share/gc/shared/partialArrayTaskStats.hpp line 90:

> 88:   // title: A string title for the table.
> 89:   template<typename StatsAccess>
> 90:   static void log_set(uint num_stats, StatsAccess access, const char* title) {

Going through all its call sites, I believe `print_stats` is more readable.

-------------

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22622#pullrequestreview-2509966063
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1889140069
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1889142484
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1889152438
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1889140874

From sspitsyn at openjdk.org  Tue Dec 17 21:05:46 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 17 Dec 2024 21:05:46 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
Message-ID: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>

The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add request a breakpoint that was already requested.

CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE

Testing:
 - tested with mach5 tiers 1-6

-------------

Commit messages:
 - 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE

Changes: https://git.openjdk.org/jdk/pull/22798/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346460
  Stats: 11 lines in 3 files changed: 7 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22798/head:pull/22798

PR: https://git.openjdk.org/jdk/pull/22798

From coleenp at openjdk.org  Tue Dec 17 21:28:47 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 17 Dec 2024 21:28:47 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata
Message-ID: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>

Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.

before:

        /* size: 216, cachelines: 4, members: 25, static members: 17 */
        /* sum members: 194, holes: 3, sum holes: 18 */


after:

        /* size: 200, cachelines: 4, members: 25, static members: 17 */
        /* sum members: 188, holes: 4, sum holes: 12 */


We may eventually move the modifiers to java.lang.Class but that's WIP.

Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

-------------

Commit messages:
 - Remove JVM_ACC_WRITTEN_FLAGS because they are all written in the classfile now.
 - 8339113: AccessFlags can be u2 in metadata

Changes: https://git.openjdk.org/jdk/pull/22246/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339113
  Stats: 167 lines in 41 files changed: 16 ins; 40 del; 111 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

PR: https://git.openjdk.org/jdk/pull/22246

From cjplummer at openjdk.org  Tue Dec 17 21:40:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 21:40:36 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
 <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>
Message-ID: <KupjLIJhBw4_jor4h6LjBEXvM2z-k5BVPRu38aVPPrE=.344109e5-e9a8-4ba0-8a60-94555fa60561@github.com>

On Tue, 17 Dec 2024 17:35:52 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/interpreter/interpreterRuntime.cpp line 580:
>> 
>>> 578:   // notify debugger of an exception catch
>>> 579:   // (this is good for exceptions caught in native methods as well)
>>> 580:   if (JvmtiExport::can_post_on_exceptions() || JvmtiExport::can_post_frame_pop()) {
>> 
>> This doesn't seem like it is related to ClearAllFramePops.
>
> Yes, it does not relate to the `ClearAllFramePops` directly. But it is needed for correctness of the `NotifyFramePop`. I do not feel it is worth to separate this change.

So this is a long standing bug hidden by the fact that if `can_post_frame_pop()` is true, then so is `can_post_on_exceptions()`:


  JvmtiExport::set_can_post_on_exceptions(
    avail.can_generate_exception_events ||
    avail.can_generate_frame_pop_events ||
    avail.can_generate_method_exit_events);

  JvmtiExport::set_can_post_frame_pop(avail.can_generate_frame_pop_events);


Or you could argue that the existing code is correct because it already captures `can_post_frame_pop()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1889259920

From cjplummer at openjdk.org  Tue Dec 17 21:44:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 17 Dec 2024 21:44:36 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <feyLIGUwsTniQCKgKA71yXtaKAufPmb_KmDrdwRZSTU=.a264a170-69cc-48b6-af74-e99c7c8793e5@github.com>

On Tue, 17 Dec 2024 21:01:51 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

src/hotspot/share/prims/jvmti.xml line 3088:

> 3086:         </error>
> 3087:         <error id="JVMTI_ERROR_DUPLICATE">
> 3088:           There is already frame pop event request at the specified depth.

Suggestion:

          There is already a frame pop event request at the specified depth.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1889263242

From stevenschlansker at gmail.com  Tue Dec 17 23:52:22 2024
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Tue, 17 Dec 2024 15:52:22 -0800
Subject: Bits.reserveMemory OutOfMemoryError does not seem to trigger
 -XX:OnOutOfMemoryError
Message-ID: <CAHjY6CVJDh4wqdHBwQNBCZZybEEVnF5X7aqj9GOA-+bs-H3JtQ@mail.gmail.com>

Hi hotspot-dev,

In our continuing mission to explore strange new VM memory limits
(aren't containers fun?), we have encountered a situation where a
un-serviceable direct memory allocation request leaves the running
application in a live but unusable state. In the container world, we
expect to run into resource misconfigurations from time to time, it
seems to be a fact of life for the moment. But having the app unable
to recover sucks.

We run:
openjdk 23.0.1+11
netty 4.1.115

A big workload spike comes in, and suddenly we allocate a lot of
memory, and run out:
java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct
buffer memory (allocated: 804069357, limit: 805306368) at
java.base/java.nio.Bits.reserveMemory(Bits.java:178) at
java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:111)
at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:363)
at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)
at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)

We configure our jvm with
'-XX:OnError=bin/crasher %p' '-XX:OnOutOfMemoryError=bin/crasher %p'

where crasher is a shell script that dumps various things and runs
kill -9 on the process to ensure recovery by kubernetes starting a new
container.

The java help page says,

> -XX:OnOutOfMemoryError=string Sets a custom command or a series of semicolon-separated commands to run when an OutOfMemoryError exception is first thrown. ...

>From a simple reading of this, it sounds like this Bits.reserveMemory
OOM should trigger the OnOutOfMemoryError handler. We would expect the
behavior to invoke the error handler, leading to a kill signal.

Instead, the program proceeds. Something quickly goes wrong with
reference counting inside of the Lettuce Redis client:

Caused by: java.lang.NullPointerException: Cannot invoke
"io.netty.buffer.ByteBuf.refCnt()" because "this.buffer" is null at
io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:597)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)

and then the whole application wedges. I reported this separately
(https://github.com/redis/lettuce/issues/3087).

While it will be nice to improve the Lettuce / Netty handling of OOME,
we felt like our configuration of OnOutOfMemoryError should have
covered this case - the help message doesn't qualify a particular type
of OOME, like "out of Java heap memory" - and a clean kill of the
process would have reduced a multi-hour outage (until a human could
notice + respond) to moments while the process restarts.

Is this an appropriate expectation? I'm happy to file an issue if this
would be considered a bug.

Thank you for your consideration.

From sspitsyn at openjdk.org  Wed Dec 18 00:22:11 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 00:22:11 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v4]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <9tTRNfROib49s9phM63-6n0itRfte7nAn6Q1mwSXOM4=.b1817c38-4c25-4cfe-b85f-743b3352e970@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: add a unit test covering JVMTI ClearAllFramePops

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/0e4ddcc1..156c1580

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=02-03

  Stats: 261 lines in 2 files changed: 261 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

PR: https://git.openjdk.org/jdk/pull/22744

From fyang at openjdk.org  Wed Dec 18 00:58:05 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Dec 2024 00:58:05 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for MacroAssembler::ctzc_bit
Message-ID: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>

Hi, please review this small improvement.

When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.

Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

-------------

Commit messages:
 - 8346475: RISC-V: Small improvement for MacroAssembler::ctzc_bit

Changes: https://git.openjdk.org/jdk/pull/22800/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22800&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346475
  Stats: 8 lines in 2 files changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22800.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22800/head:pull/22800

PR: https://git.openjdk.org/jdk/pull/22800

From zgu at openjdk.org  Wed Dec 18 01:09:37 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 18 Dec 2024 01:09:37 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
Message-ID: <raZi-Bp7m_BMTtR_pDCFBJu_W29MEvzyyF4qt6qAbls=.b423c349-ac06-4500-aeb5-f84ab3b646f8@github.com>

On Tue, 17 Dec 2024 18:08:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - merge log_set decl/defn
>  - remove default counts for stats incrementers
>  - remove uneeded 'explicit'
>  - cleanup unneeded includes
>  - remove moved-from macro defines
>  - Merge branch 'master' into pa-splitter
>  - rename splitter.step() => claim()
>  - simplify comments
>  - Merge branch 'master' into pa-splitter
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/9fad115b...54c37988

LGTM

-------------

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22622#pullrequestreview-2510521893

From david.holmes at oracle.com  Wed Dec 18 01:31:55 2024
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Dec 2024 11:31:55 +1000
Subject: Bits.reserveMemory OutOfMemoryError does not seem to trigger
 -XX:OnOutOfMemoryError
In-Reply-To: <CAHjY6CVJDh4wqdHBwQNBCZZybEEVnF5X7aqj9GOA-+bs-H3JtQ@mail.gmail.com>
References: <CAHjY6CVJDh4wqdHBwQNBCZZybEEVnF5X7aqj9GOA-+bs-H3JtQ@mail.gmail.com>
Message-ID: <00c063ad-270f-4a3d-a49c-9efabb360b8c@oracle.com>

Hi Steven,

The -XX OOM relating flags are only for OOM conditions directly detected 
by the VM itself - please also see:

https://bugs.openjdk.org/browse/JDK-8257790

Unfortunately the java mapage documentation didn't get updated to make 
this clear, but I will address that. We did clarify in the source [1]:

   product(ccstrlist, OnOutOfMemoryError, "", 
     \
           "Run user-defined commands on first 
java.lang.OutOfMemoryError "  \
           "thrown from JVM") 
     \

You need to handle Java triggered OOM conditions in the Java code.

David
-----

[1] https://bugs.openjdk.org/browse/JDK-8258058

On 18/12/2024 9:52 am, Steven Schlansker wrote:
> Hi hotspot-dev,
> 
> In our continuing mission to explore strange new VM memory limits
> (aren't containers fun?), we have encountered a situation where a
> un-serviceable direct memory allocation request leaves the running
> application in a live but unusable state. In the container world, we
> expect to run into resource misconfigurations from time to time, it
> seems to be a fact of life for the moment. But having the app unable
> to recover sucks.
> 
> We run:
> openjdk 23.0.1+11
> netty 4.1.115
> 
> A big workload spike comes in, and suddenly we allocate a lot of
> memory, and run out:
> java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct
> buffer memory (allocated: 804069357, limit: 805306368) at
> java.base/java.nio.Bits.reserveMemory(Bits.java:178) at
> java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:111)
> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:363)
> at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)
> at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)
> 
> We configure our jvm with
> '-XX:OnError=bin/crasher %p' '-XX:OnOutOfMemoryError=bin/crasher %p'
> 
> where crasher is a shell script that dumps various things and runs
> kill -9 on the process to ensure recovery by kubernetes starting a new
> container.
> 
> The java help page says,
> 
>> -XX:OnOutOfMemoryError=string Sets a custom command or a series of semicolon-separated commands to run when an OutOfMemoryError exception is first thrown. ...
> 
>  From a simple reading of this, it sounds like this Bits.reserveMemory
> OOM should trigger the OnOutOfMemoryError handler. We would expect the
> behavior to invoke the error handler, leading to a kill signal.
> 
> Instead, the program proceeds. Something quickly goes wrong with
> reference counting inside of the Lettuce Redis client:
> 
> Caused by: java.lang.NullPointerException: Cannot invoke
> "io.netty.buffer.ByteBuf.refCnt()" because "this.buffer" is null at
> io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:597)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
> 
> and then the whole application wedges. I reported this separately
> (https://github.com/redis/lettuce/issues/3087).
> 
> While it will be nice to improve the Lettuce / Netty handling of OOME,
> we felt like our configuration of OnOutOfMemoryError should have
> covered this case - the help message doesn't qualify a particular type
> of OOME, like "out of Java heap memory" - and a clean kill of the
> process would have reduced a multi-hour outage (until a human could
> notice + respond) to moments while the process restarts.
> 
> Is this an appropriate expectation? I'm happy to file an issue if this
> would be considered a bug.
> 
> Thank you for your consideration.


From dholmes at openjdk.org  Wed Dec 18 01:54:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 01:54:46 GMT
Subject: RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java failed
 with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
References: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
Message-ID: <YhFn5PHSKQTIaeuLpc0stYBthuJlKh7ujmIbsmyUSAY=.c5e803ea-8eb3-451e-82bc-e00aee61c480@github.com>

On Mon, 16 Dec 2024 06:33:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the strace tests that adds a check for a null entry.
> 
> Testing:
>   - self
>   - tiers 1-3 (sanity)
> 
> Thanks

Thanks for the review @hamlin-li !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22756#issuecomment-2550103109

From dholmes at openjdk.org  Wed Dec 18 01:54:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 01:54:46 GMT
Subject: Integrated: 8321818: vmTestbase/nsk/stress/strace/strace015.java
 failed with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
References: <n_PFG9tgeNkyYKsEnvrWJj7Gb9Z4ep5bzpNhZBnkME0=.e1d8f256-f33b-4447-abc1-173bff284d65@github.com>
Message-ID: <fORiYwOL0WIPFMBPQ-jiRxGVjaVAqNqR_2RNaNPLn98=.81789e79-1f5e-42cf-8ebe-2d8e667927cb@github.com>

On Mon, 16 Dec 2024 06:33:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple update to the strace tests that adds a check for a null entry.
> 
> Testing:
>   - self
>   - tiers 1-3 (sanity)
> 
> Thanks

This pull request has now been integrated.

Changeset: ea50c54a
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea50c54a14d39fcedabe8426a14eaec27ab24af2
Stats:     53 lines in 9 files changed: 45 ins; 0 del; 8 mod

8321818: vmTestbase/nsk/stress/strace/strace015.java failed with 'Cannot read the array length because "<local4>" is null'

Reviewed-by: lmesnik, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22756

From sspitsyn at openjdk.org  Wed Dec 18 03:12:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 03:12:14 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: minor tweak in jvmti.xml update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/57aa3bdb..4106c10a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22798/head:pull/22798

PR: https://git.openjdk.org/jdk/pull/22798

From sspitsyn at openjdk.org  Wed Dec 18 03:28:30 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 03:28:30 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: removed unneeded check for JvmtiExport::can_post_frame_pop()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/156c1580..850cafbd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

PR: https://git.openjdk.org/jdk/pull/22744

From sspitsyn at openjdk.org  Wed Dec 18 03:28:31 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 18 Dec 2024 03:28:31 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v2]
In-Reply-To: <KupjLIJhBw4_jor4h6LjBEXvM2z-k5BVPRu38aVPPrE=.344109e5-e9a8-4ba0-8a60-94555fa60561@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <ZRy14pWsrwLIt0gIx4_R1eG4l2Yn49ydEUxdftlCHfo=.b885d12c-f033-4bc3-a115-627a290079e6@github.com>
 <YqbG3ukjXorcimUUIlWZlfe7kFdQmOjKWoEX-w_PVrY=.9323d609-79fb-491a-bab0-2904d97c96cd@github.com>
 <4fDg6b_3Dpu0Cd9vlcei4gGCyyu8hE-y2Mvisb0Lp98=.7d02241a-d75b-4de6-888d-996d4fb7dcd5@github.com>
 <KupjLIJhBw4_jor4h6LjBEXvM2z-k5BVPRu38aVPPrE=.344109e5-e9a8-4ba0-8a60-94555fa60561@github.com>
Message-ID: <BT2nbOFXdsq1Y62-odoZIG1oGz9KGU09VcrFCDjbchw=.ed98967f-0d11-4315-9c2f-a2a9c4f33428@github.com>

On Tue, 17 Dec 2024 21:38:28 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Yes, it does not relate to the `ClearAllFramePops` directly. But it is needed for correctness of the `NotifyFramePop`. I do not feel it is worth to separate this change.
>
> So this is a long standing bug hidden by the fact that if `can_post_frame_pop()` is true, then so is `can_post_on_exceptions()`:
> 
> 
>   JvmtiExport::set_can_post_on_exceptions(
>     avail.can_generate_exception_events ||
>     avail.can_generate_frame_pop_events ||
>     avail.can_generate_method_exit_events);
> 
>   JvmtiExport::set_can_post_frame_pop(avail.can_generate_frame_pop_events);
> 
> 
> Or you could argue that the existing code is correct because it already captures `can_post_frame_pop()`.

Good check, thanks! Rolled back this change. I remember that I've added this because some of the tests was failing. Most likely, I had made a wrong conclusion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1889553986

From dholmes at openjdk.org  Wed Dec 18 04:18:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 04:18:44 GMT
Subject: Integrated: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures
In-Reply-To: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
Message-ID: <l1YalF1B94LPRQnWxUFEW7uh-e-fyvtOU8doU7-HRUY=.aca72542-5e62-48ea-a941-949542d2d16a@github.com>

On Thu, 12 Dec 2024 05:25:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
> 
> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
> 
> as inspection of the class sources will show the expected `permits` and `extends` clauses.
> 
> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
> 
> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
> 
> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
> 
> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
> 
> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the quer
 ies - but we could do it for conveni...

This pull request has now been integrated.

Changeset: 45331091
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/453310918b5d1a284d8467aab797e349d3fb5e14
Stats:     158 lines in 15 files changed: 110 ins; 4 del; 44 mod

8345911: Enhance error message when IncompatibleClassChangeError is thrown for sealed class loading failures

Reviewed-by: coleenp, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22703

From dholmes at openjdk.org  Wed Dec 18 04:18:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 04:18:43 GMT
Subject: RFR: 8345911: Enhance error message when
 IncompatibleClassChangeError is thrown for sealed class loading failures [v5]
In-Reply-To: <nQDwn2PlcSzhILUy5kBwLeLcx9AUxuysRAPDOZvJJ-4=.e02c92c3-b457-4724-9e9f-7c6f9dfc0dfe@github.com>
References: <4vMHYkNh-BlUTxcBVR0hKDcsnBpF3AkIo9CXh3uQFyc=.48a3f1a4-f28c-4998-afc9-5d2d5ecb7678@github.com>
 <nQDwn2PlcSzhILUy5kBwLeLcx9AUxuysRAPDOZvJJ-4=.e02c92c3-b457-4724-9e9f-7c6f9dfc0dfe@github.com>
Message-ID: <iam53Zz2PaqQ3WMo8pPOvqnJykeelY6251Eb9Nfn7Mk=.708714ae-2afb-4ae3-b68f-a7560bf0f614@github.com>

On Tue, 17 Dec 2024 04:19:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> When a sealed superclass and its permitted subclass get loaded by different classloaders they end up in different modules (the unnamed module of each loader) and cause an `IncompatibleClassChangeError` to be thrown when loading the subclass. The existing error message is not very useful in recognizing this situation:
>> 
>> java.lang.IncompatibleClassChangeError: class SealedSubClass cannot inherit from sealed class SealedClass
>> 
>> as inspection of the class sources will show the expected `permits` and `extends` clauses.
>> 
>> This change augments the `InstanceKlass::has_as_permitted_subclass` method to provide a means to return a meaningful error message to the `ClassFileParser` callers for use in any ICCE that is to be thrown. That same message is shared between unified logging within the method, and the throwing of the ICCE by the caller. We introduce a new helper to throw the ICCE in this case.
>> 
>> The changes also adds a little helper method to `ModuleEntry` to make it easier to gets its name.
>> 
>> The existing tests are updated to reflect the updated error messages, and a new test for the missing "different module" situation is added.
>> 
>> Note: as with the existing logging code the message always refers to class/subclass when in some cases it is really interface and/or subinterface. This can be changed to be more accurate but greatly complicates the formulation of the messages. It is not uncommon to use "(sub)class" when we mean "(sub)class or (sub)interface".
>> 
>> The presented implementation exposes the error message by having the caller pass in a `stringStream` which is then used to store the message. This has the downside of always requiring a `stringStream` in the caller, even if there is no problem to report. Alternatively, we could create the `stringStream` in the callee and then "return" its `as_string()` result to the caller via an out parameter (e.g. `char** error_msg`). However because of the lifetime of the `stringStream` we would need to `os::strdup` the `as_string()` value before returning it, and then free it in the caller. A third alternative would be to push the throwing of the ICCE down into the `InstanceKlass` method so there is no need to pass the message around - though that blurs the line of "division of responsibility" between checking the condition and deciding it should result in ICCE being thrown (the normal pattern is to have the `ClassFileParser` code make that decision, while `InstanceKlass` just provides the que
 ries - ...
>
> David Holmes has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Coleen's suggestions

Thanks for the reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22703#issuecomment-2550293375

From dholmes at openjdk.org  Wed Dec 18 04:20:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 04:20:37 GMT
Subject: RFR: 8346306: Unattached thread can cause crash during VM exit if
 it calls wait_if_vm_exited
In-Reply-To: <NHQ44mT_t8faMvQRrby00HqGS8lWXjVqyDPIKZRv-HY=.e5457d3d-b5fc-47cc-a93a-ff675595739a@github.com>
References: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
 <NHQ44mT_t8faMvQRrby00HqGS8lWXjVqyDPIKZRv-HY=.e5457d3d-b5fc-47cc-a93a-ff675595739a@github.com>
Message-ID: <blZXEs8iXh4qwk-KhnOhEyKEgMRpSL05OsqKCI9xrX8=.4961d6a6-ee82-489b-8555-9e99eb04d67a@github.com>

On Tue, 17 Dec 2024 14:34:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this simple fix to account for unattached threads using RawMonitors which check if the VM has exited.
>> 
>> Testing:
>>  - tiers 1-3 (sanity)
>> 
>> Thanks
>
> This makes sense.

Thanks for the review @coleenp !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22779#issuecomment-2550297325

From dholmes at openjdk.org  Wed Dec 18 04:39:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 04:39:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
Message-ID: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>

On Tue, 17 Dec 2024 15:46:01 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updates tests and remove old class

The direct use of CML is functionally correct but requires leaking knowledge to all the use-sites that should not need to know about the actual condition for locking. This really needs to be encapsulated which means we need to be able to subclass CML.

@kbarrett what is needed to make `ConditionalMutexLocker` subclassable?

src/hotspot/os/windows/os_windows.cpp line 3624:

> 3622: #ifdef ASSERT
> 3623:       fileStream fs(stdout);
> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);

Why was this change made? tty could be stdout or stderr depending on VM flag settings.

src/hotspot/share/runtime/threads.cpp line 530:

> 528: 
> 529:   // Once mutexes are ready, we can use NMT locks.
> 530:   MemTracker::set_done_bootstrap();

This should be done after the main thread has attached and set the current thread, otherwise if we hit any NMT code that needs the lock it would crash trying to acquire it.

src/hotspot/share/utilities/vmError.cpp line 720:

> 718: 
> 719:   BEGIN
> 720:   if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr && NmtVirtualMemory_lock->owned_by_self()) {

Suggestion:

  if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr  && MemTracker::is_done_bootstrap() && NmtVirtualMemory_lock->owned_by_self()) {

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2510765294
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1889595113
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1889598981
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1889600501

From fyang at openjdk.org  Wed Dec 18 04:46:08 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Dec 2024 04:46:08 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines
Message-ID: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>

Hi, please consider this cleanup change.

Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check
about the immediate range and save the tmp register used by the latter as well. In order to make the code more readable, this
also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.

Testing: tier1-3 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

-------------

Commit messages:
 - 8346478: RISC-V: Refactor add/sub assembler routines

Changes: https://git.openjdk.org/jdk/pull/22804/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346478
  Stats: 392 lines in 19 files changed: 14 ins; 6 del; 372 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

PR: https://git.openjdk.org/jdk/pull/22804

From dholmes at openjdk.org  Wed Dec 18 05:26:09 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 05:26:09 GMT
Subject: [jdk24] RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java
 failed with 'Cannot read the array length because "<local4>" is null'
Message-ID: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>

Simple backport of test fixes.

Thanks

-------------

Commit messages:
 - Backport ea50c54a14d39fcedabe8426a14eaec27ab24af2

Changes: https://git.openjdk.org/jdk/pull/22801/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321818
  Stats: 53 lines in 9 files changed: 45 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22801.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22801/head:pull/22801

PR: https://git.openjdk.org/jdk/pull/22801

From epeter at openjdk.org  Wed Dec 18 06:22:42 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Dec 2024 06:22:42 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v6]
In-Reply-To: <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>
Message-ID: <q8IuUJ4fGxWZEyh9EWXRV2DXRpHg8h8Wr3U88_33GT8=.efab776b-d561-4f9c-b714-ad7d116f00ac@github.com>

On Tue, 17 Dec 2024 18:12:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - Fix style
>  - Add max reduction test
>  - Add empty line

test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 2:

> 1: /*
> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Suggestion:

 * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1889678576

From epeter at openjdk.org  Wed Dec 18 06:25:37 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Wed, 18 Dec 2024 06:25:37 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
 <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>
 <BVCdpvLHRak1YFlcQJhM2W9NObn89vKx81p77y_EN6I=.9069e2ea-10ad-4747-847a-bf752886c2ab@github.com>
 <razvT5p84D36NIaNS1d1Szi8VUEgzxA9uYBdUiMpj9g=.3db3054f-6ea1-4ba1-8dd4-f047c2b06c3b@github.com>
 <QlwwUI2A1KgnIu0ZPsfh3iaNWb686AL7Z2R2GNNmyq4=.21d9b469-7efd-4e0b-95ab-c5eda8a42c0d@github.com>
Message-ID: <W_1aMfdcikW9rZAmSoHBAP4bxFN5NHAP_Oqkzq_xspQ=.22aa9b09-05f9-4c2b-8f9b-6c3668119ad9@github.com>

On Tue, 17 Dec 2024 18:20:36 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> @galderz Yes, there is significant duplication, sadly. Often there were old tests there, but then one comes along and sees that one wants to have more comprehensive tests. So one adds it, but does not feel 100% comfortable removing old tests. A little bit of duplication is probably ok. Often, there are still subtle differences, and sometimes those end up mattering.
>> 
>> `compiler/loopopts/superword/MinMaxRed_Long.java` sounds like a good idea.
>
> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further.
> 
> @jaskarth FYI I've adjusted the expectations in `TestMinMaxIdentities` after this change (thx for adding the test!). Check if there's any comments/changes you'd like.

@galderz Nice, thanks for the updates. I gave the patch a quick scan and I think it looks really good. Just ping me again when you are done with your aarch64 investigations, and you think I should review again :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2550456266

From syan at openjdk.org  Wed Dec 18 07:28:50 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 18 Dec 2024 07:28:50 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v2]
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  update comment "Use volatile to prevent compiler from optimising away the store"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22757/files
  - new: https://git.openjdk.org/jdk/pull/22757/files/3a8e4349..caa26be4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22757&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22757&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22757/head:pull/22757

PR: https://git.openjdk.org/jdk/pull/22757

From syan at openjdk.org  Wed Dec 18 08:30:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 18 Dec 2024 08:30:36 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v2]
In-Reply-To: <qyEGVBwEWUAvOsStjROe2_eid-ouQ7fUtBv2HoIQLlg=.511ef1fd-d622-4ab8-89cb-7faf015aa6bb@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <qyEGVBwEWUAvOsStjROe2_eid-ouQ7fUtBv2HoIQLlg=.511ef1fd-d622-4ab8-89cb-7faf015aa6bb@github.com>
Message-ID: <UTMlUvwovHvWAr6_XOi0g5ZS5XFa2U2fwU_TRme5QpQ=.9afb38a1-f33c-4858-ab0d-92de068f4811@github.com>

On Tue, 17 Dec 2024 07:06:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comment "Use volatile to prevent compiler from optimising away the store"
>
> src/hotspot/share/runtime/frame.cpp line 1166:
> 
>> 1164:   // simulate GC crash here to dump java thread in error report
>> 1165:   if (CrashGCForDumpingJavaThread) {
>> 1166:     volatile char *t = nullptr; // Use volatile modifier to make clang avoid 'dead code' elimination
> 
> Suggestion:
> 
>     volatile char* t = nullptr; // Use volatile to prevent compiler from optimising away the store

Thanks David. The comment had been updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1889814710

From syan at openjdk.org  Wed Dec 18 09:01:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 18 Dec 2024 09:01:37 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v2]
In-Reply-To: <FpkeIwcZ9nkepIbw-S5JLEmg166CgImqw5_OpYR9pBo=.a7c43da3-265f-4df7-a84c-17bf3004e1e7@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <FpkeIwcZ9nkepIbw-S5JLEmg166CgImqw5_OpYR9pBo=.a7c43da3-265f-4df7-a84c-17bf3004e1e7@github.com>
Message-ID: <0rT3bcm0FZGJl_LGLBs2XUkLdI24GXZc6I5We9MsOtk=.3adc51db-5b42-47d9-aed2-d3e017bd059c@github.com>

On Tue, 17 Dec 2024 11:00:56 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Would `ShouldNotReachHere();` be more secure?

There is a bit diffrence between `ShouldNotReachHere();` and `*t = 'c';`

1. `ShouldNotReachHere();` cause jvm trigger `Internal Error` and then crash.
2. `*t = 'c';` cause jvm receive `SIGSEGV` signal, and then  crash.

The test `runtime/ErrorHandling/TestDwarf.java` try to test various kinds jvm errors, such as `unsafeAccess`/`outOfMemory`/`abortVMOnException`/`nativeDivByZero` etc. I don't known change `*t = 'c';` to `ShouldNotReachHere();` could change the test intention or not. So I'm inclined to keep this unchange, just add `volatile` modifier.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2550739950

From duke at openjdk.org  Wed Dec 18 09:30:42 2024
From: duke at openjdk.org (Yuri Gaevsky)
Date: Wed, 18 Dec 2024 09:30:42 GMT
Subject: RFR: 8324124: RISC-V: implement _vectorizedMismatch intrinsic
In-Reply-To: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
References: <dxSBhJiLeVkLF8PvHW3MMg69vwXU0VshECCMz5HnhhI=.e0cbda8b-f7f6-44ff-806b-1f21496911be@github.com>
Message-ID: <e1Kafez5XL0PmDrxEJKld9xBLof2S65c0P-s1f6PPps=.1cc4ae37-5661-47c3-875e-e6b5baa2ea2b@github.com>

On Wed, 7 Feb 2024 14:35:55 GMT, Yuri Gaevsky <duke at openjdk.org> wrote:

> Hello All,
> 
> Please review these changes to enable the __vectorizedMismatch_ intrinsic on RISC-V platform with RVV instructions supported.
> 
> Thank you,
> -Yuri Gaevsky
> 
> **Correctness checks:**
>   hotspot/jtreg/compiler/{intrinsic/c1/c2}/ under QEMU-8.1 with RVV v1.0.0 and -XX:TieredStopAtLevel=1/2/3/4.

.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17750#issuecomment-2550817813

From mli at openjdk.org  Wed Dec 18 09:49:36 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 18 Dec 2024 09:49:36 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v2]
In-Reply-To: <0rT3bcm0FZGJl_LGLBs2XUkLdI24GXZc6I5We9MsOtk=.3adc51db-5b42-47d9-aed2-d3e017bd059c@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <FpkeIwcZ9nkepIbw-S5JLEmg166CgImqw5_OpYR9pBo=.a7c43da3-265f-4df7-a84c-17bf3004e1e7@github.com>
 <0rT3bcm0FZGJl_LGLBs2XUkLdI24GXZc6I5We9MsOtk=.3adc51db-5b42-47d9-aed2-d3e017bd059c@github.com>
Message-ID: <kEWHanBSLMG2CpftNjfYfgY0HSzYAVhWxglpDF6ei6k=.a319ffcd-8f34-44d2-82cc-f071d1765ab9@github.com>

On Wed, 18 Dec 2024 08:59:26 GMT, SendaoYan <syan at openjdk.org> wrote:

> There is a bit diffrence between `ShouldNotReachHere();` and `*t = 'c';`
> 
> 1. `ShouldNotReachHere();` cause jvm trigger `Internal Error` and then crash.
> 2. `*t = 'c';` cause jvm receive `SIGSEGV` signal, and then  crash.
> 

I see, thanks for explanation.
But seems the test does not check the crash details (i.e. the difference you mentioned above)?

> The test `runtime/ErrorHandling/TestDwarf.java` try to test various kinds jvm errors, such as `unsafeAccess`/`outOfMemory`/`abortVMOnException`/`nativeDivByZero` etc. I don't known change `*t = 'c';` to `ShouldNotReachHere();` could change the original test intention or not. So I'm inclined to keep this unchange, just add `volatile` modifier.

My only concern is that the current fix depends on the internal implementation and the effect of a compilation flag of clang, this is not stable, which means that in the future, it could fail for the similar reason. (In this sense, the change could also impact gcc behaviour.) IMHO, it would be better to use existing APIs in the JVM to implement this functionality.
But I'm not an expert of clang, so my above statement about clang could be wrong.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2550860244

From jbechberger at openjdk.org  Wed Dec 18 10:11:33 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 18 Dec 2024 10:11:33 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v33]
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <hnv3YxlKvm7AnIiEu9sNgGgu3YNZPG7a0iKu1JlHVLY=.87fa58e9-774b-4932-8112-64c8ba2af02a@github.com>

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Handle weakened vthread-epoch identity invariant

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20752/files
  - new: https://git.openjdk.org/jdk/pull/20752/files/020bbe98..d17c39e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=31-32

  Stats: 9 lines in 2 files changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/20752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752

PR: https://git.openjdk.org/jdk/pull/20752

From stefank at openjdk.org  Wed Dec 18 10:21:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 18 Dec 2024 10:21:49 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <tdhhNj0l3--1dPqKYi2cUz5t1B8mrQUbCNwICGthPhI=.6d5bac90-9375-4cc9-887e-a0af6a73097d@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

I merged and ran tier1 internally and GHA. Thanks again for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2550930159

From stefank at openjdk.org  Wed Dec 18 10:21:52 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 18 Dec 2024 10:21:52 GMT
Subject: Integrated: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <wIdt2Qz9l1hmnuN6WG4M1PszURSof4VEYv0rllrNjHI=.21eba295-4030-42e7-b56b-9c95cf418d92@github.com>

On Thu, 12 Dec 2024 13:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

This pull request has now been integrated.

Changeset: 73b5dbae
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73b5dbaec340b3e8c958d63f510df92ec621c04e
Stats:     2113 lines in 59 files changed: 1182 ins; 806 del; 125 mod

8345655: Move reservation code out of ReservedSpace

Reviewed-by: azafari, jsjolen

-------------

PR: https://git.openjdk.org/jdk/pull/22712

From jbechberger at openjdk.org  Wed Dec 18 10:22:10 2024
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 18 Dec 2024 10:22:10 GMT
Subject: RFR: 8342818: Implement CPU Time Profiling for JFR [v34]
In-Reply-To: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
References: <onBUNQab1zJ6z4ikWiBchj9iPClMEouwXJhDILwgCVI=.36fbf394-81a6-4884-8b65-da51194757b2@github.com>
Message-ID: <P8XN6rCGezelIOVQ3QyZmVy53jXH8P7nyQXiWc3FPI0=.b790e716-6c85-4b8b-88ee-adc1ed99043b@github.com>

> This is the code for the [JEP draft: CPU Time based profiling for JFR].

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 160 commits:

 - Merge branch 'master' into parttimenerd_jfr_cpu_time_sampler4
 - Handle weakened vthread-epoch identity invariant
 - Fix build
 - Merge branch 'master' into parttimenerd_jfr_cpu_time_sampler4
 - Fix disenroll issue
 - Merge remote-tracking branch 'origin' into parttimenerd_jfr_cpu_time_sampler4
 - Fix zero build
 - Simplify #ifdefs to fix minimal and zero builds
 - Merge remote-tracking branch 'origin' into parttimenerd_jfr_cpu_time_sampler4
 - Compute actual sampling period via si_overrun
 - ... and 150 more: https://git.openjdk.org/jdk/compare/d50b725a...d1574a29

-------------

Changes: https://git.openjdk.org/jdk/pull/20752/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20752&range=33
  Stats: 2630 lines in 53 files changed: 2420 ins; 176 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/20752.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20752/head:pull/20752

PR: https://git.openjdk.org/jdk/pull/20752

From cnorrbin at openjdk.org  Wed Dec 18 10:46:53 2024
From: cnorrbin at openjdk.org (Casper Norrbin)
Date: Wed, 18 Dec 2024 10:46:53 GMT
Subject: RFR: 8345314: Add a =?UTF-8?B?cmVk4oCTYmxhY2s=?= tree as a utility
 data structure [v7]
In-Reply-To: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
References: <Wai38-BVD68uo7uFneJtTqaEesx9UiDaLJ40uTDsUCw=.10e92399-115f-409c-a76b-ffebaab44b62@github.com>
Message-ID: <HO2dg7E_mQnjRKkWWliH_dMml8whmGh-Nk0F2yKQTdE=.8e681837-6b98-412d-9a9f-f56fcc21985d@github.com>

> Hi everyone,
> 
> This effort began as an exploration of replacing the current NMT treap with a red-black tree. Along the way, I discovered that others were also interested in having a general-purpose tree structure available within HotSpot.
> 
> The red-black tree is designed to serve as a drop-in replacement for the existing NMT treap, keeping a nearly identical interface. However, I?ve also added a few additional requested features, such as an iterator.
> 
> Testing builds off the treap tests, adding a few extra that inserts/removes and checks that the tree is correct. Testing uses the function `verify_self`, which iterates over the tree and checks that all red-black tree properties hold. Additionally, the tree has been tested in vmatree instead of the treap without any errors.
> 
> For those who may want to revisit the fundamentals of red-black trees, [Wikipedia](https://en.wikipedia.org/wiki/Red%E2%80%93black_tree) offers a great summary with tables covering the various balancing cases. Alternatively, your favorite data structure book could provide even more insight.

Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision:

  renamed coloring functions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22360/files
  - new: https://git.openjdk.org/jdk/pull/22360/files/3705c1ef..505c7f8d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22360&range=05-06

  Stats: 25 lines in 2 files changed: 1 ins; 3 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/22360.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22360/head:pull/22360

PR: https://git.openjdk.org/jdk/pull/22360

From mli at openjdk.org  Wed Dec 18 12:08:37 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 18 Dec 2024 12:08:37 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit
In-Reply-To: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
Message-ID: <Oav4GUUkK8KeRS9hnWyrgYFmlue1pY4cTQKAWWUs5NU=.41ead2ed-b982-4806-8c0b-0a494e66fb23@github.com>

On Wed, 18 Dec 2024 00:47:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this small improvement.
> 
> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
> 
> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

Looks good. Thanks!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22800#pullrequestreview-2511642056

From mli at openjdk.org  Wed Dec 18 12:14:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 18 Dec 2024 12:14:38 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit
In-Reply-To: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
Message-ID: <2bVqKFLLKQCHseIqQQ0-pqUF1_ARkGgp-wCvSA6wS64=.dae78de6-5bb7-4e52-97ff-19935d3ee283@github.com>

On Wed, 18 Dec 2024 00:47:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this small improvement.
> 
> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
> 
> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

Sorry, just realize this.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5404:

> 5402:                               Register tmp1, Register tmp2) {
> 5403:   if (UseZbb) {
> 5404:     assert_different_registers(Rd, Rs, tmp1);

Is it necessary for Rd/Rs be different registers? similar question for the assert below.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22800#pullrequestreview-2511652525
PR Review Comment: https://git.openjdk.org/jdk/pull/22800#discussion_r1890136404

From syan at openjdk.org  Wed Dec 18 12:59:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 18 Dec 2024 12:59:39 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v2]
In-Reply-To: <kEWHanBSLMG2CpftNjfYfgY0HSzYAVhWxglpDF6ei6k=.a319ffcd-8f34-44d2-82cc-f071d1765ab9@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <FpkeIwcZ9nkepIbw-S5JLEmg166CgImqw5_OpYR9pBo=.a7c43da3-265f-4df7-a84c-17bf3004e1e7@github.com>
 <0rT3bcm0FZGJl_LGLBs2XUkLdI24GXZc6I5We9MsOtk=.3adc51db-5b42-47d9-aed2-d3e017bd059c@github.com>
 <kEWHanBSLMG2CpftNjfYfgY0HSzYAVhWxglpDF6ei6k=.a319ffcd-8f34-44d2-82cc-f071d1765ab9@github.com>
Message-ID: <TvdOajd-ohVXMeDRAgHb52iZa-uFvFmGfSA0vAuxDTs=.80b19968-1ce0-4861-842c-aee311fc905b@github.com>

On Wed, 18 Dec 2024 09:47:23 GMT, Hamlin Li <mli at openjdk.org> wrote:

> the current fix depends on the internal implementation and the effect of a compilation flag of clang, this is not stable

I don't think the current fix is not stable. According the cppreference documentation:

1.  [volatile accesses cannot be optimized out](https://en.cppreference.com/w/cpp/language/cv) 
2. [Accesses (reads and writes) to volatile objects occur strictly according to the semantics of the expressions in which they occur.](https://en.cppreference.com/w/cpp/language/as_if)

> seems the test does not check the crash details

Yes, use `ShouldNotReachHere();` instead of `*t = 'c';`, the test still run passed which tested jdk build from gcc. From this perspective, use `ShouldNotReachHere();` also acceptable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2551257350

From fyang at openjdk.org  Wed Dec 18 13:29:18 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Dec 2024 13:29:18 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v2]
In-Reply-To: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
Message-ID: <NfCSuXwUXkgdLwVxnTerH0vBkBMUIc71V0Ncdm0YOAk=.11de3468-1033-402d-98c9-954766e68e9a@github.com>

> Hi, please review this small improvement.
> 
> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
> 
> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22800/files
  - new: https://git.openjdk.org/jdk/pull/22800/files/1f86156b..f4d9b181

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22800&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22800&range=00-01

  Stats: 29 lines in 4 files changed: 11 ins; 3 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/22800.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22800/head:pull/22800

PR: https://git.openjdk.org/jdk/pull/22800

From fyang at openjdk.org  Wed Dec 18 13:29:18 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Dec 2024 13:29:18 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v2]
In-Reply-To: <2bVqKFLLKQCHseIqQQ0-pqUF1_ARkGgp-wCvSA6wS64=.dae78de6-5bb7-4e52-97ff-19935d3ee283@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
 <2bVqKFLLKQCHseIqQQ0-pqUF1_ARkGgp-wCvSA6wS64=.dae78de6-5bb7-4e52-97ff-19935d3ee283@github.com>
Message-ID: <btwcnkoLVgQYlaRHGtkKbQm1ecRSCjFdfhx6Vqxw6qM=.4e614660-fc1a-45e5-aed5-7304a3db795a@github.com>

On Wed, 18 Dec 2024 12:10:51 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5404:
> 
>> 5402:                               Register tmp1, Register tmp2) {
>> 5403:   if (UseZbb) {
>> 5404:     assert_different_registers(Rd, Rs, tmp1);
> 
> Is it necessary for Rd/Rs be different registers? similar question for the assert below.

Good question. I don't think it's necessary to put `Rs` on the list. But we need to swap the two `mv`s for the second assertion in case `Rd` and `Rs` are the same. I also renamed `ctzc_bit` to `ctzc_bits` as appropriate and added code comments for the callsites. Please take another look. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22800#discussion_r1890236776

From mli at openjdk.org  Wed Dec 18 14:13:41 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 18 Dec 2024 14:13:41 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v2]
In-Reply-To: <NfCSuXwUXkgdLwVxnTerH0vBkBMUIc71V0Ncdm0YOAk=.11de3468-1033-402d-98c9-954766e68e9a@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
 <NfCSuXwUXkgdLwVxnTerH0vBkBMUIc71V0Ncdm0YOAk=.11de3468-1033-402d-98c9-954766e68e9a@github.com>
Message-ID: <H62NuNC4eUrYguImmK__w7Ovb6PwP7o5CepZwC6GOnE=.5bf62350-e092-4429-9f2a-3343c715fbeb@github.com>

On Wed, 18 Dec 2024 13:29:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please review this small improvement.
>> 
>> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
>> 
>> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Another comment.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5408:

> 5406:     ctz(Rd, Rs);
> 5407:     andi(tmp1, Rd, step - 1);
> 5408:     sub(Rd, Rd, tmp1);

Seems these 2 lines can be replaced with single instruction:

andi Rd, Rd, -step

-------------

PR Review: https://git.openjdk.org/jdk/pull/22800#pullrequestreview-2511957263
PR Review Comment: https://git.openjdk.org/jdk/pull/22800#discussion_r1890305395

From mli at openjdk.org  Wed Dec 18 14:19:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 18 Dec 2024 14:19:39 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v2]
In-Reply-To: <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>
Message-ID: <AC_zChPPGJoDrKSAlbiin867Zsoq6F4fQYEAt0oPmJo=.c70396de-c201-485f-8661-969a2c24eab6@github.com>

On Wed, 18 Dec 2024 07:28:50 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comment "Use volatile to prevent compiler from optimising away the store"

I see, thanks for the information. Then the change looks good to me.
`ShouldNotReachHere();` seems better to me, but you have the final say.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22757#issuecomment-2551436683

From fjiang at openjdk.org  Wed Dec 18 14:23:41 2024
From: fjiang at openjdk.org (Feilong Jiang)
Date: Wed, 18 Dec 2024 14:23:41 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v2]
In-Reply-To: <NfCSuXwUXkgdLwVxnTerH0vBkBMUIc71V0Ncdm0YOAk=.11de3468-1033-402d-98c9-954766e68e9a@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
 <NfCSuXwUXkgdLwVxnTerH0vBkBMUIc71V0Ncdm0YOAk=.11de3468-1033-402d-98c9-954766e68e9a@github.com>
Message-ID: <WIBb17WMTJ0usOzEbRbE4Z7qRRYU-_CE9EWQjN2Kzqo=.2735d8dc-2f3b-4c6a-92ba-7c89008a0a83@github.com>

On Wed, 18 Dec 2024 13:29:18 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please review this small improvement.
>> 
>> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
>> 
>> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Looks good, thanks!

-------------

Marked as reviewed by fjiang (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22800#pullrequestreview-2511982961

From mli at openjdk.org  Wed Dec 18 14:37:13 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 18 Dec 2024 14:37:13 GMT
Subject: [jdk24] RFR: 8345669: RISC-V: fix client build failure due to
 AlignVector after JDK-8343827
Message-ID: <FpGN_oaIRHHS-M2HwWjxQg7YBuQOiljZiLQ8jXVjgH4=.4fab5286-1f4c-4117-9811-46e2ff825c0d@github.com>

Hi,
Can you help to review this backport patch?
Thanks!

-------------

Commit messages:
 - Backport a24b08fcb0b3784181096f5c669e57e110600056

Changes: https://git.openjdk.org/jdk/pull/22811/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22811&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345669
  Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22811.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22811/head:pull/22811

PR: https://git.openjdk.org/jdk/pull/22811

From fyang at openjdk.org  Wed Dec 18 14:38:57 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Dec 2024 14:38:57 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v3]
In-Reply-To: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
Message-ID: <6C3w7koCRkMH615zYXqDhpX1WeQnI3w9AkpSClTTRe0=.271da696-f89b-4fc2-a2e7-95152142cc52@github.com>

> Hi, please review this small improvement.
> 
> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
> 
> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

Fei Yang has updated the pull request incrementally with two additional commits since the last revision:

 - Review comments
 - Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22800/files
  - new: https://git.openjdk.org/jdk/pull/22800/files/f4d9b181..714f2b94

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22800&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22800&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22800.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22800/head:pull/22800

PR: https://git.openjdk.org/jdk/pull/22800

From fyang at openjdk.org  Wed Dec 18 14:38:58 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Dec 2024 14:38:58 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v2]
In-Reply-To: <H62NuNC4eUrYguImmK__w7Ovb6PwP7o5CepZwC6GOnE=.5bf62350-e092-4429-9f2a-3343c715fbeb@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
 <NfCSuXwUXkgdLwVxnTerH0vBkBMUIc71V0Ncdm0YOAk=.11de3468-1033-402d-98c9-954766e68e9a@github.com>
 <H62NuNC4eUrYguImmK__w7Ovb6PwP7o5CepZwC6GOnE=.5bf62350-e092-4429-9f2a-3343c715fbeb@github.com>
Message-ID: <GzK5m9CLZJq_S0P1H5Mycc4pl7NSf_MuBMVV9CVBdr8=.0aaa8635-26cc-49e6-8a34-a9032f04b7eb@github.com>

On Wed, 18 Dec 2024 14:11:12 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 5408:
> 
>> 5406:     ctz(Rd, Rs);
>> 5407:     andi(tmp1, Rd, step - 1);
>> 5408:     sub(Rd, Rd, tmp1);
> 
> Seems these 2 lines can be replaced with single instruction:
> 
> andi Rd, Rd, -step

Great! I have fixed accordingly and remove the first assertion. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22800#discussion_r1890344743

From duke at openjdk.org  Wed Dec 18 14:40:55 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 14:40:55 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
Message-ID: <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>

On Wed, 18 Dec 2024 04:24:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates tests and remove old class
>
> src/hotspot/os/windows/os_windows.cpp line 3624:
> 
>> 3622: #ifdef ASSERT
>> 3623:       fileStream fs(stdout);
>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
> 
> Why was this change made? tty could be stdout or stderr depending on VM flag settings.

This change was decided on in the original PR after it was discovered that calling [os::print_memory_mappings](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/os/windows/os_windows.cpp#L3623) from the windows implementation of `os::pd_release_memory` causes a rank conflict between `tty_lock` and `NmtVirtualMemory_lock`. This is getting called from `os::release_memory` [after we've already acquired the lock for NMT](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/share/runtime/os.cpp#L2202-L2203).

Original discussion here https://github.com/openjdk/jdk/pull/20852#issuecomment-2350882050.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890345578

From duke at openjdk.org  Wed Dec 18 14:40:54 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 14:40:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v4]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <KSb49qWHhhsNjolnVd0wVSlPCg0fynvzP5QE-QcA8Os=.10b160cb-d32f-4d48-a986-c7c2d21bd5cc@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/utilities/vmError.cpp
  
  Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/1d07d95a..a51cdc61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From mli at openjdk.org  Wed Dec 18 15:06:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 18 Dec 2024 15:06:38 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v3]
In-Reply-To: <6C3w7koCRkMH615zYXqDhpX1WeQnI3w9AkpSClTTRe0=.271da696-f89b-4fc2-a2e7-95152142cc52@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
 <6C3w7koCRkMH615zYXqDhpX1WeQnI3w9AkpSClTTRe0=.271da696-f89b-4fc2-a2e7-95152142cc52@github.com>
Message-ID: <EGgUfv95gA7u6nlRv3BywyFoURjTyonX8N3yZNiFogo=.1f518773-8cb9-4f19-b68c-d94ee4fd1a95@github.com>

On Wed, 18 Dec 2024 14:38:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please review this small improvement.
>> 
>> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
>> 
>> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.
>
> Fei Yang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Review comments
>  - Review comments

Looks good, thanks for updating!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22800#pullrequestreview-2512097646

From duke at openjdk.org  Wed Dec 18 15:09:56 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 15:09:56 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge master
 - move MemTracker::set_done_bootstrap()
 - Update src/hotspot/share/utilities/vmError.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - updates tests and remove old class
 - use ConditionalMutexLocker directly
 - Fix concurrency issue. Add assertions. Update tests.
 - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"
   
   This reverts commit c3df050b88ecef123199a4e96f6d9884d064ae45.

-------------

Changes: https://git.openjdk.org/jdk/pull/22745/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=04
  Stats: 93 lines in 19 files changed: 45 ins; 24 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From duke at openjdk.org  Wed Dec 18 15:09:57 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Wed, 18 Dec 2024 15:09:57 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
Message-ID: <7izhKeubKx3xwia21Y50pkjaxYb0Yb781-P-ZbZZ-6I=.c89be21e-28b6-4685-ae60-6e3b29655a12@github.com>

On Wed, 18 Dec 2024 04:31:45 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updates tests and remove old class
>
> src/hotspot/share/runtime/threads.cpp line 530:
> 
>> 528: 
>> 529:   // Once mutexes are ready, we can use NMT locks.
>> 530:   MemTracker::set_done_bootstrap();
> 
> This should be done after the main thread has attached and set the current thread, otherwise if we hit any NMT code that needs the lock it would crash trying to acquire it.

Ok I've moved it until after `initialize_thread_current`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890393548

From sroy at openjdk.org  Wed Dec 18 16:08:22 2024
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 18 Dec 2024 16:08:22 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm
Message-ID: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>

JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)

Currently acceleration code for GHASH is missing for PPC64. 

The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

-------------

Commit messages:
 - Copyrights update
 -  spaces fix
 -  spaces fix
 - comments
 - comments
 - using power 8 loadinstructions
 - using power 8 loadinstructions
 - change load instructions
 - comments
 - Merge branch 'openjdk:master' into ghash_processblocks
 - ... and 15 more: https://git.openjdk.org/jdk/compare/7d3a4049...9dea4fc0

Changes: https://git.openjdk.org/jdk/pull/20235/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8216437
  Stats: 137 lines in 2 files changed: 132 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/20235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20235/head:pull/20235

PR: https://git.openjdk.org/jdk/pull/20235

From amitkumar at openjdk.org  Wed Dec 18 16:26:37 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 18 Dec 2024 16:26:37 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <Iu6RhS3JE7wx9BnIaGDJwwOjV0P7saWMEAovmP0V5Ug=.3ae3c0c4-c133-4123-8e2c-a089fffb1781@github.com>

On Thu, 18 Jul 2024 14:31:57 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

src/hotspot/cpu/ppc/vm_version_ppc.cpp line 309:

> 307:   }
> 308: 
> 309:   if (FLAG_IS_DEFAULT(UseGHASHIntrinsics)) {

Just a passing comment: I guess there should be a check about whether underlying architecture supports vector instruction or not. If it does then only enable intrinsic.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1890514646

From kbarrett at openjdk.org  Wed Dec 18 16:59:43 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Dec 2024 16:59:43 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <XZ-XU1c0qP6cP2ctLQnfc4UebY_02W7ZbLZTnD-Vz4Y=.14943f82-945b-40d1-a389-5d690f2ed1d4@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
 <XZ-XU1c0qP6cP2ctLQnfc4UebY_02W7ZbLZTnD-Vz4Y=.14943f82-945b-40d1-a389-5d690f2ed1d4@github.com>
Message-ID: <f0U2zPhAbTTQ9jUgIVPdpweIKCOzbfIozoXoA2btrdY=.847d51d1-1139-4e3b-ae64-0653707a4e49@github.com>

On Tue, 17 Dec 2024 20:00:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into pa-splitter
>>  - merge log_set decl/defn
>>  - remove default counts for stats incrementers
>>  - remove uneeded 'explicit'
>>  - cleanup unneeded includes
>>  - remove moved-from macro defines
>>  - Merge branch 'master' into pa-splitter
>>  - rename splitter.step() => claim()
>>  - simplify comments
>>  - Merge branch 'master' into pa-splitter
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/6b515303...54c37988
>
> src/hotspot/share/gc/shared/partialArraySplitter.hpp line 81:
> 
>> 79:   // Result type for claim(), carrying multiple values.  Provides the claimed
>> 80:   // chunk's start and end array indices.
>> 81:   struct Claim {
> 
> I feel `Chunk` is a better name.

I think Chunk is overly generic and used a lot elsewhere.  It could just as
easily be Region (e.g. the "claimed region" instead of the "claimed chunk").
I think the "claim-ness" is the important feature here.

> src/hotspot/share/gc/shared/partialArraySplitter.inline.hpp line 63:
> 
>> 61: PartialArraySplitter::claim(PartialArrayState* state, Queue* queue, bool stolen) {
>> 62: #if TASKQUEUE_STATS
>> 63:   if (stolen) _stats.inc_stolen();
> 
> Breaking it into multiple lines make the control flow more explicit.

This stylistic difference has been discussed at length in the past.

> src/hotspot/share/gc/shared/partialArrayTaskStats.cpp line 49:
> 
>> 47: 
>> 48: void PartialArrayTaskStats::reset() {
>> 49:   *this = PartialArrayTaskStats();
> 
> Can we do sth like `static_assert(std::is_trivially_copyable<PartialArrayTaskStats>::value)` here?

I think you mean is_trivially_assignable.  I don't think it's a useful
assertion here.  Depending on details of the class, one might reasonably
implement such an operation in the same way even if it isn't trivially
assignable.

> src/hotspot/share/gc/shared/partialArrayTaskStats.hpp line 90:
> 
>> 88:   // title: A string title for the table.
>> 89:   template<typename StatsAccess>
>> 90:   static void log_set(uint num_stats, StatsAccess access, const char* title) {
> 
> Going through all its call sites, I believe `print_stats` is more readable.

The name log_set was chosen to suggest that it does "UL logging", and to
indicate that it is for dealing with a set of stats objects.  I think
print_stats loses both of those cues and is less clear because of that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1890561127
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1890561291
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1890561350
PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1890561199

From bpb at openjdk.org  Wed Dec 18 17:32:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Dec 2024 17:32:06 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
Message-ID: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>

Remove from problem list test which should have been removed in #22339.

-------------

Commit messages:
 - 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from test/hotspot/jtreg/ProblemList.txt

Changes: https://git.openjdk.org/jdk/pull/22819/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22819&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346576
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22819.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22819/head:pull/22819

PR: https://git.openjdk.org/jdk/pull/22819

From alanb at openjdk.org  Wed Dec 18 17:37:34 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Dec 2024 17:37:34 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <qagem0tbuo01AZoEyC4kqMPGQ0nuog2q903JWqjovBU=.e6df1311-e36f-4a95-b2e6-d95459046331@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22819#pullrequestreview-2512471005

From ayang at openjdk.org  Wed Dec 18 18:25:37 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Dec 2024 18:25:37 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <f0U2zPhAbTTQ9jUgIVPdpweIKCOzbfIozoXoA2btrdY=.847d51d1-1139-4e3b-ae64-0653707a4e49@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
 <XZ-XU1c0qP6cP2ctLQnfc4UebY_02W7ZbLZTnD-Vz4Y=.14943f82-945b-40d1-a389-5d690f2ed1d4@github.com>
 <f0U2zPhAbTTQ9jUgIVPdpweIKCOzbfIozoXoA2btrdY=.847d51d1-1139-4e3b-ae64-0653707a4e49@github.com>
Message-ID: <ZZ0mrVUw6F8PduKHXAjpSd6sXJiKFupdSScGJB0i9kg=.acf3a5c6-ff6b-4d9b-8771-c0fa0e8118fe@github.com>

On Wed, 18 Dec 2024 16:56:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/partialArrayTaskStats.hpp line 90:
>> 
>>> 88:   // title: A string title for the table.
>>> 89:   template<typename StatsAccess>
>>> 90:   static void log_set(uint num_stats, StatsAccess access, const char* title) {
>> 
>> Going through all its call sites, I believe `print_stats` is more readable.
>
> The name log_set was chosen to suggest that it does "UL logging", and to
> indicate that it is for dealing with a set of stats objects.  I think
> print_stats loses both of those cues and is less clear because of that.

Why is "set" more than important than "stats" in "set of stats objects"? If "UL logging" is critical, "log_stats" would be better. When I first read this name, I thought it's related to "set" as in "getter/setter" of log...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1890642530

From cjplummer at openjdk.org  Wed Dec 18 18:58:36 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 18 Dec 2024 18:58:36 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <mPH28lBNaCacYe01SUbFyWRLCwy-N33juiUCG6akkTc=.aba83040-8abf-4989-be3c-835886fe6054@github.com>

On Wed, 18 Dec 2024 03:12:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweak in jvmti.xml update

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2512624718

From kbarrett at openjdk.org  Wed Dec 18 19:01:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Dec 2024 19:01:39 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <ZZ0mrVUw6F8PduKHXAjpSd6sXJiKFupdSScGJB0i9kg=.acf3a5c6-ff6b-4d9b-8771-c0fa0e8118fe@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
 <XZ-XU1c0qP6cP2ctLQnfc4UebY_02W7ZbLZTnD-Vz4Y=.14943f82-945b-40d1-a389-5d690f2ed1d4@github.com>
 <f0U2zPhAbTTQ9jUgIVPdpweIKCOzbfIozoXoA2btrdY=.847d51d1-1139-4e3b-ae64-0653707a4e49@github.com>
 <ZZ0mrVUw6F8PduKHXAjpSd6sXJiKFupdSScGJB0i9kg=.acf3a5c6-ff6b-4d9b-8771-c0fa0e8118fe@github.com>
Message-ID: <0Rt2156r75CNZ05GNDBP9dm2UbtJAm3wuViLWyQXIB8=.6bfd61dc-2b56-4bda-82c1-cc76fb2a91c5@github.com>

On Wed, 18 Dec 2024 18:04:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> The name log_set was chosen to suggest that it does "UL logging", and to
>> indicate that it is for dealing with a set of stats objects.  I think
>> print_stats loses both of those cues and is less clear because of that.
>
> Why is "set" more than important than "stats" in "set of stats objects"? If "UL logging" is critical, "log_stats" would be better. When I first read this name, I thought it's related to "set" as in "getter/setter" of log...

"stats" is redundent here.  Recall this is a static function. A client call is
going to look like `PartialArrayTaskStats::log_set(...)`, so it's already
obvious it's related to "stats" at the call site.

A value assigning function would have a "set_" prefix.  Using a "_set" suffix
for that would be really weird and non-idiomatic (and a reader would be quite
right to complain about such).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1890702759

From coleenp at openjdk.org  Wed Dec 18 19:23:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Dec 2024 19:23:39 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <4z2P9wv0UyYE7Ct-X0W6VYLVOqpocol7MblNDxlpy6U=.5a09be4a-b10a-4a55-91c2-99abeafef3db@github.com>

On Tue, 19 Nov 2024 16:18:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

No, bot, this is a new PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2552096922

From stevenschlansker at gmail.com  Wed Dec 18 19:27:50 2024
From: stevenschlansker at gmail.com (Steven Schlansker)
Date: Wed, 18 Dec 2024 11:27:50 -0800
Subject: Bits.reserveMemory OutOfMemoryError does not seem to trigger
 -XX:OnOutOfMemoryError
In-Reply-To: <00c063ad-270f-4a3d-a49c-9efabb360b8c@oracle.com>
References: <CAHjY6CVJDh4wqdHBwQNBCZZybEEVnF5X7aqj9GOA-+bs-H3JtQ@mail.gmail.com>
 <00c063ad-270f-4a3d-a49c-9efabb360b8c@oracle.com>
Message-ID: <463B6C20-C57C-449F-984F-9B9103426A0D@gmail.com>



> On Dec 17, 2024, at 5:31?PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Steven,
> 
> The -XX OOM relating flags are only for OOM conditions directly detected by the VM itself - please also see:
> 
> https://bugs.openjdk.org/browse/JDK-8257790
> 

Thank you David, this explains what we see.

> Unfortunately the java mapage documentation didn't get updated to make this clear, but I will address that. We did clarify in the source [1]:
> 
>  product(ccstrlist, OnOutOfMemoryError, "",     \
>          "Run user-defined commands on first java.lang.OutOfMemoryError "  \
>          "thrown from JVM")     \
> 
> You need to handle Java triggered OOM conditions in the Java code.

We'll endeavor to do this. I hope the Lettuce / Netty maintainers can help us out here, as none of our code is directly implicated.

I am sure this is not a high priority feature request, but it would be nice to have a more general "on any user-visible Error: stop, dump, and crash".
So far every time we see an Error, regardless of whether it came from the VM or the Java standard library,
we'd rather crash and analyze offline than try to continue in an unknown state and end up in an even worse state!

That said, I see you already stated your position as "strongly opposed" in JDK-8257790, so I suppose this is how the world is at least for now :)

Thanks for your time and for everyone's efforts making Java robust.

> David
> -----
> 
> [1] https://bugs.openjdk.org/browse/JDK-8258058
> 
> On 18/12/2024 9:52 am, Steven Schlansker wrote:
>> Hi hotspot-dev,
>> In our continuing mission to explore strange new VM memory limits
>> (aren't containers fun?), we have encountered a situation where a
>> un-serviceable direct memory allocation request leaves the running
>> application in a live but unusable state. In the container world, we
>> expect to run into resource misconfigurations from time to time, it
>> seems to be a fact of life for the moment. But having the app unable
>> to recover sucks.
>> We run:
>> openjdk 23.0.1+11
>> netty 4.1.115
>> A big workload spike comes in, and suddenly we allocate a lot of
>> memory, and run out:
>> java.lang.OutOfMemoryError: Cannot reserve 4194304 bytes of direct
>> buffer memory (allocated: 804069357, limit: 805306368) at
>> java.base/java.nio.Bits.reserveMemory(Bits.java:178) at
>> java.base/java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:111)
>> at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:363)
>> at io.netty.buffer.PoolArena$DirectArena.allocateDirect(PoolArena.java:718)
>> at io.netty.buffer.PoolArena$DirectArena.newChunk(PoolArena.java:693)
>> We configure our jvm with
>> '-XX:OnError=bin/crasher %p' '-XX:OnOutOfMemoryError=bin/crasher %p'
>> where crasher is a shell script that dumps various things and runs
>> kill -9 on the process to ensure recovery by kubernetes starting a new
>> container.
>> The java help page says,
>>> -XX:OnOutOfMemoryError=string Sets a custom command or a series of semicolon-separated commands to run when an OutOfMemoryError exception is first thrown. ...
>> From a simple reading of this, it sounds like this Bits.reserveMemory
>> OOM should trigger the OnOutOfMemoryError handler. We would expect the
>> behavior to invoke the error handler, leading to a kill signal.
>> Instead, the program proceeds. Something quickly goes wrong with
>> reference counting inside of the Lettuce Redis client:
>> Caused by: java.lang.NullPointerException: Cannot invoke
>> "io.netty.buffer.ByteBuf.refCnt()" because "this.buffer" is null at
>> io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:597)
>> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
>> and then the whole application wedges. I reported this separately
>> (https://github.com/redis/lettuce/issues/3087).
>> While it will be nice to improve the Lettuce / Netty handling of OOME,
>> we felt like our configuration of OnOutOfMemoryError should have
>> covered this case - the help message doesn't qualify a particular type
>> of OOME, like "out of Java heap memory" - and a clean kill of the
>> process would have reduced a multi-hour outage (until a human could
>> notice + respond) to moments while the process restarts.
>> Is this an appropriate expectation? I'm happy to file an issue if this
>> would be considered a bug.
>> Thank you for your consideration.
> 


From ayang at openjdk.org  Wed Dec 18 19:32:38 2024
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Dec 2024 19:32:38 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <0Rt2156r75CNZ05GNDBP9dm2UbtJAm3wuViLWyQXIB8=.6bfd61dc-2b56-4bda-82c1-cc76fb2a91c5@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
 <XZ-XU1c0qP6cP2ctLQnfc4UebY_02W7ZbLZTnD-Vz4Y=.14943f82-945b-40d1-a389-5d690f2ed1d4@github.com>
 <f0U2zPhAbTTQ9jUgIVPdpweIKCOzbfIozoXoA2btrdY=.847d51d1-1139-4e3b-ae64-0653707a4e49@github.com>
 <ZZ0mrVUw6F8PduKHXAjpSd6sXJiKFupdSScGJB0i9kg=.acf3a5c6-ff6b-4d9b-8771-c0fa0e8118fe@github.com>
 <0Rt2156r75CNZ05GNDBP9dm2UbtJAm3wuViLWyQXIB8=.6bfd61dc-2b56-4bda-82c1-cc76fb2a91c5@github.com>
Message-ID: <dRJRPiDwaTbgRlInycC5AoI0lrkGW42JZwHJQTEqYso=.3166056c-4e8e-48b9-8a90-624793aa1fa2@github.com>

On Wed, 18 Dec 2024 18:58:54 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Why is "set" more than important than "stats" in "set of stats objects"? If "UL logging" is critical, "log_stats" would be better. When I first read this name, I thought it's related to "set" as in "getter/setter" of log...
>
> "stats" is redundent here.  Recall this is a static function. A client call is
> going to look like `PartialArrayTaskStats::log_set(...)`, so it's already
> obvious it's related to "stats" at the call site.
> 
> A value assigning function would have a "set_" prefix.  Using a "_set" suffix
> for that would be really weird and non-idiomatic (and a reader would be quite
> right to complain about such).

I don't feel that the redundancy here is bad, since the first two args are tied to "stats". OTOH, I find the trailing "set" super confusing. This function is to log/print multiple stats, and the most intuitive choice would have been "log/print" + "stats", because it directly communicates the action being performed (logging stats).

Emphasizing the collective noun instead of the actual noun seems odd. YMMV.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22622#discussion_r1890738140

From amenkov at openjdk.org  Wed Dec 18 19:37:44 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 18 Dec 2024 19:37:44 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <kidVU6rc0AJs1On50ARWP1gft9_Uu-17rwkcpcbYwYQ=.b71bc563-1cb7-49e5-9538-a1df111d30c5@github.com>

On Wed, 18 Dec 2024 03:12:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweak in jvmti.xml update

I think we need a test for the functionality (a new one or update existing)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22798#issuecomment-2552120263

From amenkov at openjdk.org  Wed Dec 18 19:49:39 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 18 Dec 2024 19:49:39 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <SBb2mrl6tpsyMezvT2Xx0KVT5IFHhQBSNg8MpHFLj7g=.94949e20-efae-4af6-86c8-3aa677122d11@github.com>

On Wed, 18 Dec 2024 03:12:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweak in jvmti.xml update

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 500:

> 498:   cname = get_method_class_name(jvmti, jni, method);
> 499: 
> 500:   LOG("\nHit #%d: VirtualThreadUnmount #%d: enabling FramePop for method: %s::%s on virtual thread: %p\n",

The comment needs to be updated as NotifyFramePop is removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1890741942

From kbarrett at openjdk.org  Wed Dec 18 20:01:38 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Dec 2024 20:01:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
Message-ID: <OUcQnSGavJY98qHWZng2KZAmD-15Z59GlJV4sV4AwnE=.53335129-d474-4625-bab7-5fe2eef86775@github.com>

On Wed, 18 Dec 2024 04:37:22 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The direct use of CML is functionally correct but requires leaking knowledge to all the use-sites that should not need to know about the actual condition for locking. This really needs to be encapsulated which means we need to be able to subclass CML.

I agree that directly using ConditionalMutexLocker isn't pleasant here, and
one actually does want a dedicated locker for this use-case.  However, that
doesn't mean we need to subclass CML.

> @kbarrett what is needed to make `ConditionalMutexLocker` subclassable?

You don't change ConditionalMutexLocker at all.  Just change how it's used:

class NmtVirtualMemoryLocker : StackObj {
  ConditionalMutexLocker _locker;

public:
  NmtVirtualMemoryLocker()
    : _locker(NmtVirtualMemory_lock, _done_bootstrap, Mutex::_no_safepoint_check_flag)
  {}
};

MutexLocker can be has-a used similarly for convenience lockers that don't
need the conditionalization.

Note that making MutexLockerImpl noncopyable (as it should be, but that ought
to be addressed separately) would render this noncopyable too (as it should
be).

Note that I was previously wrong when I suggested it might be messy to has-a
use CML; I misremembered and thought these locker things had more operations
than they actually do.

And not that it really matters, but deriving from StackObj with a CML member
doesn't affect the size of this class, because of EBO.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2552160345

From kbarrett at openjdk.org  Wed Dec 18 20:01:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Dec 2024 20:01:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <fW8-yqnaOsES3tHkgdos0fa_2B40OpkEzAfACv1VoI8=.7c1066e2-333c-4704-92de-f77522918e7e@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <ijMwwcc_9kYaeoCRVct50bD5fxs8BKwEXpL2cliJscw=.89ea6e7c-a706-4574-8c10-986f86f3abd2@github.com>
 <tIGVb1_5Z9UBWm9_LXsG54RiUJ1ewjPnNZMeg2IkEsw=.3871b8cf-6aa9-40c8-9f4b-38611a62844f@github.com>
 <-AN1pvDXXdS7SNRQHFlRECkSva-OaE9Val6b7z91qbg=.9313b68c-dcee-4a11-9482-135bd40c81ef@github.com>
 <-yAB7h8upLHnj28ba9LRoJcuglVIbDQNPqCo-b3z9v0=.a8a7bc4b-abe9-4b09-930a-8923d32247b9@github.com>
 <fW8-yqnaOsES3tHkgdos0fa_2B40OpkEzAfACv1VoI8=.7c1066e2-333c-4704-92de-f77522918e7e@github.com>
Message-ID: <PhE9qjgKTe1UmdJzTykDwX3DGNBO-DfdOfAO-RW0Nco=.32d3d7f0-63cf-4107-b60f-9dd10dbb0221@github.com>

On Tue, 17 Dec 2024 13:45:38 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> `MutexLockerImpl` was not intended for external subclassing, but as the internal base class for `MutexLocker`, and `ConditionalMutexLocker`.  CML was provided for exactly this kind of situation: conditionally locking the mutex.
>
> Ok I see. I will stop using `ConditionalMutexLocker` as a base class. Instead, I'll just get rid of `NmtVirtualMemoryLocker` and use `ConditionalMutexLocker` directly.

Regarding use of `MutexLockerImpl`, perhaps, though I see nothing in the JBS
issue or the PR that says that.  If it's the name that drives that position
then I think it can easily be argued that it's misnamed, and should be
something like MutexLockerBase.  It *is* nicely designed for use as a base
class, with protected ctors/dtor, making it a convient basis for lockers for
specific use cases. But see my other response about how to has-a use CML (and
MutexLocker) for that purpose.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890769789

From luhenry at openjdk.org  Wed Dec 18 21:47:36 2024
From: luhenry at openjdk.org (Ludovic Henry)
Date: Wed, 18 Dec 2024 21:47:36 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe
In-Reply-To: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
Message-ID: <2RmVFYfayHVylIQPrRLI-JGUzEz4t2gDsIAMkQn3KFQ=.c74854c4-ea93-42e2-82f7-45c81d1341f1@github.com>

On Mon, 2 Dec 2024 09:55:22 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review the patch?
> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
> 
> Thanks!
> 
> Tests running so far so good.

Marked as reviewed by luhenry (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22474#pullrequestreview-2512922965

From dholmes at openjdk.org  Wed Dec 18 22:23:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 18 Dec 2024 22:23:36 GMT
Subject: [jdk24] RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java
 failed with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>
References: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>
Message-ID: <0WhKQV1KVfljmAPlLMiH1ieDOzGMQc8A3blkU4JZSWE=.adc158f5-9586-4218-8e36-3b22b55f6c04@github.com>

On Wed, 18 Dec 2024 01:52:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea50c54a](https://github.com/openjdk/jdk/commit/ea50c54a14d39fcedabe8426a14eaec27ab24af2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 18 Dec 2024 and was reviewed by Leonid Mesnik and Hamlin Li.
> 
> Thanks

@lmesnik could you approve please.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22801#issuecomment-2552379227

From lmesnik at openjdk.org  Wed Dec 18 22:39:34 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 18 Dec 2024 22:39:34 GMT
Subject: [jdk24] RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java
 failed with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>
References: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>
Message-ID: <oZNtA64v7EVfZf1zJMew2OaA9JG4X_Ygh4aPG61pRX8=.07001fcf-7ba2-413f-af99-42afdcfb0c22@github.com>

On Wed, 18 Dec 2024 01:52:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea50c54a](https://github.com/openjdk/jdk/commit/ea50c54a14d39fcedabe8426a14eaec27ab24af2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 18 Dec 2024 and was reviewed by Leonid Mesnik and Hamlin Li.
> 
> Thanks

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22801#pullrequestreview-2512994338

From coleenp at openjdk.org  Wed Dec 18 23:04:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 18 Dec 2024 23:04:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@github.com>
Message-ID: <laIxVxbUrtPGON0nIPCZ9tgQtF3ke2NFuf3Ftny9LmQ=.770e9807-7553-4beb-966d-c7d6f097870e@github.com>

On Wed, 18 Dec 2024 15:09:56 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge master
>  - move MemTracker::set_done_bootstrap()
>  - Update src/hotspot/share/utilities/vmError.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - updates tests and remove old class
>  - use ConditionalMutexLocker directly
>  - Fix concurrency issue. Add assertions. Update tests.
>  - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"
>    
>    This reverts commit c3df050b88ecef123199a4e96f6d9884d064ae45.

Sorry if I'm repeating other comments, but it looks like a good change but could be a bit less repetition.  Thanks for removing this instance of ThreadCritical.

Oh yes, now I see, sorry I did repeat Kim's suggestion.

src/hotspot/share/runtime/mutexLocker.cpp line 292:

> 290:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
> 291:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
> 292:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4);

Why is this service-4?  Does it depend on being a rank lower than another lock?  If so, this and the SharedDecoder_lock should be declared below as MUTEX_DEFL and call out that lock.

src/hotspot/share/runtime/os.cpp line 2313:

> 2311:   bool result;
> 2312:   if (MemTracker::enabled()) {
> 2313:     ConditionalMutexLocker cml(NmtVirtualMemory_lock, MemTracker::is_done_bootstrap(), Mutex::_no_safepoint_check_flag);

This pattern is all over.  Can you create a class in nmtSomeHeader like:

class NMTLocker {
    ConditionalMutexLocker cml;
    NMTLocker();
};

in cpp file:
NmtLocker() : _cml(NmtVirtualMemory_lock, MemTracker::is_done_bootstrap(), Mutex::_no_safepoint_check_flag) {}

Or something like that, rather than this be repeated everywhere.  I only skimmed the other comments, so maybe David and Kim said the same thing.

-------------

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2513014280
PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2552430048
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890930186
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1890932610

From ccheung at openjdk.org  Thu Dec 19 00:14:42 2024
From: ccheung at openjdk.org (Calvin Cheung)
Date: Thu, 19 Dec 2024 00:14:42 GMT
Subject: RFR: 8346306: Unattached thread can cause crash during VM exit if
 it calls wait_if_vm_exited
In-Reply-To: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
References: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
Message-ID: <raapDtKq_sPkZK1v3oMOA8dtwDilawCSaS3XNmm7Dss=.d889571e-a8f5-4f91-abd5-bd3b3f23d7f3@github.com>

On Tue, 17 Dec 2024 00:10:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple fix to account for unattached threads using RawMonitors which check if the VM has exited.
> 
> Testing:
>  - tiers 1-3 (sanity)
> 
> Thanks

Looks good.

-------------

Marked as reviewed by ccheung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22779#pullrequestreview-2513086638

From amenkov at openjdk.org  Thu Dec 19 00:32:40 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 19 Dec 2024 00:32:40 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
Message-ID: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>

On Wed, 18 Dec 2024 03:28:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()

src/hotspot/share/prims/jvmti.xml line 3096:

> 3094:         event will not be generated for any frames.
> 3095:         See the <eventlink id="FramePop"></eventlink> event for details.
> 3096:         <p/>

I think
`The specified thread must be suspended or must be the current thread.`
should be added (as we have in `NotifyFramePop` description)

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 79:

> 77:     _pops->remove_at(idx);
> 78:   }
> 79:   assert(_pops->length() == 0, "sanity check");

Suggestion:

  _pops->clear();

src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 261:

> 259:   Thread *current = Thread::current();
> 260: #endif
> 261:   assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(current),

Suggestion:

  assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(Thread::current()),

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 44:

> 42: static
> 43: bool isTestThread(JNIEnv *jni, jvmtiEnv *jvmti, jthread thr) {
> 44:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);

Only thread name is required, `get_thread_name` can be used

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 55:

> 53:   jclass cls;
> 54:   char *mname, *msig, *csig;
> 55:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);

Only thread name is required, `get_thread_name` can be used

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 81:

> 79:   jclass cls;
> 80:   char *csig;
> 81:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);

Looks like this is not needed (and inf.name not deallocated)

test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 137:

> 135:     LOG("(GetCapabilities) unexpected error: %s (%d)\n", TranslateError(err), err);
> 136:     return JNI_ERR;
> 137:   }

I don't think this is needed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890964500
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890974928
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890976875
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890987527
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890987617
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890984746
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1890985653

From fyang at openjdk.org  Thu Dec 19 01:20:36 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Dec 2024 01:20:36 GMT
Subject: [jdk24] RFR: 8345669: RISC-V: fix client build failure due to
 AlignVector after JDK-8343827
In-Reply-To: <FpGN_oaIRHHS-M2HwWjxQg7YBuQOiljZiLQ8jXVjgH4=.4fab5286-1f4c-4117-9811-46e2ff825c0d@github.com>
References: <FpGN_oaIRHHS-M2HwWjxQg7YBuQOiljZiLQ8jXVjgH4=.4fab5286-1f4c-4117-9811-46e2ff825c0d@github.com>
Message-ID: <LFB9KasyiYG7qnOeYn7qz6S9XCfNhEW4rdmXujA4os0=.4e756ddd-d3a6-4723-a7ac-7943ac8f9d2b@github.com>

On Wed, 18 Dec 2024 14:30:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this backport patch?
> Thanks!

Marked as reviewed by fyang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22811#pullrequestreview-2513139406

From fyang at openjdk.org  Thu Dec 19 01:35:47 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Dec 2024 01:35:47 GMT
Subject: RFR: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit [v3]
In-Reply-To: <EGgUfv95gA7u6nlRv3BywyFoURjTyonX8N3yZNiFogo=.1f518773-8cb9-4f19-b68c-d94ee4fd1a95@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
 <6C3w7koCRkMH615zYXqDhpX1WeQnI3w9AkpSClTTRe0=.271da696-f89b-4fc2-a2e7-95152142cc52@github.com>
 <EGgUfv95gA7u6nlRv3BywyFoURjTyonX8N3yZNiFogo=.1f518773-8cb9-4f19-b68c-d94ee4fd1a95@github.com>
Message-ID: <sHpPOgsvqS56_4GFoOCSqepO7vCXPN4yZC1TzNSi39A=.7614fc40-f676-471a-b6c2-b901c3ea5a00@github.com>

On Wed, 18 Dec 2024 15:03:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Review comments
>>  - Review comments
>
> Looks good, thanks for updating!

@Hamlin-Li @feilongjiang : Thanks for the review! Tier1-2 test is still clean with the latest version. Moving on.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22800#issuecomment-2552589508

From fyang at openjdk.org  Thu Dec 19 01:35:47 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Dec 2024 01:35:47 GMT
Subject: Integrated: 8346475: RISC-V: Small improvement for
 MacroAssembler::ctzc_bit
In-Reply-To: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
References: <fh_MRdcmvFECYVEWJ6XeW8_nrvQUQVHWuU3I7ayXDQg=.5397f10a-632e-4119-8fcd-cff5fa65eecb@github.com>
Message-ID: <qx-2PiRxebSt3jUboSnYfEFIqr5D5D-ksWrXEao0gYo=.50d3f8bc-e81d-42cb-b678-9bf0c7835e3c@github.com>

On Wed, 18 Dec 2024 00:47:48 GMT, Fei Yang <fyang at openjdk.org> wrote:

> Hi, please review this small improvement.
> 
> When `step` is 16, the `andi` instruction in the loop performs a bitwise AND with immediate mask value 0xFFFF. This will emit 3 instructions. It's effectively a zero extension operation and could be reduced to 1 or 2 instructions repectively depending on whether Zbb extension is available. And there is no difference when `step` is 8 with this change.
> 
> Testing: tier1 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

This pull request has now been integrated.

Changeset: 6b89954c
Author:    Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b89954c65342bc601633d24075dab4f4b248f4b
Stats:     35 lines in 4 files changed: 13 ins; 5 del; 17 mod

8346475: RISC-V: Small improvement for MacroAssembler::ctzc_bit

Reviewed-by: mli, fjiang

-------------

PR: https://git.openjdk.org/jdk/pull/22800

From dholmes at openjdk.org  Thu Dec 19 02:22:51 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 02:22:51 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
Message-ID: <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>

On Wed, 18 Dec 2024 14:36:41 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 3624:
>> 
>>> 3622: #ifdef ASSERT
>>> 3623:       fileStream fs(stdout);
>>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
>> 
>> Why was this change made? tty could be stdout or stderr depending on VM flag settings.
>
> This change was decided on in the original PR after it was discovered that calling [os::print_memory_mappings](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/os/windows/os_windows.cpp#L3623) from the windows implementation of `os::pd_release_memory` causes a rank conflict between `tty_lock` and `NmtVirtualMemory_lock`. This is getting called from `os::release_memory` [after we've already acquired the lock for NMT](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/share/runtime/os.cpp#L2202-L2203).
> 
> Original discussion here https://github.com/openjdk/jdk/pull/20852#issuecomment-2350882050.

Okay ... still not sure this shouldn't be dynamically determining whether stdout or stderr is the right target.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1891048323

From dholmes at openjdk.org  Thu Dec 19 02:25:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 02:25:45 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <OUcQnSGavJY98qHWZng2KZAmD-15Z59GlJV4sV4AwnE=.53335129-d474-4625-bab7-5fe2eef86775@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <OUcQnSGavJY98qHWZng2KZAmD-15Z59GlJV4sV4AwnE=.53335129-d474-4625-bab7-5fe2eef86775@github.com>
Message-ID: <PiJnRk_RKagcnT6YVwXRtyT5kjl7vatJgEyJ20vH0Lg=.a4e6f51b-fd8f-4ec2-bd12-98e09c0f18ad@github.com>

On Wed, 18 Dec 2024 19:58:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> You don't change ConditionalMutexLocker at all. Just change how it's used:

Doh! @kimbarrett  don't know what I was thinking. Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2552637884

From dholmes at openjdk.org  Thu Dec 19 02:50:41 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 02:50:41 GMT
Subject: RFR: 8346306: Unattached thread can cause crash during VM exit if
 it calls wait_if_vm_exited
In-Reply-To: <raapDtKq_sPkZK1v3oMOA8dtwDilawCSaS3XNmm7Dss=.d889571e-a8f5-4f91-abd5-bd3b3f23d7f3@github.com>
References: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
 <raapDtKq_sPkZK1v3oMOA8dtwDilawCSaS3XNmm7Dss=.d889571e-a8f5-4f91-abd5-bd3b3f23d7f3@github.com>
Message-ID: <y7LsGIfJgDnN2R7gU-Y9G9DA-yYr6_aiSyopCtthVR4=.820e3fab-b9ee-46c6-b364-8d5656792f9f@github.com>

On Thu, 19 Dec 2024 00:11:45 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Please review this simple fix to account for unattached threads using RawMonitors which check if the VM has exited.
>> 
>> Testing:
>>  - tiers 1-3 (sanity)
>> 
>> Thanks
>
> Looks good.

Thanks for the review @calvinccheung !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22779#issuecomment-2552662891

From dholmes at openjdk.org  Thu Dec 19 02:50:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 02:50:42 GMT
Subject: Integrated: 8346306: Unattached thread can cause crash during VM exit
 if it calls wait_if_vm_exited
In-Reply-To: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
References: <LCDj8ZRy8bNnDu6HOwV5Zee3m-FKu-7Xd_BVhNY9nAg=.0c66ecb7-007f-4aa5-98a6-a2dc790a591a@github.com>
Message-ID: <AQ_lffRuAoUnPazMWpQhESUwsu9mKUj1uXxYaT2uaLg=.0d144b28-29dd-4b90-a57d-55a5b9d9073e@github.com>

On Tue, 17 Dec 2024 00:10:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Please review this simple fix to account for unattached threads using RawMonitors which check if the VM has exited.
> 
> Testing:
>  - tiers 1-3 (sanity)
> 
> Thanks

This pull request has now been integrated.

Changeset: 484229e0
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/484229e04b812acd0c58a261c935c9e9190b3ba8
Stats:     13 lines in 2 files changed: 5 ins; 0 del; 8 mod

8346306: Unattached thread can cause crash during VM exit if it calls wait_if_vm_exited

Reviewed-by: coleenp, ccheung

-------------

PR: https://git.openjdk.org/jdk/pull/22779

From fyang at openjdk.org  Thu Dec 19 03:19:06 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Dec 2024 03:19:06 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v2]
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <LtH9C6pYxZPkHeB3uIg8qGKYGT-uRbqaSWU_fZCrhlQ=.1a8e3d7f-ef68-477e-a2a4-32a85780c693@github.com>

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check
> about the immediate range and save the tmp register used by the latter as well. In order to make the code more readable, this
> also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> Testing: tier1-3 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

Fei Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8346478
 - 8346478: RISC-V: Refactor add/sub assembler routines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22804/files
  - new: https://git.openjdk.org/jdk/pull/22804/files/22d2397f..58e9a0eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=00-01

  Stats: 3103 lines in 121 files changed: 1813 ins; 1008 del; 282 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

PR: https://git.openjdk.org/jdk/pull/22804

From sspitsyn at openjdk.org  Thu Dec 19 03:56:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 03:56:42 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <SBb2mrl6tpsyMezvT2Xx0KVT5IFHhQBSNg8MpHFLj7g=.94949e20-efae-4af6-86c8-3aa677122d11@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
 <SBb2mrl6tpsyMezvT2Xx0KVT5IFHhQBSNg8MpHFLj7g=.94949e20-efae-4af6-86c8-3aa677122d11@github.com>
Message-ID: <ATQKSdJMzAha28FxGMlmPUErIEm6Ow-8WaXwKdG_ZQo=.ad587c97-507d-4ac3-b78a-3fb59529b010@github.com>

On Wed, 18 Dec 2024 19:33:05 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: minor tweak in jvmti.xml update
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 500:
> 
>> 498:   cname = get_method_class_name(jvmti, jni, method);
>> 499: 
>> 500:   LOG("\nHit #%d: VirtualThreadUnmount #%d: enabling FramePop for method: %s::%s on virtual thread: %p\n",
> 
> The comment needs to be updated as NotifyFramePop is removed

>  think we need a test for the functionality (a new one or update existing)

I've updated this test to request a duplicated `FramePop` event.

> The comment needs to be updated as NotifyFramePop is removed

I've updated this comment accordingly to the change above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1891097969

From sspitsyn at openjdk.org  Thu Dec 19 04:46:12 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:46:12 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/4106c10a..defa6206

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=01-02

  Stats: 17 lines in 1 file changed: 11 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22798/head:pull/22798

PR: https://git.openjdk.org/jdk/pull/22798

From sspitsyn at openjdk.org  Thu Dec 19 04:46:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:46:13 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v2]
In-Reply-To: <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <53FH2_sTbQxO3J6Q8lNhhWBn7PgKDHB6CzkdmDiJmq4=.ce683423-606f-4ae3-b544-e7c6e65e4d4b@github.com>
Message-ID: <PgvC2aBGih8_UOjF7H84gWred8q5IExT8_d5Lk5o02I=.55484bfb-249c-4315-b212-915a010dd5fa@github.com>

On Wed, 18 Dec 2024 03:12:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: minor tweak in jvmti.xml update

Chris, thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22798#issuecomment-2552766218

From sspitsyn at openjdk.org  Thu Dec 19 04:51:37 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:51:37 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
 <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
Message-ID: <3fwf-HTKmKsVKGzQTBlvFXGu04bU9MTjUzN3T7Vrfjg=.04899bd8-87a8-4a0e-8b39-2d234bbb2a94@github.com>

On Wed, 18 Dec 2024 23:51:23 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()
>
> src/hotspot/share/prims/jvmti.xml line 3096:
> 
>> 3094:         event will not be generated for any frames.
>> 3095:         See the <eventlink id="FramePop"></eventlink> event for details.
>> 3096:         <p/>
> 
> I think
> `The specified thread must be suspended or must be the current thread.`
> should be added (as we have in `NotifyFramePop` description)

Nice catch, thanks. Fixed now. Fixed the CSR as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891150755

From jpai at openjdk.org  Thu Dec 19 04:52:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Dec 2024 04:52:34 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <YdQ_OkowwtUrTbh1dtbF0Was8d1zONn8uWrZENGKJH8=.bb3907fe-b566-4c3e-a5e5-e7f914b7bb0c@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

Thank you for fixing this Brian. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22819#pullrequestreview-2513343986

From sspitsyn at openjdk.org  Thu Dec 19 04:58:42 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 04:58:42 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
 <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
Message-ID: <RbA4vnBHRiHW_TqtSdIERVU7FTXnouuAJPrqAhrD_ls=.2d8c2b92-e99a-406d-b39f-33abc7b33f25@github.com>

On Thu, 19 Dec 2024 00:09:38 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 79:
> 
>> 77:     _pops->remove_at(idx);
>> 78:   }
>> 79:   assert(_pops->length() == 0, "sanity check");
> 
> Suggestion:
> 
>   _pops->clear();

Good suggestion, thanks. Fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891155240

From sspitsyn at openjdk.org  Thu Dec 19 05:10:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 05:10:38 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
 <_hxAw596AMur7i8kQBO2ZjymfmC8BOJB4kcpRo4LwqM=.2c8e4795-b815-49eb-bbdf-538e50c3c13c@github.com>
Message-ID: <m9XZOTCFsud4-yeQJU6r3BRz78JAkU4NdmqNZGa0ieg=.b6bf57c1-49e4-4a46-8ce5-83097c490d35@github.com>

On Thu, 19 Dec 2024 00:12:52 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()
>
> src/hotspot/share/prims/jvmtiEnvThreadState.cpp line 261:
> 
>> 259:   Thread *current = Thread::current();
>> 260: #endif
>> 261:   assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(current),
> 
> Suggestion:
> 
>   assert(get_thread() == nullptr || get_thread()->is_handshake_safe_for(Thread::current()),

Thank you for the comment. Chris suggested the same.
I've fixed all such places in the file to make it consistent.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 44:
> 
>> 42: static
>> 43: bool isTestThread(JNIEnv *jni, jvmtiEnv *jvmti, jthread thr) {
>> 44:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);
> 
> Only thread name is required, `get_thread_name` can be used

Thanks. Updated now.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 55:
> 
>> 53:   jclass cls;
>> 54:   char *mname, *msig, *csig;
>> 55:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);
> 
> Only thread name is required, `get_thread_name` can be used

Thank. Updated now.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 81:
> 
>> 79:   jclass cls;
>> 80:   char *csig;
>> 81:   jvmtiThreadInfo inf = get_thread_info(jvmti, jni, thr);
> 
> Looks like this is not needed (and inf.name not deallocated)

Good catch. Removed the line now.

> test/hotspot/jtreg/serviceability/jvmti/events/FramePop/ClearAllFramePops/libClearAllFramePops.cpp line 137:
> 
>> 135:     LOG("(GetCapabilities) unexpected error: %s (%d)\n", TranslateError(err), err);
>> 136:     return JNI_ERR;
>> 137:   }
> 
> I don't think this is needed

Thanks. Removed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891157836
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891161525
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891162238
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891159383
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1891160447

From sspitsyn at openjdk.org  Thu Dec 19 05:14:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 05:14:38 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v5]
In-Reply-To: <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <Al0Sb7Yfh5N2UzSy50apFtus0IC2tGumHeewmPhqPWQ=.892ce388-4784-4a7d-850d-49bb479b1172@github.com>
Message-ID: <ogdUk0yZRLFMj_YGelTrroeZM1Pi7ozN2dCjcyiW1-U=.34e11cae-7b8b-43e6-9063-7e5ccd7bfe93@github.com>

On Wed, 18 Dec 2024 03:28:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: removed unneeded check for JvmtiExport::can_post_frame_pop()

Alex, thank you for review comments! Can you, please, add yourself as CSR reviewer, so I could finalize it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22744#issuecomment-2552802640

From cjplummer at openjdk.org  Thu Dec 19 05:20:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 19 Dec 2024 05:20:35 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
Message-ID: <v5qPLRu0QqodSIjsLbEXt1sNJR9I4KmK6IA103yPl9w=.e5fc234d-b749-4355-8c75-93f3696f84cd@github.com>

On Thu, 19 Dec 2024 04:46:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2513370366

From sspitsyn at openjdk.org  Thu Dec 19 05:24:20 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 19 Dec 2024 05:24:20 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/850cafbd..0d762462

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=04-05

  Stats: 33 lines in 3 files changed: 1 ins; 21 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

PR: https://git.openjdk.org/jdk/pull/22744

From cjplummer at openjdk.org  Thu Dec 19 06:20:37 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 19 Dec 2024 06:20:37 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
In-Reply-To: <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
Message-ID: <fFbG0XcGTOVBs9iYaB4eUrxoguDmb3KhnMQIaLkO8s0=.b93ccb0f-e26e-4650-a890-a40760e81b91@github.com>

On Thu, 19 Dec 2024 05:24:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2513448235

From tschatzl at openjdk.org  Thu Dec 19 07:16:39 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 19 Dec 2024 07:16:39 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
Message-ID: <IEY8nWuRFs_zmaeTxzUZdkgZrmnvyvBZjVA7b6zd0Qo=.60d28629-0852-469e-b5df-83b4a70cd676@github.com>

On Tue, 17 Dec 2024 18:08:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - merge log_set decl/defn
>  - remove default counts for stats incrementers
>  - remove uneeded 'explicit'
>  - cleanup unneeded includes
>  - remove moved-from macro defines
>  - Merge branch 'master' into pa-splitter
>  - rename splitter.step() => claim()
>  - simplify comments
>  - Merge branch 'master' into pa-splitter
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/eb68ee60...54c37988

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22622#pullrequestreview-2513518190

From dskantz at openjdk.org  Thu Dec 19 07:30:07 2024
From: dskantz at openjdk.org (Daniel Skantz)
Date: Thu, 19 Dec 2024 07:30:07 GMT
Subject: RFR: 8346288: WB_IsIntrinsicAvailable fails if called with wrong
 compilation level
Message-ID: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>

Fixes crashes when calling isIntrinsicAvailable with an incorrect compilation level or incompatible VM flag values.

Testing: T1-3.
Extra testing: called isIntrinsicAvailable with compLevel={-2, -1, ..., 5) without extra flags, and with -XX:-TieredCompilation -XX:TieredStopAtLevel={0, 1, ..., 4} and observed no crashes after the fix.

-------------

Commit messages:
 - fix

Changes: https://git.openjdk.org/jdk/pull/22823/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22823&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346288
  Stats: 9 lines in 1 file changed: 7 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22823.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22823/head:pull/22823

PR: https://git.openjdk.org/jdk/pull/22823

From dholmes at openjdk.org  Thu Dec 19 07:52:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 07:52:44 GMT
Subject: [jdk24] RFR: 8321818: vmTestbase/nsk/stress/strace/strace015.java
 failed with 'Cannot read the array length because "<local4>" is null'
In-Reply-To: <oZNtA64v7EVfZf1zJMew2OaA9JG4X_Ygh4aPG61pRX8=.07001fcf-7ba2-413f-af99-42afdcfb0c22@github.com>
References: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>
 <oZNtA64v7EVfZf1zJMew2OaA9JG4X_Ygh4aPG61pRX8=.07001fcf-7ba2-413f-af99-42afdcfb0c22@github.com>
Message-ID: <18zTPjZ8M57GOt-4WC359lCzYRn4-24sfnwre-7x1g8=.9177ded3-e63e-4cce-8435-84041569671f@github.com>

On Wed, 18 Dec 2024 22:36:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [ea50c54a](https://github.com/openjdk/jdk/commit/ea50c54a14d39fcedabe8426a14eaec27ab24af2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by David Holmes on 18 Dec 2024 and was reviewed by Leonid Mesnik and Hamlin Li.
>> 
>> Thanks
>
> Marked as reviewed by lmesnik (Reviewer).

Thanks @lmesnik !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22801#issuecomment-2552995056

From dholmes at openjdk.org  Thu Dec 19 07:52:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 07:52:45 GMT
Subject: [jdk24] Integrated: 8321818:
 vmTestbase/nsk/stress/strace/strace015.java failed with 'Cannot read the array
 length because "<local4>" is null'
In-Reply-To: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>
References: <gMVAlAqYjHIoO-gg4DT5z4B6Is-9Dg_5P5U8--ny7kU=.6388bc46-5b81-4be2-812e-f75cfbe00d80@github.com>
Message-ID: <_G0Nzpov_C8nGhjs29oxYyxZHE1dm2U1UgfEuAs4C2s=.cdaeaa91-48fa-4bf2-b6cb-bdfd0a9cd3e7@github.com>

On Wed, 18 Dec 2024 01:52:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [ea50c54a](https://github.com/openjdk/jdk/commit/ea50c54a14d39fcedabe8426a14eaec27ab24af2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by David Holmes on 18 Dec 2024 and was reviewed by Leonid Mesnik and Hamlin Li.
> 
> Thanks

This pull request has now been integrated.

Changeset: 2c336299
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c336299aabe240ef2f559c711600b2983e28daa
Stats:     53 lines in 9 files changed: 45 ins; 0 del; 8 mod

8321818: vmTestbase/nsk/stress/strace/strace015.java failed with 'Cannot read the array length because "<local4>" is null'

Reviewed-by: lmesnik
Backport-of: ea50c54a14d39fcedabe8426a14eaec27ab24af2

-------------

PR: https://git.openjdk.org/jdk/pull/22801

From qxing at openjdk.org  Thu Dec 19 08:22:05 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Thu, 19 Dec 2024 08:22:05 GMT
Subject: RFR: 8346602: Remove unused macro parameters in `jni.cpp`
Message-ID: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>

Some of the macros in `jni.cpp`, including `DEFINE_GETSCALARARRAYELEMENTS`, `DEFINE_RELEASESCALARARRAYELEMENTS`, `DEFINE_GETSCALARARRAYREGION` and `DEFINE_SETSCALARARRAYREGION`, have unused parameters.

This patch removes them.

-------------

Commit messages:
 - Remove unused macro parameters in `jni.cpp`.

Changes: https://git.openjdk.org/jdk/pull/22824/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22824&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346602
  Stats: 39 lines in 1 file changed: 0 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/22824.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22824/head:pull/22824

PR: https://git.openjdk.org/jdk/pull/22824

From aturbanov at openjdk.org  Thu Dec 19 09:18:40 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 19 Dec 2024 09:18:40 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v5]
In-Reply-To: <D_4mEsBrH8liSvrR0lAh7Skzgo0mcPwUdESsNS5MWvw=.04fe9276-82e7-49c1-b51f-7fc512cbd3a4@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <D_4mEsBrH8liSvrR0lAh7Skzgo0mcPwUdESsNS5MWvw=.04fe9276-82e7-49c1-b51f-7fc512cbd3a4@github.com>
Message-ID: <JLEEjMUmFyOdT2niWdaMFAyq8Br_kuzRdDki90ZD59A=.c3e6d8f3-c116-4c84-ba9c-39aef4b93fd9@github.com>

On Tue, 17 Dec 2024 11:09:09 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 9. X86  backend implementation for all supported intrinsics.
>> 10. Functional and Performance validation tests.
>> 
>> Kindly review the patch and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressing review comments

test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java line 222:

> 220:             }
> 221:         }
> 222:         assertArraysEquals(res, farr, (fp16) ->  Float.isInfinite(fp16.floatValue()));

Suggestion:

        assertArraysEquals(res, farr, (fp16) -> Float.isInfinite(fp16.floatValue()));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1891411255

From mli at openjdk.org  Thu Dec 19 09:29:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 19 Dec 2024 09:29:39 GMT
Subject: [jdk24] Integrated: 8345669: RISC-V: fix client build failure due to
 AlignVector after JDK-8343827
In-Reply-To: <FpGN_oaIRHHS-M2HwWjxQg7YBuQOiljZiLQ8jXVjgH4=.4fab5286-1f4c-4117-9811-46e2ff825c0d@github.com>
References: <FpGN_oaIRHHS-M2HwWjxQg7YBuQOiljZiLQ8jXVjgH4=.4fab5286-1f4c-4117-9811-46e2ff825c0d@github.com>
Message-ID: <JQjMNZbrttsLM4wfahtUmlWRuF5N4T-h7axCvSoOxlo=.827137d0-456d-44ac-9a6e-711310902ebc@github.com>

On Wed, 18 Dec 2024 14:30:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this backport patch?
> Thanks!

This pull request has now been integrated.

Changeset: 303736b0
Author:    Hamlin Li <mli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/303736b038590609cf65bef19cabb6848d211a8d
Stats:     8 lines in 1 file changed: 4 ins; 4 del; 0 mod

8345669: RISC-V: fix client build failure due to AlignVector after JDK-8343827

Reviewed-by: fyang
Backport-of: a24b08fcb0b3784181096f5c669e57e110600056

-------------

PR: https://git.openjdk.org/jdk/pull/22811

From mli at openjdk.org  Thu Dec 19 09:29:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 19 Dec 2024 09:29:38 GMT
Subject: [jdk24] RFR: 8345669: RISC-V: fix client build failure due to
 AlignVector after JDK-8343827
In-Reply-To: <FpGN_oaIRHHS-M2HwWjxQg7YBuQOiljZiLQ8jXVjgH4=.4fab5286-1f4c-4117-9811-46e2ff825c0d@github.com>
References: <FpGN_oaIRHHS-M2HwWjxQg7YBuQOiljZiLQ8jXVjgH4=.4fab5286-1f4c-4117-9811-46e2ff825c0d@github.com>
Message-ID: <0FHn7kzDI9G3UOr-waXaTXCHd5mREDQQX8x8BSBzLe0=.26d63695-12d0-4d32-a46c-c3d137ef63e3@github.com>

On Wed, 18 Dec 2024 14:30:32 GMT, Hamlin Li <mli at openjdk.org> wrote:

> Hi,
> Can you help to review this backport patch?
> Thanks!

Thanks for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22811#issuecomment-2553179163

From stefank at openjdk.org  Thu Dec 19 09:40:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 19 Dec 2024 09:40:07 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace instances
Message-ID: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>

There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.

The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.

Tested tier1 and GHA, but will run more tests when/if this gets accepted.

-------------

Commit messages:
 - 8346572: Check is_reserved() before using ReservedSpace instances

Changes: https://git.openjdk.org/jdk/pull/22825/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22825&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346572
  Stats: 117 lines in 10 files changed: 47 ins; 31 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/22825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22825/head:pull/22825

PR: https://git.openjdk.org/jdk/pull/22825

From mli at openjdk.org  Thu Dec 19 10:41:35 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 19 Dec 2024 10:41:35 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <5FV6Rb6ZXXbkeFcQuXlBVKvtZ4bjHI_5bA9rDg7-6tU=.1e38a041-0d14-4cb4-b3dc-4e4a5e0a57a0@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

Looks good.

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22819#pullrequestreview-2514032898

From coleenp at openjdk.org  Thu Dec 19 12:52:34 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:52:34 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/opto/library_call.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/3106bdd3..cc69a3f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

PR: https://git.openjdk.org/jdk/pull/22246

From coleenp at openjdk.org  Thu Dec 19 12:52:35 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:52:35 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <Fxi3bpvaxo6Ykk4meQqFhFYu36gLYkykHSkUD6ahA3M=.b41491e6-9530-47c4-90d9-287641b41ff3@github.com>

On Tue, 19 Nov 2024 16:18:48 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

The as_int() was because we are using the AccessFlags as an _integral_ value.  I was trying to minimize the effects of the change and the code uses AccessFlags as an integral value.  as_int() returns u2 so I guess that's confusing.  I don't want AccessFlags::get_flags() because that's implies the return is AccessFlags.  I could change the name to as_unsigned_short().  Would that be less confusing?

Thank you David for looking through this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2553766012

From coleenp at openjdk.org  Thu Dec 19 12:52:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:52:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
Message-ID: <MTbxg4PoKJ1vWg7AOVsmpQPy8rWmr-zcKHh7JPDf_HE=.fb6c414a-6f9f-48e8-b637-d68922b6679a@github.com>

On Thu, 19 Dec 2024 01:48:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/share/opto/library_call.cpp line 3874:
> 
>> 3872: Node* LibraryCallKit::generate_interface_guard(Node* kls, RegionNode* region) {
>> 3873:   return generate_klass_flags_guard(kls, JVM_ACC_INTERFACE, 0, region,
>> 3874:                                     Klass::access_flags_offset(), TypeInt::CHAR, T_CHAR);
> 
> Is this CHAR/T_CHAR because you want unsigned?

Yes.  T_SHORT generates the wrong code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1891931433

From coleenp at openjdk.org  Thu Dec 19 12:56:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 12:56:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
Message-ID: <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>

On Thu, 19 Dec 2024 01:33:57 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 690:
> 
>> 688:     push(state);
>> 689: 
>> 690:     // Skip if we don't have to unlock. (???is this right???)
> 
> The logic seems consistent with other platforms. Not sure what you are querying.

It wasn't the logic.  When I went through I didn't know if this instruction needed fixing because we loaded an unsigned short instead of an int.  So I left myself a note to look at it again that you noticed and I didn't in my final walk through.  It seems right but maybe someone with ppc knowledge can answer this.


    rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1891953704

From aph at openjdk.org  Thu Dec 19 13:50:43 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 19 Dec 2024 13:50:43 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
Message-ID: <dVCmPOdJKEIUVsGjrtKhlVM8g87UOYGd9lO5jS8sYzg=.aba7ae4e-8ecc-48a3-8c18-aaa11b52eb6d@github.com>

On Thu, 19 Dec 2024 12:52:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/opto/library_call.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 823:

> 821:   {
> 822:     Label done;
> 823:     __ load_unsigned_short(r0, access_flags);

Could you please use `ldrh` rather than `load_unsigned_short` here? `load_unsigned_short` is only used in the termplate interpreter, and is a hangover from the hand-translation from x86.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1892155007

From fyang at openjdk.org  Thu Dec 19 15:50:22 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Dec 2024 15:50:22 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v3]
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check
> about the immediate range and save the tmp register used by the latter as well. In order to make the code more readable, this
> also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> Testing: tier1-3 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Revert unnecessary changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22804/files
  - new: https://git.openjdk.org/jdk/pull/22804/files/58e9a0eb..4f8a6662

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=01-02

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

PR: https://git.openjdk.org/jdk/pull/22804

From kbarrett at openjdk.org  Thu Dec 19 16:05:49 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 19 Dec 2024 16:05:49 GMT
Subject: RFR: 8345732: Provide helpers for using PartialArrayState [v4]
In-Reply-To: <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
 <R4T4DXp64W0BWZFbbV7euom-8KsqudSojeVrZaS3TYw=.23adc797-1f1a-4cf6-b3ea-d2e73fd373dd@github.com>
Message-ID: <Jv_TP10sDLXW0ovek2Fk-FIUU7jfJ6lOdsyrFG-KKgU=.9d3536a9-17f4-4697-b634-69da0d46c22f@github.com>

On Tue, 17 Dec 2024 18:08:23 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change that introduces two new helper classes to simplify
>> the usage of PartialArrayStates to manage splitting the processing of large
>> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
>> changed to use this new mechanism.
>> 
>> PartialArrayTaskStats is used to collect and report statistics related to
>> array splitting.  It replaces the direct implementation in PSPromotionManager,
>> and is now also used by G1 young GCs.
>> 
>> PartialArraySplitter packages up most of the work involved in splitting and
>> processing tasks. It provides task allocation and release, enqueuing, chunk
>> claiming, and statistics tracking. It does this by encapsulating existing
>> objects and functionality. Using array splitting is mostly reduced to calling
>> the splitter's start function and then calling it's step function to process
>> partial states. This substantially reduces the amount of code for each client
>> to perform this work.
>> 
>> Testing: mach5 tier1-5
>> 
>> Manually ran some test programs with each of G1 and Parallel, with taskqueue
>> stats logging enabled, and checked that the logged statistics looked okay.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge branch 'master' into pa-splitter
>  - merge log_set decl/defn
>  - remove default counts for stats incrementers
>  - remove uneeded 'explicit'
>  - cleanup unneeded includes
>  - remove moved-from macro defines
>  - Merge branch 'master' into pa-splitter
>  - rename splitter.step() => claim()
>  - simplify comments
>  - Merge branch 'master' into pa-splitter
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/1a1ee563...54c37988

Thanks all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22622#issuecomment-2554792809

From kbarrett at openjdk.org  Thu Dec 19 16:05:52 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 19 Dec 2024 16:05:52 GMT
Subject: Integrated: 8345732: Provide helpers for using PartialArrayState
In-Reply-To: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
References: <gtE3WH_9-QXJyoF0fEp67wdUuBSDv2m-mqx3l6I3lOA=.c54e47ca-4089-44c4-9cfd-d7733100f9f3@github.com>
Message-ID: <PO742CWMlSuQZ9lWwfoVzFRq3uaXR9QJrtXGKYe9I_U=.3fbc0b7b-0361-4d08-9815-564631fea0de@github.com>

On Fri, 6 Dec 2024 23:27:33 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change that introduces two new helper classes to simplify
> the usage of PartialArrayStates to manage splitting the processing of large
> object arrays into parallelizable chunks.  G1 and Parallel young GCs are
> changed to use this new mechanism.
> 
> PartialArrayTaskStats is used to collect and report statistics related to
> array splitting.  It replaces the direct implementation in PSPromotionManager,
> and is now also used by G1 young GCs.
> 
> PartialArraySplitter packages up most of the work involved in splitting and
> processing tasks. It provides task allocation and release, enqueuing, chunk
> claiming, and statistics tracking. It does this by encapsulating existing
> objects and functionality. Using array splitting is mostly reduced to calling
> the splitter's start function and then calling it's step function to process
> partial states. This substantially reduces the amount of code for each client
> to perform this work.
> 
> Testing: mach5 tier1-5
> 
> Manually ran some test programs with each of G1 and Parallel, with taskqueue
> stats logging enabled, and checked that the logged statistics looked okay.

This pull request has now been integrated.

Changeset: 2344a1a9
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2344a1a917ec6f6380a8187af9f6c369ac3da6cb
Stats:     674 lines in 14 files changed: 489 ins; 123 del; 62 mod

8345732: Provide helpers for using PartialArrayState

Reviewed-by: tschatzl, ayang, zgu, iwalulya

-------------

PR: https://git.openjdk.org/jdk/pull/22622

From bpb at openjdk.org  Thu Dec 19 16:19:50 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Dec 2024 16:19:50 GMT
Subject: Integrated: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <ls7q11o6XhtCn7fQ5nGJRhaQ3k3naRxAr4iWwGkPddc=.3a6c7ccd-61b0-42d1-822b-707ccab74b3a@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

This pull request has now been integrated.

Changeset: 4d77dbad
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d77dbad4e15c5392878e7bc91cd8eb7ce49a482
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from test/hotspot/jtreg/ProblemList.txt

Reviewed-by: alanb, jpai, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22819

From duke at openjdk.org  Thu Dec 19 17:03:50 2024
From: duke at openjdk.org (duke)
Date: Thu, 19 Dec 2024 17:03:50 GMT
Subject: Withdrawn: 8340178: Make ArrayWithFreeList have Index type and move to
 utilities
In-Reply-To: <60GYHj6KckbaHKY1mDgIyiEjzkqdAKpRyNchQXi37xE=.2b6b0cbb-4066-4c56-9ff6-af58ffd55b38@github.com>
References: <60GYHj6KckbaHKY1mDgIyiEjzkqdAKpRyNchQXi37xE=.2b6b0cbb-4066-4c56-9ff6-af58ffd55b38@github.com>
Message-ID: <Vv0p9BbXfLvu_eciGe46vdwHTEep0blY2BnJLc1FSN4=.da4bbe88-c828-4d05-9900-019a4270451e@github.com>

On Wed, 3 Jul 2024 10:06:09 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Hi,
> 
> This PR does multiple things:
> 
> 1. Gives `AWFL` an index template `I` which specifies the type of the indices, this lets us have very small indices and that saves memory.
> 2. Gives `AWFL` the ability to store things in a static memory area of a specific length
> 3. Finally, moves it to utilities for general consumption
> 
> For some context:
> 
> I tried to give `GrowableArray` the index type feature, but I hit a brick wall at changing the assert messages. It's also not a feature which has consensus, some people like it, and some people think it's too complex. I find putting a smaller and hidden `resizable_array` class In AWFL to be an acceptable compromise. I also believe that `GA` will not find too much competition with `AWFL`, as it has a less rich API and is really meant as an allocator interface rather than a general array type.
> 
> **Hint for reviewers:** Do NOT go into "Files changed", look at the commits to see the actual changes and ignore the commits with "Move" in the title.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20002

From dlong at openjdk.org  Thu Dec 19 19:10:36 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 19 Dec 2024 19:10:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
Message-ID: <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>

On Thu, 19 Dec 2024 12:52:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/opto/library_call.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>

src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 691:

> 689: 
> 690:     // Skip if we don't have to unlock. (???is this right???)
> 691:     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.

Using `testbitdi` might make it more readable to non-experts.  It took me a while reading aix docs to realize that this platform numbers LSB as 63 and MSB/sign as 0.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1893009550

From amenkov at openjdk.org  Thu Dec 19 19:23:36 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 19 Dec 2024 19:23:36 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
Message-ID: <_wulnP9V0mncTcDa6jWzSm9pluNCIwrtlMkO_QD__zM=.4f5c659a-aa06-4a90-ac3d-27b747e6468b@github.com>

On Thu, 19 Dec 2024 04:46:12 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned

test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 470:

> 468:     LOG("NotifyFramePop at VirtualThreadUnmount event returned expected JVMTI_ERROR_DUPLICATE\n");
> 469:   } else {
> 470:     LOG("Failed: expected JVMTI_ERROR_DUPLICATE from NotifyFramePop at VirtualThreadUnmount event\n");

Would be nice to log returned value, something like


    LOG("Failed: NotifyFramePop at VirtualThreadUnmount returned %s (%d) instead of expected JVMTI_ERROR_DUPLICATE\n",
           TranslateError(err), err);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1893023250

From amenkov at openjdk.org  Thu Dec 19 19:28:40 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Thu, 19 Dec 2024 19:28:40 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
In-Reply-To: <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
Message-ID: <VjnVLrI7C8RuPct8ujtjGEd8nNj5FPhTolwlWCts5hU=.578e3ac0-cf7f-4c04-90c4-4efdb43c597d@github.com>

On Thu, 19 Dec 2024 05:24:20 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp

Marked as reviewed by amenkov (Reviewer).

src/hotspot/share/prims/jvmtiEnvThreadState.hpp line 89:

> 87:   void set(JvmtiFramePop& fp);
> 88:   void clear(JvmtiFramePop& fp);
> 89:   void clear_all();

Need to update copyright year

-------------

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2515999210
PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1893027385

From coleenp at openjdk.org  Thu Dec 19 20:15:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 20:15:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v3]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <3L1E24-MgN60lpElt0drkUi3nBz3n078fcx9iwab-U8=.0054a22f-90cc-4e07-ac2b-f52558b9775c@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Fixed bug.
 - Fix merge and compilation errors.
 - Merge branch 'master' into access-flags
 - Renamed AccessFlags.as_int() to as_unsigned_short(), moved masks for method, field and class modifiers into AccessFlags. Change ciFlags to use AccessFlags.
 - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Update src/hotspot/share/opto/library_call.cpp
   
   Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
 - Remove JVM_ACC_WRITTEN_FLAGS because they are all written in the classfile now.
 - 8339113: AccessFlags can be u2 in metadata

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/cc69a3f2..522ade8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=01-02

  Stats: 5573 lines in 201 files changed: 3545 ins; 1398 del; 630 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

PR: https://git.openjdk.org/jdk/pull/22246

From coleenp at openjdk.org  Thu Dec 19 20:15:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 20:15:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <dVCmPOdJKEIUVsGjrtKhlVM8g87UOYGd9lO5jS8sYzg=.aba7ae4e-8ecc-48a3-8c18-aaa11b52eb6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
 <dVCmPOdJKEIUVsGjrtKhlVM8g87UOYGd9lO5jS8sYzg=.aba7ae4e-8ecc-48a3-8c18-aaa11b52eb6d@github.com>
Message-ID: <1hwxD50hCezqeSWdKVroWZhJkP4MiTH0votpw4YBOGs=.3b77bab6-0479-4b7b-aa1f-92b33efe28cd@github.com>

On Thu, 19 Dec 2024 13:48:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 823:
> 
>> 821:   {
>> 822:     Label done;
>> 823:     __ load_unsigned_short(r0, access_flags);
> 
> Could you please use `ldrh` rather than `load_unsigned_short` here? `load_unsigned_short` is only used in the termplate interpreter, and is a hangover from the hand-translation from x86.

Oh, I thought it was quite nice that I didn't have to know the ldrh instruction as a platform independent load_unsigned_short was available.  I can change it in the aarch64 code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1893073141

From kvn at openjdk.org  Thu Dec 19 20:22:49 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 19 Dec 2024 20:22:49 GMT
Subject: RFR: 8346288: WB_IsIntrinsicAvailable fails if called with wrong
 compilation level
In-Reply-To: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
References: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
Message-ID: <h1f21ZzWg_tu3U25uIPLUM2VJ8XtTQxwh1jKjWDA19w=.7b08a2c6-fe7a-4d0e-b7c1-94141f3ed419@github.com>

On Thu, 19 Dec 2024 07:25:15 GMT, Daniel Skantz <dskantz at openjdk.org> wrote:

> Fixes crashes when calling isIntrinsicAvailable with an incorrect compilation level or incompatible VM flag values.
> 
> Testing: T1-3.
> Extra testing: called isIntrinsicAvailable with compLevel={-2, -1, ..., 5) without extra flags, and with -XX:-TieredCompilation -XX:TieredStopAtLevel={0, 1, ..., 4} and observed no crashes after the fix.

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22823#pullrequestreview-2516092478

From coleenp at openjdk.org  Thu Dec 19 20:29:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 20:29:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
 <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>
Message-ID: <T4gc8ddEsijIPlsS_tjsFzSIpGeXeBVxGKhx7ejU-uA=.1977d4f0-95fa-4bc4-a14d-a52e9934e38c@github.com>

On Thu, 19 Dec 2024 19:08:06 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - Update src/hotspot/share/opto/library_call.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>
> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 691:
> 
>> 689: 
>> 690:     // Skip if we don't have to unlock. (???is this right???)
>> 691:     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.
> 
> Using `testbitdi` might make it more readable to non-experts.  It took me a while reading aix docs to realize that this platform numbers LSB as 63 and MSB/sign as 0.

yes I like testbitdi better.  I found a sample in the templateInterpreterGenerator code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1893099373

From duke at openjdk.org  Thu Dec 19 21:04:51 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 19 Dec 2024 21:04:51 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/9015d984..f519c3b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=04-05

  Stats: 37 lines in 12 files changed: 9 ins; 1 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From duke at openjdk.org  Thu Dec 19 21:04:53 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 19 Dec 2024 21:04:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v5]
In-Reply-To: <laIxVxbUrtPGON0nIPCZ9tgQtF3ke2NFuf3Ftny9LmQ=.770e9807-7553-4beb-966d-c7d6f097870e@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <sKfiW0jCYqtS1g1_-d5KzCR56V7ckhCRlSTGYr_VPa0=.52bf8f29-a000-4296-88e7-1af09628e00c@github.com>
 <laIxVxbUrtPGON0nIPCZ9tgQtF3ke2NFuf3Ftny9LmQ=.770e9807-7553-4beb-966d-c7d6f097870e@github.com>
Message-ID: <TzUUNf637N1BlrQWnaWunNzzUC1WsKGLJu2cUmywpcU=.0e7f8637-ac52-4389-83d1-ecc9bbdd6617@github.com>

On Wed, 18 Dec 2024 23:01:38 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge master
>>  - move MemTracker::set_done_bootstrap()
>>  - Update src/hotspot/share/utilities/vmError.cpp
>>    
>>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>>  - updates tests and remove old class
>>  - use ConditionalMutexLocker directly
>>  - Fix concurrency issue. Add assertions. Update tests.
>>  - Revert "8343726: [BACKOUT] NMT should not use ThreadCritical"
>>    
>>    This reverts commit c3df050b88ecef123199a4e96f6d9884d064ae45.
>
> Oh yes, now I see, sorry I did repeat Kim's suggestion.

Thank you @coleenp  and @kimbarrett for the advice on the best way to use `ConditionalMutexLocker` without subclassing it. I've adopted your suggestions.

> src/hotspot/share/runtime/mutexLocker.cpp line 292:
> 
>> 290:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
>> 291:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
>> 292:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4);
> 
> Why is this service-4?  Does it depend on being a rank lower than another lock?  If so, this and the SharedDecoder_lock should be declared below as MUTEX_DEFL and call out that lock.

Yes, it must have a lower rank than "G1Mapper_lock" which is in `G1RegionsSmallerThanCommitSizeMapper`, not in `mutexLocker.cpp`.  I've moved `SharedDecoder_lock` down below as `MUTEX_DEFL` and I've left a comment beside `MUTEX_DEFN(NmtVirtualMemory_lock, PaddedMutex  , service-4);` to explain the rank. Would this be enough?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2555767690
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893136241

From duke at openjdk.org  Thu Dec 19 21:04:53 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Thu, 19 Dec 2024 21:04:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
 <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
Message-ID: <4GdE0Yc2QNtbtPJeRY1Xr9ruapEWooJ7Q598uO6cHQQ=.788b7c0a-b96e-4de7-9ce2-73e3546207d1@github.com>

On Thu, 19 Dec 2024 02:19:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change was decided on in the original PR after it was discovered that calling [os::print_memory_mappings](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/os/windows/os_windows.cpp#L3623) from the windows implementation of `os::pd_release_memory` causes a rank conflict between `tty_lock` and `NmtVirtualMemory_lock`. This is getting called from `os::release_memory` [after we've already acquired the lock for NMT](https://github.com/openjdk/jdk/blob/jdk-25%2B2/src/hotspot/share/runtime/os.cpp#L2202-L2203).
>> 
>> Original discussion here https://github.com/openjdk/jdk/pull/20852#issuecomment-2350882050.
>
> Okay ... still not sure this shouldn't be dynamically determining whether stdout or stderr is the right target.

Ok I see. I've changed it now to use `defaultStream::output_stream()` which should choose either stderr or stdout based on the VM flags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893138320

From dholmes at openjdk.org  Thu Dec 19 21:07:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 21:07:34 GMT
Subject: RFR: 8346602: Remove unused macro parameters in `jni.cpp`
In-Reply-To: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
References: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
Message-ID: <WB62uql8vIgbMQRLWVmb--kS1oGfnqzuc-qKXCdblMo=.4a920196-4ffb-4de7-8566-2594e62cd8ca@github.com>

On Thu, 19 Dec 2024 08:16:54 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> Some of the macros in `jni.cpp`, including `DEFINE_GETSCALARARRAYELEMENTS`, `DEFINE_RELEASESCALARARRAYELEMENTS`, `DEFINE_GETSCALARARRAYREGION` and `DEFINE_SETSCALARARRAYREGION`, have unused parameters.
> 
> This patch removes them.

Wow - how did you spot that? These parameters have been unused since the day the code was added!

LGTM.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22824#pullrequestreview-2516202657

From dholmes at openjdk.org  Thu Dec 19 21:11:36 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Dec 2024 21:11:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata
In-Reply-To: <Fxi3bpvaxo6Ykk4meQqFhFYu36gLYkykHSkUD6ahA3M=.b41491e6-9530-47c4-90d9-287641b41ff3@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <Fxi3bpvaxo6Ykk4meQqFhFYu36gLYkykHSkUD6ahA3M=.b41491e6-9530-47c4-90d9-287641b41ff3@github.com>
Message-ID: <0AxZxBjocVYDGFLq6nYhjXOd_TwAJ4qseWsBlYurNnE=.25da67e6-9a51-4229-9118-540d3f775601@github.com>

On Thu, 19 Dec 2024 12:47:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>  I could change the name to as_unsigned_short(). Would that be less confusing?

How about `as_u2()` as that is what it is? (less typing :) ).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2555777513

From coleenp at openjdk.org  Thu Dec 19 22:22:13 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 22:22:13 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v4]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <7xCemQV3MFSKQh81__K-VbLDj8lZYPwfy6a-s0_MAz0=.a01e2ef0-b2ef-4bdb-be2c-2671707a8f90@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Use ldrh rather than load_unsigned_short for aarch64, use testbitdi for ppc.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/522ade8c..828e4835

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=02-03

  Stats: 12 lines in 4 files changed: 0 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

PR: https://git.openjdk.org/jdk/pull/22246

From coleenp at openjdk.org  Thu Dec 19 22:22:14 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 19 Dec 2024 22:22:14 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v3]
In-Reply-To: <3L1E24-MgN60lpElt0drkUi3nBz3n078fcx9iwab-U8=.0054a22f-90cc-4e07-ac2b-f52558b9775c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <3L1E24-MgN60lpElt0drkUi3nBz3n078fcx9iwab-U8=.0054a22f-90cc-4e07-ac2b-f52558b9775c@github.com>
Message-ID: <QdHSICvr1Z5EplzuPkni6ucHZ93kSZt2TRJHEp6sen4=.12b4e08f-3616-4263-8865-7ddc62f473b5@github.com>

On Thu, 19 Dec 2024 20:15:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Fixed bug.
>  - Fix merge and compilation errors.
>  - Merge branch 'master' into access-flags
>  - Renamed AccessFlags.as_int() to as_unsigned_short(), moved masks for method, field and class modifiers into AccessFlags. Change ciFlags to use AccessFlags.
>  - Update src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Update src/hotspot/share/opto/library_call.cpp
>    
>    Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com>
>  - Remove JVM_ACC_WRITTEN_FLAGS because they are all written in the classfile now.
>  - 8339113: AccessFlags can be u2 in metadata

I didn't really like that name since it's the name of the type rather than more of a description of the type returned.  I was able to reduce the number of these by adding some helper functions in AccessFlags.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2555868918

From kbarrett at openjdk.org  Thu Dec 19 22:59:44 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 19 Dec 2024 22:59:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
Message-ID: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>

On Thu, 19 Dec 2024 21:04:51 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

Changes requested by kbarrett (Reviewer).

src/hotspot/share/nmt/memTracker.hpp line 72:

> 70:     _done_bootstrap = true;
> 71:   }
> 72: 

I think I would prefer "bootstrap_done" rather than "done_bootstrap" throughout.  But you should get
opinions from some of the runtime folks like @coleenp and @dholmes-ora .

src/hotspot/share/nmt/memTracker.hpp line 285:

> 283:       ConditionalMutexLocker _cml;
> 284:   public:
> 285:       NmtVirtualMemoryLocker(): _cml(NmtVirtualMemory_lock, _done_bootstrap, Mutex::_no_safepoint_check_flag){}

Indented 4, but HotSpot style is indent 2.

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 341:

> 339:   assert(_reserved_regions != nullptr, "Sanity check");
> 340:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
> 341: 

This line is kind of long.  And why the space before the comma?  And there's a bunch of
these, suggesting there should be a helper to package this up.

src/hotspot/share/utilities/vmError.cpp line 652:

> 650: 
> 651:   BEGIN
> 652:   if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr  && MemTracker::is_done_bootstrap() && NmtVirtualMemory_lock->owned_by_self()) {

This line is rather long.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2516359489
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893232700
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893228258
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893234021
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1893236557

From sspitsyn at openjdk.org  Fri Dec 20 01:17:49 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:17:49 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v7]
In-Reply-To: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
Message-ID: <sdAIaNXI51xpFyCDX8jYqwFBbT33SsGqGutd0CIRMoA=.8da9cdb9-ea25-4374-8ccf-8687ce3cc24f@github.com>

> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
> 
> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
> 
> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
> 
> Testing:
>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: updated one copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22744/files
  - new: https://git.openjdk.org/jdk/pull/22744/files/0d762462..21ca5294

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22744&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22744/head:pull/22744

PR: https://git.openjdk.org/jdk/pull/22744

From sspitsyn at openjdk.org  Fri Dec 20 01:17:50 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:17:50 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v6]
In-Reply-To: <VjnVLrI7C8RuPct8ujtjGEd8nNj5FPhTolwlWCts5hU=.578e3ac0-cf7f-4c04-90c4-4efdb43c597d@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <8_pueheWXMMFty3hym8te9TARMEEIRo8YC6vIT_fXLo=.61a387c0-f43d-4ca9-b946-97d343574546@github.com>
 <VjnVLrI7C8RuPct8ujtjGEd8nNj5FPhTolwlWCts5hU=.578e3ac0-cf7f-4c04-90c4-4efdb43c597d@github.com>
Message-ID: <sBqmQlp0FCHK7W3POfLxci86uYWEkmB8OMRBl7ZlvO8=.bf4020ca-f80d-4898-8c8a-4d8b5c3142a9@github.com>

On Thu, 19 Dec 2024 19:24:36 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: addressed comments for new test, jvmti.xml, jvmtiEnvThreadState.cpp
>
> src/hotspot/share/prims/jvmtiEnvThreadState.hpp line 89:
> 
>> 87:   void set(JvmtiFramePop& fp);
>> 88:   void clear(JvmtiFramePop& fp);
>> 89:   void clear_all();
> 
> Need to update copyright year

Thanks. Updated now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22744#discussion_r1893315706

From sspitsyn at openjdk.org  Fri Dec 20 01:23:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:23:22 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
Message-ID: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>

> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
> 
> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
> 
> Testing:
>  - tested with mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  review: improved one failure logging a little bit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22798/files
  - new: https://git.openjdk.org/jdk/pull/22798/files/defa6206..2b3fef1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22798&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22798.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22798/head:pull/22798

PR: https://git.openjdk.org/jdk/pull/22798

From sspitsyn at openjdk.org  Fri Dec 20 01:23:22 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:23:22 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v3]
In-Reply-To: <_wulnP9V0mncTcDa6jWzSm9pluNCIwrtlMkO_QD__zM=.4f5c659a-aa06-4a90-ac3d-27b747e6468b@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <XPnDetiBdFXABnQj5HnHbG85hc23dVcc0G-cqoi3ttU=.6781a0f3-4e91-4fd4-825b-16c90ebd2898@github.com>
 <_wulnP9V0mncTcDa6jWzSm9pluNCIwrtlMkO_QD__zM=.4f5c659a-aa06-4a90-ac3d-27b747e6468b@github.com>
Message-ID: <wMZdi0hCLF5V7vRYKtrIL6AGjyGpsyTqL5QzqPUeQjA=.151bc32d-12a8-49c4-8885-edbf6878d2e2@github.com>

On Thu, 19 Dec 2024 19:20:21 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: added NotifyFramePop test case to check JVMTI_ERROR_DUPLICATE is returned
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/MethodExitTest/libMethodExitTest.cpp line 470:
> 
>> 468:     LOG("NotifyFramePop at VirtualThreadUnmount event returned expected JVMTI_ERROR_DUPLICATE\n");
>> 469:   } else {
>> 470:     LOG("Failed: expected JVMTI_ERROR_DUPLICATE from NotifyFramePop at VirtualThreadUnmount event\n");
> 
> Would be nice to log returned value, something like
> 
> 
>     LOG("Failed: NotifyFramePop at VirtualThreadUnmount returned %s (%d) instead of expected JVMTI_ERROR_DUPLICATE\n",
>            TranslateError(err), err);

Thanks. Updated now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1893319148

From sspitsyn at openjdk.org  Fri Dec 20 01:25:36 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 01:25:36 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <feyLIGUwsTniQCKgKA71yXtaKAufPmb_KmDrdwRZSTU=.a264a170-69cc-48b6-af74-e99c7c8793e5@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <feyLIGUwsTniQCKgKA71yXtaKAufPmb_KmDrdwRZSTU=.a264a170-69cc-48b6-af74-e99c7c8793e5@github.com>
Message-ID: <GERxLWvEb6A-e0WvP-rR27KEZg1gljDpeXqj2L9DmVo=.7c6adafb-72bb-4552-b37d-b835ead747e0@github.com>

On Tue, 17 Dec 2024 21:41:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: improved one failure logging a little bit
>
> src/hotspot/share/prims/jvmti.xml line 3088:
> 
>> 3086:         </error>
>> 3087:         <error id="JVMTI_ERROR_DUPLICATE">
>> 3088:           There is already frame pop event request at the specified depth.
> 
> Suggestion:
> 
>           There is already a frame pop event request at the specified depth.

Thanks. This was fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22798#discussion_r1893320347

From amenkov at openjdk.org  Fri Dec 20 03:07:43 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 20 Dec 2024 03:07:43 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
Message-ID: <YqIY0yZ9IrKN9dYxWJWZDUyDOyP7AHT7hmz2TEJPPGE=.692cd5df-d331-4c28-9187-5ec3f145bcec@github.com>

On Fri, 20 Dec 2024 01:23:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: improved one failure logging a little bit

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2516639718

From amenkov at openjdk.org  Fri Dec 20 03:08:37 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 20 Dec 2024 03:08:37 GMT
Subject: RFR: 8346143: add ClearAllFramePops function to speedup debugger
 single stepping in some cases [v7]
In-Reply-To: <sdAIaNXI51xpFyCDX8jYqwFBbT33SsGqGutd0CIRMoA=.8da9cdb9-ea25-4374-8ccf-8687ce3cc24f@github.com>
References: <eTh55fr8NuZ0MGcm-1a-mlwtfQr6o4pwRSZMAvdy1jE=.2337908f-25b9-4283-959e-100bc69ff5ef@github.com>
 <sdAIaNXI51xpFyCDX8jYqwFBbT33SsGqGutd0CIRMoA=.8da9cdb9-ea25-4374-8ccf-8687ce3cc24f@github.com>
Message-ID: <z4zUZkaPvv99xYFe8XJasd_fKIs1M2XEpOo6_F-ALj4=.50fab829-6fd6-4a42-8dfe-ea8bf85cdea6@github.com>

On Fri, 20 Dec 2024 01:17:49 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> New JVMTI function `ClearAllFramePops` will help to speedup debugger single stepping in some cases.
>> Additionally, the JVMTI `NotifyFramePop` implementation was fixed to return `JVMTI_ERROR_DUPLICATE` to make it consistent with the `SetBreakpoint` which also returns this error.
>> 
>> The JDWP agent fix will be needed to make use of this new JVMTI function. The corresponding debugger bug is:
>> [8229012](https://bugs.openjdk.org/browse/JDK-8229012): When single stepping, the debug agent can cause the thread to remain in interpreter mode after single stepping completes
>> 
>> CSR: [8346144](https://bugs.openjdk.org/browse/JDK-8346144): add ClearAllFramePops function to speedup debugger single stepping in some cases
>> 
>> Testing:
>>  - mach5 tiers 1-6 were run to make sure this fix caused no regressions
>>  - Chris tested the JVMTI patch with his JDWP fix of [8229012](https://bugs.openjdk.org/browse/JDK-8229012).
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: updated one copyright year

Marked as reviewed by amenkov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22744#pullrequestreview-2516644271

From dholmes at openjdk.org  Fri Dec 20 05:05:37 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Dec 2024 05:05:37 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v4]
In-Reply-To: <7xCemQV3MFSKQh81__K-VbLDj8lZYPwfy6a-s0_MAz0=.a01e2ef0-b2ef-4bdb-be2c-2671707a8f90@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <7xCemQV3MFSKQh81__K-VbLDj8lZYPwfy6a-s0_MAz0=.a01e2ef0-b2ef-4bdb-be2c-2671707a8f90@github.com>
Message-ID: <S76F1PHjzrzWhrV7AfPYVCphjimVT2wo65Iw3eGjSc4=.82b52756-0aa5-405a-afbe-34a2c5629c02@github.com>

On Thu, 19 Dec 2024 22:22:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ldrh rather than load_unsigned_short for aarch64, use testbitdi for ppc.

Things become somewhat clearer once one realizes/recalls that `AccessFlags` do not specifically pertain to access, but to all class/method modifiers as per the various JVMS ACC_XXX constants. We need to restore the leading comment in accessFlags.hpp to read

// AccessFlags is an abstraction over Java ACC flags.

as it originally did.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2556293078

From sspitsyn at openjdk.org  Fri Dec 20 05:19:41 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 20 Dec 2024 05:19:41 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
Message-ID: <zMCws6vT1RN8VUeXi0CMkOOE2ufcpCIVVhL8C7ywR0M=.1e03f9c8-5256-4016-a12d-57556c18fa69@github.com>

On Fri, 20 Dec 2024 01:23:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: improved one failure logging a little bit

Thank you for review, Alex!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22798#issuecomment-2556306574

From qxing at openjdk.org  Fri Dec 20 08:58:45 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Fri, 20 Dec 2024 08:58:45 GMT
Subject: RFR: 8346602: Remove unused macro parameters in `jni.cpp`
In-Reply-To: <WB62uql8vIgbMQRLWVmb--kS1oGfnqzuc-qKXCdblMo=.4a920196-4ffb-4de7-8566-2594e62cd8ca@github.com>
References: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
 <WB62uql8vIgbMQRLWVmb--kS1oGfnqzuc-qKXCdblMo=.4a920196-4ffb-4de7-8566-2594e62cd8ca@github.com>
Message-ID: <Tfw1mHOAx1CXq7AXFNAEPwCNWlJclCcQie-hA8gNnDA=.06a88164-d4b6-4cb7-a78e-47a6fa66eae7@github.com>

On Thu, 19 Dec 2024 21:05:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Some of the macros in `jni.cpp`, including `DEFINE_GETSCALARARRAYELEMENTS`, `DEFINE_RELEASESCALARARRAYELEMENTS`, `DEFINE_GETSCALARARRAYREGION` and `DEFINE_SETSCALARARRAYREGION`, have unused parameters.
>> 
>> This patch removes them.
>
> Wow - how did you spot that? These parameters have been unused since the day the code was added!
> 
> LGTM.
> 
> Thanks

@dholmes-ora Thanks for your review!

> Wow - how did you spot that? These parameters have been unused since the day the code was added!

I was trying to work on JNI related implementations recently, and just happened to find this ?.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22824#issuecomment-2556555179

From mli at openjdk.org  Fri Dec 20 09:17:34 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 20 Dec 2024 09:17:34 GMT
Subject: RFR: 8346602: Remove unused macro parameters in `jni.cpp`
In-Reply-To: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
References: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
Message-ID: <o67vj-RXX0DLZu_FgmRy5Q39CQblHfoteov-_uO-r8A=.b427f208-b974-46aa-ba73-3c4c53c57b40@github.com>

On Thu, 19 Dec 2024 08:16:54 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> Some of the macros in `jni.cpp`, including `DEFINE_GETSCALARARRAYELEMENTS`, `DEFINE_RELEASESCALARARRAYELEMENTS`, `DEFINE_GETSCALARARRAYREGION` and `DEFINE_SETSCALARARRAYREGION`, have unused parameters.
> 
> This patch removes them.

Looks good, thanks!

-------------

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22824#pullrequestreview-2517102341

From qxing at openjdk.org  Fri Dec 20 09:39:37 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Fri, 20 Dec 2024 09:39:37 GMT
Subject: RFR: 8346602: Remove unused macro parameters in `jni.cpp`
In-Reply-To: <o67vj-RXX0DLZu_FgmRy5Q39CQblHfoteov-_uO-r8A=.b427f208-b974-46aa-ba73-3c4c53c57b40@github.com>
References: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
 <o67vj-RXX0DLZu_FgmRy5Q39CQblHfoteov-_uO-r8A=.b427f208-b974-46aa-ba73-3c4c53c57b40@github.com>
Message-ID: <nbhpnHzooyBdSAM9NUhrkuIHo5uvKCu5vTSosUO1TpQ=.9f3f3ea1-e2ea-42a4-81b5-f43d06f807d0@github.com>

On Fri, 20 Dec 2024 09:14:39 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Some of the macros in `jni.cpp`, including `DEFINE_GETSCALARARRAYELEMENTS`, `DEFINE_RELEASESCALARARRAYELEMENTS`, `DEFINE_GETSCALARARRAYREGION` and `DEFINE_SETSCALARARRAYREGION`, have unused parameters.
>> 
>> This patch removes them.
>
> Looks good, thanks!

@Hamlin-Li Thanks for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22824#issuecomment-2556622441

From duke at openjdk.org  Fri Dec 20 09:39:38 2024
From: duke at openjdk.org (duke)
Date: Fri, 20 Dec 2024 09:39:38 GMT
Subject: RFR: 8346602: Remove unused macro parameters in `jni.cpp`
In-Reply-To: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
References: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
Message-ID: <HqmbyS7vk5X1z-W7hjxFxqJZ5er0hgXOLN91nBwK6Hg=.23dd28cb-09cd-4493-812c-eb423ad1fe55@github.com>

On Thu, 19 Dec 2024 08:16:54 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> Some of the macros in `jni.cpp`, including `DEFINE_GETSCALARARRAYELEMENTS`, `DEFINE_RELEASESCALARARRAYELEMENTS`, `DEFINE_GETSCALARARRAYREGION` and `DEFINE_SETSCALARARRAYREGION`, have unused parameters.
> 
> This patch removes them.

@MaxXSoft 
Your change (at version a7ec34034e0e6c1569db9caf3506d1b1772a8e0c) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22824#issuecomment-2556623954

From mli at openjdk.org  Fri Dec 20 10:31:08 2024
From: mli at openjdk.org (Hamlin Li)
Date: Fri, 20 Dec 2024 10:31:08 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe [v2]
In-Reply-To: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
Message-ID: <m-sbsXrg9J4sFny906TXhtBIt7YSaNlC7knipXcR6sg=.7af90449-83f1-4db0-bc9e-635eab80c557@github.com>

> Hi,
> Can you help to review the patch?
> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
> 
> Thanks!
> 
> Tests running so far so good.

Hamlin Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - merge master
 - only enable Zicboz
 - initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/22474/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22474&range=01
  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22474/head:pull/22474

PR: https://git.openjdk.org/jdk/pull/22474

From rehn at openjdk.org  Fri Dec 20 12:40:54 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 20 Dec 2024 12:40:54 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v3]
In-Reply-To: <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
Message-ID: <SJxQ6aCSXr2eVcD8VDWdmtBWSONzQTfgbRPOWtVcYXE=.69612701-4087-46cd-b05e-d0d6cd0b7bad@github.com>

On Thu, 19 Dec 2024 15:50:22 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  211 would add 211 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] : tier1-3 and gtest:all (release)
>> - [x] : hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unnecessary changes

Hey,

As we have instructions **and** and **andi** but in asm they are called **andr** and **andi**, I suggest we apply this to add/sub also?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22804#issuecomment-2556927747

From fyang at openjdk.org  Fri Dec 20 12:58:36 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 20 Dec 2024 12:58:36 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v3]
In-Reply-To: <SJxQ6aCSXr2eVcD8VDWdmtBWSONzQTfgbRPOWtVcYXE=.69612701-4087-46cd-b05e-d0d6cd0b7bad@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
 <SJxQ6aCSXr2eVcD8VDWdmtBWSONzQTfgbRPOWtVcYXE=.69612701-4087-46cd-b05e-d0d6cd0b7bad@github.com>
Message-ID: <3PgxJf4-2_PF3UyXo1LjqGBHopHVJrjRgD3OEuy_iaw=.1d47db47-3a82-4bdb-8b92-09676e8d8e2c@github.com>

On Fri, 20 Dec 2024 12:38:22 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Hey,
> 
> As we have instructions **and** and **andi** but in asm they are called **andr** and **andi**, I suggest we apply this to add/sub also?

Hi, that's exactly what I am thinking for now :-) I guess this might help with other naming issues as well.
I don't really like other macro-assember routine names such as `MacroAssembler::ror_imm`. I think it should be something simpler like `MacroAssembler::ror`. But we need to rename the `Assembler::ror` as `Assembler::rorr` first.

BTW: We cannot use names like `and`/`xor`/`or` because they are standard C++ operators. That's why we use `andr`/`xorr`/`orr`  for RISC-V and other CPU platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22804#issuecomment-2556944440

From syan at openjdk.org  Fri Dec 20 13:02:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 20 Dec 2024 13:02:15 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying non-zero
 offset to null pointer
Message-ID: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>

Hi all,
CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.

The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.

```c++
    address const end = addr + len;
    if (end <= (address)unscaled_max) {
      _base = nullptr;
      _shift = 0;

-------------

Commit messages:
 - 8346714: [ASAN] compressedKlass.cpp reported applying non-zero offset to null pointer

Changes: https://git.openjdk.org/jdk/pull/22848/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22848&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346714
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22848/head:pull/22848

PR: https://git.openjdk.org/jdk/pull/22848

From coleenp at openjdk.org  Fri Dec 20 13:17:17 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 13:17:17 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
Message-ID: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>

> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
> 
> before:
> 
>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 194, holes: 3, sum holes: 18 */
> 
> 
> after:
> 
>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>         /* sum members: 188, holes: 4, sum holes: 12 */
> 
> 
> We may eventually move the modifiers to java.lang.Class but that's WIP.
> 
> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Restore ACC in comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22246/files
  - new: https://git.openjdk.org/jdk/pull/22246/files/828e4835..4faf19ba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22246&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22246.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22246/head:pull/22246

PR: https://git.openjdk.org/jdk/pull/22246

From fyang at openjdk.org  Fri Dec 20 13:27:38 2024
From: fyang at openjdk.org (Fei Yang)
Date: Fri, 20 Dec 2024 13:27:38 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v3]
In-Reply-To: <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
Message-ID: <4KPVcqDS2xO7Oy4TUYfafLlxwMqUFGZn83tUEbUcBhU=.458fb60b-3963-43c9-a99b-4a22261d9e1a@github.com>

On Thu, 19 Dec 2024 15:50:22 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  211 would add 211 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] : tier1-3 and gtest:all (release)
>> - [x] : hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unnecessary changes

Let's take `add` for example, new proposal about the naming is:

Assembler::addr    ====> add two registers
Assembler::addi    ====> add one register and sign-extended 12-bit immediate

and 

MacroAssembler::add(int64_t increment)    ====> add one register and any 64-bit immediate


Similar for rotate-right:

Assembler::rorr    ====> rotate right variable amount (Zbb)
Assembler::rori    ====> rotate right constant amount (sign-extended 12-bit immediate) (Zbb)

and 

MacroAssembler::ror(Register amount)    ====> Use Zbb rorr if available and basic instructions otherwise
MacroAssembler::ror(uint32_t amount)    ====> Use Zbb rori if available and basic instructions otherwise


Let me know what you think. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22804#issuecomment-2557005905

From coleenp at openjdk.org  Fri Dec 20 13:30:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 13:30:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
Message-ID: <wiAVa84s2rMcdJkxaX2OGz3CSC0tn87Ai2evu9-DqYA=.0822ca14-1a0a-4b9d-b3a6-1d1b0afd7332@github.com>

On Thu, 19 Dec 2024 01:40:41 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Restore ACC in comment.
>
> src/hotspot/share/jfr/leakprofiler/chains/edgeUtils.cpp line 75:
> 
>> 73:     while (!jfs.done()) {
>> 74:       if (offset == jfs.offset()) {
>> 75:         *modifiers = jfs.access_flags().as_int();
> 
> This looks wrong - we want a short and you extracted as an int when it was already a short. ??

I changed as_int() to as_unsigned_short() which hopefully is less confusing, so resolving these conversations/questions.

> src/hotspot/share/oops/method.cpp line 1655:
> 
>> 1653:     return;
>> 1654:   }
>> 1655:   jshort flags = access_flags().as_int();
> 
> Again why the short -> int -> short? And why isn't this unsigned?

The call below takes jshort, so added a checked_cast<>  The top sign bit won't be set because we filter that out (it was ACC_MODULE).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1893940015
PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1893941294

From mdoerr at openjdk.org  Fri Dec 20 14:04:38 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Dec 2024 14:04:38 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer
In-Reply-To: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
Message-ID: <ChmfdK_EwIOuzUqyXag9TMF7w0mAtLkQEjDHRCth2Ag=.9cdc4e0e-8f81-4acd-adf0-86960b5c19de@github.com>

On Fri, 20 Dec 2024 12:56:08 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
> 
> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
> 
> ```c++
>     address const end = addr + len;
>     if (end <= (address)unscaled_max) {
>       _base = nullptr;
>       _shift = 0;

"encoding" is the correct spelling. If you cast `_base` and `encoding_offset` to `uintptr_t` you can do the addition without null check. (Then cast the sum back to `address`.)

-------------

PR Review: https://git.openjdk.org/jdk/pull/22848#pullrequestreview-2517616173

From syan at openjdk.org  Fri Dec 20 15:12:57 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 20 Dec 2024 15:12:57 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
Message-ID: <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>

> Hi all,
> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
> 
> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
> 
> ```c++
>     address const end = addr + len;
>     if (end <= (address)unscaled_max) {
>       _base = nullptr;
>       _shift = 0;

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  case _base to inrptr_t and add the offset, to avoid null check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22848/files
  - new: https://git.openjdk.org/jdk/pull/22848/files/766e09be..6abd26e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22848&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22848&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22848/head:pull/22848

PR: https://git.openjdk.org/jdk/pull/22848

From syan at openjdk.org  Fri Dec 20 15:15:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 20 Dec 2024 15:15:35 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <ChmfdK_EwIOuzUqyXag9TMF7w0mAtLkQEjDHRCth2Ag=.9cdc4e0e-8f81-4acd-adf0-86960b5c19de@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <ChmfdK_EwIOuzUqyXag9TMF7w0mAtLkQEjDHRCth2Ag=.9cdc4e0e-8f81-4acd-adf0-86960b5c19de@github.com>
Message-ID: <SyvskiSH3jehf8bZApsTk5K1NPkthbFDImZeA3SghyU=.1364969b-886a-49f0-af35-bfaf97f560c7@github.com>

On Fri, 20 Dec 2024 14:02:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> "encoding" is the correct spelling. If you cast `_base` and `encoding_offset` to `uintptr_t` you can do the addition without null check. (Then cast the sum back to `address`.)

Thanks for the advice. PR has been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2557194481

From coleenp at openjdk.org  Fri Dec 20 15:18:37 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 15:18:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
Message-ID: <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>

On Thu, 19 Dec 2024 22:50:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/memTracker.hpp line 72:
> 
>> 70:     _done_bootstrap = true;
>> 71:   }
>> 72: 
> 
> I think I would prefer "bootstrap_done" rather than "done_bootstrap" throughout.  But you should get
> opinions from some of the runtime folks like @coleenp and @dholmes-ora .

Yes, I agree, bootstrap_done reads better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894060699

From coleenp at openjdk.org  Fri Dec 20 15:40:39 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 15:40:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
Message-ID: <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>

On Fri, 20 Dec 2024 15:16:10 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/nmt/memTracker.hpp line 72:
>> 
>>> 70:     _done_bootstrap = true;
>>> 71:   }
>>> 72: 
>> 
>> I think I would prefer "bootstrap_done" rather than "done_bootstrap" throughout.  But you should get
>> opinions from some of the runtime folks like @coleenp and @dholmes-ora .
>
> Yes, I agree, bootstrap_done reads better.

There's a few other is_bootstrapping() predicates in the code like Universe::is_bootstrapping.  This might read nicely as is_bootstrapping_done() and the instance is _bootstrapping_done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894069375

From coleenp at openjdk.org  Fri Dec 20 15:40:38 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 15:40:38 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
Message-ID: <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>

On Thu, 19 Dec 2024 21:04:51 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

I had a few minor comments and hopefully easy changes to make.

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 421:

> 419:   assert(_reserved_regions != nullptr, "Sanity check");
> 420:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
> 421: 

You could add this to MemTracker class like:
 ```
 inline static void assert_locked();


Then put the body  

void MemTracker::assert_locked() {
  assert(!is_bootstrapping_done() || NmtVirtualMemory_lock->owned_by_self(),
            "should have acquired NmtVirtualMemory_lock");
}

Then all these calls could be MemTracker::assert_locked().

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 631:

> 629: 
> 630:   bool do_allocation_site(const ReservedMemoryRegion* rgn) {
> 631:     assert_lock_strong(NmtVirtualMemory_lock);

So this is past bootstrapping?

src/hotspot/share/runtime/mutexLocker.cpp line 292:

> 290:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
> 291:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4); // Must be lower than G1Mapper_lock used from G1RegionsSmallerThanCommitSizeMapper::commit_regions
> 292: #if INCLUDE_CDS

Yes, this looks good.  I see why you couldn't move this one to MUTEX_DEFL.

-------------

Changes requested by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2517782112
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894080029
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894080796
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894084698

From mdoerr at openjdk.org  Fri Dec 20 15:44:37 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Dec 2024 15:44:37 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
Message-ID: <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>

On Fri, 20 Dec 2024 15:12:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
>> 
>> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
>> 
>> ```c++
>>     address const end = addr + len;
>>     if (end <= (address)unscaled_max) {
>>       _base = nullptr;
>>       _shift = 0;
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   case _base to inrptr_t and add the offset, to avoid null check

Thanks for fixing the issue! This should work.
In general, I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22848#pullrequestreview-2517816077

From fgao at openjdk.org  Fri Dec 20 15:44:40 2024
From: fgao at openjdk.org (Fei Gao)
Date: Fri, 20 Dec 2024 15:44:40 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v6]
In-Reply-To: <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>
Message-ID: <9uGYNmVdvCXvyYSOAfwmvD70nWkimOFIlQJolQWa_Z4=.c6ffbfa0-5eb1-40a4-83a4-b657f57c9836@github.com>

On Tue, 17 Dec 2024 18:12:24 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Added comment around the assertions
>  - Adjust min/max identity IR test expectations after changes
>  - Fix style
>  - Add max reduction test
>  - Add empty line

test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 135:

> 133:     @IR(applyIf = {"SuperWordReductions", "true"},
> 134:         applyIfCPUFeatureOr = { "avx512", "true" },
> 135:         counts = {IRNode.MIN_REDUCTION_V, " > 0"})

> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further.

Hi @galderz , may I ask if these long-reduction cases can't work even with `sve`? It might be related with the limitation [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566). Some `sve` machines have only 128 bits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1894089883

From syan at openjdk.org  Fri Dec 20 16:08:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 20 Dec 2024 16:08:12 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
Message-ID: <Jcoa2IqTzwGdigYCEIWGZirx8Gp9fU2nulU8-hZfOV0=.ef44adc5-a211-4f67-be33-11d4d0d8c0ad@github.com>

On Fri, 20 Dec 2024 15:41:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. 

Sorry, got it now. The `_base` and offset has been cast to `uintptr_t`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2557283177

From syan at openjdk.org  Fri Dec 20 16:08:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 20 Dec 2024 16:08:12 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v3]
In-Reply-To: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
Message-ID: <XAyOj8fRdrN4dHxlYUc4CGyjdNxpjVf1Yu1J7Gxng4Q=.c2ca1d2f-edd0-4471-b868-4e3249ce23a4@github.com>

> Hi all,
> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
> 
> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
> 
> ```c++
>     address const end = addr + len;
>     if (end <= (address)unscaled_max) {
>       _base = nullptr;
>       _shift = 0;

SendaoYan has updated the pull request incrementally with two additional commits since the last revision:

 - Use uintptr_t instead intptr_t
 - cast offset to intptr_t to avoid overflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22848/files
  - new: https://git.openjdk.org/jdk/pull/22848/files/6abd26e1..86f00f87

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22848&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22848&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22848/head:pull/22848

PR: https://git.openjdk.org/jdk/pull/22848

From aph at openjdk.org  Fri Dec 20 16:11:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 20 Dec 2024 16:11:38 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v6]
In-Reply-To: <9uGYNmVdvCXvyYSOAfwmvD70nWkimOFIlQJolQWa_Z4=.c6ffbfa0-5eb1-40a4-83a4-b657f57c9836@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <BmcBU2NE8-d1Zaz8mM6oPw5VY--4lPsn8aX9pL7hJ0Y=.e2d62858-a0da-4f69-845a-7cbd8897dd30@github.com>
 <9uGYNmVdvCXvyYSOAfwmvD70nWkimOFIlQJolQWa_Z4=.c6ffbfa0-5eb1-40a4-83a4-b657f57c9836@github.com>
Message-ID: <JOUCPakioJEQD8AVPnDAw51sFAk6qYADITVo-fEsZxk=.8d6dc3d6-0838-490a-b2e6-8a78cb1f6afb@github.com>

On Fri, 20 Dec 2024 15:42:14 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> Galder Zamarre?o has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Added comment around the assertions
>>  - Adjust min/max identity IR test expectations after changes
>>  - Fix style
>>  - Add max reduction test
>>  - Add empty line
>
> test/hotspot/jtreg/compiler/loopopts/superword/MinMaxRed_Long.java line 135:
> 
>> 133:     @IR(applyIf = {"SuperWordReductions", "true"},
>> 134:         applyIfCPUFeatureOr = { "avx512", "true" },
>> 135:         counts = {IRNode.MIN_REDUCTION_V, " > 0"})
> 
>> @eme64 I've addressed all your comments except aarch64 testing. `asimd` is not enough, you need `sve` for this, but I'm yet to make it work even with `sve`, something's up and need to debug it further.
> 
> Hi @galderz , may I ask if these long-reduction cases can't work even with `sve`? It might be related with the limitation [here](https://github.com/openjdk/jdk/blob/75420e9314c54adc5b45f9b274a87af54dd6b5a8/src/hotspot/share/opto/superword.cpp#L1564-L1566). Some `sve` machines have only 128 bits.

That's right. Neoverse V2 is 4 pipes of 128 bits, V1 is 2 pipes of 256 bits.
That comment is "interesting". Maybe it should be tunable by the back end. Given that Neoverse V2 can issue 4 SVE operations per clock cycle, it might still be a win.

Galder, how about you disable that line and give it another try?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20098#discussion_r1894118531

From mdoerr at openjdk.org  Fri Dec 20 16:16:36 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Dec 2024 16:16:36 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v3]
In-Reply-To: <XAyOj8fRdrN4dHxlYUc4CGyjdNxpjVf1Yu1J7Gxng4Q=.c2ca1d2f-edd0-4471-b868-4e3249ce23a4@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <XAyOj8fRdrN4dHxlYUc4CGyjdNxpjVf1Yu1J7Gxng4Q=.c2ca1d2f-edd0-4471-b868-4e3249ce23a4@github.com>
Message-ID: <79RQM5ECE0W6AqgbiRYX9LA0C8jb0dm8ZvkE5W-0vfU=.6d57be20-4b61-44f0-a89d-fa498f6be8a4@github.com>

On Fri, 20 Dec 2024 16:08:12 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
>> 
>> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
>> 
>> ```c++
>>     address const end = addr + len;
>>     if (end <= (address)unscaled_max) {
>>       _base = nullptr;
>>       _shift = 0;
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use uintptr_t instead intptr_t
>  - cast offset to intptr_t to avoid overflow

Thanks! LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22848#pullrequestreview-2517874718

From cjplummer at openjdk.org  Fri Dec 20 16:39:35 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 20 Dec 2024 16:39:35 GMT
Subject: RFR: 8346460: NotifyFramePop should return JVMTI_ERROR_DUPLICATE
 [v4]
In-Reply-To: <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
References: <GqS1NMo9I7Z0Yc0cxw7mDuOnSNf71w5YUlBfn9VgsIo=.c9b4ca80-9e2e-4f85-b411-9afa1ecf8b76@github.com>
 <6R3JI_qLLbxrWLelgmmlw6n1QjuvidxsMKzIPMKosEU=.b03e94e9-9faf-440f-9197-4c7c7c093bf7@github.com>
Message-ID: <wX0FP2JL4HvDQg7GKgI4wU1leiBlhBLR3yDmAfBM23o=.fee5ea6f-e19b-40f9-b79e-c175f6c2f9ca@github.com>

On Fri, 20 Dec 2024 01:23:22 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The JVMTI NotifyFramePop should return JVMTI_ERROR_DUPLICATE in a case the specified FramePop event was already requested. This makes it consistent with the SetBreakpoint which returns the JVMTI_ERROR_DUPLICATE on an attempt to add a breakpoint request that was already requested.
>> 
>> CSR: [8346460](https://bugs.openjdk.org/browse/JDK-8346460): NotifyFramePop should return JVMTI_ERROR_DUPLICATE
>> 
>> Testing:
>>  - tested with mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: improved one failure logging a little bit

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22798#pullrequestreview-2517927355

From mdoerr at openjdk.org  Fri Dec 20 17:25:40 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Dec 2024 17:25:40 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <Q0Gew_GeNQLcwFQAZ3eiisUOCBMaAv8mHLpQOvSHSsM=.142a184c-5b17-4eef-8c74-497cb26c4635@github.com>

On Thu, 18 Jul 2024 14:31:57 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

Thanks for implementing it! Reviewing the algorithm will take more time. I already have some comments and suggestions.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 634:

> 632:   }
> 633: 
> 634: // Generate stub for ghash process  blocks.

There are multiple double-whitespaces in the new comments. Please clean them up!

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 639:

> 637: //      state:  R3_ARG1
> 638: //      subkeyH:    R4_ARG2
> 639: //      data: R5_ARG3

Argument "blocks" missing.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 684:

> 682:   VectorRegister vS = VR25;
> 683:   VectorSRegister vXS = VSR33;
> 684:   Label L_end, L_aligned;

I suggest to declare `VectorRegisters` only and using `->to_vsr()` below. This should improve readability.

Non-volatile VectorRegisters need to be preserved. See https://github.com/openjdk/jdk/blob/bcb1bdaae772c752d54939dae3a0d95892acc228/src/hotspot/cpu/ppc/macroAssembler_ppc.cpp#L3866

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 686:

> 684:   Label L_end, L_aligned;
> 685: 
> 686:   static const unsigned char perm_pattern[16] __attribute__((aligned(16))) = {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15};

This pattern can be produced by `lvsl`. Loading it from memory is not needed.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 713:

> 711:   __ vxor(vTmp1, vTmp1, vTmp1);
> 712:   __ vxor(vZero, vZero, vZero);
> 713:   __ mtctr(blocks);

Can `blocks` be 0?
`blocks` is an int. The higher half of the register may possibly contain garbage and should be cleared. (Can be combined with 0 check if needed.)

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 759:

> 757:     __ bdnz(loop);
> 758:   __ stxvd2x(vZero->to_vsr(), state);
> 759:   __ blr();                                     // Return from function

Some empty lines would improve readability.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20235#pullrequestreview-2517971876
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1894178520
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1894193680
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1894184131
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1894189657
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1894194165
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1894197698

From rehn at openjdk.org  Fri Dec 20 17:29:38 2024
From: rehn at openjdk.org (Robbin Ehn)
Date: Fri, 20 Dec 2024 17:29:38 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v3]
In-Reply-To: <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
Message-ID: <S0auXOf6vpK9VLQovEmc9ylIkqZnh01wMhsKxrk9XwI=.5e8556b4-486a-428a-b1cd-0bad0abaf357@github.com>

On Thu, 19 Dec 2024 15:50:22 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  211 would add 211 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] : tier1-3 and gtest:all (release)
>> - [x] : hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unnecessary changes

Yea, I think what you are suggesting seems good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22804#issuecomment-2557428201

From duke at openjdk.org  Fri Dec 20 17:48:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
 <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
Message-ID: <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>

On Fri, 20 Dec 2024 15:24:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Yes, I agree, bootstrap_done reads better.
>
> There's a few other is_bootstrapping() predicates in the code like Universe::is_bootstrapping.  This might read nicely as is_bootstrapping_done() and the instance is _bootstrapping_done.

Ok I've updated everything to use "bootstrapping_done" instead of "done_bootstrap"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894219662

From duke at openjdk.org  Fri Dec 20 17:48:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v7]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <BohJMWicbq-8h98uuaSRT1LnmiDU6hIlKapJOWxSXmU=.1476c43b-3a3c-46b2-ac86-e3e585a7ec13@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  apply style feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/f519c3b8..5af32fc1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=05-06

  Stats: 28 lines in 5 files changed: 10 ins; 1 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From duke at openjdk.org  Fri Dec 20 17:48:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
Message-ID: <UX5tVwjnKyjiQ6Xpokj0txKqR5cIENiFWh7c6msX_nc=.6e2cc942-03ec-4749-b595-0baf2d489a18@github.com>

On Thu, 19 Dec 2024 22:52:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 341:
> 
>> 339:   assert(_reserved_regions != nullptr, "Sanity check");
>> 340:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
>> 341: 
> 
> This line is kind of long.  And why the space before the comma?  And there's a bunch of
> these, suggesting there should be a helper to package this up.

Good point. I've gotten rid of this in favor of the helper that Coleen suggested below.

> src/hotspot/share/utilities/vmError.cpp line 652:
> 
>> 650: 
>> 651:   BEGIN
>> 652:   if (MemTracker::enabled() && NmtVirtualMemory_lock != nullptr  && MemTracker::is_done_bootstrap() && NmtVirtualMemory_lock->owned_by_self()) {
> 
> This line is rather long.

Ok I've broken it up now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894218609
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894218393

From duke at openjdk.org  Fri Dec 20 17:48:14 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:48:14 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
Message-ID: <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>

On Fri, 20 Dec 2024 15:33:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 421:
> 
>> 419:   assert(_reserved_regions != nullptr, "Sanity check");
>> 420:   assert(!MemTracker::is_done_bootstrap() || NmtVirtualMemory_lock->owned_by_self() , "Should have acquired NmtVirtualMemory_lock");
>> 421: 
> 
> You could add this to MemTracker class like:
>  ```
>  inline static void assert_locked();
> 
> 
> Then put the body  
> 
> void MemTracker::assert_locked() {
>   assert(!is_bootstrapping_done() || NmtVirtualMemory_lock->owned_by_self(),
>             "should have acquired NmtVirtualMemory_lock");
> }
> 
> Then all these calls could be MemTracker::assert_locked().

Good idea. I've adopted your suggestion. Thank you!

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 631:
> 
>> 629: 
>> 630:   bool do_allocation_site(const ReservedMemoryRegion* rgn) {
>> 631:     assert_lock_strong(NmtVirtualMemory_lock);
> 
> So this is past bootstrapping?

I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894218073
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894217960

From duke at openjdk.org  Fri Dec 20 17:53:16 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:53:16 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v8]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  convert forgotten assert

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/5af32fc1..547f07b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From duke at openjdk.org  Fri Dec 20 17:53:16 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 17:53:16 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
Message-ID: <dKT85q2GvWZL1KP2q0yBSimdRNyaGGZRXaqa2fF45g8=.e72c45ce-2e9a-42f6-b1c8-8b8693d8d649@github.com>

On Thu, 19 Dec 2024 22:43:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/share/nmt/memTracker.hpp line 285:
> 
>> 283:       ConditionalMutexLocker _cml;
>> 284:   public:
>> 285:       NmtVirtualMemoryLocker(): _cml(NmtVirtualMemory_lock, _done_bootstrap, Mutex::_no_safepoint_check_flag){}
> 
> Indented 4, but HotSpot style is indent 2.

Updated. Thank you!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894224351

From coleenp at openjdk.org  Fri Dec 20 18:12:40 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 18:12:40 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v8]
In-Reply-To: <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
Message-ID: <UMZirYuTPT7H66gOOVkePvR0ROWbGVrp23LwYaZXvHQ=.9c0e3528-1b0e-4d49-bbd6-9e3aa40010fa@github.com>

On Fri, 20 Dec 2024 17:53:16 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert forgotten assert

This looks good! Thank you for making these changes.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2518083639

From stuefe at openjdk.org  Fri Dec 20 18:26:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 20 Dec 2024 18:26:49 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
Message-ID: <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>

On Thu, 19 Dec 2024 21:04:51 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock

@roberttoyonaga thank you for taking this on again.

Could you please add a comment somewhere that describes the locking problem we try to solve in all its ugliness? I keep forgetting the details myself.

Something along these lines:

We need locking in NMT for mmap-based allocated (malloc is lockless). Because mmap-based allocations use global data structures. But we also need those lock sections to include the OS-side mmap/munmap calls that caused modifications of said sections. So, `mmap` calls must happen together with their associated `MemTracker::record_reserve`, same for `munmap` and `MemTracker::record_release`. Without locking, NMT may see states that are invalid. For example this order: `T1 calls munmap; T2 calls mmap (same region); T2 calls MemTracker::record_reserve; T1  calls MemTracker::record_release;` would result in NMT seeing a `MemTracker::record_reserve` for a region that, in its opinion, is still occupied.

So we lock, and we want to use Mutex. This has two problems: a) does not work before mutexes have been initialized. b) does not work if Thread::current is NULL. 

(a) is a problem for early mmaps. (Example: polling page setup ?)
(b) is a problem if a thread tries to use mmap but has not yet set Thread::current. This was stack region registration with NMT (because we misuse NMT mmap management for registering stack threads).

src/hotspot/os/windows/os_windows.cpp line 3626:

> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
> 3625:       assert(false, "bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
> 3626: #endif

@roberttoyonaga Thinking about this, I propose to just remove the os::print_memory_mappings call here. I added this way back when we had problems on Windows with removing "striped" NUMA mappings, but those issues have long been solved. We still have the assertion check, so we will notice if something goes wrong.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2513685220
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894197615

From stuefe at openjdk.org  Fri Dec 20 18:26:49 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 20 Dec 2024 18:26:49 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v3]
In-Reply-To: <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <zeWANBYo0WeAioKEWf6Vh2Op2yZ3LGa5QWrS1kxRHm0=.501104fd-e96c-4476-b9c0-b91578f71631@github.com>
 <ZDLTTLd4Akto7BkhCyRmevYVS3khzET3ErcdRHD3W_k=.d4be2cb4-0728-4f04-b57b-123b9e471b36@github.com>
 <ohCTWsMuzVdMIGVTJ7AcxL2KQs5mznt_viQF0-vHsCg=.ad2331b1-1e44-4923-83d6-c7814ee802e7@github.com>
 <LTU3M2GAIP1tQIbZTXI2UhgTN6tYhBpNZrGextu9zFg=.f894c9d3-9fd4-40b2-beec-496222f8e1b9@github.com>
Message-ID: <s-TbfNJNzCjjHc9lSaKOtYeSOBYCx4_-2vjuNMNJxp8=.c79165a7-6f68-4f0a-a6c2-870f1c3fd56d@github.com>

On Thu, 19 Dec 2024 02:19:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Okay ... still not sure this shouldn't be dynamically determining whether stdout or stderr is the right target.

We should really have a not-blocking variant of `tty` since er use tty for things like debug output when being deep down the stack. In most cases, printing to a small stringStream and then printing the stream content in one go is what I do to get uninterrupted printing. Works well.

@roberttoyonaga pragmatic proposal would be to just remove this debug output, so the whole ASSERT section. I think I added this way back when we had problems investigating Windows reservations writing over each other, but that problem has been fixed and this assert has not been firing for ages.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1891348435

From stuefe at openjdk.org  Fri Dec 20 18:26:50 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 20 Dec 2024 18:26:50 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
 <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
 <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>
Message-ID: <Qpo6rphF_kSQIGkZVoqy59lUs295x9eZO3Rd5e4wYL8=.e4d563ca-6a76-49df-b5e9-f7f3a8226d71@github.com>

On Fri, 20 Dec 2024 17:45:21 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> There's a few other is_bootstrapping() predicates in the code like Universe::is_bootstrapping.  This might read nicely as is_bootstrapping_done() and the instance is _bootstrapping_done.
>
> Ok I've updated everything to use "bootstrapping_done" instead of "done_bootstrap"

Arguably, MemTracker is the wrong place anyway since the problem it tries to solve is not tied to NMT initialization.

The thought behind the "bootstrap_done" was to make visible that it is safe to not lock since we still run effectively single-threaded. Hotspot loading and CreateJavaVM may happen on different threads, but not at the same time.

We can delay real locking until other threads are starting up. That is somewhere in the middle of VM initialization, but long after NMT has booted. But we can do it also as soon as Mutex initialization is done. 

So we could either move this to the mutex layer and give us a "MutexLocker::all_initialised". In that case, the implicit assumption is that as long as the JVM initializes this before other threads are started. Or, we could move it to the thread subsystem and give us a marker for when we are not single-threaded anymore. I like the former better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894256355

From coleenp at openjdk.org  Fri Dec 20 18:58:47 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 18:58:47 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v8]
In-Reply-To: <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <Vedg_GQHRORNzKBRTBGEt6ArvFymcAcaJXJnA2I4of8=.c237ed23-2351-44c0-8997-30ead67d9857@github.com>
Message-ID: <cusGIsMpx_-AQZ2R315Nx2lN3ffHsp68gPedojTdSLo=.63afd895-3ed4-4c29-8002-b471e8d547af@github.com>

On Fri, 20 Dec 2024 17:53:16 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   convert forgotten assert

I was wondering if there was another initialization predicate that could be used instead for this, but it's sort of unclear which to use since there are several, and they're all protecting different actions.  So I thought this was fine for this.

If there was a second need for detecting when it was safe to use MutexLocker, then it seems that moving the initialization flag there would be sensible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2557550021

From coleenp at openjdk.org  Fri Dec 20 19:28:36 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 20 Dec 2024 19:28:36 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v3]
In-Reply-To: <XAyOj8fRdrN4dHxlYUc4CGyjdNxpjVf1Yu1J7Gxng4Q=.c2ca1d2f-edd0-4471-b868-4e3249ce23a4@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <XAyOj8fRdrN4dHxlYUc4CGyjdNxpjVf1Yu1J7Gxng4Q=.c2ca1d2f-edd0-4471-b868-4e3249ce23a4@github.com>
Message-ID: <TDR70iwFBPO3xDOFME7AQm7t0JplKLLrmY8A5mPE6Rk=.1dc0b311-fb6b-4f76-a456-22559d9e1dde@github.com>

On Fri, 20 Dec 2024 16:08:12 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
>> 
>> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
>> 
>> ```c++
>>     address const end = addr + len;
>>     if (end <= (address)unscaled_max) {
>>       _base = nullptr;
>>       _shift = 0;
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use uintptr_t instead intptr_t
>  - cast offset to intptr_t to avoid overflow

This looks better than the conditional on _addr. Thanks for fixing these errors.

-------------

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22848#pullrequestreview-2518204831

From duke at openjdk.org  Fri Dec 20 20:19:50 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:19:50 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v9]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <eTRGPqCdDcBZtltj18f52hGvmYnQqnsiU8Fv7O5g_Lk=.5d24c867-7224-4611-87eb-6a98e4096fa2@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  remove os::print_memory_mappings. Add comments explaining NMT locking

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/547f07b7..9e016b8c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=07-08

  Stats: 17 lines in 2 files changed: 13 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From duke at openjdk.org  Fri Dec 20 20:24:39 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:24:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
Message-ID: <OSlZWlrt5f0aOJGIKLdgOC9qQGA9qmBYISmXmBQx41s=.99acdee3-216b-4956-a3a0-6f48b5efcb0e@github.com>

On Fri, 20 Dec 2024 17:22:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> src/hotspot/os/windows/os_windows.cpp line 3626:
> 
>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
>> 3625:       assert(false, "bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
>> 3626: #endif
> 
> @roberttoyonaga Thinking about this, I propose to just remove the os::print_memory_mappings call here. I added this way back when we had problems on Windows with removing "striped" NUMA mappings, but those issues have long been solved. We still have the assertion check, so we will notice if something goes wrong.

Ok I've removed it now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894359621

From duke at openjdk.org  Fri Dec 20 20:57:53 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:57:53 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v10]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <WDoPWuQkgHt41WpbFh69HmFnq1S4uhAhM6WRpMcGQnM=.68e8c540-bc32-478f-ac72-6e102fe1059d@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  move _bootstrapping_done into MutexLocker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/9e016b8c..223928de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=08-09

  Stats: 29 lines in 7 files changed: 12 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From duke at openjdk.org  Fri Dec 20 20:57:54 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 20:57:54 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
Message-ID: <mvyTzLqOf2L-pcRnqjs4QbBYG4g6qxh_S0wUvl0hgWw=.70c7dc0a-57fd-4fd8-909e-058fe522298b@github.com>

On Fri, 20 Dec 2024 18:23:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert to using NmtVirtualMemoryLocker. Use defaultStream. Add comment for SharedDecoder_lock
>
> @roberttoyonaga thank you for taking this on again.
> 
> Could you please add a comment somewhere that describes the locking problem we try to solve in all its ugliness? I keep forgetting the details myself.
> 
> Something along these lines:
> 
> We need locking in NMT for mmap-based allocated (malloc is lockless). Because mmap-based allocations use global data structures. But we also need those lock sections to include the OS-side mmap/munmap calls that caused modifications of said sections. So, `mmap` calls must happen together with their associated `MemTracker::record_reserve`, same for `munmap` and `MemTracker::record_release`. Without locking, NMT may see states that are invalid. For example this order: `T1 calls munmap; T2 calls mmap (same region); T2 calls MemTracker::record_reserve; T1  calls MemTracker::record_release;` would result in NMT seeing a `MemTracker::record_reserve` for a region that, in its opinion, is still occupied.
> 
> So we lock, and we want to use Mutex. This has two problems: a) does not work before mutexes have been initialized. b) does not work if Thread::current is NULL. 
> 
> (a) is a problem for early mmaps. (Example: polling page setup ?)
> (b) is a problem if a thread tries to use mmap but has not yet set Thread::current. This was stack region registration with NMT (because we misuse NMT mmap management for registering stack threads).

Thank you @tstuefe  for the feedback! I've added a comment explaining why the locking is necessary and the considerations surrounding it.  Please let me know if I should change the wording or if you think I missed any details. 

As for other initialization predicates that could be reused instead of  `_bootstrapping_done`,   maybe `is_init_completed()`  could also accomplish the same task. However, it uses atomics and gets set much later in VM initialization, whereas `_bootstrapping_done` can be set immediately after current thread is attached.  

So I think it makes the most sense to either keep `_bootstrapping_done` inside `MemTracker` or move it into `MutexLocker`. For now, I've adopted your suggestion to moved it into `MutexLocker` so that it can be used more generally in places other than NMT in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2557704119

From duke at openjdk.org  Fri Dec 20 21:29:18 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Fri, 20 Dec 2024 21:29:18 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  move boostrapping_done flag into Mutex from MutexLocker

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/223928de..1909279c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=09-10

  Stats: 26 lines in 7 files changed: 10 ins; 10 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From dlong at openjdk.org  Fri Dec 20 21:37:38 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 20 Dec 2024 21:37:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
Message-ID: <IniXsCjoGi3TxdIGl2LPkyhWAc6xSSPJgvqrFp7GQu0=.f32a6d18-7c9b-4e04-9502-dbfb2bee13b2@github.com>

On Fri, 20 Dec 2024 13:17:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore ACC in comment.

src/hotspot/share/oops/method.cpp line 1655:

> 1653:     return;
> 1654:   }
> 1655:   jshort flags = checked_cast<jshort>(access_flags().as_unsigned_short());

Can we cleanup the intrinsics code next, to stop using jshort for flags?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1894406531

From syan at openjdk.org  Sat Dec 21 02:30:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 21 Dec 2024 02:30:36 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v3]
In-Reply-To: <XAyOj8fRdrN4dHxlYUc4CGyjdNxpjVf1Yu1J7Gxng4Q=.c2ca1d2f-edd0-4471-b868-4e3249ce23a4@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <XAyOj8fRdrN4dHxlYUc4CGyjdNxpjVf1Yu1J7Gxng4Q=.c2ca1d2f-edd0-4471-b868-4e3249ce23a4@github.com>
Message-ID: <mq1kga6D8xNBrgYjkcNLbE5sV1H1ap15wtS-DUfnXnQ=.47f82ebb-f049-4aa0-992e-d5fa0a5f944b@github.com>

On Fri, 20 Dec 2024 16:08:12 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
>> 
>> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
>> 
>> ```c++
>>     address const end = addr + len;
>>     if (end <= (address)unscaled_max) {
>>       _base = nullptr;
>>       _shift = 0;
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use uintptr_t instead intptr_t
>  - cast offset to intptr_t to avoid overflow

GHA report 1 failure:

1. ` linux-x64 / test - Test (tier1)` job report test `gc/shenandoah/TestSmallHeap.java#generational` timed out, the shenandoah-generational interminnet timed out failure has been recorded by [JDK-8345958](https://bugs.openjdk.org/browse/JDK-8345958), it's unrelated to this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2557959921

From fyang at openjdk.org  Sat Dec 21 04:10:22 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 21 Dec 2024 04:10:22 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v4]
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <t02yd1iGRzLpvh484txjfb_2eLDOPv1Q6aSJ1UbNmQM=.9fcb73ad-1bb4-494b-bb8a-f3baf0117589@github.com>

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
> 
> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> 
> 
>  <Design of the RISC-V Instruction Set Architecture>:
> 
>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>  211 would add 211 to a register, which ADDI is incapable of.
> 
> 
> Testing on Premier-P550 SBC running Ubuntu-24.04:
> - [x] : tier1-3 and gtest:all (release)
> - [x] : hotspot:tier1 (fastdebug)

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Improve naming for rotate routines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22804/files
  - new: https://git.openjdk.org/jdk/pull/22804/files/4f8a6662..b27fc623

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=02-03

  Stats: 33 lines in 5 files changed: 0 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

PR: https://git.openjdk.org/jdk/pull/22804

From fyang at openjdk.org  Sat Dec 21 04:20:36 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 21 Dec 2024 04:20:36 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v3]
In-Reply-To: <S0auXOf6vpK9VLQovEmc9ylIkqZnh01wMhsKxrk9XwI=.5e8556b4-486a-428a-b1cd-0bad0abaf357@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <t5bQ3H9x_TiRpwHB2jRr7QJ06cHB6NDRSV7D_W2yr1I=.b0fe7be0-b4d4-4684-9d28-1075512beb23@github.com>
 <S0auXOf6vpK9VLQovEmc9ylIkqZnh01wMhsKxrk9XwI=.5e8556b4-486a-428a-b1cd-0bad0abaf357@github.com>
Message-ID: <eMt30c3k6I_NUntbTLCX8evGqdqFstrlnXSnDrDNKwk=.e0ec0f46-9d70-4635-83e9-05e7649f7e7a@github.com>

On Fri, 20 Dec 2024 17:26:57 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> Yea, I think what you are suggesting seems good.

Thanks. I added one commit only handling naming of the rotate routines. I would keep this kind of change minimum unless we have similar issues like this. Also names like `addr` doesn't seem nice to me as it could be mis-interpreted as an address.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22804#issuecomment-2557988750

From fyang at openjdk.org  Sat Dec 21 06:24:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 21 Dec 2024 06:24:04 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v5]
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <IMQeCdVRT2aZIIXjVej-BZ7A2vKCz5fktMAw9--xH9g=.56a4a142-c946-4627-b22d-9f7969a6eaaa@github.com>

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
> 
> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> 
> 
>  <Design of the RISC-V Instruction Set Architecture>:
> 
>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>  211 would add 211 to a register, which ADDI is incapable of.
> 
> 
> Testing on Premier-P550 SBC running Ubuntu-24.04:
> - [x] : tier1-3 and gtest:all (release)
> - [x] : hotspot:tier1 (fastdebug)

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Revert unnecessary change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22804/files
  - new: https://git.openjdk.org/jdk/pull/22804/files/b27fc623..55eaaac6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

PR: https://git.openjdk.org/jdk/pull/22804

From stuefe at openjdk.org  Sat Dec 21 10:59:34 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 21 Dec 2024 10:59:34 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
Message-ID: <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>

On Fri, 20 Dec 2024 15:41:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for fixing the issue! This should work. In general, I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.

+1. Also, instead of casting manually, please use p2u (and if there is none, we should add it like we have a p2i for intptr_t).

I am somewhat unenthusiastic about changes like these. We seem to add a lot of casting boilerplate to satisfy UBsan for the sake of cleanliness that only matters on special hardware that treats pointers differently from numeric. Like old-style IBM AS/400s. But if we ever build for that kind of hardware, nothing will work anyway. I am happy to be corrected, though, but I think all our compilers treat NULL as numeric 0, right?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2558083084

From gcao at openjdk.org  Sat Dec 21 11:55:36 2024
From: gcao at openjdk.org (Gui Cao)
Date: Sat, 21 Dec 2024 11:55:36 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v5]
In-Reply-To: <IMQeCdVRT2aZIIXjVej-BZ7A2vKCz5fktMAw9--xH9g=.56a4a142-c946-4627-b22d-9f7969a6eaaa@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <IMQeCdVRT2aZIIXjVej-BZ7A2vKCz5fktMAw9--xH9g=.56a4a142-c946-4627-b22d-9f7969a6eaaa@github.com>
Message-ID: <0WJWUhlBy8EtK-geEmgPOUUapaCVudy7SIJwsL8IaOA=.6b823152-8a75-40b0-bf32-042354860d7c@github.com>

On Sat, 21 Dec 2024 06:24:04 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  211 would add 211 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] : tier1-3 and gtest:all (release)
>> - [x] : hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unnecessary change

Looks good to me.

-------------

Marked as reviewed by gcao (Author).

PR Review: https://git.openjdk.org/jdk/pull/22804#pullrequestreview-2518637669

From aph at openjdk.org  Sun Dec 22 17:50:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sun, 22 Dec 2024 17:50:40 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
 <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
Message-ID: <BEqn7gaZ8OnzfCfcupUxVXaXpF5FzN92veve_oSVwwc=.7ce7b6aa-f8af-4928-99c7-43b67fe58b6d@github.com>

On Sat, 21 Dec 2024 10:57:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > Thanks for fixing the issue! This should work. In general, I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.
> 
> +1. Also, instead of casting manually, please use p2u (and if there is none, we should add it like we have a p2i for intptr_t).
> 
> I am somewhat unenthusiastic about changes like these. We seem to add a lot of casting boilerplate to satisfy UBsan for the sake of cleanliness that only matters on special hardware that treats pointers differently from numeric.

True, but we can very effectively make the compiler and the reader happy by using `uintptr_t` for all of the arithmetic. After all, we are not using null-based compressed pointers, we are using zero-based compressed pointers, and the distinction is important. `uintptr_t` does not have null as a member, it has zero; conversely `address` does not have zero, it has null. Therefore, when we are using zero-based compressed pointers, better to to use `uintptr_t` for the arithmetic.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2558534965

From syan at openjdk.org  Sat Dec 21 15:56:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 21 Dec 2024 15:56:15 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
 <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
Message-ID: <Ie7mTACrN97p2V0dzHwPH5jUoZrCturDeKa-d2P0_-E=.ef75821f-f60f-438a-bfbd-41a444993195@github.com>

On Sat, 21 Dec 2024 10:57:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> instead of casting manually, please use p2u (and if there is none, we should add it like we have a p2i for intptr_t).

Casting manually has been replace as use p2u.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2558157765

From fyang at openjdk.org  Mon Dec 23 03:24:08 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 23 Dec 2024 03:24:08 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v6]
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <O4t3DYyEeMOgQ2HAR2M-UPI0IIbgMKLINEdExVgyFUc=.057053f2-0107-4ddd-a433-c3e7dad923af@github.com>

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
> 
> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> 
> 
>  <Design of the RISC-V Instruction Set Architecture>:
> 
>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>  -2048 would add 2048 to a register, which ADDI is incapable of.
> 
> 
> Testing on Premier-P550 SBC running Ubuntu-24.04:
> - [x] : tier1-3 and gtest:all (release)
> - [x] : hotspot:tier1 (fastdebug)

Fei Yang has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22804/files
  - new: https://git.openjdk.org/jdk/pull/22804/files/55eaaac6..ba5f37cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=04-05

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

PR: https://git.openjdk.org/jdk/pull/22804

From qxing at openjdk.org  Sun Dec 22 20:55:41 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Sun, 22 Dec 2024 20:55:41 GMT
Subject: Integrated: 8346602: Remove unused macro parameters in `jni.cpp`
In-Reply-To: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
References: <bRzBq87TcHiwFxk4nA1yeD_3oT6urbg-C6oPNW8bvYI=.412feedd-6e0a-4819-857e-e75e7e426d45@github.com>
Message-ID: <jvAjOVxnzx6awHD_s_2tbFSVzdgO5FgTPTLxdZliquo=.001f4f24-24a4-4ed4-a87d-4b166fe4e752@github.com>

On Thu, 19 Dec 2024 08:16:54 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> Some of the macros in `jni.cpp`, including `DEFINE_GETSCALARARRAYELEMENTS`, `DEFINE_RELEASESCALARARRAYELEMENTS`, `DEFINE_GETSCALARARRAYREGION` and `DEFINE_SETSCALARARRAYREGION`, have unused parameters.
> 
> This patch removes them.

This pull request has now been integrated.

Changeset: c1b868d2
Author:    Qizheng Xing <qxing at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1b868d27d955b5e219caf8f76e87e5edf4c92df
Stats:     39 lines in 1 file changed: 0 ins; 0 del; 39 mod

8346602: Remove unused macro parameters in `jni.cpp`

Reviewed-by: dholmes, mli

-------------

PR: https://git.openjdk.org/jdk/pull/22824

From fjiang at openjdk.org  Sun Dec 22 12:39:43 2024
From: fjiang at openjdk.org (Feilong Jiang)
Date: Sun, 22 Dec 2024 12:39:43 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v5]
In-Reply-To: <IMQeCdVRT2aZIIXjVej-BZ7A2vKCz5fktMAw9--xH9g=.56a4a142-c946-4627-b22d-9f7969a6eaaa@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <IMQeCdVRT2aZIIXjVej-BZ7A2vKCz5fktMAw9--xH9g=.56a4a142-c946-4627-b22d-9f7969a6eaaa@github.com>
Message-ID: <btRJGN6_wAxCiVXcKOoh2E5AKweeytlMIrsNAlXdNAI=.8416f6e7-dd88-4232-b070-1bf838185355@github.com>

On Sat, 21 Dec 2024 06:24:04 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  211 would add 211 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] : tier1-3 and gtest:all (release)
>> - [x] : hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unnecessary change

Looks good! I have some minor comments.

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 1755:

> 1753: 
> 1754:       int to_add = in_bytes(TypeStackSlotEntries::per_arg_size());
> 1755:       add(off_to_args, off_to_args, to_add);

Do we need to use `add` here? I think `addi` is okay.

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 1852:

> 1850:     add(mdp, mdp, tmp1);
> 1851:     ld(tmp1, Address(mdp, ArrayData::array_len_offset()));
> 1852:     sub(tmp1, tmp1, TypeStackSlotEntries::per_arg_count());

`per_arg_count()` returns `2`, maybe we could use `subi`

src/hotspot/cpu/riscv/interp_masm_riscv.cpp line 1878:

> 1876: 
> 1877:     // go to next parameter
> 1878:     sub(tmp1, tmp1, TypeStackSlotEntries::per_arg_count());

We can use `subi` too.

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 200:

> 198:     // if a breakpoint is present we can't rewrite the stream directly
> 199:     __ load_unsigned_byte(temp_reg, at_bcp(0));
> 200:     __ sub(temp_reg, temp_reg, Bytecodes::_breakpoint); // temp_reg is temporary register.

Should we use `subi` here?

src/hotspot/cpu/riscv/templateTable_riscv.cpp line 212:

> 210:   __ load_unsigned_byte(temp_reg, at_bcp(0));
> 211:   __ beq(temp_reg, bc_reg, L_okay);
> 212:   __ sub(temp_reg, temp_reg, (int)Bytecodes::java_code(bc));

ditto

-------------

PR Review: https://git.openjdk.org/jdk/pull/22804#pullrequestreview-2519615588
PR Review Comment: https://git.openjdk.org/jdk/pull/22804#discussion_r1894911494
PR Review Comment: https://git.openjdk.org/jdk/pull/22804#discussion_r1894912306
PR Review Comment: https://git.openjdk.org/jdk/pull/22804#discussion_r1894912476
PR Review Comment: https://git.openjdk.org/jdk/pull/22804#discussion_r1894915970
PR Review Comment: https://git.openjdk.org/jdk/pull/22804#discussion_r1894916145

From amitkumar at openjdk.org  Mon Dec 23 05:41:36 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 23 Dec 2024 05:41:36 GMT
Subject: RFR: JDK-8216437 : PPC64: Add intrinsic for GHASH algorithm
In-Reply-To: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
References: <2cIptfLHrdxSy0t7RdsRlde94arK3gmqge9AiXmOZeo=.069a496c-e9dd-40cd-a144-306a65df0e1a@github.com>
Message-ID: <SRm_flqQF3g9t2MvIXhKfBeNsZjxaCIcRkfsK3Vo-00=.e306b85a-20c2-4a03-a511-128f1ebf6133@github.com>

On Thu, 18 Jul 2024 14:31:57 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8216437](https://bugs.openjdk.org/browse/JDK-8216437)
> 
> Currently acceleration code for GHASH is missing for PPC64. 
> 
> The current implementation utlilises SIMD instructions on Power and uses Karatsuba multiplication for obtaining the final result.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 692:

> 690:   // Load the vector from memory into vConstC2
> 691:   __ vxor(vConstC2, vConstC2, vConstC2);
> 692:   __ mtvrd(vConstC2, temp1);

is that `vxor` instruction really necessary? `mtvrd` will do overwrite any way. So why do we want to be sure that there is 0 in `vConstC2` ?

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 711:

> 709:   __ vsldoi(vLowerH, vZero, vSwappedH, 8);      // H.L
> 710:   __ vsldoi(vHigherH, vSwappedH, vZero, 8);     // H.H
> 711:   __ vxor(vTmp1, vTmp1, vTmp1);

I see this `vTmp1` is being used in the loop and `vpmsumd` (line 741) should overwrite whatever it is containing. So was this xor necessary ?

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 712:

> 710:   __ vsldoi(vHigherH, vSwappedH, vZero, 8);     // H.H
> 711:   __ vxor(vTmp1, vTmp1, vTmp1);
> 712:   __ vxor(vZero, vZero, vZero);

we are doing same xor operation on `vZero` at 721 in the loop, before that It is not being used. So can we get rid of this xor-instruction as well ?

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 714:

> 712:   __ vxor(vZero, vZero, vZero);
> 713:   __ mtctr(blocks);
> 714:   __ li(temp1, 0);

I find this load redundant as well. We are loading 0 again at line 722 in the loop.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1895264074
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1895268663
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1895271706
PR Review Comment: https://git.openjdk.org/jdk/pull/20235#discussion_r1895270802

From kbarrett at openjdk.org  Sat Dec 21 17:07:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 21 Dec 2024 17:07:42 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
Message-ID: <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>

On Fri, 20 Dec 2024 21:29:18 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move boostrapping_done flag into Mutex from MutexLocker

Changes requested by kbarrett (Reviewer).

src/hotspot/share/nmt/threadStackTracker.cpp line 55:

> 53:   align_thread_stack_boundaries_inward(base, size);
> 54: 
> 55:   MemTracker::MemTracker::NmtVirtualMemoryLocker nvml;

Too many "MemTracker"s here?

src/hotspot/share/nmt/virtualMemoryTracker.cpp line 632:

> 630:     if (Mutex::is_bootstrapping_done()) {
> 631:       assert_lock_strong(NmtVirtualMemory_lock);
> 632:     }

It seems like this can use `MemTracker::assert_locked()`, since that is conditioned on bootstrapping state.

src/hotspot/share/runtime/mutex.hpp line 222:

> 220:   }
> 221:  private:
> 222:   static bool _bootstrapping_done;

A description of what these mean would be nice. It seems to be mutex_init completed + threading
initialization completed?

src/hotspot/share/runtime/mutexLocker.cpp line 291:

> 289:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
> 290:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
> 291:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4); // Must be lower than G1Mapper_lock used from G1RegionsSmallerThanCommitSizeMapper::commit_regions

Is it really okay for nmt to use a VM mutex? That means relevant functions can
only be called from a VM thread. In particular, what happens if we get into
the error handler because of a signal on a non-VM thread, or something
similarly weird.

This is also replacing the PlatformMutex that was being used by
MemoryFileTracker. I don't know why that was using a PlatformMutex, but I
presume there was a reason. It was doing so in the initial version of
JDK-8312132. Looking back through the development commits, is see these two in
sequence:

3472573 Introduce a separate Mutex for MemoryFileTracker
46f10f6 Use own PlatformMutex instead

I found no discussion about that choice in the PR. Maybe it was because of
problems determining the needed lock rank? (The original VM mutex had
Mutex::service rank. That's apparently too high, as discussed in this change.)
Or maybe there was some other reason?

I'll ask @jdksjolen about this, though holidays...

-------------

PR Review: https://git.openjdk.org/jdk/pull/22745#pullrequestreview-2518602318
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894576359
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894576955
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894652359
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894657610

From fyang at openjdk.org  Mon Dec 23 03:24:08 2024
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 23 Dec 2024 03:24:08 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v5]
In-Reply-To: <btRJGN6_wAxCiVXcKOoh2E5AKweeytlMIrsNAlXdNAI=.8416f6e7-dd88-4232-b070-1bf838185355@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <IMQeCdVRT2aZIIXjVej-BZ7A2vKCz5fktMAw9--xH9g=.56a4a142-c946-4627-b22d-9f7969a6eaaa@github.com>
 <btRJGN6_wAxCiVXcKOoh2E5AKweeytlMIrsNAlXdNAI=.8416f6e7-dd88-4232-b070-1bf838185355@github.com>
Message-ID: <5sSfXh1HwJf-becNA1QNpP5YAd3ZJ5O2EQHnVqgbZiE=.dc41de9c-6b63-4e49-9120-4ce4775ee2c6@github.com>

On Sun, 22 Dec 2024 12:34:24 GMT, Feilong Jiang <fjiang at openjdk.org> wrote:

>> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unnecessary change
>
> src/hotspot/cpu/riscv/templateTable_riscv.cpp line 212:
> 
>> 210:   __ load_unsigned_byte(temp_reg, at_bcp(0));
>> 211:   __ beq(temp_reg, bc_reg, L_okay);
>> 212:   __ sub(temp_reg, temp_reg, (int)Bytecodes::java_code(bc));
> 
> ditto

Make sense. I have fixes all of them. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22804#discussion_r1895196662

From syan at openjdk.org  Sat Dec 21 15:56:15 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 21 Dec 2024 15:56:15 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v4]
In-Reply-To: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
Message-ID: <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>

> Hi all,
> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
> 
> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
> 
> ```c++
>     address const end = addr + len;
>     if (end <= (address)unscaled_max) {
>       _base = nullptr;
>       _shift = 0;

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  add function p2u and use function p2u instead of cast manually

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22848/files
  - new: https://git.openjdk.org/jdk/pull/22848/files/86f00f87..f9b9bb3e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22848&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22848&range=02-03

  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22848.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22848/head:pull/22848

PR: https://git.openjdk.org/jdk/pull/22848

From dholmes at openjdk.org  Sun Dec 22 20:46:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sun, 22 Dec 2024 20:46:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <Qpo6rphF_kSQIGkZVoqy59lUs295x9eZO3Rd5e4wYL8=.e4d563ca-6a76-49df-b5e9-f7f3a8226d71@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <vL0ZvbaDo_vh1ck7FtiqESR0e4DM5C8EXWMP3_nzZPU=.6bec87be-26f3-4a4a-9fd1-14d56203e56b@github.com>
 <YFZzaRN4mopIowOkhCJYz6HiykjJEZP3aZT4jJ2ignY=.9fefbfc7-1950-45fd-9423-59b2bfb2c511@github.com>
 <YBGbvyOtAhKST24BCjXOQKorJJV1xOET8dkkStDME88=.1296b01e-0652-4a5c-82af-62627ce72995@github.com>
 <MfQbKpZpke15CqRINKtGXPNYFgWtqYQ6CC1MgEJKbnc=.ac39db8c-0308-480d-a6b2-f5565560e1ec@github.com>
 <Qpo6rphF_kSQIGkZVoqy59lUs295x9eZO3Rd5e4wYL8=.e4d563ca-6a76-49df-b5e9-f7f3a8226d71@github.com>
Message-ID: <SBXFXJnsjQHShRNn9P_Q3TijbVi9uQhZUhk2Z9COuF8=.7367f29e-9333-430f-861d-8670cf495160@github.com>

On Fri, 20 Dec 2024 18:22:53 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hotspot loading and CreateJavaVM may happen on different threads

??? What are you referring to as "hotspot loading"? To me that _is_ CreateJavaVM.

> Or, we could move it to the thread subsystem

We already have `Threads::number_of_threads()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895052378

From jbhateja at openjdk.org  Mon Dec 23 06:43:35 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 23 Dec 2024 06:43:35 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v6]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <vLGw_aNYwsVBXHclBwVubObBctcaX65DobT-vRZgdW4=.943eccc4-420e-4dce-8840-78d5e3e20e9d@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments resolution

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/ec0834a3..ae6776e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=04-05

  Stats: 119 lines in 3 files changed: 93 ins; 8 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From jbhateja at openjdk.org  Mon Dec 23 06:43:36 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 23 Dec 2024 06:43:36 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <mrYSgamNO4vK_No6T46HnvsF-RZ8yVW8nC7_rbTwwVY=.b0c27c0b-ea72-49f8-9276-f11025154e27@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <PsaSjWyXPjNy_SUsZjZQLUh1HrQdP-DqU7sdIAatEg8=.93de139c-ce65-41d5-85b1-dc7f064712e5@github.com>
 <mrYSgamNO4vK_No6T46HnvsF-RZ8yVW8nC7_rbTwwVY=.b0c27c0b-ea72-49f8-9276-f11025154e27@github.com>
Message-ID: <KRgGnYOX7MIgslvdeaf8QbZbDW86PwZ5gYhrgDTbAHM=.6736b884-a466-4d2f-8305-a7e8729d2c1e@github.com>

On Tue, 17 Dec 2024 16:39:58 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> This is the core idealization logic which infers FP16 IR. Every test point added in the test points added in test/hotspot/jtreg/compiler/c2/irTests/TestFloat16ScalarOperations.java verifies this.
>
> Picking a random line from `testAddConstantFolding()`
> ` assertResult(add(Float16.POSITIVE_INFINITY, Float16.POSITIVE_INFINITY).floatValue(), Float.POSITIVE_INFINITY, "testAddConstantFolding");`
> 
> So this seems to do a FP16 -> FP16 add, then convert to float, so I don't immediately see the FP16 -> Float -> FP16 conversion.
> 
> Ah, how do we intrinsify this?
> 
>     public static Float16 add(Float16 addend, Float16 augend) {
>         return valueOf(addend.floatValue() + augend.floatValue());
>     }
> 
> Is it not the `add` that is intfinsified, but the `valueOf`, `floatValue` and Float `+`?
> 
> Why not intrinsify the `Float16.add` directly?

In above case, we infer the FP16 addition through pattern matching. 
ConvF2HF (AddF (ConvF2HF addened)   (ConvF2HF augend)) =>   AddHF (ReinterpretS2HF addened) (ReinterpretS2HF augend)

The idea here is to catch the frequently occurring patterns in the graph rather than intrensifying at the function level.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1895315441

From jbhateja at openjdk.org  Mon Dec 23 06:43:36 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 23 Dec 2024 06:43:36 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v3]
In-Reply-To: <Efd8UzwgOqpz162CU5S9fq16xZ7Zs7y2rJF--RoC5O4=.8697cfdb-b144-42fe-9b00-1a764b677815@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
 <VoIW-oMzstyimmhx_1-oUHMkCo_FeXjW9O1MEWMxhzA=.ec52927a-1234-46d6-9213-2ae619d948e8@github.com>
 <pUoK7F0Sx14Uz-Ggt0L4gB3WzScd5TkEZ4-Z1Oj1qSA=.867d7363-b896-43a5-b99a-7c05c6fdce96@github.com>
 <DiFSbHS-FHHYMWH8ukFlm8meO3bMSbt9EkQbM-MJTyQ=.fb7a9050-fa97-4d73-b4e8-862e511c2280@github.com>
 <PfwB5m-a0q5OUzeEqXCaw8qJU-aS7PQjwmcX8NAvgG8=.b94cf242-6b12-46dd-b944-6c86ff3487d1@github.com>
 <Efd8UzwgOqpz162CU5S9fq16xZ7Zs7y2rJF--RoC5O4=.8697cfdb-b144-42fe-9b00-1a764b677815@github.com>
Message-ID: <YI69sF47Bqj2d-9CaY-LyIVc-aMd3fT1m2SFbIfJsmY=.36dce571-b7b9-4844-ad5e-12eb459c5fc9@github.com>

On Tue, 17 Dec 2024 16:40:33 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Yes, there are multiple test points in newly added test which receive floating-point constant which goes through following IR logic before being constant folded 
>> ConF -> ConvF2HF -> ReinterpretS2HF
>
> Please show me an example.

Every constant folding test point that accepts a floating point number first folds it to a short constant by ConvF2HF value routine which is then re-interpreted to FP16 constant (TypeH) through ReinterpretS2HF value conversion.

Here is the link to one such test point
https://github.com/openjdk/jdk/pull/22754/files#diff-3f8786f9f62662eda4b4a5c76c01fa04534c94d870d496501bfc20434ad45579R472

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22754#discussion_r1895315365

From jbhateja at openjdk.org  Mon Dec 23 06:54:34 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Mon, 23 Dec 2024 06:54:34 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 scalar operations [v7]
In-Reply-To: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
References: <a00XTjaE0iFc3MKq9ER_tgXoz81Hg07N8sPSPpTIQt4=.c05fd92f-8105-49d5-80be-ee56aeb77ede@github.com>
Message-ID: <Pfc5OL7VuwoN5XcngckPx0FSdT9wU-y9sGnb1esBmMo=.8be153ea-60d9-49ca-b17e-a7164e98a73b@github.com>

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/22754#issuecomment-2543982577)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA generally operates over floating point registers, thus the compiler injects reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 9. X86  backend implementation for all supported intrinsics.
> 10. Functional and Performance validation tests.
> 
> Kindly review the patch and share your feedback.
> 
> Best Regards,
> Jatin

Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Review comments resolutions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22754/files
  - new: https://git.openjdk.org/jdk/pull/22754/files/ae6776e3..dd444c44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22754&range=05-06

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22754/head:pull/22754

PR: https://git.openjdk.org/jdk/pull/22754

From lliu at openjdk.org  Mon Dec 23 07:06:55 2024
From: lliu at openjdk.org (Liming Liu)
Date: Mon, 23 Dec 2024 07:06:55 GMT
Subject: RFR: 8343978: Update the default value of CodeEntryAlignment for
 Ampere-1A and 1B
In-Reply-To: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
References: <d8J7HGWtv-yPuUbYAEsp4Ts3hgcLjosphqJoK-AP_fc=.c5376952-4203-4a6f-90db-723a5460f83b@github.com>
Message-ID: <q2IP0T_b_0EbB8D5u4HSKLT9Byekk4XtSW6KGReg078=.ee1e29da-aca1-4245-b706-84218766edfb@github.com>

On Fri, 15 Nov 2024 07:01:23 GMT, Liming Liu <lliu at openjdk.org> wrote:

> This PR updates the default value of CodeEntryAlignment for Ampere-1A and 1B from 64 to 32. The microbenchmark CodeCacheStress shows that frontend stall becomes ~21% smaller by the change, and IPC increases by ~2.8%. The benefits persist after CodeCacheSegmentSize changes from 64 back to 128.
> 
> Ran JTReg tier1 on Ampere-1A and no new issues were found.

Keep alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22134#issuecomment-2559037664

From stuefe at openjdk.org  Mon Dec 23 07:26:36 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 07:26:36 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <BEqn7gaZ8OnzfCfcupUxVXaXpF5FzN92veve_oSVwwc=.7ce7b6aa-f8af-4928-99c7-43b67fe58b6d@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
 <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
 <BEqn7gaZ8OnzfCfcupUxVXaXpF5FzN92veve_oSVwwc=.7ce7b6aa-f8af-4928-99c7-43b67fe58b6d@github.com>
Message-ID: <ndMEKVe2lLss3_7O93-w0U-jaCjweME7Rdx2JydkGeA=.75acb111-d54e-4db7-a97f-11fb157cd074@github.com>

On Sun, 22 Dec 2024 17:46:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > Thanks for fixing the issue! This should work. In general, I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.
> > 
> > 
> > +1. Also, instead of casting manually, please use p2u (and if there is none, we should add it like we have a p2i for intptr_t).
> > I am somewhat unenthusiastic about changes like these. We seem to add a lot of casting boilerplate to satisfy UBsan for the sake of cleanliness that only matters on special hardware that treats pointers differently from numeric.
> 
> True, but we can very effectively make the compiler and the reader happy by using `uintptr_t` for all of the arithmetic. After all, we are not using null-based compressed pointers, we are using zero-based compressed pointers, and the distinction is important. `uintptr_t` does not have null as a member, it has zero; conversely `address` does not have zero, it has null. Therefore, when we are using zero-based compressed pointers, better to to use `uintptr_t` for the arithmetic.

Okay, but this is just for the sake of the reader, right? Because a cast can be just as invalid as adding to NULL. I worked on hardware that marked pointers as invalid if they resulted from an integer cast. I assume that "don't add to NULL" warnings exist to preserve portability for these platforms. My thought is: since we cannot hope to achieve portability for these platforms anyway, we might just as well allow adding to NULL. Casting feels like just switching off these warnings. Note that even if I convert the whole of CompressedKlassPointers to uintptr_t, we will need a cast at the latest when we use the base as input to mmap.

But I agree that UBSAN cleanliness is valuable since most of its warnings are good, and maybe its just simpler to fix these issues than to argue about them. So, I am fine with this patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2559061209

From stuefe at openjdk.org  Mon Dec 23 08:08:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:37 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <OSlZWlrt5f0aOJGIKLdgOC9qQGA9qmBYISmXmBQx41s=.99acdee3-216b-4956-a3a0-6f48b5efcb0e@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <2N8ZxzATpiCHJmi0-vqUY7MR9R-FbQjgb004PubtImI=.c093ee71-dfe5-455f-9f95-70c38a260d16@github.com>
 <OSlZWlrt5f0aOJGIKLdgOC9qQGA9qmBYISmXmBQx41s=.99acdee3-216b-4956-a3a0-6f48b5efcb0e@github.com>
Message-ID: <Lschz_z7Wg4alo2vOwo8uUDEVgDSVu1leXfwJEeJkNg=.643e9514-99e9-4312-8de5-f4e157b656cf@github.com>

On Fri, 20 Dec 2024 20:21:39 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 3626:
>> 
>>> 3624:       os::print_memory_mappings((char*)start, bytes, &fs);
>>> 3625:       assert(false, "bad release: [" PTR_FORMAT "-" PTR_FORMAT "): %s", p2i(start), p2i(end), err);
>>> 3626: #endif
>> 
>> @roberttoyonaga Thinking about this, I propose to just remove the os::print_memory_mappings call here. I added this way back when we had problems on Windows with removing "striped" NUMA mappings, but those issues have long been solved. We still have the assertion check, so we will notice if something goes wrong.
>
> Ok I've removed it now

You can also remove the ifdef assert, since assert() only fires if ASSERT is defined

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1894655240

From stuefe at openjdk.org  Mon Dec 23 08:08:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:39 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v9]
In-Reply-To: <eTRGPqCdDcBZtltj18f52hGvmYnQqnsiU8Fv7O5g_Lk=.5d24c867-7224-4611-87eb-6a98e4096fa2@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <eTRGPqCdDcBZtltj18f52hGvmYnQqnsiU8Fv7O5g_Lk=.5d24c867-7224-4611-87eb-6a98e4096fa2@github.com>
Message-ID: <6F00QUi_ttcWN1bxlpiPYQ_GmgYBd9tDqCiA_c5A0sk=.7f47c1c4-2422-4e82-9ba4-8805ff02afdf@github.com>

On Fri, 20 Dec 2024 20:19:50 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
>> 
>> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
>> 
>> 
>> thread->register_thread_stack_with_NMT();
>> thread->initialize_thread_current();
>> 
>> 
>> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
>> 
>> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
>> 
>> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
>> 
>> I also removed the unused `_query_lock` variable in `MemTracker`.
>> 
>> Testing: 
>> 
>> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
>> - hotspot_nmt , gtest:VirtualSpace, tier1
>
> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove os::print_memory_mappings. Add comments explaining NMT locking

src/hotspot/share/nmt/memTracker.hpp line 300:

> 298:    * attempting to lock until initialization is finished. Lack of synchronization here should not be a problem since it
> 299:    * is single threaded at that point in time anyway.
> 300:    */

good comment

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895374056

From stuefe at openjdk.org  Mon Dec 23 08:08:40 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:40 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
 <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>
Message-ID: <fOL5YuULPagTqxeleFjU5L9fR_7Nc78yx-Xx--F0vmk=.4abbb123-4d64-418b-b968-d65a8a24e0fb@github.com>

On Fri, 20 Dec 2024 17:43:29 GMT, Robert Toyonaga <duke at openjdk.org> wrote:

> I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.


It could be called as part of the NMT report error reporting during early JVM initialization => between NMT bootstrap and Mutex system startup. That report is only written though if NMT is enabled, and that requires NMT to have been bootstrapped. Is NMT bootstrap after Mutex system bootstrap? Then we are fine here.

Man, I start warming up to your original idea of just using a plain OS-side mutex for NMT lockes, @roberttoyonaga . One that always works. Problem is missing deadlock detection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895379917

From stuefe at openjdk.org  Mon Dec 23 08:08:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:08:42 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
 <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
Message-ID: <3n0ir33zcUWsWk13ncRu4dfnMDUqfUcHmVkJbXI04gU=.66b705fd-d1fb-4175-b7b2-f637ffdc21ec@github.com>

On Sat, 21 Dec 2024 16:57:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move boostrapping_done flag into Mutex from MutexLocker
>
> src/hotspot/share/runtime/mutexLocker.cpp line 291:
> 
>> 289:   MUTEX_DEFN(NMTQuery_lock                   , PaddedMutex  , safepoint);
>> 290:   MUTEX_DEFN(NMTCompilationCostHistory_lock  , PaddedMutex  , nosafepoint);
>> 291:   MUTEX_DEFN(NmtVirtualMemory_lock           , PaddedMutex  , service-4); // Must be lower than G1Mapper_lock used from G1RegionsSmallerThanCommitSizeMapper::commit_regions
> 
> Is it really okay for nmt to use a VM mutex? That means relevant functions can
> only be called from a VM thread. In particular, what happens if we get into
> the error handler because of a signal on a non-VM thread, or something
> similarly weird.
> 
> This is also replacing the PlatformMutex that was being used by
> MemoryFileTracker. I don't know why that was using a PlatformMutex, but I
> presume there was a reason. It was doing so in the initial version of
> JDK-8312132. Looking back through the development commits, is see these two in
> sequence:
> 
> 3472573 Introduce a separate Mutex for MemoryFileTracker
> 46f10f6 Use own PlatformMutex instead
> 
> I found no discussion about that choice in the PR. Maybe it was because of
> problems determining the needed lock rank? (The original VM mutex had
> Mutex::service rank. That's apparently too high, as discussed in this change.)
> Or maybe there was some other reason?
> 
> I'll ask @jdksjolen about this, though holidays...

@kimbarrett This was my proposal, but I now doubt whether it was a good proposal. My reasoning was that we want to have deadlock detection (NMT locking is somewhat "midlevel" since the section it encompasses can be large) and things like "assert_lock_strong". Admittedly, the latter can be easily done differently with a raw OS-side mutex.

After thinking about this more, the advantages of a raw OS-side mutex would be:
- not having to think about initialization order
- can be statically initialized at least on Posix
- it works when we are called from a non-VM thread - ideas both I and @jdksjolen had would be extending NMT to outside, which opens us to being called both long before VM init and outside any VM thread

Not sure anymore what to think. What do others think? Go back to Roberts original proposal?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895386033

From stuefe at openjdk.org  Mon Dec 23 08:13:40 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 23 Dec 2024 08:13:40 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v4]
In-Reply-To: <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
Message-ID: <0A4ekxV87UU3d6YbazCu7plLGEglkYLvAF_dvkPRmug=.c577b4a1-e10a-4ef8-9d1d-2928320ecb54@github.com>

On Sat, 21 Dec 2024 15:56:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
>> 
>> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
>> 
>> ```c++
>>     address const end = addr + len;
>>     if (end <= (address)unscaled_max) {
>>       _base = nullptr;
>>       _shift = 0;
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add function p2u and use function p2u instead of cast manually

src/hotspot/share/oops/compressedKlass.cpp line 99:

> 97:   // Check that Klass range is fully engulfed in the encoding range
> 98:   const address encoding_start = _base;
> 99:   const address encoding_end = (address)(p2u(_base) + (uintptr_t)nth_bit(narrow_klass_pointer_bits() + _shift));

nth_bit should already give us a 64-bit value, why the second cast?
I see that nth_bit returns an intptr_t - is the sign the problem? We may want to change that to uintptr_t...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22848#discussion_r1895392988

From syan at openjdk.org  Mon Dec 23 09:18:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 23 Dec 2024 09:18:40 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v4]
In-Reply-To: <0A4ekxV87UU3d6YbazCu7plLGEglkYLvAF_dvkPRmug=.c577b4a1-e10a-4ef8-9d1d-2928320ecb54@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
 <0A4ekxV87UU3d6YbazCu7plLGEglkYLvAF_dvkPRmug=.c577b4a1-e10a-4ef8-9d1d-2928320ecb54@github.com>
Message-ID: <Xyo3-hz5_2Ac8lt_58uioWlmTBE8BCNypeulA1d9MD4=.28649037-18b0-4886-bea7-fa90e21c2985@github.com>

On Mon, 23 Dec 2024 08:11:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add function p2u and use function p2u instead of cast manually
>
> src/hotspot/share/oops/compressedKlass.cpp line 99:
> 
>> 97:   // Check that Klass range is fully engulfed in the encoding range
>> 98:   const address encoding_start = _base;
>> 99:   const address encoding_end = (address)(p2u(_base) + (uintptr_t)nth_bit(narrow_klass_pointer_bits() + _shift));
> 
> nth_bit should already give us a 64-bit value, why the second cast?
> I see that nth_bit returns an intptr_t - is the sign the problem? We may want to change that to uintptr_t...

Prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22848#discussion_r1895508997

From mdoerr at openjdk.org  Mon Dec 23 09:44:36 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 23 Dec 2024 09:44:36 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v4]
In-Reply-To: <Xyo3-hz5_2Ac8lt_58uioWlmTBE8BCNypeulA1d9MD4=.28649037-18b0-4886-bea7-fa90e21c2985@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
 <0A4ekxV87UU3d6YbazCu7plLGEglkYLvAF_dvkPRmug=.c577b4a1-e10a-4ef8-9d1d-2928320ecb54@github.com>
 <Xyo3-hz5_2Ac8lt_58uioWlmTBE8BCNypeulA1d9MD4=.28649037-18b0-4886-bea7-fa90e21c2985@github.com>
Message-ID: <J3kYr5fkTkkQqhNE_Y7UutiPxsZT4l8imU6jauMs9rY=.d4180d39-6210-4160-8371-d8252ade69aa@github.com>

On Mon, 23 Dec 2024 09:15:33 GMT, SendaoYan <syan at openjdk.org> wrote:

>> src/hotspot/share/oops/compressedKlass.cpp line 99:
>> 
>>> 97:   // Check that Klass range is fully engulfed in the encoding range
>>> 98:   const address encoding_start = _base;
>>> 99:   const address encoding_end = (address)(p2u(_base) + (uintptr_t)nth_bit(narrow_klass_pointer_bits() + _shift));
>> 
>> nth_bit should already give us a 64-bit value, why the second cast?
>> I see that nth_bit returns an intptr_t - is the sign the problem? We may want to change that to uintptr_t...
>
> Prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.

It should work without the second cast, but there may be compiler warnings like "warning: implicit conversion changes signedness: 'long' to 'unsigned long' [-Wsign-conversion]".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22848#discussion_r1895537616

From qxing at openjdk.org  Mon Dec 23 09:50:10 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Mon, 23 Dec 2024 09:50:10 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
Message-ID: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>

This patch fixes unmatched brackets in some source files.

-------------

Commit messages:
 - Fix unmatched brackets in source files.

Changes: https://git.openjdk.org/jdk/pull/22861/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346773
  Stats: 2244 lines in 25 files changed: 2211 ins; 2 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/22861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22861/head:pull/22861

PR: https://git.openjdk.org/jdk/pull/22861

From mdoerr at openjdk.org  Mon Dec 23 10:21:37 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 23 Dec 2024 10:21:37 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <ndMEKVe2lLss3_7O93-w0U-jaCjweME7Rdx2JydkGeA=.75acb111-d54e-4db7-a97f-11fb157cd074@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
 <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
 <BEqn7gaZ8OnzfCfcupUxVXaXpF5FzN92veve_oSVwwc=.7ce7b6aa-f8af-4928-99c7-43b67fe58b6d@github.com>
 <ndMEKVe2lLss3_7O93-w0U-jaCjweME7Rdx2JydkGeA=.75acb111-d54e-4db7-a97f-11fb157cd074@github.com>
Message-ID: <wZTOfHu5jaXwUQMFmo5efJusYkPhgANYkVPR3zm_MKA=.ddf12f37-ddaf-447a-b33b-59dd7ea82cf8@github.com>

On Mon, 23 Dec 2024 07:23:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > > Thanks for fixing the issue! This should work. In general, I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.
> > > 
> > > 
> > > +1. Also, instead of casting manually, please use p2u (and if there is none, we should add it like we have a p2i for intptr_t).
> > > I am somewhat unenthusiastic about changes like these. We seem to add a lot of casting boilerplate to satisfy UBsan for the sake of cleanliness that only matters on special hardware that treats pointers differently from numeric.
> > 
> > 
> > True, but we can very effectively make the compiler and the reader happy by using `uintptr_t` for all of the arithmetic. After all, we are not using null-based compressed pointers, we are using zero-based compressed pointers, and the distinction is important. `uintptr_t` does not have null as a member, it has zero; conversely `address` does not have zero, it has null. Therefore, when we are using zero-based compressed pointers, better to to use `uintptr_t` for the arithmetic.
> 
> Okay, but this is just for the sake of the reader, right? Because a cast can be just as invalid as adding to NULL. I worked on hardware that marked pointers as invalid if they resulted from an integer cast. I assume that "don't add to NULL" warnings exist to preserve portability for these platforms. My thought is: since we cannot hope to achieve portability for these platforms anyway, we might just as well allow adding to NULL. Casting feels like just switching off these warnings. Note that even if I convert the whole of CompressedKlassPointers to uintptr_t, we will need a cast at the latest when we use the base as input to mmap.
> 
> But I agree that UBSAN cleanliness is valuable since most of its warnings are good, and maybe its just simpler to fix these issues than to argue about them. So, I am fine with this patch.

Undefined behavior is a risk. Compilers currently seem to do what we want, but there's no guarantee. They could optimize the code in a way which breaks it. That would be legal since it is undefined behavior. `uintptr_t` arithmetics are defined as well as the casts. "Any value of type std::nullptr_t, including nullptr can be converted to any integral type as if it were (void*)0" [https://en.cppreference.com/w/cpp/language/reinterpret_cast]. I guess compilers need to handle the conversion during the casts on platforms on which nullptr is not the zero address.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2559371631

From syan at openjdk.org  Mon Dec 23 10:21:38 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 23 Dec 2024 10:21:38 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v4]
In-Reply-To: <J3kYr5fkTkkQqhNE_Y7UutiPxsZT4l8imU6jauMs9rY=.d4180d39-6210-4160-8371-d8252ade69aa@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
 <0A4ekxV87UU3d6YbazCu7plLGEglkYLvAF_dvkPRmug=.c577b4a1-e10a-4ef8-9d1d-2928320ecb54@github.com>
 <Xyo3-hz5_2Ac8lt_58uioWlmTBE8BCNypeulA1d9MD4=.28649037-18b0-4886-bea7-fa90e21c2985@github.com>
 <J3kYr5fkTkkQqhNE_Y7UutiPxsZT4l8imU6jauMs9rY=.d4180d39-6210-4160-8371-d8252ade69aa@github.com>
Message-ID: <vhWmuTcLQLrYB3J01QeR1wtBrA4M1giK1XsadUqHWa8=.ee57c123-2e3a-4eab-81cd-21d1b12e0e5e@github.com>

On Mon, 23 Dec 2024 09:41:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> It should work without the second cast, but there may be compiler warnings like "warning: implicit conversion changes signedness: 'long' to 'unsigned long' [-Wsign-conversion]".

Yes, below example can reproduce the gcc/clang compile warning.


#include <stdio.h>

int main()
{
  unsigned long a = 1;
  signed long b = 2;
  printf("%llu\n", (long long unsigned int)(a + b));
  return 0;
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22848#discussion_r1895571206

From mdoerr at openjdk.org  Mon Dec 23 10:25:45 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 23 Dec 2024 10:25:45 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v4]
In-Reply-To: <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
Message-ID: <Vv1xk8zOJBRiTS7NMfFVdZ89aK_Ey83HI1MmAJHBKwE=.9b95a618-23ee-4d3d-9934-7bac3e801e39@github.com>

On Sat, 21 Dec 2024 15:56:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
>> 
>> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
>> 
>> ```c++
>>     address const end = addr + len;
>>     if (end <= (address)unscaled_max) {
>>       _base = nullptr;
>>       _shift = 0;
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add function p2u and use function p2u instead of cast manually

Marked as reviewed by mdoerr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22848#pullrequestreview-2520321027

From fgao at openjdk.org  Mon Dec 23 10:50:17 2024
From: fgao at openjdk.org (Fei Gao)
Date: Mon, 23 Dec 2024 10:50:17 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands
Message-ID: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>

`IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.

This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).

After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.

Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.

-------------

Commit messages:
 - 8341611: [REDO] AArch64: Clean up IndOffXX type and let legitimize_address() fix out-of-range operands

Changes: https://git.openjdk.org/jdk/pull/22862/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22862&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341611
  Stats: 8742 lines in 15 files changed: 8373 ins; 247 del; 122 mod
  Patch: https://git.openjdk.org/jdk/pull/22862.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22862/head:pull/22862

PR: https://git.openjdk.org/jdk/pull/22862

From syan at openjdk.org  Mon Dec 23 11:29:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 23 Dec 2024 11:29:40 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v4]
In-Reply-To: <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <eUPH9olyajDabykn9uSnUaCkv4PBShRc37ygDlYqdTc=.d5830499-8ec5-4fa8-b371-4bfacd2a86a0@github.com>
Message-ID: <HSbpJobUKK7WGsf_i_SdEwVLVdaIaceCnyHZ2WMn74w=.e3b29f74-1ef5-4c70-8304-aca97374cd2f@github.com>

On Sat, 21 Dec 2024 15:56:15 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
>> 
>> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
>> 
>> ```c++
>>     address const end = addr + len;
>>     if (end <= (address)unscaled_max) {
>>       _base = nullptr;
>>       _shift = 0;
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add function p2u and use function p2u instead of cast manually

Thank all for the detailed discussion, explanation and reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2559504548

From syan at openjdk.org  Mon Dec 23 11:29:40 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 23 Dec 2024 11:29:40 GMT
Subject: Integrated: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer
In-Reply-To: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
Message-ID: <__grmgyYMxG11vNSMJfk6deuN-3Vv2vFYuoAm0IwXh4=.7d367c64-173c-4ac8-8025-102ff54eb0f8@github.com>

On Fri, 20 Dec 2024 12:56:08 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> CompressedKlassPointers::sanity_check_after_initialization() src/hotspot/share/oops/compressedKlass.cpp:104:38 reported runtime error: applying non-zero offset 4294967296 to null pointer by clang17 UndefinedBehaviorSanitizer.
> 
> The _base initial as nullptr in function CompressedKlassPointers::initialize(address addr, size_t len) shows as below. In C/C++, offsetting a null pointer is undefined behavior. This PR do not change the original logic but eliminate the undefined behaviour in code, the risk is low.
> 
> ```c++
>     address const end = addr + len;
>     if (end <= (address)unscaled_max) {
>       _base = nullptr;
>       _shift = 0;

This pull request has now been integrated.

Changeset: bffa77bc
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bffa77bc04219d3b2fd0898f5e62f324503b2b94
Stats:     6 lines in 2 files changed: 5 ins; 0 del; 1 mod

8346714: [ASAN] compressedKlass.cpp reported applying non-zero offset to null pointer

Reviewed-by: mdoerr, coleenp

-------------

PR: https://git.openjdk.org/jdk/pull/22848

From fjiang at openjdk.org  Mon Dec 23 13:51:37 2024
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 23 Dec 2024 13:51:37 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v6]
In-Reply-To: <O4t3DYyEeMOgQ2HAR2M-UPI0IIbgMKLINEdExVgyFUc=.057053f2-0107-4ddd-a433-c3e7dad923af@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
 <O4t3DYyEeMOgQ2HAR2M-UPI0IIbgMKLINEdExVgyFUc=.057053f2-0107-4ddd-a433-c3e7dad923af@github.com>
Message-ID: <9j40rWZ33LquI5ljXhNwhiVJcNnSaZM7AhdkoreGtzs=.38d337b9-18a5-4ec4-a331-450976eec519@github.com>

On Mon, 23 Dec 2024 03:24:08 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Hi, please consider this cleanup change.
>> 
>> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
>> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check about the immediate range and avoid the use of one tmp register by the latter as well.
>> 
>> In order to make the code more readable, this also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
>> 
>> 
>> 
>>  <Design of the RISC-V Instruction Set Architecture>:
>> 
>>  There is no SUBI instruction, because ADDI with a negative immediate is almost equivalent. The one
>>  exception arises from the asymmetry of the twos complement representation: SUBI with an immediate of
>>  -2048 would add 2048 to a register, which ADDI is incapable of.
>> 
>> 
>> Testing on Premier-P550 SBC running Ubuntu-24.04:
>> - [x] : tier1-3 and gtest:all (release)
>> - [x] : hotspot:tier1 (fastdebug)
>
> Fei Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Marked as reviewed by fjiang (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22804#pullrequestreview-2520628868

From erikj at openjdk.org  Mon Dec 23 14:05:35 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 23 Dec 2024 14:05:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some source files.

I can really only review the doc files and the Makefile.

doc/hotspot-unit-tests.md line 175:

> 173: there is no need to have them in error messages. Asserts print only
> 174: compared values, they do not print any of interim variables, e.g.
> 175: `ASSERT_TRUE(val1 == val2 && isFail(foo(8)) || i == 18)` prints only

Looking at this expression, I believe the intention is this.
Suggestion:

`ASSERT_TRUE((val1 == val2 && isFail(foo(8))) || i == 18)` prints only

-------------

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2520648246
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1895785097

From duke at openjdk.org  Mon Dec 23 14:30:43 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 23 Dec 2024 14:30:43 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v11]
In-Reply-To: <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <_mYFIyBMcdaQasuxzrHzRHonm9dUhW_CXxwBpP-vCiw=.7caa2d49-d687-4ef7-bbaa-20a6fa01469b@github.com>
 <hpJo8r4ka8W0mq7T0_IIy114asXjpl_TbWZ9fKLZ5j8=.4cae1be8-04e2-4ad4-a30c-d90daf2c2fc5@github.com>
Message-ID: <QBH7xfLoxwZP_Vj1l2EWCF78I6dQFZQBthy3TJnEFQc=.25cb7bbc-2d6a-4f17-8b2a-774def040906@github.com>

On Sat, 21 Dec 2024 07:16:22 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   move boostrapping_done flag into Mutex from MutexLocker
>
> src/hotspot/share/nmt/threadStackTracker.cpp line 55:
> 
>> 53:   align_thread_stack_boundaries_inward(base, size);
>> 54: 
>> 55:   MemTracker::MemTracker::NmtVirtualMemoryLocker nvml;
> 
> Too many "MemTracker"s here?

thank you for spotting. I'll remove that

> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 632:
> 
>> 630:     if (Mutex::is_bootstrapping_done()) {
>> 631:       assert_lock_strong(NmtVirtualMemory_lock);
>> 632:     }
> 
> It seems like this can use `MemTracker::assert_locked()`, since that is conditioned on bootstrapping state.

`assert_lock_strong`  skips checking the lock ownership if `DebuggingContext::is_enabled() || VMError::is_error_reported()`. `MemTracker::assert_locked()` does not do that.  Is that ok?

> src/hotspot/share/runtime/mutex.hpp line 222:
> 
>> 220:   }
>> 221:  private:
>> 222:   static bool _bootstrapping_done;
> 
> A description of what these mean would be nice. It seems to be mutex_init completed + threading
> initialization completed?

Yes, that's right. I'll add a comment describing this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895809641
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895811421
PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895812737

From duke at openjdk.org  Mon Dec 23 14:30:44 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 23 Dec 2024 14:30:44 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v6]
In-Reply-To: <fOL5YuULPagTqxeleFjU5L9fR_7Nc78yx-Xx--F0vmk=.4abbb123-4d64-418b-b968-d65a8a24e0fb@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
 <-3JI1AYO0DU91WGcVxw8bZxxmB1G8NgQlQnnl9HeKeE=.a9382247-42aa-443c-b9cc-62bb09920bd0@github.com>
 <jJ4RyS1aJjME8nPCqNOF2XBdnJcZc9v_Mc4ZscUHayA=.ef6cb8b0-56af-4b47-beed-11c840261dd0@github.com>
 <0P0VqDd6YpHxE8FdHL8X2GhpIZstJes6wd032pKtKoA=.b0f2f29c-37a1-49a5-a2a9-415eb8af0368@github.com>
 <fOL5YuULPagTqxeleFjU5L9fR_7Nc78yx-Xx--F0vmk=.4abbb123-4d64-418b-b968-d65a8a24e0fb@github.com>
Message-ID: <mKKgJkD_4QVGje73WRrviM-KEqq11juDenhV7VWV3ZU=.6bfee217-dfff-4b78-9585-dc7d887ba07a@github.com>

On Mon, 23 Dec 2024 07:58:32 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.
>
>> I don't think this should ever get called during bootstrapping because thread stacks are only accounted lazily when a snapshot is created. I don't think an NMT snapshot would ever get created during bootstrapping, but just in case, I've added a check for `MemTracker::is_bootstrapping_done()`.
> 
> 
> It could be called as part of the NMT report error reporting during early JVM initialization => between NMT bootstrap and Mutex system startup. That report is only written though if NMT is enabled, and that requires NMT to have been bootstrapped. Is NMT bootstrap after Mutex system bootstrap? Then we are fine here.
> 
> Man, I start warming up to your original idea of just using a plain OS-side mutex for NMT lockes, @roberttoyonaga . One that always works. Problem is missing deadlock detection.

`MemTracker::initialize();` is called before Mutexes are ready. So it seems like that means this `assert_lock_strong` can be called before Mutexes can be used. So we do need that check for `MemTracker::is_bootstrapping_done()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22745#discussion_r1895808205

From rcastanedalo at openjdk.org  Mon Dec 23 15:09:36 2024
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 23 Dec 2024 15:09:36 GMT
Subject: RFR: 8346288: WB_IsIntrinsicAvailable fails if called with wrong
 compilation level
In-Reply-To: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
References: <T-iWeR41XZO2F5XoPhE_fbhITGzSxmQWlpCsTAGwbqI=.d8c58391-7c80-4b17-a417-682032024eeb@github.com>
Message-ID: <IyiJ5vvDf-a4D4GZ3IrlvLZ_SfR1eIkN38DYXn8KmHI=.9c7b4b4a-d13e-473a-b9cc-4b54f0d2bee5@github.com>

On Thu, 19 Dec 2024 07:25:15 GMT, Daniel Skantz <dskantz at openjdk.org> wrote:

> Fixes crashes when calling isIntrinsicAvailable with an incorrect compilation level or incompatible VM flag values.
> 
> Testing: T1-3.
> Extra testing: called isIntrinsicAvailable with compLevel={-2, -1, ..., 5) without extra flags, and with -XX:-TieredCompilation -XX:TieredStopAtLevel={0, 1, ..., 4} and observed no crashes after the fix.

Marked as reviewed by rcastanedalo (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22823#pullrequestreview-2520750645

From duke at openjdk.org  Mon Dec 23 15:26:13 2024
From: duke at openjdk.org (Robert Toyonaga)
Date: Mon, 23 Dec 2024 15:26:13 GMT
Subject: RFR: 8346123: [REDO] NMT should not use ThreadCritical [v12]
In-Reply-To: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
References: <ftxirLsharO9VdVtKbCa787SFzUQwX3XNMubBH8roPc=.18524a30-a685-4e00-bff7-836315623487@github.com>
Message-ID: <PRehBeojKAaWfsmBZtPYuGO7A-0lSobodb2VsknHjGE=.e23dbb09-41b8-40db-a0df-6a4a4493b616@github.com>

> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824) which was backed out by [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems documented in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244).
> 
> The problem was that `NmtVirtualMemoryLocker` was not locking when the current thread is not attached by checking `Thread::current_or_null_safe() != nullptr`. This is necessary during VM init, but should not be allowed afterward. NMT may be used in `attach_current_thread` before the current thread is set. The lock was not being acquired in that case, which intermittently caused NMT accounting to become corrupted, triggering various assertions when future NMT operations are done.  To fix this, I've adopted [Thomas' suggestion](https://github.com/openjdk/jdk/pull/21928#issuecomment-2460238057) to reverse the order of 
> 
> 
> thread->register_thread_stack_with_NMT();
> thread->initialize_thread_current();
> 
> 
> in `attach_current_thread`.  This allows `NmtVirtualMemoryLocker` to be locked after current thread is set. 
> 
> To allow for `NmtVirtualMemoryLocker` to be used during VM init, I've replaced the `ConditionalMutexLocker` check `Thread::current_or_null_safe() != nullptr` with a new flag: `_done_bootstrap`. This flag prevents the lock from being used during VM init, at which point we are single threaded anyway. This avoids errors due to Hotspot mutexes and current thread not yet being ready. 
> 
> I also added new asserts in `virtualMemoryTracker.cpp` to catch future bugs like this where the lock is not held when it should be. I updated the appropriate VMT tests to also lock (there were a few cases where locking was being bypassed) so they can pass the new asserts.
> 
> I also removed the unused `_query_lock` variable in `MemTracker`.
> 
> Testing: 
> 
> - On Linux amd64, I was able to consistently reproduce the errors described in [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) by increasing the number of test threads in `java/lang/Thread/jni/AttachCurrentThread/AttachTest.java`. The test consistently passes with the new changes in this PR.
> - hotspot_nmt , gtest:VirtualSpace, tier1

Robert Toyonaga has updated the pull request incrementally with one additional commit since the last revision:

  comments, remove unneeded ifdef, remove typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22745/files
  - new: https://git.openjdk.org/jdk/pull/22745/files/1909279c..5e36546e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22745&range=10-11

  Stats: 7 lines in 3 files changed: 4 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22745.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22745/head:pull/22745

PR: https://git.openjdk.org/jdk/pull/22745

From jlu at openjdk.org  Mon Dec 23 17:13:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Dec 2024 17:13:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some source files.

make/data/cldr/common/main/kn.xml line 1085:

> 1083: 			<type key="calendar" type="islamic">????????? ??????????</type>
> 1084: 			<type key="calendar" type="islamic-civil">?????????-?????? ??????????</type>
> 1085: 			<type key="calendar" type="islamic-rgsa" draft="contributed">?????????? ??????????? (???? ???????, ????????)</type>

Hi, we would not modify the contents of upstream data from CLDR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1895964999

From aph at openjdk.org  Mon Dec 23 18:58:36 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 23 Dec 2024 18:58:36 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands
In-Reply-To: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
References: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
Message-ID: <37mq65a-Jfc2gwilfr2OqH2bGl8EsuWaLp9g5nWZP4s=.997cf843-ac48-4d35-a314-b6eb4b378d90@github.com>

On Mon, 23 Dec 2024 10:45:00 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.
> 
> This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).
> 
> After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.
> 
> Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.

src/hotspot/cpu/aarch64/aarch64.ad line 5203:

> 5201: %}
> 5202: 
> 5203: // "off" is probably not within the encoding range for LDR/STR instructions

Suggestion:

// "off" may not be within the encoding range for LDR/STR instructions

Reads better, perhaps?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22862#discussion_r1896038897

From aph at openjdk.org  Mon Dec 23 19:04:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 23 Dec 2024 19:04:40 GMT
Subject: RFR: 8341611: [REDO] AArch64: Clean up IndOffXX type and let
 legitimize_address() fix out-of-range operands
In-Reply-To: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
References: <WJZEwsDDkx7Qu0ANHGvHUqgcziarhAf8Qq9FcJ9NukQ=.e314ee6a-d6ac-41a0-ab14-23a0a2af8465@github.com>
Message-ID: <s_94WASXBZfedpvij--bghlregLi4MZ6O4j49-lw1B8=.f3daabef-a9b4-42a0-bc52-0152a4b9ef27@github.com>

On Mon, 23 Dec 2024 10:45:00 GMT, Fei Gao <fgao at openjdk.org> wrote:

> `IndOffXX` types don't do us any good. It would be simpler and faster to match a general-purpose `IndOff` type then let `legitimize_address()` fix any out-of-range operands. That'd reduce the size of the match rules and the time to run them.
> 
> This patch simplifies the definitions of `immXOffset` with an estimated range. Whether an immediate can be encoded in a `LDR`/`STR` instructions as an offset will be determined in the phase of code-emitting. Meanwhile, we add necessary `legitimize_address()` in the phase of matcher for all `LDR`/`STR` instructions using the new `IndOff` memory operands (fix [JDK-8341437](https://bugs.openjdk.org/browse/JDK-8341437)).
> 
> After this clean-up, memory operands matched with `IndOff` may require extra code emission (effectively a `lea`) before the address can be used. So we also modify the code about looking up precise offset of load/store instruction for implicit null check (fix [JDK-8340646](https://bugs.openjdk.org/browse/JDK-8340646)). On `aarch64` platform, we will use the beginning offset of the last instruction in the instruction clause emitted for a load/store machine node. Because `LDR`/`STR` is always the last one emitted, no matter what addressing mode the load/store operations finally use.
> 
> Tier 1 - 3 passed on `Macos-aarch64` with or without the vm option `-XX:+UseZGC`.

In general I like this very much.
If I were you I'd count how often `legitimize_address` has to split an instruction, and also count the total size of all C2 compilations over a run. I'd perhaps run jshell or javac all of java.base. Then we'd know how rare `legitimize_address` splitting is.
Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22862#issuecomment-2560171145

From aph-open at littlepinkcloud.com  Mon Dec 23 19:12:07 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Mon, 23 Dec 2024 19:12:07 +0000
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer [v2]
In-Reply-To: <ndMEKVe2lLss3_7O93-w0U-jaCjweME7Rdx2JydkGeA=.75acb111-d54e-4db7-a97f-11fb157cd074@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
 <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
 <BEqn7gaZ8OnzfCfcupUxVXaXpF5FzN92veve_oSVwwc=.7ce7b6aa-f8af-4928-99c7-43b67fe58b6d@github.com>
 <ndMEKVe2lLss3_7O93-w0U-jaCjweME7Rdx2JydkGeA=.75acb111-d54e-4db7-a97f-11fb157cd074@github.com>
Message-ID: <a04b4351-b726-48e3-9dc8-535aeab843df@littlepinkcloud.com>

On 12/23/24 07:26, Thomas Stuefe wrote:
> On Sun, 22 Dec 2024 17:46:52 GMT, Andrew Haley <aph at openjdk.org> wrote:
> 
>>>> Thanks for fixing the issue! This should work. In general, I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.
>>>
>>>
>>> +1. Also, instead of casting manually, please use p2u (and if there is none, we should add it like we have a p2i for intptr_t).
>>> I am somewhat unenthusiastic about changes like these. We seem to add a lot of casting boilerplate to satisfy UBsan for the sake of cleanliness that only matters on special hardware that treats pointers differently from numeric.
>>
>> True, but we can very effectively make the compiler and the reader happy by using `uintptr_t` for all of the arithmetic. After all, we are not using null-based compressed pointers, we are using zero-based compressed pointers, and the distinction is important. `uintptr_t` does not have null as a member, it has zero; conversely `address` does not have zero, it has null. Therefore, when we are using zero-based compressed pointers, better to to use `uintptr_t` for the arithmetic.
> 
> Okay, but this is just for the sake of the reader, right? Because a cast can be just as invalid as adding to NULL.

I don't agree.  Adding to NULL is explicitly UB. C++ doesn't have to generate
any code for it.

> I worked on hardware that marked pointers as invalid if they resulted from an integer cast. I assume that "don't add to NULL" warnings exist to preserve portability for these platforms.

That's not so. Current C++ compilers can, and some do, correctly generate no code for anything following UB.

If you were to convert a pointer to uintptr_t, discover that it fits in an int, convert it to an int, and
then convert it back to a pointer, that is well-defined C++, and must be executed. You can even write a
pointer to a file, read it back later, and use that pointer. And it must work.

> My thought is: since we cannot hope to achieve portability for these platforms anyway, we might just as well allow adding to NULL.

No. That is UB.

> Casting feels like just switching off these warnings.

That's how it feels, sure, but you're moving from UB to implementation-defined behaviour.
The latter we can cope with.

> Note that even if I convert the whole of CompressedKlassPointers to uintptr_t, we will need a cast at the latest when we use the base as input to mmap.

Yes. Good.

> But I agree that UBSAN cleanliness is valuable since most of its warnings are good, and maybe its just simpler to fix these issues than to argue about them. So, I am fine with this patch.



From kbarrett at openjdk.org  Mon Dec 23 19:36:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Dec 2024 19:36:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>

On Mon, 23 Dec 2024 09:45:00 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> This patch fixes unmatched brackets in some source files.

I strongly suggest avoiding omnibus changes like this when possible (which it
is here). Just because it's all about one "kind" of change doesn't make it a
cohesive change. This is touching many distinct areas of the JDK, and several
different languages as well. That makes it harder to review and to manage the
review, because it is large and affects a wide range of areas, so may need
many reviewers. And the whole thing might get stalled by discussion of one
piece.

There is also no mention of what testing has been done for this PR. Some of
the changes are in executable code, and need to be tested.

I think that all of the files in make/data/cldr/common are from the Unicode
Consortium, and should not be modified here.

doc/hotspot-unit-tests.html line 248:

> 246: so there is no need to have them in error messages. Asserts print only
> 247: compared values, they do not print any of interim variables, e.g.
> 248: <code>ASSERT_TRUE(val1 == val2 &amp;&amp; isFail(foo(8)) || i == 18)</code>

This file is generated from the .md file, and should not be edited directly.

test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:

> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
> 49:     $(TESTLIBRARY_DIR)/jtreg \
> 50:     -maxdepth 1 -name '*.java')

I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
close-paren?

test/jaxp/javax/xml/jaxp/unittest/transform/Bug8169112.xsl line 65:

> 63:           @page { margin: 0.1in; }
> 64: 
> 65:           }

Does this affect the behavior of the test this is part of?

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:

> 1: <?xml version="1.0" encoding="UTF-8"?>
> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"

I can't tell whether anything was changed in this file other than the modification of all the end of
line indicators. I've no idea whether changing those is appropriate or not, but this file came from
a 3rd party, so might not be appropriate to change here.

test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:

> 1: <?xml version="1.0" encoding="UTF-8"?>
> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"

Does this change affect the behavior of the associated test(s)?

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2521031190
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896040106
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896050113
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896061137
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896064083
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896064580

From kbarrett at openjdk.org  Mon Dec 23 19:45:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Dec 2024 19:45:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>

On Mon, 23 Dec 2024 19:33:36 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.

And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2560215378

From prr at openjdk.org  Mon Dec 23 20:33:34 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 20:33:34 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
Message-ID: <PFz3alfIjjgTruEYo0zh1sF7VlmWQfYSm5zVAbgWMZM=.16f79e13-f7ca-4311-81f5-a66874094766@github.com>

On Mon, 23 Dec 2024 19:42:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.
> 
> And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

I think at the very least this needs multiple reviewers. Even 2 isn't enough considering it is so cross-area.
It went to 7 different mailing lists, so that should tell you something !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2560263514

From prr at openjdk.org  Mon Dec 23 20:33:36 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 20:33:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>

On Mon, 23 Dec 2024 19:30:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
> 
>> 1: <?xml version="1.0" encoding="UTF-8"?>
>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
> 
> Does this change affect the behavior of the associated test(s)?

I was also wondering how this was tested.

> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
> 
>> 1: <?xml version="1.0" encoding="UTF-8"?>
>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
> 
> I can't tell whether anything was changed in this file other than the modification of all the end of
> line indicators. I've no idea whether changing those is appropriate or not, but this file came from
> a 3rd party, so might not be appropriate to change here.

+1 to all of that. This change is un-reviewable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896100629
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896100936

From prr at openjdk.org  Mon Dec 23 22:18:35 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 23 Dec 2024 22:18:35 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files
In-Reply-To: <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
Message-ID: <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>

On Mon, 23 Dec 2024 20:29:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/sanity/client/lib/SwingSet3/src/com/sun/swingset3/demos/table/resources/oscars.xml line 2:
>> 
>>> 1: <?xml version="1.0" encoding="UTF-8"?>
>>> 2: <oscars xmlns:osc-results="http://www.fatdog.com/oscar-results"
>> 
>> Does this change affect the behavior of the associated test(s)?
>
> I was also wondering how this was tested.

FYI, the way to test this is ..
cd test/jdk
jtreg sanity/client/SwingSet/src/TableDemoTest.java

I tried converting all ^M to \n in this file another repo and comparing with your patch but every line was different so I just can't review this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896162028

From qxing at openjdk.org  Tue Dec 24 03:26:23 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:23 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>

> This patch fixes unmatched brackets in some source files.

Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:

 - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
 - Do not touch files in test.
 - Do not touch upstream data from CLDR.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22861/files
  - new: https://git.openjdk.org/jdk/pull/22861/files/540312c4..ec3e6aa5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=00-01

  Stats: 2235 lines in 19 files changed: 2 ins; 2211 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22861/head:pull/22861

PR: https://git.openjdk.org/jdk/pull/22861

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <qToKH3NIiVa0fL7Lyd8VoUIjdMf1kohn_JEMNJE5A4s=.1fd147f1-fe89-46f0-8ffa-57aeef5d2d24@github.com>

On Mon, 23 Dec 2024 18:57:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> doc/hotspot-unit-tests.html line 248:
> 
>> 246: so there is no need to have them in error messages. Asserts print only
>> 247: compared values, they do not print any of interim variables, e.g.
>> 248: <code>ASSERT_TRUE(val1 == val2 &amp;&amp; isFail(foo(8)) || i == 18)</code>
> 
> This file is generated from the .md file, and should not be edited directly.

Updated both `.md` and `.html` using `make update-build-docs` in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896332803

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <S-WFhl3OYtxnxMvPlMMI2tSqGzCrdVYDmB1oN7jL_lk=.0510eda6-8a48-4cba-8862-f2f229edbe46@github.com>
Message-ID: <4QfTqVdt_-vwDpQQAaeiElZLvHDDBabcyBtISbLrmPo=.7aa033a5-d09b-4193-9d2e-1336167a10ce@github.com>

On Mon, 23 Dec 2024 14:00:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> doc/hotspot-unit-tests.md line 175:
> 
>> 173: there is no need to have them in error messages. Asserts print only
>> 174: compared values, they do not print any of interim variables, e.g.
>> 175: `ASSERT_TRUE(val1 == val2 && isFail(foo(8)) || i == 18)` prints only
> 
> Looking at this expression, I believe the intention is this.
> Suggestion:
> 
> `ASSERT_TRUE((val1 == val2 && isFail(foo(8))) || i == 18)` prints only

Thanks for the suggestion, updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896331528

From qxing at openjdk.org  Tue Dec 24 03:26:24 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:26:24 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <Wvl3SUC6VY0yp14dgXMiXB9TaAJg6FncZSY51kjl5R8=.820767b6-bccb-4987-bbd2-7ae6a612da5a@github.com>
Message-ID: <rjeNtZS_8Tl4gLjpg0W0gwCSOIHIHcU0VfNB1_P9D1Y=.69d45611-fded-4d4d-96d5-89e33ab6addc@github.com>

On Mon, 23 Dec 2024 17:11:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> make/data/cldr/common/main/kn.xml line 1085:
> 
>> 1083: 			<type key="calendar" type="islamic">????????? ??????????</type>
>> 1084: 			<type key="calendar" type="islamic-civil">?????????-?????? ??????????</type>
>> 1085: 			<type key="calendar" type="islamic-rgsa" draft="contributed">?????????? ??????????? (???? ???????, ????????)</type>
> 
> Hi, we would not modify the contents of upstream data from CLDR.

Sorry, I've reverted these changes in the latest commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896331971

From qxing at openjdk.org  Tue Dec 24 03:32:36 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:32:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
Message-ID: <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>

On Mon, 23 Dec 2024 19:13:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>>  - Do not touch files in test.
>>  - Do not touch upstream data from CLDR.
>
> test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:
> 
>> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
>> 49:     $(TESTLIBRARY_DIR)/jtreg \
>> 50:     -maxdepth 1 -name '*.java')
> 
> I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
> close-paren?

I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.

I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.

> test/jaxp/javax/xml/jaxp/unittest/transform/Bug8169112.xsl line 65:
> 
>> 63:           @page { margin: 0.1in; }
>> 64: 
>> 65:           }
> 
> Does this affect the behavior of the test this is part of?

Reverted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896336118
PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896337303

From qxing at openjdk.org  Tue Dec 24 03:35:47 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Tue, 24 Dec 2024 03:35:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <rNpIv9ErIdEqWQqzp5xb0Pn0Wn1PGjxThYJAThp80Z4=.323068e8-70cc-476b-ad80-48ce14db92d7@github.com>
 <_AIqmu61ZK3rRO-44sivWfkuH1ceJm8bQ3MtL2cu8vs=.f4c3bb3b-3697-4ba4-8199-0f1cf9f2f047@github.com>
Message-ID: <bs7fuVeUaVtrunvJFhOMsam8pz9Oi43_cTdEk0c2Wsc=.276f1181-a283-4d29-b8b5-bbe45a4eccf6@github.com>

On Mon, 23 Dec 2024 22:16:01 GMT, Phil Race <prr at openjdk.org> wrote:

>> I was also wondering how this was tested.
>
> FYI, the way to test this is ..
> cd test/jdk
> jtreg sanity/client/SwingSet/src/TableDemoTest.java
> 
> I tried converting all ^M to \n in this file another repo and comparing with your patch but every line was different so I just can't review this.

For safety reasons I've restored this file as well as all the files in unit tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896338401

From erikj at openjdk.org  Tue Dec 24 14:57:36 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 24 Dec 2024 14:57:36 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <LWyDWVBvPHM-9HkpB7pI5vh4Ppr-pNufCTbqGlBEhBE=.9917b618-876d-4744-8d1f-f59b137984c8@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

I've reviewed doc/hotspot-unit-tests.* and the Makefile.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522037503

From liach at openjdk.org  Tue Dec 24 15:48:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Dec 2024 15:48:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <dlNpmJp8MDFrFYWDsN0BOkDNw5MOiJB1AoEx6VfQC5g=.794bdb89-b349-49a3-88aa-9f41dc5bfc23@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

Thanks for the ctw fix.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522077710

From liach at openjdk.org  Tue Dec 24 15:48:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 24 Dec 2024 15:48:38 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
Message-ID: <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>

On Tue, 24 Dec 2024 03:28:31 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> test/hotspot/jtreg/testlibrary/ctw/Makefile line 50:
>> 
>>> 48:     $(TESTLIBRARY_DIR)/jdk/test/lib/util \
>>> 49:     $(TESTLIBRARY_DIR)/jtreg \
>>> 50:     -maxdepth 1 -name '*.java')
>> 
>> I wonder why this hasn't caused problems and been found long ago?  Does make just drop that stray
>> close-paren?
>
> I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.
> 
> I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.

Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896838026

From stooke at openjdk.org  Tue Dec 24 16:21:19 2024
From: stooke at openjdk.org (Simon Tooke)
Date: Tue, 24 Dec 2024 16:21:19 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java failing on
 Windows with "Stack base not yet set for thread id"
Message-ID: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>

This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

-------------

Commit messages:
 - Merge branch 'pr_8346717' of https://github.com/stooke/jdk into pr_8346717
 - restore deleted function name
 - add ZGC run of SystemMapTest
 - fix test for unready thread on Windows

Changes: https://git.openjdk.org/jdk/pull/22870/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22870&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346717
  Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22870.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22870/head:pull/22870

PR: https://git.openjdk.org/jdk/pull/22870

From kbarrett at openjdk.org  Tue Dec 24 20:30:37 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 20:30:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
Message-ID: <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>

On Tue, 24 Dec 2024 15:45:24 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I've tested this by running `make`, and the previous Makefile reports an error like file `test/lib/jtreg/SkippedException.java)` not found. So this fix is necessary.
>> 
>> I also checked the git log, this change was introduced in https://github.com/openjdk/jdk/pull/22420, not that long ago.
>
> Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.

Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
fixing it in isolation, and backporting that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896952109

From kbarrett at openjdk.org  Tue Dec 24 22:25:41 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 22:25:41 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
 <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
Message-ID: <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>

On Tue, 24 Dec 2024 20:27:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hmm, apparently this is not run as part of tier 1-3, which I ran in my patch.  I wonder how this test is run.  And it means this patch needs to be backported to 24.
>
> Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
> fixing it in isolation, and backporting that.

The purpose of this Makefile seems to be to build ctw.jar. So far as I can tell, nothing in the JDK uses that jar,
or invokes that Makefile. There are some tests for the ctw component in hotspot/jtreg/testlibrary_tests/ctw. I
think if you ran tier4 testing that you would hit those. Or you could use `TEST=hotspot:hotspot_misc`, or
specify that directory.  But those tests don't appear to use that jar. So I think there isn't a test that touches
this Makefile.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1896981987

From kbarrett at openjdk.org  Tue Dec 24 22:36:47 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Dec 2024 22:36:47 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <2MNSzuaI99GRQMqD4tbU5VMfHjwfm3KzzTBySopxKJM=.af677925-5588-456c-86c0-7bb262c2cec2@github.com>
Message-ID: <5RJCjU8mibDWRUFIu_5QaivS78cZGFT1ECjS4_f2Z8E=.a8ff6fd5-cba0-40f5-b754-9bdb6f7e8d4b@github.com>

On Tue, 24 Dec 2024 03:26:23 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update `hotspot-unit-tests.md` and HTML (using Pandoc 2.19.2).
>  - Do not touch files in test.
>  - Do not touch upstream data from CLDR.

The fix for the ctw Makefile should not be included in this PR.  It's a bug, and needs
to be fixed separately and backported to 24 to fix the introduction there via the
backport of JDK-8334733 from 25 to 24, without dragging the rest of this back to 24.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522228423

From lmesnik at openjdk.org  Wed Dec 25 00:29:36 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Dec 2024 00:29:36 GMT
Subject: RFR: 8346717: serviceability/dcmd/vm/SystemDumpMapTest.java
 failing on Windows with "Stack base not yet set for thread id"
In-Reply-To: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
References: <6BFli19jNH8gxlcSp3sBqeldXnjnTlUqkibzSG6Rh4w=.9330f159-520e-4efd-b3db-bef2759b03f6@github.com>
Message-ID: <vVnDBpaQPPLgUr42_r3PhIstcOymm6wxlBADbPkLhWs=.671f5826-1a21-4cb6-9500-61357cf4b3ed@github.com>

On Mon, 23 Dec 2024 18:43:07 GMT, Simon Tooke <stooke at openjdk.org> wrote:

> This test fixes an issue with incomplete Windows threads not yet having a stack.  A test for a null stack_base is added to guard against the potential null dereference.  An additional test using ZGC is added to the jtreg SystemMapTest.

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/serviceability/dcmd/vm/SystemMapTest.java line 39:

> 37:  *          java.management
> 38:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
> 39:  * @run testng/othervm -XX:+UsePerfData -XX:+UseZGC SystemMapTest

No need to add separate testcase for ZGC. It is expected that  hotspot tests are usually executed to ensure that all functionality works with any GC.
If you want to add it to ensure that  regression testcase is always executed even no ZGC is set then please 
1) add
`* @requires vm.gc.Z`
So testcase is not executed if non-ZGC GC (Parallel/Serial etc) is set explicitly.
2) Add 
` * @bug 8346717`
3) Add id like
`* @test id=zgc`
to make testcase name clearer.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22870#pullrequestreview-2522246825
PR Review Comment: https://git.openjdk.org/jdk/pull/22870#discussion_r1897011178

From lmesnik at openjdk.org  Wed Dec 25 01:47:37 2024
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 25 Dec 2024 01:47:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v2]
In-Reply-To: <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <8pTor9oXFFHRouI1-vrAKdlTzPX9cHlU5s3RbqxBx34=.3b5db6b0-d8ee-4ac9-b29e-d3bbf21740d3@github.com>
 <ktubNHz_TCetvRrfrZyA2vZwT-fgByExGIWP4wz9y_8=.76156a02-8901-4ea3-9373-0a0ff8385b56@github.com>
 <StDuMPfHR9hLUHWhsyfBJFXCkQPVnhd5HDC95-61a1U=.850e539f-767e-49ba-ad06-81c0e9b8e140@github.com>
 <asOSxb9S_XZtKx7RIBj-VVYdhN4Qy95J65pO7CJXHKk=.032eeb6a-86c3-4be6-909a-35ebcd0223b7@github.com>
Message-ID: <7rkkA5WQNof4ipfVB0NnpXU1o_nHsPmW3rulRPp78ZU=.593fc62d-f6ae-4885-b6db-09822cfb45ef@github.com>

On Tue, 24 Dec 2024 22:22:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Only this small piece would be appropriate for backport to 24.  I suggest splitting this out into its own bug,
>> fixing it in isolation, and backporting that.
>
> The purpose of this Makefile seems to be to build ctw.jar. So far as I can tell, nothing in the JDK uses that jar,
> or invokes that Makefile. There are some tests for the ctw component in hotspot/jtreg/testlibrary_tests/ctw. I
> think if you ran tier4 testing that you would hit those. Or you could use `TEST=hotspot:hotspot_misc`, or
> specify that directory.  But those tests don't appear to use that jar. So I think there isn't a test that touches
> this Makefile.

This makefile is not used by jtreg tests. The ctw code is compiled with 
`@library /test/lib / /testlibrary/ctw/src`
so jtreg compiled the ctw library files itself.
This makefile might be used for standalone build if needed.
Thanks for fixing this!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22861#discussion_r1897036236

From qxing at openjdk.org  Wed Dec 25 02:34:16 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Wed, 25 Dec 2024 02:34:16 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
Message-ID: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>

> This patch fixes unmatched brackets in some source files.

Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:

  Revert fix in the CTW Makefile.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22861/files
  - new: https://git.openjdk.org/jdk/pull/22861/files/ec3e6aa5..7f85c5e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22861&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22861.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22861/head:pull/22861

PR: https://git.openjdk.org/jdk/pull/22861

From qxing at openjdk.org  Wed Dec 25 02:37:41 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Wed, 25 Dec 2024 02:37:41 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SKV4vB0onb6Vw2U8fySvy-mQVH2x82YqC2Ys9qO0nAY=.ec464613-4024-459d-855b-b5890ee96ed7@github.com>
 <o9cZHHS4iQ1l-qTxASqqtTQ6WMijrJ0ZDrPrOYSYzak=.e40da9cf-374f-44b0-ae3c-3f48b77f5df6@github.com>
Message-ID: <lfbJHjq8KIOjVlG1hsR_nMbCSJ98DVHO8psUkvciZ88=.afbd9575-ea1a-4a19-a483-999917c01510@github.com>

On Mon, 23 Dec 2024 19:42:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I strongly suggest avoiding omnibus changes like this when possible (which it
>> is here). Just because it's all about one "kind" of change doesn't make it a
>> cohesive change. This is touching many distinct areas of the JDK, and several
>> different languages as well. That makes it harder to review and to manage the
>> review, because it is large and affects a wide range of areas, so may need
>> many reviewers. And the whole thing might get stalled by discussion of one
>> piece.
>> 
>> There is also no mention of what testing has been done for this PR. Some of
>> the changes are in executable code, and need to be tested.
>> 
>> I think that all of the files in make/data/cldr/common are from the Unicode
>> Consortium, and should not be modified here.
>
>> That makes it harder to review and to manage the review, because it is large and affects a wide range of areas, so may need many reviewers.
> 
> And many of the appropriate reviewers might be unavailable for a while, since it's right before Christmas.

@kimbarrett @liach Thanks for your suggestions!

I've moved the fix for the CTW Makefile to a separate pull request: https://github.com/openjdk/jdk/pull/22878, please check it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2561558033

From kbarrett at openjdk.org  Wed Dec 25 04:57:39 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 25 Dec 2024 04:57:39 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <RqSpJLzAEPtdnM_px2zUHBK8OWqoSsBiQABho0fLUAY=.f409be95-8db4-4e5b-9337-313a7256461e@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522326924

From stuefe at openjdk.org  Wed Dec 25 07:08:39 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 25 Dec 2024 07:08:39 GMT
Subject: RFR: 8346714: [ASAN] compressedKlass.cpp reported applying
 non-zero offset to null pointer
In-Reply-To: <BEqn7gaZ8OnzfCfcupUxVXaXpF5FzN92veve_oSVwwc=.7ce7b6aa-f8af-4928-99c7-43b67fe58b6d@github.com>
References: <LW82Kdihxq7jVs_NQBsHCJrngE3gcCREEtjA7XW64ls=.63c82ab5-bcf3-43b8-bdad-639b94cb20a6@github.com>
 <oTWtaxRQadfCBH8-sAGfgiKDHOn62gM4nY0oFFCFFXE=.82fa41da-00f0-4809-b9c0-d687951ab996@github.com>
 <QbGSIIwC5U7Vph51KTd4lNQ18nEF1zYElzjLo8f2s4c=.f65ea12d-1638-49ea-aa1b-81575bef6f4d@github.com>
 <wGaz9c7dEs8PVa3rMUZdqiDHwh8dBJ--0aZS9i8Dm6s=.6f69e7b2-28ce-43d3-8acf-2979d47be793@github.com>
 <BEqn7gaZ8OnzfCfcupUxVXaXpF5FzN92veve_oSVwwc=.7ce7b6aa-f8af-4928-99c7-43b67fe58b6d@github.com>
Message-ID: <-AgBV5Nb2X7Xebl2-768-BqbqNd_hRSirjWO8nOpmLA=.b8b7780b-6164-4879-b095-3bb824cec81e@github.com>

On Sun, 22 Dec 2024 17:46:52 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> On 12\/23\/24 07\:26\, Thomas Stuefe wrote\:
>>> On Sun\, 22 Dec 2024 17\:46\:52 GMT\, Andrew Haley \<aph at openjdk\.org> wrote\:
>>> 
>>>>>> Thanks for fixing the issue\! This should work\. In general\, I still prefer using \`uintptr\_t\` because \`intptr\_t\` has undefined behavior on overflow\. Probably not in this case\, here\.
>>>>>
>>>>>
>>>>> \+1\. Also\, instead of casting manually\, please use p2u \(and if there is none\, we should add it like we have a p2i for intptr\_t\)\.
>>>>> I am somewhat unenthusiastic about changes like these\. We seem to add a lot of casting boilerplate to satisfy UBsan for the sake of cleanliness that only matters on special hardware that treats pointers differently from numeric\.
>>>>
>>>> True\, but we can very effectively make the compiler and the reader happy by using \`uintptr\_t\` for all of the arithmetic\. After all\, we are not using null\-based compressed pointers\, we are using zero\-based compressed pointers\, and the distinction is important\. \`uintptr\_t\` does not have null as a member\, it has zero\; conversely \`address\` does not have zero\, it has null\. Therefore\, when we are using zero\-based compressed pointers\, better to to use \`uintptr\_t\` for the arithmetic\.
>>> 
>>> Okay\, but this is just for the sake of the reader\, right\? Because a cast can be just as invalid as adding to NULL\.
>> 
>> I don\'t agree\.  Adding to NULL is explicitly UB\. C\+\+ doesn\'t have to generate
>> any code for it\.
>> 
>>> I worked on hardware that marked pointers as invalid if they resulted from an integer cast\. I assume that \"don\'t add to NULL\" warnings exist to preserve portability for these platforms\.
>> 
>> That\'s not so\. Current C\+\+ compilers can\, and some do\, correctly generate no code for anything following UB\.
>> 
>> If you were to convert a pointer to uintptr\_t\, discover that it fits in an int\, convert it to an int\, and
>> then convert it back to a pointer\, that is well\-defined C\+\+\, and must be executed\. You can even write a
>> pointer to a file\, read it back later\, and use that pointer\. And it must work\.
>> 
>>> My thought is\: since we cannot hope to achieve portability for these platforms anyway\, we might just as well allow adding to NULL\.
>> 
>> No\. That is UB\.
>> 
>>> Casting feels like just switching off these warnings\.
>> 
>> That\'s how it feels\, sure\, but you\'re moving from UB to implementation\-defined behaviour\.
>> The latter we can cope with\.
>> 
>>> Note that even if I convert the wh...
>
>> > Thanks for fixing the issue! This should work. In general, I still prefer using `uintptr_t` because `intptr_t` has undefined behavior on overflow. Probably not in this case, here.
>> 
>> +1. Also, instead of casting manually, please use p2u (and if there is none, we should add it like we have a p2i for intptr_t).
>> 
>> I am somewhat unenthusiastic about changes like these. We seem to add a lot of casting boilerplate to satisfy UBsan for the sake of cleanliness that only matters on special hardware that treats pointers differently from numeric.
> 
> True, but we can very effectively make the compiler and the reader happy by using `uintptr_t` for all of the arithmetic. After all, we are not using null-based compressed pointers, we are using zero-based compressed pointers, and the distinction is important. `uintptr_t` does not have null as a member, it has zero; conversely `address` does not have zero, it has null. Therefore, when we are using zero-based compressed pointers, better to to use `uintptr_t` for the arithmetic.

@theRealAph @TheRealMDoerr Thank you for your points! You have convinced me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22848#issuecomment-2561669624

From amitkumar at openjdk.org  Wed Dec 25 07:48:36 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 25 Dec 2024 07:48:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
Message-ID: <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>

On Fri, 20 Dec 2024 13:17:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore ACC in comment.

Hi @coleenp, 

This is breaking s390x build. Would you please added below patch :) 

[s390_port.patch](https://github.com/user-attachments/files/18244370/s390_port.patch)

-------------

Changes requested by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22246#pullrequestreview-2522399559

From mdoerr at openjdk.org  Wed Dec 25 15:46:07 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Dec 2024 15:46:07 GMT
Subject: RFR: 8344232: [PPC64] secondary_super_cache does not scale well: C1
 and interpreter
Message-ID: <mEwI1t5yhTCqbQxOzW_JeMXZZa8E6M2gJfLMwF_O5ts=.23cba3e9-c3c5-46b2-bba5-5445e53850ae@github.com>

PPC64 implementation of https://github.com/openjdk/jdk/commit/ead0116f2624e0e34529e47e4f509142d588b994. I have implemented a couple of rotate instructions.
C1 part is refactored such that the same code as before this patch is generated when `UseSecondarySupersTable` is disabled.
The first commit only implements `lookup_secondary_supers_table_var` and uses it in C2. The second commit makes the changes to use it in the interpreter, runtime and C1.

Performance difference can be observed when C2 is disabled (measured on Power10):


-XX:TieredStopAtLevel=1 -XX:-UseSecondarySupersTable:
SecondarySuperCacheHits.test  avgt   15  13.028 ? 0.005  ns/op
SecondarySuperCacheInterContention.test     avgt   15  417.746 ? 19.046  ns/op
SecondarySuperCacheInterContention.test:t1  avgt   15  417.852 ? 17.814  ns/op
SecondarySuperCacheInterContention.test:t2  avgt   15  417.641 ? 23.431  ns/op
SecondarySuperCacheIntraContention.test  avgt   15  340.995 ? 5.620  ns/op



-XX:TieredStopAtLevel=1 -XX:+UseSecondarySupersTable:
SecondarySuperCacheHits.test  avgt   15  14.539 ? 0.002  ns/op
SecondarySuperCacheInterContention.test     avgt   15  25.667 ? 0.576  ns/op
SecondarySuperCacheInterContention.test:t1  avgt   15  25.709 ? 0.655  ns/op
SecondarySuperCacheInterContention.test:t2  avgt   15  25.626 ? 0.820  ns/op
SecondarySuperCacheIntraContention.test  avgt   15  22.466 ? 1.554  ns/op


`SecondarySuperCacheHits` seems to be slightly slower, but `SecondarySuperCacheInterContention` and `SecondarySuperCacheIntraContention` are much faster (when C2 is disabled).

-------------

Commit messages:
 - Change interpreter, runtime and C1 to use lookup_secondary_supers_table_var.
 - 8344232: [PPC64] secondary_super_cache does not scale well: C1 and interpreter

Changes: https://git.openjdk.org/jdk/pull/22881/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22881&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344232
  Stats: 311 lines in 7 files changed: 256 ins; 7 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/22881.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22881/head:pull/22881

PR: https://git.openjdk.org/jdk/pull/22881

From mdoerr at openjdk.org  Wed Dec 25 16:31:35 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Dec 2024 16:31:35 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v2]
In-Reply-To: <T4gc8ddEsijIPlsS_tjsFzSIpGeXeBVxGKhx7ejU-uA=.1977d4f0-95fa-4bc4-a14d-a52e9934e38c@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <k_VnVwzrO8CgKWruRuNJMm1uvZsKK6Or898DGsHh3_M=.d94cc9e0-ef5e-406d-b5fd-6e140699fe4d@github.com>
 <7u51ceqCUvoClO7UvFk57s_pLil_wncOZAVRRuQexTE=.772835f1-1811-44e9-a969-3fe3f05c9de5@github.com>
 <T4gc8ddEsijIPlsS_tjsFzSIpGeXeBVxGKhx7ejU-uA=.1977d4f0-95fa-4bc4-a14d-a52e9934e38c@github.com>
Message-ID: <U9dvIXFJj4I-Tzl2u6qaZXU3KsiSAbsgumWRrTJUVzc=.e66c9353-507d-4dff-8b7b-8088b3af39df@github.com>

On Thu, 19 Dec 2024 20:27:28 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 691:
>> 
>>> 689: 
>>> 690:     // Skip if we don't have to unlock. (???is this right???)
>>> 691:     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.
>> 
>> Using `testbitdi` might make it more readable to non-experts.  It took me a while reading aix docs to realize that this platform numbers LSB as 63 and MSB/sign as 0.
>
> yes I like testbitdi better.  I found a sample in the templateInterpreterGenerator code.

Right, Bit 0 refers to the MSB on IBM platforms (not only AIX). Using `testbitdi` is also fine.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1897419817

From mdoerr at openjdk.org  Wed Dec 25 16:36:44 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Dec 2024 16:36:44 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <jkR_fgNOY6hnARzlm_hmtttV4XD8_ZTGkfTUqUJE65Q=.e74d7d52-fb6d-4774-abbb-0f09124c2ed8@github.com>
 <o7rFTTx6rqzDxqasad2RZUqD4sssbC1Uy4tTBcZUd_g=.11d7935b-165d-4b49-9be6-876a21f44aa9@github.com>
Message-ID: <a-vdtKR9hAh_fOS3EVjIT_pmb-3ZG2-mKAskG-9ufh0=.a101141b-12b8-4723-aa8d-d2aaf11b9cc3@github.com>

On Thu, 19 Dec 2024 12:54:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp line 690:
>> 
>>> 688:     push(state);
>>> 689: 
>>> 690:     // Skip if we don't have to unlock. (???is this right???)
>> 
>> The logic seems consistent with other platforms. Not sure what you are querying.
>
> It wasn't the logic.  When I went through I didn't know if this instruction needed fixing because we loaded an unsigned short instead of an int.  So I left myself a note to look at it again that you noticed and I didn't in my final walk through.  It seems right but maybe someone with ppc knowledge can answer this.
> 
> 
>     rldicl_(R0, Raccess_flags, 64-JVM_ACC_SYNCHRONIZED_BIT, 63); // Extract bit and compare to 0.

The instruction looks still correct. We are checking the same bit of the 64 bit register as before. (Using `testbitdi` would also work.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1897420985

From mdoerr at openjdk.org  Wed Dec 25 16:42:36 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Dec 2024 16:42:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
Message-ID: <RuiVOVzj252-iXUbhhY2PNiIHzQdxUCaBD6IRbxouI4=.df35fa01-1ce0-44e4-b6db-b4bc3476792f@github.com>

On Fri, 20 Dec 2024 13:17:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review this change that makes AccessFlags and modifier_flags u2 types and removes the last remnants of Hotspot adding internal access flags.  This change moves AccessFlags and modifier_flags in Klass to alignment gaps saving 16 bytes.  From pahole: so it's a bit better.
>> 
>> before:
>> 
>>         /* size: 216, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 194, holes: 3, sum holes: 18 */
>> 
>> 
>> after:
>> 
>>         /* size: 200, cachelines: 4, members: 25, static members: 17 */
>>         /* sum members: 188, holes: 4, sum holes: 12 */
>> 
>> 
>> We may eventually move the modifiers to java.lang.Class but that's WIP.
>> 
>> Tested with tier1-7 on oracle platforms.  Did test builds on other platforms (please try these changes ppc/arm32 and s390).  Also requires minor Graal changes.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore ACC in comment.

src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp line 149:

> 147:     // _access_flags must be a 16 bit value.
> 148:     assert(sizeof(AccessFlags) == 2, "wrong size");
> 149:     __ lha(R11_scratch1/*access_flags*/, method_(access_flags));

Using `lhz` would be more consistent. `lha` uses sign extend instead of zero extend. Feel free to clean this up if you want. Both instructions should work.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22246#discussion_r1897422214

From aph at openjdk.org  Wed Dec 25 22:37:38 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 25 Dec 2024 22:37:38 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>
Message-ID: <c8v9J0FfHZ9eLVi9pTeVgCFM3ZhGlVPPGADfUhM-7dY=.11de53cd-7507-4fd3-b1fa-4ea4ea4feef6@github.com>

On Wed, 25 Dec 2024 07:46:00 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> This is breaking s390x build. Would you please added below patch :)

Maybe `testbit_16` isn't the rbest name. Perhaps `testbit_ushort` is better?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2562014053

From amitkumar at openjdk.org  Thu Dec 26 04:12:36 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 26 Dec 2024 04:12:36 GMT
Subject: RFR: 8339113: AccessFlags can be u2 in metadata [v5]
In-Reply-To: <c8v9J0FfHZ9eLVi9pTeVgCFM3ZhGlVPPGADfUhM-7dY=.11de53cd-7507-4fd3-b1fa-4ea4ea4feef6@github.com>
References: <0esPcg-bCT6iGHTebf8WsmbokSuIYUUUe5okCARAX9k=.a86a14d3-8cef-46d5-9887-095ac02a1b6d@github.com>
 <XJ0mGIfj5w9HKUhic3f_h73-AKHyNNVMDpLV1Lw_6Yc=.84566b74-33e8-47a4-b0dc-9677a17288dd@github.com>
 <OGQGhuBDFdu2rqhtLGcyFnnnbjSTPs-ILttY8vg1xIA=.a5d10e41-f683-4af0-9a7b-9c941e4e9ff5@github.com>
 <c8v9J0FfHZ9eLVi9pTeVgCFM3ZhGlVPPGADfUhM-7dY=.11de53cd-7507-4fd3-b1fa-4ea4ea4feef6@github.com>
Message-ID: <GxGzV5ErM8HjQ7P9Y1Htbpv1HcdPs_1w2Jye8Ge4i-4=.0933e662-e346-48b2-af68-85e74fe7b512@github.com>

On Wed, 25 Dec 2024 22:35:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > This is breaking s390x build. Would you please added below patch :)
> 
> Maybe `testbit_16` isn't the rbest name. Perhaps `testbit_ushort` is better?

Sure, updated patch: 
[s390_port_updated.patch](https://github.com/user-attachments/files/18249438/s390_port_updated.patch)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2562134245

From alanb at openjdk.org  Thu Dec 26 07:30:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Dec 2024 07:30:42 GMT
Subject: RFR: 8346773: Fix unmatched brackets in source files [v3]
In-Reply-To: <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
Message-ID: <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>

On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

>> This patch fixes unmatched brackets in some source files.
>
> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert fix in the CTW Makefile.

The title on the JBS issue is a mis-leading as it's now about man pages, docs, and a comment. Looks okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22861#pullrequestreview-2522898115

From qxing at openjdk.org  Thu Dec 26 07:47:37 2024
From: qxing at openjdk.org (Qizheng Xing)
Date: Thu, 26 Dec 2024 07:47:37 GMT
Subject: RFR: 8346773: Fix unmatched brackets in some misc files [v3]
In-Reply-To: <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>
References: <Ahoe6wxmlEDW1RD4NxmCAXjJHguK_eWa7G_UCRjmdvc=.66cf0125-baef-4e4c-97dd-a411b45bbea2@github.com>
 <SCztXJSKpXnWls5xQGQa_WLe5lxq4DOr9qCSrVPqY40=.84c5d360-e022-4978-88a1-8c3c2348c2a9@github.com>
 <nGkMbWXiCS3ZkEzYl6snQ5uweExG-l8Y4nEf7YOb5lo=.c2a606ea-9c6c-40b0-a685-7871333abae6@github.com>
Message-ID: <IUYSixbdrVq_VN1BgMfj3kE9DJb17d4aQ6_eg1w_-7U=.1841076e-3ed7-432c-af9b-a38bd4c6e8e4@github.com>

On Thu, 26 Dec 2024 07:27:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Qizheng Xing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert fix in the CTW Makefile.
>
> The title on the JBS issue is a mis-leading as it's now about man pages, docs, and a comment. Looks okay.

@AlanBateman Thanks for the review! I updated the title of the JBS issue and this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22861#issuecomment-2562270247

From amitkumar at openjdk.org  Fri Dec 27 06:38:29 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 27 Dec 2024 06:38:29 GMT
Subject: RFR: 8346847: [s390x] minimal build failure
Message-ID: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>

While working on [JDK-8343884](https://bugs.openjdk.org/browse/JDK-8343884), I made sure that `OptoScheduling` remains disabled on s390x, but for that code was not guarded by C2-specific if-def (`COMPILER2`) . Which caused a build failure on minimal-vm (see JBS issue for log). This is trivial fix for that.

-------------

Commit messages:
 - move change to c2-specific guard

Changes: https://git.openjdk.org/jdk/pull/22887/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22887&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346847
  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22887.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22887/head:pull/22887

PR: https://git.openjdk.org/jdk/pull/22887

From stuefe at openjdk.org  Fri Dec 27 07:24:34 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 27 Dec 2024 07:24:34 GMT
Subject: RFR: 8346847: [s390x] minimal build failure
In-Reply-To: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>
References: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>
Message-ID: <hFME18dp2y9HFi4AIXhox6qS-HlNpiMDgmHgOQ-8pio=.aaf776fa-0512-4245-b081-d99406544c0c@github.com>

On Fri, 27 Dec 2024 06:32:49 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> While working on [JDK-8343884](https://bugs.openjdk.org/browse/JDK-8343884), I made sure that `OptoScheduling` remains disabled on s390x, but for that code was not guarded by C2-specific if-def (`COMPILER2`) . Which caused a build failure on minimal-vm (see JBS issue for log). This is trivial fix for that.

Good and trivial

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22887#pullrequestreview-2523766981

From amitkumar at openjdk.org  Fri Dec 27 07:31:34 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 27 Dec 2024 07:31:34 GMT
Subject: RFR: 8346847: [s390x] minimal build failure
In-Reply-To: <hFME18dp2y9HFi4AIXhox6qS-HlNpiMDgmHgOQ-8pio=.aaf776fa-0512-4245-b081-d99406544c0c@github.com>
References: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>
 <hFME18dp2y9HFi4AIXhox6qS-HlNpiMDgmHgOQ-8pio=.aaf776fa-0512-4245-b081-d99406544c0c@github.com>
Message-ID: <0kmctE41EnvDoY91bn54LMp1PTl-gdvRc4c0rFSyVko=.a26eba2e-4275-42c2-83e6-3e64df18de60@github.com>

On Fri, 27 Dec 2024 07:21:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Good and trivial

Thanks Thomas for approval. I will integrate it after GHA finishes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22887#issuecomment-2563410470

From amitkumar at openjdk.org  Fri Dec 27 10:08:45 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 27 Dec 2024 10:08:45 GMT
Subject: Integrated: 8346847: [s390x] minimal build failure
In-Reply-To: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>
References: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>
Message-ID: <tYzfuW2i1L9W_ZT3BzcBycOF2TR_QH1fgyhsMQFAvWc=.60a4589f-6052-4424-9e1a-ba82fa046ca1@github.com>

On Fri, 27 Dec 2024 06:32:49 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> While working on [JDK-8343884](https://bugs.openjdk.org/browse/JDK-8343884), I made sure that `OptoScheduling` remains disabled on s390x, but for that code was not guarded by C2-specific if-def (`COMPILER2`) . Which caused a build failure on minimal-vm (see JBS issue for log). This is trivial fix for that.

This pull request has now been integrated.

Changeset: 807f6f7f
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/807f6f7fb868240cba5ba117c7059216f69a53f9
Stats:     12 lines in 1 file changed: 6 ins; 6 del; 0 mod

8346847: [s390x] minimal build failure

Reviewed-by: stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/22887

From amitkumar at openjdk.org  Fri Dec 27 10:08:44 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Fri, 27 Dec 2024 10:08:44 GMT
Subject: RFR: 8346847: [s390x] minimal build failure
In-Reply-To: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>
References: <Dq-EhcxWDEi0utYr53CIzaiLlrttrRtgUwVUh9c6NKM=.76d05738-ce94-4198-aca0-6da434b3da49@github.com>
Message-ID: <l85FMsE5s8kkB4py52STQfU57o9gPg0Iism9yUvmfOA=.d52e467f-80fb-4218-bf38-00aa13eb082e@github.com>

On Fri, 27 Dec 2024 06:32:49 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> While working on [JDK-8343884](https://bugs.openjdk.org/browse/JDK-8343884), I made sure that `OptoScheduling` remains disabled on s390x, but for that code was not guarded by C2-specific if-def (`COMPILER2`) . Which caused a build failure on minimal-vm (see JBS issue for log). This is trivial fix for that.

GHA failure for mac/x64 is not related to this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22887#issuecomment-2563533455

From duke at openjdk.org  Fri Dec 27 18:20:41 2024
From: duke at openjdk.org (duke)
Date: Fri, 27 Dec 2024 18:20:41 GMT
Subject: Withdrawn: 8204681: Option to include timestamp in hprof filename
In-Reply-To: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
References: <ajRIs0-SLNjQnzlkdlwrZ33kyYeJntnwgaE1d3XUx_M=.4b1cb043-2ea6-47ab-bf8d-eabd4e35f5a2@github.com>
Message-ID: <M1y0s9LPKxMj2hUZ_uDWGmaYjRBUXXfUJWh-UQipE_w=.6eedc7ec-e0e5-4ef8-9054-cd6440a68a8c@github.com>

On Tue, 13 Aug 2024 15:07:17 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681) enabling support for timestamp expansion in filenames specified in `-XX:HeapDumpPath` using `%t`. 
> 
> As mentioned in this comments for this issue, this is somewhat related to [8334492](https://bugs.openjdk.org/browse/JDK-8334492) where we enabled support for `%p` for filenames specified in jcmd. 
> 
> With this patch, I propose: 
> - Expanding the utility function `Arguments::copy_expand_pid` to `Arguments::copy_expand_arguments` to deal with `%p` expansions for pid and `%t` expansions for timestamps. 
> - Leveraging the above utility function to enable argument expansion for both heap dump filenames and jcmd output commands. 
> - Though the linked JBS issue only relates to heap dumps generated in case of OOM, I think we can edit it to more broadly support filename expansion to support `%t` for jcmd as well. 
> 
> Testing: 
> - [x] Added test cases pass with all platforms (verified with a GHA job). 
> - [x] Tier 1 passes with GHA. 
> 
> Looking forward to hearing your thoughts!
> 
> Thanks, 
> Sonia

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20568

From kbarrett at openjdk.org  Sun Dec 29 08:16:50 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 29 Dec 2024 08:16:50 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
Message-ID: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>

Please review this change to how HotSpot prevents the use of certain C library
functions (e.g. poisons references to those functions), while permitting a
subset to be used in restricted circumstances.  Reasons for poisoning a
function include it being considered obsolete, or a security concern, or there
is a HotSpot function (typically in the os:: namespace) providing similar
functionality that should be used instead.

The old mechanism, based on -Wattribute-warning and the associated attribute,
only worked for gcc.  (Clang's implementation differs in an important way from
gcc, which is the subject of a clang bug that has been open for years.  MSVC
doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
gcc bug.

The new mechanism is based on deprecation warnings, using [[deprecated]]
attributes. We redeclare or forward declare the functions we want to prevent
use of as being deprecated.  This relies on deprecation warnings being
enabled, which they already are in our build configuration.  All of our
supported compilers support the [[deprecated]] attribute.

Another benefit of using deprecation warnings rather than warning attributes
is the time when the check is performed.  Warning attributes are checked only
if the function is referenced after all optimizations have been performed.
Deprecation is checked during initial semantic analysis.  That's better for
our purposes here.  (This is also part of why gcc LTO has problems with the
old mechanism, but not the new.)

Adding these redeclarations or forward declarations isn't as simple as
expected, due to differences between the various compilers.  We hide the
differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
the compiler-specific parts of those macros for details.

In some situations we need to allow references to these poisoned functions.

One common case is where our poisoning is visible to some 3rd party code we
don't want to modify.  This is typically 3rd party headers included in HotSpot
code, such as from Google Test or the C++ Standard Library.  For these the
BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
where such references are permitted.

Some of the poisoned functions are needed to implement associated HotSpot os::
functions, or in other similarly restricted contexts.  For these, a wrapper
function is provided that calls the poisoned function with the warning
suppressed. These wrappers are defined in the permit_forbidden_functions
namespace, and called using the qualified name. This makes the use of these
functions stand out, suggesting they need careful scrutiny in code reviews and
the like.  There are several benefits to this approach vs the old
ALLOW_C_FUNCTION macro.  We can centralize the set of such functions.  The
syntax for use is simpler (there were syntactic bugs with the old mechanism
that weren't always noticed for a while). The permitted reference is explicit;
there can't be an ALLOW_C_FUNCTION use that isn't actually needed.

Testing:
mach5 tier1-3, which includes various build variants such as slowdebug.
GHA sanity tests
Manual testing for warnings for direct calls to poisoned functions with all 3
compilers, and that the error messages look sane and helpful.

gcc:

<file/containing/reference>: In function 'void test_exit(int)':
<file/containing/reference>:<line>:<column>: error: 'void exit(int)' is deprecated: use os::exit [-Werror=deprecated-declarations]
   32 | void test_exit(int status) { return exit(status); }
      |                                     ~~~~^~~~~~~~

... and more stuff about the declaration ... 


clang:

<file/containing/reference>:<line>:<column>: error: 'exit' is deprecated: use os::exit [-Werror,-Wdeprecated-declarations]
void test_exit(int status) { return exit(status); }
                                    ^

... and more stuff about the declaration ... 

Visual Studio:

<file/containing/reference>(<line>): warning C4996: 'exit': use os::exit

-------------

Commit messages:
 - new poisoning

Changes: https://git.openjdk.org/jdk/pull/22890/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22890&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8313396
  Stats: 713 lines in 35 files changed: 553 ins; 71 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/22890.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22890/head:pull/22890

PR: https://git.openjdk.org/jdk/pull/22890

From kim.barrett at oracle.com  Sun Dec 29 08:17:43 2024
From: kim.barrett at oracle.com (Kim Barrett)
Date: Sun, 29 Dec 2024 03:17:43 -0500
Subject: Poisoning in HotSpot
In-Reply-To: <aae37bc2-6a48-4e48-b1e3-910995254a42@oracle.com>
References: <CAP2b4GNUdxqnYvVLD9Mqb6-rKrwaJfvy8V_pGY1X8oVp_P0e_w@mail.gmail.com>
 <7cb918b4-4ee7-4c2f-9ab8-036325dc43b4@oracle.com>
 <CAP2b4GP5-jPyDRtXx04_sdL0rTwXZyUNipvAB-eZ2ivHcHn4VA@mail.gmail.com>
 <c38cb3a4-ac2e-4114-94fa-1f59e0e84bd5@oracle.com>
 <CAP2b4GMVg=Dj4KMWD234fuN07S=urxWDu+pYLHh-GCZ+TMYg9g@mail.gmail.com>
 <105ec0e9-ef09-4a6c-9cfc-76da9f260e73@oracle.com>
 <CAP2b4GP-O3MPXJgCbeQYtb6mjhqvr5BxFwJB6ZaDf=27NSaHkg@mail.gmail.com>
 <1915b20b-4a7d-43bd-b71b-045dcec4be4e@oracle.com>
 <e6474fe1-8f0d-494f-b06b-31d816f26c86@oracle.com>
 <bbc1d875-0a34-4789-b96b-e5fe14cc6b6a@oracle.com>
 <337d3e32-57c0-45b7-81bb-6ce6f8174ad2@oracle.com>
 <048a76f8-38b5-454e-b427-5bdadeae702d@oracle.com>
 <aae37bc2-6a48-4e48-b1e3-910995254a42@oracle.com>
Message-ID: <f70b2654-dd1d-4542-81d4-55345896a5f7@oracle.com>

On 12/9/24 7:56 PM, Kim Barrett wrote:
> I think I've figured out how to get the "add deprecation attributes" 
> approach
> to work with all three compilers.? [...]
>
> I've done a bit of prototyping in this direction, and I think I've 
> come up
> with a pretty good approach.? It's not completely bullet-proof, but 
> neither is
> the current mechanism, nor the namespace manipulation mechanism. But I 
> think
> this 3rd approach has better usage features and is easier to 
> maintain.? I'll
> describe it in more detail once I've got something more fully worked out.

https://github.com/openjdk/jdk/pull/22890



From jwaters at openjdk.org  Sun Dec 29 08:36:39 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 29 Dec 2024 08:36:39 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <DzUf4j7WrT-9hSZLXH_kj4DDYKSiouiVRdfQ_RZ06r0=.73754b85-d824-4e31-a5ef-546b3e8e52b8@github.com>

On Sun, 29 Dec 2024 08:11:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

src/hotspot/os/windows/permitForbiddenFunctions_windows.hpp line 41:

> 39:   return ::_fullpath(absPath, relPath, maxLength);
> 40: }
> 41: 

Could we forbid the non Standard _snprintf too?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899086776

From jwaters at openjdk.org  Sun Dec 29 08:42:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 29 Dec 2024 08:42:42 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <ghQDCOpSGZzsvX6aiTFwQ3HmqPpM7Qk51YSEDdX-hp0=.d78f09e9-274a-4cc2-9c30-ccc975b67e04@github.com>

On Sun, 29 Dec 2024 08:11:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 85:

> 83: #ifdef __clang__
> 84: #define FORBID_NORETURN_C_FUNCTION(Signature, Alternative) \
> 85:   FORBID_C_FUNCTION(__attribute__((__noreturn__)) Signature, Alternative)

clang isn't the only one that makes a distinction between [[gnu::noreturn]] and [[noreturn]], gcc does too. It's a little strange that gcc doesn't face this same issue

src/hotspot/share/utilities/permitForbiddenFunctions.hpp line 48:

> 46: // for one reason or another.
> 47: 
> 48: namespace permit_forbidden_functions {

permit_forbidden_functions sounds like a bit of a mouthful, maybe permit or permitted could work better in this case? If a call to free is to be permitted for example, permit::free(ptr) or permitted::free(ptr) sounds like "permit free", which conveys the intent pretty well, at least in my opinion

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899087414
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899087106

From jwaters at openjdk.org  Sun Dec 29 08:47:34 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 29 Dec 2024 08:47:34 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <I0CuLSOUMzTQRl_AFVhInYXZyHDi6ncxyF34Fic13a4=.645b9423-ebb8-464b-9c0f-6f2f9610b971@github.com>

On Sun, 29 Dec 2024 08:11:07 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Overall nice change, my only complaint is that to know which FORBID macro to use (IMPORTED, NORETURN, etc), you have to delve into implementation details to select the right one. That quickly becomes confusing. But unfortunately all the other approaches thus far have failed, so there aren't really any alternatives that are any better than this approach

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2564655329

From kbarrett at openjdk.org  Sun Dec 29 11:13:41 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 29 Dec 2024 11:13:41 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <DzUf4j7WrT-9hSZLXH_kj4DDYKSiouiVRdfQ_RZ06r0=.73754b85-d824-4e31-a5ef-546b3e8e52b8@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <DzUf4j7WrT-9hSZLXH_kj4DDYKSiouiVRdfQ_RZ06r0=.73754b85-d824-4e31-a5ef-546b3e8e52b8@github.com>
Message-ID: <raT3lA3051OdfgHhHbENQQPgWId-gcsBdwtgepZu8xg=.dfafc5df-3013-4f00-8299-67c204f05582@github.com>

On Sun, 29 Dec 2024 08:34:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> src/hotspot/os/windows/permitForbiddenFunctions_windows.hpp line 41:
> 
>> 39:   return ::_fullpath(absPath, relPath, maxLength);
>> 40: }
>> 41: 
> 
> Could we forbid the non Standard _snprintf too?

Sure, I'll add that.  We should also technically be forbidding snprintf in favor of os::snprintf, but the difference
is pretty minuscule and there are a significant number of occurrences (125 today).

> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 85:
> 
>> 83: #ifdef __clang__
>> 84: #define FORBID_NORETURN_C_FUNCTION(Signature, Alternative) \
>> 85:   FORBID_C_FUNCTION(__attribute__((__noreturn__)) Signature, Alternative)
> 
> clang isn't the only one that makes a distinction between [[gnu::noreturn]] and [[noreturn]], gcc does too. It's a little strange that gcc doesn't face this same issue

I don't know what `[[gnu::noreturn]]` has to do with this?  And in what way does gcc treat them differently?

> src/hotspot/share/utilities/permitForbiddenFunctions.hpp line 48:
> 
>> 46: // for one reason or another.
>> 47: 
>> 48: namespace permit_forbidden_functions {
> 
> permit_forbidden_functions sounds like a bit of a mouthful, maybe permit or permitted could work better in this case? If a call to free is to be permitted for example, permit::free(ptr) or permitted::free(ptr) sounds like "permit free", which conveys the intent pretty well, at least in my opinion

It is intentionally a mouthful.  It's not intended to be used except in pretty rare situations, and it should stand
out as unusual and needing additional scrutiny by readers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899110603
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899109858
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899110095

From kbarrett at openjdk.org  Sun Dec 29 11:27:34 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 29 Dec 2024 11:27:34 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <I0CuLSOUMzTQRl_AFVhInYXZyHDi6ncxyF34Fic13a4=.645b9423-ebb8-464b-9c0f-6f2f9610b971@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <I0CuLSOUMzTQRl_AFVhInYXZyHDi6ncxyF34Fic13a4=.645b9423-ebb8-464b-9c0f-6f2f9610b971@github.com>
Message-ID: <Yo-L4IsxcqdGC9EBJTZyRag4vQs5QtJIt4BPo6zlyp0=.347940cb-c962-4b8f-9617-e4d37b69dd20@github.com>

On Sun, 29 Dec 2024 08:45:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Overall nice change, my only complaint is that to know which FORBID macro to use (IMPORTED, NORETURN, etc), you have to delve into implementation details to select the right one. That quickly becomes confusing. But unfortunately all the other approaches thus far have failed, so there aren't really any alternatives that are any better than this approach

Unfortunately, I couldn't find any way to determine whether IMPORTED or not
other than trial and error.  One would think this might be documented
somewhere, but I didn't find anything.

Whether to use a NORETURN variant seems pretty straightforward.  It would be
better if we could just say (for example)

FORBID_C_FUNCTION([[noreturn]] void exit(int), "use os::exit")

But that doesn't work both because of the clang weirdness, and because all
attributes must preceed the Windows dllimport spec.

We'll have to come up with something new if we ever want to forbid a function
that has other attributes that we need to mention. I'm hoping that won't
happen, but I haven't (yet) gone through any secure coding guidelines looking
for additional functions to forbid.

One option would be to have distinct arguments for the signature, like we do
for JNI/JVM entry points, e.g.

FORBID_C_FUNCTION(char*, strerror, (int))

with attributes at the end or something like that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22890#issuecomment-2564692959

From aph-open at littlepinkcloud.com  Sun Dec 29 12:15:48 2024
From: aph-open at littlepinkcloud.com (Andrew Haley)
Date: Sun, 29 Dec 2024 12:15:48 +0000
Subject: The Cost of Profiling in the HotSpot Virtual Machine
Message-ID: <6a4681bb-4ea6-4ca6-9dcf-0edb11827664@littlepinkcloud.com>

Has anyone here seen an open-access copy of this? It seems to be the only paper
in the proceedings that is not open. Usually one of the authors of a paper will
publish a copy on their own web page, but not this time.

https://dl.acm.org/doi/10.1145/3679007.3685055

Thanks,

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From jwaters at openjdk.org  Mon Dec 30 05:29:36 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 30 Dec 2024 05:29:36 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <raT3lA3051OdfgHhHbENQQPgWId-gcsBdwtgepZu8xg=.dfafc5df-3013-4f00-8299-67c204f05582@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <DzUf4j7WrT-9hSZLXH_kj4DDYKSiouiVRdfQ_RZ06r0=.73754b85-d824-4e31-a5ef-546b3e8e52b8@github.com>
 <raT3lA3051OdfgHhHbENQQPgWId-gcsBdwtgepZu8xg=.dfafc5df-3013-4f00-8299-67c204f05582@github.com>
Message-ID: <YdA6P4TPe7qIAYrfDWfKicOpHeuaSEUro-61ciELv0A=.821c0d75-d29d-4e86-a44e-ba1a8caa8b6d@github.com>

On Sun, 29 Dec 2024 11:06:43 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/utilities/compilerWarnings_gcc.hpp line 85:
>> 
>>> 83: #ifdef __clang__
>>> 84: #define FORBID_NORETURN_C_FUNCTION(Signature, Alternative) \
>>> 85:   FORBID_C_FUNCTION(__attribute__((__noreturn__)) Signature, Alternative)
>> 
>> clang isn't the only one that makes a distinction between [[gnu::noreturn]] and [[noreturn]], gcc does too. It's a little strange that gcc doesn't face this same issue
>
> I don't know what `[[gnu::noreturn]]` has to do with this?  And in what way does gcc treat them differently?

[[gnu::noreturn]] is equal to __attribute__((noreturn)), I just referred to it as its scoped attribute form to make it clear that I wasn't talking about the Standard noreturn. There is funnily enough no documentation on how gcc treats them differently, I only learnt that it does while reading through gcc's source code one day


/* We used to treat C++11 noreturn attribute as equivalent to GNU's,
	 but no longer: we have to be able to tell [[noreturn]] and
	 __attribute__((noreturn)) apart.
	 Similarly for C++14 deprecated attribute, we need to emit extra
	 diagnostics for [[deprecated]] compared to [[gnu::deprecated]].  */
      /* C++17 fallthrough attribute is equivalent to GNU's.  */

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899281479

From kbarrett at openjdk.org  Mon Dec 30 07:45:33 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 30 Dec 2024 07:45:33 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <YdA6P4TPe7qIAYrfDWfKicOpHeuaSEUro-61ciELv0A=.821c0d75-d29d-4e86-a44e-ba1a8caa8b6d@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <DzUf4j7WrT-9hSZLXH_kj4DDYKSiouiVRdfQ_RZ06r0=.73754b85-d824-4e31-a5ef-546b3e8e52b8@github.com>
 <raT3lA3051OdfgHhHbENQQPgWId-gcsBdwtgepZu8xg=.dfafc5df-3013-4f00-8299-67c204f05582@github.com>
 <YdA6P4TPe7qIAYrfDWfKicOpHeuaSEUro-61ciELv0A=.821c0d75-d29d-4e86-a44e-ba1a8caa8b6d@github.com>
Message-ID: <90pl1SEZdEQ37FQum1-ewJMAYErSfwz7B8ffWC5vZoE=.0eef2c5c-4067-4442-baf2-d51837b43ad3@github.com>

On Mon, 30 Dec 2024 05:26:36 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I don't know what `[[gnu::noreturn]]` has to do with this?  And in what way does gcc treat them differently?
>
> [[gnu::noreturn]] is equal to __attribute__((noreturn)), I just referred to it as its scoped attribute form to make it clear that I wasn't talking about the Standard noreturn. There is funnily enough no documentation on how gcc treats them differently, I only learnt that it does while reading through gcc's source code one day
> 
> 
> /* We used to treat C++11 noreturn attribute as equivalent to GNU's,
> 	 but no longer: we have to be able to tell [[noreturn]] and
> 	 __attribute__((noreturn)) apart.
> 	 Similarly for C++14 deprecated attribute, we need to emit extra
> 	 diagnostics for [[deprecated]] compared to [[gnu::deprecated]].  */
>       /* C++17 fallthrough attribute is equivalent to GNU's.  */

gcc does treat [[noreturn]] differently from [[gnu::noreturn]] /
attribute((noreturn)) when there is a preceding declaration that doesn't have
either kind of attribute.  Compile this:

void frob(int);
//__attribute__((__noreturn__)) void frob(int);
//[[gnu::noreturn]] void frob(int);
[[noreturn]] void frob(int);

and you'll get an error:

error: function 'void frob(int)' declared '[[noreturn]]' but its first declaration was not

But uncomment either of the gnu-specific attributes and the error goes away.

C++14 7.6.3 "Noreturn attribute" says "The first declaration of a function
shall specify the noreturn attribute if any declaration of that function
specifies the noreturn attribute."

So without the declarations with gcc-specific attributes it errors, and that's
fine. The gcc-specific attributes never complained in that situation, and
continue to not complain, for backward compatibility. But other than that
error checking difference, the gcc-specific attributes seem to be treated as
equivalent to the standard attribute.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899343321

From kbarrett at openjdk.org  Mon Dec 30 07:53:36 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 30 Dec 2024 07:53:36 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION
In-Reply-To: <90pl1SEZdEQ37FQum1-ewJMAYErSfwz7B8ffWC5vZoE=.0eef2c5c-4067-4442-baf2-d51837b43ad3@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <DzUf4j7WrT-9hSZLXH_kj4DDYKSiouiVRdfQ_RZ06r0=.73754b85-d824-4e31-a5ef-546b3e8e52b8@github.com>
 <raT3lA3051OdfgHhHbENQQPgWId-gcsBdwtgepZu8xg=.dfafc5df-3013-4f00-8299-67c204f05582@github.com>
 <YdA6P4TPe7qIAYrfDWfKicOpHeuaSEUro-61ciELv0A=.821c0d75-d29d-4e86-a44e-ba1a8caa8b6d@github.com>
 <90pl1SEZdEQ37FQum1-ewJMAYErSfwz7B8ffWC5vZoE=.0eef2c5c-4067-4442-baf2-d51837b43ad3@github.com>
Message-ID: <qr2vd-z4K0RrlnwARQNzhvVqM96qpysJaU8sDgn5AKY=.2d76d482-cf75-4e5a-8fb7-f5191c6fc2e9@github.com>

On Mon, 30 Dec 2024 07:43:01 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> [[gnu::noreturn]] is equal to __attribute__((noreturn)), I just referred to it as its scoped attribute form to make it clear that I wasn't talking about the Standard noreturn. There is funnily enough no documentation on how gcc treats them differently, I only learnt that it does while reading through gcc's source code one day
>> 
>> 
>> /* We used to treat C++11 noreturn attribute as equivalent to GNU's,
>> 	 but no longer: we have to be able to tell [[noreturn]] and
>> 	 __attribute__((noreturn)) apart.
>> 	 Similarly for C++14 deprecated attribute, we need to emit extra
>> 	 diagnostics for [[deprecated]] compared to [[gnu::deprecated]].  */
>>       /* C++17 fallthrough attribute is equivalent to GNU's.  */
>
> gcc does treat [[noreturn]] differently from [[gnu::noreturn]] /
> attribute((noreturn)) when there is a preceding declaration that doesn't have
> either kind of attribute.  Compile this:
> 
> void frob(int);
> //__attribute__((__noreturn__)) void frob(int);
> //[[gnu::noreturn]] void frob(int);
> [[noreturn]] void frob(int);
> 
> and you'll get an error:
> 
> error: function 'void frob(int)' declared '[[noreturn]]' but its first declaration was not
> 
> But uncomment either of the gnu-specific attributes and the error goes away.
> 
> C++14 7.6.3 "Noreturn attribute" says "The first declaration of a function
> shall specify the noreturn attribute if any declaration of that function
> specifies the noreturn attribute."
> 
> So without the declarations with gcc-specific attributes it errors, and that's
> fine. The gcc-specific attributes never complained in that situation, and
> continue to not complain, for backward compatibility. But other than that
> error checking difference, the gcc-specific attributes seem to be treated as
> equivalent to the standard attribute.

The difference between [[deprecated]] and [[gnu::deprecated]] is discussed here:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;f=gcc/cp/parser.cc;h=cd647514a539943ade6461efbf056a7c3f4305c6
TL;DR - [[gnu::deprecated]] is allowed in more places than [[deprecated]].

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899346761

From amitkumar at openjdk.org  Mon Dec 30 10:20:21 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 30 Dec 2024 10:20:21 GMT
Subject: [jdk24] RFR: 8346847: [s390x] minimal build failure
Message-ID: <tFpXyFXne1bYqAcsGxokk-jc4cMuDE0A0OQ11AZX1y0=.59a5ab84-2d27-46d5-8ad7-9d93a787f7f2@github.com>

Hi all,

This pull request contains a backport of commit [807f6f7f](https://github.com/openjdk/jdk/commit/807f6f7fb868240cba5ba117c7059216f69a53f9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Amit Kumar on 27 Dec 2024 and was reviewed by Thomas Stuefe.

Thanks!

-------------

Commit messages:
 - Backport 807f6f7fb868240cba5ba117c7059216f69a53f9

Changes: https://git.openjdk.org/jdk/pull/22895/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22895&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346847
  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22895.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22895/head:pull/22895

PR: https://git.openjdk.org/jdk/pull/22895

From clanger at openjdk.org  Mon Dec 30 10:26:41 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Mon, 30 Dec 2024 10:26:41 GMT
Subject: [jdk24] RFR: 8346847: [s390x] minimal build failure
In-Reply-To: <tFpXyFXne1bYqAcsGxokk-jc4cMuDE0A0OQ11AZX1y0=.59a5ab84-2d27-46d5-8ad7-9d93a787f7f2@github.com>
References: <tFpXyFXne1bYqAcsGxokk-jc4cMuDE0A0OQ11AZX1y0=.59a5ab84-2d27-46d5-8ad7-9d93a787f7f2@github.com>
Message-ID: <TzV-gVnHuSPgp5i7XHmlHKnlG1WaA1gbFgSS_pfmyjk=.d18aa8be-bd74-4242-bf22-b2838c3799b7@github.com>

On Mon, 30 Dec 2024 10:14:54 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [807f6f7f](https://github.com/openjdk/jdk/commit/807f6f7fb868240cba5ba117c7059216f69a53f9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Amit Kumar on 27 Dec 2024 and was reviewed by Thomas Stuefe.
> 
> Thanks!

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22895#pullrequestreview-2525420355

From fyang at openjdk.org  Tue Dec 31 02:25:42 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 31 Dec 2024 02:25:42 GMT
Subject: RFR: 8345289: RISC-V: enable some extensions with hwprobe
In-Reply-To: <rJpRTjpbmZC42i8_0RTy3Krkda1nfw2aKHl21RaPyrA=.21ac38e3-a5e6-411f-afb5-5b19bd7ccc9d@github.com>
References: <Hae4bvIjbFiDHzc-xtsdMfVNMuuPOSph3vE_51S65NU=.aeb1ee2e-28f0-409c-9525-2e3eaec88fd2@github.com>
 <rJpRTjpbmZC42i8_0RTy3Krkda1nfw2aKHl21RaPyrA=.21ac38e3-a5e6-411f-afb5-5b19bd7ccc9d@github.com>
Message-ID: <KI5wclVPAKJHGO_x0mtzak3Dt-ueGW3VdH-w3xUcbnU=.193fa87e-e897-4a12-bc96-1fe367394dc3@github.com>

On Tue, 3 Dec 2024 09:34:25 GMT, Hamlin Li <mli at openjdk.org> wrote:

>> Hi,
>> Can you help to review the patch?
>> Currently, some extensions are not enable automatically with hwprobe, this is to enable them with hwprobe result.
>> 
>> Thanks!
>> 
>> Tests running so far so good.
>
> I think you're right, I'll only check and enable zicboz in this pr.

Hi @Hamlin-Li

> I think you're right, I'll only check and enable zicboz in this pr.

Please update the PR title to reflect the latest change. And I have two comments here.
1. It would be nice if we have some JMH or benchmark tests to show the performance benefit.
2. Regarding the cache line size, we assume `CacheLineSize` is 64 bytes for now. But that doesn't seem safe.
    Starting from linux-6.7, we have `RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE` hwprobe to get the real size at JVM startup.
    For safety consideration, I prefer to get this cache-line size auto-detection resolved before this one.

Let me know what you think. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22474#issuecomment-2566078154

From kbarrett at openjdk.org  Tue Dec 31 06:23:43 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 31 Dec 2024 06:23:43 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v2]
In-Reply-To: <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>
Message-ID: <3cxwvvQ_z9o4uDtyqrxNB7-9_7v7_Ufz8iE61ZXPxl0=.a0f13fa3-64fa-4f13-9e5e-717e31c177b7@github.com>

On Wed, 18 Dec 2024 07:28:50 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
>> 
>> Here is the example explain the "dead code" elimination.
>> 
>> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
>> 
>> 
>>> cat demo.c 
>> int main() { char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> 0
>> 
>> 
>> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
>> 
>>> cat demo.c 
>> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>>> clang -O0 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>>> clang -O1 demo.c && ./a.out ; echo $?
>> Segmentation fault (core dumped)
>> 139
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update comment "Use volatile to prevent compiler from optimising away the store"

Changes requested by kbarrett (Reviewer).

src/hotspot/share/runtime/frame.cpp line 1166:

> 1164:   // simulate GC crash here to dump java thread in error report
> 1165:   if (CrashGCForDumpingJavaThread) {
> 1166:     volatile char *t = nullptr; // Use volatile to prevent compiler from optimising away the store

No, don't do this. We don't need more ways to force a crash. Use
VMError::controlled_crash instead. Note that this will require upgrading that
function to !PRODUCT rather than DEBUG_ONLY. (Don't forget "optimized"
builds.)

OTOH, based on the comment's description of what this is needed for, why not
just `guarantee(!CrashGCForDumpingJavaThread, "")` ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22757#pullrequestreview-2526195638
PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1899937409

From amitkumar at openjdk.org  Tue Dec 31 06:29:38 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 31 Dec 2024 06:29:38 GMT
Subject: [jdk24] RFR: 8346847: [s390x] minimal build failure
In-Reply-To: <tFpXyFXne1bYqAcsGxokk-jc4cMuDE0A0OQ11AZX1y0=.59a5ab84-2d27-46d5-8ad7-9d93a787f7f2@github.com>
References: <tFpXyFXne1bYqAcsGxokk-jc4cMuDE0A0OQ11AZX1y0=.59a5ab84-2d27-46d5-8ad7-9d93a787f7f2@github.com>
Message-ID: <MffV8B263A1GcBs8i7ICKyxJefhiMzQJZ1h1yB1RTCY=.395fa6e7-69d4-4941-b500-f9624d8bef57@github.com>

On Mon, 30 Dec 2024 10:14:54 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [807f6f7f](https://github.com/openjdk/jdk/commit/807f6f7fb868240cba5ba117c7059216f69a53f9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Amit Kumar on 27 Dec 2024 and was reviewed by Thomas Stuefe.
> 
> Thanks!

Thanks for approval Christoph :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22895#issuecomment-2566169643

From amitkumar at openjdk.org  Tue Dec 31 06:29:38 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 31 Dec 2024 06:29:38 GMT
Subject: [jdk24] Integrated: 8346847: [s390x] minimal build failure
In-Reply-To: <tFpXyFXne1bYqAcsGxokk-jc4cMuDE0A0OQ11AZX1y0=.59a5ab84-2d27-46d5-8ad7-9d93a787f7f2@github.com>
References: <tFpXyFXne1bYqAcsGxokk-jc4cMuDE0A0OQ11AZX1y0=.59a5ab84-2d27-46d5-8ad7-9d93a787f7f2@github.com>
Message-ID: <rql-_gOjpO3oErSgyw3066pHFNvGNkmwFGm7hgBfDHw=.bd466269-795e-4e77-8997-f16d4aa5fa69@github.com>

On Mon, 30 Dec 2024 10:14:54 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [807f6f7f](https://github.com/openjdk/jdk/commit/807f6f7fb868240cba5ba117c7059216f69a53f9) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Amit Kumar on 27 Dec 2024 and was reviewed by Thomas Stuefe.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 4254e99c
Author:    Amit Kumar <amitkumar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4254e99ce28f767ddf0f7f6803a45d68afd44859
Stats:     12 lines in 1 file changed: 6 ins; 6 del; 0 mod

8346847: [s390x] minimal build failure

Reviewed-by: clanger
Backport-of: 807f6f7fb868240cba5ba117c7059216f69a53f9

-------------

PR: https://git.openjdk.org/jdk/pull/22895

From kbarrett at openjdk.org  Tue Dec 31 06:42:43 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 31 Dec 2024 06:42:43 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
Message-ID: <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>

> Please review this change to how HotSpot prevents the use of certain C library
> functions (e.g. poisons references to those functions), while permitting a
> subset to be used in restricted circumstances.  Reasons for poisoning a
> function include it being considered obsolete, or a security concern, or there
> is a HotSpot function (typically in the os:: namespace) providing similar
> functionality that should be used instead.
> 
> The old mechanism, based on -Wattribute-warning and the associated attribute,
> only worked for gcc.  (Clang's implementation differs in an important way from
> gcc, which is the subject of a clang bug that has been open for years.  MSVC
> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
> gcc bug.
> 
> The new mechanism is based on deprecation warnings, using [[deprecated]]
> attributes. We redeclare or forward declare the functions we want to prevent
> use of as being deprecated.  This relies on deprecation warnings being
> enabled, which they already are in our build configuration.  All of our
> supported compilers support the [[deprecated]] attribute.
> 
> Another benefit of using deprecation warnings rather than warning attributes
> is the time when the check is performed.  Warning attributes are checked only
> if the function is referenced after all optimizations have been performed.
> Deprecation is checked during initial semantic analysis.  That's better for
> our purposes here.  (This is also part of why gcc LTO has problems with the
> old mechanism, but not the new.)
> 
> Adding these redeclarations or forward declarations isn't as simple as
> expected, due to differences between the various compilers.  We hide the
> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
> the compiler-specific parts of those macros for details.
> 
> In some situations we need to allow references to these poisoned functions.
> 
> One common case is where our poisoning is visible to some 3rd party code we
> don't want to modify.  This is typically 3rd party headers included in HotSpot
> code, such as from Google Test or the C++ Standard Library.  For these the
> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
> where such references are permitted.
> 
> Some of the poisoned functions are needed to implement associated HotSpot os::
> functions, or in other similarly restricted contexts.  For these, a wrapper
> function is provided that calls the poisoned function with the warning
> suppressed. These wrappers are defined in the permit_fo...

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  forbid windows _snprintf

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22890/files
  - new: https://git.openjdk.org/jdk/pull/22890/files/993d465b..e2a63247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22890&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22890&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22890.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22890/head:pull/22890

PR: https://git.openjdk.org/jdk/pull/22890

From kbarrett at openjdk.org  Tue Dec 31 06:42:44 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 31 Dec 2024 06:42:44 GMT
Subject: RFR: 8313396: Portable implementation of FORBID_C_FUNCTION and
 ALLOW_C_FUNCTION [v2]
In-Reply-To: <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
References: <QtP6qEPB5L8XKNK-7VmlRS4bbH_Z6RCUgTDGVHVtF8o=.0225df78-3574-4064-b69a-42827763c3bc@github.com>
 <voCMBd8p4tIXogAG3qq-A-mDl4A8v_q9GrhNU0Euhjc=.6268286b-4ff6-4a99-b153-590bf82dd1dd@github.com>
Message-ID: <cGc0nkpZ_EZCiFTXj_-4he-G3CDh2k3oSq3_6YKAEsM=.a2248ba5-f059-4e24-bc58-2c01d9427471@github.com>

On Tue, 31 Dec 2024 06:39:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to how HotSpot prevents the use of certain C library
>> functions (e.g. poisons references to those functions), while permitting a
>> subset to be used in restricted circumstances.  Reasons for poisoning a
>> function include it being considered obsolete, or a security concern, or there
>> is a HotSpot function (typically in the os:: namespace) providing similar
>> functionality that should be used instead.
>> 
>> The old mechanism, based on -Wattribute-warning and the associated attribute,
>> only worked for gcc.  (Clang's implementation differs in an important way from
>> gcc, which is the subject of a clang bug that has been open for years.  MSVC
>> doesn't provide a similar mechanism.)  It also had problems with LTO, due to a
>> gcc bug.
>> 
>> The new mechanism is based on deprecation warnings, using [[deprecated]]
>> attributes. We redeclare or forward declare the functions we want to prevent
>> use of as being deprecated.  This relies on deprecation warnings being
>> enabled, which they already are in our build configuration.  All of our
>> supported compilers support the [[deprecated]] attribute.
>> 
>> Another benefit of using deprecation warnings rather than warning attributes
>> is the time when the check is performed.  Warning attributes are checked only
>> if the function is referenced after all optimizations have been performed.
>> Deprecation is checked during initial semantic analysis.  That's better for
>> our purposes here.  (This is also part of why gcc LTO has problems with the
>> old mechanism, but not the new.)
>> 
>> Adding these redeclarations or forward declarations isn't as simple as
>> expected, due to differences between the various compilers.  We hide the
>> differences behind a set of macros, FORBID_C_FUNCTION and related macros.  See
>> the compiler-specific parts of those macros for details.
>> 
>> In some situations we need to allow references to these poisoned functions.
>> 
>> One common case is where our poisoning is visible to some 3rd party code we
>> don't want to modify.  This is typically 3rd party headers included in HotSpot
>> code, such as from Google Test or the C++ Standard Library.  For these the
>> BEGIN/END_ALLOW_FORBIDDEN_FUNCTIONS pair of macros are used demark the context
>> where such references are permitted.
>> 
>> Some of the poisoned functions are needed to implement associated HotSpot os::
>> functions, or in other similarly restricted contexts.  For these, a wrapper
>> function is provided that calls the poison...
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forbid windows _snprintf

src/hotspot/os/linux/mallocInfoDcmd.cpp line 40:

> 38:   char* buf;
> 39:   size_t size;
> 40:   FILE* stream = ::open_memstream(&buf, &size);

Note that open_memstream was never forbidden, so the ALLOW_C_FUNCTION was not needed.

src/hotspot/os/linux/mallocInfoDcmd.cpp line 48:

> 46:   int err = os::Linux::malloc_info(stream);
> 47:   if (err == 0) {
> 48:     fflush(stream);

Note that fflush was never forbidden, so the ALLOW_C_FUNCTION was not needed.

src/hotspot/os/linux/mallocInfoDcmd.cpp line 58:

> 56:     ShouldNotReachHere();
> 57:   }
> 58:   ::fclose(stream);

Note that fclose was never forbidden, so the ALLOW_C_FUNCTION was not needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899941063
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899941170
PR Review Comment: https://git.openjdk.org/jdk/pull/22890#discussion_r1899941297

From syan at openjdk.org  Tue Dec 31 10:22:24 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 31 Dec 2024 10:22:24 GMT
Subject: RFR: 8346193: Test runtime/ErrorHandling/TestDwarf.java fails
 build with clang17 [v3]
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <y4OldUJtaI-aQTnOLNtV8nkOyOf9qFj-wh1mWaUUPgI=.ad23b188-072a-4e6b-8da9-040f6810bae4@github.com>

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'openjdk:master' into jbs8346193
 - update comment "Use volatile to prevent compiler from optimising away the store"
 - 8346193: Test runtime/ErrorHandling/TestDwarf.java fails build with clang17

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22757/files
  - new: https://git.openjdk.org/jdk/pull/22757/files/caa26be4..1f5c1955

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22757&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22757&range=01-02

  Stats: 17346 lines in 466 files changed: 13217 ins; 2375 del; 1754 mod
  Patch: https://git.openjdk.org/jdk/pull/22757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22757/head:pull/22757

PR: https://git.openjdk.org/jdk/pull/22757

From syan at openjdk.org  Tue Dec 31 10:41:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 31 Dec 2024 10:41:23 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v4]
In-Reply-To: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
Message-ID: <NyBWsSdfXlu4YI_lYkuN-XU0wPP7VPhGY5IqBAPmQv8=.ac4e0727-2e27-4960-81a9-482a20b4410c@github.com>

> Hi all,
> Function `frame::oops_do_internal` in src/hotspot/share/runtime/frame.cpp assign value to a nullptr `char *t` and intended to cause jvm crash. But after the assignment the nullptr do not use anymore, so clang17 consider the `char *t` initialization and assignment is "dead code". This PR add `volatile` modifier to `char *t`, to make avoid clang do the "dead code" elimination. Risk is low.
> 
> Here is the example explain the "dead code" elimination.
> 
> 1. Without volatile modifier, clang will delete the "dead code" and cause no more Segmentation fault error by -O1.
> 
> 
>> cat demo.c 
> int main() { char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> 0
> 
> 
> 2. With volatile modifier, clang do not delete the "dead code" again and and the expected Segmentation fault occur by -O1.
> 
>> cat demo.c 
> int main() { volatile char *t = 0; *t = 'c'; return 0; }
>> clang -O0 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139
>> clang -O1 demo.c && ./a.out ; echo $?
> Segmentation fault (core dumped)
> 139

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  use guarantee(!CrashGCForDumpingJavaThread, "") to generate jvm crash

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22757/files
  - new: https://git.openjdk.org/jdk/pull/22757/files/1f5c1955..12515205

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22757&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22757&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22757.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22757/head:pull/22757

PR: https://git.openjdk.org/jdk/pull/22757

From kbarrett at openjdk.org  Tue Dec 31 10:41:23 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 31 Dec 2024 10:41:23 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v2]
In-Reply-To: <3cxwvvQ_z9o4uDtyqrxNB7-9_7v7_Ufz8iE61ZXPxl0=.a0f13fa3-64fa-4f13-9e5e-717e31c177b7@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>
 <3cxwvvQ_z9o4uDtyqrxNB7-9_7v7_Ufz8iE61ZXPxl0=.a0f13fa3-64fa-4f13-9e5e-717e31c177b7@github.com>
Message-ID: <YsA_I2Lriaap_xT_9yk921RCQv-OKXbeIVr016Li1aw=.5e7f057f-8bbc-47dc-9b96-dde8df9a0973@github.com>

On Tue, 31 Dec 2024 06:20:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update comment "Use volatile to prevent compiler from optimising away the store"
>
> src/hotspot/share/runtime/frame.cpp line 1166:
> 
>> 1164:   // simulate GC crash here to dump java thread in error report
>> 1165:   if (CrashGCForDumpingJavaThread) {
>> 1166:     volatile char *t = nullptr; // Use volatile to prevent compiler from optimising away the store
> 
> No, don't do this. We don't need more ways to force a crash. Use
> VMError::controlled_crash instead. Note that this will require upgrading that
> function to !PRODUCT rather than DEBUG_ONLY. (Don't forget "optimized"
> builds.)
> 
> OTOH, based on the comment's description of what this is needed for, why not
> just `guarantee(!CrashGCForDumpingJavaThread, "")` ?

Or do we really need to support this in "optimized" builds?  I'm not sure who uses this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900044614

From syan at openjdk.org  Tue Dec 31 10:43:35 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 31 Dec 2024 10:43:35 GMT
Subject: RFR: 8346193: CrashGCForDumpingJavaThread do not trigger expected
 crash build with clang17 [v2]
In-Reply-To: <YsA_I2Lriaap_xT_9yk921RCQv-OKXbeIVr016Li1aw=.5e7f057f-8bbc-47dc-9b96-dde8df9a0973@github.com>
References: <-OK-vdz5eg5LjC1kT0Rn_FRabFIY1mKzH9O4GOcv4fg=.ea9fd530-bbab-4b79-bc21-5e99ebdf448d@github.com>
 <1un8gWR4Ybo3CMB4xNWk2OI6IsJyeeukIyqhfR708z8=.aa45ffdc-baa7-406a-a284-040f72dcbdab@github.com>
 <3cxwvvQ_z9o4uDtyqrxNB7-9_7v7_Ufz8iE61ZXPxl0=.a0f13fa3-64fa-4f13-9e5e-717e31c177b7@github.com>
 <YsA_I2Lriaap_xT_9yk921RCQv-OKXbeIVr016Li1aw=.5e7f057f-8bbc-47dc-9b96-dde8df9a0973@github.com>
Message-ID: <WAMtcxIBp_Fi5EK_ZQbMjnIEUpriSdO5ZsHurJuTvWw=.c421321c-9141-4560-88c3-4b5b3cba03b9@github.com>

On Tue, 31 Dec 2024 10:38:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/runtime/frame.cpp line 1166:
>> 
>>> 1164:   // simulate GC crash here to dump java thread in error report
>>> 1165:   if (CrashGCForDumpingJavaThread) {
>>> 1166:     volatile char *t = nullptr; // Use volatile to prevent compiler from optimising away the store
>> 
>> No, don't do this. We don't need more ways to force a crash. Use
>> VMError::controlled_crash instead. Note that this will require upgrading that
>> function to !PRODUCT rather than DEBUG_ONLY. (Don't forget "optimized"
>> builds.)
>> 
>> OTOH, based on the comment's description of what this is needed for, why not
>> just `guarantee(!CrashGCForDumpingJavaThread, "")` ?
>
> Or do we really need to support this in "optimized" builds?  I'm not sure who uses this.

> OTOH, based on the comment's description of what this is needed for, why not just `guarantee(!CrashGCForDumpingJavaThread, "")` ?

Previously I am not quite sure that use `ShouldNotReachHere()` instead of `*t = 'c'` could break the original test intention or not. Use `guarantee(!CrashGCForDumpingJavaThread, "")` make the original test [check](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/ErrorHandling/TestDwarf.java#L103) success. So I think use `guarantee(!CrashGCForDumpingJavaThread, "")` will acceptable. The code has been changed. Thanks your advices.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22757#discussion_r1900045713