From coleenp at openjdk.java.net  Wed Sep  1 01:48:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 1 Sep 2021 01:48:06 GMT
Subject: RFR: 8273217: Make ParHeapInspectTask _safepoint_check_never
Message-ID: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>

Make lock be declared as safepoint_check_never.
Ran tier1-3 tests and test that uses this code: serviceability/dcmd/gc/ClassHistogramTest.java

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

Commit messages:
 - 8273217: Make ParHeapInspectTask _safepoint_check_never

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

PR: https://git.openjdk.java.net/jdk/pull/5323

From iklam at openjdk.java.net  Wed Sep  1 02:20:49 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 1 Sep 2021 02:20:49 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <_tB94xauligjxvtsYGChlrCKDhkcx67jJupp4uPxmoQ=.4fca1985-8bcf-4fed-9874-a48b098256e2@github.com>

On Mon, 30 Aug 2021 07:09:54 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
> 
> $java -Xlog:gc:gc.log -verbose:gc -version
> [0.003s][info][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.

https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html only mentions that `-verbose:gc` will be overridden by `-Xloggc:<filename>` (and  `-Xloggc:<filename>` has been replaced with `-Xlog:gc:file=<filename>`). It doesn't mention the other three `-verbose` options (class, module, jni). We need to discuss what (if anything) should be done for those three options.

src/hotspot/share/runtime/arguments.cpp line 2963:

> 2961:     if (ts->contains(LogTag::_gc) && ts->has_output_to_file()) {
> 2962:       has_verbose_gc = false;
> 2963:     }

What if the command-line is this?


java -Xlog:gc+heap=foo.txt -verbose:gc -version

src/hotspot/share/runtime/arguments.cpp line 2965:

> 2963:     }
> 2964:     if (ts->contains(LogTag::_class) && ts->has_output_to_file()) {
> 2965:       has_verbose_class = false;

This doesn't seem correct to me. If the command line is:


java -Xlog:class+resolve=debug:file=log.txt -verbose:class -version


We should have the following:


(a) class,load -> stdout
(b) class,unload -> stdout
(c) class,resolve -> log.txt


But your change will disable both (a) and (b).


Also, what is the proposed behavior with this?


java -Xlog:class+load:file=log.txt -verbose:class -version


Will we have [A]:


class,load -> log.txt
class,unload -> stdout


or [B]?


class,load -> log.txt
class,unload -> disabled

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From ioi.lam at oracle.com  Wed Sep  1 02:35:22 2021
From: ioi.lam at oracle.com (Ioi Lam)
Date: Tue, 31 Aug 2021 19:35:22 -0700
Subject: Why no hs-err file on CheckJNI?
In-Reply-To: <CAA-vtUwF14HFAiadQV0KBnP+UPBqeSHOWkOgJnKOjSXt+hSxWw@mail.gmail.com>
References: <CAA-vtUyJHCTbd=vWvNCOLnytkZtqFbT9az7OT0UQGhoC3zH-aA@mail.gmail.com>
 <260265ec-d19b-d208-fa8e-169df2dec647@oracle.com>
 <CAA-vtUx9GbwShybF+XABCSAhhbL9PyGJ12Mew4S-6wOOQUp68w@mail.gmail.com>
 <6f8de254-be71-6889-aeea-ed284523f0c1@oracle.com>
 <CAA-vtUwF14HFAiadQV0KBnP+UPBqeSHOWkOgJnKOjSXt+hSxWw@mail.gmail.com>
Message-ID: <53fbb6d8-433b-46cf-87ce-a0c9b08abc84@oracle.com>



On 8/25/21 9:32 PM, Thomas St?fe wrote:
> On Wed, Aug 25, 2021 at 9:28 AM David Holmes <david.holmes at oracle.com>
> wrote:
>
>> On 25/08/2021 4:04 pm, Thomas St?fe wrote:
>>> Hi David,
>>>
>>> thank you for looking at this. Answers below.
>>>
>>> On Tue, Aug 24, 2021 at 9:38 AM David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>>      Hi Thomas,
>>>
>>>      On 24/08/2021 12:27 am, Thomas St?fe wrote:
>>>       > Hi,
>>>       >
>>>       > when we specify CheckJNI or CheckJNICalls and we catch an error
>>>      (e.g. a
>>>       > memory overwriter), we write a short report, then abort. See:
>>>       >
>>>       >
>>>
>> https://github.com/openjdk/jdk/blob/594e5161b48382d61509b4969bc8f52c3c076452/src/hotspot/share/prims/jniCheck.hpp#L36-L41
>>>      <
>> https://github.com/openjdk/jdk/blob/594e5161b48382d61509b4969bc8f52c3c076452/src/hotspot/share/prims/jniCheck.hpp#L36-L41
>>>       >
>>>       > This has been introduced in 2008 with JDK-6739363 "Xcheck jni
>>>      doesn't check
>>>       > native function arguments". I could find no discussion about this
>> on
>>>       > mailing list archives.
>>>
>>>      There have been a number of updates to Xcheck:jni since then and in
>>>      17 I
>>>      documented the different kinds of checks and their behaviour in more
>>>      detail (JDK-8260194):
>>>
>>>
>> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
>>>      <
>> https://htmlpreview.github.io/?https://github.com/openjdk/jdk17/blob/4f336dd3985b654dc3fbacabdcfccf590ea918e5/java.html
>>>
>>>
>>> Nice and interesting. Does not mention buffer overruns though.
>> Do we detect buffer overruns? I looked at all the jniCheck functions to
>> see what things we checked for and thought I had found them all. :(
>>
>>>       > Does anyone know why we don't write a normal hs-err file in this
>>>      case?
>>>
>>>      Because the intent is to mimic throwing an exception and exiting and
>> it
>>>      is not a "hotspot error" it is an application error.
>>>
>>>       > Would anyone care if we did? We do so in similar cases, e.g. if
>>>      os::free()
>>>       > catches an overwrite.
>>>
>>>      os::free() is capturing an internal hotspot programming error, not an
>>>      error in user code.
>>>
>>>
>>> Is this mainly a support issue for you? Meaning, the existence of an
>>> hs-err file would indicate a hotspot error and third-party JNI errors
>>> erroneously assigned to the hotspot group's support queue? If so, I can
>>> understand that, though that separation has a lot of holes in practice
>>> (it's very easy to make the hotspot crash from third-party code).
>>>
>>> Technically, a hs-err file would be useful even if most of the hotspot
>>> internals are irrelevant for a JNI bug. The file contains a lot of
>>> valuable context.
>> I just don't think a "hotspot error file" is a reasonable or necessary
>> response to detecting a JNI error in application code. A stacktrace
>> should suffice for the vast majority of errors detected.
>>
>>>      You would need to rework the header error messages etc and remove the
>>>      bug reporting stuff so that the user doesn't think it is an error in
>>>      the
>>>      VM itself. Overall I don't see the need to do it as the main thing is
>>>      the stacktrace to see where the bad JNI usage occurred - and as I
>> said
>>>      this isn't a VM error.
>>>
>>>      It might also introduce compatibility issues for anyone who runs
>>>      testing
>>>      wiith -Xcheck:jni and doesn't expect to get the hs_err file - though
>> if
>>>      you keep the current output but also produce a modified hs_err file
>>>      that
>>>      may be okay. But I still question why you would need this?
>>>
>>>
>>> I am currently investigating a buffer overrun at a client caused in
>>> ReleaseByteArrayElements. A hs-err file would have been definitely
>> useful.
>>
>> I need more info on this case. If the overrun was detected when it
>> happened then I would hope a stacktrace would suffice to show the errant
>> code. And I'm not clear how a hs_err file would help. ??
>>
>>
> A hs-err file would give you context information beyond the stack, e.g. VM
> and program arguments, runtime, memory content at register/stack addresses
> (may contain the broken block) etc.
>
> A hs-err file is also a clear sign for a fatal error, while output to
> stderr may be accidentally ignored. It depends on how well versed your
> first level support and your customers are.
>
> But I don't like pressing this. I understand your reasons for not writing
> an hs-err file. We may change this downstream only, the patch would be
> really trivial.

What about a new option like -XX:+LogJNIChecks which writes a 
jni_check_log_<pid>.log file?

This way you get more information about the check, and it's clear that 
this is not a hotspot error.

Thanks

- Ioi

From dholmes at openjdk.java.net  Wed Sep  1 04:23:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 04:23:48 GMT
Subject: RFR: 8272970: Parallelize runtime/InvocationTests/
In-Reply-To: <dPVHiYGv1TvuGM-ctRMZW2cuXDat7vZ-0gm5g_Tu6l8=.9cb2b7eb-6887-4e48-89a2-5ced5dac3f1b@github.com>
References: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
 <dPVHiYGv1TvuGM-ctRMZW2cuXDat7vZ-0gm5g_Tu6l8=.9cb2b7eb-6887-4e48-89a2-5ced5dac3f1b@github.com>
Message-ID: <Jzo7MoIvZHB8ckqWGlTz-E16fbC9HsMneIx-QgD8Yec=.45ac5677-cb1f-4b8c-a89a-6b621779c554@github.com>

On Tue, 31 Aug 2021 21:29:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Current runtime/InvocationTests/ are long and serial. They take about half an hour on a modern desktop, mostly using a single CPU. They can be parallelized better, at least on sub-test level. This would be important as [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914) would start to run them in tier3.
>> 
>> Sample run times:
>> 
>> 
>> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=runtime/InvocationTests/
>> 
>> # Before
>> real	32m2.188s
>> user	59m12.818s
>> sys	0m45.612s
>> 
>> # After
>> real	17m21.110s
>> user	63m31.851s
>> sys	0m55.391s
>> 
>> 
>> I think we can technically go even deeper, for example parallelising by `packageSet` in the generators themselves, but that would be much more intrusive. I think 17 minutes is already quite good, given other tests running in prospective `hotspot:tier3`.
>
> LGTM. one nit: it should be possible to reduce clutter by removing `@compile` actions, could you please either do that here or file an RFE? 
> 
> PS I wish jtreg had a way not to duplicate all these tags, perhaps w/ some kind of a preprocessor.

@iignatev  At least some of the compile commands must remain. The top level test doesn't reference the actual test classes directly so must explicitly compile them. Any classes those directly reference do not need an explicit compile-command.

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

PR: https://git.openjdk.java.net/jdk/pull/5250

From iklam at openjdk.java.net  Wed Sep  1 04:37:46 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 1 Sep 2021 04:37:46 GMT
Subject: RFR: 8273104: Refactoring option parser for UL
In-Reply-To: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
Message-ID: <TEZicNe53jurhtrAHF2n1_DH5EpvI9Wspafi-jmx35M=.9de40fde-ce5a-4d08-bfa1-f8d2b50ac90d@github.com>

On Sun, 29 Aug 2021 03:48:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
> 
> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
> 
> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
> 
> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.

This refactoring looks good to me. Thanks for doing it.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5293

From dholmes at openjdk.java.net  Wed Sep  1 06:09:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 06:09:45 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <fOPA1Jv4hC6LH9NWgFnMaQ-UPFfQODTA8941S5Ls91Q=.ee288462-62de-4fd8-b5b3-242b99dc36ad@github.com>

On Mon, 30 Aug 2021 07:09:54 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
> 
> $java -Xlog:gc:gc.log -verbose:gc -version
> [0.003s][info][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.

I find it very unfortunate that it states that  `-verbose:gc` will be overridden by `-Xloggc:<filename>`  and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.
I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From dholmes at openjdk.java.net  Wed Sep  1 07:07:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 07:07:52 GMT
Subject: RFR: 8273217: Make ParHeapInspectTask _safepoint_check_never
In-Reply-To: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
References: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
Message-ID: <mICj5xjWiFaZBHgSSiyhnYKNissFraFYFTXJQXrYrIc=.1261e5dc-bea9-42c0-82c5-8d53588e9f7a@github.com>

On Wed, 1 Sep 2021 01:40:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make lock be declared as safepoint_check_never.
> Ran tier1-3 tests and test that uses this code: serviceability/dcmd/gc/ClassHistogramTest.java

Hi Coleen,

The main change is fine, but the other seems unnecessary - see comment below.

Thanks,
David

src/hotspot/share/memory/heapInspection.cpp line 564:

> 562:   missed_count = ric.missed_count();
> 563:   {
> 564:     MutexLocker x(&_mutex, Mutex::_no_safepoint_check_flag);

This change seems unnecessary - this lock is only taken by GC threads, or the VMThread (?), never a JavaThread, but this change makes it look like it is taken by a JavaThread that wants to avoid safepoint checks.

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

PR: https://git.openjdk.java.net/jdk/pull/5323

From dholmes at openjdk.java.net  Wed Sep  1 07:18:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 07:18:49 GMT
Subject: RFR: JDK-8273176: handle latest VS2019 in abstract_vm_version
In-Reply-To: <O-KrIvbdEtgg3ZSpLDnTcpn_hHid0u-CJIJKvKTkCGw=.d6197a74-2705-4969-8634-427252aa6831@github.com>
References: <O-KrIvbdEtgg3ZSpLDnTcpn_hHid0u-CJIJKvKTkCGw=.d6197a74-2705-4969-8634-427252aa6831@github.com>
Message-ID: <mpchi7V2Vigxro1tt5PKYjeufVEmRUPUg830GI8TS7Q=.6a26616e-c7e1-4fa9-8eb9-e9e2c0fbc707@github.com>

On Tue, 31 Aug 2021 13:09:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It handles latest  VS2019 versions  in abstract_vm_version, e.g. 16.10.
> See the _MSC_VER documentation at  https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-160
> 
> Thanks, Matthias

Looks fine and trivial.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5317

From github.com+39413832+weixlu at openjdk.java.net  Wed Sep  1 07:36:48 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Wed, 1 Sep 2021 07:36:48 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <_tB94xauligjxvtsYGChlrCKDhkcx67jJupp4uPxmoQ=.4fca1985-8bcf-4fed-9874-a48b098256e2@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <_tB94xauligjxvtsYGChlrCKDhkcx67jJupp4uPxmoQ=.4fca1985-8bcf-4fed-9874-a48b098256e2@github.com>
Message-ID: <86ZzLccBTRSeiVntARn0Yr3zi2m7S2bgwTpToiSipSw=.504febe5-7c82-45a6-9ab3-ecf09cbaf546@github.com>

On Wed, 1 Sep 2021 02:03:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>> 
>> $java -Xloggc:gc.log -verbose:gc -version
>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>> [0.003s][info ][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
>> 
>> $java -Xlog:gc:gc.log -verbose:gc -version
>> [0.003s][info][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.
>
> src/hotspot/share/runtime/arguments.cpp line 2965:
> 
>> 2963:     }
>> 2964:     if (ts->contains(LogTag::_class) && ts->has_output_to_file()) {
>> 2965:       has_verbose_class = false;
> 
> This doesn't seem correct to me. If the command line is:
> 
> 
> java -Xlog:class+resolve=debug:file=log.txt -verbose:class -version
> 
> 
> We should have the following:
> 
> 
> (a) class,load -> stdout
> (b) class,unload -> stdout
> (c) class,resolve -> log.txt
> 
> 
> But your change will disable both (a) and (b).
> 
> 
> Also, what is the proposed behavior with this?
> 
> 
> java -Xlog:class+load:file=log.txt -verbose:class -version
> 
> 
> Will we have [A]:
> 
> 
> class,load -> log.txt
> class,unload -> stdout
> 
> 
> or [B]?
> 
> 
> class,load -> log.txt
> class,unload -> disabled

For your java command:

java -Xlog:class+load:file=log.txt -verbose:class -version

We will have [B] according to the current commit:

class,load -> log.txt
class,unload -> disabled

But I'm not sure whether this behavior is correct. The website (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html) doesn't give us explicit clue. It only says -verbose:class equals -Xlog:class+load=info,class+unload=info.
For the command above, maybe we can propose a third way [C]:

class,load -> log.txt and stdout
class,unload -> stdout

In addition, what if the command is:

java -Xlog:class+load=error,class+unload=info:log.txt -verbose:class -version

In this case, since ``class+load=error`` is ?weaker" than ``class+load=info``, maybe -verbose should not be overriden by -Xlog?
To make things simple, in my commit, as long as "class"  shows up, no matter it's ``-Xlog:class`` or ``-Xlog:class+resolve`` or ``-Xlog:class=debug``  , then ``-verbose:class`` is to be overiden. But I'm quite uncertain about whether it is correct. Looking forward to your suggestions.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Wed Sep  1 07:44:44 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Wed, 1 Sep 2021 07:44:44 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <_tB94xauligjxvtsYGChlrCKDhkcx67jJupp4uPxmoQ=.4fca1985-8bcf-4fed-9874-a48b098256e2@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <_tB94xauligjxvtsYGChlrCKDhkcx67jJupp4uPxmoQ=.4fca1985-8bcf-4fed-9874-a48b098256e2@github.com>
Message-ID: <GWUZgpE1QSB_IMeH2RPIWVeusPZiwtqqK1S70A7e7no=.4f056d95-4f3c-4319-92fb-6baf666d6194@github.com>

On Wed, 1 Sep 2021 02:14:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>> 
>> $java -Xloggc:gc.log -verbose:gc -version
>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>> [0.003s][info ][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
>> 
>> $java -Xlog:gc:gc.log -verbose:gc -version
>> [0.003s][info][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.
>
> src/hotspot/share/runtime/arguments.cpp line 2963:
> 
>> 2961:     if (ts->contains(LogTag::_gc) && ts->has_output_to_file()) {
>> 2962:       has_verbose_gc = false;
>> 2963:     }
> 
> What if the command-line is this?
> 
> 
> java -Xlog:gc+heap=foo.txt -verbose:gc -version

According to the current commit, we will have 

gc -> disabled
gc+heap ->foo.txt

But the same as the comment above, I'm not sure about its correctness. So maybe we should discuss what if the selections in Xlog is not the same as ``-Xlog:gc``.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Wed Sep  1 07:53:46 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Wed, 1 Sep 2021 07:53:46 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <fOPA1Jv4hC6LH9NWgFnMaQ-UPFfQODTA8941S5Ls91Q=.ee288462-62de-4fd8-b5b3-242b99dc36ad@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <fOPA1Jv4hC6LH9NWgFnMaQ-UPFfQODTA8941S5Ls91Q=.ee288462-62de-4fd8-b5b3-242b99dc36ad@github.com>
Message-ID: <Y29E_zaSmtlJJ63Nyb6coISNWVh4iB1LCICHo2qmcdI=.6e7feaa7-26a5-4617-bfb7-c13efa80027e@github.com>

On Wed, 1 Sep 2021 06:06:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I find it very unfortunate that it states that `-verbose:gc` will be overridden by `-Xloggc:<filename>` and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.

Things are quite easy if `-verbose:x` is treated as `-Xlog`. Multiple -Xlog arguments for the same output override each other in their given order, according to https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html.

> I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?

I have looked up some documents but unfortunately haven't found relevant statements.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From shade at openjdk.java.net  Wed Sep  1 08:01:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Sep 2021 08:01:20 GMT
Subject: RFR: 8272970: Parallelize runtime/InvocationTests/ [v2]
In-Reply-To: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
References: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
Message-ID: <_3hdfNIcBw_oQNsiCpOTt0CBkzYMO6OrP5XHtCSVHp0=.509392f8-66cc-44f7-9a2e-e324fb527620@github.com>

> Current runtime/InvocationTests/ are long and serial. They take about half an hour on a modern desktop, mostly using a single CPU. They can be parallelized better, at least on sub-test level. This would be important as [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914) would start to run them in tier3.
> 
> Sample run times:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=runtime/InvocationTests/
> 
> # Before
> real	32m2.188s
> user	59m12.818s
> sys	0m45.612s
> 
> # After
> real	17m21.110s
> user	63m31.851s
> sys	0m55.391s
> 
> 
> I think we can technically go even deeper, for example parallelising by `packageSet` in the generators themselves, but that would be much more intrusive. I think 17 minutes is already quite good, given other tests running in prospective `hotspot:tier3`.

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

 - Merge branch 'master' into JDK-8272970-parallel-invocation-tests
 - Trim down redundant compile tags
 - 8272970: Parallelize runtime/InvocationTests/

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5250/files
  - new: https://git.openjdk.java.net/jdk/pull/5250/files/3651efa3..f16b642d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5250&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5250&range=00-01

  Stats: 5444 lines in 222 files changed: 3928 ins; 730 del; 786 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5250.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5250/head:pull/5250

PR: https://git.openjdk.java.net/jdk/pull/5250

From shade at openjdk.java.net  Wed Sep  1 08:01:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 1 Sep 2021 08:01:22 GMT
Subject: RFR: 8272970: Parallelize runtime/InvocationTests/ [v2]
In-Reply-To: <dPVHiYGv1TvuGM-ctRMZW2cuXDat7vZ-0gm5g_Tu6l8=.9cb2b7eb-6887-4e48-89a2-5ced5dac3f1b@github.com>
References: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
 <dPVHiYGv1TvuGM-ctRMZW2cuXDat7vZ-0gm5g_Tu6l8=.9cb2b7eb-6887-4e48-89a2-5ced5dac3f1b@github.com>
Message-ID: <LEF3UJTzZVTerXoC5gyd_Yj2RF-NkixbnSZA68DXzGA=.35111472-4686-4902-a6fc-aecdb45794d3@github.com>

On Tue, 31 Aug 2021 21:29:25 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> LGTM. one nit: it should be possible to reduce clutter by removing `@compile` actions, could you please either do that here or file an RFE?

Right. The generators are referencing the `shared/` stuff implicitly, so we can drop `@compile` for them. Tests still pass without them. See new commit.

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

PR: https://git.openjdk.java.net/jdk/pull/5250

From mbaesken at openjdk.java.net  Wed Sep  1 08:02:53 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 1 Sep 2021 08:02:53 GMT
Subject: Integrated: JDK-8273176: handle latest VS2019 in abstract_vm_version
In-Reply-To: <O-KrIvbdEtgg3ZSpLDnTcpn_hHid0u-CJIJKvKTkCGw=.d6197a74-2705-4969-8634-427252aa6831@github.com>
References: <O-KrIvbdEtgg3ZSpLDnTcpn_hHid0u-CJIJKvKTkCGw=.d6197a74-2705-4969-8634-427252aa6831@github.com>
Message-ID: <_NuKXlDknzFOxOMxqUYOml0FW2l64Uy81P1aKTOHbD8=.0dcc1054-e5ae-4ad9-8f9a-8ba964538e27@github.com>

On Tue, 31 Aug 2021 13:09:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It handles latest  VS2019 versions  in abstract_vm_version, e.g. 16.10.
> See the _MSC_VER documentation at  https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-160
> 
> Thanks, Matthias

This pull request has now been integrated.

Changeset: 0e14bf70
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0e14bf70cf6e482a2ec7d13ed37df0bee911740d
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8273176: handle latest VS2019 in abstract_vm_version

Reviewed-by: kevinw, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5317

From lucy at openjdk.java.net  Wed Sep  1 09:30:52 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 1 Sep 2021 09:30:52 GMT
Subject: RFR: JDK-8273176: handle latest VS2019 in abstract_vm_version
In-Reply-To: <O-KrIvbdEtgg3ZSpLDnTcpn_hHid0u-CJIJKvKTkCGw=.d6197a74-2705-4969-8634-427252aa6831@github.com>
References: <O-KrIvbdEtgg3ZSpLDnTcpn_hHid0u-CJIJKvKTkCGw=.d6197a74-2705-4969-8634-427252aa6831@github.com>
Message-ID: <DtyiPKFt8_UMWf00hTlaGAJyLGYdmJqzniu7axdf9a8=.ce1d6b17-fbeb-47e2-be4a-41cd16eef328@github.com>

On Tue, 31 Aug 2021 13:09:26 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It handles latest  VS2019 versions  in abstract_vm_version, e.g. 16.10.
> See the _MSC_VER documentation at  https://docs.microsoft.com/en-us/cpp/preprocessor/predefined-macros?view=msvc-160
> 
> Thanks, Matthias

Looks good to me.
Thanks for adding support for the latest MSVC++.
Lutz

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

PR: https://git.openjdk.java.net/jdk/pull/5317

From dholmes at openjdk.java.net  Wed Sep  1 09:44:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 09:44:42 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <L_9A93oioPl63n8ov_q6ZcdiKv06_IOW2nmLsgAnWGM=.79482c94-5d01-45a8-ac9f-99a318ce5571@github.com>

On Mon, 30 Aug 2021 07:09:54 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
> 
> $java -Xlog:gc:gc.log -verbose:gc -version
> [0.003s][info][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.

There are no statements about how the other `-verbose:x` options interact with their `-Xlog:x` equivalents, but I was wondering how the implementation actually works?

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From dholmes at openjdk.java.net  Wed Sep  1 09:47:45 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 09:47:45 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <x1HXR2bi9A58bv7w4IicUcCVmChEja0LevOEkeTUjlU=.8baf5505-31ad-48a9-b417-394101736953@github.com>

On Mon, 30 Aug 2021 07:09:54 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
> 
> $java -Xlog:gc:gc.log -verbose:gc -version
> [0.003s][info][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.

I also can't see how to implement the "overrides" semantics without scanning the entire command-line to collate the different forms of the flag and then collapse them into a single appropriate `-Xlog` definition. And that would be a startup hit.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From dholmes at openjdk.java.net  Wed Sep  1 09:50:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 09:50:46 GMT
Subject: RFR: 8272970: Parallelize runtime/InvocationTests/ [v2]
In-Reply-To: <_3hdfNIcBw_oQNsiCpOTt0CBkzYMO6OrP5XHtCSVHp0=.509392f8-66cc-44f7-9a2e-e324fb527620@github.com>
References: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
 <_3hdfNIcBw_oQNsiCpOTt0CBkzYMO6OrP5XHtCSVHp0=.509392f8-66cc-44f7-9a2e-e324fb527620@github.com>
Message-ID: <UlmgEfUxvSaskuC3BlZdcXEwrfgppONLb6AdIT-lR2w=.4b153847-2c09-4ae8-9ebc-f9f0b76d7851@github.com>

On Wed, 1 Sep 2021 08:01:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current runtime/InvocationTests/ are long and serial. They take about half an hour on a modern desktop, mostly using a single CPU. They can be parallelized better, at least on sub-test level. This would be important as [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914) would start to run them in tier3.
>> 
>> Sample run times:
>> 
>> 
>> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=runtime/InvocationTests/
>> 
>> # Before
>> real	32m2.188s
>> user	59m12.818s
>> sys	0m45.612s
>> 
>> # After
>> real	17m21.110s
>> user	63m31.851s
>> sys	0m55.391s
>> 
>> 
>> I think we can technically go even deeper, for example parallelising by `packageSet` in the generators themselves, but that would be much more intrusive. I think 17 minutes is already quite good, given other tests running in prospective `hotspot:tier3`.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8272970-parallel-invocation-tests
>  - Trim down redundant compile tags
>  - 8272970: Parallelize runtime/InvocationTests/

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5250

From coleenp at openjdk.java.net  Wed Sep  1 11:35:45 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 1 Sep 2021 11:35:45 GMT
Subject: RFR: 8273217: Make ParHeapInspectTask _safepoint_check_never
In-Reply-To: <mICj5xjWiFaZBHgSSiyhnYKNissFraFYFTXJQXrYrIc=.1261e5dc-bea9-42c0-82c5-8d53588e9f7a@github.com>
References: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
 <mICj5xjWiFaZBHgSSiyhnYKNissFraFYFTXJQXrYrIc=.1261e5dc-bea9-42c0-82c5-8d53588e9f7a@github.com>
Message-ID: <7rkaVJuZkUaWaB-XoGqGNmUF_gbp1SC0UaSflZvbzSA=.e53c4264-ed83-4ba9-84c8-49c1c5beba01@github.com>

On Wed, 1 Sep 2021 06:28:36 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Make lock be declared as safepoint_check_never.
>> Ran tier1-3 tests and test that uses this code: serviceability/dcmd/gc/ClassHistogramTest.java
>
> src/hotspot/share/memory/heapInspection.cpp line 564:
> 
>> 562:   missed_count = ric.missed_count();
>> 563:   {
>> 564:     MutexLocker x(&_mutex, Mutex::_no_safepoint_check_flag);
> 
> This change seems unnecessary - this lock is only taken by GC threads, or the VMThread (?), never a JavaThread, but this change makes it look like it is taken by a JavaThread that wants to avoid safepoint checks.

This change is necessary in that we have a check inside Mutex::lock that this flag matches how the lock was defined.  It was argued that we want to have to pass this parameter to know when safepoints are not checked in the code that was taking out the lock, so the parameter is needed.

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

PR: https://git.openjdk.java.net/jdk/pull/5323

From david.holmes at oracle.com  Wed Sep  1 12:13:31 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 1 Sep 2021 22:13:31 +1000
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <86ZzLccBTRSeiVntARn0Yr3zi2m7S2bgwTpToiSipSw=.504febe5-7c82-45a6-9ab3-ecf09cbaf546@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <_tB94xauligjxvtsYGChlrCKDhkcx67jJupp4uPxmoQ=.4fca1985-8bcf-4fed-9874-a48b098256e2@github.com>
 <86ZzLccBTRSeiVntARn0Yr3zi2m7S2bgwTpToiSipSw=.504febe5-7c82-45a6-9ab3-ecf09cbaf546@github.com>
Message-ID: <132434ce-bf0e-cc8e-af49-6ba5c8eed141@oracle.com>

On 1/09/2021 5:36 pm, Xiaowei Lu wrote:
> On Wed, 1 Sep 2021 02:03:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:
> 
>>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>>>
>>> $java -Xloggc:gc.log -verbose:gc -version
>>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>>> [0.003s][info ][gc] Using G1
>>> $cat gc.log
>>> [0.003s][info][gc] Using G1
>>>
>>> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
>>>
>>> $java -Xlog:gc:gc.log -verbose:gc -version
>>> [0.003s][info][gc] Using G1
>>> $cat gc.log
>>> [0.003s][info][gc] Using G1
>>>
>>> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.
>>
>> src/hotspot/share/runtime/arguments.cpp line 2965:
>>
>>> 2963:     }
>>> 2964:     if (ts->contains(LogTag::_class) && ts->has_output_to_file()) {
>>> 2965:       has_verbose_class = false;
>>
>> This doesn't seem correct to me. If the command line is:
>>
>>
>> java -Xlog:class+resolve=debug:file=log.txt -verbose:class -version
>>
>>
>> We should have the following:
>>
>>
>> (a) class,load -> stdout
>> (b) class,unload -> stdout
>> (c) class,resolve -> log.txt
>>
>>
>> But your change will disable both (a) and (b).
>>
>>
>> Also, what is the proposed behavior with this?
>>
>>
>> java -Xlog:class+load:file=log.txt -verbose:class -version
>>
>>
>> Will we have [A]:
>>
>>
>> class,load -> log.txt
>> class,unload -> stdout
>>
>>
>> or [B]?
>>
>>
>> class,load -> log.txt
>> class,unload -> disabled
> 
> For your java command:
> 
> java -Xlog:class+load:file=log.txt -verbose:class -version
> 
> We will have [B] according to the current commit:
> 
> class,load -> log.txt
> class,unload -> disabled
> 
> But I'm not sure whether this behavior is correct. The website (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html) doesn't give us explicit clue. It only says -verbose:class equals -Xlog:class+load=info,class+unload=info.
> For the command above, maybe we can propose a third way [C]:
> 
> class,load -> log.txt and stdout
> class,unload -> stdout
> 
> In addition, what if the command is:
> 
> java -Xlog:class+load=error,class+unload=info:log.txt -verbose:class -version
> 
> In this case, since ``class+load=error`` is ?weaker" than ``class+load=info``, maybe -verbose should not be overriden by -Xlog?

There is no specification that states that -verbose:X is overridden by 
-Xlog:X except for GC. For the non-GC case the -verbose:X argument 
should be  processed in its -Xlog form and the full command-line 
processed as-if only -Xlog had been used. That is very clear and simple 
to implement.

The GC case is more problematic as per my other comment. There is no 
clear definition of what override means, but I would think that "ignore" 
would be appropriate. The main problem is that you have to scan the 
entire command-line to know what to do with the -verbose:gc.

David
-----

> To make things simple, in my commit, as long as "class"  shows up, no matter it's ``-Xlog:class`` or ``-Xlog:class+resolve`` or ``-Xlog:class=debug``  , then ``-verbose:class`` is to be overiden. But I'm quite uncertain about whether it is correct. Looking forward to your suggestions.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5295
> 

From dholmes at openjdk.java.net  Wed Sep  1 12:29:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 12:29:49 GMT
Subject: RFR: 8273217: Make ParHeapInspectTask _safepoint_check_never
In-Reply-To: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
References: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
Message-ID: <oXH8eq01i50vd6Bzfl2-7RVdZwDaolt7ar40w_zRvlE=.7722fe02-1f63-4e03-b001-ad3aacca4c2c@github.com>

On Wed, 1 Sep 2021 01:40:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make lock be declared as safepoint_check_never.
> Ran tier1-3 tests and test that uses this code: serviceability/dcmd/gc/ClassHistogramTest.java

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5323

From dholmes at openjdk.java.net  Wed Sep  1 12:29:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 1 Sep 2021 12:29:49 GMT
Subject: RFR: 8273217: Make ParHeapInspectTask _safepoint_check_never
In-Reply-To: <7rkaVJuZkUaWaB-XoGqGNmUF_gbp1SC0UaSflZvbzSA=.e53c4264-ed83-4ba9-84c8-49c1c5beba01@github.com>
References: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
 <mICj5xjWiFaZBHgSSiyhnYKNissFraFYFTXJQXrYrIc=.1261e5dc-bea9-42c0-82c5-8d53588e9f7a@github.com>
 <7rkaVJuZkUaWaB-XoGqGNmUF_gbp1SC0UaSflZvbzSA=.e53c4264-ed83-4ba9-84c8-49c1c5beba01@github.com>
Message-ID: <SIamWrGYHmwD4v5Bfe95tj_hAAi86bwTJEhtHUbcu1s=.52794587-8dc0-4bba-a90a-62a46ffbc0be@github.com>

On Wed, 1 Sep 2021 11:32:15 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/memory/heapInspection.cpp line 564:
>> 
>>> 562:   missed_count = ric.missed_count();
>>> 563:   {
>>> 564:     MutexLocker x(&_mutex, Mutex::_no_safepoint_check_flag);
>> 
>> This change seems unnecessary - this lock is only taken by GC threads, or the VMThread (?), never a JavaThread, but this change makes it look like it is taken by a JavaThread that wants to avoid safepoint checks.
>
> This change is necessary in that we have a check inside Mutex::lock that this flag matches how the lock was defined.  It was argued that we want to have to pass this parameter to know when safepoints are not checked in the code that was taking out the lock, so the parameter is needed.

I hadn't realized that we included a check for safepoint-check-never for the NJT case. I thought the safepoint-check state was completely ignored for NJTs.

I don't recall if in the past I agreed with doing this, but I think it is confusing and misleading to see this in the code. But so be it, as far as this PR goes at least.

Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/5323

From pchilanomate at openjdk.java.net  Wed Sep  1 16:31:38 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 1 Sep 2021 16:31:38 GMT
Subject: RFR: 8273217: Make ParHeapInspectTask _safepoint_check_never
In-Reply-To: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
References: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
Message-ID: <x7BBNn5iOPTIFqnfAdxebcIGQz5lM99hjgMenrzVxvI=.5207a7d8-8ab8-42a7-9456-d3c1478cf690@github.com>

On Wed, 1 Sep 2021 01:40:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make lock be declared as safepoint_check_never.
> Ran tier1-3 tests and test that uses this code: serviceability/dcmd/gc/ClassHistogramTest.java

LGTM.

Thanks,
Patricio

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

Marked as reviewed by pchilanomate (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5323

From iklam at openjdk.java.net  Wed Sep  1 16:42:32 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 1 Sep 2021 16:42:32 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <Y29E_zaSmtlJJ63Nyb6coISNWVh4iB1LCICHo2qmcdI=.6e7feaa7-26a5-4617-bfb7-c13efa80027e@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <fOPA1Jv4hC6LH9NWgFnMaQ-UPFfQODTA8941S5Ls91Q=.ee288462-62de-4fd8-b5b3-242b99dc36ad@github.com>
 <Y29E_zaSmtlJJ63Nyb6coISNWVh4iB1LCICHo2qmcdI=.6e7feaa7-26a5-4617-bfb7-c13efa80027e@github.com>
Message-ID: <ISWyyNoC_AevUW85Rnzs21iIWwpoNcQarFRMMKcLKb4=.59745132-5aba-4ff4-892e-cb01a7c9bd2e@github.com>

On Wed, 1 Sep 2021 07:50:18 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> > I find it very unfortunate that it states that `-verbose:gc` will be overridden by `-Xloggc:<filename>` and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.
> 
> Things are quite easy if `-verbose:x` is treated as `-Xlog`. Multiple -Xlog arguments for the same output override each other in their given order, according to https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html.
> 
> > I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?
> 
> I have looked up some documents but unfortunately haven't found relevant statements.

History:

See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html

Before UL was implemented, we had this:

" -Xloggc:filename -- Sets the file to which verbose GC events information should be redirected for logging. The information written to this file is similar to the output of -verbose:gc with the time elapsed since the first GC event preceding each logged event. The -Xloggc option overrides -verbose:gc if both are given with the same java command."



~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -cp ~/tmp HelloGC
[GC (System.gc())  391K->536K(1029632K), 0.0243973 secs]
[Full GC (System.gc())  536K->259K(1029632K), 0.0079780 secs]
~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -Xloggc:foo -verbose:gc -cp ~/tmp HelloGC
~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -Xloggc:foo -cp ~/tmp HelloGC
~/jdk/official/jdk8_b132/linux_amd64$ 


After UL was implemented, we changed the man page to say this, but unfortunately the "overrides" part is no longer working:

"Sets the file to which verbose GC events information should be redirected for logging. The -Xloggc option overrides -verbose:gc if both are given with the same java command. -Xloggc:filename is replaced by -Xlog:gc:filename. See Enable Logging with the JVM Unified Logging Framework."

****************************
UL doesn't support the notion of "overriding" as required by the java8 man page. If -Xlog:gc is specified for both a file and stdout, both will be written:


$ rm foo
$ tbjava -Xlog:gc:file=foo -Xlog:gc:stdout -version
[0.003s][info][gc] Using G1
java version "18-internal" 2022-03-15
Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
$ cat foo 
[0.003s][info][gc] Using G1
$ rm foo
$ tbjava -Xlog:gc:stdout -Xlog:gc:file=foo -version
[0.003s][info][gc] Using G1
java version "18-internal" 2022-03-15
Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
$ cat foo 
[0.003s][info][gc] Using G1
$ 


I think the ability to "override" -verbose:gc with -Xloggc:filename is rather useless. We should just change the man page to match the current behavior (i.e., -verbose:gc is an alias to -Xlog:gc:stdout) and remove the mention of overriding. If someone really wants the old behavior, they should remove -verbose:gc from their command-line.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From coleenp at openjdk.java.net  Wed Sep  1 16:53:47 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 1 Sep 2021 16:53:47 GMT
Subject: Integrated: 8273217: Make ParHeapInspectTask _safepoint_check_never
In-Reply-To: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
References: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
Message-ID: <txp7eCNdC44uAXHIrzLk6UnGgDNXjMQOyJw1tKSLU3o=.38ba655d-2cd4-479d-8ec0-f9d22efbfca0@github.com>

On Wed, 1 Sep 2021 01:40:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make lock be declared as safepoint_check_never.
> Ran tier1-3 tests and test that uses this code: serviceability/dcmd/gc/ClassHistogramTest.java

This pull request has now been integrated.

Changeset: dacd1978
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dacd1978972b46510049086c8431bb12e5f3722f
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8273217: Make ParHeapInspectTask _safepoint_check_never

Reviewed-by: dholmes, pchilanomate

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

PR: https://git.openjdk.java.net/jdk/pull/5323

From coleenp at openjdk.java.net  Wed Sep  1 16:53:43 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 1 Sep 2021 16:53:43 GMT
Subject: RFR: 8273217: Make ParHeapInspectTask _safepoint_check_never
In-Reply-To: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
References: <cXVQl3en3yq7m20uhfO1DDupuGRod-XaRHaH3kbiB14=.d709c4cd-27c2-445d-bff2-c7983c72db85@github.com>
Message-ID: <26YeWITCjMku2htnJLmg4nhTJCbcX_m_lWxWI9SFxMI=.c2096393-9546-4686-97d4-3156b57964e4@github.com>

On Wed, 1 Sep 2021 01:40:17 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Make lock be declared as safepoint_check_never.
> Ran tier1-3 tests and test that uses this code: serviceability/dcmd/gc/ClassHistogramTest.java

Thanks David and Patricio!

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

PR: https://git.openjdk.java.net/jdk/pull/5323

From naoto at openjdk.java.net  Wed Sep  1 17:42:29 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Sep 2021 17:42:29 GMT
Subject: RFR: 8273248: ProblemList
 java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs
In-Reply-To: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com>
References: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com>
Message-ID: <DQsBW28Yawe9mrqk-fPHDAIecNmWH9NVa-_TD0DfJQE=.04e7a3a1-b4dd-4fb7-ba3c-5a182960fcbb@github.com>

On Wed, 1 Sep 2021 17:33:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5337

From dcubed at openjdk.java.net  Wed Sep  1 17:42:28 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 1 Sep 2021 17:42:28 GMT
Subject: RFR: 8273248: ProblemList
 java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs
Message-ID: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com>

A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs.

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

Commit messages:
 - 8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs

Changes: https://git.openjdk.java.net/jdk/pull/5337/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5337&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273248
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5337.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5337/head:pull/5337

PR: https://git.openjdk.java.net/jdk/pull/5337

From dcubed at openjdk.java.net  Wed Sep  1 17:48:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 1 Sep 2021 17:48:33 GMT
Subject: Integrated: 8273197: ProblemList 2 jtools tests due to JDK-8273187
In-Reply-To: <huc6gbQBfDqKJpNIFxF98JedRTfK0jb7P2exKllXXA8=.b9e4d71d-8c75-4c3a-8a08-f30a655b222f@github.com>
References: <rjuJdKOLzaG6mLNsDDY63hUbFo5c6D4njr93pamuTfY=.80dd3885-41b9-4439-82e5-6f384a3909e2@github.com>
 <huc6gbQBfDqKJpNIFxF98JedRTfK0jb7P2exKllXXA8=.b9e4d71d-8c75-4c3a-8a08-f30a655b222f@github.com>
Message-ID: <RZgmxetOEuJQkL8vbi3xZXJD5YvR2XGeQodHs5RYs4A=.adaa8b63-141c-4e68-86b5-f5427199e85f@github.com>

On Tue, 31 Aug 2021 20:02:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Trivial fixes to reduce the noise in the JDK18 CI:
>> JDK-8273197 ProblemList 2 jtools tests due to JDK-8273187
>> JDK-8273198 ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh due to JDK-8273188
>> 
>> These failures happen in Tier5 so I'm ProblemListing them now to give @naotoj time to
>> work on the issues introduced by JDK-8260265 UTF-8 by Default.
>
> Marked as reviewed by naoto (Reviewer).

@naotoj - Thanks for the review! (I forgot to post yesterday)

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

PR: https://git.openjdk.java.net/jdk/pull/5321

From dcubed at openjdk.java.net  Wed Sep  1 17:49:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 1 Sep 2021 17:49:34 GMT
Subject: Integrated: 8273248: ProblemList
 java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs
In-Reply-To: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com>
References: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com>
Message-ID: <70I-zujvEsVJGyVtWwjn5PnAFeflQvGoI50doKfVPq8=.190805d3-c45a-4fca-ab25-e1e04a8ce43b@github.com>

On Wed, 1 Sep 2021 17:33:13 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs.

This pull request has now been integrated.

Changeset: 4ee0dace
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4ee0dacecd5afc5876ea839ffbb5df962ff6cd08
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8273248: ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs

Reviewed-by: naoto

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

PR: https://git.openjdk.java.net/jdk/pull/5337

From dcubed at openjdk.java.net  Wed Sep  1 17:49:33 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 1 Sep 2021 17:49:33 GMT
Subject: RFR: 8273248: ProblemList
 java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs
In-Reply-To: <DQsBW28Yawe9mrqk-fPHDAIecNmWH9NVa-_TD0DfJQE=.04e7a3a1-b4dd-4fb7-ba3c-5a182960fcbb@github.com>
References: <8yAn_t7lLh2Gj_GEB7rsCHIji0tbZbIV-SPRJR67HXE=.5a12bad5-c883-4982-bbcd-77fb90e5a5e9@github.com>
 <DQsBW28Yawe9mrqk-fPHDAIecNmWH9NVa-_TD0DfJQE=.04e7a3a1-b4dd-4fb7-ba3c-5a182960fcbb@github.com>
Message-ID: <3WYXAfBSiqZ7xd-6idwuc6Vn_3AD9GdclWawnV6n41g=.81682de0-90f0-4378-aa6a-25c924e782cd@github.com>

On Wed, 1 Sep 2021 17:35:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A trivial fix to ProblemList java/lang/instrument/BootClassPath/BootClassPathTest.sh on all configs.
>
> Marked as reviewed by naoto (Reviewer).

@naotoj - Thanks for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/5337

From pchilanomate at openjdk.java.net  Wed Sep  1 21:38:42 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 1 Sep 2021 21:38:42 GMT
Subject: RFR: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
Message-ID: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>

Hi,

Please review this small fix to call check_possible_safepoint() from SafepointMechanism::process_if_requested() and remove the same call from transition_and_process(). See the bug description for more detail.
Since there were only two lines left of common code from transition_from_native() and transition_from_vm() I just removed transition_and_process() altogether. This also saves an unneeded extra transition to _thread_in_vm when transitioning from vm to Java.

Testing tiers 1-6.

Thanks,
Patricio

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

Commit messages:
 - v1

Changes: https://git.openjdk.java.net/jdk/pull/5342/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5342&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273251
  Stats: 34 lines in 3 files changed: 13 ins; 17 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5342.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5342/head:pull/5342

PR: https://git.openjdk.java.net/jdk/pull/5342

From coleenp at openjdk.java.net  Wed Sep  1 21:59:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 1 Sep 2021 21:59:33 GMT
Subject: RFR: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
In-Reply-To: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
References: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
Message-ID: <p3hkJapfWnNahN0VPhBJLXD_Ni-1sfaX0S3Relvx25s=.42cb7f8c-90d2-448e-a727-7cd8a5a379e9@github.com>

On Wed, 1 Sep 2021 20:53:46 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review this small fix to call check_possible_safepoint() from SafepointMechanism::process_if_requested() and remove the same call from transition_and_process(). See the bug description for more detail.
> Since there were only two lines left of common code from transition_from_native() and transition_from_vm() I just removed transition_and_process() altogether. This also saves an unneeded extra transition to _thread_in_vm when transitioning from vm to Java.
> 
> Testing tiers 1-6.
> 
> Thanks,
> Patricio

Looks good to me!

src/hotspot/share/runtime/interfaceSupport.inline.hpp line 81:

> 79: 
> 80:  private:
> 81:   static inline void transition_and_process(JavaThread *thread, JavaThreadState to, bool check_asyncs) {

??

src/hotspot/share/runtime/thread.cpp line 959:

> 957:     assert_wx_state(WXWrite);
> 958:   }
> 959: #endif

I was wondering why you moved this, but it's assert code so it makes sense to me to be with the other assert code.  Maybe check_possible_safepoint could have a better name to encompass all these checking and assertions actions but I don't know what better name to give it.
With this code moved here, all the other callers where there's a possible safepoint but one not taken will also check this.  Did you test on macosx aarch64 too?

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5342

From minqi at openjdk.java.net  Wed Sep  1 22:19:48 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 1 Sep 2021 22:19:48 GMT
Subject: RFR: 8273240: Dynamic test ArchiveConsistency.java should use
 CDSArchiveUtils
Message-ID: <SLQDke_PT223794n1BM_g3aCx8W9agnW35MwRpeI314=.753e4791-a6e8-4a4c-a158-9af77369e930@github.com>

Please review the simple fix to simplify the test case appcds/dynamicArchive/ArchiveConsistency.java to use CDSArchiveUtils, which was added in JDK-8271419.

Tests: mach5 tier1,tier4

Thanks
Yumin

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

Commit messages:
 - 8273240: Dynamic test ArchiveConsistency.java should use CDSArchiveUtils

Changes: https://git.openjdk.java.net/jdk/pull/5344/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5344&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273240
  Stats: 110 lines in 2 files changed: 25 ins; 80 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5344.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5344/head:pull/5344

PR: https://git.openjdk.java.net/jdk/pull/5344

From pchilanomate at openjdk.java.net  Wed Sep  1 23:09:32 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 1 Sep 2021 23:09:32 GMT
Subject: RFR: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
In-Reply-To: <p3hkJapfWnNahN0VPhBJLXD_Ni-1sfaX0S3Relvx25s=.42cb7f8c-90d2-448e-a727-7cd8a5a379e9@github.com>
References: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
 <p3hkJapfWnNahN0VPhBJLXD_Ni-1sfaX0S3Relvx25s=.42cb7f8c-90d2-448e-a727-7cd8a5a379e9@github.com>
Message-ID: <e2uRF7F60dIc-RDE3Vi-rfhK2UOvYjOlL-aRAlTrpD4=.1803fb39-4861-49b1-8f91-d02e82ce6271@github.com>

On Wed, 1 Sep 2021 21:56:30 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Looks good to me!
>
Thanks for the review Coleen!

Patricio

> src/hotspot/share/runtime/thread.cpp line 959:
> 
>> 957:     assert_wx_state(WXWrite);
>> 958:   }
>> 959: #endif
> 
> I was wondering why you moved this, but it's assert code so it makes sense to me to be with the other assert code.  Maybe check_possible_safepoint could have a better name to encompass all these checking and assertions actions but I don't know what better name to give it.
> With this code moved here, all the other callers where there's a possible safepoint but one not taken will also check this.  Did you test on macosx aarch64 too?

I already run tiers 1-3 and I'm currently running tiers 4-6. Since we already include macosx-aarch64 tasks in those tiers I didn't run any additional tests. I will run an additional test cycle macosx-aarch64 specific. I'm not expecting any failures in that area though since those other places are methods with conditional statements where in one branch we might directly call process_if_requested() already due to some _safepoint_check_always lock. Caller method check_for_valid_safepoint_state() should also be safe since it asserts we are in _thread_in_vm implying WXWrite(in any case the callers of that method could also directly call process_if_requested()). We should probably merge this two methods after I fix callers of process_if_requested() to be in _thread_in_vm.

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

PR: https://git.openjdk.java.net/jdk/pull/5342

From jiefu at openjdk.java.net  Wed Sep  1 23:47:45 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 1 Sep 2021 23:47:45 GMT
Subject: RFR: 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails due
 to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32
Message-ID: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>

Hi all,

It fails on x86_32 since `ObjectAlignmentInBytes` is not a VM option.
Let's fix it.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32

Changes: https://git.openjdk.java.net/jdk/pull/5345/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5345&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273256
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5345.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5345/head:pull/5345

PR: https://git.openjdk.java.net/jdk/pull/5345

From dholmes at openjdk.java.net  Thu Sep  2 02:52:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Sep 2021 02:52:29 GMT
Subject: RFR: 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails
 due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32
In-Reply-To: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>
References: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>
Message-ID: <h25J2-r-8SZL5jr-sasc9OV_PbqXMTFNw3I3SMf0hkU=.fe1bff73-8852-46f1-98eb-7a9c0cc84bc1@github.com>

On Wed, 1 Sep 2021 23:39:17 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> It fails on x86_32 since `ObjectAlignmentInBytes` is not a VM option.
> Let's fix it.
> 
> Thanks.
> Best regards,
> Jie

Seems a reasonable way to fix this.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5345

From github.com+39413832+weixlu at openjdk.java.net  Thu Sep  2 03:01:31 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Thu, 2 Sep 2021 03:01:31 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <ISWyyNoC_AevUW85Rnzs21iIWwpoNcQarFRMMKcLKb4=.59745132-5aba-4ff4-892e-cb01a7c9bd2e@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <fOPA1Jv4hC6LH9NWgFnMaQ-UPFfQODTA8941S5Ls91Q=.ee288462-62de-4fd8-b5b3-242b99dc36ad@github.com>
 <Y29E_zaSmtlJJ63Nyb6coISNWVh4iB1LCICHo2qmcdI=.6e7feaa7-26a5-4617-bfb7-c13efa80027e@github.com>
 <ISWyyNoC_AevUW85Rnzs21iIWwpoNcQarFRMMKcLKb4=.59745132-5aba-4ff4-892e-cb01a7c9bd2e@github.com>
Message-ID: <VlE1LjvhDIjWGBzpy0laTr25Refnk5qPyYOYTrHfB7M=.a3e2ca2c-5d08-4ff3-8bcb-4651e7760a2a@github.com>

On Wed, 1 Sep 2021 16:39:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> I find it very unfortunate that it states that `-verbose:gc` will be overridden by `-Xloggc:<filename>` and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.
>> 
>> Things are quite easy if `-verbose:x` is treated as `-Xlog`. Multiple -Xlog arguments for the same output override each other in their given order, according to https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html.
>> 
>>> I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?
>> 
>> I have looked up some documents but unfortunately haven't found relevant statements.
>
>> > I find it very unfortunate that it states that `-verbose:gc` will be overridden by `-Xloggc:<filename>` and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.
>> 
>> Things are quite easy if `-verbose:x` is treated as `-Xlog`. Multiple -Xlog arguments for the same output override each other in their given order, according to https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html.
>> 
>> > I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?
>> 
>> I have looked up some documents but unfortunately haven't found relevant statements.
> 
> History:
> 
> See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
> 
> Before UL was implemented, we had this:
> 
> " -Xloggc:filename -- Sets the file to which verbose GC events information should be redirected for logging. The information written to this file is similar to the output of -verbose:gc with the time elapsed since the first GC event preceding each logged event. The -Xloggc option overrides -verbose:gc if both are given with the same java command."
> 
> 
> 
> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -cp ~/tmp HelloGC
> [GC (System.gc())  391K->536K(1029632K), 0.0243973 secs]
> [Full GC (System.gc())  536K->259K(1029632K), 0.0079780 secs]
> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -Xloggc:foo -verbose:gc -cp ~/tmp HelloGC
> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -Xloggc:foo -cp ~/tmp HelloGC
> ~/jdk/official/jdk8_b132/linux_amd64$ 
> 
> 
> After UL was implemented, we changed the man page to say this, but unfortunately the "overrides" part is no longer working:
> 
> "Sets the file to which verbose GC events information should be redirected for logging. The -Xloggc option overrides -verbose:gc if both are given with the same java command. -Xloggc:filename is replaced by -Xlog:gc:filename. See Enable Logging with the JVM Unified Logging Framework."
> 
> ****************************
> UL doesn't support the notion of "overriding" as required by the java8 man page. If -Xlog:gc is specified for both a file and stdout, both will be written:
> 
> 
> $ rm foo
> $ tbjava -Xlog:gc:file=foo -Xlog:gc:stdout -version
> [0.003s][info][gc] Using G1
> java version "18-internal" 2022-03-15
> Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
> Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
> $ cat foo 
> [0.003s][info][gc] Using G1
> $ rm foo
> $ tbjava -Xlog:gc:stdout -Xlog:gc:file=foo -version
> [0.003s][info][gc] Using G1
> java version "18-internal" 2022-03-15
> Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
> Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
> $ cat foo 
> [0.003s][info][gc] Using G1
> $ 
> 
> 
> I think the ability to "override" -verbose:gc with -Xloggc:filename is rather useless. We should just change the man page to match the current behavior (i.e., -verbose:gc is an alias to -Xlog:gc:stdout) and remove the mention of overriding. If someone really wants the old behavior, they should remove -verbose:gc from their command-line.

@iklam Yes, the introduction of UL has reconstructed many codes about logging. But a lot of Java users, as far as we know, are quite confused about the not working of such overrides for many days. These users have just upgraded to new java versions from java8 under our persuasion and they are more familiar with the behavior in java8. So I guess the ability to override may be useful for them.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Thu Sep  2 03:13:26 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Thu, 2 Sep 2021 03:13:26 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <x1HXR2bi9A58bv7w4IicUcCVmChEja0LevOEkeTUjlU=.8baf5505-31ad-48a9-b417-394101736953@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <x1HXR2bi9A58bv7w4IicUcCVmChEja0LevOEkeTUjlU=.8baf5505-31ad-48a9-b417-394101736953@github.com>
Message-ID: <z_fdEW0j0isdSpFoquDh7T8A-ihJoZb7Xfo3rPhpNWY=.b801b201-c8e3-47ea-b802-6803a1e46000@github.com>

On Wed, 1 Sep 2021 09:44:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>> 
>> $java -Xloggc:gc.log -verbose:gc -version
>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>> [0.003s][info ][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
>> 
>> $java -Xlog:gc:gc.log -verbose:gc -version
>> [0.003s][info][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.
>
> I also can't see how to implement the "overrides" semantics without scanning the entire command-line to collate the different forms of the flag and then collapse them into a single appropriate `-Xlog` definition. And that would be a startup hit.

@dholmes-ora In my commit, the behavior of override is much like "ignore" as you say. We put off the process of `-verbose:gc` until the entire command-line has been parsed. Then we decide whether to ignore `-verbose:gc` or not. As far as I'm concerned, we have to scan the entire command-line firstly.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From iklam at openjdk.java.net  Thu Sep  2 03:56:32 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 2 Sep 2021 03:56:32 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <ISWyyNoC_AevUW85Rnzs21iIWwpoNcQarFRMMKcLKb4=.59745132-5aba-4ff4-892e-cb01a7c9bd2e@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <fOPA1Jv4hC6LH9NWgFnMaQ-UPFfQODTA8941S5Ls91Q=.ee288462-62de-4fd8-b5b3-242b99dc36ad@github.com>
 <Y29E_zaSmtlJJ63Nyb6coISNWVh4iB1LCICHo2qmcdI=.6e7feaa7-26a5-4617-bfb7-c13efa80027e@github.com>
 <ISWyyNoC_AevUW85Rnzs21iIWwpoNcQarFRMMKcLKb4=.59745132-5aba-4ff4-892e-cb01a7c9bd2e@github.com>
Message-ID: <AuJtTvkW4xk8reev9E-VobZGQ1OHdt8WIQchElzjiOM=.665e7a15-e8f6-4cd8-9072-889a53743947@github.com>

On Wed, 1 Sep 2021 16:39:23 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> I find it very unfortunate that it states that `-verbose:gc` will be overridden by `-Xloggc:<filename>` and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.
>> 
>> Things are quite easy if `-verbose:x` is treated as `-Xlog`. Multiple -Xlog arguments for the same output override each other in their given order, according to https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html.
>> 
>>> I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?
>> 
>> I have looked up some documents but unfortunately haven't found relevant statements.
>
>> > I find it very unfortunate that it states that `-verbose:gc` will be overridden by `-Xloggc:<filename>` and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.
>> 
>> Things are quite easy if `-verbose:x` is treated as `-Xlog`. Multiple -Xlog arguments for the same output override each other in their given order, according to https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html.
>> 
>> > I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?
>> 
>> I have looked up some documents but unfortunately haven't found relevant statements.
> 
> History:
> 
> See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
> 
> Before UL was implemented, we had this:
> 
> " -Xloggc:filename -- Sets the file to which verbose GC events information should be redirected for logging. The information written to this file is similar to the output of -verbose:gc with the time elapsed since the first GC event preceding each logged event. The -Xloggc option overrides -verbose:gc if both are given with the same java command."
> 
> 
> 
> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -cp ~/tmp HelloGC
> [GC (System.gc())  391K->536K(1029632K), 0.0243973 secs]
> [Full GC (System.gc())  536K->259K(1029632K), 0.0079780 secs]
> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -Xloggc:foo -verbose:gc -cp ~/tmp HelloGC
> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -Xloggc:foo -cp ~/tmp HelloGC
> ~/jdk/official/jdk8_b132/linux_amd64$ 
> 
> 
> After UL was implemented, we changed the man page to say this, but unfortunately the "overrides" part is no longer working:
> 
> "Sets the file to which verbose GC events information should be redirected for logging. The -Xloggc option overrides -verbose:gc if both are given with the same java command. -Xloggc:filename is replaced by -Xlog:gc:filename. See Enable Logging with the JVM Unified Logging Framework."
> 
> ****************************
> UL doesn't support the notion of "overriding" as required by the java8 man page. If -Xlog:gc is specified for both a file and stdout, both will be written:
> 
> 
> $ rm foo
> $ tbjava -Xlog:gc:file=foo -Xlog:gc:stdout -version
> [0.003s][info][gc] Using G1
> java version "18-internal" 2022-03-15
> Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
> Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
> $ cat foo 
> [0.003s][info][gc] Using G1
> $ rm foo
> $ tbjava -Xlog:gc:stdout -Xlog:gc:file=foo -version
> [0.003s][info][gc] Using G1
> java version "18-internal" 2022-03-15
> Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
> Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
> $ cat foo 
> [0.003s][info][gc] Using G1
> $ 
> 
> 
> I think the ability to "override" -verbose:gc with -Xloggc:filename is rather useless. We should just change the man page to match the current behavior (i.e., -verbose:gc is an alias to -Xlog:gc:stdout) and remove the mention of overriding. If someone really wants the old behavior, they should remove -verbose:gc from their command-line.

> @iklam Yes, the introduction of UL has reconstructed many codes about logging. But a lot of Java users, as far as we know, are quite confused about the not working of such overrides for many days. These users have just upgraded to new java versions from java8 under our persuasion and they are more familiar with the behavior in java8. So I guess the ability to override may be useful for them.

If that's the case, those users aren't using -Xlog:gc yet. Maybe we should implement strictly what the man page says: if `-Xloggc:<filename>` is used, then `-verbose` (or `-verbose:gc`) will not cause gc logs to be printed to the stdout.

We shouldn't do anything to the other components of `-verbose`, and we shouldn't consider the interaction between `-Xlog` and `-verbose`.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From iklam at openjdk.java.net  Thu Sep  2 04:14:37 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 2 Sep 2021 04:14:37 GMT
Subject: RFR: 8273240: Dynamic test ArchiveConsistency.java should use
 CDSArchiveUtils
In-Reply-To: <SLQDke_PT223794n1BM_g3aCx8W9agnW35MwRpeI314=.753e4791-a6e8-4a4c-a158-9af77369e930@github.com>
References: <SLQDke_PT223794n1BM_g3aCx8W9agnW35MwRpeI314=.753e4791-a6e8-4a4c-a158-9af77369e930@github.com>
Message-ID: <V06RC3PkqkTv7PCZmG4q4ALzb1YUlEK2Ispk9fVPbDM=.a9c44dc3-8a57-439a-8251-04c4678a1f26@github.com>

On Wed, 1 Sep 2021 22:11:58 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review the simple fix to simplify the test case appcds/dynamicArchive/ArchiveConsistency.java to use CDSArchiveUtils, which was added in JDK-8271419.
> 
> Tests: mach5 tier1,tier4
> 
> Thanks
> Yumin

LGTM.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5344

From iklam at openjdk.java.net  Thu Sep  2 04:14:38 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 2 Sep 2021 04:14:38 GMT
Subject: RFR: 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails
 due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32
In-Reply-To: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>
References: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>
Message-ID: <cH3SDirgBHoCvwqIAyBOIDt0pwd-WrRxhvO3F_xthj0=.b8eae0be-5def-486a-bc6e-62174e23189e@github.com>

On Wed, 1 Sep 2021 23:39:17 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> It fails on x86_32 since `ObjectAlignmentInBytes` is not a VM option.
> Let's fix it.
> 
> Thanks.
> Best regards,
> Jie

LGTM. Thanks for fixing this.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5345

From jiefu at openjdk.java.net  Thu Sep  2 04:14:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 2 Sep 2021 04:14:38 GMT
Subject: RFR: 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails
 due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32
In-Reply-To: <h25J2-r-8SZL5jr-sasc9OV_PbqXMTFNw3I3SMf0hkU=.fe1bff73-8852-46f1-98eb-7a9c0cc84bc1@github.com>
References: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>
 <h25J2-r-8SZL5jr-sasc9OV_PbqXMTFNw3I3SMf0hkU=.fe1bff73-8852-46f1-98eb-7a9c0cc84bc1@github.com>
Message-ID: <SMGSlDtisUCP9LvPwtJ-VN63hlZCoBdUZM1ZobHAl5Y=.ea53370c-bcfd-4cab-8235-0c968f355801@github.com>

On Thu, 2 Sep 2021 02:49:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hi all,
>> 
>> It fails on x86_32 since `ObjectAlignmentInBytes` is not a VM option.
>> Let's fix it.
>> 
>> Thanks.
>> Best regards,
>> Jie
>
> Seems a reasonable way to fix this.
> 
> Thanks,
> David

Thanks @dholmes-ora and @iklam .

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

PR: https://git.openjdk.java.net/jdk/pull/5345

From jiefu at openjdk.java.net  Thu Sep  2 04:14:38 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 2 Sep 2021 04:14:38 GMT
Subject: Integrated: 8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java
 fails due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32
In-Reply-To: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>
References: <_xKHNYcCLl6ylPFKBmZRS1vp6dbHSq8flgaScRf3qeY=.4d15a248-97b0-4ff4-9314-26f133e4cf88@github.com>
Message-ID: <CdcQQuwvikpUHwtUFG6DPfWV2oSF1yQwZuQNo7djGq4=.77659ed4-94f8-4933-9b76-c89201f5e165@github.com>

On Wed, 1 Sep 2021 23:39:17 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> It fails on x86_32 since `ObjectAlignmentInBytes` is not a VM option.
> Let's fix it.
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: a9a83b24
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a9a83b248e4a575e3d22541c122b27246a52dc7b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8273256: runtime/cds/appcds/TestEpsilonGCWithCDS.java fails due to Unrecognized VM option 'ObjectAlignmentInBytes=64' on x86_32

Reviewed-by: dholmes, iklam

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

PR: https://git.openjdk.java.net/jdk/pull/5345

From dholmes at openjdk.java.net  Thu Sep  2 05:57:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Sep 2021 05:57:28 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <twCUgm9SV1EEy7RPG2POsZlz7yjHyY0mu1m8EfuvYfM=.3e9983ef-8899-4870-bb1b-715a51f9a7a3@github.com>

On Mon, 30 Aug 2021 07:09:54 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
> 
> $java -Xlog:gc:gc.log -verbose:gc -version
> [0.003s][info][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.

Before UL `-verbose:gc` simply set `PrintGC=true`. If you specified `-Xloggc:<file>` then it also set `PrintGC=true` and `PrintGCTimestamps=true`. So to describe this as "overriding" is misleading in the extreme - it simply changed the output destination and added a timestamp. It also made no difference what order the flags were specified in, or even if they were passed mutiple times.

With UL `-verbose:gc` enables logging of "gc" at "Info" level to stdout. However `-Xloggc:<file>` sets `_gc_log_filename` which in turns causes logging at either the "gc" or "gc*" levels depending on `PrintGCDetails`. That logging is at the default level - which is Info. So as far as I can see, we are doing the right thing in terms of preserving the pre-UL relationship between `-verbose:gc` and `-Xloggc:<file>` - except that with UL ordering does matter and that is where we have lost the "override" so to speak.

So as far as I can see the only thing we need to fix here is to track the use of both legacy flags, and to hold back on the actual UL configuration until processing of the command-line is complete. That also avoids the need of scanning the entire command-line. This isn't completely trivial to track but I'd be using a simple struct/class as follows:

struct LegacyGCLogging {
  char* tags;  // "gc" or "gc*"
  char* file; // NULL ->stdout
  int lastFlag; // -1 not set; 0 -> -verbose:gc; 1 -> -Xloggc
  }
If lastFlag was 1 and we encounter -verbose:gc then we do nothing - ensuring the override. Then at the end of argument processing we see what has been set and use that to configure GC logging.

This has the side-effect of ignoring some explicit `-Xlog:gc` arguments, but that is okay in my view because we are simply treating the legacy flags as-if they appeared last on the command-line and where converted to -Xlog in place.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From mbaesken at openjdk.java.net  Thu Sep  2 06:50:40 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 2 Sep 2021 06:50:40 GMT
Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows
 Server 2022
Message-ID: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>

Hello, please review this small change.
The OS detection code of the JDK/JVM should recognize the new Windows server 2022 :

https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info

The build number of Windows server 2022 according to the documentation in the second link is 20348 .
Thanks, Matthias

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

Commit messages:
 - JDK-8273229

Changes: https://git.openjdk.java.net/jdk/pull/5347/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5347&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273229
  Stats: 11 lines in 2 files changed: 8 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5347.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5347/head:pull/5347

PR: https://git.openjdk.java.net/jdk/pull/5347

From alanb at openjdk.java.net  Thu Sep  2 07:49:27 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Sep 2021 07:49:27 GMT
Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows
 Server 2022
In-Reply-To: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
References: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
Message-ID: <s0ZZGtA2Kimms414d4guIB1wP955Tl2KsH3hGEWT45c=.0b27a0a2-bcb1-4cfe-8aa3-59fc66496afe@github.com>

On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small change.
> The OS detection code of the JDK/JVM should recognize the new Windows server 2022 :
> 
> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
> https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info
> 
> The build number of Windows server 2022 according to the documentation in the second link is 20348 .
> Thanks, Matthias

The link to the "Windows Server release information" page is useful to check the build number - thanks!

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5347

From dholmes at openjdk.java.net  Thu Sep  2 07:53:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Sep 2021 07:53:29 GMT
Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows
 Server 2022
In-Reply-To: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
References: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
Message-ID: <y1E8M4XANTlOYI4GA6TaGqlK_udbUqA719QaeZa0GqQ=.226a73d5-b3c7-439e-985c-be9b5c432e82@github.com>

On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small change.
> The OS detection code of the JDK/JVM should recognize the new Windows server 2022 :
> 
> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
> https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info
> 
> The build number of Windows server 2022 according to the documentation in the second link is 20348 .
> Thanks, Matthias

Hi Matthias,

Some minor suggestions but okay as-is.

Thanks,
David

src/hotspot/os/windows/os_windows.cpp line 1871:

> 1869:       // distinguish Windows Server 2016, 2019 and 2022 by build number
> 1870:       // Windows server 2019 GA 10/2018 build number is 17763
> 1871:       // Windows server 2022 build number is 20348

Perhaps to avoid too much future editing:

// Distinguish Windows Server by build number:
// - 2016 GA 10/2016 build: 14393
// - 2019 GA 11/2018 build: 17763
// - 2022 GA 08/2021 build: 20348

src/java.base/windows/native/libjava/java_props_md.c line 478:

> 476:          *       where (buildNumber > 17762)
> 477:          * Windows Server 2022          10              0  (!VER_NT_WORKSTATION)
> 478:          *       where (buildNumber > 20347)

There is a comment at line 392 that you may want to adjust too - perhaps just say "Windows Server 2016+" to avoid the need to keep updating it.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5347

From shade at openjdk.java.net  Thu Sep  2 07:59:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 07:59:36 GMT
Subject: RFR: 8272970: Parallelize runtime/InvocationTests/ [v2]
In-Reply-To: <_3hdfNIcBw_oQNsiCpOTt0CBkzYMO6OrP5XHtCSVHp0=.509392f8-66cc-44f7-9a2e-e324fb527620@github.com>
References: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
 <_3hdfNIcBw_oQNsiCpOTt0CBkzYMO6OrP5XHtCSVHp0=.509392f8-66cc-44f7-9a2e-e324fb527620@github.com>
Message-ID: <JZgqdCQBmz_9s7ETm0LyGSZ1gFZ4TuRBha-r-stsvKU=.db0005e7-1968-47e1-b851-188efb1a76e6@github.com>

On Wed, 1 Sep 2021 08:01:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Current runtime/InvocationTests/ are long and serial. They take about half an hour on a modern desktop, mostly using a single CPU. They can be parallelized better, at least on sub-test level. This would be important as [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914) would start to run them in tier3.
>> 
>> Sample run times:
>> 
>> 
>> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=runtime/InvocationTests/
>> 
>> # Before
>> real	32m2.188s
>> user	59m12.818s
>> sys	0m45.612s
>> 
>> # After
>> real	17m21.110s
>> user	63m31.851s
>> sys	0m55.391s
>> 
>> 
>> I think we can technically go even deeper, for example parallelising by `packageSet` in the generators themselves, but that would be much more intrusive. I think 17 minutes is already quite good, given other tests running in prospective `hotspot:tier3`.
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8272970-parallel-invocation-tests
>  - Trim down redundant compile tags
>  - 8272970: Parallelize runtime/InvocationTests/

Thanks, I think this is good to go in.

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

PR: https://git.openjdk.java.net/jdk/pull/5250

From shade at openjdk.java.net  Thu Sep  2 07:59:37 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 2 Sep 2021 07:59:37 GMT
Subject: Integrated: 8272970: Parallelize runtime/InvocationTests/
In-Reply-To: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
References: <DbEfs-7Q37wuvl3asxDEbk83pwNhfwvM-rDGHjrhouc=.3bf59086-203b-4dc2-9de1-60a040f4ad2a@github.com>
Message-ID: <ROuglBEM5Pr_6zkukNyIBpNe1YyMYcP-4EpYhRAkZUM=.e53c5fec-3e5c-44e6-b4a3-55626fb821d0@github.com>

On Wed, 25 Aug 2021 11:58:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current runtime/InvocationTests/ are long and serial. They take about half an hour on a modern desktop, mostly using a single CPU. They can be parallelized better, at least on sub-test level. This would be important as [JDK-8272914](https://bugs.openjdk.java.net/browse/JDK-8272914) would start to run them in tier3.
> 
> Sample run times:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=runtime/InvocationTests/
> 
> # Before
> real	32m2.188s
> user	59m12.818s
> sys	0m45.612s
> 
> # After
> real	17m21.110s
> user	63m31.851s
> sys	0m55.391s
> 
> 
> I think we can technically go even deeper, for example parallelising by `packageSet` in the generators themselves, but that would be much more intrusive. I think 17 minutes is already quite good, given other tests running in prospective `hotspot:tier3`.

This pull request has now been integrated.

Changeset: 6cfe3142
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6cfe314262dacd6ca1a74c000d045b1cabd374db
Stats:     263 lines in 6 files changed: 215 ins; 25 del; 23 mod

8272970: Parallelize runtime/InvocationTests/

Reviewed-by: dholmes, iignatyev

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

PR: https://git.openjdk.java.net/jdk/pull/5250

From dholmes at openjdk.java.net  Thu Sep  2 08:02:36 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Sep 2021 08:02:36 GMT
Subject: RFR: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
In-Reply-To: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
References: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
Message-ID: <-1P0pjNDg02W8ICX1LzP1CMNufiYvQMm6Dv99TEiUmk=.f93db33d-9356-4a88-9286-4543d79f5d2f@github.com>

On Wed, 1 Sep 2021 20:53:46 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review this small fix to call check_possible_safepoint() from SafepointMechanism::process_if_requested() and remove the same call from transition_and_process(). See the bug description for more detail.
> Since there were only two lines left of common code from transition_from_native() and transition_from_vm() I just removed transition_and_process() altogether. This also saves an unneeded extra transition to _thread_in_vm when transitioning from vm to Java.
> 
> Testing tiers 1-6.
> 
> Thanks,
> Patricio

Looks good! Thanks for the cleanup Patricio: fewer functions and no redundant state changes.

Cheers,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5342

From dholmes at openjdk.java.net  Thu Sep  2 08:02:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Sep 2021 08:02:37 GMT
Subject: RFR: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
In-Reply-To: <e2uRF7F60dIc-RDE3Vi-rfhK2UOvYjOlL-aRAlTrpD4=.1803fb39-4861-49b1-8f91-d02e82ce6271@github.com>
References: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
 <p3hkJapfWnNahN0VPhBJLXD_Ni-1sfaX0S3Relvx25s=.42cb7f8c-90d2-448e-a727-7cd8a5a379e9@github.com>
 <e2uRF7F60dIc-RDE3Vi-rfhK2UOvYjOlL-aRAlTrpD4=.1803fb39-4861-49b1-8f91-d02e82ce6271@github.com>
Message-ID: <hpaX4hQecLLg3hPxJwgKxAmGHFvGUAT80_4psgapWc8=.f435acd2-c8f4-40e4-9077-f059b9acc886@github.com>

On Wed, 1 Sep 2021 23:06:32 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 959:
>> 
>>> 957:     assert_wx_state(WXWrite);
>>> 958:   }
>>> 959: #endif
>> 
>> I was wondering why you moved this, but it's assert code so it makes sense to me to be with the other assert code.  Maybe check_possible_safepoint could have a better name to encompass all these checking and assertions actions but I don't know what better name to give it.
>> With this code moved here, all the other callers where there's a possible safepoint but one not taken will also check this.  Did you test on macosx aarch64 too?
>
> I already run tiers 1-3 and I'm currently running tiers 4-6. Since we already include macosx-aarch64 tasks in those tiers I didn't run any additional tests. I will run an additional test cycle macosx-aarch64 specific. I'm not expecting any failures in that area though since those other places are methods with conditional statements where in one branch we might directly call process_if_requested() already due to some _safepoint_check_always lock. Caller method check_for_valid_safepoint_state() should also be safe since it asserts we are in _thread_in_vm implying WXWrite(in any case the callers of that method could also directly call process_if_requested()). We should probably merge this two methods after I fix callers of process_if_requested() to be in _thread_in_vm.

Maybe `check_safepoint_ready` for the new name? (Not needed for this PR though.)

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

PR: https://git.openjdk.java.net/jdk/pull/5342

From mbaesken at openjdk.java.net  Thu Sep  2 08:16:53 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 2 Sep 2021 08:16:53 GMT
Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows
 Server 2022 [v2]
In-Reply-To: <y1E8M4XANTlOYI4GA6TaGqlK_udbUqA719QaeZa0GqQ=.226a73d5-b3c7-439e-985c-be9b5c432e82@github.com>
References: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
 <y1E8M4XANTlOYI4GA6TaGqlK_udbUqA719QaeZa0GqQ=.226a73d5-b3c7-439e-985c-be9b5c432e82@github.com>
Message-ID: <JdDBYYJQfoNl7jXIjvXplcDMCn77HKw13YmYUFOqwYQ=.9b066175-ed13-451c-bdb4-68fc84ecd49c@github.com>

On Thu, 2 Sep 2021 07:49:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust comments
>
> src/hotspot/os/windows/os_windows.cpp line 1871:
> 
>> 1869:       // distinguish Windows Server 2016, 2019 and 2022 by build number
>> 1870:       // Windows server 2019 GA 10/2018 build number is 17763
>> 1871:       // Windows server 2022 build number is 20348
> 
> Perhaps to avoid too much future editing:
> 
> // Distinguish Windows Server by build number:
> // - 2016 GA 10/2016 build: 14393
> // - 2019 GA 11/2018 build: 17763
> // - 2022 GA 08/2021 build: 20348

Hi David , thanks for your suggestions. I  adjusted the comments.

Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5347

From mbaesken at openjdk.java.net  Thu Sep  2 08:16:52 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 2 Sep 2021 08:16:52 GMT
Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows
 Server 2022 [v2]
In-Reply-To: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
References: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
Message-ID: <QE0rpHaop5h5H_Uv5Wv3Sr18jUcZlPJB9ilFy5MgsvE=.d072da48-9a5b-4a58-aa7f-9acae2919e40@github.com>

> Hello, please review this small change.
> The OS detection code of the JDK/JVM should recognize the new Windows server 2022 :
> 
> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
> https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info
> 
> The build number of Windows server 2022 according to the documentation in the second link is 20348 .
> Thanks, Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5347/files
  - new: https://git.openjdk.java.net/jdk/pull/5347/files/c7ce4abc..f8952e3e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5347&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5347&range=00-01

  Stats: 5 lines in 2 files changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5347.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5347/head:pull/5347

PR: https://git.openjdk.java.net/jdk/pull/5347

From dholmes at openjdk.java.net  Thu Sep  2 08:51:28 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 2 Sep 2021 08:51:28 GMT
Subject: RFR: JDK-8273229: Update OS detection code to recognize Windows
 Server 2022 [v2]
In-Reply-To: <QE0rpHaop5h5H_Uv5Wv3Sr18jUcZlPJB9ilFy5MgsvE=.d072da48-9a5b-4a58-aa7f-9acae2919e40@github.com>
References: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
 <QE0rpHaop5h5H_Uv5Wv3Sr18jUcZlPJB9ilFy5MgsvE=.d072da48-9a5b-4a58-aa7f-9acae2919e40@github.com>
Message-ID: <HDM9Ego6HfyY5tZ6wgIMS2OUfFbR1RGrg9my49B5AVA=.d0d1adb9-4ba6-45e0-932a-4ca6ebbf6bdb@github.com>

On Thu, 2 Sep 2021 08:16:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Hello, please review this small change.
>> The OS detection code of the JDK/JVM should recognize the new Windows server 2022 :
>> 
>> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
>> https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info
>> 
>> The build number of Windows server 2022 according to the documentation in the second link is 20348 .
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust comments

Thanks for the updates

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5347

From github.com+39413832+weixlu at openjdk.java.net  Thu Sep  2 11:07:51 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Thu, 2 Sep 2021 11:07:51 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose [v2]
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <3iodGk__FeWss6QvgOa5INJHhpRk5_7wNCF2u5nL8kk=.1c3fa531-7048-4889-a7cc-181de17784b2@github.com>

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
> 
> $java -Xlog:gc:gc.log -verbose:gc -version
> [0.003s][info][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.

Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:

  8273112: -Xloggc should override -verbose

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5295/files
  - new: https://git.openjdk.java.net/jdk/pull/5295/files/639eafc0..0681dae1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5295&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5295&range=00-01

  Stats: 60 lines in 2 files changed: 13 ins; 37 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5295.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5295/head:pull/5295

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Thu Sep  2 11:13:51 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Thu, 2 Sep 2021 11:13:51 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose [v3]
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <meRWAIq4S4oydKURS6VgTJhtKaPkqmGH7lWdM6s3rFc=.63caffcf-8ffb-4c1c-b124-bc445060fb54@github.com>

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
> 
> $java -Xlog:gc:gc.log -verbose:gc -version
> [0.003s][info][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.

Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:

  remove code in previous commit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5295/files
  - new: https://git.openjdk.java.net/jdk/pull/5295/files/0681dae1..f355e598

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5295&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5295&range=01-02

  Stats: 10 lines in 2 files changed: 0 ins; 10 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5295.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5295/head:pull/5295

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Thu Sep  2 11:16:29 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Thu, 2 Sep 2021 11:16:29 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose [v2]
In-Reply-To: <3iodGk__FeWss6QvgOa5INJHhpRk5_7wNCF2u5nL8kk=.1c3fa531-7048-4889-a7cc-181de17784b2@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <3iodGk__FeWss6QvgOa5INJHhpRk5_7wNCF2u5nL8kk=.1c3fa531-7048-4889-a7cc-181de17784b2@github.com>
Message-ID: <e0KsEIn7vFJ99W1RoWjYmfXYFG1AA8f-wupLb-E_EFs=.b04f3d1f-85ba-41d6-a795-1baa9cb7a769@github.com>

On Thu, 2 Sep 2021 11:07:51 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>> 
>> $java -Xloggc:gc.log -verbose:gc -version
>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>> [0.003s][info ][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
>> 
>> $java -Xlog:gc:gc.log -verbose:gc -version
>> [0.003s][info][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.
>
> Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8273112: -Xloggc should override -verbose

Thanks for your suggestions. Yes, I think we should merely focus on the man page and let `-Xloggc:` override `-verbose:gc`. Thus in the new commit, I put off the process of these two legacy flags (in Arguments::handle_deprecated_print_gc_flags()) until the entire command-line has been parsed.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From mbaesken at openjdk.java.net  Thu Sep  2 11:26:35 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 2 Sep 2021 11:26:35 GMT
Subject: Integrated: JDK-8273229: Update OS detection code to recognize
 Windows Server 2022
In-Reply-To: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
References: <sDkA14RywgUoJPLKz7wLKrYmvjNNuDYgS3k7UMOz86A=.819b77b7-94c4-494b-a02f-3a035c42f239@github.com>
Message-ID: <pLPHwCNE2NHal_lJpfw_QonRskYTJ3sUMTcfwOdw2R8=.cdf21c01-c184-48cb-994e-849e7d8d382d@github.com>

On Thu, 2 Sep 2021 06:43:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small change.
> The OS detection code of the JDK/JVM should recognize the new Windows server 2022 :
> 
> https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2022
> https://docs.microsoft.com/en-us/windows-server/get-started/windows-server-release-info
> 
> The build number of Windows server 2022 according to the documentation in the second link is 20348 .
> Thanks, Matthias

This pull request has now been integrated.

Changeset: c2e015c3
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c2e015c3c1a2274112bb8e6671a85bc7fb624fde
Stats:     14 lines in 2 files changed: 9 ins; 0 del; 5 mod

8273229: Update OS detection code to recognize Windows Server 2022

Reviewed-by: alanb, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5347

From pchilanomate at openjdk.java.net  Thu Sep  2 14:45:38 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 2 Sep 2021 14:45:38 GMT
Subject: RFR: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
In-Reply-To: <-1P0pjNDg02W8ICX1LzP1CMNufiYvQMm6Dv99TEiUmk=.f93db33d-9356-4a88-9286-4543d79f5d2f@github.com>
References: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
 <-1P0pjNDg02W8ICX1LzP1CMNufiYvQMm6Dv99TEiUmk=.f93db33d-9356-4a88-9286-4543d79f5d2f@github.com>
Message-ID: <4dnSLeL8sVfZd0eObFf9KJhmFdhxK86oFEu3hIvDZQU=.ced9888c-75cf-4f04-9e33-a2fb9a83968f@github.com>

On Thu, 2 Sep 2021 07:59:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Looks good! Thanks for the cleanup Patricio: fewer functions and no redundant state changes.
> 
Thanks for the review David!

Patricio

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

PR: https://git.openjdk.java.net/jdk/pull/5342

From pchilanomate at openjdk.java.net  Thu Sep  2 14:45:39 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 2 Sep 2021 14:45:39 GMT
Subject: RFR: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
In-Reply-To: <hpaX4hQecLLg3hPxJwgKxAmGHFvGUAT80_4psgapWc8=.f435acd2-c8f4-40e4-9077-f059b9acc886@github.com>
References: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
 <p3hkJapfWnNahN0VPhBJLXD_Ni-1sfaX0S3Relvx25s=.42cb7f8c-90d2-448e-a727-7cd8a5a379e9@github.com>
 <e2uRF7F60dIc-RDE3Vi-rfhK2UOvYjOlL-aRAlTrpD4=.1803fb39-4861-49b1-8f91-d02e82ce6271@github.com>
 <hpaX4hQecLLg3hPxJwgKxAmGHFvGUAT80_4psgapWc8=.f435acd2-c8f4-40e4-9077-f059b9acc886@github.com>
Message-ID: <C58OmjWTAfvuDvEDXsyg7hMSeZ9DA_cniPpdIvxBmfw=.413ca169-b8fc-46cb-800e-6c8694507f29@github.com>

On Thu, 2 Sep 2021 07:58:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I already run tiers 1-3 and I'm currently running tiers 4-6. Since we already include macosx-aarch64 tasks in those tiers I didn't run any additional tests. I will run an additional test cycle macosx-aarch64 specific. I'm not expecting any failures in that area though since those other places are methods with conditional statements where in one branch we might directly call process_if_requested() already due to some _safepoint_check_always lock. Caller method check_for_valid_safepoint_state() should also be safe since it asserts we are in _thread_in_vm implying WXWrite(in any case the callers of that method could also directly call process_if_requested()). We should probably merge this two methods after I fix callers of process_if_requested() to be in _thread_in_vm.
>
> Maybe `check_safepoint_ready` for the new name? (Not needed for this PR though.)

Sounds good, I'll address that in another RFE then.

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

PR: https://git.openjdk.java.net/jdk/pull/5342

From pchilanomate at openjdk.java.net  Thu Sep  2 21:26:33 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Thu, 2 Sep 2021 21:26:33 GMT
Subject: Integrated: 8273251: Call check_possible_safepoint() from
 SafepointMechanism::process_if_requested()
In-Reply-To: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
References: <e9_aj7GZ_SDIqBgC-8FuroBkWnbfdgCMkXygtZisQk4=.be12ae5c-7151-43b9-b2bd-61a39c391717@github.com>
Message-ID: <trZOSlKyWKV5JqlIV7wA24JhBHLCRKDKURe6Za-_xJQ=.6c49a670-1618-430e-8ecb-3e5b00109026@github.com>

On Wed, 1 Sep 2021 20:53:46 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> Please review this small fix to call check_possible_safepoint() from SafepointMechanism::process_if_requested() and remove the same call from transition_and_process(). See the bug description for more detail.
> Since there were only two lines left of common code from transition_from_native() and transition_from_vm() I just removed transition_and_process() altogether. This also saves an unneeded extra transition to _thread_in_vm when transitioning from vm to Java.
> 
> Testing tiers 1-6.
> 
> Thanks,
> Patricio

This pull request has now been integrated.

Changeset: 92b05fe0
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/92b05fe0f41b91aa88e77473725ae92ee13b052f
Stats:     34 lines in 3 files changed: 13 ins; 17 del; 4 mod

8273251: Call check_possible_safepoint() from SafepointMechanism::process_if_requested()

Reviewed-by: coleenp, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5342

From iklam at openjdk.java.net  Fri Sep  3 02:07:29 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 3 Sep 2021 02:07:29 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose [v3]
In-Reply-To: <meRWAIq4S4oydKURS6VgTJhtKaPkqmGH7lWdM6s3rFc=.63caffcf-8ffb-4c1c-b124-bc445060fb54@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <meRWAIq4S4oydKURS6VgTJhtKaPkqmGH7lWdM6s3rFc=.63caffcf-8ffb-4c1c-b124-bc445060fb54@github.com>
Message-ID: <YTHxC31NF3LEqXvKKNqYRtsuV5F6VQHt6Qza2JWFsmo=.d8addf7d-5311-4bb7-8c00-fff550876ad8@github.com>

On Thu, 2 Sep 2021 11:13:51 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>> 
>> $java -Xloggc:gc.log -verbose:gc -version
>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>> [0.003s][info ][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
>> 
>> $java -Xlog:gc:gc.log -verbose:gc -version
>> [0.003s][info][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.
>
> Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove code in previous commit

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5295

From dholmes at openjdk.java.net  Fri Sep  3 02:07:29 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 3 Sep 2021 02:07:29 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose [v3]
In-Reply-To: <meRWAIq4S4oydKURS6VgTJhtKaPkqmGH7lWdM6s3rFc=.63caffcf-8ffb-4c1c-b124-bc445060fb54@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <meRWAIq4S4oydKURS6VgTJhtKaPkqmGH7lWdM6s3rFc=.63caffcf-8ffb-4c1c-b124-bc445060fb54@github.com>
Message-ID: <SEwtZUj73PRSxoBszJ-BCr4cpH1nJyB5zBaYKfgvqFU=.b6040ee9-3ad1-4ec9-b56f-aabcdaa875c5@github.com>

On Thu, 2 Sep 2021 11:13:51 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>> 
>> $java -Xloggc:gc.log -verbose:gc -version
>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>> [0.003s][info ][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> In addition, since -Xloggc:filename is replaced by -Xlog:gc:filename, can we assume that -Xlog:gc:filename should override -verbose:gc as -Xloggc:filename? Currently, gclog still outputs to both stdout and file if -Xlog and -verbose are given with the same java command.
>> 
>> $java -Xlog:gc:gc.log -verbose:gc -version
>> [0.003s][info][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> As a result, we propose to put off the log configuration of -verbose option until we are confident that there isn?t -Xloggc or -Xlog options.
>
> Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove code in previous commit

Not surprisingly this looks good to me! :)

I think this captures the desired/expected behaviour.

Thanks,
David

src/hotspot/share/runtime/arguments.cpp line 95:

> 93: char*  Arguments::SharedDynamicArchivePath      = NULL;
> 94: 
> 95: LegacyGCLogging Arguments::_legacyGCLogging     = { 0 };

`{ 0, 0}` ? Or is it implied the other members are zero-initialized?

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 02:31:29 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 02:31:29 GMT
Subject: RFR: 8273112: -Xloggc and -Xlog should override -verbose [v3]
In-Reply-To: <SEwtZUj73PRSxoBszJ-BCr4cpH1nJyB5zBaYKfgvqFU=.b6040ee9-3ad1-4ec9-b56f-aabcdaa875c5@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <meRWAIq4S4oydKURS6VgTJhtKaPkqmGH7lWdM6s3rFc=.63caffcf-8ffb-4c1c-b124-bc445060fb54@github.com>
 <SEwtZUj73PRSxoBszJ-BCr4cpH1nJyB5zBaYKfgvqFU=.b6040ee9-3ad1-4ec9-b56f-aabcdaa875c5@github.com>
Message-ID: <Hk2ZRkwefXYZ8a8JMCr5PDi7JBP5W1zOgQP3MWki5A8=.b480d777-ae56-40d2-8857-ab4b9226171f@github.com>

On Fri, 3 Sep 2021 02:03:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove code in previous commit
>
> src/hotspot/share/runtime/arguments.cpp line 95:
> 
>> 93: char*  Arguments::SharedDynamicArchivePath      = NULL;
>> 94: 
>> 95: LegacyGCLogging Arguments::_legacyGCLogging     = { 0 };
> 
> `{ 0, 0}` ? Or is it implied the other members are zero-initialized?

@dholmes-ora I think compiler will assign 0 to all members of this struct. Since you have mentioned this here, let's explicitly use { 0, 0} to avoid potential problems.

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 02:48:59 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 02:48:59 GMT
Subject: RFR: 8273112: -Xloggc:<filename> should override -verbose:gc [v4]
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <I9jeNZr_ck8Bpip8Sul-ZokW9SgJyZdNWkxd-kdVkL0=.3cbabfe7-781f-452f-bfc1-04e15bda9070@github.com>

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose:gc option until we are confident that there isn?t -Xloggc option.

Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:

  fix initialization of _legacyGCLogging

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5295/files
  - new: https://git.openjdk.java.net/jdk/pull/5295/files/f355e598..5f69d62d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5295&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5295&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 02:49:00 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 02:49:00 GMT
Subject: RFR: 8273112: -Xloggc:<filename> should override -verbose:gc
In-Reply-To: <AuJtTvkW4xk8reev9E-VobZGQ1OHdt8WIQchElzjiOM=.665e7a15-e8f6-4cd8-9072-889a53743947@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <fOPA1Jv4hC6LH9NWgFnMaQ-UPFfQODTA8941S5Ls91Q=.ee288462-62de-4fd8-b5b3-242b99dc36ad@github.com>
 <Y29E_zaSmtlJJ63Nyb6coISNWVh4iB1LCICHo2qmcdI=.6e7feaa7-26a5-4617-bfb7-c13efa80027e@github.com>
 <ISWyyNoC_AevUW85Rnzs21iIWwpoNcQarFRMMKcLKb4=.59745132-5aba-4ff4-892e-cb01a7c9bd2e@github.com>
 <AuJtTvkW4xk8reev9E-VobZGQ1OHdt8WIQchElzjiOM=.665e7a15-e8f6-4cd8-9072-889a53743947@github.com>
Message-ID: <62fCMHqLqTRQilnSQvWKxp3V2uKEQT0O3tPHs0coUPQ=.5e6860a9-a572-423e-8057-256cdb026608@github.com>

On Thu, 2 Sep 2021 03:53:06 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>>> > I find it very unfortunate that it states that `-verbose:gc` will be overridden by `-Xloggc:<filename>` and `-Xlog` as that makes the logic for dealing with this GC case very convoluted. It would make much more sense that `-verbose:x` simply be treated as its corresponding `-Xlog` variant. Then we would need no special logic at all.
>>> 
>>> Things are quite easy if `-verbose:x` is treated as `-Xlog`. Multiple -Xlog arguments for the same output override each other in their given order, according to https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html.
>>> 
>>> > I'm unclear how the non-GC versions of `-verbose:x` are treated with respect to explicit `-Xlog:x` commands?
>>> 
>>> I have looked up some documents but unfortunately haven't found relevant statements.
>> 
>> History:
>> 
>> See https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html
>> 
>> Before UL was implemented, we had this:
>> 
>> " -Xloggc:filename -- Sets the file to which verbose GC events information should be redirected for logging. The information written to this file is similar to the output of -verbose:gc with the time elapsed since the first GC event preceding each logged event. The -Xloggc option overrides -verbose:gc if both are given with the same java command."
>> 
>> 
>> 
>> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -cp ~/tmp HelloGC
>> [GC (System.gc())  391K->536K(1029632K), 0.0243973 secs]
>> [Full GC (System.gc())  536K->259K(1029632K), 0.0079780 secs]
>> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -Xloggc:foo -verbose:gc -cp ~/tmp HelloGC
>> ~/jdk/official/jdk8_b132/linux_amd64$ ./bin/java -verbose:gc -Xloggc:foo -cp ~/tmp HelloGC
>> ~/jdk/official/jdk8_b132/linux_amd64$ 
>> 
>> 
>> After UL was implemented, we changed the man page to say this, but unfortunately the "overrides" part is no longer working:
>> 
>> "Sets the file to which verbose GC events information should be redirected for logging. The -Xloggc option overrides -verbose:gc if both are given with the same java command. -Xloggc:filename is replaced by -Xlog:gc:filename. See Enable Logging with the JVM Unified Logging Framework."
>> 
>> ****************************
>> UL doesn't support the notion of "overriding" as required by the java8 man page. If -Xlog:gc is specified for both a file and stdout, both will be written:
>> 
>> 
>> $ rm foo
>> $ tbjava -Xlog:gc:file=foo -Xlog:gc:stdout -version
>> [0.003s][info][gc] Using G1
>> java version "18-internal" 2022-03-15
>> Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
>> Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
>> $ cat foo 
>> [0.003s][info][gc] Using G1
>> $ rm foo
>> $ tbjava -Xlog:gc:stdout -Xlog:gc:file=foo -version
>> [0.003s][info][gc] Using G1
>> java version "18-internal" 2022-03-15
>> Java(TM) SE Runtime Environment (build 18-internal+0-adhoc.iklam.open)
>> Java HotSpot(TM) 64-Bit Server VM (build 18-internal+0-adhoc.iklam.open, mixed mode, sharing)
>> $ cat foo 
>> [0.003s][info][gc] Using G1
>> $ 
>> 
>> 
>> I think the ability to "override" -verbose:gc with -Xloggc:filename is rather useless. We should just change the man page to match the current behavior (i.e., -verbose:gc is an alias to -Xlog:gc:stdout) and remove the mention of overriding. If someone really wants the old behavior, they should remove -verbose:gc from their command-line.
>
>> @iklam Yes, the introduction of UL has reconstructed many codes about logging. But a lot of Java users, as far as we know, are quite confused about the not working of such overrides for many days. These users have just upgraded to new java versions from java8 under our persuasion and they are more familiar with the behavior in java8. So I guess the ability to override may be useful for them.
> 
> If that's the case, those users aren't using -Xlog:gc yet. Maybe we should implement strictly what the man page says: if `-Xloggc:<filename>` is used, then `-verbose` (or `-verbose:gc`) will not cause gc logs to be printed to the stdout.
> 
> We shouldn't do anything to the other components of `-verbose`, and we shouldn't consider the interaction between `-Xlog` and `-verbose`.

@iklam @dholmes-ora Thanks for your review and helpful suggestions. Could you please sponsor this change?

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From dholmes at openjdk.java.net  Fri Sep  3 05:27:30 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 3 Sep 2021 05:27:30 GMT
Subject: RFR: 8273112: -Xloggc:<filename> should override -verbose:gc [v4]
In-Reply-To: <I9jeNZr_ck8Bpip8Sul-ZokW9SgJyZdNWkxd-kdVkL0=.3cbabfe7-781f-452f-bfc1-04e15bda9070@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
 <I9jeNZr_ck8Bpip8Sul-ZokW9SgJyZdNWkxd-kdVkL0=.3cbabfe7-781f-452f-bfc1-04e15bda9070@github.com>
Message-ID: <xm5T2f4bdb3T9eAzj36WHCrnks9aTMA1O1m9K5CoBMs=.32e4bd6b-553d-44a3-acab-0dbff5a6eba0@github.com>

On Fri, 3 Sep 2021 02:48:59 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

>> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
>> 
>> $java -Xloggc:gc.log -verbose:gc -version
>> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
>> [0.003s][info ][gc] Using G1
>> $cat gc.log
>> [0.003s][info][gc] Using G1
>> 
>> As a result, we propose to put off the log configuration of -verbose:gc option until we are confident that there isn?t -Xloggc option.
>
> Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix initialization of _legacyGCLogging

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+39413832+weixlu at openjdk.java.net  Fri Sep  3 05:32:32 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Fri, 3 Sep 2021 05:32:32 GMT
Subject: Integrated: 8273112: -Xloggc:<filename> should override -verbose:gc
In-Reply-To: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
References: <ZX7eo-FAZNPRRwJ6km0sFf8zzUXzngwjZXFmFp9ak2M=.02dca0ff-91b6-485a-b76f-e950f2f47370@github.com>
Message-ID: <CQ5aqvA6tYSkhXfo9sSnb2vUn3GZFJXPRieDZV7mlwU=.1e888097-cf89-4d96-a00e-d1c594a5ac63@github.com>

On Mon, 30 Aug 2021 07:09:54 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> According to java 16 specifications for java command (https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html), the command line option -Xloggc should override -verbose:gc if both options are given with the same java command. However, gc information still outputs to console even if gc log file is specified.
> 
> $java -Xloggc:gc.log -verbose:gc -version
> [0.000s][warning][gc] -Xloggc is deprecated. Will use -Xlog:gc:gc.log instead.
> [0.003s][info ][gc] Using G1
> $cat gc.log
> [0.003s][info][gc] Using G1
> 
> As a result, we propose to put off the log configuration of -verbose:gc option until we are confident that there isn?t -Xloggc option.

This pull request has now been integrated.

Changeset: fa9c8657
Author:    Xiaowei Lu <lxw263044 at alibaba-inc.com>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fa9c8657dfaa2018f501de1a8aa62f004342c245
Stats:     19 lines in 2 files changed: 11 ins; 1 del; 7 mod

8273112: -Xloggc:<filename> should override -verbose:gc

Reviewed-by: iklam, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5295

From github.com+8503711+danheidinga at openjdk.java.net  Fri Sep  3 15:25:43 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Fri, 3 Sep 2021 15:25:43 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
Message-ID: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>

I picked up a simple unassigned bug to work through the contribution process.

`make run-test-tier1` passes with this change.

Signed-off-by: Dan Heidinga <heidinga at redhat.com>

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

Commit messages:
 - 8272164: DumpAllocStats shouldn't subclass from ResourceObj

Changes: https://git.openjdk.java.net/jdk/pull/5362/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5362&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272164
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5362.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5362/head:pull/5362

PR: https://git.openjdk.java.net/jdk/pull/5362

From shade at openjdk.java.net  Fri Sep  3 15:36:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Sep 2021 15:36:39 GMT
Subject: RFR: 8273333: Zero should warn about unimplemented
 -XX:+LogTouchedMethods
Message-ID: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>

Currently Zero VM does not implement -XX:+LogTouchedMethods runtime features, which makes `runtime/CommandLine/PrintTouchedMethods.java` tier1 test fail with it.

Instead of implementing it (risking performance and rare bugs), Zero should just reject the option. 

Additional testing:
 - [x] Eyeballing failure message
 - [x] Affected test does not run with Zero anymore
 - [x] Affected test still runs with Server

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

Commit messages:
 - Implement

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

PR: https://git.openjdk.java.net/jdk/pull/5363

From shade at openjdk.java.net  Fri Sep  3 15:41:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Sep 2021 15:41:27 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
In-Reply-To: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
Message-ID: <jQPzHhPuIBE2z381NXqIlye5Xi4r6n7CyAEnuRCoBtM=.f1760958-221b-4fac-84b9-937f16a44c83@github.com>

On Fri, 3 Sep 2021 15:17:49 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

> I picked up a simple unassigned bug to work through the contribution process.
> 
> `make run-test-tier1` passes with this change.
> 
> Signed-off-by: Dan Heidinga <heidinga at redhat.com>

Looks fine to me. Please configure and run GHA testing: look at "Pre-submit test status" or "Checks" tab.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5362

From minqi at openjdk.java.net  Fri Sep  3 16:39:24 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 3 Sep 2021 16:39:24 GMT
Subject: RFR: 8273333: Zero should warn about unimplemented
 -XX:+LogTouchedMethods
In-Reply-To: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
References: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
Message-ID: <1liU1MFbbf5Scj-RK0h7C11P_IgoIT2FsCUY34fFkyQ=.1745b339-fe7c-4161-ba85-bbf933d5f815@github.com>

On Fri, 3 Sep 2021 15:29:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently Zero VM does not implement -XX:+LogTouchedMethods runtime features, which makes `runtime/CommandLine/PrintTouchedMethods.java` tier1 test fail with it.
> 
> Instead of implementing it (risking performance and rare bugs), Zero should just reject the option. 
> 
> Additional testing:
>  - [x] Eyeballing failure message
>  - [x] Affected test does not run with Zero anymore
>  - [x] Affected test still runs with Server

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5363

From github.com+8503711+danheidinga at openjdk.java.net  Fri Sep  3 18:37:57 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Fri, 3 Sep 2021 18:37:57 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
In-Reply-To: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
Message-ID: <m2A9T4kS9lBKJ8LcpepYAool5BbOsRZmzMCdQl49Lr0=.88da30cb-6dec-4365-85a2-474ef6fc05e7@github.com>

On Fri, 3 Sep 2021 15:17:49 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

> I picked up a simple unassigned bug to work through the contribution process.
> 
> `make run-test-tier1` passes with this change.
> 
> Signed-off-by: Dan Heidinga <heidinga at redhat.com>

I see the `` test failed on Linux_x64 and that there's a fix has already been merged for it:
https://github.com/openjdk/jdk/commit/7212561dd1ec65d7f31792959f0eaaab6229eaf4

I'll rebase to pick up the latest to get a clean test run

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From github.com+8503711+danheidinga at openjdk.java.net  Fri Sep  3 18:48:50 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Fri, 3 Sep 2021 18:48:50 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v2]
In-Reply-To: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
Message-ID: <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>

> I picked up a simple unassigned bug to work through the contribution process.
> 
> `make run-test-tier1` passes with this change.
> 
> Signed-off-by: Dan Heidinga <heidinga at redhat.com>

Dan Heidinga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8272164: DumpAllocStats shouldn't subclass from ResourceObj
  
  Signed-off-by: Dan Heidinga <heidinga at redhat.com>

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

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From iklam at openjdk.java.net  Fri Sep  3 18:48:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 3 Sep 2021 18:48:55 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v2]
In-Reply-To: <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
 <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>
Message-ID: <N7Wpq47e8s6cVeXXm0HqsKa33LOSojRnDJIFAlXXxBQ=.2f930f9e-c074-460c-8536-80447e3adf34@github.com>

On Fri, 3 Sep 2021 18:44:50 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

>> I picked up a simple unassigned bug to work through the contribution process.
>> 
>> `make run-test-tier1` passes with this change.
>> 
>> Signed-off-by: Dan Heidinga <heidinga at redhat.com>
>
> Dan Heidinga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8272164: DumpAllocStats shouldn't subclass from ResourceObj
>   
>   Signed-off-by: Dan Heidinga <heidinga at redhat.com>

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5362

From shade at openjdk.java.net  Fri Sep  3 18:48:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 3 Sep 2021 18:48:57 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
In-Reply-To: <m2A9T4kS9lBKJ8LcpepYAool5BbOsRZmzMCdQl49Lr0=.88da30cb-6dec-4365-85a2-474ef6fc05e7@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
 <m2A9T4kS9lBKJ8LcpepYAool5BbOsRZmzMCdQl49Lr0=.88da30cb-6dec-4365-85a2-474ef6fc05e7@github.com>
Message-ID: <YkG0VEna4cQXk_kRejwgVKvQG_x3JUqR2tMAa9qvbwc=.b82bb039-68a3-466f-ba51-490667a9ebff@github.com>

On Fri, 3 Sep 2021 18:32:59 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

> I'll rebase to pick up the latest to get a clean test run

You can, but no need to spend CPU time on this, as long as you know the test failure was not caused by this PR. GHA results are not required to be fully green for integration. Also, do merges not rebases, if you can -- leaves the reviews/webrevs consistent, especially when comments are bound to particular code locations.

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From github.com+8503711+danheidinga at openjdk.java.net  Fri Sep  3 18:49:00 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Fri, 3 Sep 2021 18:49:00 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
In-Reply-To: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
Message-ID: <0A-SYOzToiEbOj5KhootDQ4P8wG-cizDgooP27axdlg=.e5d3fdbe-ec38-4b9c-b7d2-0d47a72ee08b@github.com>

On Fri, 3 Sep 2021 15:17:49 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

> I picked up a simple unassigned bug to work through the contribution process.
> 
> `make run-test-tier1` passes with this change.
> 
> Signed-off-by: Dan Heidinga <heidinga at redhat.com>

Apologies - I've already pushed the rebase.  Will use merges in the future

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From minqi at openjdk.java.net  Fri Sep  3 20:39:26 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 3 Sep 2021 20:39:26 GMT
Subject: RFR: 8273240: Dynamic test ArchiveConsistency.java should use
 CDSArchiveUtils
In-Reply-To: <V06RC3PkqkTv7PCZmG4q4ALzb1YUlEK2Ispk9fVPbDM=.a9c44dc3-8a57-439a-8251-04c4678a1f26@github.com>
References: <SLQDke_PT223794n1BM_g3aCx8W9agnW35MwRpeI314=.753e4791-a6e8-4a4c-a158-9af77369e930@github.com>
 <V06RC3PkqkTv7PCZmG4q4ALzb1YUlEK2Ispk9fVPbDM=.a9c44dc3-8a57-439a-8251-04c4678a1f26@github.com>
Message-ID: <VHpRVsTibez7fhrnAzJ7Nf7Ju6LeQ4OZKTNMR09KG2w=.547f316e-df32-4f18-9fa4-cea2fe466e71@github.com>

On Thu, 2 Sep 2021 04:11:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review the simple fix to simplify the test case appcds/dynamicArchive/ArchiveConsistency.java to use CDSArchiveUtils, which was added in JDK-8271419.
>> 
>> Tests: mach5 tier1,tier4
>> 
>> Thanks
>> Yumin
>
> LGTM.

@iklam Thanks for review

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

PR: https://git.openjdk.java.net/jdk/pull/5344

From minqi at openjdk.java.net  Fri Sep  3 20:39:27 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 3 Sep 2021 20:39:27 GMT
Subject: Integrated: 8273240: Dynamic test ArchiveConsistency.java should use
 CDSArchiveUtils
In-Reply-To: <SLQDke_PT223794n1BM_g3aCx8W9agnW35MwRpeI314=.753e4791-a6e8-4a4c-a158-9af77369e930@github.com>
References: <SLQDke_PT223794n1BM_g3aCx8W9agnW35MwRpeI314=.753e4791-a6e8-4a4c-a158-9af77369e930@github.com>
Message-ID: <u0Si-hYpDCg4qdYTUnKG1tFmKidmmydkjTsb_R5Rp0s=.059c2d08-f5a7-429b-96bc-0ee2285cd4f1@github.com>

On Wed, 1 Sep 2021 22:11:58 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Please review the simple fix to simplify the test case appcds/dynamicArchive/ArchiveConsistency.java to use CDSArchiveUtils, which was added in JDK-8271419.
> 
> Tests: mach5 tier1,tier4
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: d414a88d
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d414a88d88a5734d6c431e74d735a780a90d60cf
Stats:     110 lines in 2 files changed: 25 ins; 80 del; 5 mod

8273240: Dynamic test ArchiveConsistency.java should use CDSArchiveUtils

Reviewed-by: iklam

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

PR: https://git.openjdk.java.net/jdk/pull/5344

From dholmes at openjdk.java.net  Fri Sep  3 22:39:54 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 3 Sep 2021 22:39:54 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v2]
In-Reply-To: <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
 <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>
Message-ID: <OfgV-UwigpojTZGQ9hPf_okX-iPRuLl60DdGhgvk2aY=.274363e7-279b-43c5-a539-8ed74ea50995@github.com>

On Fri, 3 Sep 2021 18:48:50 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

>> I picked up a simple unassigned bug to work through the contribution process.
>> 
>> `make run-test-tier1` passes with this change.
>> 
>> Signed-off-by: Dan Heidinga <heidinga at redhat.com>
>
> Dan Heidinga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8272164: DumpAllocStats shouldn't subclass from ResourceObj
>   
>   Signed-off-by: Dan Heidinga <heidinga at redhat.com>

> This class is never allocated from resource area or C-heap. It's just stack allocated.

So the obvious question - should it subclass StackObj instead?

> Signed-off-by: Dan Heidinga heidinga at redhat.com

What does this signify Dan?

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From mseledtsov at openjdk.java.net  Sat Sep  4 00:13:12 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Sat, 4 Sep 2021 00:13:12 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for containers is
 not tested
Message-ID: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>

Please review this addition of new testing:
  - new test for sending jcmd commands across container boundaries
  - updated existing sidecar test, enabling jcmd test case

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

Commit messages:
 - Cleanup
 - Adding TestJcmd
 - Made getBaseImageName() and version() public to allow tests access these methods
 - Test JCMD with side car pattern works

Changes: https://git.openjdk.java.net/jdk/pull/5368/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5368&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8195809
  Stats: 201 lines in 3 files changed: 194 ins; 2 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5368.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5368/head:pull/5368

PR: https://git.openjdk.java.net/jdk/pull/5368

From mseledtsov at openjdk.java.net  Sat Sep  4 00:13:12 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Sat, 4 Sep 2021 00:13:12 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested
In-Reply-To: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
Message-ID: <W6BAYfW8d_GljVGgHCuND_JuHPHUluGaKiqm2o4d_fg=.3e4b7c9f-3e55-4dac-a231-d7e0fb1986a4@github.com>

On Sat, 4 Sep 2021 00:03:14 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this addition of new testing:
>   - new test for sending jcmd commands across container boundaries
>   - updated existing sidecar test, enabling jcmd test case

@hseigel and Kevin Walls, please review when you have a chance

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

PR: https://git.openjdk.java.net/jdk/pull/5368

From github.com+8503711+danheidinga at openjdk.java.net  Sat Sep  4 01:38:54 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Sat, 4 Sep 2021 01:38:54 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v2]
In-Reply-To: <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
 <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>
Message-ID: <5RaDqUOnPFHNtbm400mghe9b2x7WNYe-u4qm8CFU3d4=.f23e043f-6cf6-4125-832f-ea337399938f@github.com>

On Fri, 3 Sep 2021 18:48:50 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

>> I picked up a simple unassigned bug to work through the contribution process.
>> 
>> `make run-test-tier1` passes with this change.
>> 
>> Signed-off-by: Dan Heidinga <heidinga at redhat.com>
>
> Dan Heidinga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8272164: DumpAllocStats shouldn't subclass from ResourceObj
>   
>   Signed-off-by: Dan Heidinga <heidinga at redhat.com>

> > Signed-off-by: Dan Heidinga [heidinga at redhat.com](mailto:heidinga at redhat.com)
> 
> What does this signify Dan?

I've gotten in the habit of using `git commit -s` to sign commits as this is required for contributing to Eclipse projects.  The intent of the line is to show that the author is signing off that they have the rights to share the patch.  It's usually used to ensure that the author of the pull request has signed the Eclipse Contributor agreement.  I guess it's not used here?

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From github.com+8503711+danheidinga at openjdk.java.net  Sat Sep  4 03:30:19 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Sat, 4 Sep 2021 03:30:19 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v3]
In-Reply-To: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
Message-ID: <xXtJuqyAw5GKgijg3GK9FmSGuza1GJ9BK7dQZ5cV6-M=.d9ab222c-32ea-4c8b-a3bc-5a970dbbc65c@github.com>

> I picked up a simple unassigned bug to work through the contribution process.
> 
> `make run-test-tier1` passes with this change.
> 
> Signed-off-by: Dan Heidinga <heidinga at redhat.com>

Dan Heidinga has updated the pull request incrementally with one additional commit since the last revision:

  Explicitly mark as StackObj subclass

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5362/files
  - new: https://git.openjdk.java.net/jdk/pull/5362/files/8438b691..b0781da0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5362&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5362&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From dholmes at openjdk.java.net  Sat Sep  4 04:48:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 4 Sep 2021 04:48:51 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v2]
In-Reply-To: <5RaDqUOnPFHNtbm400mghe9b2x7WNYe-u4qm8CFU3d4=.f23e043f-6cf6-4125-832f-ea337399938f@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
 <0VqWcVfSyL2mgxG8QSPXwBrLofpCTu2MUblrz-XF36k=.8c5a71d7-42f1-46ad-973f-5fc74d124eb4@github.com>
 <5RaDqUOnPFHNtbm400mghe9b2x7WNYe-u4qm8CFU3d4=.f23e043f-6cf6-4125-832f-ea337399938f@github.com>
Message-ID: <SyxlswVkpL9gz8Ww99n9DaUAFeIaS-XQHxTs-tYmxL8=.e6a0e94c-ca58-4580-91cb-76eb239d878d@github.com>

On Sat, 4 Sep 2021 01:35:35 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

>  I guess it's not used here?

Right, not used here. The patch author has to have signed the OCA for the PR to be accepted by the skara tooling.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From dholmes at openjdk.java.net  Sat Sep  4 04:57:46 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 4 Sep 2021 04:57:46 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v3]
In-Reply-To: <xXtJuqyAw5GKgijg3GK9FmSGuza1GJ9BK7dQZ5cV6-M=.d9ab222c-32ea-4c8b-a3bc-5a970dbbc65c@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
 <xXtJuqyAw5GKgijg3GK9FmSGuza1GJ9BK7dQZ5cV6-M=.d9ab222c-32ea-4c8b-a3bc-5a970dbbc65c@github.com>
Message-ID: <NQyp9Q2uLjEDUhaoJ7JmqroGi2uqgtNUm-0Ix77y82k=.6d58894d-2714-477a-b694-40372fa06d24@github.com>

On Sat, 4 Sep 2021 03:30:19 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

>> I picked up a simple unassigned bug to work through the contribution process.
>> 
>> `make run-test-tier1` passes with this change.
>> 
>> Signed-off-by: Dan Heidinga <heidinga at redhat.com>
>
> Dan Heidinga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly mark as StackObj subclass

Hi Dan,

This version also seems fine. I'm not sure where we stand with using `StackObj` these days in terms of style (ie is it just a historical anachronism?). But in this case `DumpAllocStats` only has a single use embedded within `ArchiveBuilder` which is itself a `StackObj` - so this seems fine either way.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5362

From dholmes at openjdk.java.net  Sun Sep  5 23:46:54 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 5 Sep 2021 23:46:54 GMT
Subject: RFR: 8273333: Zero should warn about unimplemented
 -XX:+LogTouchedMethods
In-Reply-To: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
References: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
Message-ID: <reuOpiCDNWN6vxJ7GJthB0TPZTcMcgYc_LMwuuSYrtU=.2c5c5cd0-fc5b-429e-bb45-7a81e6f6f487@github.com>

On Fri, 3 Sep 2021 15:29:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently Zero VM does not implement -XX:+LogTouchedMethods runtime features, which makes `runtime/CommandLine/PrintTouchedMethods.java` tier1 test fail with it.
> 
> Instead of implementing it (risking performance and rare bugs), Zero should just reject the option. 
> 
> Additional testing:
>  - [x] Eyeballing failure message
>  - [x] Affected test does not run with Zero anymore
>  - [x] Affected test still runs with Server

Looks fine.

One style nit.

Thanks,
David

test/hotspot/jtreg/runtime/CommandLine/PrintTouchedMethods.java line 27:

> 25:  * @test
> 26:  * @requires vm.flavor != "zero"
> 27:  * @bug 8025692 8273333

Nit: these lines tend to be in the other order

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5363

From lzang at openjdk.java.net  Mon Sep  6 06:50:12 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 6 Sep 2021 06:50:12 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v31]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <LRqidG0Ewp9g6-GamMy_ijeGc7F8vAOtKia4Rnq1SGQ=.5e95a09d-ec08-48d5-a490-fbf073d22a01@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - fix build issue
 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - Merge branch 'master' into par-dump
 - fix build issue after rebase and fix one issue
 - Merge branch 'master'
 - Merge branch 'master' into pd
 - update copyright info
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/c640fe42...062110e2

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=30
  Stats: 835 lines in 5 files changed: 648 ins; 57 del; 130 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From shade at openjdk.java.net  Mon Sep  6 07:31:15 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 07:31:15 GMT
Subject: RFR: 8273333: Zero should warn about unimplemented
 -XX:+LogTouchedMethods [v2]
In-Reply-To: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
References: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
Message-ID: <kK6ARbUVm57rOuceSh047Pbwi5m1vVChKTJBQNLJkpY=.d8a8e64e-f29c-412f-954f-e14aee944e99@github.com>

> Currently Zero VM does not implement -XX:+LogTouchedMethods runtime features, which makes `runtime/CommandLine/PrintTouchedMethods.java` tier1 test fail with it.
> 
> Instead of implementing it (risking performance and rare bugs), Zero should just reject the option. 
> 
> Additional testing:
>  - [x] Eyeballing failure message
>  - [x] Affected test does not run with Zero anymore
>  - [x] Affected test still runs with Server

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

  Change the @requries line order

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5363/files
  - new: https://git.openjdk.java.net/jdk/pull/5363/files/9e0a3218..0bdca3f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5363&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5363&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5363

From shade at openjdk.java.net  Mon Sep  6 09:54:58 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 6 Sep 2021 09:54:58 GMT
Subject: RFR: 8273373: Zero: Handle thread stack sizes with a generic Linux
 code
Message-ID: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>

See the bug for more discussion.

Additional testing:
 - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
 - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/5376/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5376&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273373
  Stats: 88 lines in 2 files changed: 3 ins; 85 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5376/head:pull/5376

PR: https://git.openjdk.java.net/jdk/pull/5376

From github.com+8503711+danheidinga at openjdk.java.net  Mon Sep  6 13:34:43 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Mon, 6 Sep 2021 13:34:43 GMT
Subject: RFR: 8272164: DumpAllocStats shouldn't subclass from ResourceObj
 [v3]
In-Reply-To: <xXtJuqyAw5GKgijg3GK9FmSGuza1GJ9BK7dQZ5cV6-M=.d9ab222c-32ea-4c8b-a3bc-5a970dbbc65c@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
 <xXtJuqyAw5GKgijg3GK9FmSGuza1GJ9BK7dQZ5cV6-M=.d9ab222c-32ea-4c8b-a3bc-5a970dbbc65c@github.com>
Message-ID: <HYijAOX0mXnvn9K4GsCIOAc6W3tEcqpfO54dzg7HB4w=.2bf09996-29db-4ee7-8afa-f6e94a988ab5@github.com>

On Sat, 4 Sep 2021 03:30:19 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

>> I picked up a simple unassigned bug to work through the contribution process.
>> 
>> `make run-test-tier1` passes with this change.
>> 
>> Signed-off-by: Dan Heidinga <heidinga at redhat.com>
>
> Dan Heidinga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Explicitly mark as StackObj subclass

The pre-submit test failures are all in `tools/javac/options/modes/InfoOptsTest.java` and I can't reproduce the failure locally.  There a a number of other open PRs with the same failure so it looks like an unrelated failure.

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From github.com+8503711+danheidinga at openjdk.java.net  Mon Sep  6 13:43:42 2021
From: github.com+8503711+danheidinga at openjdk.java.net (Dan Heidinga)
Date: Mon, 6 Sep 2021 13:43:42 GMT
Subject: Integrated: 8272164: DumpAllocStats shouldn't subclass from
 ResourceObj
In-Reply-To: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
References: <QrMFrPeVLh5QI9UreEEppHQXQVL8S7U3JnIyLEE0ZKA=.9e3eb983-e72d-4c8f-8e11-4cc8ff8a3ffb@github.com>
Message-ID: <WIx8GjORnQoOCK3RcjM4FLsKgqitMQIATEqaZatRq3k=.0edf5fbf-e236-41e8-bc59-d2398c9d1b07@github.com>

On Fri, 3 Sep 2021 15:17:49 GMT, Dan Heidinga <github.com+8503711+DanHeidinga at openjdk.org> wrote:

> I picked up a simple unassigned bug to work through the contribution process.
> 
> `make run-test-tier1` passes with this change.
> 
> Signed-off-by: Dan Heidinga <heidinga at redhat.com>

This pull request has now been integrated.

Changeset: 44c5c23b
Author:    Dan Heidinga <heidinga at redhat.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/44c5c23b96adf071339b39cfaea08c2d3a19d839
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8272164: DumpAllocStats shouldn't subclass from ResourceObj

Reviewed-by: shade, iklam, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5362

From lkorinth at openjdk.java.net  Mon Sep  6 14:03:46 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Mon, 6 Sep 2021 14:03:46 GMT
Subject: RFR: 8231356: Fix broken ResourceObj::operator new[] in debug
 builds [v2]
In-Reply-To: <kWORdVaxB4V_FfIwPqUonNufh1KZjEdDfGfpRWA4kJs=.1f0f7b5c-7062-49c0-9df8-6806a1c3fafe@github.com>
References: <TRAxAqYZG1l5NzRcAo7RqfPQM2569yg8ogDfrhmuAeM=.77821e7b-c2ab-4738-a866-2202c6c09e3b@github.com>
 <j9tGy777QDfrAupoRalKMcB8xNX3dVojt1nsJ4xqKBY=.536727c7-5e51-4998-93ab-0dc13ac9bad7@github.com>
 <kWORdVaxB4V_FfIwPqUonNufh1KZjEdDfGfpRWA4kJs=.1f0f7b5c-7062-49c0-9df8-6806a1c3fafe@github.com>
Message-ID: <iNYAxP49RbPTd-BV35RP7EELcwMxCyusmRodacghW5A=.de8e6d87-8f9f-42c4-95aa-7edd6e69f587@github.com>

On Wed, 11 Aug 2021 12:30:45 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove all other new [] operators in RsourceObj and the delete [] operator as well
>
> src/hotspot/share/memory/allocation.hpp line 444:
> 
>> 442:   }
>> 443: 
>> 444:   void* operator new [](size_t size) throw() = delete;
> 
> I think it should suffice to `delete` this one, with the others completely removed.  I think that name lookup will find this, and one will either get an error because the arguments don't match or because they do match to a deleted function.

Sorry for the delay, can I keep all `= delete`? I have an idea how to fix them in the future.

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

PR: https://git.openjdk.java.net/jdk/pull/5055

From dholmes at openjdk.java.net  Mon Sep  6 23:10:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Sep 2021 23:10:42 GMT
Subject: RFR: 8273333: Zero should warn about unimplemented
 -XX:+LogTouchedMethods [v2]
In-Reply-To: <kK6ARbUVm57rOuceSh047Pbwi5m1vVChKTJBQNLJkpY=.d8a8e64e-f29c-412f-954f-e14aee944e99@github.com>
References: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
 <kK6ARbUVm57rOuceSh047Pbwi5m1vVChKTJBQNLJkpY=.d8a8e64e-f29c-412f-954f-e14aee944e99@github.com>
Message-ID: <BDuYxEg0k1kbPr21hZZVvBdpD1DC50jauezMuD_w_Zg=.261cbc1e-50c3-494e-921b-bfaf8dd80a84@github.com>

On Mon, 6 Sep 2021 07:31:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently Zero VM does not implement -XX:+LogTouchedMethods runtime features, which makes `runtime/CommandLine/PrintTouchedMethods.java` tier1 test fail with it.
>> 
>> Instead of implementing it (risking performance and rare bugs), Zero should just reject the option. 
>> 
>> Additional testing:
>>  - [x] Eyeballing failure message
>>  - [x] Affected test does not run with Zero anymore
>>  - [x] Affected test still runs with Server
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the @requries line order

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5363

From dholmes at openjdk.java.net  Mon Sep  6 23:18:38 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 6 Sep 2021 23:18:38 GMT
Subject: RFR: 8273373: Zero: Handle thread stack sizes with a generic
 Linux code
In-Reply-To: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
Message-ID: <xQdgmsm9Z5aYgIihHaEDPuwYfrduZijnAOiJNKu604U=.83b47a1d-5078-49d8-a990-c97ee8864515@github.com>

On Mon, 6 Sep 2021 09:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

Hi Aleksey,

The assert in the shared code seems fine. I can't really comment on the Zero changes and the dropping of IA64 support here.

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From ysuenaga at openjdk.java.net  Mon Sep  6 23:32:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 6 Sep 2021 23:32:38 GMT
Subject: RFR: 8273104: Refactoring option parser for UL
In-Reply-To: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
Message-ID: <TLNqLilBVDDRkSx1jW17y_3IEDbPW146ztZ0x0M3l4c=.6ae414b1-a50f-47a2-ad92-1203f3908db7@github.com>

On Sun, 29 Aug 2021 03:48:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
> 
> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
> 
> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
> 
> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.

PING: Can I get second reviewer?

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

PR: https://git.openjdk.java.net/jdk/pull/5293

From dholmes at openjdk.java.net  Tue Sep  7 00:24:38 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 7 Sep 2021 00:24:38 GMT
Subject: RFR: 8273104: Refactoring option parser for UL
In-Reply-To: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
Message-ID: <PSWiNccrcksgcVwrmufCdYNK6Bfp5rBYc8H5xMHLDJA=.fa8a2df4-97a3-44c3-8978-fb406504d705@github.com>

On Sun, 29 Aug 2021 03:48:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
> 
> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
> 
> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
> 
> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.

Hi Yasumasa,

I have one query below about a possible correctness issue with the error messages.

IIUC these dynamic changes to the options will only apply after argument processing is complete - so anything logged prior to that will not be affected. That isn't an issue for options that don't directly change the output but for FoldMultiLines it means we would not do the folding initially. That probably isn't a practical concern given what logging can happen prior to argument processing ... or am I mistaken in thinking that UL can be used prior to that point?

Thanks,
David

src/hotspot/share/logging/logOutput.cpp line 370:

> 368:     if (!success) {
> 369:       if (errstream->count() > errstream_count_before) {
> 370:         errstream->print_cr("Invalid option '%s' for log output (%s).", key, name());

I don't quite follow this. If the error count has increased then this was a known option with a bad value that has already been reported in set_option. Here we should be catching an unknown option that wasn't recognized by set_option, in which case the error count should be unchanged no?

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

PR: https://git.openjdk.java.net/jdk/pull/5293

From kbarrett at openjdk.java.net  Tue Sep  7 01:26:39 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 7 Sep 2021 01:26:39 GMT
Subject: RFR: 8231356: Fix broken ResourceObj::operator new[] in debug
 builds [v2]
In-Reply-To: <j9tGy777QDfrAupoRalKMcB8xNX3dVojt1nsJ4xqKBY=.536727c7-5e51-4998-93ab-0dc13ac9bad7@github.com>
References: <TRAxAqYZG1l5NzRcAo7RqfPQM2569yg8ogDfrhmuAeM=.77821e7b-c2ab-4738-a866-2202c6c09e3b@github.com>
 <j9tGy777QDfrAupoRalKMcB8xNX3dVojt1nsJ4xqKBY=.536727c7-5e51-4998-93ab-0dc13ac9bad7@github.com>
Message-ID: <1NjQaJUOFt69yR7xHay_RVEb4qq9BpepENkpfeD4b9Q=.6038ddab-a9d6-40fc-aeb8-603798807757@github.com>

On Wed, 11 Aug 2021 11:36:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ResourceObj::operator new[] calls ResourceObj::operator new (non array version). In debug builds, each resource object (on C_HEAP) will be initialized with set_allocation_type() (which is correct). What is not correct is that the constructor (and thus) set_allocation_type() is called on the array itself (which is not a ResourceObj). This initialization will be partially overwritten by the header that keeps track of the array size. When the array destructor later is called, it will also chain call the non-array destructor. In debug builds the verification of _allocation_t[0] will fail as it has been overwritten by the code that keeps track of the array size.
>> 
>> The following assert will fail:
>> assert(~(_allocation_t[0] | allocation_mask) == (uintptr_t)this, "lost resource object");
>> 
>> The reason that it has not been detected is that no one uses ResourceObj::operator new[] on resource objects with C_HEAP storage.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove all other new [] operators in RsourceObj and the delete [] operator as well

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5055

From kbarrett at openjdk.java.net  Tue Sep  7 01:26:39 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 7 Sep 2021 01:26:39 GMT
Subject: RFR: 8231356: Fix broken ResourceObj::operator new[] in debug
 builds [v2]
In-Reply-To: <iNYAxP49RbPTd-BV35RP7EELcwMxCyusmRodacghW5A=.de8e6d87-8f9f-42c4-95aa-7edd6e69f587@github.com>
References: <TRAxAqYZG1l5NzRcAo7RqfPQM2569yg8ogDfrhmuAeM=.77821e7b-c2ab-4738-a866-2202c6c09e3b@github.com>
 <j9tGy777QDfrAupoRalKMcB8xNX3dVojt1nsJ4xqKBY=.536727c7-5e51-4998-93ab-0dc13ac9bad7@github.com>
 <kWORdVaxB4V_FfIwPqUonNufh1KZjEdDfGfpRWA4kJs=.1f0f7b5c-7062-49c0-9df8-6806a1c3fafe@github.com>
 <iNYAxP49RbPTd-BV35RP7EELcwMxCyusmRodacghW5A=.de8e6d87-8f9f-42c4-95aa-7edd6e69f587@github.com>
Message-ID: <10xoZG2JntvCbFEDr0rlnAD1iQlmJEzuIoywkD4N8Rk=.cadf8dc8-092f-4b60-b188-696411deb2e8@github.com>

On Mon, 6 Sep 2021 14:00:12 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> src/hotspot/share/memory/allocation.hpp line 444:
>> 
>>> 442:   }
>>> 443: 
>>> 444:   void* operator new [](size_t size) throw() = delete;
>> 
>> I think it should suffice to `delete` this one, with the others completely removed.  I think that name lookup will find this, and one will either get an error because the arguments don't match or because they do match to a deleted function.
>
> Sorry for the delay, can I keep all `= delete`? I have an idea how to fix them in the future.

Sure.

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

PR: https://git.openjdk.java.net/jdk/pull/5055

From ysuenaga at openjdk.java.net  Tue Sep  7 01:43:03 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 7 Sep 2021 01:43:03 GMT
Subject: RFR: 8273104: Refactoring option parser for UL [v2]
In-Reply-To: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
Message-ID: <lvvhqK_N_Fgqo9OnaIqwCvU9NxT-Itu9Kw8sCFqIM9w=.9c6b278b-02e7-4c81-9769-ef1f98025c35@github.com>

> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
> 
> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
> 
> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
> 
> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix condition for error stream

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5293/files
  - new: https://git.openjdk.java.net/jdk/pull/5293/files/e1f098e0..6bc61af5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5293&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5293&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5293

From ysuenaga at openjdk.java.net  Tue Sep  7 01:58:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 7 Sep 2021 01:58:40 GMT
Subject: RFR: 8273104: Refactoring option parser for UL [v2]
In-Reply-To: <PSWiNccrcksgcVwrmufCdYNK6Bfp5rBYc8H5xMHLDJA=.fa8a2df4-97a3-44c3-8978-fb406504d705@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
 <PSWiNccrcksgcVwrmufCdYNK6Bfp5rBYc8H5xMHLDJA=.fa8a2df4-97a3-44c3-8978-fb406504d705@github.com>
Message-ID: <4rT85QeTrnFD941rL8uRJ2Ph9IE41wUtWWJqc8KXqc8=.e3823c57-e262-4ba4-a9a8-b08499dfcbe3@github.com>

On Tue, 7 Sep 2021 00:15:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix condition for error stream
>
> src/hotspot/share/logging/logOutput.cpp line 370:
> 
>> 368:     if (!success) {
>> 369:       if (errstream->count() > errstream_count_before) {
>> 370:         errstream->print_cr("Invalid option '%s' for log output (%s).", key, name());
> 
> I don't quite follow this. If the error count has increased then this was a known option with a bad value that has already been reported in set_option. Here we should be catching an unknown option that wasn't recognized by set_option, in which case the error count should be unchanged no?

Good catch! I fixed it in new commit.

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

PR: https://git.openjdk.java.net/jdk/pull/5293

From ysuenaga at openjdk.java.net  Tue Sep  7 01:58:39 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 7 Sep 2021 01:58:39 GMT
Subject: RFR: 8273104: Refactoring option parser for UL [v2]
In-Reply-To: <lvvhqK_N_Fgqo9OnaIqwCvU9NxT-Itu9Kw8sCFqIM9w=.9c6b278b-02e7-4c81-9769-ef1f98025c35@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
 <lvvhqK_N_Fgqo9OnaIqwCvU9NxT-Itu9Kw8sCFqIM9w=.9c6b278b-02e7-4c81-9769-ef1f98025c35@github.com>
Message-ID: <QgofjNXGP2_WZrvooiLvwAKUPkvW9peWbcnaQEXLyuk=.bd9c4174-3fd9-477c-bf63-0b5121222ac6@github.com>

On Tue, 7 Sep 2021 01:43:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
>> 
>> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
>> 
>> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
>> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
>> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
>> 
>> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix condition for error stream

Thanks David for the comment!

> IIUC these dynamic changes to the options will only apply after argument processing is complete

All of output options can't be changed dynamically. We can see following error when we attempt to do so.
As you said UL for stdout/err can be used before argument processing, however file output isn't so. All of argument processing can be happened at `LogFileOutput::initialize()` and it would call `parse_options()`.


$ jcmd 62838 VM.log list
  <snip>
Log output configuration:
 #0: stdout all=warning uptime,level,tags
 #1: stderr all=off uptime,level,tags
 #2: file=test.log all=info uptime,level,tags filecount=5,filesize=20480K,async=false (reconfigured)

$ jcmd 62838 VM.log output=#2 output_options=foldmultilines=true
62838:
Output options for existing outputs are ignored.


(I can see `reconfigured` label in JDK 16 even if any output options are not accepted from jcmd - it may be bug)

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

PR: https://git.openjdk.java.net/jdk/pull/5293

From iklam at openjdk.java.net  Tue Sep  7 02:02:42 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 7 Sep 2021 02:02:42 GMT
Subject: RFR: 8231356: Fix broken ResourceObj::operator new[] in debug
 builds [v2]
In-Reply-To: <j9tGy777QDfrAupoRalKMcB8xNX3dVojt1nsJ4xqKBY=.536727c7-5e51-4998-93ab-0dc13ac9bad7@github.com>
References: <TRAxAqYZG1l5NzRcAo7RqfPQM2569yg8ogDfrhmuAeM=.77821e7b-c2ab-4738-a866-2202c6c09e3b@github.com>
 <j9tGy777QDfrAupoRalKMcB8xNX3dVojt1nsJ4xqKBY=.536727c7-5e51-4998-93ab-0dc13ac9bad7@github.com>
Message-ID: <4wPp3hzp2jnWUSviHMQMb3NM84P4IkzKFoLxgyA9ZGs=.3ef50054-0b6a-49c9-bf0f-f4dc4111905a@github.com>

On Wed, 11 Aug 2021 11:36:43 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> ResourceObj::operator new[] calls ResourceObj::operator new (non array version). In debug builds, each resource object (on C_HEAP) will be initialized with set_allocation_type() (which is correct). What is not correct is that the constructor (and thus) set_allocation_type() is called on the array itself (which is not a ResourceObj). This initialization will be partially overwritten by the header that keeps track of the array size. When the array destructor later is called, it will also chain call the non-array destructor. In debug builds the verification of _allocation_t[0] will fail as it has been overwritten by the code that keeps track of the array size.
>> 
>> The following assert will fail:
>> assert(~(_allocation_t[0] | allocation_mask) == (uintptr_t)this, "lost resource object");
>> 
>> The reason that it has not been detected is that no one uses ResourceObj::operator new[] on resource objects with C_HEAP storage.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove all other new [] operators in RsourceObj and the delete [] operator as well

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5055

From dholmes at openjdk.java.net  Tue Sep  7 02:42:40 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 7 Sep 2021 02:42:40 GMT
Subject: RFR: 8273104: Refactoring option parser for UL [v2]
In-Reply-To: <lvvhqK_N_Fgqo9OnaIqwCvU9NxT-Itu9Kw8sCFqIM9w=.9c6b278b-02e7-4c81-9769-ef1f98025c35@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
 <lvvhqK_N_Fgqo9OnaIqwCvU9NxT-Itu9Kw8sCFqIM9w=.9c6b278b-02e7-4c81-9769-ef1f98025c35@github.com>
Message-ID: <NcVzA65zv9to-AqeiitVZdAfi0t3pA6vp8WuB3CiskI=.3cadcbc1-2573-416a-b582-90ec91ad088d@github.com>

On Tue, 7 Sep 2021 01:43:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
>> 
>> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
>> 
>> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
>> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
>> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
>> 
>> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix condition for error stream

Hi Yasumasa,

Update looks good.

So my comment about foldMultiLines could only be true for stdout/err and only in the future when it is enabled for those.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5293

From ysuenaga at openjdk.java.net  Tue Sep  7 03:08:38 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 7 Sep 2021 03:08:38 GMT
Subject: RFR: 8273104: Refactoring option parser for UL [v2]
In-Reply-To: <lvvhqK_N_Fgqo9OnaIqwCvU9NxT-Itu9Kw8sCFqIM9w=.9c6b278b-02e7-4c81-9769-ef1f98025c35@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
 <lvvhqK_N_Fgqo9OnaIqwCvU9NxT-Itu9Kw8sCFqIM9w=.9c6b278b-02e7-4c81-9769-ef1f98025c35@github.com>
Message-ID: <dTQUNsVsqOeZpnxen7Ihc05zdRF9NMlXrv8GpJYlNqs=.2d76bc3b-aa49-4e8f-8047-fd9b2edb2a9c@github.com>

On Tue, 7 Sep 2021 01:43:03 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
>> 
>> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
>> 
>> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
>> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
>> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
>> 
>> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix condition for error stream

Thanks David for your review!

> So my comment about foldMultiLines could only be true for stdout/err and only in the future when it is enabled for those.

I agree with you that the problem is not practical concern because the log which happens before argument processing is determinative, so I think we can excuse they are not folded. I'll check what logs can happen before argument processing.

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

PR: https://git.openjdk.java.net/jdk/pull/5293

From github.com+38446717+matias9927 at openjdk.java.net  Tue Sep  7 04:05:54 2021
From: github.com+38446717+matias9927 at openjdk.java.net (Matias Saavedra Silva)
Date: Tue, 7 Sep 2021 04:05:54 GMT
Subject: RFR: 8272608: java_lang_System::allow_security_manager() doesn't set
 its initialization flag
Message-ID: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>

Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

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

Commit messages:
 - Set initialized to true

Changes: https://git.openjdk.java.net/jdk/pull/5268/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5268&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8272608
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5268.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5268/head:pull/5268

PR: https://git.openjdk.java.net/jdk/pull/5268

From coleenp at openjdk.java.net  Tue Sep  7 04:05:55 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 7 Sep 2021 04:05:55 GMT
Subject: RFR: 8272608: java_lang_System::allow_security_manager() doesn't
 set its initialization flag
In-Reply-To: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
References: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
Message-ID: <emIDS5OzrkGVR0UABE-4cpki2xAG6B2FdgFWbsf7E64=.0b0113a1-5202-41c8-a2ed-e89db0f8010e@github.com>

On Thu, 26 Aug 2021 16:00:01 GMT, Matias Saavedra Silva <github.com+38446717+matias9927 at openjdk.org> wrote:

> Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
> Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

This change looks good! thank you for fixing it.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5268

From dholmes at openjdk.java.net  Tue Sep  7 04:58:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 7 Sep 2021 04:58:37 GMT
Subject: RFR: 8272608: java_lang_System::allow_security_manager() doesn't
 set its initialization flag
In-Reply-To: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
References: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
Message-ID: <0kQyG2u82TKci4Wq1dbcegDCpq7GZl8YOLTXdfuxloc=.d6a71b9f-5f2e-43f3-8926-ca870bd5ddb5@github.com>

On Thu, 26 Aug 2021 16:00:01 GMT, Matias Saavedra Silva <github.com+38446717+matias9927 at openjdk.org> wrote:

> Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
> Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

Thanks for the fix Matias!

David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5268

From shade at openjdk.java.net  Tue Sep  7 07:38:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Sep 2021 07:38:42 GMT
Subject: RFR: 8273333: Zero should warn about unimplemented
 -XX:+LogTouchedMethods [v2]
In-Reply-To: <kK6ARbUVm57rOuceSh047Pbwi5m1vVChKTJBQNLJkpY=.d8a8e64e-f29c-412f-954f-e14aee944e99@github.com>
References: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
 <kK6ARbUVm57rOuceSh047Pbwi5m1vVChKTJBQNLJkpY=.d8a8e64e-f29c-412f-954f-e14aee944e99@github.com>
Message-ID: <NZOJnwGvl4N3tRmmheieZc4WdaC0-t0KWMMJFF4Crmo=.e0b80695-4bc3-478d-a64f-04107dda940d@github.com>

On Mon, 6 Sep 2021 07:31:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Currently Zero VM does not implement -XX:+LogTouchedMethods runtime features, which makes `runtime/CommandLine/PrintTouchedMethods.java` tier1 test fail with it.
>> 
>> Instead of implementing it (risking performance and rare bugs), Zero should just reject the option. 
>> 
>> Additional testing:
>>  - [x] Eyeballing failure message
>>  - [x] Affected test does not run with Zero anymore
>>  - [x] Affected test still runs with Server
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the @requries line order

Thanks for reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/5363

From shade at openjdk.java.net  Tue Sep  7 07:38:43 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Sep 2021 07:38:43 GMT
Subject: Integrated: 8273333: Zero should warn about unimplemented
 -XX:+LogTouchedMethods
In-Reply-To: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
References: <6cEjhB-bKG4AVrMptM2RPyRl9Ku9sZEssV_VbjWH_-k=.c61781ad-c123-449f-8904-abdb3699fd6b@github.com>
Message-ID: <13crlnLanY6t625pENBzEuYvKKxLnvUJUJT2YBL_i_A=.b1951fe4-a28f-426c-aaf1-2a496b846671@github.com>

On Fri, 3 Sep 2021 15:29:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently Zero VM does not implement -XX:+LogTouchedMethods runtime features, which makes `runtime/CommandLine/PrintTouchedMethods.java` tier1 test fail with it.
> 
> Instead of implementing it (risking performance and rare bugs), Zero should just reject the option. 
> 
> Additional testing:
>  - [x] Eyeballing failure message
>  - [x] Affected test does not run with Zero anymore
>  - [x] Affected test still runs with Server

This pull request has now been integrated.

Changeset: 81c719be
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/81c719be3995fa54974e8b8826ad81bf07bd012f
Stats:     7 lines in 2 files changed: 6 ins; 0 del; 1 mod

8273333: Zero should warn about unimplemented -XX:+LogTouchedMethods

Reviewed-by: minqi, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5363

From lkorinth at openjdk.java.net  Tue Sep  7 08:27:50 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Sep 2021 08:27:50 GMT
Subject: Integrated: 8231356: Fix broken ResourceObj::operator new[] in debug
 builds
In-Reply-To: <TRAxAqYZG1l5NzRcAo7RqfPQM2569yg8ogDfrhmuAeM=.77821e7b-c2ab-4738-a866-2202c6c09e3b@github.com>
References: <TRAxAqYZG1l5NzRcAo7RqfPQM2569yg8ogDfrhmuAeM=.77821e7b-c2ab-4738-a866-2202c6c09e3b@github.com>
Message-ID: <KJllQ0OI-_rP1vlf_7ODvqO3tSA30phqQCxvsiprONw=.ab3eabf2-5d50-4026-85d6-40625cc4eb71@github.com>

On Mon, 9 Aug 2021 14:31:22 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> ResourceObj::operator new[] calls ResourceObj::operator new (non array version). In debug builds, each resource object (on C_HEAP) will be initialized with set_allocation_type() (which is correct). What is not correct is that the constructor (and thus) set_allocation_type() is called on the array itself (which is not a ResourceObj). This initialization will be partially overwritten by the header that keeps track of the array size. When the array destructor later is called, it will also chain call the non-array destructor. In debug builds the verification of _allocation_t[0] will fail as it has been overwritten by the code that keeps track of the array size.
> 
> The following assert will fail:
> assert(~(_allocation_t[0] | allocation_mask) == (uintptr_t)this, "lost resource object");
> 
> The reason that it has not been detected is that no one uses ResourceObj::operator new[] on resource objects with C_HEAP storage.

This pull request has now been integrated.

Changeset: 3cd95a29
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3cd95a2932ab6a2cb39322354f7ad181de8bfc9e
Stats:     37 lines in 2 files changed: 0 ins; 31 del; 6 mod

8231356: Fix broken ResourceObj::operator new[] in debug builds

Reviewed-by: kbarrett, iklam

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

PR: https://git.openjdk.java.net/jdk/pull/5055

From lkorinth at openjdk.java.net  Tue Sep  7 09:48:48 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Sep 2021 09:48:48 GMT
Subject: RFR: 8273414: ResourceObj::operator delete should handle nullptr in
 debug builds
Message-ID: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>

This is how delete usually works, This is also how FreeHeap and CHeapObj::operator delete works. Delete does handle nullptr in release builds, it is the assert that may crash. Also, as a user it is nice to call delete without first checking the argument for nullptr.

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

Commit messages:
 - 8273414: ResourceObj::operator delete should handle nullptr in debug builds

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

PR: https://git.openjdk.java.net/jdk/pull/5385

From stuefe at openjdk.java.net  Tue Sep  7 10:00:45 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Sep 2021 10:00:45 GMT
Subject: RFR: 8273414: ResourceObj::operator delete should handle nullptr
 in debug builds
In-Reply-To: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>
References: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>
Message-ID: <mn9zmCX1Q9b1Wk5vsNTCsF5UHTNHvMpJ8LAmp7vYVck=.490743cb-0ba1-4d2c-b1a0-2db8abf5bd7b@github.com>

On Tue, 7 Sep 2021 09:40:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This is how delete usually works, This is also how FreeHeap and CHeapObj::operator delete works. Delete does handle nullptr in release builds, it is the assert that may crash. Also, as a user it is nice to call delete without first checking the argument for nullptr.

Seems good and trivial.

However, unrelated to this change, I think operator delete should also work for RA-allocated objects. It should call Arena::Afree() to release the memory if it happens to be on top of the arena. 

At some point we may also improve the arenas and add some form of free block handling for Arena::Afree(), like Metaspace arenas already do. In that case, it would also be able to reclaim memory not on top of the arena.

Cheers, Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5385

From myano at openjdk.java.net  Tue Sep  7 11:12:56 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 7 Sep 2021 11:12:56 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform [v3]
In-Reply-To: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
References: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
Message-ID: <ukMRCMa7AiZIObew2x0frV5u592Got3GHUkpUTi2BQU=.8872bda6-ee63-4428-bd14-2d641864b348@github.com>

> Hi all,
> 
> Could you please review the 8269373 bug fixes?
> 
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4594/files
  - new: https://git.openjdk.java.net/jdk/pull/4594/files/99925f72..655f5db0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=01-02

  Stats: 31 lines in 6 files changed: 16 ins; 9 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4594.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594

PR: https://git.openjdk.java.net/jdk/pull/4594

From myano at openjdk.java.net  Tue Sep  7 11:18:55 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 7 Sep 2021 11:18:55 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform [v3]
In-Reply-To: <ukMRCMa7AiZIObew2x0frV5u592Got3GHUkpUTi2BQU=.8872bda6-ee63-4428-bd14-2d641864b348@github.com>
References: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
 <ukMRCMa7AiZIObew2x0frV5u592Got3GHUkpUTi2BQU=.8872bda6-ee63-4428-bd14-2d641864b348@github.com>
Message-ID: <y7B4NfIWLMKbKtEbIHzp-ERloDgsKuJDDj0dUCAUzF4=.b49f9229-1f7d-4c6e-af06-cbaea2fd4f7d@github.com>

On Tue, 7 Sep 2021 11:12:56 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Hi all,
>> 
>> Could you please review the 8269373 bug fixes?
>> 
>> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

I fixed it to exit silently in case the locale is not US. Thank you.

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

PR: https://git.openjdk.java.net/jdk/pull/4594

From myano at openjdk.java.net  Tue Sep  7 11:18:54 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 7 Sep 2021 11:18:54 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform [v4]
In-Reply-To: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
References: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
Message-ID: <J1__jqbxMyStNVqqdA3t4p4nHjzXh7l1U-y6IDDwDwQ=.dc3ed950-9eb0-4671-97f9-f4a8f090cdd5@github.com>

> Hi all,
> 
> Could you please review the 8269373 bug fixes?
> 
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

Masanori Yano 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 8269373
 - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform
 - 8269373: use test opts for process arguments
 - 8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

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

Changes: https://git.openjdk.java.net/jdk/pull/4594/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=03
  Stats: 15 lines in 3 files changed: 12 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4594.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4594/head:pull/4594

PR: https://git.openjdk.java.net/jdk/pull/4594

From myano at openjdk.java.net  Tue Sep  7 11:26:01 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Tue, 7 Sep 2021 11:26:01 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform [v5]
In-Reply-To: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
References: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
Message-ID: <ATjocDRqPE5reXqEWV8DaYfGruw9159gygv0pH-e6Yc=.50a3cc75-235a-4e4e-bc11-18692efce6ce@github.com>

> Hi all,
> 
> Could you please review the 8269373 bug fixes?
> 
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:

  8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4594/files
  - new: https://git.openjdk.java.net/jdk/pull/4594/files/98e7cfcb..b5a46b4a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4594&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/4594

From shade at openjdk.java.net  Tue Sep  7 13:24:49 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Sep 2021 13:24:49 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
Message-ID: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>

Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.

We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.

Motivational performance improvements below.

Before:


$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
...
00:45:14 ==============================
00:45:14 Test summary
00:45:14 ==============================
00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
00:45:14 ==============================
00:45:14 TEST SUCCESS
00:45:14 
00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'

real	45m14.839s
user	149m49.850s
sys	13m25.849s


After:


$ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
...
00:03:25 ==============================
00:03:25 Test summary
00:03:25 ==============================
00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
00:03:25 ==============================
00:03:25 TEST SUCCESS
00:03:25 
00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'

real	3m24.702s
user	119m7.488s
sys	8m11.716s

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

Commit messages:
 - Remove TEST.properties

Changes: https://git.openjdk.java.net/jdk/pull/5389/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5389&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273433
  Stats: 20 lines in 20 files changed: 0 ins; 20 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5389.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5389/head:pull/5389

PR: https://git.openjdk.java.net/jdk/pull/5389

From david.holmes at oracle.com  Tue Sep  7 13:31:14 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 7 Sep 2021 23:31:14 +1000
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
Message-ID: <274e39a8-f674-788e-3a31-ceee1afc9ae8@oracle.com>

Hi Aleksey,

On 7/09/2021 11:24 pm, Aleksey Shipilev wrote:
> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.

I (or someone) will to need to check the history here. There's always a 
reason tests were set to run exclusively.

Thanks,
David

> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s
> 
> -------------
> 
> Commit messages:
>   - Remove TEST.properties
> 
> Changes: https://git.openjdk.java.net/jdk/pull/5389/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5389&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8273433
>    Stats: 20 lines in 20 files changed: 0 ins; 20 del; 0 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/5389.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/5389/head:pull/5389
> 
> PR: https://git.openjdk.java.net/jdk/pull/5389
> 

From stuefe at openjdk.java.net  Tue Sep  7 13:41:39 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Sep 2021 13:41:39 GMT
Subject: RFR: 8273373: Zero: Handle thread stack sizes with a generic
 Linux code
In-Reply-To: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
Message-ID: <Jzb88rxPdJfn8-D5QUmo7Xjw6ZPj_BgXQIRD8ZgJ51I=.3a93ad06-428e-4fa0-adb7-4f3e4dbd169f@github.com>

On Mon, 6 Sep 2021 09:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

Hi,

I do not see a reason why this would be dependent on !zero. Maybe @GoeLin did not want to deal with it, or the problem did not show up on zero in the first place. 

I think you are right in that gtestlauncher is the only launcher where we end up running in the primordial thread.

Removing ia64 code block is fine. Arguably zero may be the last variant where ia64 would still be useful. Debian seems still to build Zero+ia64 in openjdk15: https://buildd.debian.org/status/logs.php?pkg=openjdk-15&arch=ia64

About the zero gtest errors, do you understand why they only happen in other_vm resp. death tests? Something must be special here. I am curious since invoking JNI on the primordial thread may not be that well tested.

I tried to understand the primordial-thread-stack-boundaries coding, but it left a number of questions. For instance we try to find the primordial stack dimensions by:

- read /proc/self/stat, column 28 ("stackstart", bottom address)
- then we go and find the VMA containing this address, and assume the highest address of this VM is the stack top.

I am not sure the latter always works. Is that not dependent on memory layout? It relies on the process stack having its own VMA, but could the kernel not fold it with a neighboring VMA and show it as one line in /proc/self/maps? In that case, the stack start address we calculate could be bogus.

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

> 3369:       assert((uintptr_t)addr >= stack_extent,
> 3370:              "Sanity: addr should be larger than extent, " PTR_FORMAT " >= " PTR_FORMAT,
> 3371:              p2i(addr), stack_extent);

Should we not do something in non-debug builds too? Maybe guarantee() instead?

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From lkorinth at openjdk.java.net  Tue Sep  7 13:42:35 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 7 Sep 2021 13:42:35 GMT
Subject: RFR: 8273414: ResourceObj::operator delete should handle nullptr
 in debug builds
In-Reply-To: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>
References: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>
Message-ID: <-3pH7xZ8tEPoREFy7AWcBRa51OicLNSQ-62fTsQkMp8=.8700405a-e2ea-4b09-9673-7b287601f08f@github.com>

On Tue, 7 Sep 2021 09:40:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This is how delete usually works, This is also how FreeHeap and CHeapObj::operator delete works. Delete does handle nullptr in release builds, it is the assert that may crash. Also, as a user it is nice to call delete without first checking the argument for nullptr.

Thanks for the review Thomas!

The test failure of `Pre-submit tests - Linux x64 - Test (tier1)` is due to Shenandoah (JDK-8271834). I added a comment to that bug that it is probably not solved, I saw that you reported the bug so you might be interested.

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

PR: https://git.openjdk.java.net/jdk/pull/5385

From shade at openjdk.java.net  Tue Sep  7 13:47:33 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Sep 2021 13:47:33 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <274e39a8-f674-788e-3a31-ceee1afc9ae8@oracle.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
 <274e39a8-f674-788e-3a31-ceee1afc9ae8@oracle.com>
Message-ID: <ZPeEM3nL9jovOniemPl2zniv7QLPQa3fe1cTg3ALLMo=.32fdc6ec-23e3-46c1-bff4-58ba27ca12fd@github.com>

On Tue, 7 Sep 2021 13:33:09 GMT, David Holmes <david.holmes at oracle.com> wrote:

> I (or someone) will to need to check the history here. There's always a reason tests were set to run exclusively.

Please do. `TEST.properties` have no history before OpenJDK, and I found no relevant problems in JBS. These `exclusiveAccess.dir`-s look as something added for extra safety, but we pay dearly for that extra with test time.

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From stuefe at openjdk.java.net  Tue Sep  7 13:47:35 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 7 Sep 2021 13:47:35 GMT
Subject: RFR: 8273414: ResourceObj::operator delete should handle nullptr
 in debug builds
In-Reply-To: <-3pH7xZ8tEPoREFy7AWcBRa51OicLNSQ-62fTsQkMp8=.8700405a-e2ea-4b09-9673-7b287601f08f@github.com>
References: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>
 <-3pH7xZ8tEPoREFy7AWcBRa51OicLNSQ-62fTsQkMp8=.8700405a-e2ea-4b09-9673-7b287601f08f@github.com>
Message-ID: <lwwvqeQaBk4c76c2-SRQ8NeMKg2yrDR1JyLoJc69XbE=.d6c5b6f3-c371-4e4f-89b6-c13ef12aae53@github.com>

On Tue, 7 Sep 2021 13:40:07 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Thanks for the review Thomas!
> 
> The test failure of `Pre-submit tests - Linux x64 - Test (tier1)` is due to Shenandoah (JDK-8271834). I added a comment to that bug that it is probably not solved, I saw that you reported the bug so you might be interested.

Thanks, I see you already commented on the issue. @zhengyu123 is handling that one. I ignore those bugs in GHA for now.

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

PR: https://git.openjdk.java.net/jdk/pull/5385

From shade at openjdk.java.net  Tue Sep  7 15:48:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 7 Sep 2021 15:48:52 GMT
Subject: RFR: 8273440: Zero: Disable runtime/Unsafe/InternalErrorTest.java
Message-ID: <5NepcV6jQcYqw016mvnedX3Sc0kX_Xtf8Tm_oddmBR8=.63a22715-1a98-4fd4-8cc4-03a2717f2a3b@github.com>

JDK-8191278 added a `runtime/Unsafe/InternalErrorTest.java` test to verify that `SIGBUS` during Unsafe copy is converted into the exception. Zero currently crashes this test on `ShouldNotCall()` in signal handler:


# Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:155), pid=2752575, tid=2752589
# Error: ShouldNotCall()


It is unlikely that Zero would implement this functionality, so it seems prudent to disable the test to get clean tier1 for Zero.

Additional testing:
 - [x] Linux x86_64 Zero, test is now disabled
 - [x] Linux x86_64 Server, test still runs

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/5394/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5394&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273440
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5394.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5394/head:pull/5394

PR: https://git.openjdk.java.net/jdk/pull/5394

From naoto at openjdk.java.net  Tue Sep  7 16:14:37 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 7 Sep 2021 16:14:37 GMT
Subject: RFR: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform [v5]
In-Reply-To: <ATjocDRqPE5reXqEWV8DaYfGruw9159gygv0pH-e6Yc=.50a3cc75-235a-4e4e-bc11-18692efce6ce@github.com>
References: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
 <ATjocDRqPE5reXqEWV8DaYfGruw9159gygv0pH-e6Yc=.50a3cc75-235a-4e4e-bc11-18692efce6ce@github.com>
Message-ID: <yYjxYSUOlYswCwR64wWS9fVBsOzoKHucq8WAh2ZVX74=.8984880f-099e-45b3-8bc1-019985a4bd88@github.com>

On Tue, 7 Sep 2021 11:26:01 GMT, Masanori Yano <myano at openjdk.org> wrote:

>> Hi all,
>> 
>> Could you please review the 8269373 bug fixes?
>> 
>> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.
>
> Masanori Yano has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

Thanks. Looks good to me.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4594

From cjplummer at openjdk.java.net  Tue Sep  7 18:07:39 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Tue, 7 Sep 2021 18:07:39 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <crJcuaqSgYZQCEw2lqGaLpRmCVOXr99P1i5bcnSFpQc=.cb824923-e649-4ecd-ba5b-8d26cb93b265@github.com>
 <esex_demB2ZT0CsAp2WrzNGC_gieM9USGg_fYgmFCAE=.1911dd08-7dcc-4d88-9532-5d670399dd62@github.com>
 <ztN32xTk5joNRB7MhfYMl9zHCfGA1j8bQNu-ke975qc=.4c7ff2a9-2af8-495d-8f22-83e98c2e3221@github.com>
 <oQe3_j7vewkS8wlIuYXRCa_86pI215cFIceztTf5jX0=.d6d6201b-ec15-418e-a73b-e907d9d02607@github.com>
 <oPJ9OfKdD8CTbihLREww1QM2hc3Ckiai0-1OSpkq830=.87c4f119-07c9-471f-8c25-99dcfaad8d11@github.com>
Message-ID: <ddcFu2jZkOBviozKIZHFwJVI7WKGy5Lgf07o7EuI4E8=.ff5cb480-c3d8-4c17-8371-8a1c4e98b683@github.com>

On Thu, 28 Jan 2021 07:30:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Hi Lin,
> It is also in my memory that you actually did not have 4 arguments.
> The real incompatibility issue was that the order of arguments was swapped.
> It is why it was relatively easy to fall back and just update the constants with 3 instead of 4 and swap the order of arguments back.
> Thanks,
> Serguei

@sspitsyn or @schmelter-sap Can one of you provide a second review for this change. The GC team would like to start a review for changes that will heavily impact this same code, so it would be best if these changes could be pushed first.

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From lmesnik at openjdk.java.net  Tue Sep  7 19:44:19 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Tue, 7 Sep 2021 19:44:19 GMT
Subject: RFR: 8273451: Remove unreachable return in mutexLocker::wait
Message-ID: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>

Refactored  mutexLocker::wait to return redundant unreachable "return false;"

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

Commit messages:
 - 8273451

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

PR: https://git.openjdk.java.net/jdk/pull/5398

From minqi at openjdk.java.net  Tue Sep  7 20:49:03 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 7 Sep 2021 20:49:03 GMT
Subject: RFR: 8273451: Remove unreachable return in mutexLocker::wait
In-Reply-To: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
References: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
Message-ID: <fbcxXQRk7Z4aA5Cn1qaLnVFXySF01bqLL-Igsm7pMXU=.8b705454-31df-4bc8-97f7-9eaebd5f4f3d@github.com>

On Tue, 7 Sep 2021 19:38:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Refactored  mutexLocker::wait to return redundant unreachable "return false;"

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5398

From coleenp at openjdk.java.net  Tue Sep  7 21:46:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 7 Sep 2021 21:46:06 GMT
Subject: RFR: 8273451: Remove unreachable return in mutexLocker::wait
In-Reply-To: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
References: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
Message-ID: <_hMY7xDYWNjeRSSxldNfJSi8b_8NLCg4C1oUgdcLVUI=.5b03ab2f-dce8-4a05-840b-77c47f0139e8@github.com>

On Tue, 7 Sep 2021 19:38:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Refactored  mutexLocker::wait to return redundant unreachable "return false;"

This looks good!

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5398

From coleenp at openjdk.java.net  Tue Sep  7 22:25:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 7 Sep 2021 22:25:05 GMT
Subject: RFR: 8272608: java_lang_System::allow_security_manager() doesn't
 set its initialization flag
In-Reply-To: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
References: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
Message-ID: <0CLRTqyi_biYeCJM7GQyEWTA7qFkYcuHsl_t07fQNFA=.7165a24f-c67c-4772-8cb4-9b1f6286920c@github.com>

On Thu, 26 Aug 2021 16:00:01 GMT, Matias Saavedra Silva <github.com+38446717+matias9927 at openjdk.org> wrote:

> Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
> Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

I can sponsor this now that Matias has OCA coverage.  Thanks Matias!

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

PR: https://git.openjdk.java.net/jdk/pull/5268

From dcubed at openjdk.java.net  Wed Sep  8 00:37:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 00:37:27 GMT
Subject: Integrated: 8273462: ProblemList
 vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode
Message-ID: <KvngP5-K9_FWDi0A0Bz1d6e2qrEoG14tUwReYLDQYpU=.5e07379b-91eb-4c93-9a10-6864e92370b4@github.com>

A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode.

There are currently 17 sightings (so far) on linux-X64, macOS-X64, and win-X64.

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

Commit messages:
 - 8273462: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode

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

PR: https://git.openjdk.java.net/jdk/pull/5404

From dholmes at openjdk.java.net  Wed Sep  8 00:37:27 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 00:37:27 GMT
Subject: Integrated: 8273462: ProblemList
 vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode
In-Reply-To: <KvngP5-K9_FWDi0A0Bz1d6e2qrEoG14tUwReYLDQYpU=.5e07379b-91eb-4c93-9a10-6864e92370b4@github.com>
References: <KvngP5-K9_FWDi0A0Bz1d6e2qrEoG14tUwReYLDQYpU=.5e07379b-91eb-4c93-9a10-6864e92370b4@github.com>
Message-ID: <E7o-Qa1AqeIp4dkwxSKkg0iTKtmI7botN5Uq8-8jvJ0=.23d2e785-6684-41ee-9f93-386458fb72f3@github.com>

On Wed, 8 Sep 2021 00:25:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode.
> 
> There are currently 17 sightings (so far) on linux-X64, macOS-X64, and win-X64.

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5404

From dcubed at openjdk.java.net  Wed Sep  8 00:37:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 00:37:27 GMT
Subject: Integrated: 8273462: ProblemList
 vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode
In-Reply-To: <E7o-Qa1AqeIp4dkwxSKkg0iTKtmI7botN5Uq8-8jvJ0=.23d2e785-6684-41ee-9f93-386458fb72f3@github.com>
References: <KvngP5-K9_FWDi0A0Bz1d6e2qrEoG14tUwReYLDQYpU=.5e07379b-91eb-4c93-9a10-6864e92370b4@github.com>
 <E7o-Qa1AqeIp4dkwxSKkg0iTKtmI7botN5Uq8-8jvJ0=.23d2e785-6684-41ee-9f93-386458fb72f3@github.com>
Message-ID: <_zKNzeAcTOC1VeRlLLZsAQFv1APHBM5EvdTKd_CeNe8=.6335cfa1-8e2f-49f6-9cfa-9e6b93c2e9ff@github.com>

On Wed, 8 Sep 2021 00:27:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode.
>> 
>> There are currently 17 sightings (so far) on linux-X64, macOS-X64, and win-X64.
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora - Thanks for the lightning fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5404

From dcubed at openjdk.java.net  Wed Sep  8 00:37:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 00:37:27 GMT
Subject: Integrated: 8273462: ProblemList
 vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode
In-Reply-To: <KvngP5-K9_FWDi0A0Bz1d6e2qrEoG14tUwReYLDQYpU=.5e07379b-91eb-4c93-9a10-6864e92370b4@github.com>
References: <KvngP5-K9_FWDi0A0Bz1d6e2qrEoG14tUwReYLDQYpU=.5e07379b-91eb-4c93-9a10-6864e92370b4@github.com>
Message-ID: <Vii44zrXNUrHadyauobHY-NaVulb2thHsG67vvgVmTs=.7e7e1e8c-d93d-487f-bef9-bfca0d30fbb2@github.com>

On Wed, 8 Sep 2021 00:25:37 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode.
> 
> There are currently 17 sightings (so far) on linux-X64, macOS-X64, and win-X64.

This pull request has now been integrated.

Changeset: 8884d2f8
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8884d2f854fafdc5f775fce557053d072e4a882c
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8273462: ProblemList vmTestbase/vm/mlvm/anonloader/stress/oome/heap/Test.java in -Xcomp mode

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5404

From dholmes at openjdk.java.net  Wed Sep  8 01:01:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 01:01:08 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
Message-ID: <nJWckJcMq-B8G21nvqkqrnEpd7JM8zDoBnm2gaAtEnI=.9f57cbac-4e50-42f4-b5bd-b60ab4091b33@github.com>

On Tue, 7 Sep 2021 13:17:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
> 
> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14 
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25 
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s

I suspect it was simply the fact that these were stress tests that resulted in them being executed in isolation. Otherwise if the concurrency level is just wrong I would expect these to cause intermittent failures when run in parallel. I will ask Misha to respond here (can't locate his OpenJDK tag :( ).

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From dholmes at openjdk.java.net  Wed Sep  8 01:06:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 01:06:08 GMT
Subject: RFR: 8273451: Remove unreachable return in mutexLocker::wait
In-Reply-To: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
References: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
Message-ID: <3Xgs6Xw6soT6VPT8Kc6IAi8SfgcEQ4l8mDSj13JbfXU=.9dddf4ec-a9a8-4181-b4b8-ac2ebb86b66e@github.com>

On Tue, 7 Sep 2021 19:38:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Refactored  mutexLocker::wait to return redundant unreachable "return false;"

I think the change to the ?: operator was unnecessary and does not improve readability. YMMV.

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

PR: https://git.openjdk.java.net/jdk/pull/5398

From dholmes at openjdk.java.net  Wed Sep  8 01:08:10 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 01:08:10 GMT
Subject: RFR: 8273440: Zero: Disable runtime/Unsafe/InternalErrorTest.java
In-Reply-To: <5NepcV6jQcYqw016mvnedX3Sc0kX_Xtf8Tm_oddmBR8=.63a22715-1a98-4fd4-8cc4-03a2717f2a3b@github.com>
References: <5NepcV6jQcYqw016mvnedX3Sc0kX_Xtf8Tm_oddmBR8=.63a22715-1a98-4fd4-8cc4-03a2717f2a3b@github.com>
Message-ID: <RnuAMXL6kyxuKNA4PFV2myHZ7v-zYzUFV4bRoNvnHTQ=.f14579c1-779f-4ba4-bcdf-23078089c856@github.com>

On Tue, 7 Sep 2021 15:40:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8191278 added a `runtime/Unsafe/InternalErrorTest.java` test to verify that `SIGBUS` during Unsafe copy is converted into the exception. Zero currently crashes this test on `ShouldNotCall()` in signal handler:
> 
> 
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:155), pid=2752575, tid=2752589
> # Error: ShouldNotCall()
> 
> 
> It is unlikely that Zero would implement this functionality, so it seems prudent to disable the test to get clean tier1 for Zero.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, test is now disabled
>  - [x] Linux x86_64 Server, test still runs

Seems fine and trivial.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5394

From ysuenaga at openjdk.java.net  Wed Sep  8 01:30:09 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 8 Sep 2021 01:30:09 GMT
Subject: Integrated: 8273104: Refactoring option parser for UL
In-Reply-To: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
References: <d9MivofvospxznxcbM_C6-a4PzmE01TDM1BuHDUIFOA=.47219077-0146-4956-9118-3f984db20e51@github.com>
Message-ID: <5Wyf1YgqElPMlTaMvWeUGHNHkcsyjMOLHBYkASbTKuo=.0551f84a-da3a-4993-be4b-77e1db3dc946@github.com>

On Sun, 29 Aug 2021 03:48:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> As we discussed in PR #4885 and in [its CSR](https://bugs.openjdk.java.net/browse/JDK-8271188), we want to introduce `foldmultilines` to stdout/err UL output. However we have no chance to configure `LogOutput` for stdout/err (`LogStdoutOutput`/`LogStderrOutput`) becasuse they will be instantiated statically in logFileStreamOutput.cpp.
> 
> So we need to refactor UL option parser to propagate options to all extended classes of `LogOutput`.
> 
> * Move `parse_option()` to `LogOutput` from `LogFileOutput`, then it becames public member.
> * Introduce `set_option()` in `LogOutput` as a pure virtual member to apply options to each log output, then it is implemented in both `LogFileStreamOutput` and `LogFileOutput`.
> * Move both `FoldMultilinesOptionKey` and `_fold_mulilines` in `LogFileStreamOutput` to private member because they are no longer to need to be public.
> 
> I want to send PR to introduce `foldmultilines` to stdout/err like https://github.com/YaSuenag/jdk/compare/ul-refactoring...YaSuenag:foldmultilines-for-stdout after this.

This pull request has now been integrated.

Changeset: 4eacdb38
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4eacdb38a83b545603928392eccb116c744ef3b3
Stats:     126 lines in 7 files changed: 65 ins; 45 del; 16 mod

8273104: Refactoring option parser for UL

Reviewed-by: iklam, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5293

From dholmes at openjdk.java.net  Wed Sep  8 01:36:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 01:36:07 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
Message-ID: <AxS2-AYUiR8JTHcydx4jgi-6TP9CZ339_50Ho7dipT0=.d3d8bb83-a4df-42b6-ae97-6f2c876653c7@github.com>

On Tue, 7 Sep 2021 13:17:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
> 
> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14 
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25 
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s

I'm also concerned that hard-wiring this sort of thing is never going to make everyone happy. Probably what we need is a way to disable "exclusiveDirs" processing on the jtreg command-line ... though that would need some finer-level of control to make it useful.

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From dcubed at openjdk.java.net  Wed Sep  8 02:16:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 02:16:18 GMT
Subject: Integrated: 8273047: test jfr/api/consumer/TestRecordedFrame.java
 timing out
Message-ID: <odDjNwTjrozpNYNfOt2ng_T7lp_Ahtd1kEiBwedykBc=.ea456188-f929-4542-b1d7-696f1dd2238c@github.com>

A trivial fix to bump the timeout value for the second sub-test in
jfr/api/consumer/TestRecordedFrame.java. See the bug report
for the gory details.

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

Commit messages:
 - 8273047: test jfr/api/consumer/TestRecordedFrame.java timing out

Changes: https://git.openjdk.java.net/jdk/pull/5405/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5405&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273047
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5405.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5405/head:pull/5405

PR: https://git.openjdk.java.net/jdk/pull/5405

From dholmes at openjdk.java.net  Wed Sep  8 02:16:18 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 02:16:18 GMT
Subject: Integrated: 8273047: test jfr/api/consumer/TestRecordedFrame.java
 timing out
In-Reply-To: <odDjNwTjrozpNYNfOt2ng_T7lp_Ahtd1kEiBwedykBc=.ea456188-f929-4542-b1d7-696f1dd2238c@github.com>
References: <odDjNwTjrozpNYNfOt2ng_T7lp_Ahtd1kEiBwedykBc=.ea456188-f929-4542-b1d7-696f1dd2238c@github.com>
Message-ID: <Mvuogi8WvhidfUZtNfA1pUx7GN2XGYQuysH-8HZ3r3Q=.240819c0-f31d-4ae5-846a-8bd56703fb0b@github.com>

On Wed, 8 Sep 2021 02:04:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to bump the timeout value for the second sub-test in
> jfr/api/consumer/TestRecordedFrame.java. See the bug report
> for the gory details.

LGTM!

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5405

From dcubed at openjdk.java.net  Wed Sep  8 02:16:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 02:16:18 GMT
Subject: Integrated: 8273047: test jfr/api/consumer/TestRecordedFrame.java
 timing out
In-Reply-To: <odDjNwTjrozpNYNfOt2ng_T7lp_Ahtd1kEiBwedykBc=.ea456188-f929-4542-b1d7-696f1dd2238c@github.com>
References: <odDjNwTjrozpNYNfOt2ng_T7lp_Ahtd1kEiBwedykBc=.ea456188-f929-4542-b1d7-696f1dd2238c@github.com>
Message-ID: <rPSaQ2i27AcOXJwO7ohb3zFDGbelSW2gV61BqlojPxQ=.7d75d960-af96-4692-9b82-a4e44bbaeb7b@github.com>

On Wed, 8 Sep 2021 02:04:50 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to bump the timeout value for the second sub-test in
> jfr/api/consumer/TestRecordedFrame.java. See the bug report
> for the gory details.

This pull request has now been integrated.

Changeset: ea4907a8
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea4907a8789e00f9ec8d4175241246b8cf53f3f6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8273047: test jfr/api/consumer/TestRecordedFrame.java timing out

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5405

From dcubed at openjdk.java.net  Wed Sep  8 02:16:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 02:16:18 GMT
Subject: Integrated: 8273047: test jfr/api/consumer/TestRecordedFrame.java
 timing out
In-Reply-To: <Mvuogi8WvhidfUZtNfA1pUx7GN2XGYQuysH-8HZ3r3Q=.240819c0-f31d-4ae5-846a-8bd56703fb0b@github.com>
References: <odDjNwTjrozpNYNfOt2ng_T7lp_Ahtd1kEiBwedykBc=.ea456188-f929-4542-b1d7-696f1dd2238c@github.com>
 <Mvuogi8WvhidfUZtNfA1pUx7GN2XGYQuysH-8HZ3r3Q=.240819c0-f31d-4ae5-846a-8bd56703fb0b@github.com>
Message-ID: <O25VHWzpW3-JY6Wb7cQx29SWJpgR1cqfT01YxjUE8Ss=.5e9e8ec6-6de6-49bd-934e-3dcc73040f18@github.com>

On Wed, 8 Sep 2021 02:07:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to bump the timeout value for the second sub-test in
>> jfr/api/consumer/TestRecordedFrame.java. See the bug report
>> for the gory details.
>
> LGTM!
> 
> Thanks,
> David

@dholmes-ora - Thanks for the lightning fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5405

From lmesnik at openjdk.java.net  Wed Sep  8 03:12:05 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 8 Sep 2021 03:12:05 GMT
Subject: RFR: 8273451: Remove unreachable return in mutexLocker::wait
In-Reply-To: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
References: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
Message-ID: <NuMww7WvA8LqWEf3Ou4ogg6l0Wp59dsbxY2Wc5njgM4=.5282ef07-0c57-4032-bdf3-d35bec12da23@github.com>

On Tue, 7 Sep 2021 19:38:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Refactored  mutexLocker::wait to return redundant unreachable "return false;"

I don't see a big difference here but prefer ?: in such cases. Just a little more compact.

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

PR: https://git.openjdk.java.net/jdk/pull/5398

From rschmelter at openjdk.java.net  Wed Sep  8 05:05:13 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Wed, 8 Sep 2021 05:05:13 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
Message-ID: <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>

On Mon, 6 Sep 2021 08:03:22 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build error

I will start reviewing this today.

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From stuefe at openjdk.java.net  Wed Sep  8 07:46:06 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 8 Sep 2021 07:46:06 GMT
Subject: RFR: 8273373: Zero: Handle thread stack sizes with a generic
 Linux code
In-Reply-To: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
Message-ID: <BWVcVbDCdVeVv-WvKJWgpxxB_1k2QUUGlfC6eO7TL7Q=.6dc3a154-5c3c-4f1b-98c2-d02abd6d9dcb@github.com>

On Mon, 6 Sep 2021 09:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

I got curious and analyzed this further. Let's see if I got this correctly.

When we create the VM on the primordial thread, we locate the stack boundaries for the primordial thread in `os::Linux::capture_initial_stack()`: 

There, we basically look for the boundaries of the primordial thread stack in `/proc/pid/maps`. We manage to locate the correct VMA for the primordial stack. But then we do not simply take the boundary of that VMA as stack boundary. Instead, we take the high VMA address, subtract an assumed stack size (calculated from -Xss and RLIMIT_STACK), then take that address as stack bottom (`_initial_thread_stack_bottom`). 

Seems that that assumed stack size can be smaller than the real size of the stack, resulting in an offset between the real stack VMA low address and `_initial_thread_stack_bottom`. 

That in itself would be not a problem, but in `StackOverflow::create_stack_guard_pages()` we place the guard pages at an address which we calculate from `os::current_stack_base()`. `os::current_stack_base()` calls `current_stack_region()`, which on Zero just calls `pthread_attr_getstack(3)`, ignoring the previously captured `_initial_thread_stack_bottom`.

In `os::pd_create_stack_guard_pages()` we then essentially use both values -  `os::current_stack_base()` and `_initial_thread_stack_bottom` - to calculate the arguments to `get_stack_commited_bottom()`. The resulting assert is caused by mixing those conflicting values.

Bottomline, we should either be using `pthread_attr_getstack(3)` or our `_initial_thread_stack_(bottom|size)` but not mix them since they may differ. Therefore the proposed patch is correct. The non-zero version of `current_stack_region()` in os_linux.cpp handles the primordial thread stack correctly.

---

There are a number of additional beauty spots, like the fact that in `get_stack_commited_bottom()` the `pages` variable is 32bit unsigned. So the assert itself is random in that it depends on whether or not the overflow produces a negative overflow.

Also, I don't understand the logic in `os::pd_create_stack_guard_pages()` where the "fallback" is to call mincore() with what basically would be a zero size? Since both `addr` and `stack_extend` are the stack bottom.

---

I would probably rename the issue to "Cannot invoke JVM in primordial threads on Zero".

Cheers, Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Wed Sep  8 07:48:14 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 07:48:14 GMT
Subject: RFR: 8273440: Zero: Disable runtime/Unsafe/InternalErrorTest.java
In-Reply-To: <5NepcV6jQcYqw016mvnedX3Sc0kX_Xtf8Tm_oddmBR8=.63a22715-1a98-4fd4-8cc4-03a2717f2a3b@github.com>
References: <5NepcV6jQcYqw016mvnedX3Sc0kX_Xtf8Tm_oddmBR8=.63a22715-1a98-4fd4-8cc4-03a2717f2a3b@github.com>
Message-ID: <SwvqGEoTp4PHKFksVDbLtECZ40SsOBxX4SkwQ5xVkto=.6ac09d70-edb2-4707-aa72-ace6690b45cd@github.com>

On Tue, 7 Sep 2021 15:40:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8191278 added a `runtime/Unsafe/InternalErrorTest.java` test to verify that `SIGBUS` during Unsafe copy is converted into the exception. Zero currently crashes this test on `ShouldNotCall()` in signal handler:
> 
> 
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:155), pid=2752575, tid=2752589
> # Error: ShouldNotCall()
> 
> 
> It is unlikely that Zero would implement this functionality, so it seems prudent to disable the test to get clean tier1 for Zero.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, test is now disabled
>  - [x] Linux x86_64 Server, test still runs

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5394

From shade at openjdk.java.net  Wed Sep  8 07:48:15 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 07:48:15 GMT
Subject: Integrated: 8273440: Zero: Disable
 runtime/Unsafe/InternalErrorTest.java
In-Reply-To: <5NepcV6jQcYqw016mvnedX3Sc0kX_Xtf8Tm_oddmBR8=.63a22715-1a98-4fd4-8cc4-03a2717f2a3b@github.com>
References: <5NepcV6jQcYqw016mvnedX3Sc0kX_Xtf8Tm_oddmBR8=.63a22715-1a98-4fd4-8cc4-03a2717f2a3b@github.com>
Message-ID: <WDoAHRpPX2hCfNCZ9cTzqjtETYemEbvLB0K8QcUjDFs=.787076b4-627e-409e-a2b9-86f06074d170@github.com>

On Tue, 7 Sep 2021 15:40:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8191278 added a `runtime/Unsafe/InternalErrorTest.java` test to verify that `SIGBUS` during Unsafe copy is converted into the exception. Zero currently crashes this test on `ShouldNotCall()` in signal handler:
> 
> 
> # Internal Error (/home/shade/trunks/jdk/src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp:155), pid=2752575, tid=2752589
> # Error: ShouldNotCall()
> 
> 
> It is unlikely that Zero would implement this functionality, so it seems prudent to disable the test to get clean tier1 for Zero.
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, test is now disabled
>  - [x] Linux x86_64 Server, test still runs

This pull request has now been integrated.

Changeset: 286a1f6b
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/286a1f6b7c6d7c598ced456f1a5f63cac1be8539
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8273440: Zero: Disable runtime/Unsafe/InternalErrorTest.java

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5394

From shade at openjdk.java.net  Wed Sep  8 08:25:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 08:25:06 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <nJWckJcMq-B8G21nvqkqrnEpd7JM8zDoBnm2gaAtEnI=.9f57cbac-4e50-42f4-b5bd-b60ab4091b33@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
 <nJWckJcMq-B8G21nvqkqrnEpd7JM8zDoBnm2gaAtEnI=.9f57cbac-4e50-42f4-b5bd-b60ab4091b33@github.com>
Message-ID: <aKS655X8Woex65vIRK87c4B3vVrE9cwS3bvoKJ1DCr8=.d9ff2136-b597-4a78-b638-4a94bac2f3c3@github.com>

On Wed, 8 Sep 2021 00:58:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I suspect it was simply the fact that these were stress tests that resulted in them being executed in isolation. Otherwise if the concurrency level is just wrong I would expect these to cause intermittent failures when run in parallel. 

Yeah, I generally agree with this. Blind parallelism improvements should not be done, and we should only allow the stress tests that are not heavy on resources to run in parallel. The tests affected in this PR seem to be rather short, effectively single-threaded, and memory-dense tests, so they seem to qualify for this kind of relaxation. I'll wait for Misha to respond.

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From ysuenaga at openjdk.java.net  Wed Sep  8 09:21:24 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 8 Sep 2021 09:21:24 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err
Message-ID: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>

We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.

`foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.

`foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.


share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);

share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "

share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));


I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`

In addition, we might see following logs which relate to UL:


[0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
[0.000s][error][logging] Invalid tag 'aaa' in log selection.
[0.000s][error][logging] Invalid level 'aaa' in log selection.
[0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
[0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
[0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

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

Commit messages:
 - 8273471: Add foldmultilines to UL for stdout/err

Changes: https://git.openjdk.java.net/jdk/pull/5407/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273471
  Stats: 76 lines in 3 files changed: 50 ins; 8 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5407/head:pull/5407

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Wed Sep  8 09:21:24 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Wed, 8 Sep 2021 09:21:24 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <-37L2bthVqBlqErqtJRx3_yMH9keeKgA2SQTyWuB8Xo=.1dc46f2a-eb37-4251-9209-e0aec0423f79@github.com>

On Wed, 8 Sep 2021 06:12:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

gc/metaspace/TestMetaspacePerfCounters.java#id3 failed on GitHub Actions, but it does not seem to be caused by this change.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From shade at openjdk.java.net  Wed Sep  8 09:22:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 09:22:08 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero
In-Reply-To: <BWVcVbDCdVeVv-WvKJWgpxxB_1k2QUUGlfC6eO7TL7Q=.6dc3a154-5c3c-4f1b-98c2-d02abd6d9dcb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <BWVcVbDCdVeVv-WvKJWgpxxB_1k2QUUGlfC6eO7TL7Q=.6dc3a154-5c3c-4f1b-98c2-d02abd6d9dcb@github.com>
Message-ID: <LyyYk52UczFQ6_9d8Lfk6gN6jNEYxbkpjE4LnWv1Je8=.29f77cb9-2cb0-47ac-b56c-ede82d3a216b@github.com>

On Wed, 8 Sep 2021 07:43:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Bottomline, we should either be using `pthread_attr_getstack(3)` or our `_initial_thread_stack_(bottom|size)` but not mix them since they may differ. Therefore the proposed patch is correct. The non-zero version of `current_stack_region()` in os_linux.cpp handles the primordial thread stack correctly.

Yes, that seems to be the gist of it. In fact, if I reply `_initial_thread_stack_(bottom|size)` in Zero version of `current_stack_region()` for a primordial thread, gtests also start to pass. But I gather there is no need to continue supporting Zero-specific `current_stack_region()`, and thus dodge the issue altogether by using the code the rest of VM code uses.

> src/hotspot/os/linux/os_linux.cpp line 3371:
> 
>> 3369:       assert((uintptr_t)addr >= stack_extent,
>> 3370:              "Sanity: addr should be larger than extent, " PTR_FORMAT " >= " PTR_FORMAT,
>> 3371:              p2i(addr), stack_extent);
> 
> Should we not do something in non-debug builds too? Maybe guarantee() instead?

Nah, I think `assert` is okay here. It is supposed to aid debugging, not crash hard.

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Wed Sep  8 10:26:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 10:26:06 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero
In-Reply-To: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
Message-ID: <tWPWbXYYEC1pDWHWEmhTG3moBnSqTNZGle-Ieb698Sk=.ddfa2fa2-703b-4952-8df1-84bf99f04870@github.com>

On Mon, 6 Sep 2021 09:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

I looked around Debian's support for IA64, and I think we don't want to drop the support for it just yet. Zero VM is one of those last stands for weird arches portability :) Instead of adding the `IA64` block to a shared code, I shall try to make a more conservative fix to Zero-specific code then...

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Wed Sep  8 11:06:18 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 11:06:18 GMT
Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests
Message-ID: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>

JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:


$ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java

STDERR:
java.lang.Error: TESTBUG: unsupported vm variant
at jdk.test.lib.Platform.variant(Platform.java:368)
at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 


Additional testing:
 - [ ] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run

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

Commit messages:
 - Fix

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From alanb at openjdk.java.net  Wed Sep  8 11:19:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Sep 2021 11:19:06 GMT
Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests
In-Reply-To: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
References: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
Message-ID: <ZLrSq3i3AddayStSzDxapnvM9Clv-6q-3SFoXoxvGCI=.a691926c-f7ee-49e5-b3fa-6cd9f4a3635e@github.com>

On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java
> 
> STDERR:
> java.lang.Error: TESTBUG: unsupported vm variant
> at jdk.test.lib.Platform.variant(Platform.java:368)
> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 
> 
> 
> Additional testing:
>  - [ ] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From coleenp at openjdk.java.net  Wed Sep  8 12:00:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 8 Sep 2021 12:00:10 GMT
Subject: RFR: 8272608: java_lang_System::allow_security_manager() doesn't
 set its initialization flag
In-Reply-To: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
References: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
Message-ID: <awvp9XOM_pw-_oXcoDGwmfzBinqRpcdDF1FCyi1U_lk=.1c373971-6ed9-4739-ba94-6fa4ae4997ee@github.com>

On Thu, 26 Aug 2021 16:00:01 GMT, Matias Saavedra Silva <github.com+38446717+matias9927 at openjdk.org> wrote:

> Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
> Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

@matias9927 check your email! You can /integrate this and have to do this before I /sponsor it.

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

PR: https://git.openjdk.java.net/jdk/pull/5268

From dholmes at openjdk.java.net  Wed Sep  8 13:02:05 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 13:02:05 GMT
Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests
In-Reply-To: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
References: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
Message-ID: <86fqEtk6YKiecpQFyPaSgjD5XM2xKYfT-BrVcie34lQ=.4ea5f855-cb1a-4246-a1d2-7854c2c04966@github.com>

On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java
> 
> STDERR:
> java.lang.Error: TESTBUG: unsupported vm variant
> at jdk.test.lib.Platform.variant(Platform.java:368)
> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 
> 
> 
> Additional testing:
>  - [ ] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From shade at openjdk.java.net  Wed Sep  8 13:25:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 13:25:27 GMT
Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests
In-Reply-To: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
References: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
Message-ID: <uwBBgCV4M0Z-2t9B-ZVfelTgQsjDPyBbM8yLLgbOCpE=.095cb70b-c127-46fa-9b5b-7d8f3ad3ebe2@github.com>

On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java
> 
> STDERR:
> java.lang.Error: TESTBUG: unsupported vm variant
> at jdk.test.lib.Platform.variant(Platform.java:368)
> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run

Huh, it turns out there is the awkwardness in the build system that puts product `libjvm.so` to `server` for Zero. See [JDK-8273494](https://bugs.openjdk.java.net/browse/JDK-8273494). This was not the cause for gtest `libjvm.so`, which is in `zero` folder for Zero. So I had to make it more awkward until the build system fix is here. See new commit.

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From shade at openjdk.java.net  Wed Sep  8 13:25:27 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 8 Sep 2021 13:25:27 GMT
Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests [v2]
In-Reply-To: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
References: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
Message-ID: <NWE5FMgkpOth-1g9q9EKXMSx8SpQcy22N7K62I5pWRw=.682edff3-22c2-400d-b9a8-e477ce4bd8d0@github.com>

> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java
> 
> STDERR:
> java.lang.Error: TESTBUG: unsupported vm variant
> at jdk.test.lib.Platform.variant(Platform.java:368)
> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run

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

  Build system awkwardness ensues

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5413/files
  - new: https://git.openjdk.java.net/jdk/pull/5413/files/141d8184..40998df5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5413&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5413&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From myano at openjdk.java.net  Wed Sep  8 15:51:10 2021
From: myano at openjdk.java.net (Masanori Yano)
Date: Wed, 8 Sep 2021 15:51:10 GMT
Subject: Integrated: 8269373: some tests in jdk/tools/launcher/ fails on
 localized Windows platform
In-Reply-To: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
References: <QQYpxvbHMYYM_Rf5rOM__7Lv_qPNLSoUagvHth2CrIY=.e9355440-088d-4391-b75f-dfdbc9db2472@github.com>
Message-ID: <xKLr599IN5NzQciJuSTtY3PONImFYPMjhnGKVQdzaro=.1192b16c-5ebb-4e02-9764-2ea2bb3b7b8f@github.com>

On Fri, 25 Jun 2021 12:10:18 GMT, Masanori Yano <myano at openjdk.org> wrote:

> Hi all,
> 
> Could you please review the 8269373 bug fixes?
> 
> These tests call java.lang.ProcessBuilder in direct, so not used jtreg command option. To run non-localized tests, -Duser.language=en and -Duser.country=US options should be added in ProcessBuilder.

This pull request has now been integrated.

Changeset: cb112aff
Author:    Masanori Yano <myano at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cb112affd6061e8ace6dad4e92c7b394a413e37f
Stats:     14 lines in 2 files changed: 12 ins; 0 del; 2 mod

8269373: some tests in jdk/tools/launcher/ fails on localized Windows platform

Reviewed-by: naoto

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

PR: https://git.openjdk.java.net/jdk/pull/4594

From xxinliu at amazon.com  Wed Sep  8 17:21:25 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 8 Sep 2021 10:21:25 -0700
Subject: RFC: call report_java_out_of_memory_error() for
 -XX:AbortVMOnException=java.lang.OutOfMemoryError
In-Reply-To: <6ac33111-de76-3606-4a5e-817f115dacab@oracle.com>
References: <4ef699cc-a5bb-f93c-c62a-ef9d6cbd2e4f@amazon.com>
 <6ac33111-de76-3606-4a5e-817f115dacab@oracle.com>
Message-ID: <4ee742a3-ec29-5f54-d9b3-557cd09148b3@amazon.com>

Hi, David,

Thanks for the head-up. yes, it works for me.

There's one more thing. One drawback is that the script providing to
OnError can't trap hotspot itself or we end up with a deadlock.


If we use 'jcmd %p Thread.print' or 'jcmd %p GC.heap_dump <file>' in
OnError=, (%p means the java process itself), the main java thread which
is waiting for os::fork_and_exec(cmd) will prevent hotspot reach to the
safepoint. It's deadlock because no safepoint mean fork_and_exec can't
complete.

eg.
$java -Xmx50m -XX:AbortVMOnException=java.lang.OutOfMemoryError
-XX:OnError='jcmd %p Thread.print' -XX:+SafepointTimeout OomDumpExample
direct
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/exceptions.cpp:541
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/home/xxinliu/Devel/jdk/src/hotspot/share/utilities/exceptions.cpp:541), pid=107552,
tid=107553
#  fatal error: Saw java.lang.OutOfMemoryError, aborting
#
# JRE version: OpenJDK Runtime Environment (18.0) (slowdebug build
18-internal+0-adhoc.xxinliu.jdk)
# Java VM: OpenJDK 64-Bit Server VM (slowdebug
18-internal+0-adhoc.xxinliu.jdk, mixed mode, tiered, compressed oops,
compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x924e8c]  Exceptions::debug_check_abort(char const*,
char const*)+0x8a
#
# No core dump will be written. Core dumps have been disabled. To enable
core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /local/home/xxinliu/JDK-2085/hs_err_pid107552.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
#
# -XX:OnError="jcmd %p Thread.print"
#   Executing /bin/sh -c "jcmd 107552 Thread.print" ...
107552:
[13.045s][warning][safepoint]
[13.045s][warning][safepoint] # SafepointSynchronize::begin: Timeout
detected:
[13.045s][warning][safepoint] # SafepointSynchronize::begin: Timed out
while spinning to reach a safepoint.
[13.045s][warning][safepoint] # SafepointSynchronize::begin: Threads
which did not reach the safepoint:
[13.045s][warning][safepoint] # "main" #1 prio=5 os_prio=0 cpu=1552.12ms
elapsed=13.04s tid=0x00007f43600278e0 nid=107553 runnable
[0x00007f4369d9f000]
[13.045s][warning][safepoint]    java.lang.Thread.State: RUNNABLE
[13.045s][warning][safepoint] Thread: 0x00007f43600278e0  [0x1a421]
State: _running _at_poll_safepoint 0
[13.045s][warning][safepoint]    JavaThread state: _thread_in_vm
[13.045s][warning][safepoint]
[13.045s][warning][safepoint] # SafepointSynchronize::begin: (End of list)


I haven't figured out how yet, but I think I can lift this constraint.
Once I did, OnError would have more freedom to dump thread or heap
before dieing. Can I file bug about this?

thanks,
--lx


On 8/30/21 9:26 PM, David Holmes wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Hi,
> 
> On 28/08/2021 4:54 am, Liu, Xin wrote:
>> Hi,
>>
>> Recently I revisit JDK-8155004/JDK-8257790 because a new team trip over.
>> -XX:AbortVMOnException=java.lang.OutOfMemoryError works. I wonder
>> whether it is a good idea to call report_java_out_of_memory_error() when
>> OOME is trapped. In this way, HotSpot will trigger OnOutOfMemoryError
>> callbacks.
> 
> Why not just use AbortVMOnException together with OnError to get the
> callbacks?
> 
> Cheers,
> David
> 
>> I understand JDK-8257790 is not a bug. I don't want to overthrow that
>> conclusion. I just wonder if we can handle it better in the presence of
>> -XX:AbortVMOnException=java.lang.OutOfMemoryError.
>>
>> For Java webservers, OOME may lead to a zombie process. We may have a
>> bug in code or indeed run out of memory. OOME is suppressed or terminate
>> the thread but don't terminate the java process. eg.
>>
>> public class Main {
>>      volatile static boolean done = false;
>>
>>      public static void main(String[] args) {
>>          String msg = "a long long message.";
>>          // write your code here
>>          Runnable runnable = () -> {
>>              int cnt = Integer.MAX_VALUE / msg.length() + 1;
>>              //it will throw a OutOfMemoryError.
>>              msg.repeat(cnt);
>>              done = true;
>>          };
>>
>>          Thread thread = new Thread(runnable);
>>          thread.start();
>>          while(!done) {
>>          } // this simulates the main loop of event handling
>>      }
>> }
>>
>> Java developers can use
>> -XX:AbortVMOnException=java.lang.OutOfMemoryError to exercise fail-fast
>> principle. Java web application which handle traffics are usually
>> distributed in a cluster. A failure of a single host usually is not a
>> big deal. As long as java exits, it's easy to restart and backfill it.
>>
>> My proposing change is very simple. Just call
>> report_java_out_of_memory() if value_string is OOME. It's no-op if users
>> never specify anything. If they do specify flags like
>> Crash/ExitOnOutOfMemory,  OnOutOfMemoryError or
>> HeapDumpOnOutOfMemoryError, HotSpot will let report_java_out_of_memory
>> does the cleanup job. fatal() works but too brutal. I think we should
>> let java exits with error code.
>>
>>
>> diff --git a/src/hotspot/share/utilities/exceptions.cpp
>> b/src/hotspot/share/utilities/exceptions.cpp
>> index bd95b8306be..fd8a83deaf3 100644
>> --- a/src/hotspot/share/utilities/exceptions.cpp
>> +++ b/src/hotspot/share/utilities/exceptions.cpp
>> @@ -538,6 +538,9 @@ void Exceptions::debug_check_abort(const char
>> *value_string, const char* message
>>         strstr(value_string, AbortVMOnException)) {
>>       if (AbortVMOnExceptionMessage == NULL || (message != NULL &&
>>           strstr(message, AbortVMOnExceptionMessage))) {
>> +      if(!strcmp(value_string, "java.lang.OutOfMemoryError")) {
>> +        report_java_out_of_memory(message);
>> +      }
>>         fatal("Saw %s, aborting", value_string);
>>       }
>>     }
>>
>>
>> thanks,
>> --lx
>>

From volker.simonis at gmail.com  Wed Sep  8 17:35:49 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 8 Sep 2021 19:35:49 +0200
Subject: RFC: call report_java_out_of_memory_error() for
 -XX:AbortVMOnException=java.lang.OutOfMemoryError
In-Reply-To: <4ee742a3-ec29-5f54-d9b3-557cd09148b3@amazon.com>
References: <4ef699cc-a5bb-f93c-c62a-ef9d6cbd2e4f@amazon.com>
 <6ac33111-de76-3606-4a5e-817f115dacab@oracle.com>
 <4ee742a3-ec29-5f54-d9b3-557cd09148b3@amazon.com>
Message-ID: <CA+3eh10+PMpDsokREg8TS8utTkrg-4n9fSTdb7QL0R3jRWEfBQ@mail.gmail.com>

I'm not sure if running a jcmd process which attaches to the dying VM
as part of the OnError scripts is a use case we really want to
support?

There's a reason why the VM is crashing and attaching to this dying VM
will most probably only cause other follow-up errors.

On Wed, Sep 8, 2021 at 7:22 PM Liu, Xin <xxinliu at amazon.com> wrote:
>
> Hi, David,
>
> Thanks for the head-up. yes, it works for me.
>
> There's one more thing. One drawback is that the script providing to
> OnError can't trap hotspot itself or we end up with a deadlock.
>
>
> If we use 'jcmd %p Thread.print' or 'jcmd %p GC.heap_dump <file>' in
> OnError=, (%p means the java process itself), the main java thread which
> is waiting for os::fork_and_exec(cmd) will prevent hotspot reach to the
> safepoint. It's deadlock because no safepoint mean fork_and_exec can't
> complete.
>
> eg.
> $java -Xmx50m -XX:AbortVMOnException=java.lang.OutOfMemoryError
> -XX:OnError='jcmd %p Thread.print' -XX:+SafepointTimeout OomDumpExample
> direct
> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/exceptions.cpp:541
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error
> (/home/xxinliu/Devel/jdk/src/hotspot/share/utilities/exceptions.cpp:541), pid=107552,
> tid=107553
> #  fatal error: Saw java.lang.OutOfMemoryError, aborting
> #
> # JRE version: OpenJDK Runtime Environment (18.0) (slowdebug build
> 18-internal+0-adhoc.xxinliu.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (slowdebug
> 18-internal+0-adhoc.xxinliu.jdk, mixed mode, tiered, compressed oops,
> compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x924e8c]  Exceptions::debug_check_abort(char const*,
> char const*)+0x8a
> #
> # No core dump will be written. Core dumps have been disabled. To enable
> core dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> # /local/home/xxinliu/JDK-2085/hs_err_pid107552.log
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> #
> # -XX:OnError="jcmd %p Thread.print"
> #   Executing /bin/sh -c "jcmd 107552 Thread.print" ...
> 107552:
> [13.045s][warning][safepoint]
> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timeout
> detected:
> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timed out
> while spinning to reach a safepoint.
> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Threads
> which did not reach the safepoint:
> [13.045s][warning][safepoint] # "main" #1 prio=5 os_prio=0 cpu=1552.12ms
> elapsed=13.04s tid=0x00007f43600278e0 nid=107553 runnable
> [0x00007f4369d9f000]
> [13.045s][warning][safepoint]    java.lang.Thread.State: RUNNABLE
> [13.045s][warning][safepoint] Thread: 0x00007f43600278e0  [0x1a421]
> State: _running _at_poll_safepoint 0
> [13.045s][warning][safepoint]    JavaThread state: _thread_in_vm
> [13.045s][warning][safepoint]
> [13.045s][warning][safepoint] # SafepointSynchronize::begin: (End of list)
>
>
> I haven't figured out how yet, but I think I can lift this constraint.
> Once I did, OnError would have more freedom to dump thread or heap
> before dieing. Can I file bug about this?
>
> thanks,
> --lx
>
>
> On 8/30/21 9:26 PM, David Holmes wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > Hi,
> >
> > On 28/08/2021 4:54 am, Liu, Xin wrote:
> >> Hi,
> >>
> >> Recently I revisit JDK-8155004/JDK-8257790 because a new team trip over.
> >> -XX:AbortVMOnException=java.lang.OutOfMemoryError works. I wonder
> >> whether it is a good idea to call report_java_out_of_memory_error() when
> >> OOME is trapped. In this way, HotSpot will trigger OnOutOfMemoryError
> >> callbacks.
> >
> > Why not just use AbortVMOnException together with OnError to get the
> > callbacks?
> >
> > Cheers,
> > David
> >
> >> I understand JDK-8257790 is not a bug. I don't want to overthrow that
> >> conclusion. I just wonder if we can handle it better in the presence of
> >> -XX:AbortVMOnException=java.lang.OutOfMemoryError.
> >>
> >> For Java webservers, OOME may lead to a zombie process. We may have a
> >> bug in code or indeed run out of memory. OOME is suppressed or terminate
> >> the thread but don't terminate the java process. eg.
> >>
> >> public class Main {
> >>      volatile static boolean done = false;
> >>
> >>      public static void main(String[] args) {
> >>          String msg = "a long long message.";
> >>          // write your code here
> >>          Runnable runnable = () -> {
> >>              int cnt = Integer.MAX_VALUE / msg.length() + 1;
> >>              //it will throw a OutOfMemoryError.
> >>              msg.repeat(cnt);
> >>              done = true;
> >>          };
> >>
> >>          Thread thread = new Thread(runnable);
> >>          thread.start();
> >>          while(!done) {
> >>          } // this simulates the main loop of event handling
> >>      }
> >> }
> >>
> >> Java developers can use
> >> -XX:AbortVMOnException=java.lang.OutOfMemoryError to exercise fail-fast
> >> principle. Java web application which handle traffics are usually
> >> distributed in a cluster. A failure of a single host usually is not a
> >> big deal. As long as java exits, it's easy to restart and backfill it.
> >>
> >> My proposing change is very simple. Just call
> >> report_java_out_of_memory() if value_string is OOME. It's no-op if users
> >> never specify anything. If they do specify flags like
> >> Crash/ExitOnOutOfMemory,  OnOutOfMemoryError or
> >> HeapDumpOnOutOfMemoryError, HotSpot will let report_java_out_of_memory
> >> does the cleanup job. fatal() works but too brutal. I think we should
> >> let java exits with error code.
> >>
> >>
> >> diff --git a/src/hotspot/share/utilities/exceptions.cpp
> >> b/src/hotspot/share/utilities/exceptions.cpp
> >> index bd95b8306be..fd8a83deaf3 100644
> >> --- a/src/hotspot/share/utilities/exceptions.cpp
> >> +++ b/src/hotspot/share/utilities/exceptions.cpp
> >> @@ -538,6 +538,9 @@ void Exceptions::debug_check_abort(const char
> >> *value_string, const char* message
> >>         strstr(value_string, AbortVMOnException)) {
> >>       if (AbortVMOnExceptionMessage == NULL || (message != NULL &&
> >>           strstr(message, AbortVMOnExceptionMessage))) {
> >> +      if(!strcmp(value_string, "java.lang.OutOfMemoryError")) {
> >> +        report_java_out_of_memory(message);
> >> +      }
> >>         fatal("Saw %s, aborting", value_string);
> >>       }
> >>     }
> >>
> >>
> >> thanks,
> >> --lx
> >>

From dcubed at openjdk.java.net  Wed Sep  8 18:36:26 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 18:36:26 GMT
Subject: Integrated: 8273109:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out
Message-ID: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>

A trivial fix to increase the timeouts for the two sub-tests in
runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java.

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

Commit messages:
 - 8273109: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out

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

PR: https://git.openjdk.java.net/jdk/pull/5422

From bpb at openjdk.java.net  Wed Sep  8 18:36:26 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 8 Sep 2021 18:36:26 GMT
Subject: Integrated: 8273109:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out
In-Reply-To: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
References: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
Message-ID: <4OB-PAeiLtFxVdTL25z8hsc7erCZnpjog0U0zA1iTcY=.6bfd4a51-0d0f-4ae0-9ac3-b1f6dd0280a3@github.com>

On Wed, 8 Sep 2021 18:28:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to increase the timeouts for the two sub-tests in
> runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5422

From dcubed at openjdk.java.net  Wed Sep  8 18:36:26 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 18:36:26 GMT
Subject: Integrated: 8273109:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out
In-Reply-To: <4OB-PAeiLtFxVdTL25z8hsc7erCZnpjog0U0zA1iTcY=.6bfd4a51-0d0f-4ae0-9ac3-b1f6dd0280a3@github.com>
References: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
 <4OB-PAeiLtFxVdTL25z8hsc7erCZnpjog0U0zA1iTcY=.6bfd4a51-0d0f-4ae0-9ac3-b1f6dd0280a3@github.com>
Message-ID: <7XRauHY87fLVFqEyDp-8X0upqL5bjkKbYW5xX2ctOzA=.5cf98d29-524b-42bd-b1f2-141ae0f8ae85@github.com>

On Wed, 8 Sep 2021 18:30:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to increase the timeouts for the two sub-tests in
>> runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java.
>
> Marked as reviewed by bpb (Reviewer).

@bplb - Thanks for the lightning fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5422

From dcubed at openjdk.java.net  Wed Sep  8 18:36:27 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 18:36:27 GMT
Subject: Integrated: 8273109:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out
In-Reply-To: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
References: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
Message-ID: <H2rLpK3Jz_mDBJW3_9wBhHTY8ZMFIzxAx6A5IplyJg8=.184221f6-d3d0-40d2-b89c-8a0fa0660ff5@github.com>

On Wed, 8 Sep 2021 18:28:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to increase the timeouts for the two sub-tests in
> runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java.

This pull request has now been integrated.

Changeset: ba31eee4
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ba31eee4fc92bba3657e5f3fec2b85f55120d7a1
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8273109: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out

Reviewed-by: bpb

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

PR: https://git.openjdk.java.net/jdk/pull/5422

From hseigel at openjdk.java.net  Wed Sep  8 18:39:05 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 8 Sep 2021 18:39:05 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested
In-Reply-To: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
Message-ID: <trJKhuIZ0MY85Zdtpj--5PizVQWn1RewI_mcB612nuE=.80d60d9e-2b93-409d-ba79-645daee57d55@github.com>

On Sat, 4 Sep 2021 00:03:14 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this addition of new testing:
>   - new test for sending jcmd commands across container boundaries
>   - updated existing sidecar test, enabling jcmd test case

test/hotspot/jtreg/containers/docker/TestJcmd.java line 94:

> 92: 
> 93: 
> 94:     // Run "jcmd -l" in a sidecar container, find the target process.

Since 'jcmd -l' is not run in a sidecar, this comment is incorrect.

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

PR: https://git.openjdk.java.net/jdk/pull/5368

From xxinliu at amazon.com  Wed Sep  8 18:48:06 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Wed, 8 Sep 2021 11:48:06 -0700
Subject: RFC: call report_java_out_of_memory_error() for
 -XX:AbortVMOnException=java.lang.OutOfMemoryError
In-Reply-To: <CA+3eh10+PMpDsokREg8TS8utTkrg-4n9fSTdb7QL0R3jRWEfBQ@mail.gmail.com>
References: <4ef699cc-a5bb-f93c-c62a-ef9d6cbd2e4f@amazon.com>
 <6ac33111-de76-3606-4a5e-817f115dacab@oracle.com>
 <4ee742a3-ec29-5f54-d9b3-557cd09148b3@amazon.com>
 <CA+3eh10+PMpDsokREg8TS8utTkrg-4n9fSTdb7QL0R3jRWEfBQ@mail.gmail.com>
Message-ID: <cbdc4d54-63fe-be7c-9e60-2a58e925e1c1@amazon.com>

hi, Volker,

I think it's possible to allow OnError=jcmd to attach to the parent
process. HotSpot defines OnError as "Run user-defined commands on fatal
error; see VMError.cpp for examples". It's a callback for fatal errors.
fatal() means HotSpot starts aborting and does not notify other threads.
 In other words, other threads are in normal states. I observe so in
gdb.  All other threads are successful to enter safepoint safe state
except the main java thread.

I am not advocating using jcmd %p in OnError. I am exploring a
possibility. Currently, we will end up a deadlock if you do so. If we
made it, we would at least get more information from Hotspot. We will
fail-fast if something bad happen. I think fail-fast is still better
than a hanging process.

thanks,
--lx




On 9/8/21 10:35 AM, Volker Simonis wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> I'm not sure if running a jcmd process which attaches to the dying VM
> as part of the OnError scripts is a use case we really want to
> support?
> 
> There's a reason why the VM is crashing and attaching to this dying VM
> will most probably only cause other follow-up errors.
> 
> On Wed, Sep 8, 2021 at 7:22 PM Liu, Xin <xxinliu at amazon.com> wrote:
>>
>> Hi, David,
>>
>> Thanks for the head-up. yes, it works for me.
>>
>> There's one more thing. One drawback is that the script providing to
>> OnError can't trap hotspot itself or we end up with a deadlock.
>>
>>
>> If we use 'jcmd %p Thread.print' or 'jcmd %p GC.heap_dump <file>' in
>> OnError=, (%p means the java process itself), the main java thread which
>> is waiting for os::fork_and_exec(cmd) will prevent hotspot reach to the
>> safepoint. It's deadlock because no safepoint mean fork_and_exec can't
>> complete.
>>
>> eg.
>> $java -Xmx50m -XX:AbortVMOnException=java.lang.OutOfMemoryError
>> -XX:OnError='jcmd %p Thread.print' -XX:+SafepointTimeout OomDumpExample
>> direct
>> # To suppress the following error report, specify this argument
>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/exceptions.cpp:541
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error
>> (/home/xxinliu/Devel/jdk/src/hotspot/share/utilities/exceptions.cpp:541), pid=107552,
>> tid=107553
>> #  fatal error: Saw java.lang.OutOfMemoryError, aborting
>> #
>> # JRE version: OpenJDK Runtime Environment (18.0) (slowdebug build
>> 18-internal+0-adhoc.xxinliu.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (slowdebug
>> 18-internal+0-adhoc.xxinliu.jdk, mixed mode, tiered, compressed oops,
>> compressed class ptrs, g1 gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x924e8c]  Exceptions::debug_check_abort(char const*,
>> char const*)+0x8a
>> #
>> # No core dump will be written. Core dumps have been disabled. To enable
>> core dumping, try "ulimit -c unlimited" before starting Java again
>> #
>> # An error report file with more information is saved as:
>> # /local/home/xxinliu/JDK-2085/hs_err_pid107552.log
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> #
>> # -XX:OnError="jcmd %p Thread.print"
>> #   Executing /bin/sh -c "jcmd 107552 Thread.print" ...
>> 107552:
>> [13.045s][warning][safepoint]
>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timeout
>> detected:
>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timed out
>> while spinning to reach a safepoint.
>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Threads
>> which did not reach the safepoint:
>> [13.045s][warning][safepoint] # "main" #1 prio=5 os_prio=0 cpu=1552.12ms
>> elapsed=13.04s tid=0x00007f43600278e0 nid=107553 runnable
>> [0x00007f4369d9f000]
>> [13.045s][warning][safepoint]    java.lang.Thread.State: RUNNABLE
>> [13.045s][warning][safepoint] Thread: 0x00007f43600278e0  [0x1a421]
>> State: _running _at_poll_safepoint 0
>> [13.045s][warning][safepoint]    JavaThread state: _thread_in_vm
>> [13.045s][warning][safepoint]
>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: (End of list)
>>
>>
>> I haven't figured out how yet, but I think I can lift this constraint.
>> Once I did, OnError would have more freedom to dump thread or heap
>> before dieing. Can I file bug about this?
>>
>> thanks,
>> --lx
>>
>>
>> On 8/30/21 9:26 PM, David Holmes wrote:
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>
>>>
>>> Hi,
>>>
>>> On 28/08/2021 4:54 am, Liu, Xin wrote:
>>>> Hi,
>>>>
>>>> Recently I revisit JDK-8155004/JDK-8257790 because a new team trip over.
>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError works. I wonder
>>>> whether it is a good idea to call report_java_out_of_memory_error() when
>>>> OOME is trapped. In this way, HotSpot will trigger OnOutOfMemoryError
>>>> callbacks.
>>>
>>> Why not just use AbortVMOnException together with OnError to get the
>>> callbacks?
>>>
>>> Cheers,
>>> David
>>>
>>>> I understand JDK-8257790 is not a bug. I don't want to overthrow that
>>>> conclusion. I just wonder if we can handle it better in the presence of
>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError.
>>>>
>>>> For Java webservers, OOME may lead to a zombie process. We may have a
>>>> bug in code or indeed run out of memory. OOME is suppressed or terminate
>>>> the thread but don't terminate the java process. eg.
>>>>
>>>> public class Main {
>>>>      volatile static boolean done = false;
>>>>
>>>>      public static void main(String[] args) {
>>>>          String msg = "a long long message.";
>>>>          // write your code here
>>>>          Runnable runnable = () -> {
>>>>              int cnt = Integer.MAX_VALUE / msg.length() + 1;
>>>>              //it will throw a OutOfMemoryError.
>>>>              msg.repeat(cnt);
>>>>              done = true;
>>>>          };
>>>>
>>>>          Thread thread = new Thread(runnable);
>>>>          thread.start();
>>>>          while(!done) {
>>>>          } // this simulates the main loop of event handling
>>>>      }
>>>> }
>>>>
>>>> Java developers can use
>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError to exercise fail-fast
>>>> principle. Java web application which handle traffics are usually
>>>> distributed in a cluster. A failure of a single host usually is not a
>>>> big deal. As long as java exits, it's easy to restart and backfill it.
>>>>
>>>> My proposing change is very simple. Just call
>>>> report_java_out_of_memory() if value_string is OOME. It's no-op if users
>>>> never specify anything. If they do specify flags like
>>>> Crash/ExitOnOutOfMemory,  OnOutOfMemoryError or
>>>> HeapDumpOnOutOfMemoryError, HotSpot will let report_java_out_of_memory
>>>> does the cleanup job. fatal() works but too brutal. I think we should
>>>> let java exits with error code.
>>>>
>>>>
>>>> diff --git a/src/hotspot/share/utilities/exceptions.cpp
>>>> b/src/hotspot/share/utilities/exceptions.cpp
>>>> index bd95b8306be..fd8a83deaf3 100644
>>>> --- a/src/hotspot/share/utilities/exceptions.cpp
>>>> +++ b/src/hotspot/share/utilities/exceptions.cpp
>>>> @@ -538,6 +538,9 @@ void Exceptions::debug_check_abort(const char
>>>> *value_string, const char* message
>>>>         strstr(value_string, AbortVMOnException)) {
>>>>       if (AbortVMOnExceptionMessage == NULL || (message != NULL &&
>>>>           strstr(message, AbortVMOnExceptionMessage))) {
>>>> +      if(!strcmp(value_string, "java.lang.OutOfMemoryError")) {
>>>> +        report_java_out_of_memory(message);
>>>> +      }
>>>>         fatal("Saw %s, aborting", value_string);
>>>>       }
>>>>     }
>>>>
>>>>
>>>> thanks,
>>>> --lx
>>>>

From lmesnik at openjdk.java.net  Wed Sep  8 19:33:10 2021
From: lmesnik at openjdk.java.net (Leonid Mesnik)
Date: Wed, 8 Sep 2021 19:33:10 GMT
Subject: Integrated: 8273451: Remove unreachable return in mutexLocker::wait
In-Reply-To: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
References: <KjvJ5x389T2xP-ld7UbPVM9Bjya2xokU64OuyK_gB_Y=.60aab539-dbc4-47c7-8832-51ea3473396d@github.com>
Message-ID: <oxDZI3krFluAZDiQd69pRMmGspUQlfhal9oPsphGwBI=.b138015a-52e7-4cdc-9627-bd99936ac0b6@github.com>

On Tue, 7 Sep 2021 19:38:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Refactored  mutexLocker::wait to return redundant unreachable "return false;"

This pull request has now been integrated.

Changeset: 9b5991e8
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9b5991e811b789fe8b60701657c2f0dd2c222c2e
Stats:     6 lines in 1 file changed: 0 ins; 4 del; 2 mod

8273451: Remove unreachable return in mutexLocker::wait

Reviewed-by: minqi, coleenp

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

PR: https://git.openjdk.java.net/jdk/pull/5398

From mseledtsov at openjdk.java.net  Wed Sep  8 19:40:05 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 8 Sep 2021 19:40:05 GMT
Subject: Integrated: 8273109:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out
In-Reply-To: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
References: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
Message-ID: <e9lbtC735dycA07sLTdum_EM87ByvzQIOJ54YnFyXDc=.da85e0cf-1bbc-4e4d-a108-c72d568b98a0@github.com>

On Wed, 8 Sep 2021 18:28:48 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to increase the timeouts for the two sub-tests in
> runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java.

Looks good to me.

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

PR: https://git.openjdk.java.net/jdk/pull/5422

From mseledtsov at openjdk.java.net  Wed Sep  8 19:44:35 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 8 Sep 2021 19:44:35 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested [v2]
In-Reply-To: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
Message-ID: <tesJyvrFOgWg4plwzyH6jYkLeHJeKf1dee0FnJbEO7A=.9988e6bc-0100-42f1-8597-82e1378f569f@github.com>

> Please review this addition of new testing:
>   - new test for sending jcmd commands across container boundaries
>   - updated existing sidecar test, enabling jcmd test case

Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:

  Updated comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5368/files
  - new: https://git.openjdk.java.net/jdk/pull/5368/files/b714f662..1a66f1c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5368&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5368&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5368

From mseledtsov at openjdk.java.net  Wed Sep  8 19:44:38 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 8 Sep 2021 19:44:38 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested [v2]
In-Reply-To: <trJKhuIZ0MY85Zdtpj--5PizVQWn1RewI_mcB612nuE=.80d60d9e-2b93-409d-ba79-645daee57d55@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
 <trJKhuIZ0MY85Zdtpj--5PizVQWn1RewI_mcB612nuE=.80d60d9e-2b93-409d-ba79-645daee57d55@github.com>
Message-ID: <L6A6JIx61Hv7PutjRfyRx2M392QYKyF6JwwtaW9Xk1U=.2b2fbeef-cf14-4cc0-b1e0-01efeeb00f3d@github.com>

On Wed, 8 Sep 2021 18:36:27 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated comment
>
> test/hotspot/jtreg/containers/docker/TestJcmd.java line 94:
> 
>> 92: 
>> 93: 
>> 94:     // Run "jcmd -l" in a sidecar container, find the target process.
> 
> Since 'jcmd -l' is not run in a sidecar, this comment is incorrect.

Good catch. I will update the comment.

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

PR: https://git.openjdk.java.net/jdk/pull/5368

From mseledtsov at openjdk.java.net  Wed Sep  8 19:46:00 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 8 Sep 2021 19:46:00 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
Message-ID: <k59-vnAS4Ni1XH1ciqOgM9AlIElppuIGvOsKDF7zDaw=.7baa8bf9-2f09-438b-a966-b3a30ab48380@github.com>

On Tue, 7 Sep 2021 13:17:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
> 
> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14 
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25 
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s

Thanks Alexey. I will run some tests, look into history of tests and will get back to you with my findings tonight (PST) or tomorrow.

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From coleenp at openjdk.java.net  Wed Sep  8 22:06:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 8 Sep 2021 22:06:05 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v10]
In-Reply-To: <kDbmRbj6sWLGGhNprH_U8-9vsmbzsOkxU7_ekGtec6g=.3c825a07-fc0e-43ed-8cf7-76b62c096ee7@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <kDbmRbj6sWLGGhNprH_U8-9vsmbzsOkxU7_ekGtec6g=.3c825a07-fc0e-43ed-8cf7-76b62c096ee7@github.com>
Message-ID: <mQ3lJ0MLksSfarBtRg8HnvW1POUmy4fzzjL0M3x45c0=.f39fa255-a8e6-44f0-ae3e-197db15f1093@github.com>

On Fri, 27 Aug 2021 15:23:35 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - localize
>  - cleanup
>  - FinalizerStatistics

I have some general comments and questions about this code.

src/hotspot/share/services/classLoadingService.cpp line 80:

> 78: 
> 79: size_t ClassLoadingService::compute_class_size(InstanceKlass* k) {
> 80:   // lifted from ClassStatistics.do_class(Klass* k)

Can you remove this line? I think that function is gone now.

src/hotspot/share/services/finalizerService.cpp line 44:

> 42:     _ik(ik),
> 43:     _objects_on_heap(0),
> 44:     _total_finalizers_run(0) {}

Is this hashtable for every InstanceKlass that defines a finalizer?  How many are there generally?  Why couldn't this be a simple hashtable like ResourceHashtable (soon to be renamed) which you can write in only a few lines of code?

src/hotspot/share/services/finalizerService.cpp line 114:

> 112: 
> 113: static inline void added() {
> 114:   set_atomic<inc>(&_count);

Why isn't Atomic::inc() good enough here? It's used everywhere else.

src/hotspot/share/services/finalizerService.cpp line 123:

> 121: static inline uintx hash_function(const InstanceKlass* ik) {
> 122:   assert(ik != nullptr, "invariant");
> 123:   return primitive_hash(ik);

If the hash function is primitive_hash, this hash is good enough to not need rehashing.  The only reason for the rehashing for symbol and string table was that the char* had a dumb hash that was faster but could be hacked, so it needed to become a different hashcode.  This doesn't need rehashing.

src/hotspot/share/services/finalizerService.cpp line 485:

> 483: void FinalizerService::purge_unloaded() {
> 484:   assert_locked_or_safepoint(ClassLoaderDataGraph_lock);
> 485:   ClassLoaderDataGraph::classes_unloading_do(&on_unloading);

Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup.
You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From david.holmes at oracle.com  Wed Sep  8 22:08:07 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Sep 2021 08:08:07 +1000
Subject: [EXTERNAL] RFC: call report_java_out_of_memory_error() for
 -XX:AbortVMOnException=java.lang.OutOfMemoryError
In-Reply-To: <cbdc4d54-63fe-be7c-9e60-2a58e925e1c1@amazon.com>
References: <4ef699cc-a5bb-f93c-c62a-ef9d6cbd2e4f@amazon.com>
 <6ac33111-de76-3606-4a5e-817f115dacab@oracle.com>
 <4ee742a3-ec29-5f54-d9b3-557cd09148b3@amazon.com>
 <CA+3eh10+PMpDsokREg8TS8utTkrg-4n9fSTdb7QL0R3jRWEfBQ@mail.gmail.com>
 <cbdc4d54-63fe-be7c-9e60-2a58e925e1c1@amazon.com>
Message-ID: <9a2a3b98-de10-3ba9-1c2f-8a9904f3ed70@oracle.com>

On 9/09/2021 4:48 am, Liu, Xin wrote:
> hi, Volker,
> 
> I think it's possible to allow OnError=jcmd to attach to the parent
> process. HotSpot defines OnError as "Run user-defined commands on fatal
> error; see VMError.cpp for examples". It's a callback for fatal errors.
> fatal() means HotSpot starts aborting and does not notify other threads.
>   In other words, other threads are in normal states. I observe so in
> gdb.  All other threads are successful to enter safepoint safe state
> except the main java thread.
> 
> I am not advocating using jcmd %p in OnError. I am exploring a
> possibility. Currently, we will end up a deadlock if you do so. If we
> made it, we would at least get more information from Hotspot. We will
> fail-fast if something bad happen. I think fail-fast is still better
> than a hanging process.

It may be possible to fix the safepoint deadlock by transitioning the 
thread executing the OnError command to _thread_in_native beforehand - 
but there are constraints on doing that e.g. no oocks can be held. And 
if the error is processed in the VMThread then there is nothing that can 
be done.

But I agree with Volker that given a fatal error has been encountered, 
trying to report other information about the VM in a live manner is 
fraught with peril. Using a core dump for post mortem analysis would 
probably be better.

Cheers,
David

> thanks,
> --lx
> 
> 
> 
> 
> On 9/8/21 10:35 AM, Volker Simonis wrote:
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> I'm not sure if running a jcmd process which attaches to the dying VM
>> as part of the OnError scripts is a use case we really want to
>> support?
>>
>> There's a reason why the VM is crashing and attaching to this dying VM
>> will most probably only cause other follow-up errors.
>>
>> On Wed, Sep 8, 2021 at 7:22 PM Liu, Xin <xxinliu at amazon.com> wrote:
>>>
>>> Hi, David,
>>>
>>> Thanks for the head-up. yes, it works for me.
>>>
>>> There's one more thing. One drawback is that the script providing to
>>> OnError can't trap hotspot itself or we end up with a deadlock.
>>>
>>>
>>> If we use 'jcmd %p Thread.print' or 'jcmd %p GC.heap_dump <file>' in
>>> OnError=, (%p means the java process itself), the main java thread which
>>> is waiting for os::fork_and_exec(cmd) will prevent hotspot reach to the
>>> safepoint. It's deadlock because no safepoint mean fork_and_exec can't
>>> complete.
>>>
>>> eg.
>>> $java -Xmx50m -XX:AbortVMOnException=java.lang.OutOfMemoryError
>>> -XX:OnError='jcmd %p Thread.print' -XX:+SafepointTimeout OomDumpExample
>>> direct
>>> # To suppress the following error report, specify this argument
>>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/exceptions.cpp:541
>>> #
>>> # A fatal error has been detected by the Java Runtime Environment:
>>> #
>>> #  Internal Error
>>> (/home/xxinliu/Devel/jdk/src/hotspot/share/utilities/exceptions.cpp:541), pid=107552,
>>> tid=107553
>>> #  fatal error: Saw java.lang.OutOfMemoryError, aborting
>>> #
>>> # JRE version: OpenJDK Runtime Environment (18.0) (slowdebug build
>>> 18-internal+0-adhoc.xxinliu.jdk)
>>> # Java VM: OpenJDK 64-Bit Server VM (slowdebug
>>> 18-internal+0-adhoc.xxinliu.jdk, mixed mode, tiered, compressed oops,
>>> compressed class ptrs, g1 gc, linux-amd64)
>>> # Problematic frame:
>>> # V  [libjvm.so+0x924e8c]  Exceptions::debug_check_abort(char const*,
>>> char const*)+0x8a
>>> #
>>> # No core dump will be written. Core dumps have been disabled. To enable
>>> core dumping, try "ulimit -c unlimited" before starting Java again
>>> #
>>> # An error report file with more information is saved as:
>>> # /local/home/xxinliu/JDK-2085/hs_err_pid107552.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> #   https://bugreport.java.com/bugreport/crash.jsp
>>> #
>>> #
>>> # -XX:OnError="jcmd %p Thread.print"
>>> #   Executing /bin/sh -c "jcmd 107552 Thread.print" ...
>>> 107552:
>>> [13.045s][warning][safepoint]
>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timeout
>>> detected:
>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timed out
>>> while spinning to reach a safepoint.
>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Threads
>>> which did not reach the safepoint:
>>> [13.045s][warning][safepoint] # "main" #1 prio=5 os_prio=0 cpu=1552.12ms
>>> elapsed=13.04s tid=0x00007f43600278e0 nid=107553 runnable
>>> [0x00007f4369d9f000]
>>> [13.045s][warning][safepoint]    java.lang.Thread.State: RUNNABLE
>>> [13.045s][warning][safepoint] Thread: 0x00007f43600278e0  [0x1a421]
>>> State: _running _at_poll_safepoint 0
>>> [13.045s][warning][safepoint]    JavaThread state: _thread_in_vm
>>> [13.045s][warning][safepoint]
>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: (End of list)
>>>
>>>
>>> I haven't figured out how yet, but I think I can lift this constraint.
>>> Once I did, OnError would have more freedom to dump thread or heap
>>> before dieing. Can I file bug about this?
>>>
>>> thanks,
>>> --lx
>>>
>>>
>>> On 8/30/21 9:26 PM, David Holmes wrote:
>>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>>
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 28/08/2021 4:54 am, Liu, Xin wrote:
>>>>> Hi,
>>>>>
>>>>> Recently I revisit JDK-8155004/JDK-8257790 because a new team trip over.
>>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError works. I wonder
>>>>> whether it is a good idea to call report_java_out_of_memory_error() when
>>>>> OOME is trapped. In this way, HotSpot will trigger OnOutOfMemoryError
>>>>> callbacks.
>>>>
>>>> Why not just use AbortVMOnException together with OnError to get the
>>>> callbacks?
>>>>
>>>> Cheers,
>>>> David
>>>>
>>>>> I understand JDK-8257790 is not a bug. I don't want to overthrow that
>>>>> conclusion. I just wonder if we can handle it better in the presence of
>>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError.
>>>>>
>>>>> For Java webservers, OOME may lead to a zombie process. We may have a
>>>>> bug in code or indeed run out of memory. OOME is suppressed or terminate
>>>>> the thread but don't terminate the java process. eg.
>>>>>
>>>>> public class Main {
>>>>>       volatile static boolean done = false;
>>>>>
>>>>>       public static void main(String[] args) {
>>>>>           String msg = "a long long message.";
>>>>>           // write your code here
>>>>>           Runnable runnable = () -> {
>>>>>               int cnt = Integer.MAX_VALUE / msg.length() + 1;
>>>>>               //it will throw a OutOfMemoryError.
>>>>>               msg.repeat(cnt);
>>>>>               done = true;
>>>>>           };
>>>>>
>>>>>           Thread thread = new Thread(runnable);
>>>>>           thread.start();
>>>>>           while(!done) {
>>>>>           } // this simulates the main loop of event handling
>>>>>       }
>>>>> }
>>>>>
>>>>> Java developers can use
>>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError to exercise fail-fast
>>>>> principle. Java web application which handle traffics are usually
>>>>> distributed in a cluster. A failure of a single host usually is not a
>>>>> big deal. As long as java exits, it's easy to restart and backfill it.
>>>>>
>>>>> My proposing change is very simple. Just call
>>>>> report_java_out_of_memory() if value_string is OOME. It's no-op if users
>>>>> never specify anything. If they do specify flags like
>>>>> Crash/ExitOnOutOfMemory,  OnOutOfMemoryError or
>>>>> HeapDumpOnOutOfMemoryError, HotSpot will let report_java_out_of_memory
>>>>> does the cleanup job. fatal() works but too brutal. I think we should
>>>>> let java exits with error code.
>>>>>
>>>>>
>>>>> diff --git a/src/hotspot/share/utilities/exceptions.cpp
>>>>> b/src/hotspot/share/utilities/exceptions.cpp
>>>>> index bd95b8306be..fd8a83deaf3 100644
>>>>> --- a/src/hotspot/share/utilities/exceptions.cpp
>>>>> +++ b/src/hotspot/share/utilities/exceptions.cpp
>>>>> @@ -538,6 +538,9 @@ void Exceptions::debug_check_abort(const char
>>>>> *value_string, const char* message
>>>>>          strstr(value_string, AbortVMOnException)) {
>>>>>        if (AbortVMOnExceptionMessage == NULL || (message != NULL &&
>>>>>            strstr(message, AbortVMOnExceptionMessage))) {
>>>>> +      if(!strcmp(value_string, "java.lang.OutOfMemoryError")) {
>>>>> +        report_java_out_of_memory(message);
>>>>> +      }
>>>>>          fatal("Saw %s, aborting", value_string);
>>>>>        }
>>>>>      }
>>>>>
>>>>>
>>>>> thanks,
>>>>> --lx
>>>>>

From dholmes at openjdk.java.net  Wed Sep  8 22:47:03 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 22:47:03 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <BVczQRHbTPXB2ACwW8vd0bdw12sxQjIXK4Xgv0CNAkU=.73b91222-c157-4a67-8ac8-4dd53bc225a4@github.com>
References: <BVczQRHbTPXB2ACwW8vd0bdw12sxQjIXK4Xgv0CNAkU=.73b91222-c157-4a67-8ac8-4dd53bc225a4@github.com>
Message-ID: <VqXH4PXmDeEYu55c71YAd5efuOV92PoEOSkbsPFk8tI=.3c82d0c3-4ecf-4c6d-8813-1c84b7ea02d5@github.com>

On Wed, 8 Sep 2021 19:33:51 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Hi Yumin,

> Changed cdsOffsets.cpp to cdsConstants.cpp

This is not showing up in the PR as a rename but as a new file. So there is no way to know what changes you may have made inside cdsConstants.cpp. The header file change shows as a rename. 

David

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

PR: https://git.openjdk.java.net/jdk/pull/5423

From dcubed at openjdk.java.net  Wed Sep  8 23:15:09 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 8 Sep 2021 23:15:09 GMT
Subject: Integrated: 8273109:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest times out
In-Reply-To: <e9lbtC735dycA07sLTdum_EM87ByvzQIOJ54YnFyXDc=.da85e0cf-1bbc-4e4d-a108-c72d568b98a0@github.com>
References: <Lh7DXLo_N1SbjJqaer7ZrtS2-nPpFbxFTBM6eOnur4c=.2eb62c70-73d8-4598-8d11-bdca3f04ff51@github.com>
 <e9lbtC735dycA07sLTdum_EM87ByvzQIOJ54YnFyXDc=.da85e0cf-1bbc-4e4d-a108-c72d568b98a0@github.com>
Message-ID: <NI9WIK_z_T8HJ3vYtdXjDi1951CNVZw32AxDKuaZv9A=.38003fdb-5123-48d1-9939-67b87cff1191@github.com>

On Wed, 8 Sep 2021 19:37:30 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> A trivial fix to increase the timeouts for the two sub-tests in
>> runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java.
>
> Looks good to me.

@mseledts - Thanks for the review. It was after the integration
so you won't be listed. Sorry about that.

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

PR: https://git.openjdk.java.net/jdk/pull/5422

From dholmes at openjdk.java.net  Wed Sep  8 23:21:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 8 Sep 2021 23:21:00 GMT
Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests [v2]
In-Reply-To: <NWE5FMgkpOth-1g9q9EKXMSx8SpQcy22N7K62I5pWRw=.682edff3-22c2-400d-b9a8-e477ce4bd8d0@github.com>
References: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
 <NWE5FMgkpOth-1g9q9EKXMSx8SpQcy22N7K62I5pWRw=.682edff3-22c2-400d-b9a8-e477ce4bd8d0@github.com>
Message-ID: <VDUqb88JbxhJDXVx5dbyIgn7hMITN72d-RaBngZKA9Q=.6bbbd7ba-e78a-43fc-a15c-dfe402da1529@github.com>

On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>> 
>> 
>> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java
>> 
>> STDERR:
>> java.lang.Error: TESTBUG: unsupported vm variant
>> at jdk.test.lib.Platform.variant(Platform.java:368)
>> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
>> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
>> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Build system awkwardness ensues

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From dholmes at openjdk.java.net  Thu Sep  9 00:38:14 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 00:38:14 GMT
Subject: RFR: 8273516: ProblemList compiler/c2/Test7179138_1.java in
 -Xcomp mode on win-X64
In-Reply-To: <UGtxoyHu5SrXVmukUc_inEsOJtecso_y2A3m1ExSPGM=.8ea239e2-4585-4d6c-bd02-e66fc7ec1743@github.com>
References: <UGtxoyHu5SrXVmukUc_inEsOJtecso_y2A3m1ExSPGM=.8ea239e2-4585-4d6c-bd02-e66fc7ec1743@github.com>
Message-ID: <fafSDCmaQwSvTraITxcw4xTbivfv29He_V9Jg_obnqo=.9c30936e-ed1f-43ec-85c6-3dc97a82e136@github.com>

On Thu, 9 Sep 2021 00:26:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64.

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5429

From dcubed at openjdk.java.net  Thu Sep  9 00:38:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 9 Sep 2021 00:38:14 GMT
Subject: RFR: 8273516: ProblemList compiler/c2/Test7179138_1.java in -Xcomp
 mode on win-X64
Message-ID: <UGtxoyHu5SrXVmukUc_inEsOJtecso_y2A3m1ExSPGM=.8ea239e2-4585-4d6c-bd02-e66fc7ec1743@github.com>

A trivial fix to ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64.

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

Commit messages:
 - 8273516: ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64

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

PR: https://git.openjdk.java.net/jdk/pull/5429

From dcubed at openjdk.java.net  Thu Sep  9 00:42:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 9 Sep 2021 00:42:06 GMT
Subject: Integrated: 8273516: ProblemList compiler/c2/Test7179138_1.java in
 -Xcomp mode on win-X64
In-Reply-To: <UGtxoyHu5SrXVmukUc_inEsOJtecso_y2A3m1ExSPGM=.8ea239e2-4585-4d6c-bd02-e66fc7ec1743@github.com>
References: <UGtxoyHu5SrXVmukUc_inEsOJtecso_y2A3m1ExSPGM=.8ea239e2-4585-4d6c-bd02-e66fc7ec1743@github.com>
Message-ID: <2JTmwcx91SrWjJc-S1NazwivueHTWLEv7pO6sNjg88o=.ac449202-9826-4c4a-b013-4f4222711072@github.com>

On Thu, 9 Sep 2021 00:26:15 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64.

This pull request has now been integrated.

Changeset: 12f0b771
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/12f0b771791614b8a41fc2c62d34481f911109b0
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8273516: ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5429

From dcubed at openjdk.java.net  Thu Sep  9 00:42:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 9 Sep 2021 00:42:06 GMT
Subject: RFR: 8273516: ProblemList compiler/c2/Test7179138_1.java in
 -Xcomp mode on win-X64
In-Reply-To: <fafSDCmaQwSvTraITxcw4xTbivfv29He_V9Jg_obnqo=.9c30936e-ed1f-43ec-85c6-3dc97a82e136@github.com>
References: <UGtxoyHu5SrXVmukUc_inEsOJtecso_y2A3m1ExSPGM=.8ea239e2-4585-4d6c-bd02-e66fc7ec1743@github.com>
 <fafSDCmaQwSvTraITxcw4xTbivfv29He_V9Jg_obnqo=.9c30936e-ed1f-43ec-85c6-3dc97a82e136@github.com>
Message-ID: <vE79sk3VtvgGs5j1EXdsuaRGnxaquA4GnIgeLWAE3jY=.20ec6be0-ef64-4ba9-864e-47ab909a4f6d@github.com>

On Thu, 9 Sep 2021 00:33:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> A trivial fix to ProblemList compiler/c2/Test7179138_1.java in -Xcomp mode on win-X64.
>
> Marked as reviewed by dholmes (Reviewer).

@dholmes-ora - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5429

From dholmes at openjdk.java.net  Thu Sep  9 01:12:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 01:12:00 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <gM2suv80qi9jFsgGMGDf5ecpEUfTV0Rg5UmGfHmNwo0=.8a0bde73-bad6-4ff5-813f-98daeef91d83@github.com>

On Wed, 8 Sep 2021 06:12:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

Hi Yasumasa,

Functional changes look good.

A few issues with comments and a request with the documentation change.

Thanks,
David

src/hotspot/share/logging/logConfiguration.cpp line 413:

> 411:   // (options for existing output can't be applied.)
> 412:   // StdoutLog and StderrLog are already instantiated at static initializer
> 413:   // in logFileStreamOutput.cpp.

Suggested rewording to resolve a number of grammatical issues:
// Normally options can't be used to change an existing output (parse_log_arguments() will
// report an error), and both StdoutLog and StderrLog are created by static initializers, so we have
// to process their options (e.g. foldmultilines) directly first.

src/hotspot/share/logging/logConfiguration.cpp line 417:

> 415:       strcmp("stdout", output) == 0 || strcmp("#0", output) == 0) {
> 416:     success = StdoutLog.parse_options(output_options, &ss);
> 417:     // We are no longer to need to pass output options to parse_log_arguments().

// We no longer need to pass ...

src/hotspot/share/logging/logConfiguration.cpp line 421:

> 419:   } else if (strcmp("stderr", output) == 0 || strcmp("#1", output) == 0) {
> 420:     success = StderrLog.parse_options(output_options, &ss);
> 421:     // We are no longer to need to pass output options to parse_log_arguments().

// We no longer need to pass ...

src/hotspot/share/logging/logConfiguration.cpp line 582:

> 580:   LogTagSet::describe_tagsets(out);
> 581: 
> 582:   out->print_cr("\nAvailable log output options:");

It doesn't seem right to me to have a section on output options first, but the way the rest of this section is structured makes it awkward to ordering things appropriately. Ideally, to me, we would have this order:
- Available log outputs
- Available log output options
- Additional file output options

test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java line 44:

> 42:     private static String EXCEPTION_MESSAGE = "line 1\nline 2\\nstring";
> 43:     private static String FOLDED_EXCEPTION_MESSAGE = "line 1\\nline 2\\\\nstring";
> 44:     // Windows may out "\r\n" even though UL outs "\n" only, so we need to evaluate regex with \R.

s/out/output

Though you should always use \R to get a regex match on new-lines so I'm not sure you need to say anything.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5407

From mseledtsov at openjdk.java.net  Thu Sep  9 02:03:05 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Thu, 9 Sep 2021 02:03:05 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
Message-ID: <vgSlVTbb2jLhoP_jxJLhBnIi2Klw8-qJ2HUEG8A2HeI=.c26223c6-4c6d-4dcc-b368-21d59afc1b26@github.com>

On Tue, 7 Sep 2021 13:17:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
> 
> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14 
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25 
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s

The internal history of the change that restricted parallelism for this test set indicates that it was a wide reaching change covering a wide set of stress tests. Based on Aleksey's comment in the PR the tests "seem to be rather short, effectively single-threaded, and memory-dense tests, so they seem to qualify for this kind of relaxation." I tend to agree with his assessment.

I have also executed these tests with the change on 5 different platforms, 100 times on each platform, and found no issues. The change looks good to me.

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

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5389

From ysuenaga at openjdk.java.net  Thu Sep  9 02:16:26 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 02:16:26 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Fix comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5407/files
  - new: https://git.openjdk.java.net/jdk/pull/5407/files/057b06ea..65d5184b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=00-01

  Stats: 32 lines in 2 files changed: 9 ins; 7 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5407/head:pull/5407

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Thu Sep  9 02:16:26 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 02:16:26 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <gM2suv80qi9jFsgGMGDf5ecpEUfTV0Rg5UmGfHmNwo0=.8a0bde73-bad6-4ff5-813f-98daeef91d83@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <gM2suv80qi9jFsgGMGDf5ecpEUfTV0Rg5UmGfHmNwo0=.8a0bde73-bad6-4ff5-813f-98daeef91d83@github.com>
Message-ID: <l1n7_7SvnFrCYy9W7x4pF_5zq-3KYiz3L20--oL2FY4=.3bfac480-1e18-463c-8e73-4b0218942c1b@github.com>

On Thu, 9 Sep 2021 01:08:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comments
>
> Hi Yasumasa,
> 
> Functional changes look good.
> 
> A few issues with comments and a request with the documentation change.
> 
> Thanks,
> David

@dholmes-ora Thanks for your comment! I fixed them in new commit.
We can see following help messages with `-Xlog:help` :


Available log outputs:
 stdout/stderr
 file=<filename>
  If the filename contains %p and/or %t, they will expand to the JVM's PID and startup timestamp, respectively.

Available log output options:
 foldmultilines=.. - If set to true, a log event that consists of multiple lines will be folded into a single line by replacing newline characters with the sequence '' and 'n' in the output. Existing single backslash characters will also be replaced with a sequence of two backslashes so that the conversion can be reversed. This option is safe to use with UTF-8 character encodings, but other encodings may not work.

Additional file output options:
 filesize=..       - Target byte size for log rotation (supports K/M/G suffix). If set to 0, log rotation will not trigger automatically, but can be performed manually (see the VM.log DCMD).
 filecount=..      - Number of files to keep in rotation (not counting the active file). If set to 0, log rotation is disabled. This will cause existing log files to be overwritten.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From dholmes at openjdk.java.net  Thu Sep  9 02:29:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 02:29:57 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
Message-ID: <L3hxhMd4-tRUXMC9QCiB-Ibk0YGmWWoeG8yl8WLeaDM=.2a353aee-1f6c-42ae-bf10-aa0e13642543@github.com>

On Tue, 7 Sep 2021 13:17:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
> 
> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14 
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25 
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From dholmes at openjdk.java.net  Thu Sep  9 02:33:00 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 02:33:00 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
Message-ID: <9h1S3F4v2axjCLbCjhchXMc2-A4gDU9r1StLLwcIsW8=.48e683ef-c87c-48a0-b232-83919c350f2a@github.com>

On Thu, 9 Sep 2021 02:16:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Updates look good to me.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5407

From minqi at openjdk.java.net  Thu Sep  9 03:16:02 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 9 Sep 2021 03:16:02 GMT
Subject: RFR: 8271569: Change cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <VqXH4PXmDeEYu55c71YAd5efuOV92PoEOSkbsPFk8tI=.3c82d0c3-4ecf-4c6d-8813-1c84b7ea02d5@github.com>
References: <BVczQRHbTPXB2ACwW8vd0bdw12sxQjIXK4Xgv0CNAkU=.73b91222-c157-4a67-8ac8-4dd53bc225a4@github.com>
 <VqXH4PXmDeEYu55c71YAd5efuOV92PoEOSkbsPFk8tI=.3c82d0c3-4ecf-4c6d-8813-1c84b7ea02d5@github.com>
Message-ID: <U4vq9I9Oic6SvKQIG4lkYkl1Znd01s87qHM52OQYOVo=.dc1914ef-8e7d-41d0-83cb-b146f7b5b2a5@github.com>

On Wed, 8 Sep 2021 22:44:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Yumin,
> 
> > Changed cdsOffsets.cpp to cdsConstants.cpp
> 
> This is not showing up in the PR as a rename but as a new file. So there is no way to know what changes you may have made inside cdsConstants.cpp. The header file change shows as a rename.
> 
> David

Hi, David
  git did not rename the 'old' to 'new' so the patch showed cdsConstants.cpp as a 'new' file. So I will change description as you indicated. Thanks

Yumin

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

PR: https://git.openjdk.java.net/jdk/pull/5423

From david.holmes at oracle.com  Thu Sep  9 04:00:58 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Sep 2021 14:00:58 +1000
Subject: RFR: 8271569: Change cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <U4vq9I9Oic6SvKQIG4lkYkl1Znd01s87qHM52OQYOVo=.dc1914ef-8e7d-41d0-83cb-b146f7b5b2a5@github.com>
References: <BVczQRHbTPXB2ACwW8vd0bdw12sxQjIXK4Xgv0CNAkU=.73b91222-c157-4a67-8ac8-4dd53bc225a4@github.com>
 <VqXH4PXmDeEYu55c71YAd5efuOV92PoEOSkbsPFk8tI=.3c82d0c3-4ecf-4c6d-8813-1c84b7ea02d5@github.com>
 <U4vq9I9Oic6SvKQIG4lkYkl1Znd01s87qHM52OQYOVo=.dc1914ef-8e7d-41d0-83cb-b146f7b5b2a5@github.com>
Message-ID: <36f4f278-8052-db3e-ae88-793f47dae48b@oracle.com>

On 9/09/2021 1:16 pm, Yumin Qi wrote:
> On Wed, 8 Sep 2021 22:44:14 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> Hi Yumin,
>>
>>> Changed cdsOffsets.cpp to cdsConstants.cpp
>>
>> This is not showing up in the PR as a rename but as a new file. So there is no way to know what changes you may have made inside cdsConstants.cpp. The header file change shows as a rename.
>>
>> David
> 
> Hi, David
>    git did not rename the 'old' to 'new' so the patch showed cdsConstants.cpp as a 'new' file. So I will change description as you indicated. Thanks

?? I'd rather you try again and do a rename :) Otherwise please advise 
what, if any, changes were actually made to the "new" file?

Thanks,
David

> Yumin
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5423
> 

From minqi at openjdk.java.net  Thu Sep  9 04:28:01 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 9 Sep 2021 04:28:01 GMT
Subject: RFR: 8271569: Change cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <VqXH4PXmDeEYu55c71YAd5efuOV92PoEOSkbsPFk8tI=.3c82d0c3-4ecf-4c6d-8813-1c84b7ea02d5@github.com>
References: <BVczQRHbTPXB2ACwW8vd0bdw12sxQjIXK4Xgv0CNAkU=.73b91222-c157-4a67-8ac8-4dd53bc225a4@github.com>
 <VqXH4PXmDeEYu55c71YAd5efuOV92PoEOSkbsPFk8tI=.3c82d0c3-4ecf-4c6d-8813-1c84b7ea02d5@github.com>
Message-ID: <Iac7mx3qBJasNTvUucVdh_NBMfV90dab8fFi23KUy44=.71b17a0b-5c2a-4b43-a8a8-2a273fd66813@github.com>

On Wed, 8 Sep 2021 22:44:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Hi Yumin,
> 
>> Changed cdsOffsets.cpp to cdsConstants.cpp
> 
> This is not showing up in the PR as a rename but as a new file. So there is no way to know what changes you may have made inside cdsConstants.cpp. The header file change shows as a rename. 
> 
> David

@dholmes-ora I see your point here --- let me redo the patch using rename.

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

PR: https://git.openjdk.java.net/jdk/pull/5423

From minqi at openjdk.java.net  Thu Sep  9 04:34:06 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 9 Sep 2021 04:34:06 GMT
Subject: Withdrawn: 8271569: Change cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <BVczQRHbTPXB2ACwW8vd0bdw12sxQjIXK4Xgv0CNAkU=.73b91222-c157-4a67-8ac8-4dd53bc225a4@github.com>
References: <BVczQRHbTPXB2ACwW8vd0bdw12sxQjIXK4Xgv0CNAkU=.73b91222-c157-4a67-8ac8-4dd53bc225a4@github.com>
Message-ID: <pTvTl1HnY2M5IWJCYVl9X-m9EOxg0bt5B5fCNbbQ5WU=.cc515718-f155-4bd0-9b81-1e8e1d888cab@github.com>

On Wed, 8 Sep 2021 19:33:51 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/5423

From ysuenaga at openjdk.java.net  Thu Sep  9 05:32:01 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 05:32:01 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
Message-ID: <yGt7FoF_00RIy2HYM8j2292qrYn6OmZe4gnqzSNCl14=.6efd069e-823f-4815-bcda-5f1aa35c531e@github.com>

On Thu, 9 Sep 2021 02:16:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

My latest change failed on InfoOptsTest, but it seems to be a bug in InfoOptsTest, does not be caused by this PR:

InfoOptsTest.jtr

Main [-fullversion, -fullversion] []
rc:0
javac/DIRECT:
javac full version "18-internal+0-YaSuenag-65d5184b8598c255c78269e2c30b900d33af8416"
>>>>> Expected string appears more than once: 18

java.lang.Exception: 1 errors occurred
        at OptionModesTester.runTests(OptionModesTester.java:81)
        at InfoOptsTest.main(InfoOptsTest.java:41)


OptionModesTester.java

        TestResult checkUniqueLog(Log l, String... uniqueExpects) {
            String log = logs.get(l);
            for (String e : uniqueExpects) {
                if (!log.contains(e)) {
                    error("Expected string not found: " + e);
                } else if (log.indexOf(e) != log.lastIndexOf(e)) {
                    error("Expected string appears more than once: " + e);
                }
            }
            return this;
        }


My commit hash has "18" in the string (`65d5184b8598c255c78269e2c30b900d33af8416`), so `log.indexOf(e) != log.lastIndexOf(e)` is true if `e` is "18" (feature version).

I will file it to JBS later.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From iklam at openjdk.java.net  Thu Sep  9 06:02:04 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 9 Sep 2021 06:02:04 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
Message-ID: <OkLWkTQhdaEMPVmLHlsSQm8wcKqgH8JJythjowbocQ4=.0569b631-d476-4dc7-913a-b9ba78c73ea1@github.com>

On Thu, 9 Sep 2021 02:16:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

Also, if the user specifies foldmultilines multiple times for stdout/stderr


-Xlog:exceptions:::foldmultilines=true -Xlog:cds:::foldmultilines=false


Do we (or should) we print a warning message?

Today we'd get an warning with a command like the following, and the second foldmultilines=false is ignored. I think stdout/stderr should have the same behavior. (But the current message is too vague and should be improved, maybe in a different RFE).


$ java -Xlog:exceptions:file=foo::foldmultilines=true -Xlog:cds:file=foo::foldmultilines=false  XXX
[0.000s][warning][logging] Output options for existing outputs are ignored.
Error: Could not find or load main class XXX
Caused by: java.lang.ClassNotFoundException: XXX

test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java line 102:

> 100:         test("file=" + EXCEPTION_LOG_FILE);
> 101:         test("stdout");
> 102:         test("stderr");

I think we should add a case whe the output is not explicitly specified. I.e.,


-Xlog:exceptions=info:::foldmultilines=true

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

Changes requested by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5407

From stuefe at openjdk.java.net  Thu Sep  9 06:57:04 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 9 Sep 2021 06:57:04 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero
In-Reply-To: <LyyYk52UczFQ6_9d8Lfk6gN6jNEYxbkpjE4LnWv1Je8=.29f77cb9-2cb0-47ac-b56c-ede82d3a216b@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <BWVcVbDCdVeVv-WvKJWgpxxB_1k2QUUGlfC6eO7TL7Q=.6dc3a154-5c3c-4f1b-98c2-d02abd6d9dcb@github.com>
 <LyyYk52UczFQ6_9d8Lfk6gN6jNEYxbkpjE4LnWv1Je8=.29f77cb9-2cb0-47ac-b56c-ede82d3a216b@github.com>
Message-ID: <6bO07HAoHeelMAFPcfDNJQqgeGVpprkgIgySe9Ok0gs=.6af09365-94f1-4c4d-a80d-e7fb39e0634e@github.com>

On Wed, 8 Sep 2021 09:19:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > Bottomline, we should either be using `pthread_attr_getstack(3)` or our `_initial_thread_stack_(bottom|size)` but not mix them since they may differ. Therefore the proposed patch is correct. The non-zero version of `current_stack_region()` in os_linux.cpp handles the primordial thread stack correctly.
> 
> Yes, that seems to be the gist of it. In fact, if I reply `_initial_thread_stack_(bottom|size)` in Zero version of `current_stack_region()` for a primordial thread, gtests also start to pass. But I gather there is no need to continue supporting Zero-specific `current_stack_region()`, and thus dodge the issue altogether by using the code the rest of VM code uses.

Yes, and zero also needs Goetz' fix for the glibc guard size problem in JDK-8169373.

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From stuefe at openjdk.java.net  Thu Sep  9 07:00:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 9 Sep 2021 07:00:07 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero
In-Reply-To: <tWPWbXYYEC1pDWHWEmhTG3moBnSqTNZGle-Ieb698Sk=.ddfa2fa2-703b-4952-8df1-84bf99f04870@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <tWPWbXYYEC1pDWHWEmhTG3moBnSqTNZGle-Ieb698Sk=.ddfa2fa2-703b-4952-8df1-84bf99f04870@github.com>
Message-ID: <v9rXuVG8vUHY6wf4G9CXZazEyiUoMwL-Pr9co8T9BWY=.52ad0905-4fdc-46c8-a565-fdf0ba59ca86@github.com>

On Wed, 8 Sep 2021 10:21:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I looked around Debian's support for IA64, and I think we don't want to drop the support for it just yet. Zero VM is one of those last stands for weird arches portability :) Instead of adding the `IA64` block to a shared code, I shall try to make a more conservative fix to Zero-specific code then...

I'd be surprised if it still works in JDK 18 though. The latest they build is 15. ia64 breaks so easily, and no one took care of it in the recent past.

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From david.holmes at oracle.com  Thu Sep  9 07:46:57 2021
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Sep 2021 17:46:57 +1000
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <yGt7FoF_00RIy2HYM8j2292qrYn6OmZe4gnqzSNCl14=.6efd069e-823f-4815-bcda-5f1aa35c531e@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
 <yGt7FoF_00RIy2HYM8j2292qrYn6OmZe4gnqzSNCl14=.6efd069e-823f-4815-bcda-5f1aa35c531e@github.com>
Message-ID: <cd3f65f5-7ff8-2031-6778-1538011aa294@oracle.com>

On 9/09/2021 3:32 pm, Yasumasa Suenaga wrote:
> My commit hash has "18" in the string (`65d5184b8598c255c78269e2c30b900d33af8416`), so `log.indexOf(e) != log.lastIndexOf(e)` is true if `e` is "18" (feature version).
> 
> I will file it to JBS later.

I'm pretty sure this has already been seen and reported.

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5407
> 

From shade at openjdk.java.net  Thu Sep  9 08:10:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 08:10:10 GMT
Subject: Integrated: 8273487: Zero: Handle "zero" variant in runtime tests
In-Reply-To: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
References: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
Message-ID: <5FZ8wHoYKStQS8Vipmacd9L_xUmUpo0lsKjhFA6ALeE=.9282d76e-f1d8-441e-a6e9-d968328213bf@github.com>

On Wed, 8 Sep 2021 10:57:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java
> 
> STDERR:
> java.lang.Error: TESTBUG: unsupported vm variant
> at jdk.test.lib.Platform.variant(Platform.java:368)
> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run

This pull request has now been integrated.

Changeset: 8c16f485
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8c16f485b341ee3071c91df39dfb9ba8b9caa44d
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8273487: Zero: Handle "zero" variant in runtime tests

Reviewed-by: alanb, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From shade at openjdk.java.net  Thu Sep  9 08:10:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 08:10:09 GMT
Subject: RFR: 8273487: Zero: Handle "zero" variant in runtime tests [v2]
In-Reply-To: <NWE5FMgkpOth-1g9q9EKXMSx8SpQcy22N7K62I5pWRw=.682edff3-22c2-400d-b9a8-e477ce4bd8d0@github.com>
References: <TAYiBmMCRFZ-kbS-iKcvrnxIhWshopdhIhl0Rj6Lisw=.b17af51a-957b-4c0a-aeee-e90abf1b3e4a@github.com>
 <NWE5FMgkpOth-1g9q9EKXMSx8SpQcy22N7K62I5pWRw=.682edff3-22c2-400d-b9a8-e477ce4bd8d0@github.com>
Message-ID: <OmRsRQ8L8evn-Fdhx8anUNeB3p6MTplf9P0nXQj5HTQ=.1d9b6057-af99-41ef-bf92-f8e0b266caa5@github.com>

On Wed, 8 Sep 2021 13:25:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> JDK-8179317 rewritten runtime shell tests to Java. There is a little omission in VM variant selection, which makes Zero fail some of the tier1 tests, like:
>> 
>> 
>> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=runtime/StackGap/TestStackGap.java
>> 
>> STDERR:
>> java.lang.Error: TESTBUG: unsupported vm variant
>> at jdk.test.lib.Platform.variant(Platform.java:368)
>> at jdk.test.lib.Platform.jvmLibDir(Platform.java:357)
>> at jdk.test.lib.process.ProcessTools.addJvmLib(ProcessTools.java:585)
>> at jdk.test.lib.process.ProcessTools.createNativeTestProcessBuilder(ProcessTools.java:575) 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero affected tests (StackGap, StackGuardPages, TestTLS) now run
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Build system awkwardness ensues

I am integrating this to get the more complete `tier1` runs for Zero, and then I would tackle JDK-8273494.

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

PR: https://git.openjdk.java.net/jdk/pull/5413

From mbaesken at openjdk.java.net  Thu Sep  9 09:29:14 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 9 Sep 2021 09:29:14 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current
Message-ID: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>

https://bugs.openjdk.java.net/browse/JDK-8266490
extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
that would be helpful too and can be added to the OSContainer API .
pids.current :
A read-only single value file which exists on all cgroups.
The number of processes currently in the cgroup and its descendants.

Best regards, Matthias

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

Commit messages:
 - JDK-8273526

Changes: https://git.openjdk.java.net/jdk/pull/5437/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273526
  Stats: 104 lines in 15 files changed: 102 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437

PR: https://git.openjdk.java.net/jdk/pull/5437

From ysuenaga at openjdk.java.net  Thu Sep  9 09:30:35 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 09:30:35 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v3]
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <nAiUVg51vtgvUCMFX-mvXkJ2M27NYgNCmCrUiYk8mhE=.175826f3-5e28-4f14-ab5a-6a823db606d5@github.com>

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

Yasumasa Suenaga 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 remote-tracking branch 'upstream/master' into JDK-8273471
 - Add test for default log output (stdout)
 - Fix comments
 - 8273471: Add foldmultilines to UL for stdout/err

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5407/files
  - new: https://git.openjdk.java.net/jdk/pull/5407/files/65d5184b..668ec10c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=01-02

  Stats: 2708 lines in 187 files changed: 1434 ins; 456 del; 818 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5407/head:pull/5407

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Thu Sep  9 09:30:37 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 09:30:37 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <OkLWkTQhdaEMPVmLHlsSQm8wcKqgH8JJythjowbocQ4=.0569b631-d476-4dc7-913a-b9ba78c73ea1@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
 <OkLWkTQhdaEMPVmLHlsSQm8wcKqgH8JJythjowbocQ4=.0569b631-d476-4dc7-913a-b9ba78c73ea1@github.com>
Message-ID: <67YJHnuujM2J3p7_o6Q-eAwBL7DIYdydsXg6c2TDeJ8=.8b0aca35-970e-4303-a2a6-f91dfc99fa67@github.com>

On Thu, 9 Sep 2021 05:58:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Also, if the user specifies foldmultilines multiple times for stdout/stderr
> 
> ```
> -Xlog:exceptions:::foldmultilines=true -Xlog:cds:::foldmultilines=false
> ```
> 
> Do we (or should) we print a warning message?
> 
> Today we'd get an warning with a command like the following, and the second foldmultilines=false is ignored. I think stdout/stderr should have the same behavior. (But the current message is too vague and should be improved, maybe in a different RFE).

I saw same issue in JDK 16, so I want to fix it as another RFE. I will file it later.


$ /usr/lib/jvm/java-16-openjdk/bin/java -Xlog:os=warning:file=test.log::filecount=1 -Xlog:exceptions=
info:file=test.log::filecount=1 --version
[0.000s][warning][logging] Output options for existing outputs are ignored.
openjdk 16.0.2 2021-07-20
OpenJDK Runtime Environment 21.3 (build 16.0.2+7)
OpenJDK 64-Bit Server VM 21.3 (build 16.0.2+7, mixed mode, sharing)


So can you review this change?

> test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java line 102:
> 
>> 100:         test("file=" + EXCEPTION_LOG_FILE);
>> 101:         test("stdout");
>> 102:         test("stderr");
> 
> I think we should add a case whe the output is not explicitly specified. I.e.,
> 
> 
> -Xlog:exceptions=info:::foldmultilines=true

I added test for this pattern in new commit.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Thu Sep  9 09:30:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 09:30:40 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
Message-ID: <3VqeyDdixlyCrxYMiDOcRMoVsbyU7q9aZO_kFavDVak=.ae17b15b-1f35-4785-8e2a-f1b4e6a2d86e@github.com>

On Thu, 9 Sep 2021 02:16:26 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix comments

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 9/09/2021 3:32 pm, Yasumasa Suenaga wrote:
> 
> > My commit hash has "18" in the string (`65d5184b8598c255c78269e2c30b900d33af8416`), so `log.indexOf(e) != log.lastIndexOf(e)` is true if `e` is "18" (feature version).
> > I will file it to JBS later.
> 
> I'm pretty sure this has already been seen and reported.

Thanks! I think it is https://github.com/openjdk/jdk/commit/267c61a16a916e35762e8df5737ec74b06defae8 and it has been pushed 17 hours ago!
I merged current HEAD of upstream, so I believe this issue has gone :)

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From xxinliu at amazon.com  Thu Sep  9 10:00:17 2021
From: xxinliu at amazon.com (Liu, Xin)
Date: Thu, 9 Sep 2021 03:00:17 -0700
Subject: RFC: call report_java_out_of_memory_error() for
 -XX:AbortVMOnException=java.lang.OutOfMemoryError
In-Reply-To: <9a2a3b98-de10-3ba9-1c2f-8a9904f3ed70@oracle.com>
References: <4ef699cc-a5bb-f93c-c62a-ef9d6cbd2e4f@amazon.com>
 <6ac33111-de76-3606-4a5e-817f115dacab@oracle.com>
 <4ee742a3-ec29-5f54-d9b3-557cd09148b3@amazon.com>
 <CA+3eh10+PMpDsokREg8TS8utTkrg-4n9fSTdb7QL0R3jRWEfBQ@mail.gmail.com>
 <cbdc4d54-63fe-be7c-9e60-2a58e925e1c1@amazon.com>
 <9a2a3b98-de10-3ba9-1c2f-8a9904f3ed70@oracle.com>
Message-ID: <fad92c30-c5f3-67b2-9a20-3c83fc66d618@amazon.com>

hi, Volker and David,

Thanks for the comments. I follow this idea and it works. At least it
works with '-XX:AbortVMOnException=java.lang.OutOfMemoryError'. I can
use -XX:OnError='jcmd %p' to dump threads or heap. It can be done
without a regression.
https://github.com/navyxliu/jdk/actions/runs/1216082580

I found that I am not the only person trying to do so. JFR does the
similar thing in even harder situation.
https://github.com/openjdk/jdk/blob/master/src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp#L543

Coredump works but it will generate a very big file which is hard to
transfer and may contain sensitive data. Further, it's not all java
developers know how to analyze a coredump. It require both executable
and debuginfo.

fatal() doesn't do anything disrupted, all threads should be in good
shape when it executes OnError callbacks. I think we can use
OnError=jcmd %p as complementary approach. It's deadlock now, we have
nothing to lose.

thanks,
--lx


On 9/8/21 3:08 PM, David Holmes wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> On 9/09/2021 4:48 am, Liu, Xin wrote:
>> hi, Volker,
>>
>> I think it's possible to allow OnError=jcmd to attach to the parent
>> process. HotSpot defines OnError as "Run user-defined commands on fatal
>> error; see VMError.cpp for examples". It's a callback for fatal errors.
>> fatal() means HotSpot starts aborting and does not notify other threads.
>>   In other words, other threads are in normal states. I observe so in
>> gdb.  All other threads are successful to enter safepoint safe state
>> except the main java thread.
>>
>> I am not advocating using jcmd %p in OnError. I am exploring a
>> possibility. Currently, we will end up a deadlock if you do so. If we
>> made it, we would at least get more information from Hotspot. We will
>> fail-fast if something bad happen. I think fail-fast is still better
>> than a hanging process.
> 
> It may be possible to fix the safepoint deadlock by transitioning the
> thread executing the OnError command to _thread_in_native beforehand -
> but there are constraints on doing that e.g. no oocks can be held. And
> if the error is processed in the VMThread then there is nothing that can
> be done.
> 
> But I agree with Volker that given a fatal error has been encountered,
> trying to report other information about the VM in a live manner is
> fraught with peril. Using a core dump for post mortem analysis would
> probably be better.
> 
> Cheers,
> David
> 
>> thanks,
>> --lx
>>
>>
>>
>>
>> On 9/8/21 10:35 AM, Volker Simonis wrote:
>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>
>>>
>>>
>>> I'm not sure if running a jcmd process which attaches to the dying VM
>>> as part of the OnError scripts is a use case we really want to
>>> support?
>>>
>>> There's a reason why the VM is crashing and attaching to this dying VM
>>> will most probably only cause other follow-up errors.
>>>
>>> On Wed, Sep 8, 2021 at 7:22 PM Liu, Xin <xxinliu at amazon.com> wrote:
>>>>
>>>> Hi, David,
>>>>
>>>> Thanks for the head-up. yes, it works for me.
>>>>
>>>> There's one more thing. One drawback is that the script providing to
>>>> OnError can't trap hotspot itself or we end up with a deadlock.
>>>>
>>>>
>>>> If we use 'jcmd %p Thread.print' or 'jcmd %p GC.heap_dump <file>' in
>>>> OnError=, (%p means the java process itself), the main java thread which
>>>> is waiting for os::fork_and_exec(cmd) will prevent hotspot reach to the
>>>> safepoint. It's deadlock because no safepoint mean fork_and_exec can't
>>>> complete.
>>>>
>>>> eg.
>>>> $java -Xmx50m -XX:AbortVMOnException=java.lang.OutOfMemoryError
>>>> -XX:OnError='jcmd %p Thread.print' -XX:+SafepointTimeout OomDumpExample
>>>> direct
>>>> # To suppress the following error report, specify this argument
>>>> # after -XX: or in .hotspotrc:  SuppressErrorAt=/exceptions.cpp:541
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> #  Internal Error
>>>> (/home/xxinliu/Devel/jdk/src/hotspot/share/utilities/exceptions.cpp:541), pid=107552,
>>>> tid=107553
>>>> #  fatal error: Saw java.lang.OutOfMemoryError, aborting
>>>> #
>>>> # JRE version: OpenJDK Runtime Environment (18.0) (slowdebug build
>>>> 18-internal+0-adhoc.xxinliu.jdk)
>>>> # Java VM: OpenJDK 64-Bit Server VM (slowdebug
>>>> 18-internal+0-adhoc.xxinliu.jdk, mixed mode, tiered, compressed oops,
>>>> compressed class ptrs, g1 gc, linux-amd64)
>>>> # Problematic frame:
>>>> # V  [libjvm.so+0x924e8c]  Exceptions::debug_check_abort(char const*,
>>>> char const*)+0x8a
>>>> #
>>>> # No core dump will be written. Core dumps have been disabled. To enable
>>>> core dumping, try "ulimit -c unlimited" before starting Java again
>>>> #
>>>> # An error report file with more information is saved as:
>>>> # /local/home/xxinliu/JDK-2085/hs_err_pid107552.log
>>>> #
>>>> # If you would like to submit a bug report, please visit:
>>>> #   https://bugreport.java.com/bugreport/crash.jsp
>>>> #
>>>> #
>>>> # -XX:OnError="jcmd %p Thread.print"
>>>> #   Executing /bin/sh -c "jcmd 107552 Thread.print" ...
>>>> 107552:
>>>> [13.045s][warning][safepoint]
>>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timeout
>>>> detected:
>>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Timed out
>>>> while spinning to reach a safepoint.
>>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: Threads
>>>> which did not reach the safepoint:
>>>> [13.045s][warning][safepoint] # "main" #1 prio=5 os_prio=0 cpu=1552.12ms
>>>> elapsed=13.04s tid=0x00007f43600278e0 nid=107553 runnable
>>>> [0x00007f4369d9f000]
>>>> [13.045s][warning][safepoint]    java.lang.Thread.State: RUNNABLE
>>>> [13.045s][warning][safepoint] Thread: 0x00007f43600278e0  [0x1a421]
>>>> State: _running _at_poll_safepoint 0
>>>> [13.045s][warning][safepoint]    JavaThread state: _thread_in_vm
>>>> [13.045s][warning][safepoint]
>>>> [13.045s][warning][safepoint] # SafepointSynchronize::begin: (End of list)
>>>>
>>>>
>>>> I haven't figured out how yet, but I think I can lift this constraint.
>>>> Once I did, OnError would have more freedom to dump thread or heap
>>>> before dieing. Can I file bug about this?
>>>>
>>>> thanks,
>>>> --lx
>>>>
>>>>
>>>> On 8/30/21 9:26 PM, David Holmes wrote:
>>>>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> On 28/08/2021 4:54 am, Liu, Xin wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Recently I revisit JDK-8155004/JDK-8257790 because a new team trip over.
>>>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError works. I wonder
>>>>>> whether it is a good idea to call report_java_out_of_memory_error() when
>>>>>> OOME is trapped. In this way, HotSpot will trigger OnOutOfMemoryError
>>>>>> callbacks.
>>>>>
>>>>> Why not just use AbortVMOnException together with OnError to get the
>>>>> callbacks?
>>>>>
>>>>> Cheers,
>>>>> David
>>>>>
>>>>>> I understand JDK-8257790 is not a bug. I don't want to overthrow that
>>>>>> conclusion. I just wonder if we can handle it better in the presence of
>>>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError.
>>>>>>
>>>>>> For Java webservers, OOME may lead to a zombie process. We may have a
>>>>>> bug in code or indeed run out of memory. OOME is suppressed or terminate
>>>>>> the thread but don't terminate the java process. eg.
>>>>>>
>>>>>> public class Main {
>>>>>>       volatile static boolean done = false;
>>>>>>
>>>>>>       public static void main(String[] args) {
>>>>>>           String msg = "a long long message.";
>>>>>>           // write your code here
>>>>>>           Runnable runnable = () -> {
>>>>>>               int cnt = Integer.MAX_VALUE / msg.length() + 1;
>>>>>>               //it will throw a OutOfMemoryError.
>>>>>>               msg.repeat(cnt);
>>>>>>               done = true;
>>>>>>           };
>>>>>>
>>>>>>           Thread thread = new Thread(runnable);
>>>>>>           thread.start();
>>>>>>           while(!done) {
>>>>>>           } // this simulates the main loop of event handling
>>>>>>       }
>>>>>> }
>>>>>>
>>>>>> Java developers can use
>>>>>> -XX:AbortVMOnException=java.lang.OutOfMemoryError to exercise fail-fast
>>>>>> principle. Java web application which handle traffics are usually
>>>>>> distributed in a cluster. A failure of a single host usually is not a
>>>>>> big deal. As long as java exits, it's easy to restart and backfill it.
>>>>>>
>>>>>> My proposing change is very simple. Just call
>>>>>> report_java_out_of_memory() if value_string is OOME. It's no-op if users
>>>>>> never specify anything. If they do specify flags like
>>>>>> Crash/ExitOnOutOfMemory,  OnOutOfMemoryError or
>>>>>> HeapDumpOnOutOfMemoryError, HotSpot will let report_java_out_of_memory
>>>>>> does the cleanup job. fatal() works but too brutal. I think we should
>>>>>> let java exits with error code.
>>>>>>
>>>>>>
>>>>>> diff --git a/src/hotspot/share/utilities/exceptions.cpp
>>>>>> b/src/hotspot/share/utilities/exceptions.cpp
>>>>>> index bd95b8306be..fd8a83deaf3 100644
>>>>>> --- a/src/hotspot/share/utilities/exceptions.cpp
>>>>>> +++ b/src/hotspot/share/utilities/exceptions.cpp
>>>>>> @@ -538,6 +538,9 @@ void Exceptions::debug_check_abort(const char
>>>>>> *value_string, const char* message
>>>>>>          strstr(value_string, AbortVMOnException)) {
>>>>>>        if (AbortVMOnExceptionMessage == NULL || (message != NULL &&
>>>>>>            strstr(message, AbortVMOnExceptionMessage))) {
>>>>>> +      if(!strcmp(value_string, "java.lang.OutOfMemoryError")) {
>>>>>> +        report_java_out_of_memory(message);
>>>>>> +      }
>>>>>>          fatal("Saw %s, aborting", value_string);
>>>>>>        }
>>>>>>      }
>>>>>>
>>>>>>
>>>>>> thanks,
>>>>>> --lx
>>>>>>

From shade at openjdk.java.net  Thu Sep  9 10:11:00 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 10:11:00 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero
In-Reply-To: <v9rXuVG8vUHY6wf4G9CXZazEyiUoMwL-Pr9co8T9BWY=.52ad0905-4fdc-46c8-a565-fdf0ba59ca86@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <tWPWbXYYEC1pDWHWEmhTG3moBnSqTNZGle-Ieb698Sk=.ddfa2fa2-703b-4952-8df1-84bf99f04870@github.com>
 <v9rXuVG8vUHY6wf4G9CXZazEyiUoMwL-Pr9co8T9BWY=.52ad0905-4fdc-46c8-a565-fdf0ba59ca86@github.com>
Message-ID: <6Gb-JeNvNcDdHEXdEmdJ5LTtCvHCAb9Hd825v6UkOGY=.da6a6aae-7e59-46fd-a7d7-a9a70eda989f@github.com>

On Thu, 9 Sep 2021 06:56:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> I'd be surprised if it still works in JDK 18 though. The latest they build is 15. ia64 breaks so easily, and no one took care of it in the recent past.

Yes, but I also want the fix to be backportable to JDK 11. Which means I should probably keep whatever IA64 support there is. I'll figure this out.

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From sgehwolf at openjdk.java.net  Thu Sep  9 11:02:02 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 9 Sep 2021 11:02:02 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current
In-Reply-To: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
Message-ID: <K66BaxAL_FZiaXGxd_z8pZTiuUVyKScAT6Yb5wTZQ6k=.1252f29f-89b1-4e37-a4d2-f8be43e0cdae@github.com>

On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
> 
> Best regards, Matthias

This could get simplified a bit as we don't need to consider `max` values for `pids.current`.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 287:

> 285:  *    OSCONTAINER_ERROR for not supported
> 286:  */
> 287: jlong CgroupV1Subsystem::pids_current() {

`pids.current` never contains a string `max` (for unlimited). Therefore, we shouldn't need to do the `pids_current_val` -> `limit_from_str()` trick. We should be able to use `GET_CONTAINER_INFO(int, [...]` akin to `cpu_quota`. `int` or `long` would both be suitable. Up to you to decide which data type to use. I don't think it'll ever be beyond the maximum integrer value.

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 421:

> 419:     public long getPidsCurrent() {
> 420:         String pidsCurrentStr = CgroupSubsystemController.getStringValue(pids, "pids.current");
> 421:         return CgroupSubsystem.limitFromString(pidsCurrentStr);

`return getLongValue(pids, "pids.current");` should be sufficient here.

test/hotspot/jtreg/containers/docker/TestPids.java line 97:

> 95:                 System.out.println("DEBUG: parts.length = " + parts.length);
> 96:                 if (expectedValue.equals("no_value_expected")) {
> 97:                     System.out.println("No value expected for " + lineMarker);

Perhaps this debug print could say `System.out.println("Found '" + lineMarker + "' with value: '" + <value> +"');` and actually parse the number as we'd expect an integer there?

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

Changes requested by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5437

From stuefe at openjdk.java.net  Thu Sep  9 12:16:05 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 9 Sep 2021 12:16:05 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero
In-Reply-To: <6Gb-JeNvNcDdHEXdEmdJ5LTtCvHCAb9Hd825v6UkOGY=.da6a6aae-7e59-46fd-a7d7-a9a70eda989f@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <tWPWbXYYEC1pDWHWEmhTG3moBnSqTNZGle-Ieb698Sk=.ddfa2fa2-703b-4952-8df1-84bf99f04870@github.com>
 <v9rXuVG8vUHY6wf4G9CXZazEyiUoMwL-Pr9co8T9BWY=.52ad0905-4fdc-46c8-a565-fdf0ba59ca86@github.com>
 <6Gb-JeNvNcDdHEXdEmdJ5LTtCvHCAb9Hd825v6UkOGY=.da6a6aae-7e59-46fd-a7d7-a9a70eda989f@github.com>
Message-ID: <69A16QRQy4MBuEO_qFz24dccii9yFIpz5F-qiKFRCI0=.03a916ac-548c-4096-b959-1386c946c70a@github.com>

On Thu, 9 Sep 2021 10:07:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > I'd be surprised if it still works in JDK 18 though. The latest they build is 15. ia64 breaks so easily, and no one took care of it in the recent past.
> 
> Yes, but I also want the fix to be backportable to JDK 11. Which means I should probably keep whatever IA64 support there is. I'll figure this out.

Oh right. Makes sense.

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Thu Sep  9 12:54:22 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 12:54:22 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
Message-ID: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>

Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 

Additional testing:
 - [x] Linux x86_64 Zero build
 - [x] Linux x86_64 Zero bootcycle-images
 - [ ] Linux x86_64 Zero `tier1`

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/5440/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5440&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273494
  Stats: 14 lines in 6 files changed: 0 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5440.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5440/head:pull/5440

PR: https://git.openjdk.java.net/jdk/pull/5440

From dholmes at openjdk.java.net  Thu Sep  9 13:12:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 13:12:01 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
Message-ID: <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero build
>  - [x] Linux x86_64 Zero bootcycle-images
>  - [ ] Linux x86_64 Zero `tier1`

This does what it intends but I can't approve it via a review as the issue is more about whether this should be done. The people who own/maintain/support Zero are the ones who should be directing this.

David

make/autoconf/hotspot.m4 line 86:

> 84:   fi
> 85: 
> 86:   # All "special" variants share the same output directory ("server")

I presume "zero" was a special variant? Are there any other variants remaining?

make/modules/java.base/Copy.gmk line 98:

> 96: DEFAULT_CFG_VARIANT ?= server
> 97: 
> 98: # Any variant other than server, client, minimal, or zero is represented as server in

Are there any other variants now?

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From shade at openjdk.java.net  Thu Sep  9 13:18:04 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 13:18:04 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>
Message-ID: <O8NVvt3L3Z1D_mGYhhhTZOXx9S9u8IccBHRejjG424Y=.64e49ced-618f-4bdd-91bf-931768b7ad50@github.com>

On Thu, 9 Sep 2021 13:02:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero build
>>  - [x] Linux x86_64 Zero bootcycle-images
>>  - [ ] Linux x86_64 Zero `tier1`
>
> make/autoconf/hotspot.m4 line 86:
> 
>> 84:   fi
>> 85: 
>> 86:   # All "special" variants share the same output directory ("server")
> 
> I presume "zero" was a special variant? Are there any other variants remaining?

Yes, there are at least "core" and "custom":


# All valid JVM variants
VALID_JVM_VARIANTS="server client minimal core zero custom"

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From shade at openjdk.java.net  Thu Sep  9 13:45:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 13:45:10 GMT
Subject: RFR: 8273433: Enable parallelism in vmTestbase_nsk_sysdict tests
In-Reply-To: <k59-vnAS4Ni1XH1ciqOgM9AlIElppuIGvOsKDF7zDaw=.7baa8bf9-2f09-438b-a966-b3a30ab48380@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
 <k59-vnAS4Ni1XH1ciqOgM9AlIElppuIGvOsKDF7zDaw=.7baa8bf9-2f09-438b-a966-b3a30ab48380@github.com>
Message-ID: <SCaq0Op6CjK3BBS3RfsBSwawHUpPYW50JXWok7g2GKo=.1e4c43d5-f8e4-4c5b-bf31-1b2eb1f92581@github.com>

On Wed, 8 Sep 2021 19:43:09 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
>> 
>> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
>> 
>> Motivational performance improvements below.
>> 
>> Before:
>> 
>> 
>> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
>> ...
>> 00:45:14 ==============================
>> 00:45:14 Test summary
>> 00:45:14 ==============================
>> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
>> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
>> 00:45:14 ==============================
>> 00:45:14 TEST SUCCESS
>> 00:45:14 
>> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
>> 
>> real	45m14.839s
>> user	149m49.850s
>> sys	13m25.849s
>> 
>> 
>> After:
>> 
>> 
>> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
>> ...
>> 00:03:25 ==============================
>> 00:03:25 Test summary
>> 00:03:25 ==============================
>> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
>> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
>> 00:03:25 ==============================
>> 00:03:25 TEST SUCCESS
>> 00:03:25 
>> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
>> 
>> real	3m24.702s
>> user	119m7.488s
>> sys	8m11.716s
>
> Thanks Alexey. I will run some tests, look into history of tests and will get back to you with my findings tonight (PST) or tomorrow.

OK, good, thanks for testing, @mseledts! I'll be on lookout if these tests start to misbehave after this relaxation.

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From shade at openjdk.java.net  Thu Sep  9 13:45:11 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 13:45:11 GMT
Subject: Integrated: 8273433: Enable parallelism in vmTestbase_nsk_sysdict
 tests
In-Reply-To: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
References: <TmJPwgUQYMK0-uJci8XaxQwW-Gpcn5UvpdPJCVJiB4Q=.21896e6c-ff92-46c8-ba74-e5ec5f872ffc@github.com>
Message-ID: <A6Ohhxh-HqfYT-4_kuCPEe9XwUZG_4GB8LaoEmlLCXk=.8d2d47e4-cc19-452a-b4f0-92e5edfd18a6@github.com>

On Tue, 7 Sep 2021 13:17:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Current `vmTestbase_nsk_sysdict` suite contains about 20 tests, each running exclusively. There seem to be no reason to run them exclusively, though: they complete in reasonable time, are single-threaded, and consume the usual amount of memory.
> 
> We should consider enabling parallelism for them and get improved test performance. Currently it is blocked by `TEST.properties` with `exclusiveAccess.dirs` directives in them.
> 
> Motivational performance improvements below.
> 
> Before:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:45:14 ==============================
> 00:45:14 Test summary
> 00:45:14 ==============================
> 00:45:14    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:45:14    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:45:14 ==============================
> 00:45:14 TEST SUCCESS
> 00:45:14 
> 00:45:15 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	45m14.839s
> user	149m49.850s
> sys	13m25.849s
> 
> 
> After:
> 
> 
> $ time CONF=linux-x86_64-server-fastdebug make run-test TEST=vmTestbase_nsk_sysdict | ts -s
> ...
> 00:03:25 ==============================
> 00:03:25 Test summary
> 00:03:25 ==============================
> 00:03:25    TEST                                              TOTAL  PASS  FAIL ERROR   
> 00:03:25    jtreg:test/hotspot/jtreg:vmTestbase_nsk_sysdict      20    20     0     0   
> 00:03:25 ==============================
> 00:03:25 TEST SUCCESS
> 00:03:25 
> 00:03:25 Finished building target 'run-test' in configuration 'linux-x86_64-server-fastdebug'
> 
> real	3m24.702s
> user	119m7.488s
> sys	8m11.716s

This pull request has now been integrated.

Changeset: 5ca26cbd
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5ca26cbddbdd47a73cc141a6215dc89c53841d4a
Stats:     20 lines in 20 files changed: 0 ins; 20 del; 0 mod

8273433: Enable parallelism in vmTestbase_nsk_sysdict tests

Reviewed-by: mseledtsov, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5389

From ysuenaga at openjdk.java.net  Thu Sep  9 14:27:21 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 14:27:21 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v4]
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Refactoring FoldMultilinesTest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5407/files
  - new: https://git.openjdk.java.net/jdk/pull/5407/files/668ec10c..6bba4376

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=02-03

  Stats: 18 lines in 1 file changed: 4 ins; 10 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5407/head:pull/5407

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Thu Sep  9 14:27:22 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 14:27:22 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v2]
In-Reply-To: <67YJHnuujM2J3p7_o6Q-eAwBL7DIYdydsXg6c2TDeJ8=.8b0aca35-970e-4303-a2a6-f91dfc99fa67@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <o-NIdXf2iH9HtLfMIRNS8xPq3XA2vmRtzeBOqrkOzjc=.80798661-ea13-43ba-b628-efc305bb9985@github.com>
 <OkLWkTQhdaEMPVmLHlsSQm8wcKqgH8JJythjowbocQ4=.0569b631-d476-4dc7-913a-b9ba78c73ea1@github.com>
 <67YJHnuujM2J3p7_o6Q-eAwBL7DIYdydsXg6c2TDeJ8=.8b0aca35-970e-4303-a2a6-f91dfc99fa67@github.com>
Message-ID: <Hd7BmmppIi9WG3WBDRWg-8wRaRux3_nzNAQG5pL-nRc=.279c0fb8-9994-4e21-a2da-a4966696b4a8@github.com>

On Thu, 9 Sep 2021 09:23:38 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/logging/FoldMultilinesTest.java line 102:
>> 
>>> 100:         test("file=" + EXCEPTION_LOG_FILE);
>>> 101:         test("stdout");
>>> 102:         test("stderr");
>> 
>> I think we should add a case whe the output is not explicitly specified. I.e.,
>> 
>> 
>> -Xlog:exceptions=info:::foldmultilines=true
>
> I added test for this pattern in new commit.

I missed to check the log if output is default ("") and foldmultilines=false. So I refactored testcase.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From ihse at openjdk.java.net  Thu Sep  9 14:34:08 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Sep 2021 14:34:08 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
Message-ID: <cbKlLGiJ0036osQ8Dp6N8vM7519Ja_lz5jkVGwZqIxw=.1a1761f8-fbce-4583-b1a1-d3966a4865b0@github.com>

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero build
>  - [x] Linux x86_64 Zero bootcycle-images
>  - [ ] Linux x86_64 Zero `tier1`

And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this?

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From ihse at openjdk.java.net  Thu Sep  9 14:34:09 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Sep 2021 14:34:09 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <O8NVvt3L3Z1D_mGYhhhTZOXx9S9u8IccBHRejjG424Y=.64e49ced-618f-4bdd-91bf-931768b7ad50@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>
 <O8NVvt3L3Z1D_mGYhhhTZOXx9S9u8IccBHRejjG424Y=.64e49ced-618f-4bdd-91bf-931768b7ad50@github.com>
Message-ID: <rIE9Vts4g5SF43wNdm2EM8nGt5kLjM7QctUazTH8WAE=.045f95a6-0f21-4a43-a467-359406a2d7ef@github.com>

On Thu, 9 Sep 2021 13:14:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> make/autoconf/hotspot.m4 line 86:
>> 
>>> 84:   fi
>>> 85: 
>>> 86:   # All "special" variants share the same output directory ("server")
>> 
>> I presume "zero" was a special variant? Are there any other variants remaining?
>
> Yes, there are at least "core" and "custom":
> 
> 
> # All valid JVM variants
> VALID_JVM_VARIANTS="server client minimal core zero custom"

I think we should stop these as well from impersonating the server JVM. Preferably in the same fix, so we can remove all the special casing for "server" being anything else but server.

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From shade at openjdk.java.net  Thu Sep  9 14:44:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 14:44:08 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <rIE9Vts4g5SF43wNdm2EM8nGt5kLjM7QctUazTH8WAE=.045f95a6-0f21-4a43-a467-359406a2d7ef@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>
 <O8NVvt3L3Z1D_mGYhhhTZOXx9S9u8IccBHRejjG424Y=.64e49ced-618f-4bdd-91bf-931768b7ad50@github.com>
 <rIE9Vts4g5SF43wNdm2EM8nGt5kLjM7QctUazTH8WAE=.045f95a6-0f21-4a43-a467-359406a2d7ef@github.com>
Message-ID: <qOqXlvJhOhK7F9APj7m06Sti1hMjCIFimhRXQP6QOd4=.73be4113-d000-4d35-8448-99365d389342@github.com>

On Thu, 9 Sep 2021 14:28:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Yes, there are at least "core" and "custom":
>> 
>> 
>> # All valid JVM variants
>> VALID_JVM_VARIANTS="server client minimal core zero custom"
>
> I think we should stop these as well from impersonating the server JVM. Preferably in the same fix, so we can remove all the special casing for "server" being anything else but server.

Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially cleanly backportable), and then handle the rest of the variants?

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From cjplummer at openjdk.java.net  Thu Sep  9 15:06:11 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 9 Sep 2021 15:06:11 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
Message-ID: <XM434WFHOz5FV8UrtAthQXwhpxIT-w4hBP1AbGwLX1g=.133faa7e-d8aa-4c66-8a41-404a2f98cfc7@github.com>

On Wed, 8 Sep 2021 05:02:18 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

> I will start reviewing this today.

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From ihse at openjdk.java.net  Thu Sep  9 15:15:00 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Sep 2021 15:15:00 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <qOqXlvJhOhK7F9APj7m06Sti1hMjCIFimhRXQP6QOd4=.73be4113-d000-4d35-8448-99365d389342@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>
 <O8NVvt3L3Z1D_mGYhhhTZOXx9S9u8IccBHRejjG424Y=.64e49ced-618f-4bdd-91bf-931768b7ad50@github.com>
 <rIE9Vts4g5SF43wNdm2EM8nGt5kLjM7QctUazTH8WAE=.045f95a6-0f21-4a43-a467-359406a2d7ef@github.com>
 <qOqXlvJhOhK7F9APj7m06Sti1hMjCIFimhRXQP6QOd4=.73be4113-d000-4d35-8448-99365d389342@github.com>
Message-ID: <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com>

On Thu, 9 Sep 2021 14:41:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I think we should stop these as well from impersonating the server JVM. Preferably in the same fix, so we can remove all the special casing for "server" being anything else but server.
>
> Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially cleanly backportable), and then handle the rest of the variants?

Sure, that works for me.

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From shade at openjdk.java.net  Thu Sep  9 15:27:12 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 9 Sep 2021 15:27:12 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>
 <O8NVvt3L3Z1D_mGYhhhTZOXx9S9u8IccBHRejjG424Y=.64e49ced-618f-4bdd-91bf-931768b7ad50@github.com>
 <rIE9Vts4g5SF43wNdm2EM8nGt5kLjM7QctUazTH8WAE=.045f95a6-0f21-4a43-a467-359406a2d7ef@github.com>
 <qOqXlvJhOhK7F9APj7m06Sti1hMjCIFimhRXQP6QOd4=.73be4113-d000-4d35-8448-99365d389342@github.com>
 <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com>
Message-ID: <Y_zD67mk0z-MgTrrCjafiivlsoABDd3IVpg_PeetTSw=.ba1f0f81-a275-4b75-b21d-aea960184520@github.com>

On Thu, 9 Sep 2021 15:12:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Ok, I agree. Can I do a Zero-specific thing here (so that it is potentially cleanly backportable), and then handle the rest of the variants?
>
> Sure, that works for me.

While we are at it, do `core` and `custom` even carry their weight? I cannot remember if I ever seen anyone using them. Maybe we should "just" drop those variants, and leave only "server, client, minimal, zero"?

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From ihse at openjdk.java.net  Thu Sep  9 15:38:07 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Sep 2021 15:38:07 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <Y_zD67mk0z-MgTrrCjafiivlsoABDd3IVpg_PeetTSw=.ba1f0f81-a275-4b75-b21d-aea960184520@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <h0iAye7-QJqOTXNkT5xpJoDazFm0cMhb5LDnlWRIDoE=.6b6a3eff-74a6-42f7-95a1-617fcf23c6e8@github.com>
 <O8NVvt3L3Z1D_mGYhhhTZOXx9S9u8IccBHRejjG424Y=.64e49ced-618f-4bdd-91bf-931768b7ad50@github.com>
 <rIE9Vts4g5SF43wNdm2EM8nGt5kLjM7QctUazTH8WAE=.045f95a6-0f21-4a43-a467-359406a2d7ef@github.com>
 <qOqXlvJhOhK7F9APj7m06Sti1hMjCIFimhRXQP6QOd4=.73be4113-d000-4d35-8448-99365d389342@github.com>
 <6EpZHKmu05w7CmXzMXmUPMHwKrsBT7anSPbMUwA69TI=.a409d263-8316-4774-85fd-67981e64d579@github.com>
 <Y_zD67mk0z-MgTrrCjafiivlsoABDd3IVpg_PeetTSw=.ba1f0f81-a275-4b75-b21d-aea960184520@github.com>
Message-ID: <fPIvU2YqN6V2_02rZ0V10-gk_kG0ntM8bszXmIUxhMw=.75be267d-77fa-48e9-b777-d33056a9924e@github.com>

On Thu, 9 Sep 2021 15:23:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Sure, that works for me.
>
> While we are at it, do `core` and `custom` even carry their weight? I cannot remember if I ever seen anyone using them. Maybe we should "just" drop those variants, and leave only "server, client, minimal, zero"?

I don't know about "core". Last time it was up for discussion, some old-timer I've forgotten pointed out that it was useful for such-and-such. I'm not sure if the cost for keeping it is high enough to make the effort to figure out if anyone is going to miss it if we remove it.

As for "custom", it is not a real JVM configuration per se. Instead, it's more of a testing ground for the build system. Basically, the JVM "variants" are just named pre-defined sets of enabled JVM features. To test this properly, I introduced the "custom" variant which is just an empty set of JVM features from the start, so that individual features can be fully controlled. I don't really think anyone is using this in the "real world", but I'd like to keep it for testing purposes.

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From iklam at openjdk.java.net  Thu Sep  9 15:56:02 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 9 Sep 2021 15:56:02 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v4]
In-Reply-To: <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
Message-ID: <As-_3AbFUJXvfaeMHC2X5eaIXvt1LAIRnY50dYPOgUw=.1790e426-edf3-4046-a314-72020db2e711@github.com>

On Thu, 9 Sep 2021 14:27:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring FoldMultilinesTest

If you run with the following command-line:


java -Xlog:exceptions:::foldmultilines=true -Xlog:cds:::foldmultilines=false


Does it give a warning, or does it change foldmultilines of stdout to false?

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From minqi at openjdk.java.net  Thu Sep  9 18:24:31 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 9 Sep 2021 18:24:31 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
Message-ID: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>

Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.

Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.

Tests: ter1-4

Thanks
Yumin

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

Commit messages:
 - 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp

Changes: https://git.openjdk.java.net/jdk/pull/5450/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271569
  Stats: 336 lines in 10 files changed: 163 ins; 129 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5450.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5450/head:pull/5450

PR: https://git.openjdk.java.net/jdk/pull/5450

From ihse at openjdk.java.net  Thu Sep  9 19:38:35 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 9 Sep 2021 19:38:35 GMT
Subject: RFR: 8256977: Bump minimum GCC from 5.x to 6 for JDK
Message-ID: <GRT9YAPpauCay5CaUVeJDzqGExdbqy1r4xcVODFfIgU=.6a0cb3b1-a383-4561-8183-e2d16b4d9a1b@github.com>

The minimum acceptable version is raised from 5 to 6. There were no objections on the mailing list for doing so in the mainline, see https://mail.openjdk.java.net/pipermail/build-dev/2021-August/031899.html.

This patch also reverts the workaround that was introduced in JDK-8252797 to support gcc 5.x.

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

Commit messages:
 - 8256977: Bump minimum GCC from 5.x to 6 for JDK

Changes: https://git.openjdk.java.net/jdk/pull/5452/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5452&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256977
  Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5452.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5452/head:pull/5452

PR: https://git.openjdk.java.net/jdk/pull/5452

From erikj at openjdk.java.net  Thu Sep  9 20:38:03 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 9 Sep 2021 20:38:03 GMT
Subject: RFR: 8256977: Bump minimum GCC from 5.x to 6 for JDK
In-Reply-To: <GRT9YAPpauCay5CaUVeJDzqGExdbqy1r4xcVODFfIgU=.6a0cb3b1-a383-4561-8183-e2d16b4d9a1b@github.com>
References: <GRT9YAPpauCay5CaUVeJDzqGExdbqy1r4xcVODFfIgU=.6a0cb3b1-a383-4561-8183-e2d16b4d9a1b@github.com>
Message-ID: <YqR5EbkIrU98c5pvHvblnYr1B8KuOVy3ZuUBXD78fP4=.b3600027-46c1-4cf9-a135-1050cf18c268@github.com>

On Thu, 9 Sep 2021 19:28:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The minimum acceptable version is raised from 5 to 6. There were no objections on the mailing list for doing so in the mainline, see https://mail.openjdk.java.net/pipermail/build-dev/2021-August/031899.html.
> 
> This patch also reverts the workaround that was introduced in JDK-8252797 to support gcc 5.x.

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5452

From iklam at openjdk.java.net  Thu Sep  9 21:20:26 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 9 Sep 2021 21:20:26 GMT
Subject: RFR: 8273522: Rename test property vm.cds.archived.java.heap to
 vm.cds.write.archived.java.heap
Message-ID: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>

The vm.cds.archived.java.heap test property (see test/jtreg-ext/requires/VMProps.java) is ambiguous -- after JDK-8270489, there are now two distinct capabilities:

- HeapShared::can_write() -- G1 only
- HeapShared::can_read() -- G1, Epsilon

A few CDS tests are marked with


@requires vm.cds.archived.java.heap


These tests actually require the VM to be able to write Java objects into the CDS archive. Therefore, for clarify, they should be changed to use


@requires vm.cds.write.archived.java.heap


*****
This fix is required for JDK-8273508 - "Support archived heap objects in SerialGC".

Without this fix, tests marked with `@requires vm.cds.archived.java.heap` would be executed even if SerialGC is selected, but this will dump CDS archives without archived heap objects, causing the tests to fail.

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

Commit messages:
 - 8273522: Rename test property vm.cds.archived.java.heap to vm.cds.write.archived.java.heap

Changes: https://git.openjdk.java.net/jdk/pull/5455/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5455&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273522
  Stats: 53 lines in 40 files changed: 0 ins; 3 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5455.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5455/head:pull/5455

PR: https://git.openjdk.java.net/jdk/pull/5455

From iklam at openjdk.java.net  Thu Sep  9 21:55:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 9 Sep 2021 21:55:07 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <fvdvtU9OLgiMRMeYE5WBoT6_HllFSFSKudGH6OWTmeE=.1c6edfb4-fc34-41fb-badc-a68ec9302bc7@github.com>

On Thu, 9 Sep 2021 18:13:10 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Looks good. Just some small nits.

src/hotspot/share/cds/cdsConstants.hpp line 29:

> 27: int    get_cds_constant(const char* name);
> 28: size_t get_cds_offset(const char* name);
> 29: #endif // SHARE_CDS_CDSCONSTANTS_HPP

Instead of stand-alone functions, I think it's better to group them into a class:


class CDSConstants : AllStatic {
  static int    get_constant(const char* name);
  static size_t get_offset(const char* name);
};

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Thu Sep  9 22:59:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 22:59:02 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <cbKlLGiJ0036osQ8Dp6N8vM7519Ja_lz5jkVGwZqIxw=.1a1761f8-fbce-4583-b1a1-d3966a4865b0@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <cbKlLGiJ0036osQ8Dp6N8vM7519Ja_lz5jkVGwZqIxw=.1a1761f8-fbce-4583-b1a1-d3966a4865b0@github.com>
Message-ID: <2Yn8M-t8DrfBLGDJIgqCAHV1rIp0CydCE3wFSC-Ktu0=.b83f7003-a851-4dbf-9c9b-5d23fedc4757@github.com>

On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero build
>>  - [x] Linux x86_64 Zero bootcycle-images
>>  - [ ] Linux x86_64 Zero `tier1`
>
> And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this?

@magicus every "port" in OpenJDK is supposed to have a clear owner and support system. Zero has been somewhat lacking in that area but there were enough people to keep it surviving. Now I'm not so sure. Does Zero have an active user community? Developer community? If so they are the ones who need to assess this change.

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From ysuenaga at openjdk.java.net  Thu Sep  9 23:15:01 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Thu, 9 Sep 2021 23:15:01 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v4]
In-Reply-To: <As-_3AbFUJXvfaeMHC2X5eaIXvt1LAIRnY50dYPOgUw=.1790e426-edf3-4046-a314-72020db2e711@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
 <As-_3AbFUJXvfaeMHC2X5eaIXvt1LAIRnY50dYPOgUw=.1790e426-edf3-4046-a314-72020db2e711@github.com>
Message-ID: <JqfeCRIdFUuPcM-HRddnRabfmeZNjWljatLMjiGylYI=.307825eb-aeb0-480d-ba60-fe20c8b6a778@github.com>

On Thu, 9 Sep 2021 15:53:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> If you run with the following command-line:
> 
> ```
> java -Xlog:exceptions:::foldmultilines=true -Xlog:cds:::foldmultilines=false
> ```
> 
> Does it give a warning, or does it change foldmultilines of stdout to false?

I think it should give a warning and should keep first option (`foldmultilines=true`). It is same behavior with JDK 16.
In following case, `filecount` for test.log set to `1` - it is first option.


$ java  -Xlog:logging=info -Xlog:os=warning:file=test.log::filecount=1 -Xlog:exceptions=info:file=test.log::filecount=2 --version
[0.000s][warning][logging] Output options for existing outputs are ignored.

  (snip)

[0.010s][info   ][logging] Log output configuration:
[0.010s][info   ][logging]  #0: stdout all=warning,logging=info uptime,level,tags
[0.010s][info   ][logging]  #1: stderr all=off uptime,level,tags
[0.010s][info   ][logging]  #2: file=test.log all=off,os=warning,exceptions=info uptime,level,tags filecount=1,filesize=20480K


We need to improve this message of course as you said, but I want to work for it in another issue because the behavior in this PR is same with log file output.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From dholmes at openjdk.java.net  Thu Sep  9 23:34:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 23:34:08 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v4]
In-Reply-To: <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
Message-ID: <Gitxd-bN21b0SG9PXBTqlCCNy8Q_Br6GV_0nwxBdPRw=.1c00e797-5cb8-4eb6-a278-b5cfcf7aef11@github.com>

On Thu, 9 Sep 2021 14:27:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring FoldMultilinesTest

I'm fine with the updates.

I agree that adding in the warning can be handled next. If output options are basically "set once" then we should have an api that makes that clear.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5407

From iklam at openjdk.java.net  Thu Sep  9 23:34:08 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 9 Sep 2021 23:34:08 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v4]
In-Reply-To: <JqfeCRIdFUuPcM-HRddnRabfmeZNjWljatLMjiGylYI=.307825eb-aeb0-480d-ba60-fe20c8b6a778@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
 <As-_3AbFUJXvfaeMHC2X5eaIXvt1LAIRnY50dYPOgUw=.1790e426-edf3-4046-a314-72020db2e711@github.com>
 <JqfeCRIdFUuPcM-HRddnRabfmeZNjWljatLMjiGylYI=.307825eb-aeb0-480d-ba60-fe20c8b6a778@github.com>
Message-ID: <uHnMnfb4paJZ1tmXSGpdnmZXoxLBZyHmtcsB181r9BM=.ea488edc-08d9-4736-9675-8e70a60398ce@github.com>

On Thu, 9 Sep 2021 23:11:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > If you run with the following command-line:
> > ```
> > java -Xlog:exceptions:::foldmultilines=true -Xlog:cds:::foldmultilines=false
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Does it give a warning, or does it change foldmultilines of stdout to false?
> 
> I think it should give a warning and should keep first option (`foldmultilines=true`). It is same behavior with JDK 16.
> In following case, `filecount` for test.log set to `1` - it is first option.
> 
> ```
> $ java  -Xlog:logging=info -Xlog:os=warning:file=test.log::filecount=1 -Xlog:exceptions=info:file=test.log::filecount=2 --version
> [0.000s][warning][logging] Output options for existing outputs are ignored.
> 
>   (snip)
> 
> [0.010s][info   ][logging] Log output configuration:
> [0.010s][info   ][logging]  #0: stdout all=warning,logging=info uptime,level,tags
> [0.010s][info   ][logging]  #1: stderr all=off uptime,level,tags
> [0.010s][info   ][logging]  #2: file=test.log all=off,os=warning,exceptions=info uptime,level,tags filecount=1,filesize=20480K
> ```
> 
> We need to improve this message of course as you said, but I want to work for it in another issue because the behavior in this PR is same with log file output.

Sorry, I wasn't clear. I am not asking about file output. I am asking about stdout output.


java -Xlog:exceptions:stdout::foldmultilines=true -Xlog:cds:stdout::foldmultilines=false


I think this should give the same type of warning as you would get when the output is a file. I.e., the second `foldmultilines=false` should be ignored. However, I think your current implementation will accept the second `foldmultilines=false` and cause stdout to be printed without folded multilines.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From minqi at openjdk.java.net  Thu Sep  9 23:51:06 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 9 Sep 2021 23:51:06 GMT
Subject: RFR: 8273522: Rename test property vm.cds.archived.java.heap to
 vm.cds.write.archived.java.heap
In-Reply-To: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
References: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
Message-ID: <GvRWwBL-NUHRLQq_c9fhMRe5ZB1NGhFadL_U6HkQVoQ=.b482f5dd-8d5e-49c8-a0df-d22b01574544@github.com>

On Thu, 9 Sep 2021 20:28:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The vm.cds.archived.java.heap test property (see test/jtreg-ext/requires/VMProps.java) is ambiguous -- after JDK-8270489, there are now two distinct capabilities:
> 
> - HeapShared::can_write() -- G1 only
> - HeapShared::can_read() -- G1, Epsilon
> 
> A few CDS tests are marked with
> 
> 
> @requires vm.cds.archived.java.heap
> 
> 
> These tests actually require the VM to be able to write Java objects into the CDS archive. Therefore, for clarify, they should be changed to use
> 
> 
> @requires vm.cds.write.archived.java.heap
> 
> 
> *****
> This fix is required for JDK-8273508 - "Support archived heap objects in SerialGC".
> 
> Without this fix, tests marked with `@requires vm.cds.archived.java.heap` would be executed even if SerialGC is selected, but this will dump CDS archives without archived heap objects, causing the tests to fail.

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5455

From dholmes at openjdk.java.net  Thu Sep  9 23:58:05 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 9 Sep 2021 23:58:05 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v4]
In-Reply-To: <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <9ctw9Nw8tsUQcZfUENP407M8rsZQ3pn9J2iYJCDbmt0=.78ee6d04-ccd0-4b22-a534-a7b68e15372c@github.com>
Message-ID: <eZBrEADn53gepSoet6djxDFWiwpyBVqUSOF1VEkyicE=.e464ae5c-27b8-431a-8b29-973cb5bfa4e9@github.com>

On Thu, 9 Sep 2021 14:27:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactoring FoldMultilinesTest

Sorry I've re-evaluated things. I thought that @YaSuenag was saying that setting foldmultilines multiple times for the same file was also allowed at present and needing to be fixed. But it isn't. So I agree with Ioi that this needs to be fixed for stdoput/err as part of this PR.

I also noticed that the state of foldmultilines is not reported with UL's own logging e.g.

[0.110s][info   ][logging] Log output configuration:
[0.110s][info   ][logging]  #0: stdout all=warning,logging=info uptime,level,tags
[0.110s][info   ][logging]  #1: stderr all=off uptime,level,tags
[0.111s][info   ][logging]  #2: file=test.log all=off,os=warning,exceptions=info uptime,level,tags filecount=5,filesize=20480K,async=false

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5407

From github.com+38446717+matias9927 at openjdk.java.net  Fri Sep 10 00:00:02 2021
From: github.com+38446717+matias9927 at openjdk.java.net (Matias Saavedra Silva)
Date: Fri, 10 Sep 2021 00:00:02 GMT
Subject: RFR: 8272608: java_lang_System::allow_security_manager() doesn't
 set its initialization flag
In-Reply-To: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
References: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
Message-ID: <g426KF2REpXTXgwOAPfEcux63bjaLtXU0pIPsYmqZeI=.48bb2867-3c74-4c44-9948-9469da687dbe@github.com>

On Thu, 26 Aug 2021 16:00:01 GMT, Matias Saavedra Silva <github.com+38446717+matias9927 at openjdk.org> wrote:

> Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
> Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

> ?? @matias9927 the full name on your profile does not match the author name in this pull requests' [HEAD](https://git.openjdk.java.net/jdk/pull/5268/commits/d9127a6545e076b757f425d39826a217d487d6dd) commit. If this pull request gets integrated then the author name from this pull requests' [HEAD](https://git.openjdk.java.net/jdk/pull/5268/commits/d9127a6545e076b757f425d39826a217d487d6dd) commit will be used for the resulting commit. If you wish to push a new commit with a different author name, then please run the following commands in a local repository of your personal fork:
> 
> ```
> $ git checkout JDK-8272608
> $ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name'
> $ git push
> ```

Should I still do this?

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

PR: https://git.openjdk.java.net/jdk/pull/5268

From ccheung at openjdk.java.net  Fri Sep 10 00:41:17 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 10 Sep 2021 00:41:17 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump
Message-ID: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>

Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.

Passed tiers 1 - 4 testing.

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

Commit messages:
 - 8261941: Use ClassLoader for unregistered classes during -Xshare:dump

Changes: https://git.openjdk.java.net/jdk/pull/5458/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261941
  Stats: 115 lines in 7 files changed: 94 ins; 10 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5458.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5458/head:pull/5458

PR: https://git.openjdk.java.net/jdk/pull/5458

From coleenp at openjdk.java.net  Fri Sep 10 01:09:05 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 01:09:05 GMT
Subject: RFR: 8272608: java_lang_System::allow_security_manager() doesn't
 set its initialization flag
In-Reply-To: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
References: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
Message-ID: <oBTsanCRL66yyziOFgTf7_9XZ4H16w2MVXgwAUdgXp8=.a68bae12-eefd-4f35-b139-09b2115ba2e7@github.com>

On Thu, 26 Aug 2021 16:00:01 GMT, Matias Saavedra Silva <github.com+38446717+matias9927 at openjdk.org> wrote:

> Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
> Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

We're not really sure what the message means, so I don't think changing it is necessary.  I'm going to go ahead and sponsor it and see what happens.  Thanks Matias!!

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

PR: https://git.openjdk.java.net/jdk/pull/5268

From github.com+38446717+matias9927 at openjdk.java.net  Fri Sep 10 01:09:06 2021
From: github.com+38446717+matias9927 at openjdk.java.net (Matias Saavedra Silva)
Date: Fri, 10 Sep 2021 01:09:06 GMT
Subject: Integrated: 8272608: java_lang_System::allow_security_manager()
 doesn't set its initialization flag
In-Reply-To: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
References: <BgTQNuv3X94F4hnk2PtPyG81Gr3UlymgtGF4cURrVKk=.5b67875a-56f0-4e0a-8ea6-861b0cc11971@github.com>
Message-ID: <Qs7scEJJtCLhXh5TZgVqgBieaOsW6UFmCyUjsOi-uUI=.eacf712c-94cd-48d9-babe-0c5119e0ce1c@github.com>

On Thu, 26 Aug 2021 16:00:01 GMT, Matias Saavedra Silva <github.com+38446717+matias9927 at openjdk.org> wrote:

> Originally the initialized flag was always false causing the System fields to be read each time the method is called. The flag is now set the first time it runs.
> Tested with tier1, specifically with runtime/logging/ProtectionDomainVerificationTest.java.

This pull request has now been integrated.

Changeset: 08f0be83
Author:    matias9927 <matias at udel.edu>
Committer: Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/08f0be8388914901ac40525ed995136ce020f432
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8272608: java_lang_System::allow_security_manager() doesn't set its initialization flag

Reviewed-by: coleenp, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5268

From dholmes at openjdk.java.net  Fri Sep 10 01:30:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Sep 2021 01:30:07 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>

On Thu, 9 Sep 2021 18:13:10 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Hi Yumin,

There's obviously a lot more going on here than just a simple rename so I think the JBS issue should be changed accordingly.

A few minor comments below.

Thanks,
David

src/hotspot/share/cds/cdsConstants.cpp line 61:

> 59: 
> 60: size_t get_cds_offset(const char* name) {
> 61:   for (int i = 0; i < (int)(sizeof(cds_offsets)/sizeof(cds_offsets[0])); i++) {

Can't we just define a size for the array and use that? It isn't really a dynamic/unknown quantity.

src/hotspot/share/cds/dynamicArchive.hpp line 45:

> 43: 
> 44: public:
> 45:   int _base_region_crc[MetaspaceShared::n_regions];

This looks like it should be private with either a public accessor or else a friend declaration for the client code.

src/hotspot/share/cds/filemap.hpp line 211:

> 209:   // will function correctly with this JVM and the bootclasspath it's
> 210:   // invoked with.
> 211: public:

Again this looks like it should be private with either a public accessor or else a friend declaration for the client code.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From ysuenaga at openjdk.java.net  Fri Sep 10 02:25:40 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 10 Sep 2021 02:25:40 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v5]
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <U-l9_quEfY4f4vA9FR7R7fX_vJA45uoQfAl3ivyiWhs=.1f30ad85-2a3b-43a4-b26f-d11329b94f65@github.com>

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  output options for stdout/err should be applied just once

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5407/files
  - new: https://git.openjdk.java.net/jdk/pull/5407/files/6bba4376..68d113f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=03-04

  Stats: 28 lines in 4 files changed: 18 ins; 2 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5407/head:pull/5407

PR: https://git.openjdk.java.net/jdk/pull/5407

From lzang at openjdk.java.net  Fri Sep 10 03:06:17 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 10 Sep 2021 03:06:17 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
Message-ID: <gUwviCtEpkVYiCOvrCrudQKMfB-dOni5rYGjjqmpwcs=.094fc820-dcc1-4e4b-abb9-cae51082a25d@github.com>

On Mon, 6 Sep 2021 08:03:22 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build error

Seems the #5410 has made some change that will affect this one. I am wondering should I start to rebase this PR based on that ? 

Thanks.
Lin

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From dholmes at openjdk.java.net  Fri Sep 10 05:09:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Sep 2021 05:09:02 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v5]
In-Reply-To: <U-l9_quEfY4f4vA9FR7R7fX_vJA45uoQfAl3ivyiWhs=.1f30ad85-2a3b-43a4-b26f-d11329b94f65@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <U-l9_quEfY4f4vA9FR7R7fX_vJA45uoQfAl3ivyiWhs=.1f30ad85-2a3b-43a4-b26f-d11329b94f65@github.com>
Message-ID: <y3Q329BWSPS3D2Hq1UdRUoamC0DLbLvb0CjzrRNzWxQ=.c51dcaf6-4276-4eab-97c7-d354d434a2c7@github.com>

On Fri, 10 Sep 2021 02:25:40 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   output options for stdout/err should be applied just once

A couple of comments/queries below.

Thanks,
David

src/hotspot/share/logging/logConfiguration.cpp line 419:

> 417:   if (output == NULL || strlen(output) == 0 ||
> 418:       strcmp("stdout", output) == 0 || strcmp("#0", output) == 0) {
> 419:     if (!stdout_configured) {

So you are piggy-backing on parse_log_arguments() to produce the warning ... can you add a comment at the end:
// else - fall-through to normal option processing which will be rejected with a warning

src/hotspot/share/logging/logFileOutput.cpp line 461:

> 459: void LogFileOutput::describe(outputStream *out) {
> 460:   LogFileStreamOutput::describe(out);
> 461:   out->print(",filecount=%u,filesize=" SIZE_FORMAT "%s,async=%s", _file_count,

Don't we just need to add `foldMultilines` to this print statement? Or is it separate so that it applies to stdout/err as well?

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From minqi at openjdk.java.net  Fri Sep 10 06:08:06 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 10 Sep 2021 06:08:06 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>
Message-ID: <jJUF1uHTGq8sDTFKfeI6_tZPHtcdBCokzVkl5qIkBmE=.8b79573d-1bba-484a-8c6f-fc97fda06b84@github.com>

On Fri, 10 Sep 2021 01:20:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> src/hotspot/share/cds/cdsConstants.cpp line 61:
> 
>> 59: 
>> 60: size_t get_cds_offset(const char* name) {
>> 61:   for (int i = 0; i < (int)(sizeof(cds_offsets)/sizeof(cds_offsets[0])); i++) {
> 
> Can't we just define a size for the array and use that? It isn't really a dynamic/unknown quantity.

The array size is known at compile time --- it is not dynamic but we do not need to manually count the size of the array this way. If define a size for the array, we need to count the number of items in the array to define the array size. We may add more items to the array --- just add items and don't need change anything else. Since total array memory size and array component size are known at compile time, so compiler will not generate code to calculate the size. How about this? 
const int size =   (int)(sizeof(cds_offsets)/sizeof(cds_offsets[0]));
for (int i = 0; i < size; i++) {
  ...
}

> src/hotspot/share/cds/dynamicArchive.hpp line 45:
> 
>> 43: 
>> 44: public:
>> 45:   int _base_region_crc[MetaspaceShared::n_regions];
> 
> This looks like it should be private with either a public accessor or else a friend declaration for the client code.

Let me try but I remember it does not work with constexpr initialization. This is why I move the data field to public not using the public accessor.

> src/hotspot/share/cds/filemap.hpp line 211:
> 
>> 209:   // will function correctly with this JVM and the bootclasspath it's
>> 210:   // invoked with.
>> 211: public:
> 
> Again this looks like it should be private with either a public accessor or else a friend declaration for the client code.

same reason as above.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From shade at openjdk.java.net  Fri Sep 10 07:23:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Sep 2021 07:23:06 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <cbKlLGiJ0036osQ8Dp6N8vM7519Ja_lz5jkVGwZqIxw=.1a1761f8-fbce-4583-b1a1-d3966a4865b0@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <cbKlLGiJ0036osQ8Dp6N8vM7519Ja_lz5jkVGwZqIxw=.1a1761f8-fbce-4583-b1a1-d3966a4865b0@github.com>
Message-ID: <8vaICuN5ZWtQ8WJyIrW_-My_g72eC_TYdL6KtGE8NOs=.deb9e722-2f77-4cec-a2b3-4f9cc9db479a@github.com>

On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero build
>>  - [x] Linux x86_64 Zero bootcycle-images
>>  - [ ] Linux x86_64 Zero `tier1`
>
> And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this?

> @magicus every "port" in OpenJDK is supposed to have a clear owner and support system. Zero has been somewhat lacking in that area but there were enough people to keep it surviving. Now I'm not so sure. Does Zero have an active user community? Developer community? If so they are the ones who need to assess this change.

FWIW, Zero had fallen into Red Hat hands for support. The official lead (if you look at Census) is Gary Benson, who is not active in this project anymore. Since then, it was mostly supported by RH folks (like me) with contributions from Debian, Tencent, Huawei, Alibaba -- mostly because all of us have arch ports that do not have full-blown Server VMs yet.

I have put things in motion to claim the leadership more formally. I do have to note, though, that over the last few years of me whipping Zero into shape, this is the first time anyone asked the formal governance question, which must tell us something about how much we care about ownership formalities here ;)

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From ysuenaga at openjdk.java.net  Fri Sep 10 08:41:04 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 10 Sep 2021 08:41:04 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v5]
In-Reply-To: <y3Q329BWSPS3D2Hq1UdRUoamC0DLbLvb0CjzrRNzWxQ=.c51dcaf6-4276-4eab-97c7-d354d434a2c7@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <U-l9_quEfY4f4vA9FR7R7fX_vJA45uoQfAl3ivyiWhs=.1f30ad85-2a3b-43a4-b26f-d11329b94f65@github.com>
 <y3Q329BWSPS3D2Hq1UdRUoamC0DLbLvb0CjzrRNzWxQ=.c51dcaf6-4276-4eab-97c7-d354d434a2c7@github.com>
Message-ID: <hG17MYMz9lf6jH-9Ogcab42h2UQkT1-E-EoFNG4YvoY=.bc2f815f-ce6f-45e2-8278-5defc2f76690@github.com>

On Fri, 10 Sep 2021 05:01:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   output options for stdout/err should be applied just once
>
> src/hotspot/share/logging/logFileOutput.cpp line 461:
> 
>> 459: void LogFileOutput::describe(outputStream *out) {
>> 460:   LogFileStreamOutput::describe(out);
>> 461:   out->print(",filecount=%u,filesize=" SIZE_FORMAT "%s,async=%s", _file_count,
> 
> Don't we just need to add `foldMultilines` to this print statement? Or is it separate so that it applies to stdout/err as well?

`foldmultilines` is provided by `LogFileStreamOutput`, and it might provide more options in future. So I delegate statement printing to `LogFileStreamOutput`, then print options in `LogFileOutput`.
This change also applies to stdout/err log outputs.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From dholmes at openjdk.java.net  Fri Sep 10 10:06:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 10 Sep 2021 10:06:09 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
Message-ID: <dqlH5LKQPuatkk26ny98Bg6MrsXho6F5BP9ZEO3oA9Y=.eeef6113-4b2f-4f9f-8455-621ee12fb67a@github.com>

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero build
>  - [x] Linux x86_64 Zero bootcycle-images
>  - [ ] Linux x86_64 Zero `tier1`

It isn't the "formal governance" I'm concerned about, more about the folk who use/rely on Zero being the ones to evaluate the impact of a change like this. People, like myself, who do not use Zero in any way cannot evaluate whether this change is appropriate - it's that simple. :)

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From mbaesken at openjdk.java.net  Fri Sep 10 11:07:52 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Sep 2021 11:07:52 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v2]
In-Reply-To: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
Message-ID: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
> 
> Best regards, Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Some simplifications and test adjustment suggested by Severin

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5437/files
  - new: https://git.openjdk.java.net/jdk/pull/5437/files/aa93a12b..422aef68

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=00-01

  Stats: 13 lines in 3 files changed: 8 ins; 1 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437

PR: https://git.openjdk.java.net/jdk/pull/5437

From mbaesken at openjdk.java.net  Fri Sep 10 11:07:53 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 10 Sep 2021 11:07:53 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current
In-Reply-To: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
Message-ID: <zqVNAc0JmuReCzEVUV6yoEP0KP06nWomp9ZeUAgPwXU=.e8ce4e0b-3de1-4fc5-8927-fe0787811345@github.com>

On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
> 
> Best regards, Matthias

Hi Severin, I added another commit dealing with your comments.
Thanks, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From ysuenaga at openjdk.java.net  Fri Sep 10 12:17:41 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 10 Sep 2021 12:17:41 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v6]
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:

 - Add comments about parse_options() call
 - Fix GTest failure

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5407/files
  - new: https://git.openjdk.java.net/jdk/pull/5407/files/68d113f5..97c924d3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=04-05

  Stats: 16 lines in 3 files changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5407/head:pull/5407

PR: https://git.openjdk.java.net/jdk/pull/5407

From sgehwolf at openjdk.java.net  Fri Sep 10 12:41:08 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 10 Sep 2021 12:41:08 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v2]
In-Reply-To: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com>
Message-ID: <y1cYNeEg6fNJdYiGwjzx0i9T0QO-mUq_mr7Tu6U7RQI=.ca70e2f5-e4a9-45e9-988c-9c8c2e913c6f@github.com>

On Fri, 10 Sep 2021 11:07:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8266490
>> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
>> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
>> that would be helpful too and can be added to the OSContainer API .
>> pids.current :
>> A read-only single value file which exists on all cgroups.
>> The number of processes currently in the cgroup and its descendants.
>> 
>> Best regards, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some simplifications and test adjustment suggested by Severin

Sorry for not being clear earlier. I meant that we can do those simplifications throughout.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 255:

> 253: }
> 254: 
> 255: char* CgroupV1Subsystem::pids_current_val() {

This function can get removed. It's unused now.

src/hotspot/os/linux/cgroupV1Subsystem_linux.hpp line 110:

> 108: 
> 109:     char * pids_max_val();
> 110:     char * pids_current_val();

This is not needed.

src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 238:

> 236: }
> 237: 
> 238: char* CgroupV2Subsystem::pids_current_val() {

We don't need that function.

src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 270:

> 268:  *    OSCONTAINER_ERROR for not supported
> 269:  */
> 270: jlong CgroupV2Subsystem::pids_current() {

This should use something akin to `memory_usage_in_bytes` in this class. `pids_current_val()` isn't needed.

src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java line 317:

> 315:     public long getPidsCurrent() {
> 316:         String pidsCurrentStr = CgroupSubsystemController.getStringValue(unified, "pids.current");
> 317:         return CgroupSubsystem.limitFromString(pidsCurrentStr);

This should use: `return getLongVal("pids.current");` instead.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 415:

> 413:         ostream.println(formatLimitString(val, INDENT + "Current number of processes: ",
> 414:                                           longRetvalNotSupported, false));
> 415: 

I'm not sure we should add this to `-XshowSettings:system` output at all. What's reported there is enforced limits. Note that current memory usage isn't shown either.

test/hotspot/jtreg/containers/docker/TestPids.java line 101:

> 99:                     System.out.println("Found " + lineMarker + " with value: " + ivalue);
> 100:                     try {
> 101:                         int ai = Integer.parseInt(ivalue);

Could you move the debug print line to after line 101, please. It could say:

`System.out.println("Found " + lineMarker + " with value: " + ai + ". PASS.");`

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

Changes requested by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5437

From ysuenaga at openjdk.java.net  Fri Sep 10 14:43:46 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 10 Sep 2021 14:43:46 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v5]
In-Reply-To: <y3Q329BWSPS3D2Hq1UdRUoamC0DLbLvb0CjzrRNzWxQ=.c51dcaf6-4276-4eab-97c7-d354d434a2c7@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <U-l9_quEfY4f4vA9FR7R7fX_vJA45uoQfAl3ivyiWhs=.1f30ad85-2a3b-43a4-b26f-d11329b94f65@github.com>
 <y3Q329BWSPS3D2Hq1UdRUoamC0DLbLvb0CjzrRNzWxQ=.c51dcaf6-4276-4eab-97c7-d354d434a2c7@github.com>
Message-ID: <e2oth04-lPZik2uzT0yu5LC2OqCTNuN2McpmoGpXGRo=.b8431fd5-5633-4c0a-99da-ebfd3af93a94@github.com>

On Fri, 10 Sep 2021 05:04:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   output options for stdout/err should be applied just once
>
> src/hotspot/share/logging/logConfiguration.cpp line 419:
> 
>> 417:   if (output == NULL || strlen(output) == 0 ||
>> 418:       strcmp("stdout", output) == 0 || strcmp("#0", output) == 0) {
>> 419:     if (!stdout_configured) {
> 
> So you are piggy-backing on parse_log_arguments() to produce the warning ... can you add a comment at the end:
> // else - fall-through to normal option processing which will be rejected with a warning

I added it.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Fri Sep 10 14:47:57 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Fri, 10 Sep 2021 14:47:57 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v6]
In-Reply-To: <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
Message-ID: <Bw1BFHho3KtF5BagpMDmqD_rDH24MOlk9QbGL0AxtPM=.c93d32f9-d449-47ab-8121-64aaf8ec3475@github.com>

On Fri, 10 Sep 2021 12:17:41 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comments about parse_options() call
>  - Fix GTest failure

I pushed some changes. Could you review again?
I saw some error in GTest by adding foldmultilines to output options. I fixed it in new commit and it works fine on GHA.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From andrew at openjdk.java.net  Fri Sep 10 15:51:49 2021
From: andrew at openjdk.java.net (Andrew John Hughes)
Date: Fri, 10 Sep 2021 15:51:49 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <cbKlLGiJ0036osQ8Dp6N8vM7519Ja_lz5jkVGwZqIxw=.1a1761f8-fbce-4583-b1a1-d3966a4865b0@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <cbKlLGiJ0036osQ8Dp6N8vM7519Ja_lz5jkVGwZqIxw=.1a1761f8-fbce-4583-b1a1-d3966a4865b0@github.com>
Message-ID: <GzCraoWk9Lg61eKNKfiPzqIV987nlzsi1sieb8cr7_U=.240a8cde-5eec-497d-852c-21f8237a50cd@github.com>

On Thu, 9 Sep 2021 14:31:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero build
>>  - [x] Linux x86_64 Zero bootcycle-images
>>  - [ ] Linux x86_64 Zero `tier1`
>
> And as for @dholmes-ora comment: I'm not sure who "own" zero at this point in time. Aleksey has made a lot of the zero patches lately; does that not count? Are you thinking about any specific person that needs to weight in on this?

> > @magicus every "port" in OpenJDK is supposed to have a clear owner and support system. Zero has been somewhat lacking in that area but there were enough people to keep it surviving. Now I'm not so sure. Does Zero have an active user community? Developer community? If so they are the ones who need to assess this change.
> 
> FWIW, Zero had fallen into Red Hat hands for support. The official lead (if you look at Census) is Gary Benson, who is not active in this project anymore. Since then, it was mostly supported by RH folks (like me) with contributions from Debian, Tencent, Huawei, Alibaba -- mostly because all of us have arch ports that do not have full-blown Server VMs yet.

For clarity, Gary was a part of the Red Hat Java team at the time, so it has always been a Red Hat project. At the time, the only JIT ports in OpenJDK were x86, x86-64 and SPARC, so the other architectures Red Hat supported (ppc, ppc64, s390, s390x) needed some way to at least build and run to allow OpenJDK packages to be shipped, even if end users desiring greater performance used some other JDK.

As OpenJDK has gained further JIT ports, the use of Zero has declined in response. For example, we can build OpenJDK 17 on every architecture we need without using Zero, so it's not going to receive that kind of "you broke our build" testing any more. It is still used for 8u & 11u, and is definitely worth keeping alive to help bootstrap any new ports.

So, in short, the owner has always been and remains Red Hat, even if the individual personnel have changed. The formal project represents a time when it was maintained outside the mainline OpenJDK, so there has been no need to update that for a long time, as any JDK project committer can make changes to the code in the main JDK project.

> 
> I have put things in motion to claim the leadership more formally. I do have to note, though, that over the last few years of me whipping Zero into shape, this is the first time anyone asked the formal governance question, which must tell us something about how much we care about ownership formalities here ;)

Most of the OpenJDK committers at Red Hat have pushed Zero fixes at some time, myself included, as need has arisen. This has the first time this has been raised to my knowledge.

Regarding this change itself, I think it's fine for trunk, where there's time to shake out any issues for OpenJDK 18, but I wouldn't want to backport it. These kind of changes tend to throw up things only when someone's application breaks, and, at least if that's a new JDK version, that's somewhat expected.

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From shade at openjdk.java.net  Fri Sep 10 16:33:05 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 10 Sep 2021 16:33:05 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type mismatch
Message-ID: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>

This is actually caught by `-Werror=format` that is enabled by default.


$  sh ./configure --with-debug-level=slowdebug --with-boot-jdk=/home/shade/Install/jdk16-16.0.2-ea/ --openjdk-target=sparc64-linux-gnu --with-sysroot=/chroots/sparc64/ --with-jvm-variants=zero
$ make images

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/5470/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5470&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273606
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5470/head:pull/5470

PR: https://git.openjdk.java.net/jdk/pull/5470

From iklam at openjdk.java.net  Fri Sep 10 18:07:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 10 Sep 2021 18:07:55 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v6]
In-Reply-To: <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
Message-ID: <L7WNoOUV44Ll8fBdNjYWoqWH8j9KgjrxMBQ4nQABbhw=.309a94a1-9695-41e9-baa3-e7b905c0c843@github.com>

On Fri, 10 Sep 2021 12:17:41 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comments about parse_options() call
>  - Fix GTest failure

test/hotspot/gtest/logging/logTestFixture.cpp line 104:

> 102:     }
> 103: 
> 104: // TODO: Restore following code if options for existing log output can be changed.

I think this change needs a better explanation and should be done in a separate RFE. I've file https://bugs.openjdk.java.net/browse/JDK-8273610 and will post a PR soon.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From iklam at openjdk.java.net  Fri Sep 10 18:16:50 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 10 Sep 2021 18:16:50 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v6]
In-Reply-To: <L7WNoOUV44Ll8fBdNjYWoqWH8j9KgjrxMBQ4nQABbhw=.309a94a1-9695-41e9-baa3-e7b905c0c843@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
 <L7WNoOUV44Ll8fBdNjYWoqWH8j9KgjrxMBQ4nQABbhw=.309a94a1-9695-41e9-baa3-e7b905c0c843@github.com>
Message-ID: <4-o4duRXC_1e696wkRlPrS9JlJftt_dKlxyxa6MI8Og=.2bbd7e57-6ffd-4740-a9c2-dfdb5520a2d1@github.com>

On Fri, 10 Sep 2021 18:04:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add comments about parse_options() call
>>  - Fix GTest failure
>
> test/hotspot/gtest/logging/logTestFixture.cpp line 104:
> 
>> 102:     }
>> 103: 
>> 104: // TODO: Restore following code if options for existing log output can be changed.
> 
> I think this change needs a better explanation and should be done in a separate RFE. I've file https://bugs.openjdk.java.net/browse/JDK-8273610 and will post a PR soon.

I posted the PR: https://github.com/openjdk/jdk/pull/5472

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From hseigel at openjdk.java.net  Fri Sep 10 18:20:51 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Fri, 10 Sep 2021 18:20:51 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested [v2]
In-Reply-To: <tesJyvrFOgWg4plwzyH6jYkLeHJeKf1dee0FnJbEO7A=.9988e6bc-0100-42f1-8597-82e1378f569f@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
 <tesJyvrFOgWg4plwzyH6jYkLeHJeKf1dee0FnJbEO7A=.9988e6bc-0100-42f1-8597-82e1378f569f@github.com>
Message-ID: <FBWScvwlHJIVL0CuWS_Mg18GL3kwxvyEPmSalCjAfQ0=.ee7b4bcb-e017-4fb8-9162-31c357c4ba2f@github.com>

On Wed, 8 Sep 2021 19:44:35 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this addition of new testing:
>>   - new test for sending jcmd commands across container boundaries
>>   - updated existing sidecar test, enabling jcmd test case
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated comment

The changes look good!  Thanks for doing this.
Harold

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

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5368

From iklam at openjdk.java.net  Fri Sep 10 18:21:02 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 10 Sep 2021 18:21:02 GMT
Subject: RFR: 8273610: LogTestFixture::restore_config() should not restore
 options
Message-ID: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>

This is a prerequisite of https://github.com/openjdk/jdk/pull/5407

LogTestFixture::restore_config() should not restore the options because it's neither necessary nor allowed. Please see the RFE description for details.

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

Commit messages:
 - 8273610: LogTestFixture::restore_config() should not restore options

Changes: https://git.openjdk.java.net/jdk/pull/5472/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5472&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273610
  Stats: 9 lines in 1 file changed: 4 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5472/head:pull/5472

PR: https://git.openjdk.java.net/jdk/pull/5472

From coleenp at openjdk.java.net  Fri Sep 10 18:39:10 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 18:39:10 GMT
Subject: RFR: 8273611: Remove unused ProfilePrint_lock
Message-ID: <uyR-o7X1cpmp9lFHoX_-ENeD0n47NX_30HM_26UV6tY=.66c0dc62-f2ba-46bb-97cc-6eef35dad5f5@github.com>

Remove a lock that's no longer used.  Tested with local build.

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

Commit messages:
 - remove stray comment
 - 8273611: Remove unused ProfilePrint_lock

Changes: https://git.openjdk.java.net/jdk/pull/5474/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5474&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273611
  Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5474.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5474/head:pull/5474

PR: https://git.openjdk.java.net/jdk/pull/5474

From iklam at openjdk.java.net  Fri Sep 10 19:10:49 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 10 Sep 2021 19:10:49 GMT
Subject: RFR: 8273611: Remove unused ProfilePrint_lock
In-Reply-To: <uyR-o7X1cpmp9lFHoX_-ENeD0n47NX_30HM_26UV6tY=.66c0dc62-f2ba-46bb-97cc-6eef35dad5f5@github.com>
References: <uyR-o7X1cpmp9lFHoX_-ENeD0n47NX_30HM_26UV6tY=.66c0dc62-f2ba-46bb-97cc-6eef35dad5f5@github.com>
Message-ID: <hBN7HOynYuwA3PuQa3-GV68EkfdHmAsnEB36g7Jal_4=.e247cf83-41da-45be-accb-edcd9604e535@github.com>

On Fri, 10 Sep 2021 18:30:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove a lock that's no longer used.  Tested with local build.

LGTM and trivial

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5474

From coleenp at openjdk.java.net  Fri Sep 10 19:27:56 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 19:27:56 GMT
Subject: RFR: 8273611: Remove unused ProfilePrint_lock
In-Reply-To: <uyR-o7X1cpmp9lFHoX_-ENeD0n47NX_30HM_26UV6tY=.66c0dc62-f2ba-46bb-97cc-6eef35dad5f5@github.com>
References: <uyR-o7X1cpmp9lFHoX_-ENeD0n47NX_30HM_26UV6tY=.66c0dc62-f2ba-46bb-97cc-6eef35dad5f5@github.com>
Message-ID: <BZziU68HYug0wonuseObxYUwLlCiFKs3cbLMBHOXFiQ=.1d1a1c24-ec45-42c0-8985-c4248cfd6dca@github.com>

On Fri, 10 Sep 2021 18:30:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove a lock that's no longer used.  Tested with local build.

Thanks Ioi!

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

PR: https://git.openjdk.java.net/jdk/pull/5474

From coleenp at openjdk.java.net  Fri Sep 10 19:27:57 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 10 Sep 2021 19:27:57 GMT
Subject: Integrated: 8273611: Remove unused ProfilePrint_lock
In-Reply-To: <uyR-o7X1cpmp9lFHoX_-ENeD0n47NX_30HM_26UV6tY=.66c0dc62-f2ba-46bb-97cc-6eef35dad5f5@github.com>
References: <uyR-o7X1cpmp9lFHoX_-ENeD0n47NX_30HM_26UV6tY=.66c0dc62-f2ba-46bb-97cc-6eef35dad5f5@github.com>
Message-ID: <xEy28qKCRHKdFpJXoU7xP9eUGaqlxsYe4h61r6v5oWg=.dab56343-3b36-4431-8e96-a8934fff535e@github.com>

On Fri, 10 Sep 2021 18:30:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Remove a lock that's no longer used.  Tested with local build.

This pull request has now been integrated.

Changeset: e4cd2097
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e4cd2097a56df20da07a2b5c70838431b42c9a73
Stats:     4 lines in 2 files changed: 0 ins; 3 del; 1 mod

8273611: Remove unused ProfilePrint_lock

Reviewed-by: iklam

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

PR: https://git.openjdk.java.net/jdk/pull/5474

From glaubitz at openjdk.java.net  Fri Sep 10 19:39:47 2021
From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz)
Date: Fri, 10 Sep 2021 19:39:47 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type mismatch
In-Reply-To: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
Message-ID: <Cve5c-M1qoAVBuB5x8MKVMFKR205-MixDllFnSGE-l0=.b1936b84-429a-41a5-8244-10268bb64469@github.com>

On Fri, 10 Sep 2021 16:25:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is actually caught by `-Werror=format` that is enabled by default.
> 
> 
> $  sh ./configure --with-debug-level=slowdebug --with-boot-jdk=/home/shade/Install/jdk16-16.0.2-ea/ --openjdk-target=sparc64-linux-gnu --with-sysroot=/chroots/sparc64/ --with-jvm-variants=zero
> $ make images

> Apparently, it was never fixed in glibc for sparc64? We can still make a defensive cast to `long`.

Can you file a bug report to the glibc bug tracker?

> I looked at how Debian folks avoid this problem, and I think there is Debian patch that just disables `-Werror` wholesale. Right, @glaubitz? :)

Yes, that's correct. See: https://salsa.debian.org/openjdk-team/openjdk/-/blob/openjdk-16/debian/patches/hotspot-disable-werror.diff

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From ccheung at openjdk.java.net  Fri Sep 10 20:47:44 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 10 Sep 2021 20:47:44 GMT
Subject: RFR: 8273522: Rename test property vm.cds.archived.java.heap to
 vm.cds.write.archived.java.heap
In-Reply-To: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
References: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
Message-ID: <_uOKRrhKvHX5E9DXDs3B-Dt07tgneyj0bfAKVuImjIk=.0a3c37a8-fa4c-4cf7-975b-40e41bf69550@github.com>

On Thu, 9 Sep 2021 20:28:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The vm.cds.archived.java.heap test property (see test/jtreg-ext/requires/VMProps.java) is ambiguous -- after JDK-8270489, there are now two distinct capabilities:
> 
> - HeapShared::can_write() -- G1 only
> - HeapShared::can_read() -- G1, Epsilon
> 
> A few CDS tests are marked with
> 
> 
> @requires vm.cds.archived.java.heap
> 
> 
> These tests actually require the VM to be able to write Java objects into the CDS archive. Therefore, for clarify, they should be changed to use
> 
> 
> @requires vm.cds.write.archived.java.heap
> 
> 
> *****
> This fix is required for JDK-8273508 - "Support archived heap objects in SerialGC".
> 
> Without this fix, tests marked with `@requires vm.cds.archived.java.heap` would be executed even if SerialGC is selected, but this will dump CDS archives without archived heap objects, causing the tests to fail.

LGTM.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5455

From mseledtsov at openjdk.java.net  Fri Sep 10 21:18:23 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 10 Sep 2021 21:18:23 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested [v3]
In-Reply-To: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
Message-ID: <zHCeTdeFGpJ_8nzaWrYrePqGQv7g6z6sYhcBzdKOD9U=.bea66154-206c-4116-8c6b-d3d2916550bc@github.com>

> Please review this addition of new testing:
>   - new test for sending jcmd commands across container boundaries
>   - updated existing sidecar test, enabling jcmd test case

Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary UsePerfData per review feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5368/files
  - new: https://git.openjdk.java.net/jdk/pull/5368/files/1a66f1c0..f1eead47

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5368&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5368&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/5368

From mseledtsov at openjdk.java.net  Fri Sep 10 21:20:54 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 10 Sep 2021 21:20:54 GMT
Subject: RFR: 8273522: Rename test property vm.cds.archived.java.heap to
 vm.cds.write.archived.java.heap
In-Reply-To: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
References: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
Message-ID: <HlzNS5aSlP9btmAIx3erJJh9nOVqGiXCGi5h38VSDPs=.4d5bef9a-6ab3-4a6d-b0fc-0cf03607b8b8@github.com>

On Thu, 9 Sep 2021 20:28:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The vm.cds.archived.java.heap test property (see test/jtreg-ext/requires/VMProps.java) is ambiguous -- after JDK-8270489, there are now two distinct capabilities:
> 
> - HeapShared::can_write() -- G1 only
> - HeapShared::can_read() -- G1, Epsilon
> 
> A few CDS tests are marked with
> 
> 
> @requires vm.cds.archived.java.heap
> 
> 
> These tests actually require the VM to be able to write Java objects into the CDS archive. Therefore, for clarify, they should be changed to use
> 
> 
> @requires vm.cds.write.archived.java.heap
> 
> 
> *****
> This fix is required for JDK-8273508 - "Support archived heap objects in SerialGC".
> 
> Without this fix, tests marked with `@requires vm.cds.archived.java.heap` would be executed even if SerialGC is selected, but this will dump CDS archives without archived heap objects, causing the tests to fail.

Looks good.

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

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5455

From cjplummer at openjdk.java.net  Fri Sep 10 21:26:55 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Fri, 10 Sep 2021 21:26:55 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <gUwviCtEpkVYiCOvrCrudQKMfB-dOni5rYGjjqmpwcs=.094fc820-dcc1-4e4b-abb9-cae51082a25d@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <gUwviCtEpkVYiCOvrCrudQKMfB-dOni5rYGjjqmpwcs=.094fc820-dcc1-4e4b-abb9-cae51082a25d@github.com>
Message-ID: <ZKcteJk7-ZfxVbZI7qxMJGnm27M8jiln6xDImAA6S2s=.94a82830-9d53-4e2c-95cb-d6c099409469@github.com>

On Fri, 10 Sep 2021 03:03:01 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Seems the #5410 has made some change that will affect this one. I am wondering should I start to rebase this PR based on that ?

It looks like at most there would be one conflict, and it is trivial. You'll eventually have to merge before integrating anyway.

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From iklam at openjdk.java.net  Fri Sep 10 22:39:50 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 10 Sep 2021 22:39:50 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump
In-Reply-To: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
Message-ID: <7tS6Rp9DRCfFZ2EbuBYXk8bfvOBDP1_j51jkaBb8k3E=.1e5c76e1-a5a4-4b26-8252-f57b4a5838b8@github.com>

On Fri, 10 Sep 2021 00:20:04 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
> 
> Passed tiers 1 - 4 testing.

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/classListParser.cpp line 476:

> 474:   }
> 475: 
> 476:   // This tells JVM_FindLoadedClass to not find this class.

This comment can be deleted.

The class `k` used to be defined by the boot loader. As a result, when `JVM_FindLoadedClass` looked up a class in the boot/platform/app loaders, it may inadvertently find `k`.

However, after this PR, `k` is no longer defined by the boot loader.

src/hotspot/share/classfile/classLoaderExt.cpp line 297:

> 295: }
> 296: 
> 297: class URLClassLoaderTable : public ResourceHashtable<

I think we should try to decouple the loading of unregistered classes from ClassLoader/ClassloaderExt. Maybe these new functions can be placed in a new file, shared/cds/unregisteredClasses.cpp, and the API entry point would be `UnregisteredClasses::load_class(name, path)`.

Also, `ClassLoaderExt::find_classpath_entry_from_cache` shouldn't be needed anymore. If the JAR file doesn't exist, URLClassLoader will throw an exception, so we don't need to create a ClassPathEntry just to check for the JAR file's existence.

I wonder if there's any code in classLoader.cpp that was used only for supporting the loading of unregistered classes. If so, it can be removed, too.

src/hotspot/share/classfile/classLoaderExt.cpp line 299:

> 297: class URLClassLoaderTable : public ResourceHashtable<
> 298:   Symbol*, Handle,
> 299:   7, // prime number

I think 7 is too small. Maybe 137?

src/hotspot/share/classfile/classLoaderExt.cpp line 327:

> 325: Handle ClassLoaderExt::create_and_add_url_classloader(Symbol* path, TRAPS) {
> 326:   Handle url_classloader = create_url_classloader(path, CHECK_NH);
> 327:   bool added = _url_classloader_table->put(path, url_classloader);

added is not used. Did you want to assert that `added == true`?

I think it's better to move the body of this function to line 342. Then it would be clear that the entry doesn't exist (and there's no need to check for `added`).

src/hotspot/share/classfile/classLoaderExt.cpp line 336:

> 334:     _url_classloader_table = new (ResourceObj::C_HEAP, mtClass)URLClassLoaderTable();
> 335:     Handle url_classloader = create_and_add_url_classloader(path, CHECK_NH);
> 336:     return url_classloader;

I think the above 2 lines should be removed and the creation should be done in a single place. This means `_url_classloader_table->get()` would be unnecessarily called when the table is created, but I think that's OK since this happens only once.

src/hotspot/share/classfile/classLoaderExt.cpp line 368:

> 366:   assert(result.get_type() == T_OBJECT, "just checking");
> 367:   oop obj = result.get_oop();
> 368:   InstanceKlass* k = InstanceKlass::cast(java_lang_Class::as_Klass(obj));

No need for the temp variable `k` since it's immediately returned.

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From iklam at openjdk.java.net  Fri Sep 10 22:48:51 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 10 Sep 2021 22:48:51 GMT
Subject: RFR: 8273522: Rename test property vm.cds.archived.java.heap to
 vm.cds.write.archived.java.heap
In-Reply-To: <_uOKRrhKvHX5E9DXDs3B-Dt07tgneyj0bfAKVuImjIk=.0a3c37a8-fa4c-4cf7-975b-40e41bf69550@github.com>
References: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
 <_uOKRrhKvHX5E9DXDs3B-Dt07tgneyj0bfAKVuImjIk=.0a3c37a8-fa4c-4cf7-975b-40e41bf69550@github.com>
Message-ID: <jm_TVAUlLHkuPa_FhS_vh9a01DfzKQT0Hgpu0ljKYBg=.78f08503-65aa-46df-9fce-cd6907f3b15c@github.com>

On Fri, 10 Sep 2021 20:45:16 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> The vm.cds.archived.java.heap test property (see test/jtreg-ext/requires/VMProps.java) is ambiguous -- after JDK-8270489, there are now two distinct capabilities:
>> 
>> - HeapShared::can_write() -- G1 only
>> - HeapShared::can_read() -- G1, Epsilon
>> 
>> A few CDS tests are marked with
>> 
>> 
>> @requires vm.cds.archived.java.heap
>> 
>> 
>> These tests actually require the VM to be able to write Java objects into the CDS archive. Therefore, for clarify, they should be changed to use
>> 
>> 
>> @requires vm.cds.write.archived.java.heap
>> 
>> 
>> *****
>> This fix is required for JDK-8273508 - "Support archived heap objects in SerialGC".
>> 
>> Without this fix, tests marked with `@requires vm.cds.archived.java.heap` would be executed even if SerialGC is selected, but this will dump CDS archives without archived heap objects, causing the tests to fail.
>
> LGTM.

Thanks @calvinccheung @yminqi @mseledts for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/5455

From iklam at openjdk.java.net  Fri Sep 10 22:48:52 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 10 Sep 2021 22:48:52 GMT
Subject: Integrated: 8273522: Rename test property vm.cds.archived.java.heap
 to vm.cds.write.archived.java.heap
In-Reply-To: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
References: <OHkOZMeSi2S2IIIUJYakgRlV_egpJtJ6_71qjAYEWW0=.d0d11160-b58f-4206-b833-4ba915a28ebb@github.com>
Message-ID: <_1sZcnhlDry_rirBc0kIwuLQ4rsHyNXX1kqy6di-OGA=.07576400-8813-4805-9c6c-e68126349e18@github.com>

On Thu, 9 Sep 2021 20:28:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The vm.cds.archived.java.heap test property (see test/jtreg-ext/requires/VMProps.java) is ambiguous -- after JDK-8270489, there are now two distinct capabilities:
> 
> - HeapShared::can_write() -- G1 only
> - HeapShared::can_read() -- G1, Epsilon
> 
> A few CDS tests are marked with
> 
> 
> @requires vm.cds.archived.java.heap
> 
> 
> These tests actually require the VM to be able to write Java objects into the CDS archive. Therefore, for clarify, they should be changed to use
> 
> 
> @requires vm.cds.write.archived.java.heap
> 
> 
> *****
> This fix is required for JDK-8273508 - "Support archived heap objects in SerialGC".
> 
> Without this fix, tests marked with `@requires vm.cds.archived.java.heap` would be executed even if SerialGC is selected, but this will dump CDS archives without archived heap objects, causing the tests to fail.

This pull request has now been integrated.

Changeset: 922e86f4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/922e86f4ff28c7b17af8e7b5867a40fc76b7fdd7
Stats:     53 lines in 40 files changed: 0 ins; 3 del; 50 mod

8273522: Rename test property vm.cds.archived.java.heap to vm.cds.write.archived.java.heap

Reviewed-by: minqi, ccheung, mseledtsov

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

PR: https://git.openjdk.java.net/jdk/pull/5455

From ysuenaga at openjdk.java.net  Sat Sep 11 01:45:47 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 11 Sep 2021 01:45:47 GMT
Subject: RFR: 8273610: LogTestFixture::restore_config() should not restore
 options
In-Reply-To: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>
References: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>
Message-ID: <mPzjcAWIAvkpr1T3ADctRMdNplS1V3Iqm9wshvFu77I=.94a439b8-4891-49c9-8d85-c6087554f7c5@github.com>

On Fri, 10 Sep 2021 18:13:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a prerequisite of https://github.com/openjdk/jdk/pull/5407
> 
> LogTestFixture::restore_config() should not restore the options because it's neither necessary nor allowed. Please see the RFE description for details.

Looks good. Thank you for fixing this!

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

Marked as reviewed by ysuenaga (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5472

From ysuenaga at openjdk.java.net  Sat Sep 11 01:46:49 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sat, 11 Sep 2021 01:46:49 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v6]
In-Reply-To: <4-o4duRXC_1e696wkRlPrS9JlJftt_dKlxyxa6MI8Og=.2bbd7e57-6ffd-4740-a9c2-dfdb5520a2d1@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
 <L7WNoOUV44Ll8fBdNjYWoqWH8j9KgjrxMBQ4nQABbhw=.309a94a1-9695-41e9-baa3-e7b905c0c843@github.com>
 <4-o4duRXC_1e696wkRlPrS9JlJftt_dKlxyxa6MI8Og=.2bbd7e57-6ffd-4740-a9c2-dfdb5520a2d1@github.com>
Message-ID: <K5vOX8JjTRzBTuDtZiPOOij3D5CmvdyCYTngjDNCXLA=.c879d26c-7a72-4882-ab3f-812055565608@github.com>

On Fri, 10 Sep 2021 18:14:07 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> test/hotspot/gtest/logging/logTestFixture.cpp line 104:
>> 
>>> 102:     }
>>> 103: 
>>> 104: // TODO: Restore following code if options for existing log output can be changed.
>> 
>> I think this change needs a better explanation and should be done in a separate RFE. I've file https://bugs.openjdk.java.net/browse/JDK-8273610 and will post a PR soon.
>
> I posted the PR: https://github.com/openjdk/jdk/pull/5472

Thanks! I will modify this PR after merging #5472 .

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From kevinw at openjdk.java.net  Sat Sep 11 06:42:42 2021
From: kevinw at openjdk.java.net (Kevin Walls)
Date: Sat, 11 Sep 2021 06:42:42 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested [v3]
In-Reply-To: <zHCeTdeFGpJ_8nzaWrYrePqGQv7g6z6sYhcBzdKOD9U=.bea66154-206c-4116-8c6b-d3d2916550bc@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
 <zHCeTdeFGpJ_8nzaWrYrePqGQv7g6z6sYhcBzdKOD9U=.bea66154-206c-4116-8c6b-d3d2916550bc@github.com>
Message-ID: <yIVowawMjLJSjeUKygFycFJJ5PXOIsMh9h2S9eqnYbE=.0090dabb-411c-4a33-afa0-def3a2f8abd8@github.com>

On Fri, 10 Sep 2021 21:18:23 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this addition of new testing:
>>   - new test for sending jcmd commands across container boundaries
>>   - updated existing sidecar test, enabling jcmd test case
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary UsePerfData per review feedback

Yes looks good. I've run the tests and both running OK and passing.

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

Marked as reviewed by kevinw (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5368

From dholmes at openjdk.java.net  Sun Sep 12 06:12:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 12 Sep 2021 06:12:52 GMT
Subject: RFR: 8273610: LogTestFixture::restore_config() should not restore
 options
In-Reply-To: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>
References: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>
Message-ID: <sklkmcKg1mgmUoHOcqB2riD57dgBUuMfGm1kmlqiSS8=.5e9aeb6d-ad17-43ed-a258-17983e8bd58a@github.com>

On Fri, 10 Sep 2021 18:13:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a prerequisite of https://github.com/openjdk/jdk/pull/5407
> 
> LogTestFixture::restore_config() should not restore the options because it's neither necessary nor allowed. Please see the RFE description for details.

Seems ok.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5472

From dholmes at openjdk.java.net  Sun Sep 12 22:20:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 12 Sep 2021 22:20:48 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v6]
In-Reply-To: <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
Message-ID: <5diu3ROKNiqkE3B1VFsaKUHif4MhnZ5CiHqna_qo28I=.56bd6b88-979b-4c90-9f67-af2131efbb12@github.com>

On Fri, 10 Sep 2021 12:17:41 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add comments about parse_options() call
>  - Fix GTest failure

Changes requested by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From dholmes at openjdk.java.net  Sun Sep 12 22:20:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 12 Sep 2021 22:20:49 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v5]
In-Reply-To: <e2oth04-lPZik2uzT0yu5LC2OqCTNuN2McpmoGpXGRo=.b8431fd5-5633-4c0a-99da-ebfd3af93a94@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <U-l9_quEfY4f4vA9FR7R7fX_vJA45uoQfAl3ivyiWhs=.1f30ad85-2a3b-43a4-b26f-d11329b94f65@github.com>
 <y3Q329BWSPS3D2Hq1UdRUoamC0DLbLvb0CjzrRNzWxQ=.c51dcaf6-4276-4eab-97c7-d354d434a2c7@github.com>
 <e2oth04-lPZik2uzT0yu5LC2OqCTNuN2McpmoGpXGRo=.b8431fd5-5633-4c0a-99da-ebfd3af93a94@github.com>
Message-ID: <_A7pPQWXHEKvk0vWMOX9bppNqCWhWykoELNVwqjnRQM=.e1f5149b-958c-49e6-b499-9823bb66fef9@github.com>

On Fri, 10 Sep 2021 14:40:51 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> src/hotspot/share/logging/logConfiguration.cpp line 419:
>> 
>>> 417:   if (output == NULL || strlen(output) == 0 ||
>>> 418:       strcmp("stdout", output) == 0 || strcmp("#0", output) == 0) {
>>> 419:     if (!stdout_configured) {
>> 
>> So you are piggy-backing on parse_log_arguments() to produce the warning ... can you add a comment at the end:
>> // else - fall-through to normal option processing which will be rejected with a warning
>
> I added it.

You added it in the wrong place - it is supposed to document the not-present "else" part of "if (!stdout_configured) {"

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From iklam at openjdk.java.net  Mon Sep 13 01:59:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 13 Sep 2021 01:59:55 GMT
Subject: RFR: 8273610: LogTestFixture::restore_config() should not restore
 options
In-Reply-To: <mPzjcAWIAvkpr1T3ADctRMdNplS1V3Iqm9wshvFu77I=.94a439b8-4891-49c9-8d85-c6087554f7c5@github.com>
References: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>
 <mPzjcAWIAvkpr1T3ADctRMdNplS1V3Iqm9wshvFu77I=.94a439b8-4891-49c9-8d85-c6087554f7c5@github.com>
Message-ID: <XXMWXt_8GZrkh7E7hNd8ACTg54VPZzUh_8sqCbqehzA=.cfeaba8e-3ba1-4f53-b599-238f9ba61fe3@github.com>

On Sat, 11 Sep 2021 01:42:34 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> This is a prerequisite of https://github.com/openjdk/jdk/pull/5407
>> 
>> LogTestFixture::restore_config() should not restore the options because it's neither necessary nor allowed. Please see the RFE description for details.
>
> Looks good. Thank you for fixing this!

Thanks @YaSuenag and @dholmes-ora for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/5472

From iklam at openjdk.java.net  Mon Sep 13 01:59:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 13 Sep 2021 01:59:55 GMT
Subject: Integrated: 8273610: LogTestFixture::restore_config() should not
 restore options
In-Reply-To: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>
References: <Dac5czRcoCgCf8Gt2Dm6UO6HGL98lkMOteFWwpuQnXc=.7d8c38ed-0e30-4652-b01a-04eb76cc9ffe@github.com>
Message-ID: <WS7Hnnia9SWUpsqmJnsjRTWWL7r9AVKQm6Eo-KzOWU4=.5a71161a-873f-4c97-b888-c9c28ab187f1@github.com>

On Fri, 10 Sep 2021 18:13:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is a prerequisite of https://github.com/openjdk/jdk/pull/5407
> 
> LogTestFixture::restore_config() should not restore the options because it's neither necessary nor allowed. Please see the RFE description for details.

This pull request has now been integrated.

Changeset: 9f86082f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9f86082fd5174b4543eb6abc0879690430208ba0
Stats:     9 lines in 1 file changed: 4 ins; 3 del; 2 mod

8273610: LogTestFixture::restore_config() should not restore options

Reviewed-by: ysuenaga, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5472

From ysuenaga at openjdk.java.net  Mon Sep 13 02:48:17 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 13 Sep 2021 02:48:17 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v7]
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <a4LYa2G1TdRRY1T3X_m98Dy4eqXF4kLK7MMQvIeAAhI=.a39ef174-cad3-467a-99a6-10235e0c5a08@github.com>

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Fix comments
 - Merge remote-tracking branch 'upstream/master' into JDK-8273471
 - Add comments about parse_options() call
 - Fix GTest failure
 - output options for stdout/err should be applied just once
 - Refactoring FoldMultilinesTest
 - Merge remote-tracking branch 'upstream/master' into JDK-8273471
 - Add test for default log output (stdout)
 - Fix comments
 - 8273471: Add foldmultilines to UL for stdout/err

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

Changes: https://git.openjdk.java.net/jdk/pull/5407/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5407&range=06
  Stats: 130 lines in 7 files changed: 87 ins; 20 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5407.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5407/head:pull/5407

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Mon Sep 13 02:48:19 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 13 Sep 2021 02:48:19 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v5]
In-Reply-To: <_A7pPQWXHEKvk0vWMOX9bppNqCWhWykoELNVwqjnRQM=.e1f5149b-958c-49e6-b499-9823bb66fef9@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <U-l9_quEfY4f4vA9FR7R7fX_vJA45uoQfAl3ivyiWhs=.1f30ad85-2a3b-43a4-b26f-d11329b94f65@github.com>
 <y3Q329BWSPS3D2Hq1UdRUoamC0DLbLvb0CjzrRNzWxQ=.c51dcaf6-4276-4eab-97c7-d354d434a2c7@github.com>
 <e2oth04-lPZik2uzT0yu5LC2OqCTNuN2McpmoGpXGRo=.b8431fd5-5633-4c0a-99da-ebfd3af93a94@github.com>
 <_A7pPQWXHEKvk0vWMOX9bppNqCWhWykoELNVwqjnRQM=.e1f5149b-958c-49e6-b499-9823bb66fef9@github.com>
Message-ID: <KFtOVCwWEE-vnceCaP9ALm9J-47RFxcMdSo1gTzdhso=.cb59f50b-7a53-4046-b8b4-0a26da2d4b80@github.com>

On Sun, 12 Sep 2021 22:16:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I added it.
>
> You added it in the wrong place - it is supposed to document the not-present "else" part of "if (!stdout_configured) {"

Sorry, I fixed it in new commit.

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From ysuenaga at openjdk.java.net  Mon Sep 13 02:48:20 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Mon, 13 Sep 2021 02:48:20 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v6]
In-Reply-To: <K5vOX8JjTRzBTuDtZiPOOij3D5CmvdyCYTngjDNCXLA=.c879d26c-7a72-4882-ab3f-812055565608@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <lQYbRzXnITsJEq_pI0op-GRqOR2-Os_9h9EkYcsQ4EM=.bd67c4cb-44e7-4017-ad8b-98fcf92b3612@github.com>
 <L7WNoOUV44Ll8fBdNjYWoqWH8j9KgjrxMBQ4nQABbhw=.309a94a1-9695-41e9-baa3-e7b905c0c843@github.com>
 <4-o4duRXC_1e696wkRlPrS9JlJftt_dKlxyxa6MI8Og=.2bbd7e57-6ffd-4740-a9c2-dfdb5520a2d1@github.com>
 <K5vOX8JjTRzBTuDtZiPOOij3D5CmvdyCYTngjDNCXLA=.c879d26c-7a72-4882-ab3f-812055565608@github.com>
Message-ID: <GnAfM-OVFKCDceDkR7sB10RtF2otInxA3Db_I9gHUBM=.80fadd6a-061e-44ca-974c-c5f305703653@github.com>

On Sat, 11 Sep 2021 01:43:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> I posted the PR: https://github.com/openjdk/jdk/pull/5472
>
> Thanks! I will modify this PR after merging #5472 .

I merged #5472 .

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From dholmes at openjdk.java.net  Mon Sep 13 03:35:55 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Sep 2021 03:35:55 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v7]
In-Reply-To: <a4LYa2G1TdRRY1T3X_m98Dy4eqXF4kLK7MMQvIeAAhI=.a39ef174-cad3-467a-99a6-10235e0c5a08@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <a4LYa2G1TdRRY1T3X_m98Dy4eqXF4kLK7MMQvIeAAhI=.a39ef174-cad3-467a-99a6-10235e0c5a08@github.com>
Message-ID: <VSpQzwWz_4qtxaMhyBLZOZhE_sH3l7q_CVusUluPUE0=.14572527-4178-4475-8048-a7a77b785060@github.com>

On Mon, 13 Sep 2021 02:48:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Fix comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8273471
>  - Add comments about parse_options() call
>  - Fix GTest failure
>  - output options for stdout/err should be applied just once
>  - Refactoring FoldMultilinesTest
>  - Merge remote-tracking branch 'upstream/master' into JDK-8273471
>  - Add test for default log output (stdout)
>  - Fix comments
>  - 8273471: Add foldmultilines to UL for stdout/err

Looks good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5407

From iklam at openjdk.java.net  Mon Sep 13 06:09:57 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 13 Sep 2021 06:09:57 GMT
Subject: RFR: 8273471: Add foldmultilines to UL for stdout/err [v7]
In-Reply-To: <a4LYa2G1TdRRY1T3X_m98Dy4eqXF4kLK7MMQvIeAAhI=.a39ef174-cad3-467a-99a6-10235e0c5a08@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
 <a4LYa2G1TdRRY1T3X_m98Dy4eqXF4kLK7MMQvIeAAhI=.a39ef174-cad3-467a-99a6-10235e0c5a08@github.com>
Message-ID: <2YPQIY6ITS3pa-9Z4W_5KC8mZxOWK-M8cIf8LdpHtUU=.ee604db2-4b2d-4450-8bfa-6a60e30574aa@github.com>

On Mon, 13 Sep 2021 02:48:17 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
>> 
>> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
>> 
>> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
>> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
>> 
>> 
>> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
>> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
>> 
>> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
>> 
>> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
>> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
>> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
>> 
>> 
>> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
>> 
>> In addition, we might see following logs which relate to UL:
>> 
>> 
>> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
>> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
>> [0.000s][error][logging] Invalid level 'aaa' in log selection.
>> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
>> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
>> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.
>
> Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Fix comments
>  - Merge remote-tracking branch 'upstream/master' into JDK-8273471
>  - Add comments about parse_options() call
>  - Fix GTest failure
>  - output options for stdout/err should be applied just once
>  - Refactoring FoldMultilinesTest
>  - Merge remote-tracking branch 'upstream/master' into JDK-8273471
>  - Add test for default log output (stdout)
>  - Fix comments
>  - 8273471: Add foldmultilines to UL for stdout/err

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5407

From ihse at openjdk.java.net  Mon Sep 13 06:42:47 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 13 Sep 2021 06:42:47 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type mismatch
In-Reply-To: <Cve5c-M1qoAVBuB5x8MKVMFKR205-MixDllFnSGE-l0=.b1936b84-429a-41a5-8244-10268bb64469@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
 <Cve5c-M1qoAVBuB5x8MKVMFKR205-MixDllFnSGE-l0=.b1936b84-429a-41a5-8244-10268bb64469@github.com>
Message-ID: <IhpbIXgv8do5u-HggaGya9dbD6WodoUaTxKO7Z1vWR0=.669bcf13-a0d8-4451-a81f-5a3840d44d67@github.com>

On Fri, 10 Sep 2021 19:36:35 GMT, John Paul Adrian Glaubitz <glaubitz at openjdk.org> wrote:

> Yes, that's correct. See: https://salsa.debian.org/openjdk-team/openjdk/-/blob/openjdk-16/debian/patches/hotspot-disable-werror.diff

@glaubitz That patch seems unlikely to work on modern JDK?! The old hotspot build system was removed ages ago.

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From stuefe at openjdk.java.net  Mon Sep 13 07:54:51 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 13 Sep 2021 07:54:51 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type mismatch
In-Reply-To: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
Message-ID: <Ji6tPPLqVaCbglY4H5TWNnPnHRnJQFjXaQW2h4gTuuY=.6f854627-40ff-46bc-bb64-bc212fa4a49e@github.com>

On Fri, 10 Sep 2021 16:25:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is actually caught by `-Werror=format` that is enabled by default.
> 
> 
> $  sh ./configure --with-debug-level=slowdebug --with-boot-jdk=/home/shade/Install/jdk16-16.0.2-ea/ --openjdk-target=sparc64-linux-gnu --with-sysroot=/chroots/sparc64/ --with-jvm-variants=zero
> $ make images

Patch itself seems fine and trivial.

Lest someone removes the cast, maybe add a comment that this is for the sake of glibc problems on sparc? Leave it up to you.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5470

From shade at openjdk.java.net  Mon Sep 13 07:59:49 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Sep 2021 07:59:49 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type mismatch
In-Reply-To: <Cve5c-M1qoAVBuB5x8MKVMFKR205-MixDllFnSGE-l0=.b1936b84-429a-41a5-8244-10268bb64469@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
 <Cve5c-M1qoAVBuB5x8MKVMFKR205-MixDllFnSGE-l0=.b1936b84-429a-41a5-8244-10268bb64469@github.com>
Message-ID: <m2PjlMiWPsQgFrLdSeCziEWd0Zt6cHcMZIWFrv4Nyn0=.943938f0-f899-4739-9097-62d60b92aa80@github.com>

On Fri, 10 Sep 2021 19:36:35 GMT, John Paul Adrian Glaubitz <glaubitz at openjdk.org> wrote:

> > Apparently, it was never fixed in glibc for sparc64? We can still make a defensive cast to `long`.
> 
> Can you file a bug report to the glibc bug tracker?

I see that was already reported as [glibc bug #23821](https://sourceware.org/bugzilla/show_bug.cgi?id=23821), and glibc maintainers decided not to fix it. So, we can still make a defensive cast to (long), which would be no-op if the type is in fact long.

I verified that latest glibc sources still have:


sysdeps/unix/sysv/linux/bits/types/siginfo_t.h
110:	    __SI_BAND_TYPE si_band;	/* Band event for SIGPOLL.  */

sysdeps/unix/sysv/linux/sparc/bits/siginfo-arch.h
9:# define __SI_BAND_TYPE int

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From shade at openjdk.java.net  Mon Sep 13 08:05:20 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Sep 2021 08:05:20 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type
 mismatch [v2]
In-Reply-To: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
Message-ID: <veLkydGKyG0Uz0e1YQOW77iapCYtEU1oanVv_5rDRv4=.6d910936-0ab0-4d9e-b364-1ba9fe699e05@github.com>

> This is actually caught by `-Werror=format` that is enabled by default.
> 
> 
> $  sh ./configure --with-debug-level=slowdebug --with-boot-jdk=/home/shade/Install/jdk16-16.0.2-ea/ --openjdk-target=sparc64-linux-gnu --with-sysroot=/chroots/sparc64/ --with-jvm-variants=zero
> $ make images

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

  Add comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5470/files
  - new: https://git.openjdk.java.net/jdk/pull/5470/files/b1c72819..4746e91c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5470&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5470&range=00-01

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5470/head:pull/5470

PR: https://git.openjdk.java.net/jdk/pull/5470

From shade at openjdk.java.net  Mon Sep 13 08:05:21 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Sep 2021 08:05:21 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type
 mismatch [v2]
In-Reply-To: <Ji6tPPLqVaCbglY4H5TWNnPnHRnJQFjXaQW2h4gTuuY=.6f854627-40ff-46bc-bb64-bc212fa4a49e@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
 <Ji6tPPLqVaCbglY4H5TWNnPnHRnJQFjXaQW2h4gTuuY=.6f854627-40ff-46bc-bb64-bc212fa4a49e@github.com>
Message-ID: <wdqmQZOQWAbfnj_8Z6SlbGDxFYvo6hNEZ8Xy_SPzdo0=.c7f9f208-3ddf-4427-b072-26cca0485488@github.com>

On Mon, 13 Sep 2021 07:51:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Lest someone removes the cast, maybe add a comment that this is for the sake of glibc problems on sparc? Leave it up to you.

Yes. I added a comment block describing what happens here, plus a link to glibc bugtracker.

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From shade at openjdk.java.net  Mon Sep 13 08:16:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 13 Sep 2021 08:16:53 GMT
Subject: RFR: 8256977: Bump minimum GCC from 5.x to 6 for JDK
In-Reply-To: <GRT9YAPpauCay5CaUVeJDzqGExdbqy1r4xcVODFfIgU=.6a0cb3b1-a383-4561-8183-e2d16b4d9a1b@github.com>
References: <GRT9YAPpauCay5CaUVeJDzqGExdbqy1r4xcVODFfIgU=.6a0cb3b1-a383-4561-8183-e2d16b4d9a1b@github.com>
Message-ID: <9AfHTba66cQbBVqcJmzdlN01t6MwQ1RtF6ZaJy3vVAI=.a4e91977-dc83-4a3d-ac9f-ca2ff0389901@github.com>

On Thu, 9 Sep 2021 19:28:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The minimum acceptable version is raised from 5 to 6. There were no objections on the mailing list for doing so in the mainline, see https://mail.openjdk.java.net/pipermail/build-dev/2021-August/031899.html.
> 
> This patch also reverts the workaround that was introduced in JDK-8252797 to support gcc 5.x.

Yes, I think there would be no harm to do this for JDK mainline.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5452

From glaubitz at openjdk.java.net  Mon Sep 13 08:31:49 2021
From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz)
Date: Mon, 13 Sep 2021 08:31:49 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type mismatch
In-Reply-To: <IhpbIXgv8do5u-HggaGya9dbD6WodoUaTxKO7Z1vWR0=.669bcf13-a0d8-4451-a81f-5a3840d44d67@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
 <Cve5c-M1qoAVBuB5x8MKVMFKR205-MixDllFnSGE-l0=.b1936b84-429a-41a5-8244-10268bb64469@github.com>
 <IhpbIXgv8do5u-HggaGya9dbD6WodoUaTxKO7Z1vWR0=.669bcf13-a0d8-4451-a81f-5a3840d44d67@github.com>
Message-ID: <RJixFwKTZwXqVuPJXXjc_hYpgEUHmPNwa-pjYrTK9Eg=.b164b0b0-8fb7-44ba-82ed-faaebc5e86b3@github.com>

On Mon, 13 Sep 2021 06:39:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Yes, that's correct. See: https://salsa.debian.org/openjdk-team/openjdk/-/blob/openjdk-16/debian/patches/hotspot-disable-werror.diff
> 
> @glaubitz That patch seems unlikely to work on modern JDK?! The old hotspot build system was removed ages ago.

This is for OpenJDK-16, was that changed recently.

In any case, Matthias Klose is the maintainer of the package in Debian and Ubuntu. I will let him know.

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From mgronlun at openjdk.java.net  Mon Sep 13 11:04:58 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 13 Sep 2021 11:04:58 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v10]
In-Reply-To: <mQ3lJ0MLksSfarBtRg8HnvW1POUmy4fzzjL0M3x45c0=.f39fa255-a8e6-44f0-ae3e-197db15f1093@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <kDbmRbj6sWLGGhNprH_U8-9vsmbzsOkxU7_ekGtec6g=.3c825a07-fc0e-43ed-8cf7-76b62c096ee7@github.com>
 <mQ3lJ0MLksSfarBtRg8HnvW1POUmy4fzzjL0M3x45c0=.f39fa255-a8e6-44f0-ae3e-197db15f1093@github.com>
Message-ID: <NYoHUmht3iY5rvUrO4pgtZNsnUDvyzeSjIt1sgMZjps=.880d6c96-3eaa-4704-8079-8010508557c2@github.com>

On Wed, 8 Sep 2021 17:37:20 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - localize
>>  - cleanup
>>  - FinalizerStatistics
>
> src/hotspot/share/services/classLoadingService.cpp line 80:
> 
>> 78: 
>> 79: size_t ClassLoadingService::compute_class_size(InstanceKlass* k) {
>> 80:   // lifted from ClassStatistics.do_class(Klass* k)
> 
> Can you remove this line? I think that function is gone now.

Thanks Coleen for taking a look at this.

It is used internally by notify_class_loaded() and notify_class_unloaded(); therefore I will change it to have internal linkage.

> src/hotspot/share/services/finalizerService.cpp line 44:
> 
>> 42:     _ik(ik),
>> 43:     _objects_on_heap(0),
>> 44:     _total_finalizers_run(0) {}
> 
> Is this hashtable for every InstanceKlass that defines a finalizer?  How many are there generally?  Why couldn't this be a simple hashtable like ResourceHashtable (soon to be renamed) which you can write in only a few lines of code?

This hashtable holds a FinalizerEntry for every InstanceKlass that provides a non-empty finalizer method and have allocated at least one object. How many there are in general depends on the application. A ResourceHashtable does not have the concurrency property required, as lookups and inserts will happen as part of object allocation.

> src/hotspot/share/services/finalizerService.cpp line 114:
> 
>> 112: 
>> 113: static inline void added() {
>> 114:   set_atomic<inc>(&_count);
> 
> Why isn't Atomic::inc() good enough here? It's used everywhere else.

Our Atomic implementation does not support CAS of a 64-bit value on 32-bit platforms (compiles but does not link).

> src/hotspot/share/services/finalizerService.cpp line 123:
> 
>> 121: static inline uintx hash_function(const InstanceKlass* ik) {
>> 122:   assert(ik != nullptr, "invariant");
>> 123:   return primitive_hash(ik);
> 
> If the hash function is primitive_hash, this hash is good enough to not need rehashing.  The only reason for the rehashing for symbol and string table was that the char* had a dumb hash that was faster but could be hacked, so it needed to become a different hashcode.  This doesn't need rehashing.

Thank you for pointing that out. I had assumed this to be a part of the syntactic contract for using the ConcurrentHashTable. My wrong assumption was because the SymbolTable (which I used as a model) seemed to pass a "rehash_warning" bool to the accessor APIs (get, insert). However, looking more closely at the signatures in ConcurrentHashTable, that bool is a "grow_hint", not "rehash" specifically. Thanks again; I will remove the rehash support code.

> src/hotspot/share/services/finalizerService.cpp line 485:
> 
>> 483: void FinalizerService::purge_unloaded() {
>> 484:   assert_locked_or_safepoint(ClassLoaderDataGraph_lock);
>> 485:   ClassLoaderDataGraph::classes_unloading_do(&on_unloading);
> 
> Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup.
> You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()

"Since you remove entries on unloading, I don't see any reason to have any concurrent cleanup."
Thank you, that is true. The only concurrent work required will be to grow the table.

"You do however need in the lookup code, some code that doesn't find the InstanceKlass if !ik->is_loader_alive()"

A precondition is that the code doing the lookup hold the ClassLoaderDataGraph_lock or is at a safepoint. Is that still the case? Would not purge_unloaded() take out the InstanceKlass from the table, as part of unloading, before !ik->is_loader_alive() is published to the outside world?

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From pliden at openjdk.java.net  Mon Sep 13 12:06:06 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 13 Sep 2021 12:06:06 GMT
Subject: RFR: 8273639: tests fail with "assert(_handle_mark_nesting > 1)
 failed: memory leak: allocating handle outside HandleMark"
Message-ID: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>

This is a fix for an unintended side-effect of JDK-8273482. The problem is that we need to have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint(). Before JDK-8273482, calls to ThreadStackTrace::dump_stack_at_safepoint()  were always done from the VMThread, which always has a HandleMark on the stack before evaluating a VM operation. After JDK-8273482, calls to this function can be made from WorkerThreads, which doesn't always have a HandleMark on its stack. The fix is simple, make sure we have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint().

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

Commit messages:
 - 8273639: tests fail with "assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark"

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

PR: https://git.openjdk.java.net/jdk/pull/5492

From dholmes at openjdk.java.net  Mon Sep 13 12:46:56 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Sep 2021 12:46:56 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <jJUF1uHTGq8sDTFKfeI6_tZPHtcdBCokzVkl5qIkBmE=.8b79573d-1bba-484a-8c6f-fc97fda06b84@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>
 <jJUF1uHTGq8sDTFKfeI6_tZPHtcdBCokzVkl5qIkBmE=.8b79573d-1bba-484a-8c6f-fc97fda06b84@github.com>
Message-ID: <pM1Me1eMcL0HePpNT-BfdgwD4ZgJrW_k5QkxXcs0eDc=.1408e1ff-db10-493f-bc37-7d75d895dd88@github.com>

On Fri, 10 Sep 2021 06:01:42 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsConstants.cpp line 61:
>> 
>>> 59: 
>>> 60: size_t get_cds_offset(const char* name) {
>>> 61:   for (int i = 0; i < (int)(sizeof(cds_offsets)/sizeof(cds_offsets[0])); i++) {
>> 
>> Can't we just define a size for the array and use that? It isn't really a dynamic/unknown quantity.
>
> The array size is known at compile time --- it is not dynamic but we do not need to manually count the size of the array this way. If define a size for the array, we need to count the number of items in the array to define the array size. We may add more items to the array --- just add items and don't need change anything else. Since total array memory size and array component size are known at compile time, so compiler will not generate code to calculate the size. How about this? 
> const int size =   (int)(sizeof(cds_offsets)/sizeof(cds_offsets[0]));
> for (int i = 0; i < size; i++) {
>   ...
> }

I always thought that was a hack way of determining an array size, not an approved method. :(

Don't worry just leave it as-is.

>> src/hotspot/share/cds/dynamicArchive.hpp line 45:
>> 
>>> 43: 
>>> 44: public:
>>> 45:   int _base_region_crc[MetaspaceShared::n_regions];
>> 
>> This looks like it should be private with either a public accessor or else a friend declaration for the client code.
>
> Let me try but I remember it does not work with constexpr initialization. This is why I move the data field to public not using the public accessor.

So we are trading off use of constexpr versus broken encapsulation? :( I can't say I understand the details here.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From stefank at openjdk.java.net  Mon Sep 13 13:41:32 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 13 Sep 2021 13:41:32 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>

On Thu, 9 Sep 2021 18:13:10 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

I saw the array size comments ...

src/hotspot/share/cds/cdsConstants.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #include <cstddef>

It is not stated in the style guide, but I think most files include the system headers after the HotSpot headers, separated by a blank line.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From stefank at openjdk.java.net  Mon Sep 13 13:41:34 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Mon, 13 Sep 2021 13:41:34 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <pM1Me1eMcL0HePpNT-BfdgwD4ZgJrW_k5QkxXcs0eDc=.1408e1ff-db10-493f-bc37-7d75d895dd88@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>
 <jJUF1uHTGq8sDTFKfeI6_tZPHtcdBCokzVkl5qIkBmE=.8b79573d-1bba-484a-8c6f-fc97fda06b84@github.com>
 <pM1Me1eMcL0HePpNT-BfdgwD4ZgJrW_k5QkxXcs0eDc=.1408e1ff-db10-493f-bc37-7d75d895dd88@github.com>
Message-ID: <pXLwawmytZ6Ux0iTTWb-TX8JDvR-OciZOPBhjKLS5jI=.ebc14e07-b17e-4f18-970f-25eccc7d764f@github.com>

On Mon, 13 Sep 2021 12:42:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The array size is known at compile time --- it is not dynamic but we do not need to manually count the size of the array this way. If define a size for the array, we need to count the number of items in the array to define the array size. We may add more items to the array --- just add items and don't need change anything else. Since total array memory size and array component size are known at compile time, so compiler will not generate code to calculate the size. How about this? 
>> const int size =   (int)(sizeof(cds_offsets)/sizeof(cds_offsets[0]));
>> for (int i = 0; i < size; i++) {
>>   ...
>> }
>
> I always thought that was a hack way of determining an array size, not an approved method. :(
> 
> Don't worry just leave it as-is.

We have functionality for this in globalDefinitions.hpp:

#define ARRAY_SIZE(array) sizeof(array_size_impl(array))

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From coleenp at openjdk.java.net  Mon Sep 13 14:01:17 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 14:01:17 GMT
Subject: RFR: 8273639: tests fail with "assert(_handle_mark_nesting > 1)
 failed: memory leak: allocating handle outside HandleMark"
In-Reply-To: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>
References: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>
Message-ID: <KJtEPVAsQ8sq42S8CcBZwRyZmad9i1Wtk1gBQxRklP0=.851d5639-f3d6-4174-8d9f-c649349be156@github.com>

On Mon, 13 Sep 2021 11:57:05 GMT, Per Liden <pliden at openjdk.org> wrote:

> This is a fix for an unintended side-effect of JDK-8273482. The problem is that we need to have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint(). Before JDK-8273482, calls to ThreadStackTrace::dump_stack_at_safepoint()  were always done from the VMThread, which always has a HandleMark on the stack before evaluating a VM operation. After JDK-8273482, calls to this function can be made from WorkerThreads, which doesn't always have a HandleMark on its stack. The fix is simple, make sure we have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint().

Looks good and trivial.  We should remove the HandleMark mechanism which is a leftover from when Metadata was in Handles.  There aren't many places where we have a lot of Handles that would benefit from the optimization of bulk cleanup of Handles and it's really easy to have unnecessary Handles that GC has to process.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5492

From minqi at openjdk.java.net  Mon Sep 13 15:59:50 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 13 Sep 2021 15:59:50 GMT
Subject: RFR: 8261455: Automatically generate the CDS archive if necessary
 [v2]
In-Reply-To: <AgL7Cv-ow_Gt8yEtUFJyMO0ovRRcPu2RvIysfp6Oqrk=.de5182f7-582d-4cdf-9e99-401bc5ba2911@github.com>
References: <3RvE2aINt6h4QvSPdW_G-wPIPm6wKkl7cVCvCQNrW5Y=.aae553c8-eaf2-4e03-9454-50f86ec0bd62@github.com>
 <AgL7Cv-ow_Gt8yEtUFJyMO0ovRRcPu2RvIysfp6Oqrk=.de5182f7-582d-4cdf-9e99-401bc5ba2911@github.com>
Message-ID: <Vp12gn-E2Dllas0wPjkJQ7mtHi1ChSqTQOkQaoudm2U=.166022ef-8152-4b82-aaa1-e9f52fa6c251@github.com>

On Sat, 14 Aug 2021 15:21:50 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> When shared archive (dynamic archive) failed to map due to damage of the archive file, dump/run jdk version mismatch or non-existence file etc, the new patch will automatically create a new shared archive if -XX:+AutoCreateSharedArchive specified with the name based on SharedArchiveFile.
>> 
>> Tests: tier1,tier2,tier3,tier4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed base:top related issue and add more tests

The work will continue after related small bug fixed first.

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

PR: https://git.openjdk.java.net/jdk/pull/5077

From rschmelter at openjdk.java.net  Mon Sep 13 16:25:59 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Mon, 13 Sep 2021 16:25:59 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
Message-ID: <jNtCCL_PNXSlmUiLKa_KG9-109xigHEd8tu-2VKn9Uw=.6e996caa-8c37-497b-a693-3573651e2620@github.com>

On Mon, 6 Sep 2021 08:03:22 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build error

The change seems OK so far, but I've found a few issues.

src/hotspot/share/services/attachListener.cpp line 255:

> 253:     HeapDumper dumper(live_objects_only /* request GC */);
> 254:     dumper.dump(path, out, (int)level, (uint)parallel_thread_num);
> 255:   }

The call signature for dump has changed, since it now takes an overwrite bool value after the compression level. This means that actually the number of parallel threads is not set but remains at the default value of 1. So the parallel case  is never executed currently.

src/hotspot/share/services/heapDumper.cpp line 1681:

> 1679:   };
> 1680: 
> 1681:   HeapDumpLargeObjectListElem* _head;

This should be volatile.

src/hotspot/share/services/heapDumper.cpp line 1682:

> 1680: 
> 1681:   HeapDumpLargeObjectListElem* _head;
> 1682:   uint _length;

I don't think the length is needed at all. You just have to know if the list is empty or not and that can be found out via the _head field.

src/hotspot/share/services/heapDumper.cpp line 1714:

> 1712:     }
> 1713:     HeapDumpLargeObjectListElem* entry = _head;
> 1714:     if (_head->_next != NULL) {

Why the check? Wouldn't you want _head to be NULL when the last entry was removed?

src/hotspot/share/services/heapDumper.cpp line 1717:

> 1715:       _head = _head->_next;
> 1716:     }
> 1717:     entry->_next = NULL;

I don't see why you would NULL out the _next field. The entry is deleted shortly after anyway.

src/hotspot/share/services/heapDumper.cpp line 1797:

> 1795:   if (o->is_instance()) {
> 1796:     InstanceKlass* ik = InstanceKlass::cast(o->klass());
> 1797:     size = DumperSupport::instance_size(ik);

Getting the size of an instance can be surprisingly expensive for classes with many static fields, since we iterate over all static fields of the class. So I would avoid having to calculate the size twice (here and when we are actually dump it). Maybe here it would just be enough to use o->size() * 8 as an upper limit value of the real size in the heap dump. After all practically no non-array object will ever we that large.

src/hotspot/share/services/heapDumper.cpp line 1822:

> 1820:    Monitor* _lock;
> 1821:    uint   _dumper_number;
> 1822:    uint   _waiting_number;

The _waiting_number doesn't seem to really have a purpose. No decision depends on it.

src/hotspot/share/services/heapDumper.cpp line 2448:

> 2446: // dump the large objects.
> 2447: void VM_HeapDumper::dump_large_objects(ObjectClosure* cl) {
> 2448:   if (_large_object_list->is_empty()) {

drain() should be able to handle an empyt list, so this check should not be needed.

src/hotspot/share/services/heapDumperCompression.cpp line 386:

> 384:   size_t tmp_max = 0;
> 385: 
> 386:   MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);

This is not thread safe if flush_external_buffer() or get_new_buffer() are called concurrently. But it seems to be Ok since flush_external_buffer() is only called with the _lock var of the parallel writer locked, so there is no contention. Is this correct?

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From mgronlun at openjdk.java.net  Mon Sep 13 17:12:49 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 13 Sep 2021 17:12:49 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v11]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:

 - remove rehashing and rely on default grow_hint for table resize
 - mtStatistics

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/fd86899f..62592daf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=09-10

  Stats: 258 lines in 6 files changed: 25 ins; 197 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

From mseledtsov at openjdk.java.net  Mon Sep 13 17:40:32 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 13 Sep 2021 17:40:32 GMT
Subject: RFR: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested [v3]
In-Reply-To: <zHCeTdeFGpJ_8nzaWrYrePqGQv7g6z6sYhcBzdKOD9U=.bea66154-206c-4116-8c6b-d3d2916550bc@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
 <zHCeTdeFGpJ_8nzaWrYrePqGQv7g6z6sYhcBzdKOD9U=.bea66154-206c-4116-8c6b-d3d2916550bc@github.com>
Message-ID: <G7-nLF1VrBmOyNRjAIPgclvFznvcU-XN1Nm8xZ4cR1Y=.2f244065-c655-4e4b-8b8f-bbf6e4fde1d7@github.com>

On Fri, 10 Sep 2021 21:18:23 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this addition of new testing:
>>   - new test for sending jcmd commands across container boundaries
>>   - updated existing sidecar test, enabling jcmd test case
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary UsePerfData per review feedback

Harold, Kevin, thank you for review.

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

PR: https://git.openjdk.java.net/jdk/pull/5368

From mseledtsov at openjdk.java.net  Mon Sep 13 17:40:35 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 13 Sep 2021 17:40:35 GMT
Subject: Integrated: JDK-8195809: [TESTBUG] jps and jcmd -l support for
 containers is not tested
In-Reply-To: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
References: <VqpJ8jAQye7UAIcTyIdjcfo-p0Bwv77ocl_lfMJXQwM=.f781bf05-5d5a-41e0-9199-b4cca62849f8@github.com>
Message-ID: <FahTqO9qH98oV4imN-C4bRVNpj3WardRD_5t8vxyaOY=.4c9fa96e-47dd-41ef-8122-7356c897ab54@github.com>

On Sat, 4 Sep 2021 00:03:14 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this addition of new testing:
>   - new test for sending jcmd commands across container boundaries
>   - updated existing sidecar test, enabling jcmd test case

This pull request has now been integrated.

Changeset: 7c26ddb5
Author:    Mikhailo Seledtsov <mseledtsov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7c26ddb575bb6f1161850c31a933d154ae8b96e3
Stats:     200 lines in 3 files changed: 193 ins; 2 del; 5 mod

8195809: [TESTBUG] jps and jcmd -l support for containers is not tested

Reviewed-by: hseigel, kevinw

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

PR: https://git.openjdk.java.net/jdk/pull/5368

From minqi at openjdk.java.net  Mon Sep 13 19:04:24 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 13 Sep 2021 19:04:24 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <pXLwawmytZ6Ux0iTTWb-TX8JDvR-OciZOPBhjKLS5jI=.ebc14e07-b17e-4f18-970f-25eccc7d764f@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>
 <jJUF1uHTGq8sDTFKfeI6_tZPHtcdBCokzVkl5qIkBmE=.8b79573d-1bba-484a-8c6f-fc97fda06b84@github.com>
 <pM1Me1eMcL0HePpNT-BfdgwD4ZgJrW_k5QkxXcs0eDc=.1408e1ff-db10-493f-bc37-7d75d895dd88@github.com>
 <pXLwawmytZ6Ux0iTTWb-TX8JDvR-OciZOPBhjKLS5jI=.ebc14e07-b17e-4f18-970f-25eccc7d764f@github.com>
Message-ID: <tnJQpMN7Ts4L48yR833Ew69Keh4KKe5xFpXqKPbHTXg=.55f15acf-b1e6-4bd4-a351-a683789e6389@github.com>

On Mon, 13 Sep 2021 13:35:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I always thought that was a hack way of determining an array size, not an approved method. :(
>> 
>> Don't worry just leave it as-is.
>
> We have functionality for this in globalDefinitions.hpp:
> 
> #define ARRAY_SIZE(array) sizeof(array_size_impl(array))

@stefank Thanks --- it saves code size.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From minqi at openjdk.java.net  Mon Sep 13 19:10:53 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 13 Sep 2021 19:10:53 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp
In-Reply-To: <pM1Me1eMcL0HePpNT-BfdgwD4ZgJrW_k5QkxXcs0eDc=.1408e1ff-db10-493f-bc37-7d75d895dd88@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>
 <jJUF1uHTGq8sDTFKfeI6_tZPHtcdBCokzVkl5qIkBmE=.8b79573d-1bba-484a-8c6f-fc97fda06b84@github.com>
 <pM1Me1eMcL0HePpNT-BfdgwD4ZgJrW_k5QkxXcs0eDc=.1408e1ff-db10-493f-bc37-7d75d895dd88@github.com>
Message-ID: <LLZHwlnAF9A4SApjoE5CfC9VekCZ94pxw5TbEKeu-O8=.5a4bd986-bb04-44af-b9f5-d9d546d8bb59@github.com>

On Mon, 13 Sep 2021 12:43:59 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Let me try but I remember it does not work with constexpr initialization. This is why I move the data field to public not using the public accessor.
>
> So we are trading off use of constexpr versus broken encapsulation? :( I can't say I understand the details here.

For constexpr array --- the initialization requires every item in the array must be initialized with const expression. I have rolled back the access change. By putting the global arrays offsets and constants inside CDSConstants, and making CDSConstants a friend class of the accessed class, we can avoid such changes. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From coleenp at openjdk.java.net  Mon Sep 13 20:18:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 20:18:52 GMT
Subject: RFR: 8273675: Remove unused Universe::_verify_in_progress flag
Message-ID: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>

This is a trivial change to remove an unused flag in class Universe.
Tested with tier1 on Oracle platforms.

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

Commit messages:
 - 8273675: Remove unused Universe::_verify_in_progress flag

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

PR: https://git.openjdk.java.net/jdk/pull/5501

From minqi at openjdk.java.net  Mon Sep 13 20:25:46 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 13 Sep 2021 20:25:46 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp [v2]
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <jYacE-bW6ds1AijNzPVqrkrcN1LOF7h1WupkMGIZICU=.f0708a6d-3e6d-43e3-a73f-7dc9a871f0f0@github.com>

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Make array of offsets and constants member of class CDSConstants and made CDSConstants a friend class of accessed classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5450/files
  - new: https://git.openjdk.java.net/jdk/pull/5450/files/30ede36e..7bb5ee2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=00-01

  Stats: 46 lines in 4 files changed: 14 ins; 8 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5450.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5450/head:pull/5450

PR: https://git.openjdk.java.net/jdk/pull/5450

From hseigel at openjdk.java.net  Mon Sep 13 20:30:58 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 13 Sep 2021 20:30:58 GMT
Subject: RFR: 8273675: Remove unused Universe::_verify_in_progress flag
In-Reply-To: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
References: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
Message-ID: <_fooOcAsJat0PlE-tHxL9L20DWtgoutTvlye41BA2rs=.998aa342-34c7-40ec-a6eb-5e2f8d609fdc@github.com>

On Mon, 13 Sep 2021 20:07:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove an unused flag in class Universe.
> Tested with tier1 on Oracle platforms.

Looks good and trivial.
Thanks, Harold

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

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5501

From coleenp at openjdk.java.net  Mon Sep 13 20:36:08 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 20:36:08 GMT
Subject: RFR: 8273675: Remove unused Universe::_verify_in_progress flag
In-Reply-To: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
References: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
Message-ID: <6bA3Fd5brrlQ0_yd30DF6hZmaZOUULn3I-bLGl3Pfxs=.15745fb1-a812-4ba4-8501-9ea2446a563e@github.com>

On Mon, 13 Sep 2021 20:07:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove an unused flag in class Universe.
> Tested with tier1 on Oracle platforms.

Thanks Harold!

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

PR: https://git.openjdk.java.net/jdk/pull/5501

From coleenp at openjdk.java.net  Mon Sep 13 20:39:59 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 13 Sep 2021 20:39:59 GMT
Subject: Integrated: 8273675: Remove unused Universe::_verify_in_progress flag
In-Reply-To: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
References: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
Message-ID: <JOMgnc0UH6qchz-Am5slx_Qlw_I-W1X0z2XOW3QqyeA=.19811d51-1b66-4a20-a308-90f446c9734b@github.com>

On Mon, 13 Sep 2021 20:07:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove an unused flag in class Universe.
> Tested with tier1 on Oracle platforms.

This pull request has now been integrated.

Changeset: 5095068d
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5095068d3ba411c56752716df8e35e4215885e1d
Stats:     13 lines in 2 files changed: 0 ins; 13 del; 0 mod

8273675: Remove unused Universe::_verify_in_progress flag

Reviewed-by: hseigel

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

PR: https://git.openjdk.java.net/jdk/pull/5501

From iklam at openjdk.java.net  Mon Sep 13 20:42:59 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 13 Sep 2021 20:42:59 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp [v2]
In-Reply-To: <LLZHwlnAF9A4SApjoE5CfC9VekCZ94pxw5TbEKeu-O8=.5a4bd986-bb04-44af-b9f5-d9d546d8bb59@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <z5kLfdqwRno8wxjpBj6XKO3-ZcxWfvt-i2VZuYKfBWw=.06d0fa58-251d-4647-8cf9-e59979e97d48@github.com>
 <jJUF1uHTGq8sDTFKfeI6_tZPHtcdBCokzVkl5qIkBmE=.8b79573d-1bba-484a-8c6f-fc97fda06b84@github.com>
 <pM1Me1eMcL0HePpNT-BfdgwD4ZgJrW_k5QkxXcs0eDc=.1408e1ff-db10-493f-bc37-7d75d895dd88@github.com>
 <LLZHwlnAF9A4SApjoE5CfC9VekCZ94pxw5TbEKeu-O8=.5a4bd986-bb04-44af-b9f5-d9d546d8bb59@github.com>
Message-ID: <AvtWhZYCIaucOqOzqXskqNyZ-hHc-sV6BlL97zs7OUM=.fc6ed460-290f-43d2-9400-42be3f08df50@github.com>

On Mon, 13 Sep 2021 19:07:30 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> So we are trading off use of constexpr versus broken encapsulation? :( I can't say I understand the details here.
>
> For constexpr array --- the initialization requires every item in the array must be initialized with const expression. I have rolled back the access change. By putting the global arrays offsets and constants inside CDSConstants, and making CDSConstants a friend class of the accessed class, we can avoid such changes. Thanks!

`_base_region_crc` should be private and `CDSConstants` should be a friend class of `DynamicArchiveHeader`

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From iklam at openjdk.java.net  Mon Sep 13 20:42:58 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 13 Sep 2021 20:42:58 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp [v2]
In-Reply-To: <jYacE-bW6ds1AijNzPVqrkrcN1LOF7h1WupkMGIZICU=.f0708a6d-3e6d-43e3-a73f-7dc9a871f0f0@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <jYacE-bW6ds1AijNzPVqrkrcN1LOF7h1WupkMGIZICU=.f0708a6d-3e6d-43e3-a73f-7dc9a871f0f0@github.com>
Message-ID: <jVWTCbz-61UdhOalzNuTFIfoAW8dxiCu3ULpHf_tVSQ=.f7e58dd0-d042-4df8-ac2e-5ee26cf4f51d@github.com>

On Mon, 13 Sep 2021 20:25:46 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make array of offsets and constants member of class CDSConstants and made CDSConstants a friend class of accessed classes

Changes requested by iklam (Reviewer).

src/hotspot/share/cds/cdsConstants.cpp line 49:

> 47:   { "dynamic_magic",                (int)CDS_DYNAMIC_ARCHIVE_MAGIC },
> 48:   { "int_size",                     sizeof(int)                    },
> 49:   { "CDSFileMapRegion_size",        sizeof(CDSFileMapRegion)       },

Should be `(int)sizeof(int)` because the type of `sizeof(...)` is implementation-defined. See https://en.cppreference.com/w/cpp/types/size_t

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From minqi at openjdk.java.net  Mon Sep 13 21:36:42 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 13 Sep 2021 21:36:42 GMT
Subject: RFR: 8271569: Rename cdsoffsets.cpp to cdsConstants.cpp [v2]
In-Reply-To: <jVWTCbz-61UdhOalzNuTFIfoAW8dxiCu3ULpHf_tVSQ=.f7e58dd0-d042-4df8-ac2e-5ee26cf4f51d@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <jYacE-bW6ds1AijNzPVqrkrcN1LOF7h1WupkMGIZICU=.f0708a6d-3e6d-43e3-a73f-7dc9a871f0f0@github.com>
 <jVWTCbz-61UdhOalzNuTFIfoAW8dxiCu3ULpHf_tVSQ=.f7e58dd0-d042-4df8-ac2e-5ee26cf4f51d@github.com>
Message-ID: <UqQWuK7Yxz8lQTd1tyovrR7n3O4svxrwBIUyHQgwcwI=.2b76cf1c-46b3-45a4-bcf2-154bee218f39@github.com>

On Mon, 13 Sep 2021 20:38:41 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make array of offsets and constants member of class CDSConstants and made CDSConstants a friend class of accessed classes
>
> src/hotspot/share/cds/cdsConstants.cpp line 49:
> 
>> 47:   { "dynamic_magic",                (int)CDS_DYNAMIC_ARCHIVE_MAGIC },
>> 48:   { "int_size",                     sizeof(int)                    },
>> 49:   { "CDSFileMapRegion_size",        sizeof(CDSFileMapRegion)       },
> 
> Should be `(int)sizeof(int)` because the type of `sizeof(...)` is implementation-defined. See https://en.cppreference.com/w/cpp/types/size_t

Now that all almost all (except for 'magic') with size_t, we should use name vs size_t in the struct and get functions, cast when return from vm in whiteBox.cpp.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Mon Sep 13 22:59:12 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 13 Sep 2021 22:59:12 GMT
Subject: RFR: 8273675: Remove unused Universe::_verify_in_progress flag
In-Reply-To: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
References: <0g1o8QrgLveO9E2Mfag25O0LtISf4YUSvRgNJhy4jiY=.105f031d-c523-4c1b-a23e-1673a2bba544@github.com>
Message-ID: <3rM2FwEjaTuC2DftjrLwO8_FdU2EaZFSnH7xyH5gwUE=.7386bdf1-40f2-4839-909e-8e2941e258c4@github.com>

On Mon, 13 Sep 2021 20:07:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This is a trivial change to remove an unused flag in class Universe.
> Tested with tier1 on Oracle platforms.

Thanks for splitting this part out Coleen!

David

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

PR: https://git.openjdk.java.net/jdk/pull/5501

From minqi at openjdk.java.net  Mon Sep 13 23:12:19 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 13 Sep 2021 23:12:19 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v3]
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <IYykHUCu8_IFVEjKnrTMp4An36UnMKBhcEEqctkZYQE=.196af64e-e52a-4455-9c88-d96e98ed917e@github.com>

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Rollled back _base_region_crc to private, changed CDSConst's value from type int to size_t

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5450/files
  - new: https://git.openjdk.java.net/jdk/pull/5450/files/7bb5ee2e..c290e7c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=01-02

  Stats: 25 lines in 3 files changed: 2 ins; 2 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5450.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5450/head:pull/5450

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Tue Sep 14 00:53:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Sep 2021 00:53:09 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v3]
In-Reply-To: <IYykHUCu8_IFVEjKnrTMp4An36UnMKBhcEEqctkZYQE=.196af64e-e52a-4455-9c88-d96e98ed917e@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <IYykHUCu8_IFVEjKnrTMp4An36UnMKBhcEEqctkZYQE=.196af64e-e52a-4455-9c88-d96e98ed917e@github.com>
Message-ID: <4nBhGQuePMa50TjDO5tkirpP9pwUn5zRqiHmbMjMzfM=.9af4475a-e97b-491b-b289-44724f5cfd73@github.com>

On Mon, 13 Sep 2021 23:12:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rollled back _base_region_crc to private, changed CDSConst's value from type int to size_t

src/hotspot/share/cds/cdsConstants.hpp line 37:

> 35:  public:
> 36:   static CDSConst offsets[];
> 37:   static CDSConst constants[];

Why are these public?

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Tue Sep 14 02:21:06 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Sep 2021 02:21:06 GMT
Subject: RFR: 8273639: tests fail with "assert(_handle_mark_nesting > 1)
 failed: memory leak: allocating handle outside HandleMark"
In-Reply-To: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>
References: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>
Message-ID: <SRpqwJ9IGLYqSChEKBjC4hP7a2bO5qA-6PFNFGz8XQg=.ad112d46-d172-4131-954e-ade7028c4b25@github.com>

On Mon, 13 Sep 2021 11:57:05 GMT, Per Liden <pliden at openjdk.org> wrote:

> This is a fix for an unintended side-effect of JDK-8273482. The problem is that we need to have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint(). Before JDK-8273482, calls to ThreadStackTrace::dump_stack_at_safepoint()  were always done from the VMThread, which always has a HandleMark on the stack before evaluating a VM operation. After JDK-8273482, calls to this function can be made from WorkerThreads, which doesn't always have a HandleMark on its stack. The fix is simple, make sure we have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint().

Looks good.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5492

From minqi at openjdk.java.net  Tue Sep 14 03:04:14 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Sep 2021 03:04:14 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v4]
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <Ywokgs0nerBvmDARl3jBW2MMWAGC2m0ud4-RiN8oMPk=.cfb90679-8b60-4394-a642-135183891087@github.com>

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  offsets and constants should be private

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5450/files
  - new: https://git.openjdk.java.net/jdk/pull/5450/files/c290e7c1..4f045e35

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From minqi at openjdk.java.net  Tue Sep 14 03:16:05 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Sep 2021 03:16:05 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v3]
In-Reply-To: <4nBhGQuePMa50TjDO5tkirpP9pwUn5zRqiHmbMjMzfM=.9af4475a-e97b-491b-b289-44724f5cfd73@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <IYykHUCu8_IFVEjKnrTMp4An36UnMKBhcEEqctkZYQE=.196af64e-e52a-4455-9c88-d96e98ed917e@github.com>
 <4nBhGQuePMa50TjDO5tkirpP9pwUn5zRqiHmbMjMzfM=.9af4475a-e97b-491b-b289-44724f5cfd73@github.com>
Message-ID: <TMCaNl0RibhaXtZpghJikt8iCm0R1MOVYv0mZFZIDt8=.cef26b5a-d76f-46c7-933e-f658d151ef0e@github.com>

On Tue, 14 Sep 2021 00:50:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rollled back _base_region_crc to private, changed CDSConst's value from type int to size_t
>
> src/hotspot/share/cds/cdsConstants.hpp line 37:
> 
>> 35:  public:
>> 36:   static CDSConst offsets[];
>> 37:   static CDSConst constants[];
> 
> Why are these public?

Should be private, thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Tue Sep 14 04:22:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Sep 2021 04:22:04 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v4]
In-Reply-To: <Ywokgs0nerBvmDARl3jBW2MMWAGC2m0ud4-RiN8oMPk=.cfb90679-8b60-4394-a642-135183891087@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <Ywokgs0nerBvmDARl3jBW2MMWAGC2m0ud4-RiN8oMPk=.cfb90679-8b60-4394-a642-135183891087@github.com>
Message-ID: <Asackpqv3FlH2fElluK2Fam2AInjIXIv2Zrcx4tF9fc=.7f62f244-acaa-4f4a-8e02-93595f986edb@github.com>

On Tue, 14 Sep 2021 03:04:14 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   offsets and constants should be private

Hi Yumin,

Updates seem okay to me. One query below.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Tue Sep 14 04:22:05 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 14 Sep 2021 04:22:05 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v4]
In-Reply-To: <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
Message-ID: <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>

On Mon, 13 Sep 2021 13:33:19 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   offsets and constants should be private
>
> src/hotspot/share/cds/cdsConstants.cpp line 26:
> 
>> 24: 
>> 25: #include "precompiled.hpp"
>> 26: #include <cstddef>
> 
> It is not stated in the style guide, but I think most files include the system headers after the HotSpot headers, separated by a blank line.

Is this even needed now? I don't see it being used.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From ccheung at openjdk.java.net  Tue Sep 14 05:15:13 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 14 Sep 2021 05:15:13 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump
In-Reply-To: <7tS6Rp9DRCfFZ2EbuBYXk8bfvOBDP1_j51jkaBb8k3E=.1e5c76e1-a5a4-4b26-8252-f57b4a5838b8@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
 <7tS6Rp9DRCfFZ2EbuBYXk8bfvOBDP1_j51jkaBb8k3E=.1e5c76e1-a5a4-4b26-8252-f57b4a5838b8@github.com>
Message-ID: <tANFHz403vwkmiwIba3sHXMPYQ9TRQrMlbrx_ADrT1I=.5d7745e0-0412-4a82-9999-c5023d63793f@github.com>

On Fri, 10 Sep 2021 22:19:11 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
>> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
>> 
>> Passed tiers 1 - 4 testing.
>
> src/hotspot/share/cds/classListParser.cpp line 476:
> 
>> 474:   }
>> 475: 
>> 476:   // This tells JVM_FindLoadedClass to not find this class.
> 
> This comment can be deleted.
> 
> The class `k` used to be defined by the boot loader. As a result, when `JVM_FindLoadedClass` looked up a class in the boot/platform/app loaders, it may inadvertently find `k`.
> 
> However, after this PR, `k` is no longer defined by the boot loader.

Removed the comment.

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From ysuenaga at openjdk.java.net  Tue Sep 14 05:18:10 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 14 Sep 2021 05:18:10 GMT
Subject: Integrated: 8273471: Add foldmultilines to UL for stdout/err
In-Reply-To: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
References: <p0nZDswaESbAnHiD6rGOs63jWz1_a_wkp2DQ1UfuRA4=.8578e606-a7c6-4d20-8e75-810e6705b9ac@github.com>
Message-ID: <hVPkbadUMJgf6NoWmRP1ZoJB2d8hynsJ-jTOtCeS3Ic=.bcb253b6-4e3e-4e99-b224-482f86b83d19@github.com>

On Wed, 8 Sep 2021 06:12:21 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> We've introduced `foldmultilines` to UL in [JDK-8271186](https://bugs.openjdk.java.net/browse/JDK-8271186) (PR #4885 ) to replace newline characters within a multiline log event with the character sequence '' and 'n'. It helps to work log shippers.
> 
> `foldmultilines` supports file output only. It is useful if it affects to stdout/err output because many container applications would redirect logs to stdout.
> 
> `foldmultilines` will be enabled after option processing, so note that the log what happens before it isn't folded. AFAICS following logs might happen.
> They are not practical concern because the log which happens before option processing is determinative and does not have newline char (at least now), so I think we can excuse they are not folded.
> 
> 
> share/logging/logConfiguration.cpp:379:        log_error(logging)("Missing terminating quote in -Xlog option '%s'", str);
> share/logging/logConfiguration.cpp:397:    log_warning(logging)("Ignoring excess -Xlog options: "%s"", str);
> 
> share/prims/jvmtiTrace.cpp:91:      log_warning(arguments)("-XX:+TraceJVMTI specified, "
> 
> share/runtime/os.cpp:700:    log_warning(malloc, free)("os::malloc caught, " SIZE_FORMAT " bytes --> " PTR_FORMAT, size, p2i(ptr));
> share/runtime/os.cpp:752:    log_warning(malloc, free)("os::realloc caught " PTR_FORMAT, p2i(memblock));
> share/runtime/os.cpp:788:    log_warning(malloc, free)("os::free caught " PTR_FORMAT, p2i(memblock));
> 
> 
> I checked them with `$ grep -nrE '(warning|error)' * | grep -i log | grep -vwE '(cds|gc|safepoint|thread|codecache|symboltable|stringtable|jfr|jvmti|jni|container|pagesize|metaspace|exceptions|nmt|attach|class|handshake|monitorinflation)' | grep -vwE '(log_info|log_debug)'`
> 
> In addition, we might see following logs which relate to UL:
> 
> 
> [0.000s][error][logging] Error opening log file '/all-info.log': Permission denied
> [0.000s][error][logging] Invalid tag 'aaa' in log selection.
> [0.000s][error][logging] Invalid level 'aaa' in log selection.
> [0.012s][error][logging] Invalid option 'aaa' for log output (file=all-info.log).
> [0.021s][error][logging] Unable to log to file all-info.log with log file rotation: all-info.log is not a regular file
> [0.012s][error][logging] Initialization of output 'file=all-info.log' using options 'aaa=bbb' failed.

This pull request has now been integrated.

Changeset: 8d73ee68
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8d73ee684a47fa6a10995a19a431062b54c7eb27
Stats:     130 lines in 7 files changed: 87 ins; 20 del; 23 mod

8273471: Add foldmultilines to UL for stdout/err

Reviewed-by: dholmes, iklam

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

PR: https://git.openjdk.java.net/jdk/pull/5407

From ccheung at openjdk.java.net  Tue Sep 14 05:21:11 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 14 Sep 2021 05:21:11 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump
In-Reply-To: <7tS6Rp9DRCfFZ2EbuBYXk8bfvOBDP1_j51jkaBb8k3E=.1e5c76e1-a5a4-4b26-8252-f57b4a5838b8@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
 <7tS6Rp9DRCfFZ2EbuBYXk8bfvOBDP1_j51jkaBb8k3E=.1e5c76e1-a5a4-4b26-8252-f57b4a5838b8@github.com>
Message-ID: <yUqsvGpAzY08uQ_0U7BtnUsp37fPVbUg6A__YpfP3q8=.41e27edd-d96f-46e2-8a7a-00d4fe2901ba@github.com>

On Fri, 10 Sep 2021 22:26:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I think we should try to decouple the loading of unregistered classes from ClassLoader/ClassloaderExt. Maybe these new functions can be placed in a new file, shared/cds/unregisteredClasses.cpp, and the API entry point would be `UnregisteredClasses::load_class(name, path)`.

I've moved the new code to unregistedClasses.[c|h]pp.
> 
> Also, `ClassLoaderExt::find_classpath_entry_from_cache` shouldn't be needed anymore. If the JAR file doesn't exist, URLClassLoader will throw an exception, so we don't need to create a ClassPathEntry just to check for the JAR file's existence.

As we've discussed off-line, after removing the `ClassLoaderExt::find_classpath_entry_from_cache`, the calculation of the length and crc of the ClassFileSteam will be performed in `jvm_define_class_common()`.
> 
> I wonder if there's any code in classLoader.cpp that was used only for supporting the loading of unregistered classes. If so, it can be removed, too.

I don't see any functions in classLoader.cpp could be removed. However, I think the `ClassLoader::record_result()` could be simplified since it is no longer called with unregistered classes. I'd prefer handle the simplification in a follow-up bug.

> src/hotspot/share/classfile/classLoaderExt.cpp line 299:
> 
>> 297: class URLClassLoaderTable : public ResourceHashtable<
>> 298:   Symbol*, Handle,
>> 299:   7, // prime number
> 
> I think 7 is too small. Maybe 137?

Ok. I've increased it to 137.

> src/hotspot/share/classfile/classLoaderExt.cpp line 327:
> 
>> 325: Handle ClassLoaderExt::create_and_add_url_classloader(Symbol* path, TRAPS) {
>> 326:   Handle url_classloader = create_url_classloader(path, CHECK_NH);
>> 327:   bool added = _url_classloader_table->put(path, url_classloader);
> 
> added is not used. Did you want to assert that `added == true`?
> 
> I think it's better to move the body of this function to line 342. Then it would be clear that the entry doesn't exist (and there's no need to check for `added`).

Modified per your suggestions and I don't need to keep the bool variable.

> src/hotspot/share/classfile/classLoaderExt.cpp line 336:
> 
>> 334:     _url_classloader_table = new (ResourceObj::C_HEAP, mtClass)URLClassLoaderTable();
>> 335:     Handle url_classloader = create_and_add_url_classloader(path, CHECK_NH);
>> 336:     return url_classloader;
> 
> I think the above 2 lines should be removed and the creation should be done in a single place. This means `_url_classloader_table->get()` would be unnecessarily called when the table is created, but I think that's OK since this happens only once.

Done.

> src/hotspot/share/classfile/classLoaderExt.cpp line 368:
> 
>> 366:   assert(result.get_type() == T_OBJECT, "just checking");
>> 367:   oop obj = result.get_oop();
>> 368:   InstanceKlass* k = InstanceKlass::cast(java_lang_Class::as_Klass(obj));
> 
> No need for the temp variable `k` since it's immediately returned.

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From ccheung at openjdk.java.net  Tue Sep 14 05:24:52 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Tue, 14 Sep 2021 05:24:52 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v2]
In-Reply-To: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
Message-ID: <CdQDRWZmipqBmLh89WrfZYjdjdeyNGor0yxctIj6tQQ=.39cddcd0-8ff0-4a9a-bee5-2e79c0826b4b@github.com>

> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5458/files
  - new: https://git.openjdk.java.net/jdk/pull/5458/files/cf1fd7a4..781a9ad9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=00-01

  Stats: 361 lines in 7 files changed: 182 ins; 174 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5458.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5458/head:pull/5458

PR: https://git.openjdk.java.net/jdk/pull/5458

From stefank at openjdk.java.net  Tue Sep 14 06:28:12 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 14 Sep 2021 06:28:12 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v4]
In-Reply-To: <Ywokgs0nerBvmDARl3jBW2MMWAGC2m0ud4-RiN8oMPk=.cfb90679-8b60-4394-a642-135183891087@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <Ywokgs0nerBvmDARl3jBW2MMWAGC2m0ud4-RiN8oMPk=.cfb90679-8b60-4394-a642-135183891087@github.com>
Message-ID: <46BqyqUOhUQh7HE9rQFv4FOiIsCMXctbRpw5zxzpPHU=.02be90bb-fb0d-48de-99ec-c933589c8168@github.com>

On Tue, 14 Sep 2021 03:04:14 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   offsets and constants should be private

Changes requested by stefank (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From stefank at openjdk.java.net  Tue Sep 14 06:28:13 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 14 Sep 2021 06:28:13 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v4]
In-Reply-To: <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
 <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>
Message-ID: <G6xYYIIgxamhJJ0AQDYT7p2-pUBf-irBAFBSl628H9I=.33393e35-33ac-43f5-9ecd-561e908218e6@github.com>

On Tue, 14 Sep 2021 04:18:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/cds/cdsConstants.cpp line 26:
>> 
>>> 24: 
>>> 25: #include "precompiled.hpp"
>>> 26: #include <cstddef>
>> 
>> It is not stated in the style guide, but I think most files include the system headers after the HotSpot headers, separated by a blank line.
>
> Is this even needed now? I don't see it being used.

To be clear, the layout that I'd like to see is:

#include "precompiled.hpp"
#include "cds.hpp"
...
#include "cds/filemap.hpp"

#include <cstddef>


However, I think the more appropriate change is to include globalDefinitions.hpp instead of explicitly including cstddef.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From pliden at openjdk.java.net  Tue Sep 14 08:42:11 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 14 Sep 2021 08:42:11 GMT
Subject: RFR: 8273639: tests fail with "assert(_handle_mark_nesting > 1)
 failed: memory leak: allocating handle outside HandleMark"
In-Reply-To: <KJtEPVAsQ8sq42S8CcBZwRyZmad9i1Wtk1gBQxRklP0=.851d5639-f3d6-4174-8d9f-c649349be156@github.com>
References: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>
 <KJtEPVAsQ8sq42S8CcBZwRyZmad9i1Wtk1gBQxRklP0=.851d5639-f3d6-4174-8d9f-c649349be156@github.com>
Message-ID: <ZmF1YNV_QCMzHeZNuSt2sLOKAqPvnHX4oZSGgG_rPE4=.a41feab1-14a9-4636-b354-8ddec640293b@github.com>

On Mon, 13 Sep 2021 13:48:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is a fix for an unintended side-effect of JDK-8273482. The problem is that we need to have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint(). Before JDK-8273482, calls to ThreadStackTrace::dump_stack_at_safepoint()  were always done from the VMThread, which always has a HandleMark on the stack before evaluating a VM operation. After JDK-8273482, calls to this function can be made from WorkerThreads, which doesn't always have a HandleMark on its stack. The fix is simple, make sure we have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint().
>
> Looks good and trivial.  We should remove the HandleMark mechanism which is a leftover from when Metadata was in Handles.  There aren't many places where we have a lot of Handles that would benefit from the optimization of bulk cleanup of Handles and it's really easy to have unnecessary Handles that GC has to process.

Thanks for reviewing @coleenp and @dholmes-ora!

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

PR: https://git.openjdk.java.net/jdk/pull/5492

From pliden at openjdk.java.net  Tue Sep 14 08:42:12 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 14 Sep 2021 08:42:12 GMT
Subject: Integrated: 8273639: tests fail with "assert(_handle_mark_nesting >
 1) failed: memory leak: allocating handle outside HandleMark"
In-Reply-To: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>
References: <-ZR4QFDz_0QatpN-nuJnzKSBQJ6jUZf0Qp3ZPOHJwUQ=.2315aca1-f4db-401f-be08-56bf41859dc4@github.com>
Message-ID: <fZvLFd-gk18VGtMcFhOeP-HML6j1tKOD2GmbgCcuobM=.83e2e4a3-f8a1-48ff-8a97-33ed8a3c5f52@github.com>

On Mon, 13 Sep 2021 11:57:05 GMT, Per Liden <pliden at openjdk.org> wrote:

> This is a fix for an unintended side-effect of JDK-8273482. The problem is that we need to have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint(). Before JDK-8273482, calls to ThreadStackTrace::dump_stack_at_safepoint()  were always done from the VMThread, which always has a HandleMark on the stack before evaluating a VM operation. After JDK-8273482, calls to this function can be made from WorkerThreads, which doesn't always have a HandleMark on its stack. The fix is simple, make sure we have a HandleMark on the stack before calling ThreadStackTrace::dump_stack_at_safepoint().

This pull request has now been integrated.

Changeset: f5272899
Author:    Per Liden <pliden at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f52728993dc8f61a537b899ed0c47d83ca594738
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8273639: tests fail with "assert(_handle_mark_nesting > 1) failed: memory leak: allocating handle outside HandleMark"

Reviewed-by: coleenp, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5492

From shade at openjdk.java.net  Tue Sep 14 10:19:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 14 Sep 2021 10:19:10 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type
 mismatch [v2]
In-Reply-To: <veLkydGKyG0Uz0e1YQOW77iapCYtEU1oanVv_5rDRv4=.6d910936-0ab0-4d9e-b364-1ba9fe699e05@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
 <veLkydGKyG0Uz0e1YQOW77iapCYtEU1oanVv_5rDRv4=.6d910936-0ab0-4d9e-b364-1ba9fe699e05@github.com>
Message-ID: <S_DEOyK-L6IFp4zQdFTla-gXuTcK34515mOVvwOewcw=.4e90a2a1-1be6-433e-b816-692aa78ea853@github.com>

On Mon, 13 Sep 2021 08:05:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This is actually caught by `-Werror=format` that is enabled by default.
>> 
>> 
>> $  sh ./configure --with-debug-level=slowdebug --with-boot-jdk=/home/shade/Install/jdk16-16.0.2-ea/ --openjdk-target=sparc64-linux-gnu --with-sysroot=/chroots/sparc64/ --with-jvm-variants=zero
>> $ make images
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comments

All right, I suppose everyone is happy with this patch? I'll be integrating it soon.

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From shade at openjdk.java.net  Tue Sep 14 10:19:44 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 14 Sep 2021 10:19:44 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero [v2]
In-Reply-To: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
Message-ID: <S_1FaQmZGkYRSAwUy6xi-_xrqhuzyHUJbM8AOZSo6_8=.df6bfe38-691e-4495-86fd-961afdf805ee@github.com>

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

Aleksey Shipilev 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 JDK-8273373-zero-initial-stack
 - Coming up with a more limited fix
 - Merge branch 'master' into JDK-8273373-zero-initial-stack
 - Merge branch 'master' into JDK-8273373-zero-initial-stack
 - Fix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5376/files
  - new: https://git.openjdk.java.net/jdk/pull/5376/files/e6545c1e..29021f40

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5376&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5376&range=00-01

  Stats: 13877 lines in 610 files changed: 8641 ins; 3090 del; 2146 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5376/head:pull/5376

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Tue Sep 14 10:52:32 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 14 Sep 2021 10:52:32 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero [v3]
In-Reply-To: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
Message-ID: <2cK0WbflRssf_7MZCryUcH6pDf69wdHUBgF1rFpMefw=.be738df1-dad2-4c92-b510-44b0df5be49c@github.com>

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

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

  Even more conservative patch

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5376/files
  - new: https://git.openjdk.java.net/jdk/pull/5376/files/29021f40..b8b5774c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5376&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5376&range=01-02

  Stats: 67 lines in 1 file changed: 24 ins; 16 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5376/head:pull/5376

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Tue Sep 14 10:52:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 14 Sep 2021 10:52:40 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero [v2]
In-Reply-To: <S_1FaQmZGkYRSAwUy6xi-_xrqhuzyHUJbM8AOZSo6_8=.df6bfe38-691e-4495-86fd-961afdf805ee@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <S_1FaQmZGkYRSAwUy6xi-_xrqhuzyHUJbM8AOZSo6_8=.df6bfe38-691e-4495-86fd-961afdf805ee@github.com>
Message-ID: <CK2-Lll_mx6A37cwAa0XRuDu0dxsy6Tpi2fFwVdyjuk=.b5f0ee25-935f-4f8a-bb9f-c7bb44339693@github.com>

On Tue, 14 Sep 2021 10:19:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion.
>> 
>> Additional testing:
>>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)
>
> Aleksey Shipilev 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 JDK-8273373-zero-initial-stack
>  - Coming up with a more limited fix
>  - Merge branch 'master' into JDK-8273373-zero-initial-stack
>  - Merge branch 'master' into JDK-8273373-zero-initial-stack
>  - Fix

I pushed the most conservative version I could think of now. Debian folks seem to also patch this method for HPPA: it seems to have unusual stack arrangements too, so I left the original method body as untouched as possible. This still makes gtests happier for Zero.

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From ihse at openjdk.java.net  Tue Sep 14 11:32:15 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Sep 2021 11:32:15 GMT
Subject: Integrated: 8256977: Bump minimum GCC from 5.x to 6 for JDK
In-Reply-To: <GRT9YAPpauCay5CaUVeJDzqGExdbqy1r4xcVODFfIgU=.6a0cb3b1-a383-4561-8183-e2d16b4d9a1b@github.com>
References: <GRT9YAPpauCay5CaUVeJDzqGExdbqy1r4xcVODFfIgU=.6a0cb3b1-a383-4561-8183-e2d16b4d9a1b@github.com>
Message-ID: <ZGPED5LDqe6XtCKSTczbaoCnwtNmup5ah-RXE_-xMZE=.5ae76570-25d5-428e-92a5-9f6af3deb581@github.com>

On Thu, 9 Sep 2021 19:28:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The minimum acceptable version is raised from 5 to 6. There were no objections on the mailing list for doing so in the mainline, see https://mail.openjdk.java.net/pipermail/build-dev/2021-August/031899.html.
> 
> This patch also reverts the workaround that was introduced in JDK-8252797 to support gcc 5.x.

This pull request has now been integrated.

Changeset: ed7789d6
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ed7789d6a08bcf5e49907389c6c36a09e88e852a
Stats:     5 lines in 2 files changed: 0 ins; 4 del; 1 mod

8256977: Bump minimum GCC from 5.x to 6 for JDK

Reviewed-by: erikj, shade

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

PR: https://git.openjdk.java.net/jdk/pull/5452

From ihse at openjdk.java.net  Tue Sep 14 11:37:58 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 14 Sep 2021 11:37:58 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
Message-ID: <_RzxWBDAsjsGgktVG8WL_0Xhgl894b6LXeb33cQGowM=.37460cd8-7b3c-4f44-b677-fc05a641be96@github.com>

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero build
>  - [x] Linux x86_64 Zero bootcycle-images
>  - [ ] Linux x86_64 Zero `tier1`

I'm changing my response to "approve". I agree that we can change zero only in this patch to facilitate backporting, and fix the remaining odds and ends in a separate PR.

And also let me be clear that I see no reason to delay pushing this any further. Everyone who has any vested interest in zero has had ample chance to comment on the PR.

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

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5440

From stuefe at openjdk.java.net  Tue Sep 14 12:12:07 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 14 Sep 2021 12:12:07 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero [v3]
In-Reply-To: <2cK0WbflRssf_7MZCryUcH6pDf69wdHUBgF1rFpMefw=.be738df1-dad2-4c92-b510-44b0df5be49c@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <2cK0WbflRssf_7MZCryUcH6pDf69wdHUBgF1rFpMefw=.be738df1-dad2-4c92-b510-44b0df5be49c@github.com>
Message-ID: <HvDrp6xFUcQuweuiysAl7kQB_0Cyn75Mli8mOFHTcjA=.7725c4fe-ec91-482b-ab93-7c3f4c3f76a4@github.com>

On Tue, 14 Sep 2021 10:52:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion.
>> 
>> Additional testing:
>>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more conservative patch

Looks good

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5376

From sgehwolf at openjdk.java.net  Tue Sep 14 12:47:11 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 14 Sep 2021 12:47:11 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
Message-ID: <_qfv6SEbfuo5um8s87v9BLlw7gwLdl-MdDbGvPZOR3g=.23f2ba5c-fc04-46bd-b167-2b027e88eae6@github.com>

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero build
>  - [x] Linux x86_64 Zero bootcycle-images
>  - [ ] Linux x86_64 Zero `tier1`

Looks fine to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5440

From lzang at openjdk.java.net  Tue Sep 14 14:20:15 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 14 Sep 2021 14:20:15 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <jNtCCL_PNXSlmUiLKa_KG9-109xigHEd8tu-2VKn9Uw=.6e996caa-8c37-497b-a693-3573651e2620@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <jNtCCL_PNXSlmUiLKa_KG9-109xigHEd8tu-2VKn9Uw=.6e996caa-8c37-497b-a693-3573651e2620@github.com>
Message-ID: <R1s4RQOX7UuJ0X3DgZQQhRGrYYXOl8PJCtZpvf3USVw=.9efeeebf-90ae-4f8d-9278-124c7519aaa2@github.com>

On Wed, 8 Sep 2021 13:39:08 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix build error
>
> src/hotspot/share/services/attachListener.cpp line 255:
> 
>> 253:     HeapDumper dumper(live_objects_only /* request GC */);
>> 254:     dumper.dump(path, out, (int)level, (uint)parallel_thread_num);
>> 255:   }
> 
> The call signature for dump has changed, since it now takes an overwrite bool value after the compression level. This means that actually the number of parallel threads is not set but remains at the default value of 1. So the parallel case  is never executed currently.

The parallel threads number is set to `MAX2<uint>(1, (uint)os::initial_active_processor_count() * 3 / 8);` after the change.

> src/hotspot/share/services/heapDumperCompression.cpp line 386:
> 
>> 384:   size_t tmp_max = 0;
>> 385: 
>> 386:   MonitorLocker ml(_lock, Mutex::_no_safepoint_check_flag);
> 
> This is not thread safe if flush_external_buffer() or get_new_buffer() are called concurrently. But it seems to be Ok since flush_external_buffer() is only called with the _lock var of the parallel writer locked, so there is no contention. Is this correct?

Yes, it is correct.

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Tue Sep 14 14:23:10 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 14 Sep 2021 14:23:10 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
Message-ID: <PITllQ3EAS1NIZSI6BwfDX8qWLBarXsSlbU7BZpxrsk=.1439a545-243a-4984-a137-46d4d4debafd@github.com>

On Wed, 8 Sep 2021 05:02:18 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix build error
>
> I will start reviewing this today.

Hi Ralf @schmelter-sap , 
    Thanks for your review and comments!  The change is conflict with latest master, so I will rebase it first and then fix the issue you mentioned.

BRs,
Lin

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From mbaesken at openjdk.java.net  Tue Sep 14 14:27:36 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Sep 2021 14:27:36 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v3]
In-Reply-To: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
Message-ID: <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
> 
> Best regards, Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Simplify coding following Severins advice

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5437/files
  - new: https://git.openjdk.java.net/jdk/pull/5437/files/422aef68..afe0efd4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=01-02

  Stats: 31 lines in 6 files changed: 1 ins; 27 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437

PR: https://git.openjdk.java.net/jdk/pull/5437

From mbaesken at openjdk.java.net  Tue Sep 14 14:27:40 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 14 Sep 2021 14:27:40 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v2]
In-Reply-To: <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com>
Message-ID: <EnTndH5h2bTioyh3mr8CtCmH_GV7pTqAT5jXTiIkIUE=.ac55df5e-11ed-49f4-8a6e-48a1d187188a@github.com>

On Fri, 10 Sep 2021 11:07:52 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8266490
>> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
>> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
>> that would be helpful too and can be added to the OSContainer API .
>> pids.current :
>> A read-only single value file which exists on all cgroups.
>> The number of processes currently in the cgroup and its descendants.
>> 
>> Best regards, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Some simplifications and test adjustment suggested by Severin

Hi Severin, I adjusted my change following your latest comments.

Thanks, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From lzang at openjdk.java.net  Tue Sep 14 14:35:18 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 14 Sep 2021 14:35:18 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <jNtCCL_PNXSlmUiLKa_KG9-109xigHEd8tu-2VKn9Uw=.6e996caa-8c37-497b-a693-3573651e2620@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <jNtCCL_PNXSlmUiLKa_KG9-109xigHEd8tu-2VKn9Uw=.6e996caa-8c37-497b-a693-3573651e2620@github.com>
Message-ID: <gBcgEi3-2QDbAliLU63VA_3anSXqSWsAymU6SsMtZwE=.12700f20-91f1-4074-a100-7fa303c38509@github.com>

On Mon, 13 Sep 2021 16:12:48 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix build error
>
> src/hotspot/share/services/heapDumper.cpp line 1797:
> 
>> 1795:   if (o->is_instance()) {
>> 1796:     InstanceKlass* ik = InstanceKlass::cast(o->klass());
>> 1797:     size = DumperSupport::instance_size(ik);
> 
> Getting the size of an instance can be surprisingly expensive for classes with many static fields, since we iterate over all static fields of the class. So I would avoid having to calculate the size twice (here and when we are actually dump it). Maybe here it would just be enough to use o->size() * 8 as an upper limit value of the real size in the heap dump. After all practically no non-array object will ever we that large.

Good suggestion! I didn't realize that o->size() * 8 can be used as an upper limit.

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From shade at openjdk.java.net  Tue Sep 14 15:52:09 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 14 Sep 2021 15:52:09 GMT
Subject: RFR: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero [v3]
In-Reply-To: <2cK0WbflRssf_7MZCryUcH6pDf69wdHUBgF1rFpMefw=.be738df1-dad2-4c92-b510-44b0df5be49c@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
 <2cK0WbflRssf_7MZCryUcH6pDf69wdHUBgF1rFpMefw=.be738df1-dad2-4c92-b510-44b0df5be49c@github.com>
Message-ID: <nikXD7RMtrravPlubzqD39VdY-6NlhUjc1Hkdi1kjpM=.4d66616b-918f-407f-9b54-5b5fd999bd3c@github.com>

On Tue, 14 Sep 2021 10:52:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion.
>> 
>> Additional testing:
>>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Even more conservative patch

Thank you!

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Tue Sep 14 15:52:10 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 14 Sep 2021 15:52:10 GMT
Subject: Integrated: 8273373: Zero: Cannot invoke JVM in primordial threads on
 Zero
In-Reply-To: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
References: <5qmWTkxODLzio45dhdUT2ahZHqiOAKKr6NXSUXMC970=.404281bf-77bd-4960-9808-44f711f444bb@github.com>
Message-ID: <JS4dQOFbhcJS-2-h8nQ0TluoVxmc31I-D7sdrb_C7AY=.7e530c53-c668-49f5-a333-c5f0830e0f44@github.com>

On Mon, 6 Sep 2021 09:45:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion.
> 
> Additional testing:
>  - [x] Linux Zero x86_64 passes most gtests now (there are unrelated failures)
>  - [x] Linux Zero x86_32 passes most gtests now (there are unrelated failures)

This pull request has now been integrated.

Changeset: 0f31d0fb
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f31d0fb2c0d5db305e75e1d61bcc44de3e77839
Stats:     29 lines in 2 files changed: 17 ins; 12 del; 0 mod

8273373: Zero: Cannot invoke JVM in primordial threads on Zero

Reviewed-by: stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/5376

From shade at openjdk.java.net  Tue Sep 14 15:53:08 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 14 Sep 2021 15:53:08 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <dqlH5LKQPuatkk26ny98Bg6MrsXho6F5BP9ZEO3oA9Y=.eeef6113-4b2f-4f9f-8455-621ee12fb67a@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <dqlH5LKQPuatkk26ny98Bg6MrsXho6F5BP9ZEO3oA9Y=.eeef6113-4b2f-4f9f-8455-621ee12fb67a@github.com>
Message-ID: <b7NicZSBnxEISnkqKwyXJZjy75cM55g5NctBSPTXf_o=.5cf0f5ad-daa9-458a-b159-d59dd107212e@github.com>

On Fri, 10 Sep 2021 10:02:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 Zero build
>>  - [x] Linux x86_64 Zero bootcycle-images
>>  - [x] Linux x86_64 Zero `tier1`
>
> It isn't the "formal governance" I'm concerned about, more about the folk who use/rely on Zero being the ones to evaluate the impact of a change like this. People, like myself, who do not use Zero in any way cannot evaluate whether this change is appropriate - it's that simple. :)

I'll be happy to integrate as long as @dholmes-ora has no objections.

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From sgehwolf at openjdk.java.net  Tue Sep 14 16:36:09 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 14 Sep 2021 16:36:09 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v3]
In-Reply-To: <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
Message-ID: <3aTKQILDCNwWGM4TGKA-YjW86UQFqKujjWyrGkrNf-s=.e489ddac-53dd-4c91-a608-e5b04f95f5ec@github.com>

On Tue, 14 Sep 2021 14:27:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8266490
>> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
>> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
>> that would be helpful too and can be added to the OSContainer API .
>> pids.current :
>> A read-only single value file which exists on all cgroups.
>> The number of processes currently in the cgroup and its descendants.
>> 
>> Best regards, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify coding following Severins advice

Looks fine. I suggest to move the debug printing from line 99 to after line 101 as suggested here:
https://github.com/openjdk/jdk/pull/5437#discussion_r706145165

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

Marked as reviewed by sgehwolf (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5437

From iklam at openjdk.java.net  Tue Sep 14 16:40:11 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 14 Sep 2021 16:40:11 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v3]
In-Reply-To: <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
Message-ID: <N9TnmaI-MnRQ-9k0S8vq8K4jPWUHm4I8W7CJ7Ib7SEw=.cf8b25c2-9e9b-49ae-b5b8-747795168c78@github.com>

On Tue, 14 Sep 2021 14:27:36 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8266490
>> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
>> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
>> that would be helpful too and can be added to the OSContainer API .
>> pids.current :
>> A read-only single value file which exists on all cgroups.
>> The number of processes currently in the cgroup and its descendants.
>> 
>> Best regards, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify coding following Severins advice

HotSpot changes look good to me. I have a comment on the test.

test/hotspot/jtreg/containers/docker/TestPids.java line 97:

> 95:                 System.out.println("DEBUG: parts.length = " + parts.length);
> 96:                 if (expectedValue.equals("no_value_expected")) {
> 97:                     Asserts.assertEquals(parts.length, 2);

Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities". 

To make it easier to understand this test, I would suggest grouping all messages that were generated outside of HotSpot into something like:


// These messages are generated by Docker
static final String warning_kernel_no_pids_support = "WARNING: Your kernel does not support pids limit capabilities";
static final String no_value_expected = "no_value_expected";

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From minqi at openjdk.java.net  Tue Sep 14 16:58:41 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Sep 2021 16:58:41 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v5]
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <H7Iz9xFzzHtsdRavcGC3bc8b9Q_JjTTx6ZO0WD7TQ2U=.6f55745b-72ea-4c65-a5bd-51cac63b5282@github.com>

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  remove including <cstddef>, instead include globalDefinitions.hpp explicitly

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5450/files
  - new: https://git.openjdk.java.net/jdk/pull/5450/files/4f045e35..5eaf079b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From iklam at openjdk.java.net  Tue Sep 14 17:28:03 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 14 Sep 2021 17:28:03 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v3]
In-Reply-To: <N9TnmaI-MnRQ-9k0S8vq8K4jPWUHm4I8W7CJ7Ib7SEw=.cf8b25c2-9e9b-49ae-b5b8-747795168c78@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
 <N9TnmaI-MnRQ-9k0S8vq8K4jPWUHm4I8W7CJ7Ib7SEw=.cf8b25c2-9e9b-49ae-b5b8-747795168c78@github.com>
Message-ID: <W5LdLbASuHE540YTEmCR_2j7odB1d8uWjK3aJKdbEwo=.3ca8fd96-5db2-443b-91eb-436cf2cf03e4@github.com>

On Tue, 14 Sep 2021 16:36:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify coding following Severins advice
>
> test/hotspot/jtreg/containers/docker/TestPids.java line 97:
> 
>> 95:                 System.out.println("DEBUG: parts.length = " + parts.length);
>> 96:                 if (expectedValue.equals("no_value_expected")) {
>> 97:                     Asserts.assertEquals(parts.length, 2);
> 
> Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities". 
> 
> To make it easier to understand this test, I would suggest grouping all messages that were generated outside of HotSpot into something like:
> 
> 
> // These messages are generated by Docker
> static final String warning_kernel_no_pids_support = "WARNING: Your kernel does not support pids limit capabilities";
> static final String no_value_expected = "no_value_expected";

Oh, I misunderstood the test. "no_value_expected" was passed in from `testPids()` in this file, but that's confusing because you are expecting an integer value. Maybe it should be "any_integer"?

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From iklam at openjdk.java.net  Tue Sep 14 17:35:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 14 Sep 2021 17:35:07 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v5]
In-Reply-To: <H7Iz9xFzzHtsdRavcGC3bc8b9Q_JjTTx6ZO0WD7TQ2U=.6f55745b-72ea-4c65-a5bd-51cac63b5282@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <H7Iz9xFzzHtsdRavcGC3bc8b9Q_JjTTx6ZO0WD7TQ2U=.6f55745b-72ea-4c65-a5bd-51cac63b5282@github.com>
Message-ID: <qLWc1xvm_sJZSrh0SsdI6QETgXKBfFBYnPYry3D9nuU=.8d35ab0f-a9bd-4a9f-8ed7-b176edaf1952@github.com>

On Tue, 14 Sep 2021 16:58:41 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove including <cstddef>, instead include globalDefinitions.hpp explicitly

LGTM. Small nit on friend class declaration.

src/hotspot/share/cds/filemap.hpp line 184:

> 182: class FileMapHeader: private CDSFileMapHeaderBase {
> 183:   friend class VMStructs;
> 184:   friend class CDSConstants;

It's better to sort the classes alphabetically. CDSConstants should come before VMStructs.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5450

From lzang at openjdk.java.net  Tue Sep 14 17:43:31 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 14 Sep 2021 17:43:31 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v33]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <iiy8VyysPAc2MSIaZaNPvcGwLBXfT7cvaIBRqi_AfMg=.8c49b391-e045-4be9-9167-eeba368c386c@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 49 commits:

 - fix parallel issue
 - Merge branch 'master' into pd-fix
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - fix build error
 - rewrite dumper and writer number calculation logic
 - Merge branch 'master' into par-dump
 - Merge branch 'master' of https://github.com/openjdk/jdk
 - remove gzipaccessor
 - fix build error
 - Merge branch 'master' into par-dump
 - ... and 39 more: https://git.openjdk.java.net/jdk/compare/fe89dd3b...26255e3f

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

Changes: https://git.openjdk.java.net/jdk/pull/2261/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=32
  Stats: 848 lines in 6 files changed: 653 ins; 42 del; 153 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Tue Sep 14 17:43:35 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 14 Sep 2021 17:43:35 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
Message-ID: <fe49aMLoaWPvKbUrWgu0F4AxffICQqpeshPC58vnO9A=.a6f84d66-f33a-48dc-b6d0-c4e9ec85f2af@github.com>

On Mon, 6 Sep 2021 08:03:22 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build error

rebased with latest master, and made some change to fix the conflict issue. I will  handle Ralf's comments asap. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From sgehwolf at openjdk.java.net  Tue Sep 14 18:27:10 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 14 Sep 2021 18:27:10 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v3]
In-Reply-To: <W5LdLbASuHE540YTEmCR_2j7odB1d8uWjK3aJKdbEwo=.3ca8fd96-5db2-443b-91eb-436cf2cf03e4@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
 <N9TnmaI-MnRQ-9k0S8vq8K4jPWUHm4I8W7CJ7Ib7SEw=.cf8b25c2-9e9b-49ae-b5b8-747795168c78@github.com>
 <W5LdLbASuHE540YTEmCR_2j7odB1d8uWjK3aJKdbEwo=.3ca8fd96-5db2-443b-91eb-436cf2cf03e4@github.com>
Message-ID: <H8prGvt9-p-Gxxufce1MQu2CrNYOR5pqgYxscTEfGV4=.d17febed-d91e-4179-a128-08284bea68e2@github.com>

On Tue, 14 Sep 2021 17:25:05 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Maybe it should be "any_integer"?

+1

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From minqi at openjdk.java.net  Tue Sep 14 18:52:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Sep 2021 18:52:56 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v6]
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <dmpHa_gkSDWoPqYzUZtn6yGuYoUyy7FCua9lFyx-8as=.61b3dd2f-c1e8-46a2-af90-5621814a372f@github.com>

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Reorder friend classes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5450/files
  - new: https://git.openjdk.java.net/jdk/pull/5450/files/5eaf079b..dfd65258

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From lkorinth at openjdk.java.net  Tue Sep 14 21:23:23 2021
From: lkorinth at openjdk.java.net (Leo Korinth)
Date: Tue, 14 Sep 2021 21:23:23 GMT
Subject: Integrated: 8273414: ResourceObj::operator delete should handle
 nullptr in debug builds
In-Reply-To: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>
References: <a1XUQe-PO6Pu3bKfQANAX38ubiF1Eszgi9suBbnjCf0=.808e1e78-7b51-4e3f-a5af-d2f79c48e56d@github.com>
Message-ID: <NfmQbThXo92zjc7mGUKLVryHl_zAm-qo5L69ZyvYvfs=.e4e830fe-e178-4c96-a172-095cc7deb5dd@github.com>

On Tue, 7 Sep 2021 09:40:33 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This is how delete usually works, This is also how FreeHeap and CHeapObj::operator delete works. Delete does handle nullptr in release builds, it is the assert that may crash. Also, as a user it is nice to call delete without first checking the argument for nullptr.

This pull request has now been integrated.

Changeset: e66bf472
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e66bf472484f6873faf45d634f17b68777fdcfa6
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8273414: ResourceObj::operator delete should handle nullptr in debug builds

Reviewed-by: stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/5385

From minqi at openjdk.java.net  Tue Sep 14 21:55:05 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Sep 2021 21:55:05 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v6]
In-Reply-To: <G6xYYIIgxamhJJ0AQDYT7p2-pUBf-irBAFBSl628H9I=.33393e35-33ac-43f5-9ecd-561e908218e6@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
 <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>
 <G6xYYIIgxamhJJ0AQDYT7p2-pUBf-irBAFBSl628H9I=.33393e35-33ac-43f5-9ecd-561e908218e6@github.com>
Message-ID: <uzX73xX95AO43RhmtU4cQnhVNguEY7uNwytqEjpkKeI=.f5d75088-875e-40e7-855b-583a8d2af5c6@github.com>

On Tue, 14 Sep 2021 06:23:20 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Is this even needed now? I don't see it being used.
>
> To be clear, the layout that I'd like to see is:
> 
> #include "precompiled.hpp"
> #include "cds.hpp"
> ...
> #include "cds/filemap.hpp"
> 
> #include <cstddef>
> 
> 
> However, I think the more appropriate change is to include globalDefinitions.hpp instead of explicitly including cstddef.

The pre-submit tests failed to build hotspot for linux on arm/ppc/s390 etc after <cstddef> removed. <cstddef> needed for defining size_t. So will add it back at last section of 'include'.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From minqi at openjdk.java.net  Tue Sep 14 22:01:05 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Sep 2021 22:01:05 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v7]
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <AfqwrDDRZCc1dUu4Q80OomMqW0Cq3i03ctctgXDpTpw=.6d89799e-6cf0-4bcc-94e4-549beaf52a37@github.com>

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Add back <cstddef> for additional platforms

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5450/files
  - new: https://git.openjdk.java.net/jdk/pull/5450/files/dfd65258..10ef5a4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=05-06

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From iklam at openjdk.java.net  Tue Sep 14 22:12:26 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 14 Sep 2021 22:12:26 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v7]
In-Reply-To: <uzX73xX95AO43RhmtU4cQnhVNguEY7uNwytqEjpkKeI=.f5d75088-875e-40e7-855b-583a8d2af5c6@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
 <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>
 <G6xYYIIgxamhJJ0AQDYT7p2-pUBf-irBAFBSl628H9I=.33393e35-33ac-43f5-9ecd-561e908218e6@github.com>
 <uzX73xX95AO43RhmtU4cQnhVNguEY7uNwytqEjpkKeI=.f5d75088-875e-40e7-855b-583a8d2af5c6@github.com>
Message-ID: <yo258P2aU3NvdgbkuS9pfFHJ5gWpy68NUza1je2VmFQ=.f2da090d-10d6-43e2-8c0b-735c7c2a6145@github.com>

On Tue, 14 Sep 2021 21:52:04 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> To be clear, the layout that I'd like to see is:
>> 
>> #include "precompiled.hpp"
>> #include "cds.hpp"
>> ...
>> #include "cds/filemap.hpp"
>> 
>> #include <cstddef>
>> 
>> 
>> However, I think the more appropriate change is to include globalDefinitions.hpp instead of explicitly including cstddef.
>
> The pre-submit tests failed to build hotspot for linux on arm/ppc/s390 etc after <cstddef> removed. <cstddef> needed for defining size_t. So will add it back at last section of 'include'.

The problem is here in cdsConstants.hpp


#include "memory/allStatic.hpp"
typedef struct {
  const char* _name;
  size_t _value;
} CDSConst;


globalDefinitions.hpp should be included here for the declaration of `size_t`.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From minqi at openjdk.java.net  Tue Sep 14 22:49:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 14 Sep 2021 22:49:56 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v7]
In-Reply-To: <yo258P2aU3NvdgbkuS9pfFHJ5gWpy68NUza1je2VmFQ=.f2da090d-10d6-43e2-8c0b-735c7c2a6145@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
 <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>
 <G6xYYIIgxamhJJ0AQDYT7p2-pUBf-irBAFBSl628H9I=.33393e35-33ac-43f5-9ecd-561e908218e6@github.com>
 <uzX73xX95AO43RhmtU4cQnhVNguEY7uNwytqEjpkKeI=.f5d75088-875e-40e7-855b-583a8d2af5c6@github.com>
 <yo258P2aU3NvdgbkuS9pfFHJ5gWpy68NUza1je2VmFQ=.f2da090d-10d6-43e2-8c0b-735c7c2a6145@github.com>
Message-ID: <4ytobhcVDLgrOobT_j3uNwGXL49WxUcBM3dKFrfsG8k=.02c0b4f0-d9c5-4132-be02-6303de5105b6@github.com>

On Tue, 14 Sep 2021 22:07:10 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The pre-submit tests failed to build hotspot for linux on arm/ppc/s390 etc after <cstddef> removed. <cstddef> needed for defining size_t. So will add it back at last section of 'include'.
>
> The problem is here in cdsConstants.hpp
> 
> 
> #include "memory/allStatic.hpp"
> typedef struct {
>   const char* _name;
>   size_t _value;
> } CDSConst;
> 
> 
> globalDefinitions.hpp should be included here for the declaration of `size_t`.

Yes, but it still failed for non-pch since cds.h is before cdsConstants.hpp. size_t in cds.h is not defined yet. Should I add it to cds.h?

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From iklam at openjdk.java.net  Wed Sep 15 00:00:12 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 15 Sep 2021 00:00:12 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v7]
In-Reply-To: <4ytobhcVDLgrOobT_j3uNwGXL49WxUcBM3dKFrfsG8k=.02c0b4f0-d9c5-4132-be02-6303de5105b6@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
 <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>
 <G6xYYIIgxamhJJ0AQDYT7p2-pUBf-irBAFBSl628H9I=.33393e35-33ac-43f5-9ecd-561e908218e6@github.com>
 <uzX73xX95AO43RhmtU4cQnhVNguEY7uNwytqEjpkKeI=.f5d75088-875e-40e7-855b-583a8d2af5c6@github.com>
 <yo258P2aU3NvdgbkuS9pfFHJ5gWpy68NUza1je2VmFQ=.f2da090d-10d6-43e2-8c0b-735c7c2a6145@github.com>
 <4ytobhcVDLgrOobT_j3uNwGXL49WxUcBM3dKFrfsG8k=.02c0b4f0-d9c5-4132-be02-6303de5105b6@github.com>
Message-ID: <GpsQQ7D0o6z5G5izdzpplRquad16jB-gwjnGS8eSgEU=.a7a25ec8-de21-4777-b23d-7f6480329379@github.com>

On Tue, 14 Sep 2021 22:47:53 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> The problem is here in cdsConstants.hpp
>> 
>> 
>> #include "memory/allStatic.hpp"
>> typedef struct {
>>   const char* _name;
>>   size_t _value;
>> } CDSConst;
>> 
>> 
>> globalDefinitions.hpp should be included here for the declaration of `size_t`.
>
> Yes, but it still failed for non-pch since cds.h is before cdsConstants.hpp. size_t in cds.h is not defined yet. Should I add it to cds.h?

This is a bit complicated. The file is src/hotspot/share/include/cds.h, and the HotSpot convention for including files in this directory usually drops the "include/" part. E.g.,


#include "jvm.h"


But this will put `#include "cds.h"` at the very beginning of all includes, so it doesn't take up `size_t` which is indirectly declared later via globalDefinitions.hpp.

However, header files in src/hotspot/share/ may be included by C/C++ files outside of HotSpot. As a result, these headers cannot include other HotSpot headers. I.e., you cannot put `#include "utilities/globalDefinitions.hpp"` in cds.h, because cds.h is included by src/jdk.hotspot.agent/share/native/libsaproc/ps_core_common.c.

I think one compromise is to add `#include <stddefs.h>` in cds.h. Since cds.h can be included by C source code, we cannot use `#include <cstddef>` which is a C++ thing.  `<stddefs.h>` is part of ANSI C standard and we already include it inside share/utilities/debug.hpp, so we can safely assume that it exists for all compilers that can build HotSpot.

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Wed Sep 15 01:20:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 01:20:51 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v7]
In-Reply-To: <GpsQQ7D0o6z5G5izdzpplRquad16jB-gwjnGS8eSgEU=.a7a25ec8-de21-4777-b23d-7f6480329379@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <gkUp-KA6nRJ6GoWNXSIB7iLrWSOENubHCaZONeqhaBs=.e26d9cf2-30df-47b6-9c73-bed26282b24b@github.com>
 <JA4CPqQuOb8dXAHd26Qxz6XHQxvu-9BxbB45pfV3_UI=.ff8cd4ae-5cff-4cd5-9e22-38bb8905bee9@github.com>
 <G6xYYIIgxamhJJ0AQDYT7p2-pUBf-irBAFBSl628H9I=.33393e35-33ac-43f5-9ecd-561e908218e6@github.com>
 <uzX73xX95AO43RhmtU4cQnhVNguEY7uNwytqEjpkKeI=.f5d75088-875e-40e7-855b-583a8d2af5c6@github.com>
 <yo258P2aU3NvdgbkuS9pfFHJ5gWpy68NUza1je2VmFQ=.f2da090d-10d6-43e2-8c0b-735c7c2a6145@github.com>
 <4ytobhcVDLgrOobT_j3uNwGXL49WxUcBM3dKFrfsG8k=.02c0b4f0-d9c5-4132-be02-6303de5105b6@github.com>
 <GpsQQ7D0o6z5G5izdzpplRquad16jB-gwjnGS8eSgEU=.a7a25ec8-de21-4777-b23d-7f6480329379@github.com>
Message-ID: <rNMmYEFFdzXjH22QUQkp85Yn9EFoOndn9zPlEdmEEJM=.09f592eb-f614-4652-8283-0cc3294cf7cd@github.com>

On Tue, 14 Sep 2021 23:57:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yes, but it still failed for non-pch since cds.h is before cdsConstants.hpp. size_t in cds.h is not defined yet. Should I add it to cds.h?
>
> This is a bit complicated. The file is src/hotspot/share/include/cds.h, and the HotSpot convention for including files in this directory usually drops the "include/" part. E.g.,
> 
> 
> #include "jvm.h"
> 
> 
> But this will put `#include "cds.h"` at the very beginning of all includes, so it doesn't take up `size_t` which is indirectly declared later via globalDefinitions.hpp.
> 
> However, header files in src/hotspot/share/ may be included by C/C++ files outside of HotSpot. As a result, these headers cannot include other HotSpot headers. I.e., you cannot put `#include "utilities/globalDefinitions.hpp"` in cds.h, because cds.h is included by src/jdk.hotspot.agent/share/native/libsaproc/ps_core_common.c.
> 
> I think one compromise is to add `#include <stddefs.h>` in cds.h. Since cds.h can be included by C source code, we cannot use `#include <cstddef>` which is a C++ thing.  `<stddefs.h>` is part of ANSI C standard and we already include it inside share/utilities/debug.hpp, so we can safely assume that it exists for all compilers that can build HotSpot.

I agree with Ioi - use stddefs.h in cds.h

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Wed Sep 15 01:36:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 01:36:50 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <b7NicZSBnxEISnkqKwyXJZjy75cM55g5NctBSPTXf_o=.5cf0f5ad-daa9-458a-b159-d59dd107212e@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
 <dqlH5LKQPuatkk26ny98Bg6MrsXho6F5BP9ZEO3oA9Y=.eeef6113-4b2f-4f9f-8455-621ee12fb67a@github.com>
 <b7NicZSBnxEISnkqKwyXJZjy75cM55g5NctBSPTXf_o=.5cf0f5ad-daa9-458a-b159-d59dd107212e@github.com>
Message-ID: <e5n6ef3Zgq1lHSbK7YTsUcGG7Gtt2iDTVdtOC2LIKRI=.212fa211-2a59-48bd-a34c-d7cc5477d5e6@github.com>

On Tue, 14 Sep 2021 15:49:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> It isn't the "formal governance" I'm concerned about, more about the folk who use/rely on Zero being the ones to evaluate the impact of a change like this. People, like myself, who do not use Zero in any way cannot evaluate whether this change is appropriate - it's that simple. :)
>
> I'll be happy to integrate as long as @dholmes-ora has no objections.

@shipilev no objections from me. I will leave it to the Zero developers to worry, or not, about the Zero users.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From ccheung at openjdk.java.net  Wed Sep 15 03:58:40 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Sep 2021 03:58:40 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v3]
In-Reply-To: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
Message-ID: <aQhkCI_0mPiwcgGPvhci6R8QWdZWcMD-etE6RuiBWns=.846371e6-30b0-4994-bf56-82b138160b09@github.com>

> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  1. revert changes to jvm.cpp since SystemDictionaryShared::set_shared_class_misc_info() is being called in ClassLoader::record_result();
  2. remove UnregisteredClasses::seen_classloader();
  3. remove call to ClassLoaderExt::record_result() in ClassListParser::load_class_from_source() since it is being called in ClassLoader::record_result().

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5458/files
  - new: https://git.openjdk.java.net/jdk/pull/5458/files/781a9ad9..dd11b6db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=01-02

  Stats: 30 lines in 4 files changed: 0 ins; 28 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5458.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5458/head:pull/5458

PR: https://git.openjdk.java.net/jdk/pull/5458

From iklam at openjdk.java.net  Wed Sep 15 05:40:43 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 15 Sep 2021 05:40:43 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v3]
In-Reply-To: <aQhkCI_0mPiwcgGPvhci6R8QWdZWcMD-etE6RuiBWns=.846371e6-30b0-4994-bf56-82b138160b09@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
 <aQhkCI_0mPiwcgGPvhci6R8QWdZWcMD-etE6RuiBWns=.846371e6-30b0-4994-bf56-82b138160b09@github.com>
Message-ID: <cYorvL0uFTEJGAfxWwONlYOLYW7B0ckberrD1LLKot4=.b69cbce9-44f7-4c96-a17c-3a8122a984df@github.com>

On Wed, 15 Sep 2021 03:58:40 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
>> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. revert changes to jvm.cpp since SystemDictionaryShared::set_shared_class_misc_info() is being called in ClassLoader::record_result();
>   2. remove UnregisteredClasses::seen_classloader();
>   3. remove call to ClassLoaderExt::record_result() in ClassListParser::load_class_from_source() since it is being called in ClassLoader::record_result().

Looks good overall. Just two minor comments.

src/hotspot/share/cds/classListParser.cpp line 477:

> 475:   }
> 476: 
> 477:   k->clear_shared_class_loader_type();

I think this may not be necessary, as the correct loader type should have been set inside  ClassLoaderExt::record_result(). Maybe change this to?


assert(k->is_shared_unregistered_class(), "must be");

src/hotspot/share/classfile/systemDictionaryShared.cpp line 454:

> 452: bool SystemDictionaryShared::add_unregistered_class_for_static_archive(Thread* current, InstanceKlass* k) {
> 453:   assert(DumpSharedSpaces, "only when dumping");
> 454:   return add_unregistered_class(current, k);

Since this function is now just a pass-through to `add_unregistered_class()`, maybe we should delete this function, and make `add_unregistered_class()` public?

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5458

From minqi at openjdk.java.net  Wed Sep 15 05:44:20 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 15 Sep 2021 05:44:20 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v8]
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <GYLcrWSNLdW7GAa-nHwa_EM8dR5CGrAFbj7_Cx-XSrc=.4f6b1934-3930-4bc7-803b-5a2163c850b5@github.com>

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Include stddef.h in cds.h

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5450/files
  - new: https://git.openjdk.java.net/jdk/pull/5450/files/10ef5a4d..d23e70e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5450&range=06-07

  Stats: 5 lines in 3 files changed: 3 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5450.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5450/head:pull/5450

PR: https://git.openjdk.java.net/jdk/pull/5450

From iklam at openjdk.java.net  Wed Sep 15 05:44:22 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 15 Sep 2021 05:44:22 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v8]
In-Reply-To: <GYLcrWSNLdW7GAa-nHwa_EM8dR5CGrAFbj7_Cx-XSrc=.4f6b1934-3930-4bc7-803b-5a2163c850b5@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <GYLcrWSNLdW7GAa-nHwa_EM8dR5CGrAFbj7_Cx-XSrc=.4f6b1934-3930-4bc7-803b-5a2163c850b5@github.com>
Message-ID: <4P5KJv3VUrOmvGqjXEvDU-s6KDrjG0lrjqWk1i6pV9U=.c4f6a379-5867-47e3-9a82-f1e9ac64cd44@github.com>

On Wed, 15 Sep 2021 05:40:57 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include stddef.h in cds.h

The new version looks good to me.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5450

From mbaesken at openjdk.java.net  Wed Sep 15 07:12:45 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 15 Sep 2021 07:12:45 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v3]
In-Reply-To: <H8prGvt9-p-Gxxufce1MQu2CrNYOR5pqgYxscTEfGV4=.d17febed-d91e-4179-a128-08284bea68e2@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
 <N9TnmaI-MnRQ-9k0S8vq8K4jPWUHm4I8W7CJ7Ib7SEw=.cf8b25c2-9e9b-49ae-b5b8-747795168c78@github.com>
 <W5LdLbASuHE540YTEmCR_2j7odB1d8uWjK3aJKdbEwo=.3ca8fd96-5db2-443b-91eb-436cf2cf03e4@github.com>
 <H8prGvt9-p-Gxxufce1MQu2CrNYOR5pqgYxscTEfGV4=.d17febed-d91e-4179-a128-08284bea68e2@github.com>
Message-ID: <v7oz0Z-UxoliaXHzzhJhdIIxGTkaJz-JZh0hOeDLNHk=.616462bd-ccc9-4bc8-acdb-55604bbab6b6@github.com>

On Tue, 14 Sep 2021 18:23:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Oh, I misunderstood the test. "no_value_expected" was passed in from `testPids()` in this file, but that's confusing because you are expecting an integer value. Maybe it should be "any_integer"?
>
>> Maybe it should be "any_integer"?
> 
> +1

> Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities".
> 

Hi, this warning is showing up on some of our Linux ppc64le machines where the pids limit capabilities is not supported.

Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From dholmes at openjdk.java.net  Wed Sep 15 07:39:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 07:39:09 GMT
Subject: RFR: 8271569: Clean up the use of CDS constants and field offsets
 [v8]
In-Reply-To: <GYLcrWSNLdW7GAa-nHwa_EM8dR5CGrAFbj7_Cx-XSrc=.4f6b1934-3930-4bc7-803b-5a2163c850b5@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
 <GYLcrWSNLdW7GAa-nHwa_EM8dR5CGrAFbj7_Cx-XSrc=.4f6b1934-3930-4bc7-803b-5a2163c850b5@github.com>
Message-ID: <OjrXWl5sxFEQMNaxnsoAaCemDGLOgdXNoDXGZTXAyJE=.020134b7-5f6e-41f8-ad1d-f84bd9942a19@github.com>

On Wed, 15 Sep 2021 05:44:20 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
>> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
>> 
>> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
>> 
>> Tests: ter1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Include stddef.h in cds.h

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From mbaesken at openjdk.java.net  Wed Sep 15 07:46:34 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 15 Sep 2021 07:46:34 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v4]
In-Reply-To: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
Message-ID: <vgBIPEzOiCZi0c00ERAyO8npf6X34NFQokpH34Gz8EY=.8aa86049-1a83-4627-af06-525feecc7104@github.com>

> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
> 
> Best regards, Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust TestPids

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5437/files
  - new: https://git.openjdk.java.net/jdk/pull/5437/files/afe0efd4..86f3f534

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5437&range=02-03

  Stats: 7 lines in 1 file changed: 3 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5437.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5437/head:pull/5437

PR: https://git.openjdk.java.net/jdk/pull/5437

From mbaesken at openjdk.java.net  Wed Sep 15 08:07:55 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 15 Sep 2021 08:07:55 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v3]
In-Reply-To: <v7oz0Z-UxoliaXHzzhJhdIIxGTkaJz-JZh0hOeDLNHk=.616462bd-ccc9-4bc8-acdb-55604bbab6b6@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <GJw-MJ6W9nOXp3xGZVn6OTu9y7Ft-UEkyZ7k0PZ_lxY=.e33aa10d-5624-4d0f-b4fa-5e13ae4902fb@github.com>
 <N9TnmaI-MnRQ-9k0S8vq8K4jPWUHm4I8W7CJ7Ib7SEw=.cf8b25c2-9e9b-49ae-b5b8-747795168c78@github.com>
 <W5LdLbASuHE540YTEmCR_2j7odB1d8uWjK3aJKdbEwo=.3ca8fd96-5db2-443b-91eb-436cf2cf03e4@github.com>
 <H8prGvt9-p-Gxxufce1MQu2CrNYOR5pqgYxscTEfGV4=.d17febed-d91e-4179-a128-08284bea68e2@github.com>
 <v7oz0Z-UxoliaXHzzhJhdIIxGTkaJz-JZh0hOeDLNHk=.616462bd-ccc9-4bc8-acdb-55604bbab6b6@github.com>
Message-ID: <-AS4eYSWQbIT2pnPY1hveJCn4o1h8Aoc66xTHejbLMs=.937d0af0-290e-414a-ad8d-0e38b7e3c775@github.com>

On Wed, 15 Sep 2021 07:09:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> Maybe it should be "any_integer"?
>> 
>> +1
>
>> Is "no_value_expected" generated by Docker? I searched the entire HotSpot source code and couldn't find it. I also couldn't find "WARNING: Your kernel does not support pids limit capabilities".
>> 
> 
> Hi, this warning is showing up on some of our Linux ppc64le machines where the pids limit capabilities is not supported.
> 
> Best regards, Matthias

Hello, I adjusted to any_integer, and introduced the "final String warning_kernel_no_pids_support" . I think the message is more related to the kernel features so I did not add the add the  'generated by Docker'  comment.

Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From mbaesken at openjdk.java.net  Wed Sep 15 08:07:56 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 15 Sep 2021 08:07:56 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v2]
In-Reply-To: <y1cYNeEg6fNJdYiGwjzx0i9T0QO-mUq_mr7Tu6U7RQI=.ca70e2f5-e4a9-45e9-988c-9c8c2e913c6f@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <3PokFyPHsil0S9A15OWUj97Xls1tFpkeXuqHydXnh4o=.64e6daaa-5dc3-438c-b362-ba61775d1403@github.com>
 <y1cYNeEg6fNJdYiGwjzx0i9T0QO-mUq_mr7Tu6U7RQI=.ca70e2f5-e4a9-45e9-988c-9c8c2e913c6f@github.com>
Message-ID: <M7mbhJmzEr9zQMzqojI2Yh-uXYOUtV3fgZv8HuCpcW4=.91ae0bb1-995a-4680-a43c-7ee85bf91e5e@github.com>

On Fri, 10 Sep 2021 12:36:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Some simplifications and test adjustment suggested by Severin
>
> test/hotspot/jtreg/containers/docker/TestPids.java line 101:
> 
>> 99:                     System.out.println("Found " + lineMarker + " with value: " + ivalue);
>> 100:                     try {
>> 101:                         int ai = Integer.parseInt(ivalue);
> 
> Could you move the debug print line to after line 101, please. It could say:
> 
> `System.out.println("Found " + lineMarker + " with value: " + ai + ". PASS.");`

the debug println has been moved down.

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From shade at openjdk.java.net  Wed Sep 15 09:00:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 09:00:57 GMT
Subject: Integrated: 8273494: Zero: Put libjvm.so into "zero" folder,
 not "server"
In-Reply-To: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
Message-ID: <w-1MDISvtws6Q6bAtqct_79B3cuQ5jJ8wK4u1iSgL3c=.870b2229-2806-4fc7-a8f7-791ebe22428f@github.com>

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero build
>  - [x] Linux x86_64 Zero bootcycle-images
>  - [x] Linux x86_64 Zero `tier1`

This pull request has now been integrated.

Changeset: 8fbcc823
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8fbcc8239a3fc04e56ebbd287c7bb5db731977b7
Stats:     14 lines in 6 files changed: 0 ins; 3 del; 11 mod

8273494: Zero: Put libjvm.so into "zero" folder, not "server"

Reviewed-by: ihse, sgehwolf

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From shade at openjdk.java.net  Wed Sep 15 09:00:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 09:00:56 GMT
Subject: RFR: 8273494: Zero: Put libjvm.so into "zero" folder, not "server"
In-Reply-To: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
References: <MkxOp3ftBww6lNqCoBHNgXxXIWy2rkeg5AVlMY2QPOM=.9b126913-731b-4272-83e5-dcc14a675937@github.com>
Message-ID: <xNO4Crt7yzvZIKo7DV-7ogrKtDeLZYdNorprGwkeMdg=.574a8048-2d4b-46de-a6c5-6b07d6fb9f58@github.com>

On Thu, 9 Sep 2021 10:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, the build system defaults the libjvm.so location to "server".  This makes looking for `libjvm.so` awkward, see JDK-8273487 for example. We need to see if moving the libjvm.so to a proper location breaks anything. 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero build
>  - [x] Linux x86_64 Zero bootcycle-images
>  - [x] Linux x86_64 Zero `tier1`

Thank you all!

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

PR: https://git.openjdk.java.net/jdk/pull/5440

From sgehwolf at openjdk.java.net  Wed Sep 15 09:35:49 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 15 Sep 2021 09:35:49 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v4]
In-Reply-To: <vgBIPEzOiCZi0c00ERAyO8npf6X34NFQokpH34Gz8EY=.8aa86049-1a83-4627-af06-525feecc7104@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <vgBIPEzOiCZi0c00ERAyO8npf6X34NFQokpH34Gz8EY=.8aa86049-1a83-4627-af06-525feecc7104@github.com>
Message-ID: <-dUrye6VcX6yUG8OlEiGO1-vdojEMY_vY3niClPCF3Y=.4cac75ba-b785-4a13-b511-b3067808b7f7@github.com>

On Wed, 15 Sep 2021 07:46:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8266490
>> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
>> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
>> that would be helpful too and can be added to the OSContainer API .
>> pids.current :
>> A read-only single value file which exists on all cgroups.
>> The number of processes currently in the cgroup and its descendants.
>> 
>> Best regards, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust TestPids

Marked as reviewed by sgehwolf (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From shade at openjdk.java.net  Wed Sep 15 10:36:06 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 15 Sep 2021 10:36:06 GMT
Subject: RFR: 8273804: Platform.isTieredSupported should handle the
 no-compiler case
Message-ID: <gQf4opc8f0J6bKr0CfNoyqncClBNXt6hFMw_s6mh_Jw=.efb32905-c66b-4f2c-b56b-f14df111a5cd@github.com>

Happens with Zero tests:


$ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java
...

java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null
at jdk.test.lib.Platform.isTieredSupported(Platform.java:82)
at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61)
at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833) 


Additional testing:
 - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/5528/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5528&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273804
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5528.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5528/head:pull/5528

PR: https://git.openjdk.java.net/jdk/pull/5528

From dholmes at openjdk.java.net  Wed Sep 15 13:01:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 15 Sep 2021 13:01:57 GMT
Subject: RFR: 8273804: Platform.isTieredSupported should handle the
 no-compiler case
In-Reply-To: <gQf4opc8f0J6bKr0CfNoyqncClBNXt6hFMw_s6mh_Jw=.efb32905-c66b-4f2c-b56b-f14df111a5cd@github.com>
References: <gQf4opc8f0J6bKr0CfNoyqncClBNXt6hFMw_s6mh_Jw=.efb32905-c66b-4f2c-b56b-f14df111a5cd@github.com>
Message-ID: <zI8qJm8DA6bAAy0SZuXRLHX1FEcIV1mbLQ8y_uqf46Q=.9ccd499f-19d0-4337-b370-50d338f4cf20@github.com>

On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Happens with Zero tests:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java
> ...
> 
> java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null
> at jdk.test.lib.Platform.isTieredSupported(Platform.java:82)
> at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61)
> at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error

Looks fine and trivial.

Cheers,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5528

From iklam at openjdk.java.net  Wed Sep 15 16:21:56 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 15 Sep 2021 16:21:56 GMT
Subject: RFR: JDK-8273526: Extend the OSContainer API pids controller with
 pids.current [v4]
In-Reply-To: <vgBIPEzOiCZi0c00ERAyO8npf6X34NFQokpH34Gz8EY=.8aa86049-1a83-4627-af06-525feecc7104@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
 <vgBIPEzOiCZi0c00ERAyO8npf6X34NFQokpH34Gz8EY=.8aa86049-1a83-4627-af06-525feecc7104@github.com>
Message-ID: <2YWy5hYePGAF37qNzKNWfXOzseN2w2ASotVayUFCfLc=.e3d2be21-a335-4b15-9007-af93865b2afe@github.com>

On Wed, 15 Sep 2021 07:46:34 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8266490
>> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
>> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
>> that would be helpful too and can be added to the OSContainer API .
>> pids.current :
>> A read-only single value file which exists on all cgroups.
>> The number of processes currently in the cgroup and its descendants.
>> 
>> Best regards, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust TestPids

Marked as reviewed by iklam (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From ccheung at openjdk.java.net  Wed Sep 15 18:04:50 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Sep 2021 18:04:50 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v4]
In-Reply-To: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
Message-ID: <6vtyQlrcFO_q6iiCte_q6tDB420vft-HLfd0e4u42WQ=.372a61c9-d6b7-4d0f-92d3-7ce3313a02f7@github.com>

> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  @iklam comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5458/files
  - new: https://git.openjdk.java.net/jdk/pull/5458/files/dd11b6db..6272a480

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=02-03

  Stats: 14 lines in 4 files changed: 1 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5458.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5458/head:pull/5458

PR: https://git.openjdk.java.net/jdk/pull/5458

From ccheung at openjdk.java.net  Wed Sep 15 18:06:20 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 15 Sep 2021 18:06:20 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v3]
In-Reply-To: <cYorvL0uFTEJGAfxWwONlYOLYW7B0ckberrD1LLKot4=.b69cbce9-44f7-4c96-a17c-3a8122a984df@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
 <aQhkCI_0mPiwcgGPvhci6R8QWdZWcMD-etE6RuiBWns=.846371e6-30b0-4994-bf56-82b138160b09@github.com>
 <cYorvL0uFTEJGAfxWwONlYOLYW7B0ckberrD1LLKot4=.b69cbce9-44f7-4c96-a17c-3a8122a984df@github.com>
Message-ID: <D2xKkvx_M3YctfvWdQqRrlPWikoqFtOV_7AzP4PSS7o=.7772626d-b8cd-43a8-958c-67990addaf47@github.com>

On Wed, 15 Sep 2021 05:35:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   1. revert changes to jvm.cpp since SystemDictionaryShared::set_shared_class_misc_info() is being called in ClassLoader::record_result();
>>   2. remove UnregisteredClasses::seen_classloader();
>>   3. remove call to ClassLoaderExt::record_result() in ClassListParser::load_class_from_source() since it is being called in ClassLoader::record_result().
>
> src/hotspot/share/cds/classListParser.cpp line 477:
> 
>> 475:   }
>> 476: 
>> 477:   k->clear_shared_class_loader_type();
> 
> I think this may not be necessary, as the correct loader type should have been set inside  ClassLoaderExt::record_result(). Maybe change this to?
> 
> 
> assert(k->is_shared_unregistered_class(), "must be");

I've changed it to assert. Also removed the `clear_shared_class_loader_type()` since it is not used anymore.
The class loader type is not set not due to the call to `ClassLoaderExt::record_result()` which will default the loader type to boot loader. For unregistered classes, the `ClassLoaderExt::record_result()` won't be called in `ClassLoader::record_result()`.

> src/hotspot/share/classfile/systemDictionaryShared.cpp line 454:
> 
>> 452: bool SystemDictionaryShared::add_unregistered_class_for_static_archive(Thread* current, InstanceKlass* k) {
>> 453:   assert(DumpSharedSpaces, "only when dumping");
>> 454:   return add_unregistered_class(current, k);
> 
> Since this function is now just a pass-through to `add_unregistered_class()`, maybe we should delete this function, and make `add_unregistered_class()` public?

I've made the change. The `add_unregistered_class()` is already declared public.

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From iklam at openjdk.java.net  Wed Sep 15 21:16:57 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 15 Sep 2021 21:16:57 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v4]
In-Reply-To: <6vtyQlrcFO_q6iiCte_q6tDB420vft-HLfd0e4u42WQ=.372a61c9-d6b7-4d0f-92d3-7ce3313a02f7@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
 <6vtyQlrcFO_q6iiCte_q6tDB420vft-HLfd0e4u42WQ=.372a61c9-d6b7-4d0f-92d3-7ce3313a02f7@github.com>
Message-ID: <fX9O0wHvSU5AAUAJ65BLq2B6xWdJ3bBwnhc7f0KotIY=.af2b6a5c-c4c2-46bc-b546-e4aa9ed1e74f@github.com>

On Wed, 15 Sep 2021 18:04:50 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
>> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comment

Marked as reviewed by iklam (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From minqi at openjdk.java.net  Wed Sep 15 22:08:57 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 15 Sep 2021 22:08:57 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v4]
In-Reply-To: <6vtyQlrcFO_q6iiCte_q6tDB420vft-HLfd0e4u42WQ=.372a61c9-d6b7-4d0f-92d3-7ce3313a02f7@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
 <6vtyQlrcFO_q6iiCte_q6tDB420vft-HLfd0e4u42WQ=.372a61c9-d6b7-4d0f-92d3-7ce3313a02f7@github.com>
Message-ID: <H1DEoFCID-M2lNtOk1frfXEVw4mbMtcvXSZpdAX-Spk=.86f3ab11-f61e-45e5-983a-494264966d0c@github.com>

On Wed, 15 Sep 2021 18:04:50 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
>> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
>> 
>> Passed tiers 1 - 4 testing.
>
> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @iklam comment

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5458

From lzang at openjdk.java.net  Thu Sep 16 02:22:15 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 16 Sep 2021 02:22:15 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v34]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <CrtfVKOadKl3Wg-iKh33bioxp6wxv86MD1rUpciINsQ=.198de65f-0f7c-4808-9a09-d3bee821dffd@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  fix issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/26255e3f..64d72dbc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=33
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=32-33

  Stats: 14 lines in 1 file changed: 5 ins; 4 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Sep 16 03:25:09 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 16 Sep 2021 03:25:09 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v35]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <BwQAwDmSMygg24l37MYshzhCxguyj9E5jz3hxszxRFw=.89b5f9fa-3bbc-4f89-8112-a28ff142420f@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  code refine

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/64d72dbc..272c632e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=34
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=33-34

  Stats: 27 lines in 1 file changed: 0 ins; 16 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2261.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2261/head:pull/2261

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Sep 16 05:42:20 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 16 Sep 2021 05:42:20 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v36]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <-bgDgDvEVnCW9yreta95MNFbpGhqAt44Rtb6Gn6KicE=.9ac67198-5e79-4acc-b5dd-0bac7f297760@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  fix build issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/272c632e..43c516a4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=35
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=34-35

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From mbaesken at openjdk.java.net  Thu Sep 16 07:11:49 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 16 Sep 2021 07:11:49 GMT
Subject: Integrated: JDK-8273526: Extend the OSContainer API pids controller
 with pids.current
In-Reply-To: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
References: <IGBocJRxmDpBL_uQXQOXzqlQR0DC1hSrSUnSk_AHpPI=.7bbc7743-4a25-431b-8a0e-7c396807f0fd@github.com>
Message-ID: <ZL8qN51uPRxfsAF3z3TeC833sxSrBDfQGGSXv2-gqTI=.86699e20-f8c3-4941-af22-85a816721a24@github.com>

On Thu, 9 Sep 2021 09:21:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8266490
> extended the OSContainer API in order to also support the pids controller of cgroups. However only pids.max output was added with 8266490.
> There is a second parameter pids.current , see https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#pid
> that would be helpful too and can be added to the OSContainer API .
> pids.current :
> A read-only single value file which exists on all cgroups.
> The number of processes currently in the cgroup and its descendants.
> 
> Best regards, Matthias

This pull request has now been integrated.

Changeset: d4546b6b
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d4546b6b36f9dc9ff3d626f8cfe62b62daa0de01
Stats:     88 lines in 14 files changed: 85 ins; 0 del; 3 mod

8273526: Extend the OSContainer API pids controller with pids.current

Reviewed-by: sgehwolf, iklam

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

PR: https://git.openjdk.java.net/jdk/pull/5437

From mbaesken at openjdk.java.net  Thu Sep 16 07:28:00 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 16 Sep 2021 07:28:00 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for POSIX
 platforms
Message-ID: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>

We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.

Thanks, Matthias

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

Commit messages:
 - JDK-8273815

Changes: https://git.openjdk.java.net/jdk/pull/5540/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5540&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273815
  Stats: 50 lines in 4 files changed: 11 ins; 39 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5540.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5540/head:pull/5540

PR: https://git.openjdk.java.net/jdk/pull/5540

From shade at openjdk.java.net  Thu Sep 16 07:56:50 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 07:56:50 GMT
Subject: Integrated: 8273804: Platform.isTieredSupported should handle the
 no-compiler case
In-Reply-To: <gQf4opc8f0J6bKr0CfNoyqncClBNXt6hFMw_s6mh_Jw=.efb32905-c66b-4f2c-b56b-f14df111a5cd@github.com>
References: <gQf4opc8f0J6bKr0CfNoyqncClBNXt6hFMw_s6mh_Jw=.efb32905-c66b-4f2c-b56b-f14df111a5cd@github.com>
Message-ID: <Kea2dFMdGVqNpVS2pJQ9IsY2e4_1DuwABEUF6S0D1zY=.3e30970e-f19e-4d8f-850e-efe12abe085c@github.com>

On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Happens with Zero tests:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java
> ...
> 
> java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null
> at jdk.test.lib.Platform.isTieredSupported(Platform.java:82)
> at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61)
> at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error

This pull request has now been integrated.

Changeset: 46af82e5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/46af82e5b0d176e340f46125f8a3bb17e56bd7b3
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8273804: Platform.isTieredSupported should handle the no-compiler case

Reviewed-by: dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5528

From shade at openjdk.java.net  Thu Sep 16 07:56:50 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 07:56:50 GMT
Subject: RFR: 8273804: Platform.isTieredSupported should handle the
 no-compiler case
In-Reply-To: <gQf4opc8f0J6bKr0CfNoyqncClBNXt6hFMw_s6mh_Jw=.efb32905-c66b-4f2c-b56b-f14df111a5cd@github.com>
References: <gQf4opc8f0J6bKr0CfNoyqncClBNXt6hFMw_s6mh_Jw=.efb32905-c66b-4f2c-b56b-f14df111a5cd@github.com>
Message-ID: <j778X7mZZsxe5w_V6dB9ORumKkweeSRcF5zT5AeoC_w=.b5ffbabf-f080-4249-abe8-94969726f30f@github.com>

On Wed, 15 Sep 2021 10:29:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Happens with Zero tests:
> 
> 
> $ CONF=linux-x86_64-zero-fastdebug make exploded-test TEST=compiler/codecache/CheckSegmentedCodeCache.java
> ...
> 
> java.lang.NullPointerException: Cannot invoke "String.contains(java.lang.CharSequence)" because "jdk.test.lib.Platform.compiler" is null
> at jdk.test.lib.Platform.isTieredSupported(Platform.java:82)
> at compiler.codecache.CheckSegmentedCodeCache.verifySegmentedCodeCache(CheckSegmentedCodeCache.java:61)
> at compiler.codecache.CheckSegmentedCodeCache.main(CheckSegmentedCodeCache.java:108)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
> at java.base/java.lang.Thread.run(Thread.java:833) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 Zero, `compiler/codecache/CheckSegmentedCodeCache.java` now properly fails with "no compilers" error

Thank you!

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

PR: https://git.openjdk.java.net/jdk/pull/5528

From glaubitz at openjdk.java.net  Thu Sep 16 08:56:46 2021
From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz)
Date: Thu, 16 Sep 2021 08:56:46 GMT
Subject: RFR: 8273606: Zero: SPARC64 build fails with si_band type
 mismatch [v2]
In-Reply-To: <S_DEOyK-L6IFp4zQdFTla-gXuTcK34515mOVvwOewcw=.4e90a2a1-1be6-433e-b816-692aa78ea853@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
 <veLkydGKyG0Uz0e1YQOW77iapCYtEU1oanVv_5rDRv4=.6d910936-0ab0-4d9e-b364-1ba9fe699e05@github.com>
 <S_DEOyK-L6IFp4zQdFTla-gXuTcK34515mOVvwOewcw=.4e90a2a1-1be6-433e-b816-692aa78ea853@github.com>
Message-ID: <6vHp-t2A8BjwIxoTYBqRVmszXN8bkDGizOjLRf5mRe0=.6e080649-1854-42ef-a51c-96f5db2f2fd7@github.com>

On Tue, 14 Sep 2021 10:16:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> All right, I suppose everyone is happy with this patch? I'll be integrating it soon.

Yep, fine with me. Thanks for taking care of this.

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From shade at openjdk.java.net  Thu Sep 16 08:56:46 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 16 Sep 2021 08:56:46 GMT
Subject: Integrated: 8273606: Zero: SPARC64 build fails with si_band type
 mismatch
In-Reply-To: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
References: <XAH7m88NCNvpf287qNYLj3mY3UYgNeiGvDft-euEYK4=.bbe579ea-ec23-4668-b04d-6ca733e16df3@github.com>
Message-ID: <kybjRA-1FUg43uHUXXkB96JR2Vkk0r_KA4XV0WypRlE=.10a8f3c5-3dc3-444a-a6b7-fa2e02e69a68@github.com>

On Fri, 10 Sep 2021 16:25:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This is actually caught by `-Werror=format` that is enabled by default.
> 
> 
> $  sh ./configure --with-debug-level=slowdebug --with-boot-jdk=/home/shade/Install/jdk16-16.0.2-ea/ --openjdk-target=sparc64-linux-gnu --with-sysroot=/chroots/sparc64/ --with-jvm-variants=zero
> $ make images

This pull request has now been integrated.

Changeset: 241ac89f
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/241ac89f120f9bcfef65962aa05b51b9f847c4ce
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8273606: Zero: SPARC64 build fails with si_band type mismatch

Reviewed-by: stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/5470

From lzang at openjdk.java.net  Thu Sep 16 09:35:20 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 16 Sep 2021 09:35:20 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v37]
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <hdu5sGnna15CL1ZPzod-gwZa5v_KHgE4Nk_lSLJwz20=.716aa807-dc25-4d3c-9a94-24f8f30d9a53@github.com>

> 8252842: Extend jmap to support parallel heap dump

Lin Zang 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:

  fix build issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2261/files
  - new: https://git.openjdk.java.net/jdk/pull/2261/files/43c516a4..fcc2674c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=36
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2261&range=35-36

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Sep 16 12:20:02 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 16 Sep 2021 12:20:02 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
Message-ID: <vaDJgwJ08ngx9bB8WAL9tYMwf0Uy8hhAD9JOVpASy9k=.e26bf572-6749-4805-a2b5-cce348e9adce@github.com>

On Wed, 8 Sep 2021 05:02:18 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix build error
>
> I will start reviewing this today.

Hi Ralf @schmelter-sap, 
     I have updated the PR, would you like to help review it again? Thanks!

BRs,
Lin

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From stuefe at openjdk.java.net  Thu Sep 16 15:56:14 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 16 Sep 2021 15:56:14 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling
Message-ID: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>

Hi,

may I please have reviews for this patch.

This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).

----

Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.

I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.

When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, this became a nuisance and I'd like to simplify this. 

The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 

The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.

The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.

Small caveats:
- the first block in a chunk has no leading fence
- the last block in a chunk *may* have no trailing fence
- the guard now costs 24 bytes, up from 16 before.

Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.

Tests:
- Nightlies at SAP
- manual tests on x64 and x86 with and without guards
- manual gtests
- manual metaspace jtreg tests

Thanks, Thomas

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

Commit messages:
 - JDK-8273783-Simplify-metaspace-arena-guard-handling

Changes: https://git.openjdk.java.net/jdk/pull/5518/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5518&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273783
  Stats: 243 lines in 9 files changed: 63 ins; 169 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5518/head:pull/5518

PR: https://git.openjdk.java.net/jdk/pull/5518

From ccheung at openjdk.java.net  Thu Sep 16 16:40:34 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 16 Sep 2021 16:40:34 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v5]
In-Reply-To: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
Message-ID: <LvglXlFpu1Mgt3hZavTf4nMuJ-X5sicU3LBLeAcUDss=.20ad9d96-ca1b-4e24-b691-a0bfedb0658b@github.com>

> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
> 
> Passed tiers 1 - 4 testing.

Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:

  add back a blank line to jvm.cpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5458/files
  - new: https://git.openjdk.java.net/jdk/pull/5458/files/6272a480..bcf20769

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5458&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From ccheung at openjdk.java.net  Thu Sep 16 17:35:52 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 16 Sep 2021 17:35:52 GMT
Subject: RFR: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump [v4]
In-Reply-To: <fX9O0wHvSU5AAUAJ65BLq2B6xWdJ3bBwnhc7f0KotIY=.af2b6a5c-c4c2-46bc-b546-e4aa9ed1e74f@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
 <6vtyQlrcFO_q6iiCte_q6tDB420vft-HLfd0e4u42WQ=.372a61c9-d6b7-4d0f-92d3-7ce3313a02f7@github.com>
 <fX9O0wHvSU5AAUAJ65BLq2B6xWdJ3bBwnhc7f0KotIY=.af2b6a5c-c4c2-46bc-b546-e4aa9ed1e74f@github.com>
Message-ID: <VL-q0jnRBuwh5TOcWPXXNc3e0zojmFJvPr0gCL08VJw=.8a997e87-8754-4c93-84ea-32bd9169bca5@github.com>

On Wed, 15 Sep 2021 21:13:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @iklam comment
>
> Marked as reviewed by iklam (Reviewer).

@iklam, @yminqi Thanks for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From ccheung at openjdk.java.net  Thu Sep 16 17:35:55 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 16 Sep 2021 17:35:55 GMT
Subject: Integrated: 8261941: Use ClassLoader for unregistered classes during
 -Xshare:dump
In-Reply-To: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
References: <EmkJHfFXKFRS6XoCboQ-I_yNclZ0vNhmeevdmTuvCkw=.82c777b6-cebe-43d6-b3f7-b12bb7509102@github.com>
Message-ID: <icH-lMd3kix2tS-wQDvH9lzFk8rpfT6Bg4-2t32znXg=.3e58182a-108a-4956-9404-22fad89b9f90@github.com>

On Fri, 10 Sep 2021 00:20:04 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Before this change, unregistered classes are loaded by the boot class loader during CDS dump time.
> This RFE creates an URLClassLoader based on the source specified in the classlist and uses the URLClassLoader to load the unregistered class during CDS dump time. The URLClassLoader instances will be cached in a hash table with the source as the key so that classes associated with the same source will be loaded by the same instance of class loader.
> 
> Passed tiers 1 - 4 testing.

This pull request has now been integrated.

Changeset: 12fa7073
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/12fa7073c58eb9f204bb60ab6192738f8aece626
Stats:     285 lines in 10 files changed: 169 ins; 114 del; 2 mod

8261941: Use ClassLoader for unregistered classes during -Xshare:dump

Reviewed-by: iklam, minqi

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

PR: https://git.openjdk.java.net/jdk/pull/5458

From minqi at openjdk.java.net  Thu Sep 16 18:00:58 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 16 Sep 2021 18:00:58 GMT
Subject: Integrated: 8271569: Clean up the use of CDS constants and field
 offsets
In-Reply-To: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
References: <pB_gTViy3xtfYbsQ9Y000oEvpM_zSCRK1sG2-mkhn20=.09aa6431-04b0-4e80-8506-a7158d3f5090@github.com>
Message-ID: <JlwDt-UqkVyALVxwFNH45C_tWC5th1oTdH7gX6Aid-8=.58019dc1-3da2-4500-b4e1-d83757647d2a@github.com>

On Thu, 9 Sep 2021 18:13:10 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Changed cdsOffsets.cpp to cdsConstants.cpp, now the offsets and constants are initialized static and searched separately.
> The offsets array could not use 'constexpr' since g++ on MacOs and VSC++ on Windows complained reinterpret_cast in 'offset_of' should not be used in constexpr initialization. Changed some field access for forming global list first.
> 
> Note with 'git mv' to rename cdsoffset.cpp to cdsConstants.cpp, same for cdsoffsets.hpp to cdsConstants.hpp, due to the contents changed more than 50% so git will not think cdsConstants.cpp is renamed from cdsoffsets.cpp. Instead, it is regarded as a new file.
> 
> Tests: ter1-4
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: 9c5441c9
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9c5441c9c4eea2ea4ba78ee426729bf646dc042d
Stats:     342 lines in 11 files changed: 170 ins; 126 del; 46 mod

8271569: Clean up the use of CDS constants and field offsets

Reviewed-by: iklam, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5450

From dholmes at openjdk.java.net  Fri Sep 17 01:54:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 17 Sep 2021 01:54:49 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling
In-Reply-To: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
Message-ID: <AwXrkDwtIc5poDRGu0pe1PuMM43bwmk3nner9d0kDXc=.28458a3a-4e88-4556-93a7-4139ec4f43db@github.com>

On Wed, 15 Sep 2021 06:10:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> may I please have reviews for this patch.
> 
> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
> 
> ----
> 
> Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.
> 
> I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.
> 
> When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, this became a nuisance and I'd like to simplify this. 
> 
> The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 
> 
> The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.
> 
> The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.
> 
> Small caveats:
> - the first block in a chunk has no leading fence
> - the last block in a chunk *may* have no trailing fence
> - the guard now costs 24 bytes, up from 16 before.
> 
> Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.
> 
> Tests:
> - Nightlies at SAP
> - manual tests on x64 and x86 with and without guards
> - manual gtests
> - manual metaspace jtreg tests
> 
> Thanks, Thomas

Hi Thomas,

I can't really review this, but I'm running it through our internal tier 1-3 testing.

David

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

PR: https://git.openjdk.java.net/jdk/pull/5518

From stuefe at openjdk.java.net  Fri Sep 17 07:37:11 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 17 Sep 2021 07:37:11 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling [v2]
In-Reply-To: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
Message-ID: <ZFM7zbj9dceg4oDEqPVwVF6bFlm3GRTTC2URYL1u5-Y=.7c19e746-37ba-4f09-9ad2-cb45d9213cb2@github.com>

> Hi,
> 
> may I please have reviews for this patch.
> 
> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
> 
> ----
> 
> Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.
> 
> I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.
> 
> When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, this became a nuisance and I'd like to simplify this. 
> 
> The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 
> 
> The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.
> 
> The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.
> 
> Small caveats:
> - the first block in a chunk has no leading fence
> - the last block in a chunk *may* have no trailing fence
> - the guard now costs 24 bytes, up from 16 before.
> 
> Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.
> 
> Tests:
> - Nightlies at SAP
> - manual tests on x64 and x86 with and without guards
> - manual gtests
> - manual metaspace jtreg tests
> 
> Thanks, Thomas

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Reduce diff and improve comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5518/files
  - new: https://git.openjdk.java.net/jdk/pull/5518/files/f576205e..8738a84c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5518&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5518&range=00-01

  Stats: 18 lines in 2 files changed: 7 ins; 1 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5518/head:pull/5518

PR: https://git.openjdk.java.net/jdk/pull/5518

From mbaesken at openjdk.java.net  Fri Sep 17 11:08:59 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 11:08:59 GMT
Subject: RFR: JDK-8273877: os::unsetenv unused
Message-ID: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>

Please review this small change.
It seems the HS function os::unsetenv is not used any more for some time and could be removed.

Thanks, Matthias

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

Commit messages:
 - JDK-8273877

Changes: https://git.openjdk.java.net/jdk/pull/5561/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5561&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273877
  Stats: 13 lines in 3 files changed: 0 ins; 13 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5561/head:pull/5561

PR: https://git.openjdk.java.net/jdk/pull/5561

From mdoerr at openjdk.java.net  Fri Sep 17 11:59:44 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 17 Sep 2021 11:59:44 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms
In-Reply-To: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
Message-ID: <V5XeAXBLEWNNmvMXXu0uj0OJp5mtsg9Saw8TywkoIpM=.295e023d-7087-4059-8a1c-88743c4319b0@github.com>

On Thu, 16 Sep 2021 07:20:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.
> 
> Thanks, Matthias

Marked as reviewed by mdoerr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5540

From mdoerr at openjdk.java.net  Fri Sep 17 12:00:48 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 17 Sep 2021 12:00:48 GMT
Subject: RFR: JDK-8273877: os::unsetenv unused
In-Reply-To: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
References: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
Message-ID: <f8ZVbaOtuTudnBWL15Pt8lw3t-eV7x67W5TXyExY2Fg=.2ec4d9f3-8d85-4317-a94a-156d74a9bf4d@github.com>

On Fri, 17 Sep 2021 11:00:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It seems the HS function os::unsetenv is not used any more for some time and could be removed.
> 
> Thanks, Matthias

Marked as reviewed by mdoerr (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5561

From coleenp at openjdk.java.net  Fri Sep 17 12:05:47 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 17 Sep 2021 12:05:47 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v11]
In-Reply-To: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com>
Message-ID: <TRpEyhKyEgKG1xlNMjPYs6GIic0KrsBK-svMOIIiPPA=.67551263-107c-4c1f-8883-adade0d8e408@github.com>

On Mon, 13 Sep 2021 17:12:49 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove rehashing and rely on default grow_hint for table resize
>  - mtStatistics

src/hotspot/share/runtime/mutexLocker.cpp line 323:

> 321: 
> 322: #if INCLUDE_JFR
> 323:   def(JfrMsg_lock                  , PaddedMonitor, leaf-1,      true,  _safepoint_check_always); // -1 because the ConcurrentHashTable resize lock is leaf

The ConcurrentHashTable_lock is a lock that doesn't check for safepoints, so if you take this lock out while checking for safepoints, it should assert when called from a JavaThread, which makes me think it's not called from a JavaThread and should be _safepoint_check_never.
  _resize_lock =
    new Mutex(Mutex::nosafepoint-2, "ConcurrentHashTableResize_lock",
              Mutex::_safepoint_check_never);
In my change, this is the ranking for ConcurrentHashTableResize_lock, so this should be nosafepoint-3 if  you check in after I do.

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From mbaesken at openjdk.java.net  Fri Sep 17 12:28:42 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 12:28:42 GMT
Subject: RFR: JDK-8273877: os::unsetenv unused
In-Reply-To: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
References: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
Message-ID: <-HadfWDqOqwIbvlNvB-JloS0vO6awjPKG63uIP886h4=.49ae1852-db88-494e-936d-3e178163dcc4@github.com>

On Fri, 17 Sep 2021 11:00:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It seems the HS function os::unsetenv is not used any more for some time and could be removed.
> 
> Thanks, Matthias

Hi Martin, thanks for the approval !
Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5561

From mbaesken at openjdk.java.net  Fri Sep 17 12:29:44 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 12:29:44 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms
In-Reply-To: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
Message-ID: <PrQfEO3URuQTy_8aHmJfvJlqNL9T4F2AMJ8eYGJXMgI=.80e06033-7c73-4f01-a524-a8abc285b6c8@github.com>

On Thu, 16 Sep 2021 07:20:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.
> 
> Thanks, Matthias

Hi Martin, thanks for the approval !
Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5540

From stuefe at openjdk.java.net  Fri Sep 17 12:49:45 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 17 Sep 2021 12:49:45 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms
In-Reply-To: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
Message-ID: <TJQ75Fng8mlDEwa3jgPtsOFNVQmPdLfxrt-rQ33fY-E=.3e205cd1-b80a-4ad3-a722-27fd1f84d08e@github.com>

On Thu, 16 Sep 2021 07:20:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.
> 
> Thanks, Matthias

Looks good. Proposal for shorter code inline (if you take it, I need no re-review).

Cheers, Thomas

src/hotspot/os/posix/os_posix.cpp line 195:

> 193:   }
> 194:   return privileges;
> 195: }

Could be shortened to:

bool os::have_special_privileges() {
  static bool privileges = (getuid() != geteuid()) || (getgid() != getegid());
  return privileges;
}

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5540

From stuefe at openjdk.java.net  Fri Sep 17 12:51:42 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 17 Sep 2021 12:51:42 GMT
Subject: RFR: JDK-8273877: os::unsetenv unused
In-Reply-To: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
References: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
Message-ID: <ucl0nHBQzaAykA0YO-RpqCqc6fvmMuPWyX_BYUN-WX4=.bc37cded-7d58-457c-b2ca-c775b0be4245@github.com>

On Fri, 17 Sep 2021 11:00:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It seems the HS function os::unsetenv is not used any more for some time and could be removed.
> 
> Thanks, Matthias

Looks good and trivial.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5561

From mbaesken at openjdk.java.net  Fri Sep 17 12:56:51 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 12:56:51 GMT
Subject: RFR: JDK-8273877: os::unsetenv unused
In-Reply-To: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
References: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
Message-ID: <F6uE6nm_ZhNf-PMwqBLfbcqAAVhlJkp7PO48wHujShY=.72205a12-f53a-4bac-b427-9e89f8c7c761@github.com>

On Fri, 17 Sep 2021 11:00:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It seems the HS function os::unsetenv is not used any more for some time and could be removed.
> 
> Thanks, Matthias

Hi Thomas, thanks for the review !

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

PR: https://git.openjdk.java.net/jdk/pull/5561

From mbaesken at openjdk.java.net  Fri Sep 17 12:56:51 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 12:56:51 GMT
Subject: Integrated: JDK-8273877: os::unsetenv unused
In-Reply-To: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
References: <1ivf1XP8v3Iz59V0kUCgUtAju5Pp8eHUgjsCTu6_BMg=.fab30cbf-2e1c-4772-a6fd-b4ddc6521827@github.com>
Message-ID: <BmtirKRDTvUO6W9Qa8Sj31nG-E45jhdaSmwow7-uFrE=.ca65155f-792f-446f-a6bb-4a2718bf04b5@github.com>

On Fri, 17 Sep 2021 11:00:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small change.
> It seems the HS function os::unsetenv is not used any more for some time and could be removed.
> 
> Thanks, Matthias

This pull request has now been integrated.

Changeset: 27d747ad
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/27d747ad4f13193d5fc651d893540465248c48a6
Stats:     13 lines in 3 files changed: 0 ins; 13 del; 0 mod

8273877: os::unsetenv unused

Reviewed-by: mdoerr, stuefe

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

PR: https://git.openjdk.java.net/jdk/pull/5561

From mgronlun at openjdk.java.net  Fri Sep 17 13:55:45 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 17 Sep 2021 13:55:45 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v11]
In-Reply-To: <TRpEyhKyEgKG1xlNMjPYs6GIic0KrsBK-svMOIIiPPA=.67551263-107c-4c1f-8883-adade0d8e408@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com>
 <TRpEyhKyEgKG1xlNMjPYs6GIic0KrsBK-svMOIIiPPA=.67551263-107c-4c1f-8883-adade0d8e408@github.com>
Message-ID: <gATuOOdjp6j19jdjT0Pz1vf2ZdEYPuPNTWkpycJNaNo=.897a8190-0214-4111-bd55-607f1b6efd3d@github.com>

On Fri, 17 Sep 2021 12:02:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove rehashing and rely on default grow_hint for table resize
>>  - mtStatistics
>
> src/hotspot/share/runtime/mutexLocker.cpp line 323:
> 
>> 321: 
>> 322: #if INCLUDE_JFR
>> 323:   def(JfrMsg_lock                  , PaddedMonitor, leaf-1,      true,  _safepoint_check_always); // -1 because the ConcurrentHashTable resize lock is leaf
> 
> The ConcurrentHashTable_lock is a lock that doesn't check for safepoints, so if you take this lock out while checking for safepoints, it should assert when called from a JavaThread, which makes me think it's not called from a JavaThread and should be _safepoint_check_never.
>   _resize_lock =
>     new Mutex(Mutex::nosafepoint-2, "ConcurrentHashTableResize_lock",
>               Mutex::_safepoint_check_never);
> In my change, this is the ranking for ConcurrentHashTableResize_lock, so this should be nosafepoint-3 if  you check in after I do.

Thanks, the JfrMsg_lock is acquired normally with safepoint checks when the JFR system needs to issue synchronous, blocking operations. Asynchronous operations, like message notifications, only attempt a try_lock() to avoid blocking in the case the lock is contended. The ConcurrentHashTable_lock is held during table iteration to prevent resizes from happening. Fortunately, the callback processing will only post asynchronous messages (like "Buffer full") and therefore will not reach the safepoint check.

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From mbaesken at openjdk.java.net  Fri Sep 17 14:45:09 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 14:45:09 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms [v2]
In-Reply-To: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
Message-ID: <pMwjMHmrvarI0qc7aDlTinaD5iZExERQnz3Vra7MebA=.0a456cbe-97fb-4bbf-9096-9b81b9872b36@github.com>

> We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.
> 
> Thanks, Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Simplification proposed by Thomas Stuefe

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5540/files
  - new: https://git.openjdk.java.net/jdk/pull/5540/files/3e48d8cf..ed47cb34

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5540&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5540&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5540

From mbaesken at openjdk.java.net  Fri Sep 17 15:00:56 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 17 Sep 2021 15:00:56 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms [v2]
In-Reply-To: <TJQ75Fng8mlDEwa3jgPtsOFNVQmPdLfxrt-rQ33fY-E=.3e205cd1-b80a-4ad3-a722-27fd1f84d08e@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
 <TJQ75Fng8mlDEwa3jgPtsOFNVQmPdLfxrt-rQ33fY-E=.3e205cd1-b80a-4ad3-a722-27fd1f84d08e@github.com>
Message-ID: <rdsAp7NfHZQe0HGPF63FEuIGKi6niK6Miy2CBfo0rX8=.7ba16988-e43f-448f-b5b1-725386f0abce@github.com>

On Fri, 17 Sep 2021 12:44:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplification proposed by Thomas Stuefe
>
> src/hotspot/os/posix/os_posix.cpp line 195:
> 
>> 193:   }
>> 194:   return privileges;
>> 195: }
> 
> Could be shortened to:
> 
> bool os::have_special_privileges() {
>   static bool privileges = (getuid() != geteuid()) || (getgid() != getegid());
>   return privileges;
> }

Hi Thomas, thanks for the hint - I adjusted the coding.
Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5540

From mdoerr at openjdk.java.net  Fri Sep 17 15:24:43 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 17 Sep 2021 15:24:43 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms [v2]
In-Reply-To: <rdsAp7NfHZQe0HGPF63FEuIGKi6niK6Miy2CBfo0rX8=.7ba16988-e43f-448f-b5b1-725386f0abce@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
 <TJQ75Fng8mlDEwa3jgPtsOFNVQmPdLfxrt-rQ33fY-E=.3e205cd1-b80a-4ad3-a722-27fd1f84d08e@github.com>
 <rdsAp7NfHZQe0HGPF63FEuIGKi6niK6Miy2CBfo0rX8=.7ba16988-e43f-448f-b5b1-725386f0abce@github.com>
Message-ID: <-KhFVIHLsZL5cwu6Dw9qfIalf9vQKqV5hnL2r6QL4W4=.c3cfc805-bb1b-4287-aae5-b6cda2de3a09@github.com>

On Fri, 17 Sep 2021 14:57:37 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> src/hotspot/os/posix/os_posix.cpp line 195:
>> 
>>> 193:   }
>>> 194:   return privileges;
>>> 195: }
>> 
>> Could be shortened to:
>> 
>> bool os::have_special_privileges() {
>>   static bool privileges = (getuid() != geteuid()) || (getgid() != getegid());
>>   return privileges;
>> }
>
> Hi Thomas, thanks for the hint - I adjusted the coding.
> Best regards, Matthias

A static bool which gets evaluated on every call makes no sense!

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

PR: https://git.openjdk.java.net/jdk/pull/5540

From mdoerr at openjdk.java.net  Fri Sep 17 15:29:44 2021
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Fri, 17 Sep 2021 15:29:44 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms [v2]
In-Reply-To: <pMwjMHmrvarI0qc7aDlTinaD5iZExERQnz3Vra7MebA=.0a456cbe-97fb-4bbf-9096-9b81b9872b36@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
 <pMwjMHmrvarI0qc7aDlTinaD5iZExERQnz3Vra7MebA=.0a456cbe-97fb-4bbf-9096-9b81b9872b36@github.com>
Message-ID: <ur1lLBJ8rUEnzaVTr-8rml1oXcMwRvzAfmnH5MN_DMM=.b3c7eadd-a498-445d-8378-9d9c3473e1cb@github.com>

On Fri, 17 Sep 2021 14:45:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.
>> 
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplification proposed by Thomas Stuefe

Forget my comment. Still good.

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

Marked as reviewed by mdoerr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5540

From stuefe at openjdk.java.net  Fri Sep 17 15:48:44 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 17 Sep 2021 15:48:44 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms [v2]
In-Reply-To: <-KhFVIHLsZL5cwu6Dw9qfIalf9vQKqV5hnL2r6QL4W4=.c3cfc805-bb1b-4287-aae5-b6cda2de3a09@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
 <TJQ75Fng8mlDEwa3jgPtsOFNVQmPdLfxrt-rQ33fY-E=.3e205cd1-b80a-4ad3-a722-27fd1f84d08e@github.com>
 <rdsAp7NfHZQe0HGPF63FEuIGKi6niK6Miy2CBfo0rX8=.7ba16988-e43f-448f-b5b1-725386f0abce@github.com>
 <-KhFVIHLsZL5cwu6Dw9qfIalf9vQKqV5hnL2r6QL4W4=.c3cfc805-bb1b-4287-aae5-b6cda2de3a09@github.com>
Message-ID: <69IA1M_vxVhW6p3HTIqIkinBRwUhSMli653w8D7ZDRM=.c550e9b6-a721-48e7-a318-69fddded5ac7@github.com>

On Fri, 17 Sep 2021 15:21:51 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Hi Thomas, thanks for the hint - I adjusted the coding.
>> Best regards, Matthias
>
> A static bool which gets evaluated on every call makes no sense! Oh, wait! I think it's ok. I was only wondering why `privileges` should get initialized when `have_special_privileges()` is called for the first time and not during static initialization of the class. But it's at least equivalent to what we had before.

Now I am confused, what class? This is a global function with a function-local static variable.

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

PR: https://git.openjdk.java.net/jdk/pull/5540

From minqi at openjdk.java.net  Fri Sep 17 20:59:45 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 17 Sep 2021 20:59:45 GMT
Subject: RFR: 8273505:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl
 crashed with SIGSEGV in MetaspaceShared::link_shared_classes
In-Reply-To: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>
References: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>
Message-ID: <hFxtnP1nPfJUUaqYNfs52Tb0En43MvqEvdbo0YH2ewM=.1573e9a9-6ace-4b67-8a16-39d51bdc1523@github.com>

On Fri, 17 Sep 2021 17:56:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small patch for keeping the class loader, which is the holder of the `ClassLoaderData`, alive during class linking within `MetaspaceShared::link_shared_classes()`. Prior to this fix, the `ClassLoaderData::inc_keep_alive()` was used in an attempt to keep the `ClassLoaderData` alive but that was for hidden classes only.
> 
> Testing: tiers 1 - 4.

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5566

From iklam at openjdk.java.net  Fri Sep 17 18:53:45 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 17 Sep 2021 18:53:45 GMT
Subject: RFR: 8273505:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl
 crashed with SIGSEGV in MetaspaceShared::link_shared_classes
In-Reply-To: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>
References: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>
Message-ID: <cSEvpv1CAqHVLZ87YfPImkSv5e3smGxvj73_GOTrWTQ=.35e8ac2b-0655-4a2e-bcf8-262f9301f06e@github.com>

On Fri, 17 Sep 2021 17:56:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small patch for keeping the class loader, which is the holder of the `ClassLoaderData`, alive during class linking within `MetaspaceShared::link_shared_classes()`. Prior to this fix, the `ClassLoaderData::inc_keep_alive()` was used in an attempt to keep the `ClassLoaderData` alive but that was for hidden classes only.
> 
> Testing: tiers 1 - 4.

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5566

From ccheung at openjdk.java.net  Fri Sep 17 18:04:57 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 17 Sep 2021 18:04:57 GMT
Subject: RFR: 8273505:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl
 crashed with SIGSEGV in MetaspaceShared::link_shared_classes
Message-ID: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>

Please review this small patch for keeping the class loader, which is the holder of the `ClassLoaderData`, alive during class linking within `MetaspaceShared::link_shared_classes()`. Prior to this fix, the `ClassLoaderData::inc_keep_alive()` was used in an attempt to keep the `ClassLoaderData` alive but that was for hidden classes only.

Testing: tiers 1 - 4.

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

Commit messages:
 - 8273505: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl crashed with SIGSEGV in MetaspaceShared::link_shared_classes

Changes: https://git.openjdk.java.net/jdk/pull/5566/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5566&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273505
  Stats: 15 lines in 2 files changed: 5 ins; 7 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5566.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5566/head:pull/5566

PR: https://git.openjdk.java.net/jdk/pull/5566

From mseledtsov at openjdk.java.net  Sat Sep 18 00:22:01 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Sat, 18 Sep 2021 00:22:01 GMT
Subject: RFR: JDK-8267163: Rename anonymous loader tests to hidden loader tests
Message-ID: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>

Please review this simple change that renames vm/mlvm tests and test package name from anonymous to hidden.
Testing:
  Ran open/test/hotspot/jtreg/vmTestbase/vm/mlvm on MacOS-x64: PASS
  Running open/test/hotspot/jtreg/vmTestbase/vm/mlvm on multiple platforms: in progress ...

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

Commit messages:
 - Renamed AnonkTestee* to HiddenkTestee*
 - Renamed package name except for VM testbase conversion comment
 - Renamed Anonk classes
 - Renamed classes
 - Renamed anonloader to hiddenloader

Changes: https://git.openjdk.java.net/jdk/pull/5570/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5570&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267163
  Stats: 1268 lines in 21 files changed: 631 ins; 631 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5570.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5570/head:pull/5570

PR: https://git.openjdk.java.net/jdk/pull/5570

From mseledtsov at openjdk.java.net  Sat Sep 18 00:22:02 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Sat, 18 Sep 2021 00:22:02 GMT
Subject: RFR: JDK-8267163: Rename anonymous loader tests to hidden loader
 tests
In-Reply-To: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
References: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
Message-ID: <XuGIg8Jhagq4kYrQmOHfPdqVOjI1Gm2WJjXrdhSDhe4=.526583ba-1d5b-4393-aa63-b9a379691226@github.com>

On Sat, 18 Sep 2021 00:16:08 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this simple change that renames vm/mlvm tests and test package name from anonymous to hidden.
> Testing:
>   Ran open/test/hotspot/jtreg/vmTestbase/vm/mlvm on MacOS-x64: PASS
>   Running open/test/hotspot/jtreg/vmTestbase/vm/mlvm on multiple platforms: in progress ...

@hseigel Harold, please review when you have a chance.

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

PR: https://git.openjdk.java.net/jdk/pull/5570

From stuefe at openjdk.java.net  Sat Sep 18 05:36:28 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 18 Sep 2021 05:36:28 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling [v3]
In-Reply-To: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
Message-ID: <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>

> Hi,
> 
> may I please have reviews for this patch.
> 
> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
> 
> ----
> 
> Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.
> 
> I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.
> 
> When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, this became a nuisance and I'd like to simplify this. 
> 
> The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 
> 
> The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.
> 
> The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.
> 
> Small caveats:
> - the first block in a chunk has no leading fence
> - the last block in a chunk *may* have no trailing fence
> - the guard now costs 24 bytes, up from 16 before.
> 
> Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.
> 
> Tests:
> - Nightlies at SAP
> - manual tests on x64 and x86 with and without guards
> - manual gtests
> - manual metaspace jtreg tests
> 
> Thanks, Thomas

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 three additional commits since the last revision:

 - Merge
 - Reduce diff and improve comments
 - JDK-8273783-Simplify-metaspace-arena-guard-handling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5518/files
  - new: https://git.openjdk.java.net/jdk/pull/5518/files/8738a84c..61d6efb6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5518&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5518&range=01-02

  Stats: 1588 lines in 55 files changed: 1062 ins; 402 del; 124 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5518/head:pull/5518

PR: https://git.openjdk.java.net/jdk/pull/5518

From yyang at openjdk.java.net  Sat Sep 18 07:52:29 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 18 Sep 2021 07:52:29 GMT
Subject: RFR: 8272114: Unused _last_state in osThread_windows
Message-ID: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>

Unused _last_state in osThread_windows? its getter and setter can be removed as well.

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

Commit messages:
 - remove

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

PR: https://git.openjdk.java.net/jdk/pull/5572

From stuefe at openjdk.java.net  Sat Sep 18 08:14:00 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 18 Sep 2021 08:14:00 GMT
Subject: RFR: JDK-8273958: gtest/MetaspaceGtests executes unnecessary tests in
 debug builds
Message-ID: <-oos37ohbNlDIKtW9pSVsySIt_XMAIsz9oKOeRWHSps=.4dc6b68f-c1f1-4f51-83cf-fe40dcd26a7b@github.com>

May I please have reviews for this trivial fix.

We miss two "debug==false" requires rules on tests meant for non-debug only. Taking them out reduces test runtime on debug by ~20 seconds.

I also shifted some of the existing requires tags down to cluster them together in one place, for better clarity.

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

Commit messages:
 - JDK-8273958-gtest-MetaspaceGtests-executes-unnecessary-tests-in-debug-builds

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

PR: https://git.openjdk.java.net/jdk/pull/5571

From jiefu at openjdk.java.net  Sat Sep 18 08:27:45 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 18 Sep 2021 08:27:45 GMT
Subject: RFR: JDK-8273958: gtest/MetaspaceGtests executes unnecessary
 tests in debug builds
In-Reply-To: <-oos37ohbNlDIKtW9pSVsySIt_XMAIsz9oKOeRWHSps=.4dc6b68f-c1f1-4f51-83cf-fe40dcd26a7b@github.com>
References: <-oos37ohbNlDIKtW9pSVsySIt_XMAIsz9oKOeRWHSps=.4dc6b68f-c1f1-4f51-83cf-fe40dcd26a7b@github.com>
Message-ID: <rLU9ZR2mLIUsl4PxepdP0ZNVm6Cp4Vt52xjFho4Dx58=.3d6e06cf-8e2f-4dca-ab30-6d7ce92ebaed@github.com>

On Sat, 18 Sep 2021 06:36:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I please have reviews for this trivial fix.
> 
> We miss two "debug==false" requires rules on tests meant for non-debug only. Taking them out reduces test runtime on debug by ~20 seconds.
> 
> I also shifted some of the existing requires tags down to cluster them together in one place, for better clarity.

Looks good and trivial.

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

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5571

From stuefe at openjdk.java.net  Sat Sep 18 08:32:48 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 18 Sep 2021 08:32:48 GMT
Subject: RFR: JDK-8273958: gtest/MetaspaceGtests executes unnecessary
 tests in debug builds
In-Reply-To: <rLU9ZR2mLIUsl4PxepdP0ZNVm6Cp4Vt52xjFho4Dx58=.3d6e06cf-8e2f-4dca-ab30-6d7ce92ebaed@github.com>
References: <-oos37ohbNlDIKtW9pSVsySIt_XMAIsz9oKOeRWHSps=.4dc6b68f-c1f1-4f51-83cf-fe40dcd26a7b@github.com>
 <rLU9ZR2mLIUsl4PxepdP0ZNVm6Cp4Vt52xjFho4Dx58=.3d6e06cf-8e2f-4dca-ab30-6d7ce92ebaed@github.com>
Message-ID: <7e1KrHiJ8ag15dU1rEMrXCOE4zYY4QGChANpXVOo8rg=.2320fb82-64d3-4b93-9679-7bae374a959d@github.com>

On Sat, 18 Sep 2021 08:24:30 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Looks good and trivial.

Thank you!

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

PR: https://git.openjdk.java.net/jdk/pull/5571

From stuefe at openjdk.java.net  Sat Sep 18 08:32:48 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 18 Sep 2021 08:32:48 GMT
Subject: Integrated: JDK-8273958: gtest/MetaspaceGtests executes unnecessary
 tests in debug builds
In-Reply-To: <-oos37ohbNlDIKtW9pSVsySIt_XMAIsz9oKOeRWHSps=.4dc6b68f-c1f1-4f51-83cf-fe40dcd26a7b@github.com>
References: <-oos37ohbNlDIKtW9pSVsySIt_XMAIsz9oKOeRWHSps=.4dc6b68f-c1f1-4f51-83cf-fe40dcd26a7b@github.com>
Message-ID: <VZzn3LLwWYgNOhqE03k9Wx8X42TRgkJbCYQAqeyjAjA=.463f08ee-bf95-4b0e-bd98-e6cf7b2c19cd@github.com>

On Sat, 18 Sep 2021 06:36:50 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I please have reviews for this trivial fix.
> 
> We miss two "debug==false" requires rules on tests meant for non-debug only. Taking them out reduces test runtime on debug by ~20 seconds.
> 
> I also shifted some of the existing requires tags down to cluster them together in one place, for better clarity.

This pull request has now been integrated.

Changeset: bb9d1427
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bb9d142759ece7665329b124a8ea0b16049b024a
Stats:     10 lines in 1 file changed: 6 ins; 4 del; 0 mod

8273958: gtest/MetaspaceGtests executes unnecessary tests in debug builds

Reviewed-by: jiefu

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

PR: https://git.openjdk.java.net/jdk/pull/5571

From stuefe at openjdk.java.net  Sat Sep 18 08:44:13 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 18 Sep 2021 08:44:13 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be develop
Message-ID: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>

May I have reviews please for this fix.

The switches `MetaspaceHandleDeallocations` and `MetaspaceGuardAllocations` control debug-only features and consequently should be develop instead.

Unnecessary usage of -XX:+UnlockDiagnosticVMOptions is removed (in two cases unrelated to the changed switches).

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

Commit messages:
 - JDK-8273959-Some-metaspace-diagnostic-switches-should-be-develop

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

PR: https://git.openjdk.java.net/jdk/pull/5573

From stuefe at openjdk.java.net  Sat Sep 18 08:48:42 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 18 Sep 2021 08:48:42 GMT
Subject: RFR: 8272114: Unused _last_state in osThread_windows
In-Reply-To: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
References: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
Message-ID: <aGu60895AuJguKNSFIOGSXtavsZFvER_O3OZD1Hil4A=.ca6b580d-727e-4590-8650-69c83b376faf@github.com>

On Sat, 18 Sep 2021 07:44:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Trivial change to remove unused _last_state in osThread_windows? its getter and setter can be removed as well.

Good and trivial. Tried to find out the history, but AFAICS its been in there since the beginning of OpenJDK.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5572

From jiefu at openjdk.java.net  Sat Sep 18 08:50:43 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sat, 18 Sep 2021 08:50:43 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
Message-ID: <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>

On Sat, 18 Sep 2021 08:37:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I have reviews please for this fix.
> 
> The switches `MetaspaceHandleDeallocations` and `MetaspaceGuardAllocations` control debug-only features and consequently should be develop instead.
> 
> Unnecessary usage of -XX:+UnlockDiagnosticVMOptions is removed (in two cases unrelated to the changed switches).

Do we need a CSR for this change?

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

PR: https://git.openjdk.java.net/jdk/pull/5573

From stuefe at openjdk.java.net  Sat Sep 18 08:55:49 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 18 Sep 2021 08:55:49 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
 <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>
Message-ID: <bV6w29WV3qPc-YYVX7QqAt8DBBX0fUQEfQJgX9-v7nQ=.44310e9b-a2d4-49c2-9e74-9cffd330865a@github.com>

On Sat, 18 Sep 2021 08:48:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Do we need a CSR for this change?

God no :) These were diagnostic switches only used in tests (and I believe, only used by me).

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

PR: https://git.openjdk.java.net/jdk/pull/5573

From yyang at openjdk.java.net  Sat Sep 18 12:23:42 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 18 Sep 2021 12:23:42 GMT
Subject: RFR: 8272114: Unused _last_state in osThread_windows
In-Reply-To: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
References: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
Message-ID: <nPZm3HlvnVNWlnKloytgLFbef99zJ6VP4kQW4yD2EpE=.df5a4090-0d8e-421d-8826-af117327fa0c@github.com>

On Sat, 18 Sep 2021 07:44:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Trivial change to remove unused _last_state in osThread_windows? its getter and setter can be removed as well.

Yes, it predates the history of OPENjdk.

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

PR: https://git.openjdk.java.net/jdk/pull/5572

From dholmes at openjdk.java.net  Sat Sep 18 23:51:48 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 18 Sep 2021 23:51:48 GMT
Subject: RFR: 8272114: Unused _last_state in osThread_windows
In-Reply-To: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
References: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
Message-ID: <5tmX6mRF0l2phVmRfapG4wTT-FYSg6_byumxryFs4C8=.e6976acb-43f7-4f06-bb1b-139346a97f90@github.com>

On Sat, 18 Sep 2021 07:44:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Trivial change to remove unused _last_state in osThread_windows? its getter and setter can be removed as well.

Well spotted! :)

Added in November 2000 as a temporary fix as per the comment. But too much effort to try and figure out when it became dead code.

Cheers,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5572

From dholmes at openjdk.java.net  Sun Sep 19 23:11:09 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Sep 2021 23:11:09 GMT
Subject: RFR: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms [v2]
In-Reply-To: <pMwjMHmrvarI0qc7aDlTinaD5iZExERQnz3Vra7MebA=.0a456cbe-97fb-4bbf-9096-9b81b9872b36@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
 <pMwjMHmrvarI0qc7aDlTinaD5iZExERQnz3Vra7MebA=.0a456cbe-97fb-4bbf-9096-9b81b9872b36@github.com>
Message-ID: <UlO9zQ7X3Zxj4xDeSpABvo8WjeUtIwmKqt5a8LwkqsI=.8e1e89ed-d878-435a-a7cd-355c6a46876c@github.com>

On Fri, 17 Sep 2021 14:45:09 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.
>> 
>> Thanks, Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplification proposed by Thomas Stuefe

As an equivalent refactoring this is fine.

We could also do the initialization is os::init() but it makes little, if any difference.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5540

From dholmes at openjdk.java.net  Sun Sep 19 23:31:59 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Sep 2021 23:31:59 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
Message-ID: <vCyJGYuXQwwoAPzFJG3aeL0s22lS604WwXhmrUeFGPY=.3c650906-0fa7-4a64-b0f6-ce5ae9823692@github.com>

On Sat, 18 Sep 2021 08:37:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I have reviews please for this fix.
> 
> The switches `MetaspaceHandleDeallocations` and `MetaspaceGuardAllocations` control debug-only features and consequently should be develop instead.
> 
> Unnecessary usage of -XX:+UnlockDiagnosticVMOptions is removed (in two cases unrelated to the changed switches).

LGTM!

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5573

From dholmes at openjdk.java.net  Sun Sep 19 23:35:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Sep 2021 23:35:53 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
 <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>
Message-ID: <_viq4vQTxU-5b_gDFMSiD2XLE37q3PcHZXlE8aOTNdU=.14efbfe5-ad36-423f-a4e8-b731fd0943c7@github.com>

On Sat, 18 Sep 2021 08:48:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> May I have reviews please for this fix.
>> 
>> The switches `MetaspaceHandleDeallocations` and `MetaspaceGuardAllocations` control debug-only features and consequently should be develop instead.
>> 
>> Unnecessary usage of -XX:+UnlockDiagnosticVMOptions is removed (in two cases unrelated to the changed switches).
>
> Do we need a CSR for this change?

@DamonFool  for reference: https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process

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

PR: https://git.openjdk.java.net/jdk/pull/5573

From dholmes at openjdk.java.net  Sun Sep 19 23:41:52 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 19 Sep 2021 23:41:52 GMT
Subject: RFR: JDK-8267163: Rename anonymous loader tests to hidden loader
 tests
In-Reply-To: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
References: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
Message-ID: <MvPauDxtMC6pfhvrLL-oGG3XmfxOh4T2LWAuqyuhI40=.21eb0aee-126d-42a4-8ea4-eee98b4fdba5@github.com>

On Sat, 18 Sep 2021 00:16:08 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this simple change that renames vm/mlvm tests and test package name from anonymous to hidden.
> Testing:
>   Ran open/test/hotspot/jtreg/vmTestbase/vm/mlvm on MacOS-x64: PASS
>   Running open/test/hotspot/jtreg/vmTestbase/vm/mlvm on multiple platforms: in progress ...

Hi Misha,

This renaming seems fine.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5570

From jiefu at openjdk.java.net  Sun Sep 19 23:42:49 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 19 Sep 2021 23:42:49 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
Message-ID: <ZxSlioDN-N31dIZ5SmAxQwYQuLhFyBoUqIEMzcKD6YE=.ab63e52c-0979-486b-9ad2-6ff08765f01a@github.com>

On Sat, 18 Sep 2021 08:37:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I have reviews please for this fix.
> 
> The switches `MetaspaceHandleDeallocations` and `MetaspaceGuardAllocations` control debug-only features and consequently should be develop instead.
> 
> Unnecessary usage of -XX:+UnlockDiagnosticVMOptions is removed (in two cases unrelated to the changed switches).

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5573

From jiefu at openjdk.java.net  Sun Sep 19 23:42:49 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Sun, 19 Sep 2021 23:42:49 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
 <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>
Message-ID: <rq8RKL4J6lo6ja1qdo0AxpzNwBPca2uBDaZiJJr2gSU=.2dcc259f-02e3-467e-897d-0a7b0446ad44@github.com>

On Sat, 18 Sep 2021 08:48:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> May I have reviews please for this fix.
>> 
>> The switches `MetaspaceHandleDeallocations` and `MetaspaceGuardAllocations` control debug-only features and consequently should be develop instead.
>> 
>> Unnecessary usage of -XX:+UnlockDiagnosticVMOptions is removed (in two cases unrelated to the changed switches).
>
> Do we need a CSR for this change?

> @DamonFool for reference: https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process

Got it.
Thanks @dholmes-ora .

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

PR: https://git.openjdk.java.net/jdk/pull/5573

From david.holmes at oracle.com  Mon Sep 20 05:31:31 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 20 Sep 2021 15:31:31 +1000
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling
In-Reply-To: <AwXrkDwtIc5poDRGu0pe1PuMM43bwmk3nner9d0kDXc=.28458a3a-4e88-4556-93a7-4139ec4f43db@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
 <AwXrkDwtIc5poDRGu0pe1PuMM43bwmk3nner9d0kDXc=.28458a3a-4e88-4556-93a7-4139ec4f43db@github.com>
Message-ID: <ec1d39c8-4366-46e7-e4e3-6b30771260a6@oracle.com>

On 17/09/2021 11:54 am, David Holmes wrote:
> On Wed, 15 Sep 2021 06:10:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> 
>> Hi,
>>
>> may I please have reviews for this patch.
>>
>> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
>>
> 
> I can't really review this, but I'm running it through our internal tier 1-3 testing.

That testing passed - one unrelated crash.

David

> David
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/5518
> 

From stuefe at openjdk.java.net  Mon Sep 20 05:46:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 20 Sep 2021 05:46:54 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling [v3]
In-Reply-To: <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
 <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
Message-ID: <XCnN-U_9Yygn1QYjmvDMXb5bx0doV70zkv2XBI3kcTw=.b6118ed8-4ae5-415c-a297-926660a46cd4@github.com>

On Sat, 18 Sep 2021 05:36:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi,
>> 
>> may I please have reviews for this patch.
>> 
>> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
>> 
>> ----
>> 
>> Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.
>> 
>> I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.
>> 
>> When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, working around all that special handling became too complicated and therefore I'd like a simpler solution.
>> 
>> The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 
>> 
>> The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.
>> 
>> The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.
>> 
>> Small caveats:
>> - the first block in a chunk has no leading fence
>> - the last block in a chunk *may* have no trailing fence
>> - the guard now costs 24 bytes, up from 16 before.
>> 
>> Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.
>> 
>> Tests:
>> - Nightlies at SAP
>> - manual tests on x64 and x86 with and without guards
>> - manual gtests
>> - manual metaspace jtreg tests
>> 
>> Thanks, Thomas
>
> 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 three additional commits since the last revision:
> 
>  - Merge
>  - Reduce diff and improve comments
>  - JDK-8273783-Simplify-metaspace-arena-guard-handling

> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at mail.openjdk.java.net):_
> 
> On 17/09/2021 11:54 am, David Holmes wrote:
> 
> > On Wed, 15 Sep 2021 06:10:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:
> > > Hi,
> > > may I please have reviews for this patch.
> > > This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
> > 
> > 
> > I can't really review this, but I'm running it through our internal tier 1-3 testing.
> 
> That testing passed - one unrelated crash.
> 
> David

 Thank you David!

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

PR: https://git.openjdk.java.net/jdk/pull/5518

From stuefe at openjdk.java.net  Mon Sep 20 05:47:47 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 20 Sep 2021 05:47:47 GMT
Subject: RFR: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <rq8RKL4J6lo6ja1qdo0AxpzNwBPca2uBDaZiJJr2gSU=.2dcc259f-02e3-467e-897d-0a7b0446ad44@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
 <31rCelPaJPHnibirbJHQscZbEwtQktB0VYPO_lo1IiM=.44d38c25-6547-4d6b-8535-495edd191a81@github.com>
 <rq8RKL4J6lo6ja1qdo0AxpzNwBPca2uBDaZiJJr2gSU=.2dcc259f-02e3-467e-897d-0a7b0446ad44@github.com>
Message-ID: <4Mi7hRJqh9S1mkxpoD0nVfwdmdIl_gHl05BMTLDumy0=.414cfe7f-dfd5-4e5e-81a4-ec07e9f84e9b@github.com>

On Sun, 19 Sep 2021 23:39:31 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Do we need a CSR for this change?
>
>> @DamonFool for reference: https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process
> 
> Got it.
> Thanks @dholmes-ora .

Thank you @DamonFool and @dholmes-ora !

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

PR: https://git.openjdk.java.net/jdk/pull/5573

From mbaesken at openjdk.java.net  Mon Sep 20 08:33:56 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 20 Sep 2021 08:33:56 GMT
Subject: Integrated: JDK-8273815: move have_special_privileges to os_posix for
 POSIX platforms
In-Reply-To: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
References: <hE-HWmUikYruhw8WMbolfRbc0apM2K-jVRcvoybQ9n4=.f9d598e9-febb-4803-9dcd-46135b85713d@github.com>
Message-ID: <An15OW2y789btlVqQkGipAlSdM_g4vb7CcaxEC2kqWo=.92c26241-0647-4ca2-b77f-c1f136af7b39@github.com>

On Thu, 16 Sep 2021 07:20:39 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> We have identical have_special_privileges() for Linux/AIX/BSD so the function is a good candidate to be moved to os_posix.
> 
> Thanks, Matthias

This pull request has now been integrated.

Changeset: dc7f452a
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dc7f452acbe3afa5aa6e31d316bd5e669c86d6f6
Stats:     45 lines in 4 files changed: 6 ins; 39 del; 0 mod

8273815: move have_special_privileges to os_posix for POSIX platforms

Reviewed-by: mdoerr, stuefe, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5540

From stuefe at openjdk.java.net  Mon Sep 20 08:49:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Mon, 20 Sep 2021 08:49:54 GMT
Subject: Integrated: JDK-8273959: Some metaspace diagnostic switches should be
 develop
In-Reply-To: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
References: <2uhO8ByuRBRfNyvhqVmKaEwDnz7j4q4kwBmIyf3fNYc=.8ecd09a9-d505-4bc3-8593-836e1bdf5504@github.com>
Message-ID: <nLJwUZa-y929P9cbzFjpQjEJ87CNAdBtBGAW1FVVTCM=.47fddf18-dd2d-4596-aca3-c9fdfbbffb3a@github.com>

On Sat, 18 Sep 2021 08:37:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> May I have reviews please for this fix.
> 
> The switches `MetaspaceHandleDeallocations` and `MetaspaceGuardAllocations` control debug-only features and consequently should be develop instead.
> 
> Unnecessary usage of -XX:+UnlockDiagnosticVMOptions is removed (in two cases unrelated to the changed switches).

This pull request has now been integrated.

Changeset: d2388b7a
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2388b7a0f4bfb55ea0d5648175e3253f30a4302
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8273959: Some metaspace diagnostic switches should be develop

Reviewed-by: dholmes, jiefu

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

PR: https://git.openjdk.java.net/jdk/pull/5573

From hseigel at openjdk.java.net  Mon Sep 20 12:49:55 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 20 Sep 2021 12:49:55 GMT
Subject: RFR: JDK-8267163: Rename anonymous loader tests to hidden loader
 tests
In-Reply-To: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
References: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
Message-ID: <8beyLqeoJtvlEd0nqumHG4EEHlRvDc1w6DmcKA7L3xo=.f4e13bd3-35c9-45ad-a96c-04f825b4d9c0@github.com>

On Sat, 18 Sep 2021 00:16:08 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this simple change that renames vm/mlvm tests and test package name from anonymous to hidden.
> Testing:
>   Ran open/test/hotspot/jtreg/vmTestbase/vm/mlvm on MacOS-x64: PASS
>   Running open/test/hotspot/jtreg/vmTestbase/vm/mlvm on multiple platforms: in progress ...

The changes look good.  Thanks for doing this.
Harold

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

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5570

From mbaesken at openjdk.java.net  Mon Sep 20 13:49:37 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 20 Sep 2021 13:49:37 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix for
 POSIX platforms
Message-ID: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>

There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 

Best regards , Matthias

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

Commit messages:
 - JDK-8273979

Changes: https://git.openjdk.java.net/jdk/pull/5582/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5582&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273979
  Stats: 255 lines in 4 files changed: 65 ins; 187 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5582/head:pull/5582

PR: https://git.openjdk.java.net/jdk/pull/5582

From minqi at openjdk.java.net  Mon Sep 20 16:08:20 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 20 Sep 2021 16:08:20 GMT
Subject: RFR: 8273152: Store base archive path in CDSFileMapHeaderBase
Message-ID: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>

Store base archive path offset in CDSFileMapHeaderBase (which should be invariant in evolving versions) so we can read the base archive name reliably from dynamic archive even with variant header sizes over versions.

tests: tier1-4

Thanks
Yumin

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

Commit messages:
 - 8273152: Store base archive path in CDSFileMapHeaderBase

Changes: https://git.openjdk.java.net/jdk/pull/5584/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5584&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273152
  Stats: 48 lines in 7 files changed: 27 ins; 4 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5584.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5584/head:pull/5584

PR: https://git.openjdk.java.net/jdk/pull/5584

From ccheung at openjdk.java.net  Mon Sep 20 16:56:56 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 20 Sep 2021 16:56:56 GMT
Subject: RFR: 8273505:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl
 crashed with SIGSEGV in MetaspaceShared::link_shared_classes
In-Reply-To: <cSEvpv1CAqHVLZ87YfPImkSv5e3smGxvj73_GOTrWTQ=.35e8ac2b-0655-4a2e-bcf8-262f9301f06e@github.com>
References: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>
 <cSEvpv1CAqHVLZ87YfPImkSv5e3smGxvj73_GOTrWTQ=.35e8ac2b-0655-4a2e-bcf8-262f9301f06e@github.com>
Message-ID: <p4O0JycTJp_00u8_SExxKhmaSXmcoZGx_D-HApPXcog=.cd40229e-134e-48fe-8a3c-e7028f142498@github.com>

On Fri, 17 Sep 2021 18:50:49 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Please review this small patch for keeping the class loader, which is the holder of the `ClassLoaderData`, alive during class linking within `MetaspaceShared::link_shared_classes()`. Prior to this fix, the `ClassLoaderData::inc_keep_alive()` was used in an attempt to keep the `ClassLoaderData` alive but that was for hidden classes only.
>> 
>> Testing: tiers 1 - 4.
>
> LGTM

Thanks @iklam, @yminqi for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/5566

From ccheung at openjdk.java.net  Mon Sep 20 16:59:59 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 20 Sep 2021 16:59:59 GMT
Subject: Integrated: 8273505:
 runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl
 crashed with SIGSEGV in MetaspaceShared::link_shared_classes
In-Reply-To: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>
References: <mxRs4o5IfvdTEUyefavqjLq6PVF6LV2OUqgqAC97KoY=.e2b6e046-57a7-4ca0-87d0-839e55a5e0b3@github.com>
Message-ID: <Lfgbtp7f6YthJEMDfArNY_1zjSIB-HIO48WLfIG0maQ=.60f8df60-14ce-4b9f-9ebc-4858db1b412f@github.com>

On Fri, 17 Sep 2021 17:56:44 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Please review this small patch for keeping the class loader, which is the holder of the `ClassLoaderData`, alive during class linking within `MetaspaceShared::link_shared_classes()`. Prior to this fix, the `ClassLoaderData::inc_keep_alive()` was used in an attempt to keep the `ClassLoaderData` alive but that was for hidden classes only.
> 
> Testing: tiers 1 - 4.

This pull request has now been integrated.

Changeset: a67f0f9d
Author:    Calvin Cheung <ccheung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a67f0f9dc04200c22db05e277346f24d31306b53
Stats:     15 lines in 2 files changed: 5 ins; 7 del; 3 mod

8273505: runtime/cds/appcds/loaderConstraints/DynamicLoaderConstraintsTest.java#default-cl crashed with SIGSEGV in MetaspaceShared::link_shared_classes

Reviewed-by: iklam, minqi

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

PR: https://git.openjdk.java.net/jdk/pull/5566

From iklam at openjdk.java.net  Mon Sep 20 17:25:54 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 20 Sep 2021 17:25:54 GMT
Subject: RFR: 8273152: Store base archive path in CDSFileMapHeaderBase
In-Reply-To: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
References: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
Message-ID: <eaCyYUs7g4e1IK86VQKKhtjTrIZyiP3uzcwhVrpC5qw=.26cbc14d-4965-4b8a-9a03-494d58d81097@github.com>

On Mon, 20 Sep 2021 15:58:54 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Store base archive path offset in CDSFileMapHeaderBase (which should be invariant in evolving versions) so we can read the base archive name reliably from dynamic archive even with variant header sizes over versions.
> 
> tests: tier1-4
> 
> Thanks
> Yumin

Changes requested by iklam (Reviewer).

src/hotspot/share/include/cds.h line 67:

> 65:   int          _crc;             // header crc checksum
> 66:   int          _version;         // must be CURRENT_CDS_ARCHIVE_VERSION
> 67:   int _base_archive_path_offset; // This field is present with (_version >= 12). It's declaration

`CURRENT_CDS_ARCHIVE_VERSION` in this file should also be changed to 12.

Typo: `It's declaration` -> `Its declaration`

For safety, I think we need an extra field, and also `change _base_archive_path_offse` to unsigned:


  int          _version; 
+ unsigned int _header_size;       // total size of the header, in bytes
! unsigned int _base_archive_path_offset;
 ```

We need new test cases for safety checks:

1. _header_size is larger than the size of the archive file.
2. _base_archive_path_offset points is not zero for static archive.
3. For dynamic archive: _base_archive_path_offset points beyond _header_size
4. For dynamic archive: `(((char*)this) + _base_archive_path_offset)` does not point to a zero-terminated string. I.e., there is no zero byte between `(((char*)this) + _base_archive_path_offset)` and the end of the header.

Also, we should add something like this in the very beginning of the structure. E.g., we don't want someone to add a field in the middle of them.


// The declaration of the following 5 fields must never be changed
// in any future versions of HotSpot

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

PR: https://git.openjdk.java.net/jdk/pull/5584

From mseledtsov at openjdk.java.net  Mon Sep 20 17:38:22 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 20 Sep 2021 17:38:22 GMT
Subject: RFR: JDK-8267163: Rename anonymous loader tests to hidden loader
 tests [v2]
In-Reply-To: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
References: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
Message-ID: <Tfu88f_qZm8CfK2GZotS4-tqobRzHM1_tJbejEPrbbQ=.28a72f48-cf06-4c85-936c-785b1b3abdad@github.com>

> Please review this simple change that renames vm/mlvm tests and test package name from anonymous to hidden.
> Testing:
>   Ran open/test/hotspot/jtreg/vmTestbase/vm/mlvm on MacOS-x64: PASS
>   Running open/test/hotspot/jtreg/vmTestbase/vm/mlvm on multiple platforms: in progress ...

Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:

  Updated problem list for Xcomp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5570/files
  - new: https://git.openjdk.java.net/jdk/pull/5570/files/959604ef..de437bc2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5570&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5570&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5570

From rschmelter at openjdk.java.net  Mon Sep 20 17:50:33 2021
From: rschmelter at openjdk.java.net (Ralf Schmelter)
Date: Mon, 20 Sep 2021 17:50:33 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v37]
In-Reply-To: <hdu5sGnna15CL1ZPzod-gwZa5v_KHgE4Nk_lSLJwz20=.716aa807-dc25-4d3c-9a94-24f8f30d9a53@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <hdu5sGnna15CL1ZPzod-gwZa5v_KHgE4Nk_lSLJwz20=.716aa807-dc25-4d3c-9a94-24f8f30d9a53@github.com>
Message-ID: <n94n9nnuDNHTQrr-GBJ8fK6qoHVLrPa9exYuY_wjhqI=.09f78eaa-0da1-4ce8-94ff-761fb2a09821@github.com>

On Thu, 16 Sep 2021 09:35:20 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 8252842: Extend jmap to support parallel heap dump
>
> Lin Zang 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.

Looks good to me.

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

Marked as reviewed by rschmelter (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2261

From mseledtsov at openjdk.java.net  Mon Sep 20 19:07:54 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 20 Sep 2021 19:07:54 GMT
Subject: RFR: JDK-8267163: Rename anonymous loader tests to hidden loader
 tests [v2]
In-Reply-To: <Tfu88f_qZm8CfK2GZotS4-tqobRzHM1_tJbejEPrbbQ=.28a72f48-cf06-4c85-936c-785b1b3abdad@github.com>
References: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
 <Tfu88f_qZm8CfK2GZotS4-tqobRzHM1_tJbejEPrbbQ=.28a72f48-cf06-4c85-936c-785b1b3abdad@github.com>
Message-ID: <nm-hW05j4vkScBjkqP_2xSwCkjqFNg6D3gFD-n-c1_0=.c42d4f07-7833-4890-8e8e-fdf1f4a2301b@github.com>

On Mon, 20 Sep 2021 17:38:22 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this simple change that renames vm/mlvm tests and test package name from anonymous to hidden.
>> Testing:
>>   Ran open/test/hotspot/jtreg/vmTestbase/vm/mlvm on MacOS-x64: PASS
>>   Running open/test/hotspot/jtreg/vmTestbase/vm/mlvm on multiple platforms: in progress ...
>
> Mikhailo Seledtsov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated problem list for Xcomp

I discovered that I had to update ProblemList-Xcomp, it is a trivial renaming for problem listed test.

David, Harold, thank you for review. All testing passed.

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

PR: https://git.openjdk.java.net/jdk/pull/5570

From mseledtsov at openjdk.java.net  Mon Sep 20 19:07:56 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Mon, 20 Sep 2021 19:07:56 GMT
Subject: Integrated: JDK-8267163: Rename anonymous loader tests to hidden
 loader tests
In-Reply-To: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
References: <7OyLeC0tOsfe8jfrUZTAScfgb06RIBgda9VE2mG1JZ4=.4efcda8d-c8b6-4b91-8942-a70f72789ebb@github.com>
Message-ID: <bOevfMDWZsTghyV3dWeFjeR6GfLhpprqRtVMc2WZ73Y=.ca25e4e5-0978-4032-b9a8-368c0141d146@github.com>

On Sat, 18 Sep 2021 00:16:08 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

> Please review this simple change that renames vm/mlvm tests and test package name from anonymous to hidden.
> Testing:
>   Ran open/test/hotspot/jtreg/vmTestbase/vm/mlvm on MacOS-x64: PASS
>   Running open/test/hotspot/jtreg/vmTestbase/vm/mlvm on multiple platforms: in progress ...

This pull request has now been integrated.

Changeset: 5c21c004
Author:    Mikhailo Seledtsov <mseledtsov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5c21c0044104b52fcaf3f3a830ea6e219d504ada
Stats:     1269 lines in 22 files changed: 631 ins; 631 del; 7 mod

8267163: Rename anonymous loader tests to hidden loader tests

Reviewed-by: dholmes, hseigel

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

PR: https://git.openjdk.java.net/jdk/pull/5570

From coleenp at openjdk.java.net  Mon Sep 20 22:07:53 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 20 Sep 2021 22:07:53 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling [v3]
In-Reply-To: <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
 <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
Message-ID: <_Vx6Nsv48PuAsla06UDQvuA3AopQ_o4T4nDQoIhXkq0=.c29e56bc-98fa-4fff-a66a-c19d6e14d7ab@github.com>

On Sat, 18 Sep 2021 05:36:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi,
>> 
>> may I please have reviews for this patch.
>> 
>> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
>> 
>> ----
>> 
>> Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.
>> 
>> I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.
>> 
>> When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, working around all that special handling became too complicated and therefore I'd like a simpler solution.
>> 
>> The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 
>> 
>> The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.
>> 
>> The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.
>> 
>> Small caveats:
>> - the first block in a chunk has no leading fence
>> - the last block in a chunk *may* have no trailing fence
>> - the guard now costs 24 bytes, up from 16 before.
>> 
>> Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.
>> 
>> Tests:
>> - Nightlies at SAP
>> - manual tests on x64 and x86 with and without guards
>> - manual gtests
>> - manual metaspace jtreg tests
>> 
>> Thanks, Thomas
>
> 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 three additional commits since the last revision:
> 
>  - Merge
>  - Reduce diff and improve comments
>  - JDK-8273783-Simplify-metaspace-arena-guard-handling

This looks good, and much simpler!

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5518

From lzang at openjdk.java.net  Tue Sep 21 02:10:57 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 21 Sep 2021 02:10:57 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
Message-ID: <zYZdMl3uNRfHGg_-89k0SRvn_TMOJ_vyJDs3DhTQysg=.9f065c03-7a46-4f13-ad2f-638c337f5345@github.com>

On Wed, 8 Sep 2021 05:02:18 GMT, Ralf Schmelter <rschmelter at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix build error
>
> I will start reviewing this today.

Thanks @schmelter-sap and @plummercj for your help review and approve this PR!
Since this is a non-trivial change, I would like to wait for 2 days before integrate it in case more comments from others.

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From stuefe at openjdk.java.net  Tue Sep 21 04:39:50 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 21 Sep 2021 04:39:50 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling [v3]
In-Reply-To: <_Vx6Nsv48PuAsla06UDQvuA3AopQ_o4T4nDQoIhXkq0=.c29e56bc-98fa-4fff-a66a-c19d6e14d7ab@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
 <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
 <_Vx6Nsv48PuAsla06UDQvuA3AopQ_o4T4nDQoIhXkq0=.c29e56bc-98fa-4fff-a66a-c19d6e14d7ab@github.com>
Message-ID: <M1Vdnlerem5vKTvVdgvnAAaO4tN0eCqwLQ-O1bSk-3Y=.3526d771-5337-4cdf-a296-a917ba443289@github.com>

On Mon, 20 Sep 2021 22:04:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This looks good, and much simpler!

Thank you Coleen!

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

PR: https://git.openjdk.java.net/jdk/pull/5518

From dholmes at openjdk.java.net  Tue Sep 21 06:18:56 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Sep 2021 06:18:56 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms
In-Reply-To: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
Message-ID: <zltbI0RP2uttTXRf4XfCZRutYCDvc8vprXTrH1Cf3tY=.e4118c0a-9346-4263-b00b-219de669701c@github.com>

On Mon, 20 Sep 2021 13:16:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
> 
> Best regards , Matthias

Hi Matthias,

Generally this refactoring looks good, though I have a request to restore some of the code - see comments below. Also could you clarify where functions were only "pretty similar" rather than identical as we don't want to introduce subtle incompatibilities.

I think supports_vtime() could probably be removed in a separate RFE.

Thanks,
David

src/hotspot/os/aix/os_aix.cpp line 997:

> 995: }
> 996: 
> 997: void os::javaTimeNanos_info(jvmtiTimerInfo *info_ptr) {

Please restore this. As has been discussed in previous refactorings in this code if there is a platform specific definition of javaTimeNanos then we should keep the platform specific definition of javaTimeNanos_info, even if it happens to be the same as on other platforms. Otherwise if the javaTimeNanos code were changed one would not realise they also may have to change javaTimenanos_info.

src/hotspot/os/bsd/os_bsd.cpp line 808:

> 806: }
> 807: 
> 808: void os::javaTimeNanos_info(jvmtiTimerInfo *info_ptr) {

Please restore as per previous comment.

src/hotspot/os/posix/os_posix.cpp line 98:

> 96: #else
> 97: static int clock_tics_per_sec = 100;
> 98: #endif

Can't we just defer the conditional initialization to the init() function where we already have to conditionally initialise.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5582

From lucy at openjdk.java.net  Tue Sep 21 06:24:05 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Tue, 21 Sep 2021 06:24:05 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling [v3]
In-Reply-To: <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
 <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
Message-ID: <zHJpIgYz3f9V0kRHAGQCh26CTwhTVWMcv_Qk4bcmHvY=.519ac3e7-b85e-4cbf-8f30-a886334f3a7d@github.com>

On Sat, 18 Sep 2021 05:36:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi,
>> 
>> may I please have reviews for this patch.
>> 
>> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
>> 
>> ----
>> 
>> Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.
>> 
>> I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.
>> 
>> When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, working around all that special handling became too complicated and therefore I'd like a simpler solution.
>> 
>> The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 
>> 
>> The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.
>> 
>> The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.
>> 
>> Small caveats:
>> - the first block in a chunk has no leading fence
>> - the last block in a chunk *may* have no trailing fence
>> - the guard now costs 24 bytes, up from 16 before.
>> 
>> Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.
>> 
>> Tests:
>> - Nightlies at SAP
>> - manual tests on x64 and x86 with and without guards
>> - manual gtests
>> - manual metaspace jtreg tests
>> 
>> Thanks, Thomas
>
> 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 three additional commits since the last revision:
> 
>  - Merge
>  - Reduce diff and improve comments
>  - JDK-8273783-Simplify-metaspace-arena-guard-handling

LGTM.
Much simpler code now. I like the KISS principle (keep it simple and (you select the last word).

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5518

From stuefe at openjdk.java.net  Tue Sep 21 06:26:49 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 21 Sep 2021 06:26:49 GMT
Subject: RFR: JDK-8273783: Simplify Metaspace arena guard handling [v3]
In-Reply-To: <zHJpIgYz3f9V0kRHAGQCh26CTwhTVWMcv_Qk4bcmHvY=.519ac3e7-b85e-4cbf-8f30-a886334f3a7d@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
 <1-ZK_6AeHRPRDulufbCH6M8ggts3k4kEu4te18suRCE=.c43dcec2-fbc2-4b62-982b-841df699f1ac@github.com>
 <zHJpIgYz3f9V0kRHAGQCh26CTwhTVWMcv_Qk4bcmHvY=.519ac3e7-b85e-4cbf-8f30-a886334f3a7d@github.com>
Message-ID: <nAdWGsv79uQH1SjeAda-FUUyV4Iy3pspbhUtvN9P7d8=.02e9a7f3-b4ba-4a61-95f0-e7ad995ea784@github.com>

On Tue, 21 Sep 2021 06:20:50 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> LGTM.
> Much simpler code now. I like the KISS principle (keep it simple and (you select the last word).

:-) Yep, me too. Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5518

From stuefe at openjdk.java.net  Tue Sep 21 06:30:48 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 21 Sep 2021 06:30:48 GMT
Subject: Integrated: JDK-8273783: Simplify Metaspace arena guard handling
In-Reply-To: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
References: <87_ZxIQa2HZUghdV4zjBxb7zAXuA-89ru6wig2ht0bw=.dc4078de-e03a-4980-9e1c-055687a37841@github.com>
Message-ID: <BaDmxOVdM6qTjCiXlCXAr_NJcsfsc76MNPSBBFAQ4tk=.4e6d589b-60a6-4fb4-a7e6-73f8aeb940ed@github.com>

On Wed, 15 Sep 2021 06:10:36 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi,
> 
> may I please have reviews for this patch.
> 
> This simplifies metaspace arena guard handling and reduces the complexity guard mode brings to metaspace and its tests. It makes future modifications easier (esp. wrt Lilliput).
> 
> ----
> 
> Metaspace has a guard mode which I added as part of JEP 387. It means that metaspace allocations are bracketed by canaries which, if broken, indicate a buffer overrun in metaspace. It can be switched on and off using -XX:+MetaspaceGuardAllocations, is by default off, and a debug-only feature.
> 
> I was always a bit unhappy with the implementation though since it seemed too complex and one needed a bit of lateral thinking when looking at arenas. This is because guard prefixes change block size, cause problems with deallocations, require thinking about user pointer alignment etc.
> 
> When investigating how to compress compressed class pointers beyond 32-bit for Lilliput, working around all that special handling became too complicated and therefore I'd like a simpler solution.
> 
> The new mechanism uses the fact that Metaspace is an arena allocator and we therefore know that (almost) all subsequent allocations are adjacent to each other in memory. Therefore, instead of adding guards as prefixes/suffixes with each allocation, we can just allocate the guard block as a separate block after each user allocation, as if the guard were just another user allocation. 
> 
> The result is exactly the same as before: all real allocations are separated in memory by a guard. But to most of the metaspace, these guard blocks are just normal allocations. A lot of special handling can be removed. And we don't have to disable deallocation handling in guard mode.
> 
> The guard blocks are chained together via a simple pointer list and verifying them just means walking that list and examining the eyecatcher. Note that the guard has two eyecatchers, bracketing the next pointer between them - that way we don't have to do a sanity check on the pointer since an overwriter would likely have overwritten one of the eyecatchers before corrupting the pointer.
> 
> Small caveats:
> - the first block in a chunk has no leading fence
> - the last block in a chunk *may* have no trailing fence
> - the guard now costs 24 bytes, up from 16 before.
> 
> Note that all these caveats could be easily solved with a bit more intricate bit fiddling. However, I opted for simplicity here. Guard mode is only activated on demand, if one suspects a problem, and I think it works good enough this way.
> 
> Tests:
> - Nightlies at SAP
> - manual tests on x64 and x86 with and without guards
> - manual gtests
> - manual metaspace jtreg tests
> 
> Thanks, Thomas

This pull request has now been integrated.

Changeset: 6642d2eb
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6642d2eb8b129a2291191647197c5b3333a32989
Stats:     245 lines in 9 files changed: 66 ins; 166 del; 13 mod

8273783: Simplify Metaspace arena guard handling

Reviewed-by: coleenp, lucy

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

PR: https://git.openjdk.java.net/jdk/pull/5518

From mbaesken at openjdk.java.net  Tue Sep 21 07:01:20 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 21 Sep 2021 07:01:20 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms [v2]
In-Reply-To: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
Message-ID: <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>

> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
> 
> Best regards , Matthias

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Restored javaTimeNanos_info in os-files, adjusted clock_tics_per_sec init

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5582/files
  - new: https://git.openjdk.java.net/jdk/pull/5582/files/fb75bd14..91bd15ae

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5582&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5582&range=00-01

  Stats: 25 lines in 3 files changed: 18 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5582.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5582/head:pull/5582

PR: https://git.openjdk.java.net/jdk/pull/5582

From dholmes at openjdk.java.net  Tue Sep 21 07:17:49 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 21 Sep 2021 07:17:49 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms [v2]
In-Reply-To: <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
 <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
Message-ID: <k0GlsQYUBaGzzlfg1pO222kbc_p0jdfTWW2gRX2cOrw=.0f1813f6-d70b-431f-ad90-b3b0359743f3@github.com>

On Tue, 21 Sep 2021 07:01:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
>> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
>> 
>> Best regards , Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored javaTimeNanos_info in os-files, adjusted clock_tics_per_sec init

Thanks Matthias - updates look good.

David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5582

From mbaesken at openjdk.java.net  Tue Sep 21 07:46:52 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 21 Sep 2021 07:46:52 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms [v2]
In-Reply-To: <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
 <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
Message-ID: <0cE3Bo5G0LXQua_U0NaEZP3MTZScuXnaL3kCAB03DzI=.dd762acb-e9c5-4fb5-94c4-0b36c55c6f3a@github.com>

On Tue, 21 Sep 2021 07:01:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
>> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
>> 
>> Best regards , Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored javaTimeNanos_info in os-files, adjusted clock_tics_per_sec init

Hi David, I brought back os::javaTimeNanos_info  following your suggestion and adjusted the initialization of  'clock_tics_per_sec ' in os_posix.

>Also could you clarify where functions were only "pretty similar" rather than identical as we don't want to introduce subtle incompatibilities


Sure, went through them and this is what I found
os::elapsedTime()      identical except comment
os::elapsed_counter()   identical
os::elapsed_frequency() identical
os::supports_vtime()          identical
os::getTimesSecs         identical
os::local_time_string  identical
os::localtime_pd   identical

>I think supports_vtime() could probably be removed in a separate RFE.

OK, I opened https://bugs.openjdk.java.net/browse/JDK-8274051  .

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

PR: https://git.openjdk.java.net/jdk/pull/5582

From rehn at openjdk.java.net  Tue Sep 21 15:47:50 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 21 Sep 2021 15:47:50 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
Message-ID: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>

We should not do any processing in SM::should_process().
The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.

This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
Thus the code querying should release any such Mutex and call process SM::process_if_requested().

The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.

Passes t1-t4 and local stressing.

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

Commit messages:
 - Removed string dedup test from problem list
 - Check SWS for processing

Changes: https://git.openjdk.java.net/jdk/pull/5613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273695
  Stats: 48 lines in 5 files changed: 26 ins; 21 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5613/head:pull/5613

PR: https://git.openjdk.java.net/jdk/pull/5613

From dcubed at openjdk.java.net  Tue Sep 21 16:07:36 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Sep 2021 16:07:36 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
Message-ID: <03Fvclcroars49mbVw2oyWttblbyG3VeL68wAlkSdDU=.6f624429-5ae8-4574-bfc6-f14b4b70717f@github.com>

On Tue, 21 Sep 2021 13:17:43 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> We should not do any processing in SM::should_process().
> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
> 
> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
> 
> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
> 
> Passes t1-t4 and local stressing.

@robehn - There are a couple of other bugs that are considered duplicates
of this bug. Some of those track failures in Tier8 so it would be a good idea
to do testing up through Tier8.

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From dcubed at openjdk.java.net  Tue Sep 21 16:28:34 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Sep 2021 16:28:34 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
Message-ID: <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>

On Tue, 21 Sep 2021 13:17:43 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> We should not do any processing in SM::should_process().
> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
> 
> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
> 
> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
> 
> Passes t1-t4 and local stressing.

Thumbs up. Most of my comments are nits.

I have one question about a possible missing update_poll_values(thread) call
before cross_modify_fence().

src/hotspot/share/runtime/safepointMechanism.inline.hpp line 75:

> 73:   if (global_poll() || // Safepoint
> 74:       thread->handshake_state()->has_a_non_suspend_operation() || // Non-suspend handshake
> 75:       !StackWatermarkSet::processing_started(thread)) { // StackWater processing is not started

Perhaps: s/StackWater/StackWatermark/

src/hotspot/share/runtime/safepointMechanism.inline.hpp line 81:

> 79:   // 1: A suspend handshake targets the JavaThread.
> 80:   // 2: A safepoint takes place.
> 81:   // 3: The JavaThread wakes-up from blocked and do not allow suspend.

typo: s/do not/does not/

src/hotspot/share/runtime/safepointMechanism.inline.hpp line 83:

> 81:   // 3: The JavaThread wakes-up from blocked and do not allow suspend.
> 82:   // We are now about to avoid processing and thus no cross modify fence will be executed.
> 83:   // Therefore we executed it here.

typo: s/executed/execute/

src/hotspot/share/runtime/stackWatermarkSet.hpp line 82:

> 80:   static void start_processing(JavaThread* jt, StackWatermarkKind kind);
> 81: 
> 82:   // Returns true if all StackWaters have been started.

Perhaps: s/StackWaters/StackWatermarks/

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5613

From dcubed at openjdk.java.net  Tue Sep 21 16:28:35 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Sep 2021 16:28:35 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
Message-ID: <SJ55UEiibyb72s3ZG6clJxi8XnVtPjddWEhSS91nAvY=.178379ca-17df-43a1-8c39-9b0edda0bf65@github.com>

On Tue, 21 Sep 2021 16:15:58 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> We should not do any processing in SM::should_process().
>> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
>> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
>> 
>> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
>> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
>> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
>> 
>> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
>> 
>> Passes t1-t4 and local stressing.
>
> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 83:
> 
>> 81:   // 3: The JavaThread wakes-up from blocked and do not allow suspend.
>> 82:   // We are now about to avoid processing and thus no cross modify fence will be executed.
>> 83:   // Therefore we executed it here.
> 
> typo: s/executed/execute/

Also, do you need a call to `update_poll_values(thread)` here
before the `cross_modify_fence()` call?

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From rehn at openjdk.java.net  Tue Sep 21 19:49:14 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 21 Sep 2021 19:49:14 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
Message-ID: <DNDrmj6vCosW-pJz5hJlntiMrlJoPKJBz0KIjSHk-10=.9a3ce41b-6385-428f-9d79-96e4431bf79a@github.com>

On Tue, 21 Sep 2021 16:15:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> We should not do any processing in SM::should_process().
>> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
>> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
>> 
>> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
>> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
>> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
>> 
>> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
>> 
>> Passes t1-t4 and local stressing.
>
> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 81:
> 
>> 79:   // 1: A suspend handshake targets the JavaThread.
>> 80:   // 2: A safepoint takes place.
>> 81:   // 3: The JavaThread wakes-up from blocked and do not allow suspend.
> 
> typo: s/do not/does not/

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From rehn at openjdk.java.net  Tue Sep 21 19:49:18 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 21 Sep 2021 19:49:18 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <SJ55UEiibyb72s3ZG6clJxi8XnVtPjddWEhSS91nAvY=.178379ca-17df-43a1-8c39-9b0edda0bf65@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
 <SJ55UEiibyb72s3ZG6clJxi8XnVtPjddWEhSS91nAvY=.178379ca-17df-43a1-8c39-9b0edda0bf65@github.com>
Message-ID: <iQTGtteATRAVvcgabG7nDAEnUzdJgEbauf9VRFx-f8E=.75344d9a-3319-48c1-9124-a9d41c394a8c@github.com>

On Tue, 21 Sep 2021 16:21:20 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 83:
>> 
>>> 81:   // 3: The JavaThread wakes-up from blocked and do not allow suspend.
>>> 82:   // We are now about to avoid processing and thus no cross modify fence will be executed.
>>> 83:   // Therefore we executed it here.
>> 
>> typo: s/executed/execute/
>
> Also, do you need a call to `update_poll_values(thread)` here
> before the `cross_modify_fence()` call?

Fixed.

No, we do not need to update it.
But maybe we want to, to avoid hitting poll-sites.
The reason not to do it is that it is preferable to have the plain query should_process() not having side-effects.

I need to think about that, thanks for bringing that up.

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From dcubed at openjdk.java.net  Tue Sep 21 19:55:45 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Sep 2021 19:55:45 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <iQTGtteATRAVvcgabG7nDAEnUzdJgEbauf9VRFx-f8E=.75344d9a-3319-48c1-9124-a9d41c394a8c@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
 <SJ55UEiibyb72s3ZG6clJxi8XnVtPjddWEhSS91nAvY=.178379ca-17df-43a1-8c39-9b0edda0bf65@github.com>
 <iQTGtteATRAVvcgabG7nDAEnUzdJgEbauf9VRFx-f8E=.75344d9a-3319-48c1-9124-a9d41c394a8c@github.com>
Message-ID: <8PDKme6-tXXJCJlz17hBTWtjYq7hCmdst8A3ba4sTws=.65a5b555-4664-4226-951e-b6efbcd60992@github.com>

On Tue, 21 Sep 2021 19:38:32 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Also, do you need a call to `update_poll_values(thread)` here
>> before the `cross_modify_fence()` call?
>
> Fixed.
> 
> No, we do not need to update it.
> But maybe we want to, to avoid hitting poll-sites.
> The reason not to do it is that it is preferable to have the plain query should_process() not having side-effects.
> 
> I need to think about that, thanks for bringing that up.

Hmmm... good point about `should_process()` not having side effects.

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From rehn at openjdk.java.net  Tue Sep 21 20:07:57 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Tue, 21 Sep 2021 20:07:57 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <8PDKme6-tXXJCJlz17hBTWtjYq7hCmdst8A3ba4sTws=.65a5b555-4664-4226-951e-b6efbcd60992@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
 <SJ55UEiibyb72s3ZG6clJxi8XnVtPjddWEhSS91nAvY=.178379ca-17df-43a1-8c39-9b0edda0bf65@github.com>
 <iQTGtteATRAVvcgabG7nDAEnUzdJgEbauf9VRFx-f8E=.75344d9a-3319-48c1-9124-a9d41c394a8c@github.com>
 <8PDKme6-tXXJCJlz17hBTWtjYq7hCmdst8A3ba4sTws=.65a5b555-4664-4226-951e-b6efbcd60992@github.com>
Message-ID: <71vqqoh1qLZkZXCAiRr_qOvxLzPWbaKAVsuS1gzOfu4=.a0716640-8052-47cb-8e11-cd056abce9e0@github.com>

On Tue, 21 Sep 2021 19:52:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Fixed.
>> 
>> No, we do not need to update it.
>> But maybe we want to, to avoid hitting poll-sites.
>> The reason not to do it is that it is preferable to have the plain query should_process() not having side-effects.
>> 
>> I need to think about that, thanks for bringing that up.
>
> Hmmm... good point about `should_process()` not having side effects.

This case could notice the update:
bool q1 = should_process(jt, true);
bool q_that_updates_poll_value = should_process(jt, false);
bool q2 = should_process(jt, true);

So q2 can be false while q1 is true. I do not think this is a problem, but worth considering the implications.

I think we should update the poll value even if I do not like it. (running some tests)

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From dcubed at openjdk.java.net  Tue Sep 21 22:29:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 21 Sep 2021 22:29:59 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <71vqqoh1qLZkZXCAiRr_qOvxLzPWbaKAVsuS1gzOfu4=.a0716640-8052-47cb-8e11-cd056abce9e0@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
 <SJ55UEiibyb72s3ZG6clJxi8XnVtPjddWEhSS91nAvY=.178379ca-17df-43a1-8c39-9b0edda0bf65@github.com>
 <iQTGtteATRAVvcgabG7nDAEnUzdJgEbauf9VRFx-f8E=.75344d9a-3319-48c1-9124-a9d41c394a8c@github.com>
 <8PDKme6-tXXJCJlz17hBTWtjYq7hCmdst8A3ba4sTws=.65a5b555-4664-4226-951e-b6efbcd60992@github.com>
 <71vqqoh1qLZkZXCAiRr_qOvxLzPWbaKAVsuS1gzOfu4=.a0716640-8052-47cb-8e11-cd056abce9e0@github.com>
Message-ID: <AXBHstK3QjuRsXk2JDlGfbq5oXBMZKsO3bofdlzBbFg=.88dc19bf-b1e2-4d91-8a54-ba5f08fbed55@github.com>

On Tue, 21 Sep 2021 20:04:03 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> Hmmm... good point about `should_process()` not having side effects.
>
> This case could notice the update:
> bool q1 = should_process(jt, true);
> bool q_that_updates_poll_value = should_process(jt, false);
> bool q2 = should_process(jt, true);
> 
> So q2 can be false while q1 is true. I do not think this is a problem, but worth considering the implications.
> 
> I think we should update the poll value even if I do not like it. (running some tests)

If you decide to add the call to `update_poll_values(thread)`, then
please add a comment with a short explanation about the reason
for this "side effect".

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From dholmes at openjdk.java.net  Wed Sep 22 01:38:01 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Sep 2021 01:38:01 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
Message-ID: <Sd7tBr83kuRFBgPAoZu8sfKr9rvYJDE0MactYyHWMHg=.371cb9bc-b413-4e00-adec-ac51ce53fc31@github.com>

On Tue, 21 Sep 2021 13:17:43 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> We should not do any processing in SM::should_process().
> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
> 
> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
> 
> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
> 
> Passes t1-t4 and local stressing.

Hi Robbin,

Not knowing anything about stackwatermarks and their use I can't really review this in any detail. Avoiding the call to `StackWatermarkSet::on_safepoint` so that `should_process` is just a query does seem like a reasonable thing to do to avoid the problem. That said I'm more generally concerned that something hooked into the lowest-levels of the safepoint/handshake code can itself have a dependency on execution of a safepoint operation!

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From dholmes at openjdk.java.net  Wed Sep 22 01:38:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Sep 2021 01:38:02 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <DNDrmj6vCosW-pJz5hJlntiMrlJoPKJBz0KIjSHk-10=.9a3ce41b-6385-428f-9d79-96e4431bf79a@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <kIv0RRcDOOfpv4wh0R0bvrmpqlr4Jv3yh4iiqn6v56Y=.cbd2edc2-00d0-4b86-96a0-ff6f467f72ef@github.com>
 <DNDrmj6vCosW-pJz5hJlntiMrlJoPKJBz0KIjSHk-10=.9a3ce41b-6385-428f-9d79-96e4431bf79a@github.com>
Message-ID: <3Y9Q3p2i8EYpayg4HU2SUe79UIy7LvGObWn8FRGGWss=.10d724c5-ffcd-4666-aaca-3b918ba67419@github.com>

On Tue, 21 Sep 2021 19:26:05 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 81:
>> 
>>> 79:   // 1: A suspend handshake targets the JavaThread.
>>> 80:   // 2: A safepoint takes place.
>>> 81:   // 3: The JavaThread wakes-up from blocked and do not allow suspend.
>> 
>> typo: s/do not/does not/
>
> Fixed

I don't see the fix?

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From yyang at openjdk.java.net  Wed Sep 22 02:23:59 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 22 Sep 2021 02:23:59 GMT
Subject: RFR: 8272114: Unused _last_state in osThread_windows
In-Reply-To: <aGu60895AuJguKNSFIOGSXtavsZFvER_O3OZD1Hil4A=.ca6b580d-727e-4590-8650-69c83b376faf@github.com>
References: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
 <aGu60895AuJguKNSFIOGSXtavsZFvER_O3OZD1Hil4A=.ca6b580d-727e-4590-8650-69c83b376faf@github.com>
Message-ID: <4I4zYJxRFIfOJjlwMgz5OIMATAO6lI9D3HdkU_MRUfc=.819b7312-536b-4b91-b882-990c7eb366ed@github.com>

On Sat, 18 Sep 2021 08:45:39 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Trivial change to remove unused _last_state in osThread_windows? its getter and setter can be removed as well.
>
> Good and trivial. Tried to find out the history, but AFAICS its been in there since the beginning of OpenJDK.

Thanks @tstuefe and @dholmes-ora for reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/5572

From yyang at openjdk.java.net  Wed Sep 22 02:24:00 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Wed, 22 Sep 2021 02:24:00 GMT
Subject: Integrated: 8272114: Unused _last_state in osThread_windows
In-Reply-To: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
References: <q4EFbor6RGWaTK4j-J-1IV0rOf0aErSCyzzTBromfTU=.2e0dbbab-5411-42f2-9ab8-0d3d43eccf4b@github.com>
Message-ID: <QstHkt3tHcHRCyDsVnvCacJejuKIxtq_CRxaxsJNw-A=.09a931d7-d8e1-4d3b-8467-3af11d753d95@github.com>

On Sat, 18 Sep 2021 07:44:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

> Trivial change to remove unused _last_state in osThread_windows? its getter and setter can be removed as well.

This pull request has now been integrated.

Changeset: 11cddd32
Author:    Yi Yang <yyang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11cddd3261e2bfaa4f2b9142ce9e275bbc48c72e
Stats:     7 lines in 1 file changed: 0 ins; 7 del; 0 mod

8272114: Unused _last_state in osThread_windows

Reviewed-by: stuefe, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5572

From dcubed at openjdk.java.net  Wed Sep 22 02:46:12 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Sep 2021 02:46:12 GMT
Subject: RFR: 8274114: ProblemList serviceability/sa/TestJhsdbJstackMixed.java
 on linux-aarch64 in -Xcomp mode
Message-ID: <TgkPpHCUMV3_b3en7VO2osOfQ7lF2MhbcsAHqs_kzng=.fa2bbc17-3550-4091-bc64-e1dac52799e2@github.com>

A trivial fix to ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode.

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

Commit messages:
 - 8274114: ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode

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

PR: https://git.openjdk.java.net/jdk/pull/5624

From cjplummer at openjdk.java.net  Wed Sep 22 02:52:08 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 22 Sep 2021 02:52:08 GMT
Subject: RFR: 8274114: ProblemList
 serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode
In-Reply-To: <TgkPpHCUMV3_b3en7VO2osOfQ7lF2MhbcsAHqs_kzng=.fa2bbc17-3550-4091-bc64-e1dac52799e2@github.com>
References: <TgkPpHCUMV3_b3en7VO2osOfQ7lF2MhbcsAHqs_kzng=.fa2bbc17-3550-4091-bc64-e1dac52799e2@github.com>
Message-ID: <ykqPbhWny-qo-7X2ZD9w5ClvwEepZSu8qU-y01_bgKw=.4a85c0bb-db14-4048-b6cf-1e3cec939739@github.com>

On Wed, 22 Sep 2021 02:33:41 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode.

Approved and trivial.

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5624

From dcubed at openjdk.java.net  Wed Sep 22 02:52:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Sep 2021 02:52:08 GMT
Subject: RFR: 8274114: ProblemList
 serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode
In-Reply-To: <ykqPbhWny-qo-7X2ZD9w5ClvwEepZSu8qU-y01_bgKw=.4a85c0bb-db14-4048-b6cf-1e3cec939739@github.com>
References: <TgkPpHCUMV3_b3en7VO2osOfQ7lF2MhbcsAHqs_kzng=.fa2bbc17-3550-4091-bc64-e1dac52799e2@github.com>
 <ykqPbhWny-qo-7X2ZD9w5ClvwEepZSu8qU-y01_bgKw=.4a85c0bb-db14-4048-b6cf-1e3cec939739@github.com>
Message-ID: <MTmr3Zd0lGyRcPqalKKEV7Gzm6kCdsvkPogP44Vccx4=.a112c22d-3fbb-4b2a-a581-8d13a31456e8@github.com>

On Wed, 22 Sep 2021 02:47:47 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A trivial fix to ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode.
>
> Approved and trivial.

@plummercj - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5624

From dcubed at openjdk.java.net  Wed Sep 22 02:55:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Sep 2021 02:55:57 GMT
Subject: Integrated: 8274114: ProblemList
 serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode
In-Reply-To: <TgkPpHCUMV3_b3en7VO2osOfQ7lF2MhbcsAHqs_kzng=.fa2bbc17-3550-4091-bc64-e1dac52799e2@github.com>
References: <TgkPpHCUMV3_b3en7VO2osOfQ7lF2MhbcsAHqs_kzng=.fa2bbc17-3550-4091-bc64-e1dac52799e2@github.com>
Message-ID: <B1NUjxrUSP3R5ZuU5CvCuXvsKj7RIhO2zyyX790K_T4=.da377914-c6cf-498e-839a-5b3f17f7c8a6@github.com>

On Wed, 22 Sep 2021 02:33:41 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode.

This pull request has now been integrated.

Changeset: eeaf43b2
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eeaf43b229941f49326ed6d0f37e77f6f0ce5409
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8274114: ProblemList serviceability/sa/TestJhsdbJstackMixed.java on linux-aarch64 in -Xcomp mode

Reviewed-by: cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/5624

From minqi at openjdk.java.net  Wed Sep 22 03:51:19 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Sep 2021 03:51:19 GMT
Subject: RFR: 8273152: Store base archive path in CDSFileMapHeaderBase [v2]
In-Reply-To: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
References: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
Message-ID: <3pwPp_YRC6toOK8w9TQXAGcAEFMxkahlf4Xa24itDRM=.5f53fae0-9bab-4a5a-9583-976a385a5dd1@github.com>

> Store base archive path offset in CDSFileMapHeaderBase (which should be invariant in evolving versions) so we can read the base archive name reliably from dynamic archive even with variant header sizes over versions.
> 
> tests: tier1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with two additional commits since the last revision:

 - Fixed typo
 - Moved _header_size from FileMapHeader to CDSFileMapHeaderBase and added tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5584/files
  - new: https://git.openjdk.java.net/jdk/pull/5584/files/2877aa61..d82587fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5584&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5584&range=00-01

  Stats: 145 lines in 8 files changed: 106 ins; 3 del; 36 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5584.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5584/head:pull/5584

PR: https://git.openjdk.java.net/jdk/pull/5584

From dcubed at openjdk.java.net  Wed Sep 22 03:56:25 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Sep 2021 03:56:25 GMT
Subject: RFR: 8271514: support JFR use of new ThreadsList::Iterator [v4]
In-Reply-To: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
References: <8othaRlEaoN9b-F6Jh9Q6nFLjS92sn0Tt4DQurkYbtE=.23d8f574-9fbc-45c2-b216-c96592b97d5a@github.com>
Message-ID: <lfWjKfCOZCzUNNWQwcyzvDl44xAR6B5OUvNp7UAVwyY=.9453121d-997d-42ae-9e0f-a66680bdd808@github.com>

> A trivial fix to support JFR use of new ThreadsList::Iterator.
> 
> This fix was tested with Mach5 Tier[1-3].

Daniel D. Daugherty has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into JDK-8271514
 - Merge branch 'master' into JDK-8271514
 - Merge branch 'pull/4948' into JDK-8271514
 - Merge branch 'master' into JDK-8271513
 - Merge branch 'pull/4948' into JDK-8271514
 - Merge branch 'pull/4671' into JDK-8271513
 - kbarrett CR - simplify 'ThreadsList::Iterator::operator!=(Iterator i)'
 - 8271514: support JFR use of new ThreadsList::Iterator
 - 8271513: support JavaThreadIteratorWithHandle replacement by new ThreadsList::Iterator
 - 8193559.kbarrett.part1 - Kim's proposed rewrite using newer C++ features.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/cbe57e86...76d44dcb

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

Changes: https://git.openjdk.java.net/jdk/pull/4949/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4949&range=03
  Stats: 39 lines in 2 files changed: 20 ins; 11 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4949.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4949/head:pull/4949

PR: https://git.openjdk.java.net/jdk/pull/4949

From dcubed at openjdk.java.net  Wed Sep 22 03:57:21 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Sep 2021 03:57:21 GMT
Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to
 direct handshakes [v4]
In-Reply-To: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com>
References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com>
Message-ID: <ICF1VWCDHlSgQk5_EsxUJv8PYzSZdbjMDxb-Q2eyfJY=.da10d729-658c-458f-89c7-0799f2220807@github.com>

> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes.
> 
> This refactoring was tested with Mach5 Tier[1-3].

Daniel D. Daugherty 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 JDK-8249004
 - Merge branch 'master' into JDK-8249004
 - Merge branch 'master' into JDK-8249004
 - Merge branch 'master' into JDK-8249004
 - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4677/files
  - new: https://git.openjdk.java.net/jdk/pull/4677/files/507bcbc1..093ad308

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4677&range=02-03

  Stats: 45360 lines in 1767 files changed: 28469 ins; 9160 del; 7731 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4677.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4677/head:pull/4677

PR: https://git.openjdk.java.net/jdk/pull/4677

From iklam at openjdk.java.net  Wed Sep 22 06:03:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 22 Sep 2021 06:03:23 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM
Message-ID: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>

Problem:

In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.

Fix:

Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.

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

Commit messages:
 - 8274033: Some tier-4 CDS EpsilonGC tests throw OOM

Changes: https://git.openjdk.java.net/jdk/pull/5626/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5626&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274033
  Stats: 20 lines in 3 files changed: 20 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5626.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5626/head:pull/5626

PR: https://git.openjdk.java.net/jdk/pull/5626

From dholmes at openjdk.java.net  Wed Sep 22 06:12:57 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Sep 2021 06:12:57 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM
In-Reply-To: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
Message-ID: <yQgLe-xkU_evrNC8ZnjN7iFB7mu3LxEHwYvwHfzs2Ag=.b29c4d86-2e5f-47f2-9ec3-c3e19f3c50a5@github.com>

On Wed, 22 Sep 2021 05:44:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Problem:
> 
> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
> 
> Fix:
> 
> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.

Hi Ioi,

The changes to the test files seem unrelated to the current issue. ??

The group change seems okay but please add a comment.

Thanks,
David

test/hotspot/jtreg/TEST.groups line 402:

> 400:   runtime/cds/appcds/sharedStrings/SharedStringsBasic.java
> 401: 
> 402: hotspot_cds_epsilongc = \

I don't know why we don't comment groups in this file but please add a comment here that these are low-memory using tests that won't fail (with a reasonable heap size) when run with a fake GC.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5626

From iklam at openjdk.java.net  Wed Sep 22 06:21:24 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 22 Sep 2021 06:21:24 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v2]
In-Reply-To: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
Message-ID: <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>

> Problem:
> 
> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
> 
> Fix:
> 
> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dholmes-ora comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5626/files
  - new: https://git.openjdk.java.net/jdk/pull/5626/files/267ea334..7976fb03

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5626&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5626&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From iklam at openjdk.java.net  Wed Sep 22 06:21:25 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 22 Sep 2021 06:21:25 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v2]
In-Reply-To: <yQgLe-xkU_evrNC8ZnjN7iFB7mu3LxEHwYvwHfzs2Ag=.b29c4d86-2e5f-47f2-9ec3-c3e19f3c50a5@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <yQgLe-xkU_evrNC8ZnjN7iFB7mu3LxEHwYvwHfzs2Ag=.b29c4d86-2e5f-47f2-9ec3-c3e19f3c50a5@github.com>
Message-ID: <Et7rkv_UhFu-huN3j1RGmmsuRcdMyGnxRJrEkqSAsZE=.a45fffd8-e47b-4a77-ab2f-6407ae688a7a@github.com>

On Wed, 22 Sep 2021 06:10:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

> The changes to the test files seem unrelated to the current issue. ??

The fix in DynamicArchiveTestBase.java is needed because we were not passing `-XX:+UseEpsilonGC` to dynamicArchive/HelloDynamic.java (even when this file is in the `hotspot_cds_epsilongc` group).

> test/hotspot/jtreg/TEST.groups line 402:
> 
>> 400:   runtime/cds/appcds/sharedStrings/SharedStringsBasic.java
>> 401: 
>> 402: hotspot_cds_epsilongc = \
> 
> I don't know why we don't comment groups in this file but please add a comment here that these are low-memory using tests that won't fail (with a reasonable heap size) when run with a fake GC.

I added a comment.

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From dholmes at openjdk.java.net  Wed Sep 22 06:40:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Sep 2021 06:40:02 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v2]
In-Reply-To: <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
Message-ID: <OPloY86MdQKRRhNWQWAeB5J3X7im3c90mrpcq470SN8=.4d1ae6a4-a2fd-4ee5-93de-3fd90382fce8@github.com>

On Wed, 22 Sep 2021 06:21:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Problem:
>> 
>> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
>> 
>> Fix:
>> 
>> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

test/hotspot/jtreg/TEST.groups line 402:

> 400:   runtime/cds/appcds/sharedStrings/SharedStringsBasic.java
> 401: 
> 402: # No need to run ever test with EpsilonGC. A small subset will provide enough

s/ever/every/

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From dholmes at openjdk.java.net  Wed Sep 22 06:47:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Sep 2021 06:47:58 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v2]
In-Reply-To: <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
Message-ID: <stsOe9GKGoikIjcu7fZ9J7YD3Kbo9SF1X3cxNnAQCBw=.a09a7128-d852-4926-8dfc-b41f2b7f0a69@github.com>

On Wed, 22 Sep 2021 06:21:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Problem:
>> 
>> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
>> 
>> Fix:
>> 
>> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @dholmes-ora comments

The fix to DynamicArchiveTestBase.java still seems like an independent fix to a test not directly related to the subject of this issue. If we aren't passing `-XX:+UseEpsilonGC` then presumably we are not passing `-XX:UseXGC` for any X?

test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java line 593:

> 591: 
> 592: 
> 593:     public static String[] concat(ArrayList<String> prefix, String... extra) {

So you start with an `ArrayList<String>` then convert that to a `String[]` which you pass to a function that then creates a new `ArrayList<String>`, adds all the Strings to it and then converts it to a String[] again! can't help but think there has to be a simpler way to combine an ArrayList with a String[] ??

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From lucy at openjdk.java.net  Wed Sep 22 07:59:04 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 22 Sep 2021 07:59:04 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms [v2]
In-Reply-To: <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
 <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
Message-ID: <emGJ5-NXL5OGpM4KLu_i9DZoUcivzRFtBqOhkEpY8Nk=.67b385d7-003e-45a1-8099-01cda10b6e57@github.com>

On Tue, 21 Sep 2021 07:01:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
>> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
>> 
>> Best regards , Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored javaTimeNanos_info in os-files, adjusted clock_tics_per_sec init

Changes requested by lucy (Reviewer).

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

> 173: 
> 174: static int clock_tics_per_sec = 100;
> 175: 

In os_linux.cpp, clock_tics_per_sec is used for elapsed time calculations as well as for cpu time calculations. In addition, clock_tics_per_sec is set (reinitialised) in os::init(). Are we sure that _SC_CLK_TCK evaluates to 100? If no, do we then potentially calculate wrong elapsed times after moving the code to os_posix?

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

PR: https://git.openjdk.java.net/jdk/pull/5582

From lucy at openjdk.java.net  Wed Sep 22 08:16:55 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 22 Sep 2021 08:16:55 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms [v2]
In-Reply-To: <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
 <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
Message-ID: <F1FkC2-fJCl_g-R22qcnuEJarWeyXju9lgfGfpYwZMw=.ee25e801-85a1-4d4a-ab51-b5304e8e4e43@github.com>

On Tue, 21 Sep 2021 07:01:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
>> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
>> 
>> Best regards , Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored javaTimeNanos_info in os-files, adjusted clock_tics_per_sec init

My previous comment about clock_ticks_per_sec is obsolete. Just saw the initialisation in os::Posix::init(void) now is the same as in os::init(). The static init value is in effect only for the short time until os::init() is invoked. 
Looks good to me.

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

Marked as reviewed by lucy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5582

From mbaesken at openjdk.java.net  Wed Sep 22 08:21:11 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 22 Sep 2021 08:21:11 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms [v2]
In-Reply-To: <F1FkC2-fJCl_g-R22qcnuEJarWeyXju9lgfGfpYwZMw=.ee25e801-85a1-4d4a-ab51-b5304e8e4e43@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
 <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
 <F1FkC2-fJCl_g-R22qcnuEJarWeyXju9lgfGfpYwZMw=.ee25e801-85a1-4d4a-ab51-b5304e8e4e43@github.com>
Message-ID: <7VYDUetZ8y2DQZ4fBwWUp7apKoWM31kyW9aHsGW_5W4=.b12b7ce0-8c14-4f59-a417-8c3d4da81a11@github.com>

On Wed, 22 Sep 2021 08:13:57 GMT, Lutz Schmidt <lucy at openjdk.org> wrote:

> My previous comment about clock_ticks_per_sec is obsolete. Just saw the initialisation in os::Posix::init(void) now is the same as in os::init(). The static init value is in effect only for the short time until os::init() is invoked.
> Looks good to me.

Hi Lutz, thanks for the review .
In case of worries about  the short time frame between  posix and linux init functions, we could introduce 'os::clock_ticks_per_sec()'  and  move this to os_linux, os_aix os_bsd  etc. to have the initialization at one single point.
Not sure if this is worth the effort?

Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5582

From lucy at openjdk.java.net  Wed Sep 22 08:24:58 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Wed, 22 Sep 2021 08:24:58 GMT
Subject: RFR: JDK-8273979: move some os time related functions to os_posix
 for POSIX platforms [v2]
In-Reply-To: <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
 <l5b1ECBJkX5KaGvSV011vxbO_jXXkAlDplm9cNob5c0=.abb20fdc-1b00-425f-ae13-e8d0c3404f28@github.com>
Message-ID: <0-kp3LDOoWu1AMXmSv7XgxklQEY4-1rpi2vfXkSJwtE=.fe2899dd-410b-4982-bb4b-af455af5f539@github.com>

On Tue, 21 Sep 2021 07:01:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
>> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
>> 
>> Best regards , Matthias
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restored javaTimeNanos_info in os-files, adjusted clock_tics_per_sec init

I would not add this complexity. Just leave it as it is.

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

PR: https://git.openjdk.java.net/jdk/pull/5582

From rehn at openjdk.java.net  Wed Sep 22 11:50:46 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 22 Sep 2021 11:50:46 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v2]
In-Reply-To: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
Message-ID: <wo68UCtT1wWQ3JmoLhZeix4f8_uCXecDxris7kMmnWo=.a225118b-8dde-4328-a1da-a788592161e1@github.com>

> We should not do any processing in SM::should_process().
> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
> 
> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
> 
> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
> 
> Passes t1-t4 and local stressing.

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:

 - Merge branch 'master' into 8273695-swm-should-proc
 - Added update poll values and fixed PR comments
 - Removed string dedup test from problem list
 - Check SWS for processing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5613/files
  - new: https://git.openjdk.java.net/jdk/pull/5613/files/3021d91e..536bb9e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=00-01

  Stats: 8665 lines in 332 files changed: 5982 ins; 999 del; 1684 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5613/head:pull/5613

PR: https://git.openjdk.java.net/jdk/pull/5613

From rehn at openjdk.java.net  Wed Sep 22 11:50:48 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 22 Sep 2021 11:50:48 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <03Fvclcroars49mbVw2oyWttblbyG3VeL68wAlkSdDU=.6f624429-5ae8-4574-bfc6-f14b4b70717f@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <03Fvclcroars49mbVw2oyWttblbyG3VeL68wAlkSdDU=.6f624429-5ae8-4574-bfc6-f14b4b70717f@github.com>
Message-ID: <wPMmcBkqpzc4sCIlfhRoLwFeFIhbnRqqc3yZEb07NT8=.ea76b97a-8d0c-4919-aa3a-e42b3567b873@github.com>

On Tue, 21 Sep 2021 16:04:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> @robehn - There are a couple of other bugs that are considered duplicates
> of this bug. Some of those track failures in Tier7 and Tier8 so it would be a
> good idea to do testing up through Tier8.

I started more testing.

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From ccheung at openjdk.java.net  Wed Sep 22 15:06:25 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 22 Sep 2021 15:06:25 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v2]
In-Reply-To: <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
Message-ID: <Fbgau_H_8wzF7pw5copIATDFJtTTN8G7-iUn-KUKxoo=.3720d43c-0074-48df-8c69-f2e2d28c0f4f@github.com>

On Wed, 22 Sep 2021 06:21:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Problem:
>> 
>> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
>> 
>> Fix:
>> 
>> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.
>
> 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: https://git.openjdk.java.net/jdk/pull/5626

From minqi at openjdk.java.net  Wed Sep 22 15:50:59 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Sep 2021 15:50:59 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v2]
In-Reply-To: <stsOe9GKGoikIjcu7fZ9J7YD3Kbo9SF1X3cxNnAQCBw=.a09a7128-d852-4926-8dfc-b41f2b7f0a69@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
 <stsOe9GKGoikIjcu7fZ9J7YD3Kbo9SF1X3cxNnAQCBw=.a09a7128-d852-4926-8dfc-b41f2b7f0a69@github.com>
Message-ID: <EX0dtyGtAmllIiz3-f3yzYrugQgG1wFxmxkKu2VnT54=.20a2b27a-0970-4ae5-a28a-163b3f0ef342@github.com>

On Wed, 22 Sep 2021 06:42:04 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
>
> test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java line 593:
> 
>> 591: 
>> 592: 
>> 593:     public static String[] concat(ArrayList<String> prefix, String... extra) {
> 
> So you start with an `ArrayList<String>` then convert that to a `String[]` which you pass to a function that then creates a new `ArrayList<String>`, adds all the Strings to it and then converts it to a String[] again! can't help but think there has to be a simpler way to combine an ArrayList with a String[] ??

Could use the prefix, add extra to the list then prefix.toArray to avoid such conversion between ArrayList and array.

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From dcubed at openjdk.java.net  Wed Sep 22 16:49:59 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Sep 2021 16:49:59 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v2]
In-Reply-To: <wo68UCtT1wWQ3JmoLhZeix4f8_uCXecDxris7kMmnWo=.a225118b-8dde-4328-a1da-a788592161e1@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <wo68UCtT1wWQ3JmoLhZeix4f8_uCXecDxris7kMmnWo=.a225118b-8dde-4328-a1da-a788592161e1@github.com>
Message-ID: <hL5pjyQaxyzbLmQB4vjF1SaehOSiRHiuBtEN2JQzgL8=.6b8887fa-6875-4240-96e5-b333e23a9624@github.com>

On Wed, 22 Sep 2021 11:50:46 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> We should not do any processing in SM::should_process().
>> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
>> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
>> 
>> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
>> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
>> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
>> 
>> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
>> 
>> Passes t1-t4 and local stressing.
>
> 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:
> 
>  - Merge branch 'master' into 8273695-swm-should-proc
>  - Added update poll values and fixed PR comments
>  - Removed string dedup test from problem list
>  - Check SWS for processing

Thumbs up.

Minor typographical nits.

src/hotspot/share/runtime/safepointMechanism.inline.hpp line 79:

> 77:   }
> 78: 
> 79:   // It have boiled down to two possibilities.

Please change to:
// It has boiled down to two possibilities:

src/hotspot/share/runtime/safepointMechanism.inline.hpp line 82:

> 80:   // 1: We have nothing to process, this just a disarm poll.
> 81:   // 2: We have a suspend handshake, which cannot be processed.
> 82:   // We update the poll value in case of a disarm, to reduce false positive.

Typo: s/positive/positives/

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5613

From iklam at openjdk.java.net  Wed Sep 22 17:04:21 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 22 Sep 2021 17:04:21 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v3]
In-Reply-To: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
Message-ID: <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>

> Problem:
> 
> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
> 
> Fix:
> 
> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  fixed typo; removed fix for handling of CDSUtils::getRuntimePrefix() to be done in a separate bug

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5626/files
  - new: https://git.openjdk.java.net/jdk/pull/5626/files/7976fb03..806ae762

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5626&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5626&range=01-02

  Stats: 10 lines in 3 files changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5626.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5626/head:pull/5626

PR: https://git.openjdk.java.net/jdk/pull/5626

From minqi at openjdk.java.net  Wed Sep 22 18:12:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Sep 2021 18:12:56 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v3]
In-Reply-To: <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>
Message-ID: <gTT2eoaJ1y5c7ufUPxeqU88SgfM1Hqyv2ywg0QVthco=.31aa7c96-4aa3-4f27-9154-729a6b3b8e1b@github.com>

On Wed, 22 Sep 2021 17:04:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Problem:
>> 
>> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
>> 
>> Fix:
>> 
>> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo; removed fix for handling of CDSUtils::getRuntimePrefix() to be done in a separate bug

LGTM.

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

Marked as reviewed by minqi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5626

From coleenp at openjdk.java.net  Wed Sep 22 18:25:02 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Wed, 22 Sep 2021 18:25:02 GMT
Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to
 direct handshakes [v4]
In-Reply-To: <ICF1VWCDHlSgQk5_EsxUJv8PYzSZdbjMDxb-Q2eyfJY=.da10d729-658c-458f-89c7-0799f2220807@github.com>
References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com>
 <ICF1VWCDHlSgQk5_EsxUJv8PYzSZdbjMDxb-Q2eyfJY=.da10d729-658c-458f-89c7-0799f2220807@github.com>
Message-ID: <tXz591NxubKWuG6eBOPcmIaJlq9kuCxpGW5sdrMD5vA=.c1d95fa9-3991-48e1-8c27-a866bad95a37@github.com>

On Wed, 22 Sep 2021 03:57:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes.
>> 
>> This refactoring was tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty 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 JDK-8249004
>  - Merge branch 'master' into JDK-8249004
>  - Merge branch 'master' into JDK-8249004
>  - Merge branch 'master' into JDK-8249004
>  - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes

This looks good.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4677

From ccheung at openjdk.java.net  Wed Sep 22 18:27:56 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Wed, 22 Sep 2021 18:27:56 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v3]
In-Reply-To: <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>
Message-ID: <39bmYnUwFQH_ydvvSIpUNiSu6n-jJPqoVoncAS6u_Zg=.de54f435-398b-47a8-99af-b559772785d1@github.com>

On Wed, 22 Sep 2021 17:04:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Problem:
>> 
>> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
>> 
>> Fix:
>> 
>> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo; removed fix for handling of CDSUtils::getRuntimePrefix() to be done in a separate bug

Marked as reviewed by ccheung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From dcubed at openjdk.java.net  Wed Sep 22 19:08:03 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Wed, 22 Sep 2021 19:08:03 GMT
Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to
 direct handshakes [v4]
In-Reply-To: <tXz591NxubKWuG6eBOPcmIaJlq9kuCxpGW5sdrMD5vA=.c1d95fa9-3991-48e1-8c27-a866bad95a37@github.com>
References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com>
 <ICF1VWCDHlSgQk5_EsxUJv8PYzSZdbjMDxb-Q2eyfJY=.da10d729-658c-458f-89c7-0799f2220807@github.com>
 <tXz591NxubKWuG6eBOPcmIaJlq9kuCxpGW5sdrMD5vA=.c1d95fa9-3991-48e1-8c27-a866bad95a37@github.com>
Message-ID: <zY_PX-9gRJ5NtYqYqUIS9jdxeSAIu6zUQ8XEQKHMZRg=.fc364af3-02f9-49b7-970e-6a41d8c95331@github.com>

On Wed, 22 Sep 2021 18:21:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Daniel D. Daugherty 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 JDK-8249004
>>  - Merge branch 'master' into JDK-8249004
>>  - Merge branch 'master' into JDK-8249004
>>  - Merge branch 'master' into JDK-8249004
>>  - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes
>
> This looks good.

@coleenp - Thanks, but...

I'm redoing this fix in a different way to address @dholmes-ora comment from above:

> I just updated the bug report. This really isn't addressing the reasons the RFE was filed.

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

PR: https://git.openjdk.java.net/jdk/pull/4677

From iklam at openjdk.java.net  Wed Sep 22 19:44:59 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 22 Sep 2021 19:44:59 GMT
Subject: RFR: 8273152: Store base archive path in CDSFileMapHeaderBase [v2]
In-Reply-To: <3pwPp_YRC6toOK8w9TQXAGcAEFMxkahlf4Xa24itDRM=.5f53fae0-9bab-4a5a-9583-976a385a5dd1@github.com>
References: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
 <3pwPp_YRC6toOK8w9TQXAGcAEFMxkahlf4Xa24itDRM=.5f53fae0-9bab-4a5a-9583-976a385a5dd1@github.com>
Message-ID: <wAhXTToEpOShLNRy2-2RA15jUrQwdn3k8uYEm2onSTw=.abd70b82-e213-4f6d-92b9-9b9cf29edae3@github.com>

On Wed, 22 Sep 2021 03:51:19 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Store base archive path offset in CDSFileMapHeaderBase (which should be invariant in evolving versions) so we can read the base archive name reliably from dynamic archive even with variant header sizes over versions.
>> 
>> tests: tier1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fixed typo
>  - Moved _header_size from FileMapHeader to CDSFileMapHeaderBase and added tests

src/hotspot/share/cds/filemap.cpp line 1159:

> 1157:     }
> 1158:   }
> 1159: 

The check from 1144-1158 should be done inside `FileMapInfo::check_archive()`. This function  (`FileMapInfo::init_from_file`) is called *after* we have successfully loaded the header of an archive created by the current JDK. However, -- with JDK-8261455, we will need to read the headers of an archive created by a different JDK version, so we need to do the check at the very beginning, when we are examining the magic value, etc.

Also, the base archive's name should be considered as part of the header, so `header()->header_size()` should include the size of the base archive's name as well. Otherwise, we won't be able to read the entire header, including the base archive name, of an archive created by a different JDK version.

The check for header()->base_archive_path_offset() needs to be expanded:
- it must be smaller than header()->header_size()
- it must point to a valid 0-terminated string -- the string cannot run past the end of the header.

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

PR: https://git.openjdk.java.net/jdk/pull/5584

From iklam at openjdk.java.net  Wed Sep 22 19:53:53 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 22 Sep 2021 19:53:53 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v2]
In-Reply-To: <EX0dtyGtAmllIiz3-f3yzYrugQgG1wFxmxkKu2VnT54=.20a2b27a-0970-4ae5-a28a-163b3f0ef342@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <DYu2s3C6TlfHCfDROhEZlbIkLTDYhkBS85V2iZE8VrA=.29fb61cd-0646-4ed8-a607-97b29f5eeadd@github.com>
 <stsOe9GKGoikIjcu7fZ9J7YD3Kbo9SF1X3cxNnAQCBw=.a09a7128-d852-4926-8dfc-b41f2b7f0a69@github.com>
 <EX0dtyGtAmllIiz3-f3yzYrugQgG1wFxmxkKu2VnT54=.20a2b27a-0970-4ae5-a28a-163b3f0ef342@github.com>
Message-ID: <6Ts-QnFRA7eKYYBJglO78JUbkGJzVgxZhiflfPnVsZw=.fab766b6-9511-48de-ae10-d23522081c8c@github.com>

On Wed, 22 Sep 2021 15:47:29 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> test/hotspot/jtreg/runtime/cds/appcds/TestCommon.java line 593:
>> 
>>> 591: 
>>> 592: 
>>> 593:     public static String[] concat(ArrayList<String> prefix, String... extra) {
>> 
>> So you start with an `ArrayList<String>` then convert that to a `String[]` which you pass to a function that then creates a new `ArrayList<String>`, adds all the Strings to it and then converts it to a String[] again! can't help but think there has to be a simpler way to combine an ArrayList with a String[] ??
>
> Could use the prefix, add extra to the list then prefix.toArray to avoid such conversion between ArrayList and array.

I've removed this code from the current PR. I found other cases where the "runtime prefix" was not passed to child processes. I'll do a more general fix in https://bugs.openjdk.java.net/browse/JDK-8274166

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From sspitsyn at openjdk.java.net  Wed Sep 22 19:58:03 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 22 Sep 2021 19:58:03 GMT
Subject: RFR: 8249004: Reduce ThreadListHandle overhead in relation to
 direct handshakes [v4]
In-Reply-To: <ICF1VWCDHlSgQk5_EsxUJv8PYzSZdbjMDxb-Q2eyfJY=.da10d729-658c-458f-89c7-0799f2220807@github.com>
References: <891nGxHdujE6CWxkCW8v9qnKIGBHXPeOxjyIznPorOU=.8e159ff3-d3e3-4706-9c1b-18c675855825@github.com>
 <ICF1VWCDHlSgQk5_EsxUJv8PYzSZdbjMDxb-Q2eyfJY=.da10d729-658c-458f-89c7-0799f2220807@github.com>
Message-ID: <IwYZjFVXLtke9HIzZf52grMGt5SW7sh_fQ4o-Lbe6WE=.a3bad9c8-78a2-4342-a943-7e8b77ab98ee@github.com>

On Wed, 22 Sep 2021 03:57:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to reduce ThreadListHandle overhead in relation to handshakes.
>> 
>> This refactoring was tested with Mach5 Tier[1-3].
>
> Daniel D. Daugherty 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 JDK-8249004
>  - Merge branch 'master' into JDK-8249004
>  - Merge branch 'master' into JDK-8249004
>  - Merge branch 'master' into JDK-8249004
>  - 8249004: Reduce ThreadListHandle overhead in relation to direct handshakes

Hi Dan,
It looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4677

From dholmes at openjdk.java.net  Wed Sep 22 22:48:53 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 22 Sep 2021 22:48:53 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v3]
In-Reply-To: <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>
Message-ID: <1o8dgAwb_BQb0SjNySWlIWIbXcXjrrD2EoQSu2VrUDc=.92a7527b-c120-45e3-bd49-7f425b7ba521@github.com>

On Wed, 22 Sep 2021 17:04:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Problem:
>> 
>> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
>> 
>> Fix:
>> 
>> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed typo; removed fix for handling of CDSUtils::getRuntimePrefix() to be done in a separate bug

Marked as reviewed by dholmes (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From minqi at openjdk.java.net  Wed Sep 22 23:28:00 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 22 Sep 2021 23:28:00 GMT
Subject: RFR: 8273152: Store base archive path in CDSFileMapHeaderBase [v2]
In-Reply-To: <wAhXTToEpOShLNRy2-2RA15jUrQwdn3k8uYEm2onSTw=.abd70b82-e213-4f6d-92b9-9b9cf29edae3@github.com>
References: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
 <3pwPp_YRC6toOK8w9TQXAGcAEFMxkahlf4Xa24itDRM=.5f53fae0-9bab-4a5a-9583-976a385a5dd1@github.com>
 <wAhXTToEpOShLNRy2-2RA15jUrQwdn3k8uYEm2onSTw=.abd70b82-e213-4f6d-92b9-9b9cf29edae3@github.com>
Message-ID: <XDPG45V7SkAciZJmxK2AHdg-B6i_Fmxt9frVNKEBbh4=.d6ccb2cb-84ac-41e3-817f-b64f3946e63e@github.com>

On Wed, 22 Sep 2021 19:42:08 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fixed typo
>>  - Moved _header_size from FileMapHeader to CDSFileMapHeaderBase and added tests
>
> src/hotspot/share/cds/filemap.cpp line 1159:
> 
>> 1157:     }
>> 1158:   }
>> 1159: 
> 
> The check from 1144-1158 should be done inside `FileMapInfo::check_archive()`. This function  (`FileMapInfo::init_from_file`) is called *after* we have successfully loaded the header of an archive created by the current JDK. However, -- with JDK-8261455, we will need to read the headers of an archive created by a different JDK version, so we need to do the check at the very beginning, when we are examining the magic value, etc.
> 
> Also, the base archive's name should be considered as part of the header, so `header()->header_size()` should include the size of the base archive's name as well. Otherwise, we won't be able to read the entire header, including the base archive name, of an archive created by a different JDK version.
> 
> The check for header()->base_archive_path_offset() needs to be expanded:
> - it must be smaller than header()->header_size()
> - it must point to a valid 0-terminated string -- the string cannot run past the end of the header.

The base archive name size should be included in CDSFileMapHeaderBase, not the base archive name itself. If the name as a part of header size, it will complicate the code. We want to read the base archive name from the archive file, this should be done by only reading CDSFileMapHeaderBase from the archive file to get enough information.

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

PR: https://git.openjdk.java.net/jdk/pull/5584

From minqi at openjdk.java.net  Thu Sep 23 01:00:21 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 23 Sep 2021 01:00:21 GMT
Subject: RFR: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info
Message-ID: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>

Hi, please review the change for printing more info in jcmd terminal when dump shared archives. The ultimate shared archive file name is formed in java function (CDS.dumpSharedArchive) so to get the final archive name, the signature of CDS.dumpSharedArchive changed to return the archive name. At the end of dumping, return the archive name back to the caller so we can print out it in jcmd terminal.

Tests: ter1-4
           manually checked the output of jcmd execution.

Thanks
Yumin

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

Commit messages:
 - 8271303: jcmd VM.cds {static, dynamic}_dump should print more info

Changes: https://git.openjdk.java.net/jdk/pull/5643/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5643&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8271303
  Stats: 15 lines in 3 files changed: 9 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5643.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5643/head:pull/5643

PR: https://git.openjdk.java.net/jdk/pull/5643

From iklam at openjdk.java.net  Thu Sep 23 03:52:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 23 Sep 2021 03:52:55 GMT
Subject: RFR: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM [v3]
In-Reply-To: <39bmYnUwFQH_ydvvSIpUNiSu6n-jJPqoVoncAS6u_Zg=.de54f435-398b-47a8-99af-b559772785d1@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
 <U7kbIdeuwsaLgcGQ8oRv_qY5NMb_VFnZagXhhnxntlY=.455a8728-5061-4f27-b4ac-ce419f7b075f@github.com>
 <39bmYnUwFQH_ydvvSIpUNiSu6n-jJPqoVoncAS6u_Zg=.de54f435-398b-47a8-99af-b559772785d1@github.com>
Message-ID: <RxxKqC4oHuVSC8PbjE5YC84uwEELiLtvdWdZqZ3lYoo=.aec89824-41f0-4964-8437-2493b4929d56@github.com>

On Wed, 22 Sep 2021 18:24:24 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed typo; removed fix for handling of CDSUtils::getRuntimePrefix() to be done in a separate bug
>
> Marked as reviewed by ccheung (Reviewer).

Thanks @calvinccheung @dholmes-ora @yminqi for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From iklam at openjdk.java.net  Thu Sep 23 03:52:55 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 23 Sep 2021 03:52:55 GMT
Subject: Integrated: 8274033: Some tier-4 CDS EpsilonGC tests throw OOM
In-Reply-To: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
References: <Pdf4wZsPbmiLBHTAd2HoBdofE17Cbqhg1vNIkEsskvY=.23f55d7f-236e-45d3-8eb7-56de9dc45e7d@github.com>
Message-ID: <qa6vr3pfJZd3mLNallTtSsJfh-zDMe9c-pNHrw114tE=.545264a0-c9a4-4233-8ac9-cfae9ebfab69@github.com>

On Wed, 22 Sep 2021 05:44:44 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Problem:
> 
> In Oracle hs-tier4, in order to test the support of archived heap objects in EpsilonGC, we run all test cases under open/test/hotspot/jtreg/runtime/cds with `-Dtest.cds.runtime.options=-XX:+UnlockExperimentalVMOptions,-XX:+UseEpsilonGC`. Some of those tests may create a lot of objects, some of those will eventually become unreferenced. Because EpsilonGC cannot collect garbage, the tests will fail with OOM.
> 
> Fix:
> 
> Limit the set of tests to be executed by introducing a test group `hotspot_cds_epsilongc`. This reduces the number of tests from 200+ to about 50. The problematic `runtime/cds/appcds/methodHandles` cases are excluded.

This pull request has now been integrated.

Changeset: 0fbbe4c9
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fbbe4c9a779c24d5502648c866b7f1e1e50acc0
Stats:     13 lines in 1 file changed: 13 ins; 0 del; 0 mod

8274033: Some tier-4 CDS EpsilonGC tests throw OOM

Reviewed-by: dholmes, ccheung, minqi

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

PR: https://git.openjdk.java.net/jdk/pull/5626

From mbaesken at openjdk.java.net  Thu Sep 23 05:37:53 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Thu, 23 Sep 2021 05:37:53 GMT
Subject: Integrated: JDK-8273979: move some os time related functions to
 os_posix for POSIX platforms
In-Reply-To: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
References: <EOqNGDvWBoHD_Zi04dDh65ovTQ_KyyUt0MMeauXG98c=.064edac9-4371-4727-bb33-c793bf423861@github.com>
Message-ID: <FEhNLjG9aLPBtx5F5Qae0UIHx82HdFpgFJiMdEUphao=.78416a4e-01cd-4699-bbde-ab348ee4e1c7@github.com>

On Mon, 20 Sep 2021 13:16:42 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There are a couple of time related functions in os_<platform> for Linux, BSD+Mac and AIX that are pretty similar (or identical) across the platforms and can be centralized in os_posix .
> While doing so, I noticed that  os::supports_vtime()   returns always true , on Posix and also on Windows, so we might remove it completely if this prefered ? 
> 
> Best regards , Matthias

This pull request has now been integrated.

Changeset: 1c6fa113
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1c6fa113bd06585945e077f0d2004a291c27946d
Stats:     238 lines in 4 files changed: 63 ins; 173 del; 2 mod

8273979: move some os time related functions to os_posix for POSIX platforms

Reviewed-by: dholmes, lucy

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

PR: https://git.openjdk.java.net/jdk/pull/5582

From stuefe at openjdk.java.net  Thu Sep 23 06:22:10 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 23 Sep 2021 06:22:10 GMT
Subject: RFR: JDK-8273881: Metaspace: test repeated deallocations
Message-ID: <PBgX86x6kX-dZnApkmvqHaRkSRwrce1cFQW0PQRqOLg=.407ec956-7441-453f-8473-23b78b1fc115@github.com>

Hi,

this adds a gtest which tests that repeatedly allocate and deallocate from an arena with the same size will not increase the footprint beyond the first allocation (the block should be registered with freeblock management and re-used each time).

Tests:
- manual tests on Ubuntu x64 and x86, with and without guards, and metaspace jtreg tests
- GHAs

Thanks, Thomas

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

Commit messages:
 - JDK-8273881-metaspace-test-repeated-deallocs

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

PR: https://git.openjdk.java.net/jdk/pull/5546

From lzang at openjdk.java.net  Thu Sep 23 07:04:00 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 23 Sep 2021 07:04:00 GMT
Subject: Integrated: 8252842: Extend jmap to support parallel heap dump
In-Reply-To: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
Message-ID: <ZWpY132DMr6hRSdWaSfUurPjvMCUfer7YKJCk3sozwo=.08bfc112-f31b-4c54-8bbc-e7998f12dd48@github.com>

On Wed, 27 Jan 2021 12:49:29 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 8252842: Extend jmap to support parallel heap dump

This pull request has now been integrated.

Changeset: a74c099d
Author:    Lin Zang <lzang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a74c099d67272b2ef542405d30db62a82cbbebc6
Stats:     832 lines in 6 files changed: 637 ins; 42 del; 153 mod

8252842: Extend jmap to support parallel heap dump

Reviewed-by: rschmelter, cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From dholmes at openjdk.java.net  Thu Sep 23 13:12:02 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 23 Sep 2021 13:12:02 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <zYZdMl3uNRfHGg_-89k0SRvn_TMOJ_vyJDs3DhTQysg=.9f065c03-7a46-4f13-ad2f-638c337f5345@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
 <zYZdMl3uNRfHGg_-89k0SRvn_TMOJ_vyJDs3DhTQysg=.9f065c03-7a46-4f13-ad2f-638c337f5345@github.com>
Message-ID: <__674R8RO_mstjDHM_dNfkhdanXIBOuQPjnKnFO0ov0=.5c93c48e-26ce-4392-bea4-86ce45d41881@github.com>

On Tue, 21 Sep 2021 02:07:39 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> I will start reviewing this today.
>
> Thanks @schmelter-sap and @plummercj for your help review and approve this PR!
> Since this is a non-trivial change, I would like to wait for 2 days before integrate it in case more comments from others.

@linzang  this change is causing test crashes on Windows with ZGC and EpsilonGC - please see JDK-8274196

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From lzang at openjdk.java.net  Thu Sep 23 13:25:04 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 23 Sep 2021 13:25:04 GMT
Subject: RFR: 8252842: Extend jmap to support parallel heap dump [v32]
In-Reply-To: <__674R8RO_mstjDHM_dNfkhdanXIBOuQPjnKnFO0ov0=.5c93c48e-26ce-4392-bea4-86ce45d41881@github.com>
References: <EpPPP9qaTt9h2Y-_Cx2YQt8HsTwKfgRb1V2Twx9lMPo=.29366395-9fca-4f50-8188-b764eecb9ef6@github.com>
 <ZAFc1F-BRGMdjv-xv_3XF3wHjGC1tvuGgC4wV28km-k=.8db58dfa-e8b1-4eeb-9d9c-71a7ced92722@github.com>
 <NbMKLaO_hLh3XL1pgnw8yzqiJJf0ODyG5S12TeJaFBM=.8997fce0-2e3a-4e45-a8df-22a1864a2219@github.com>
 <zYZdMl3uNRfHGg_-89k0SRvn_TMOJ_vyJDs3DhTQysg=.9f065c03-7a46-4f13-ad2f-638c337f5345@github.com>
 <__674R8RO_mstjDHM_dNfkhdanXIBOuQPjnKnFO0ov0=.5c93c48e-26ce-4392-bea4-86ce45d41881@github.com>
Message-ID: <hXHklqPoxApfrgwQ2MyHaEBzR46ACTqZY_Z1zjV0LLk=.2f38e9eb-6bef-44d3-bd1f-4b096ec550a9@github.com>

On Thu, 23 Sep 2021 13:07:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thanks @schmelter-sap and @plummercj for your help review and approve this PR!
>> Since this is a non-trivial change, I would like to wait for 2 days before integrate it in case more comments from others.
>
> @linzang  this change is causing test crashes on Windows with ZGC and EpsilonGC - please see JDK-8274196

Thanks David @dholmes-ora,
I will take look at the issue. 

BRs,
Lin

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

PR: https://git.openjdk.java.net/jdk/pull/2261

From minqi at openjdk.java.net  Thu Sep 23 16:29:22 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 23 Sep 2021 16:29:22 GMT
Subject: RFR: 8273152: Store base archive path in CDSFileMapHeaderBase [v3]
In-Reply-To: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
References: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
Message-ID: <XPWq6OliO3UMR3y_zlQ8IbY-k6Y7oWZWq6RzVGPtPdI=.d3c11276-4bdf-42e6-84b8-e6f20d02a688@github.com>

> Store base archive path offset in CDSFileMapHeaderBase (which should be invariant in evolving versions) so we can read the base archive name reliably from dynamic archive even with variant header sizes over versions.
> 
> tests: tier1-4
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Moved _base_archive_name_size to CDSFileMapHeaderBase and made checking consistency in function check_archive

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5584/files
  - new: https://git.openjdk.java.net/jdk/pull/5584/files/d82587fb..e515c31b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5584&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5584&range=01-02

  Stats: 73 lines in 6 files changed: 43 ins; 20 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5584.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5584/head:pull/5584

PR: https://git.openjdk.java.net/jdk/pull/5584

From darcy at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
Message-ID: <NPvLGaVLiBPGMa9eLq0IQYHzyirhm6oBy8hoiECY-mY=.9e110985-22ac-4506-8273-49ef2a1d7922@github.com>

On Thu, 23 Sep 2021 16:45:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5657

From dcubed at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on
 linux-all and windows-all
Message-ID: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>

A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

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

Commit messages:
 - 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

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

PR: https://git.openjdk.java.net/jdk/pull/5657

From dcubed at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <NPvLGaVLiBPGMa9eLq0IQYHzyirhm6oBy8hoiECY-mY=.9e110985-22ac-4506-8273-49ef2a1d7922@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
 <NPvLGaVLiBPGMa9eLq0IQYHzyirhm6oBy8hoiECY-mY=.9e110985-22ac-4506-8273-49ef2a1d7922@github.com>
Message-ID: <wWv7tCV02wTFvyUe36a6JFKOO-Ad66ww3w_CPprkr0M=.cb77810c-c805-4464-84c7-0606b6b23a3a@github.com>

On Thu, 23 Sep 2021 16:58:58 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5657

From tschatzl at openjdk.java.net  Thu Sep 23 17:09:10 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 23 Sep 2021 17:09:10 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
Message-ID: <98hC7JdW0nSdZJrViN7XTJxJc4bpSuLtBpUPC0I1UHk=.3ba05130-cf03-47b7-a5ec-9d5be694181c@github.com>

On Thu, 23 Sep 2021 16:45:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

Marked as reviewed by tschatzl (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5657

From dcubed at openjdk.java.net  Thu Sep 23 17:09:11 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:09:11 GMT
Subject: RFR: 8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on linux-all and windows-all
In-Reply-To: <98hC7JdW0nSdZJrViN7XTJxJc4bpSuLtBpUPC0I1UHk=.3ba05130-cf03-47b7-a5ec-9d5be694181c@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
 <98hC7JdW0nSdZJrViN7XTJxJc4bpSuLtBpUPC0I1UHk=.3ba05130-cf03-47b7-a5ec-9d5be694181c@github.com>
Message-ID: <kfJ6gGASBULC1BZFDLRGCRMae7rpggRzvuL-3CPhJXU=.5d227710-b114-455a-9647-a03174d9da9c@github.com>

On Thu, 23 Sep 2021 17:01:14 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.
>
> Marked as reviewed by tschatzl (Reviewer).

@tschatzl - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5657

From dcubed at openjdk.java.net  Thu Sep 23 17:17:53 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 23 Sep 2021 17:17:53 GMT
Subject: Integrated: 8274216: ProblemList 2 serviceability/dcmd/gc tests with
 ZGC on linux-all and windows-all
In-Reply-To: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
References: <vTxm0CBpNRrNDLkmPj3DmfKIUklBW3KefxvtdybMDls=.238c0f21-47e2-487c-9250-580fad880401@github.com>
Message-ID: <VYBSJJRcUGLR2y_d1DRiXloLApq8yW4gzBRjwf-unEM=.6d263267-8eb3-4517-82a3-56c756b1ec51@github.com>

On Thu, 23 Sep 2021 16:45:30 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all.

This pull request has now been integrated.

Changeset: 0aa63fec
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0aa63feca8704c8958530ef9e3df128570c50e12
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8274216: ProblemList 2 serviceability/dcmd/gc tests with ZGC on linux-all and windows-all

Reviewed-by: darcy, tschatzl

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

PR: https://git.openjdk.java.net/jdk/pull/5657

From coleenp at openjdk.java.net  Thu Sep 23 22:38:52 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 23 Sep 2021 22:38:52 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v11]
In-Reply-To: <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com>
Message-ID: <MlN4AK9lqR3_nsnLl1hxOheI9IOxGpfnThQzllcSXeg=.bf3cf8e3-83ed-4e3b-ae10-25c298059594@github.com>

On Mon, 13 Sep 2021 17:12:49 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - remove rehashing and rely on default grow_hint for table resize
>  - mtStatistics

src/hotspot/share/jfr/periodic/jfrFinalizerStatisticsEvent.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #if INCLUDE_MANAGEMENT

With precompiled headers turned off, this gets a compilation error:
error: "INCLUDE_MANAGEMENT" is not
 defined, evaluates to 0 [-Werror=undef]

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From coleenp at openjdk.java.net  Fri Sep 24 01:34:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 01:34:06 GMT
Subject: RFR: 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank failures
Message-ID: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>

This test fails due to Mutex rank assertions that I just added.  The new mutexes in the heapDumper needs to be ranked 'nosafepoint' and 'nosafepoint-1' since they don't cause safepoint checks.
This code also holds two no-safepoint checking locks and waits on the second.  This doesn't break rank ordering but does run afoul of an old assert that we had in the code, that is no longer has meaning.

The test still fails because of other bugs like JDK-8274196 but it doesn't get the mutex rank assertions anymore.

Testing with tier 5 and 6, where the failure was observed, in progress.

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

Commit messages:
 - 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank failures

Changes: https://git.openjdk.java.net/jdk/pull/5669/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5669&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274245
  Stats: 9 lines in 3 files changed: 0 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5669/head:pull/5669

PR: https://git.openjdk.java.net/jdk/pull/5669

From coleenp at openjdk.java.net  Fri Sep 24 01:38:21 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 01:38:21 GMT
Subject: RFR: 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank
 failures [v2]
In-Reply-To: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
References: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
Message-ID: <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>

> This test fails due to Mutex rank assertions that I just added.  The new mutexes in the heapDumper needs to be ranked 'nosafepoint' and 'nosafepoint-1' since they don't cause safepoint checks.
> This code also holds two no-safepoint checking locks and waits on the second.  This doesn't break rank ordering but does run afoul of an old assert that we had in the code, that is no longer has meaning.
> 
> The test still fails because of other bugs like JDK-8274196 but it doesn't get the mutex rank assertions anymore.
> 
> Testing with tier 5 and 6, where the failure was observed, in progress.

Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:

  Remove tests for special wait assert.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5669/files
  - new: https://git.openjdk.java.net/jdk/pull/5669/files/5ccfa31d..45b4776c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5669&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5669&range=00-01

  Stats: 48 lines in 1 file changed: 0 ins; 48 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5669.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5669/head:pull/5669

PR: https://git.openjdk.java.net/jdk/pull/5669

From dholmes at openjdk.java.net  Fri Sep 24 01:53:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 24 Sep 2021 01:53:51 GMT
Subject: RFR: 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank
 failures [v2]
In-Reply-To: <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
References: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
 <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
Message-ID: <Ltq-mT0aJqcjU6MoPug8CVaq-eO6qvS48kDu3iHwn0s=.c05ad27a-8cb8-4341-9a4b-f144d80f834a@github.com>

On Fri, 24 Sep 2021 01:38:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This test fails due to Mutex rank assertions that I just added.  The new mutexes in the heapDumper needs to be ranked 'nosafepoint' and 'nosafepoint-1' since they don't cause safepoint checks.
>> This code also holds two no-safepoint checking locks and waits on the second.  This doesn't break rank ordering but does run afoul of an old assert that we had in the code, that is no longer has meaning.
>> 
>> The test still fails because of other bugs like JDK-8274196 but it doesn't get the mutex rank assertions anymore.
>> 
>> Testing with tier 5 and 6, where the failure was observed, in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tests for special wait assert.

I think the assert still has merit but only for a JavaThread, as it means we are doing a wait on a monitor with no safepoint checking and that could potentially delay a safepoint arbitrarily. But obviously it is fine for NJTs to coordinate with each other (wait & notify) using a nosafepoint Monitor.

David

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

PR: https://git.openjdk.java.net/jdk/pull/5669

From dholmes at openjdk.java.net  Fri Sep 24 02:01:05 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 24 Sep 2021 02:01:05 GMT
Subject: RFR: 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank
 failures [v2]
In-Reply-To: <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
References: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
 <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
Message-ID: <8J55rDNKCP9se7vag8jbubGzscgpKujJ7TMllVS5NQw=.7d185651-9c61-4f01-8c59-f45246fbce19@github.com>

On Fri, 24 Sep 2021 01:38:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This test fails due to Mutex rank assertions that I just added.  The new mutexes in the heapDumper needs to be ranked 'nosafepoint' and 'nosafepoint-1' since they don't cause safepoint checks.
>> This code also holds two no-safepoint checking locks and waits on the second.  This doesn't break rank ordering but does run afoul of an old assert that we had in the code, that is no longer has meaning.
>> 
>> The test still fails because of other bugs like JDK-8274196 but it doesn't get the mutex rank assertions anymore.
>> 
>> Testing with tier 5 and 6, where the failure was observed, in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tests for special wait assert.

Sorry I misread that assertion. It is not clear why we would care about holding other nosafepoint locks when doing a wait(). We would only ever care about holding safepoint-ing locks when doing a wait() on a nosafepoint lock, and that is not allowed anyway.

David

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

PR: https://git.openjdk.java.net/jdk/pull/5669

From dholmes at openjdk.java.net  Fri Sep 24 02:42:55 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 24 Sep 2021 02:42:55 GMT
Subject: RFR: 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank
 failures [v2]
In-Reply-To: <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
References: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
 <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
Message-ID: <1NR9KEVkB1IU0pN5cB0qcva-x4PxSDCsajcWwTHo9pw=.6b2846e7-abd4-4a75-ab86-5b3ee569c6c3@github.com>

On Fri, 24 Sep 2021 01:38:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This test fails due to Mutex rank assertions that I just added.  The new mutexes in the heapDumper needs to be ranked 'nosafepoint' and 'nosafepoint-1' since they don't cause safepoint checks.
>> This code also holds two no-safepoint checking locks and waits on the second.  This doesn't break rank ordering but does run afoul of an old assert that we had in the code, that is no longer has meaning.
>> 
>> The test still fails because of other bugs like JDK-8274196 but it doesn't get the mutex rank assertions anymore.
>> 
>> Testing with tier 5 and 6, where the failure was observed, in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tests for special wait assert.

Hi Coleen,

These assertions have lost their context over time as the mutex susbsystem has been changed. This one used to check for rank "special and that (once upon a time) was defined as:

 // A special lock: Is a lock where you are guaranteed not to block while you are
 // holding it, i.e., no vm operation can happen, taking other locks, etc.

Hence the check that you don't wait() while holding one. But "special" is no more and the check makes no sense for general nosafepoint mutex/monitors.

So I think your changes are fine.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5669

From iklam at openjdk.java.net  Fri Sep 24 06:54:00 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 24 Sep 2021 06:54:00 GMT
Subject: RFR: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info
In-Reply-To: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
References: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
Message-ID: <4dzTHvj7lAfklryZiiUF209oZfqwYhCAmLE3ZZRapJw=.e7e2dc67-dae0-416d-a614-566bd3513bcb@github.com>

On Thu, 23 Sep 2021 00:52:40 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, please review the change for printing more info in jcmd terminal when dump shared archives. The ultimate shared archive file name is formed in java function (CDS.dumpSharedArchive) so to get the final archive name, the signature of CDS.dumpSharedArchive changed to return the archive name. At the end of dumping, return the archive name back to the caller so we can print out it in jcmd terminal.
> 
> Tests: ter1-4
>            manually checked the output of jcmd execution.
> 
> Thanks
> Yumin

Changes requested by iklam (Reviewer).

src/java.base/share/classes/jdk/internal/misc/CDS.java line 337:

> 335:         }
> 336:         // Everyting goes well, print out the file name.
> 337:         String archiveFilePath = cwd + File.separator + archiveFileName;

`archiveFileName` may already be a absolute path (e.g., "/tmp/foo.jar"), so this will print out something like /app/cwd//tmp/foo.jar, which will be incorrect. It should be changed to


String archiveFilePath = new File(archiveFileName).getAbsolutePath();

src/java.base/share/classes/jdk/internal/misc/CDS.java line 338:

> 336:         // Everyting goes well, print out the file name.
> 337:         String archiveFilePath = cwd + File.separator + archiveFileName;
> 338:         System.out.println("The process was attached by jcmd and do a " + (isStatic ? "static" : "dynamic") + " dump to file " + archiveFilePath);

Grammar:


System.out.println("The process was attached by jcmd and dumped a "
     + (isStatic ? "static" : "dynamic") + " archive " + archiveFilePath);

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

PR: https://git.openjdk.java.net/jdk/pull/5643

From jespersm at openjdk.java.net  Fri Sep 24 08:59:03 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Fri, 24 Sep 2021 08:59:03 GMT
Subject: RFR: 8274265: Suspicious string concatenation in test code
Message-ID: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>

This patch fixes the mishap, and lets JDK compile under XCode 13 / LLVM 13.

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

Commit messages:
 - 8274265: Suspicious string concatenation in test code

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

PR: https://git.openjdk.java.net/jdk/pull/5675

From mgronlun at openjdk.java.net  Fri Sep 24 09:27:05 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 24 Sep 2021 09:27:05 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v11]
In-Reply-To: <MlN4AK9lqR3_nsnLl1hxOheI9IOxGpfnThQzllcSXeg=.bf3cf8e3-83ed-4e3b-ae10-25c298059594@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <3hNX4mQ98TyLNDmCXO4hDz8EMDoQ4ukr1Y1bvX1k8kk=.cc67221c-258a-4cac-a368-09d5fe44f245@github.com>
 <MlN4AK9lqR3_nsnLl1hxOheI9IOxGpfnThQzllcSXeg=.bf3cf8e3-83ed-4e3b-ae10-25c298059594@github.com>
Message-ID: <A8Q5IRih9FEPG-bl7y0pI1kqmSuVwfQUjh8cakP0ipw=.cf18d6f4-e7e5-4405-87a7-1a3e82a3d341@github.com>

On Thu, 23 Sep 2021 22:35:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - remove rehashing and rely on default grow_hint for table resize
>>  - mtStatistics
>
> src/hotspot/share/jfr/periodic/jfrFinalizerStatisticsEvent.cpp line 26:
> 
>> 24: 
>> 25: #include "precompiled.hpp"
>> 26: #if INCLUDE_MANAGEMENT
> 
> With precompiled headers turned off, this gets a compilation error:
> error: "INCLUDE_MANAGEMENT" is not
>  defined, evaluates to 0 [-Werror=undef]

Thanks, I missed submitting a few no-precompiled header builds. Fixed now.

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From mgronlun at openjdk.java.net  Fri Sep 24 09:27:02 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 24 Sep 2021 09:27:02 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v12]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  no precompiled headers and mtServiceability nmt classification

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/62592daf..5759c605

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=10-11

  Stats: 9 lines in 4 files changed: 4 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

From coleenp at openjdk.java.net  Fri Sep 24 12:22:01 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 12:22:01 GMT
Subject: RFR: 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank
 failures [v2]
In-Reply-To: <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
References: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
 <hZzTMlKtKHeLGBiI_QMI1h0OnJCCYGPcCrciOLuPjeo=.51a1882c-3fce-4a81-b5d8-065da292792e@github.com>
Message-ID: <e5c2riZq815mhZtcwbIC2ofnPOoEYBGFnCnD-UvajJg=.893a3ae6-0870-4641-9119-adb5660fa12d@github.com>

On Fri, 24 Sep 2021 01:38:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This test fails due to Mutex rank assertions that I just added.  The new mutexes in the heapDumper needs to be ranked 'nosafepoint' and 'nosafepoint-1' since they don't cause safepoint checks.
>> This code also holds two no-safepoint checking locks and waits on the second.  This doesn't break rank ordering but does run afoul of an old assert that we had in the code, that is no longer has meaning.
>> 
>> The test still fails because of other bugs like JDK-8274196 but it doesn't get the mutex rank assertions anymore.
>> 
>> Testing with tier 5 and 6, where the failure was observed, in progress.
>
> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove tests for special wait assert.

@linzang  has a different fix for this mutex ranking problem (make them check for safepoints, which is preferred anyway) and I'll file a different PR for the wait < nosafepoint rank problem.

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

PR: https://git.openjdk.java.net/jdk/pull/5669

From coleenp at openjdk.java.net  Fri Sep 24 12:22:02 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 12:22:02 GMT
Subject: Withdrawn: 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank
 failures
In-Reply-To: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
References: <iNLqRw4ytPao1AT-KNvWbze3VuxTCyEjgVaFCPbVZJE=.55db38e6-ebdb-4110-b01e-eb2330661b91@github.com>
Message-ID: <YnE_uJ7uP3O88ALouLjmFF9_P_zGg4Qn5V-O1DJ3lpM=.d7e46c2e-db88-4bc0-b310-681ee10132f1@github.com>

On Fri, 24 Sep 2021 01:25:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This test fails due to Mutex rank assertions that I just added.  The new mutexes in the heapDumper needs to be ranked 'nosafepoint' and 'nosafepoint-1' since they don't cause safepoint checks.
> This code also holds two no-safepoint checking locks and waits on the second.  This doesn't break rank ordering but does run afoul of an old assert that we had in the code, that is no longer has meaning.
> 
> The test still fails because of other bugs like JDK-8274196 but it doesn't get the mutex rank assertions anymore.
> 
> Testing with tier 5 and 6, where the failure was observed, in progress.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/5669

From mbaesken at openjdk.java.net  Fri Sep 24 12:53:15 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 24 Sep 2021 12:53:15 GMT
Subject: RFR: JDK-8274283: string-concatenation build warning as error with
 clang 13 on macOS aarch64
Message-ID: <rs95-o9fB9_J_zt2rtKZRu1vEWe8W53r4lwJki4gp9w=.432e0892-75b6-43ca-8a22-b6ba8cd433a1@github.com>

Please review this small fix fixing builds using clang 13.
We run into this error when compiling with clang version 13.0.0 (clang-1300.0.29.3) :

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

Commit messages:
 - JDK-8274283

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

PR: https://git.openjdk.java.net/jdk/pull/5680

From lzang at openjdk.java.net  Fri Sep 24 13:28:02 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 24 Sep 2021 13:28:02 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
Message-ID: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>

The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.

The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.

The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

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

Commit messages:
 - 8274196: Crashes in VM_HeapDumper::work after JDK-8252842

Changes: https://git.openjdk.java.net/jdk/pull/5681/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274196
  Stats: 48 lines in 2 files changed: 22 ins; 23 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5681.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5681/head:pull/5681

PR: https://git.openjdk.java.net/jdk/pull/5681

From coleenp at openjdk.java.net  Fri Sep 24 13:40:54 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 13:40:54 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <pae02IMiuNrPAHK0yTGWCyIQihQqkpsYt4D1E_QR4TY=.871e0aa5-fdbd-4e53-8d69-260edc433d54@github.com>

On Fri, 24 Sep 2021 13:13:39 GMT, Lin Zang <lzang at openjdk.org> wrote:

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

src/hotspot/share/services/heapDumper.cpp line 751:

> 749:   static void before_work() {
> 750:     assert(_lock == NULL, "ParDumpWriter lock must be initialized only once");
> 751:     _lock = new (std::nothrow) PaddedMonitor(Mutex::leaf, "ParallelHProfWriter_lock", Mutex::_safepoint_check_always);

If you change these locks to _safepoint_check_always, you have to acquire them without the Mutex::_no_safepoint_check flags so I don't know why you don't get that assert.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Fri Sep 24 13:48:55 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 24 Sep 2021 13:48:55 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <pae02IMiuNrPAHK0yTGWCyIQihQqkpsYt4D1E_QR4TY=.871e0aa5-fdbd-4e53-8d69-260edc433d54@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <pae02IMiuNrPAHK0yTGWCyIQihQqkpsYt4D1E_QR4TY=.871e0aa5-fdbd-4e53-8d69-260edc433d54@github.com>
Message-ID: <dXBq8JSKlRq_BBmZEBqz2ZZCFs2Vut1xLjtEFvjcf8E=.c213821c-7195-4f86-b8e5-e757a327b264@github.com>

On Fri, 24 Sep 2021 13:37:44 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
>> 
>> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
>> 
>> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.
>
> src/hotspot/share/services/heapDumper.cpp line 751:
> 
>> 749:   static void before_work() {
>> 750:     assert(_lock == NULL, "ParDumpWriter lock must be initialized only once");
>> 751:     _lock = new (std::nothrow) PaddedMonitor(Mutex::leaf, "ParallelHProfWriter_lock", Mutex::_safepoint_check_always);
> 
> If you change these locks to _safepoint_check_always, you have to acquire them without the Mutex::_no_safepoint_check flags so I don't know why you don't get that assert.

I think it may be because this is actually not a JavaThread. So the assert in `Mutex::check_no_safepoint_state` would pass. 
Moreover, I have tried to use `PaddedMonitor(Mutex::nosafepoint, "ParallelHProfWriter_lock", Mutex::_safepoint_check_never);` here, but the slowdebug would report errors as you mentioned in JDK-8274245.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Fri Sep 24 14:08:51 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 24 Sep 2021 14:08:51 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <dXBq8JSKlRq_BBmZEBqz2ZZCFs2Vut1xLjtEFvjcf8E=.c213821c-7195-4f86-b8e5-e757a327b264@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <pae02IMiuNrPAHK0yTGWCyIQihQqkpsYt4D1E_QR4TY=.871e0aa5-fdbd-4e53-8d69-260edc433d54@github.com>
 <dXBq8JSKlRq_BBmZEBqz2ZZCFs2Vut1xLjtEFvjcf8E=.c213821c-7195-4f86-b8e5-e757a327b264@github.com>
Message-ID: <WNGEuG7Ai3IFdcnDSfWDAbDT_Gku6v3UwCuaQSqWnFo=.236fca1a-091d-47c0-8f88-9a7765d3f85c@github.com>

On Fri, 24 Sep 2021 13:46:13 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> src/hotspot/share/services/heapDumper.cpp line 751:
>> 
>>> 749:   static void before_work() {
>>> 750:     assert(_lock == NULL, "ParDumpWriter lock must be initialized only once");
>>> 751:     _lock = new (std::nothrow) PaddedMonitor(Mutex::leaf, "ParallelHProfWriter_lock", Mutex::_safepoint_check_always);
>> 
>> If you change these locks to _safepoint_check_always, you have to acquire them without the Mutex::_no_safepoint_check flags so I don't know why you don't get that assert.
>
> I think it may be because this is actually not a JavaThread. So the assert in `Mutex::check_no_safepoint_state` would pass. 
> Moreover, I have tried to use `PaddedMonitor(Mutex::nosafepoint, "ParallelHProfWriter_lock", Mutex::_safepoint_check_never);` here, but the slowdebug would report errors as you mentioned in JDK-8274245.

I agree the flag here and at the place of lock acquiring  seems problematic. I will try to see whether I can use `Mutex::_safepoint_check_never` here and get rid of the assert.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From coleenp at openjdk.java.net  Fri Sep 24 15:05:27 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 15:05:27 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <WNGEuG7Ai3IFdcnDSfWDAbDT_Gku6v3UwCuaQSqWnFo=.236fca1a-091d-47c0-8f88-9a7765d3f85c@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <pae02IMiuNrPAHK0yTGWCyIQihQqkpsYt4D1E_QR4TY=.871e0aa5-fdbd-4e53-8d69-260edc433d54@github.com>
 <dXBq8JSKlRq_BBmZEBqz2ZZCFs2Vut1xLjtEFvjcf8E=.c213821c-7195-4f86-b8e5-e757a327b264@github.com>
 <WNGEuG7Ai3IFdcnDSfWDAbDT_Gku6v3UwCuaQSqWnFo=.236fca1a-091d-47c0-8f88-9a7765d3f85c@github.com>
Message-ID: <KYuQBNWwBWK1xZbJkKQaTOT1GDnzRm6AajAgACB6ETQ=.764f80f8-d291-4af1-a00c-5dd756e4ce5a@github.com>

On Fri, 24 Sep 2021 14:05:48 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> I think it may be because this is actually not a JavaThread. So the assert in `Mutex::check_no_safepoint_state` would pass. 
>> Moreover, I have tried to use `PaddedMonitor(Mutex::nosafepoint, "ParallelHProfWriter_lock", Mutex::_safepoint_check_never);` here, but the slowdebug would report errors as you mentioned in JDK-8274245.
>
> I agree the flag here and at the place of lock acquiring  seems problematic. I will try to see whether I can use `Mutex::_safepoint_check_never` here and get rid of the assert.

yes
    void Mutex::check_no_safepoint_state(Thread* thread) {
       check_block_state(thread);
       assert(!thread->is_active_Java_thread() || _safepoint_check_required != _safepoint_check_always,
              "This lock should always have a safepoint check for Java threads: %s",
              name());
     }

yes, we exclude the check for a non-java thread, which I thought was an odd exclusion last time I looked.  I pass the tests in sun/tools/jmap/BasicJMapTest.java so maybe leave it for now?

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Fri Sep 24 15:09:05 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 24 Sep 2021 15:09:05 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <KYuQBNWwBWK1xZbJkKQaTOT1GDnzRm6AajAgACB6ETQ=.764f80f8-d291-4af1-a00c-5dd756e4ce5a@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <pae02IMiuNrPAHK0yTGWCyIQihQqkpsYt4D1E_QR4TY=.871e0aa5-fdbd-4e53-8d69-260edc433d54@github.com>
 <dXBq8JSKlRq_BBmZEBqz2ZZCFs2Vut1xLjtEFvjcf8E=.c213821c-7195-4f86-b8e5-e757a327b264@github.com>
 <WNGEuG7Ai3IFdcnDSfWDAbDT_Gku6v3UwCuaQSqWnFo=.236fca1a-091d-47c0-8f88-9a7765d3f85c@github.com>
 <KYuQBNWwBWK1xZbJkKQaTOT1GDnzRm6AajAgACB6ETQ=.764f80f8-d291-4af1-a00c-5dd756e4ce5a@github.com>
Message-ID: <S1z1hPuJNkQOMLFpMQ5TQ4jrAzy2rdSWbzEBtB_-qjg=.2be320db-57ab-4c70-bed1-01544e6b002e@github.com>

On Fri, 24 Sep 2021 15:01:26 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> I agree the flag here and at the place of lock acquiring  seems problematic. I will try to see whether I can use `Mutex::_safepoint_check_never` here and get rid of the assert.
>
> yes
>     void Mutex::check_no_safepoint_state(Thread* thread) {
>        check_block_state(thread);
>        assert(!thread->is_active_Java_thread() || _safepoint_check_required != _safepoint_check_always,
>               "This lock should always have a safepoint check for Java threads: %s",
>               name());
>      }
> 
> yes, we exclude the check for a non-java thread, which I thought was an odd exclusion last time I looked.  I pass the tests in sun/tools/jmap/BasicJMapTest.java so maybe leave it for now?

I agree, maybe a new issue could be created for tracking this.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From coleenp at openjdk.java.net  Fri Sep 24 15:29:22 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 15:29:22 GMT
Subject: RFR: 8274282: Remove special wait assert
Message-ID: <WqwNwtyXz47rp5KUISxGDdipwpVnyhSiGgO1e3CSnx8=.f542830a-3598-4249-b418-d79aa9f09f44@github.com>

This change removes the assert and tests for Mutex::wait() only allowed with greater than nosafepoint ranked held locks.
Tested with tier1-3.

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

Commit messages:
 - Remove tests for special wait assert.
 - 8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank failures

Changes: https://git.openjdk.java.net/jdk/pull/5684/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5684&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274282
  Stats: 57 lines in 4 files changed: 0 ins; 51 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5684.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5684/head:pull/5684

PR: https://git.openjdk.java.net/jdk/pull/5684

From dcubed at openjdk.java.net  Fri Sep 24 15:48:05 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 24 Sep 2021 15:48:05 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <VuoibR__Jo0wer5wsYtDQ9wdCVDmQbf5QTXn9woJc0M=.283fa8e5-aa86-466d-b9bd-073d09bff7e9@github.com>

On Fri, 24 Sep 2021 13:13:39 GMT, Lin Zang <lzang at openjdk.org> wrote:

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

@linzang and @coleenp - I've ProblemListed the test via:

JDK-8274294 ProblemList sun/tools/jmap/BasicJMapTest.java

to give you folks time to sort thru the details.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From dcubed at openjdk.java.net  Fri Sep 24 15:50:15 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 24 Sep 2021 15:50:15 GMT
Subject: Integrated: 8274294: ProblemList sun/tools/jmap/BasicJMapTest.java
Message-ID: <HhbR0YhQmgcSnkwe2q9k7icqRz-zn3f7JLDvy_L67j0=.8de000eb-2382-401a-b2e0-04510bbb4336@github.com>

A trivial fix to ProblemList sun/tools/jmap/BasicJMapTest.java.

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

Commit messages:
 - 8274294: ProblemList sun/tools/jmap/BasicJMapTest.java

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

PR: https://git.openjdk.java.net/jdk/pull/5685

From rriggs at openjdk.java.net  Fri Sep 24 15:50:15 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 24 Sep 2021 15:50:15 GMT
Subject: Integrated: 8274294: ProblemList sun/tools/jmap/BasicJMapTest.java
In-Reply-To: <HhbR0YhQmgcSnkwe2q9k7icqRz-zn3f7JLDvy_L67j0=.8de000eb-2382-401a-b2e0-04510bbb4336@github.com>
References: <HhbR0YhQmgcSnkwe2q9k7icqRz-zn3f7JLDvy_L67j0=.8de000eb-2382-401a-b2e0-04510bbb4336@github.com>
Message-ID: <Z1Ax-NwOF9lOoNvNXkPaPd1fsm2lgiefNUveAbZEuGE=.54e3b661-e77c-45e8-bce2-6594becd2b8a@github.com>

On Fri, 24 Sep 2021 15:34:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/tools/jmap/BasicJMapTest.java.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5685

From dcubed at openjdk.java.net  Fri Sep 24 15:50:16 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 24 Sep 2021 15:50:16 GMT
Subject: Integrated: 8274294: ProblemList sun/tools/jmap/BasicJMapTest.java
In-Reply-To: <HhbR0YhQmgcSnkwe2q9k7icqRz-zn3f7JLDvy_L67j0=.8de000eb-2382-401a-b2e0-04510bbb4336@github.com>
References: <HhbR0YhQmgcSnkwe2q9k7icqRz-zn3f7JLDvy_L67j0=.8de000eb-2382-401a-b2e0-04510bbb4336@github.com>
Message-ID: <zhj8zNtcD77cdnxpwemlqLchzNIVnz-smYQ2CK2sVjM=.2e535315-129a-472a-a1a5-d0540032f1ca@github.com>

On Fri, 24 Sep 2021 15:34:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList sun/tools/jmap/BasicJMapTest.java.

This pull request has now been integrated.

Changeset: 0c050be6
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c050be64b7db297126c4dca6c7ebfc9f386b9db
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8274294: ProblemList sun/tools/jmap/BasicJMapTest.java

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/5685

From dcubed at openjdk.java.net  Fri Sep 24 15:50:15 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 24 Sep 2021 15:50:15 GMT
Subject: Integrated: 8274294: ProblemList sun/tools/jmap/BasicJMapTest.java
In-Reply-To: <Z1Ax-NwOF9lOoNvNXkPaPd1fsm2lgiefNUveAbZEuGE=.54e3b661-e77c-45e8-bce2-6594becd2b8a@github.com>
References: <HhbR0YhQmgcSnkwe2q9k7icqRz-zn3f7JLDvy_L67j0=.8de000eb-2382-401a-b2e0-04510bbb4336@github.com>
 <Z1Ax-NwOF9lOoNvNXkPaPd1fsm2lgiefNUveAbZEuGE=.54e3b661-e77c-45e8-bce2-6594becd2b8a@github.com>
Message-ID: <kqCMRFdjP0UyVQuJUSnF5lZn6QO-PFH3iE2tfXEkqx4=.8989aa13-cebf-4bea-9391-3c2fbc03c216@github.com>

On Fri, 24 Sep 2021 15:37:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix to ProblemList sun/tools/jmap/BasicJMapTest.java.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs - Thanks for the fast review!

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

PR: https://git.openjdk.java.net/jdk/pull/5685

From github.com+7837910+xpbob at openjdk.java.net  Fri Sep 24 16:27:13 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Fri, 24 Sep 2021 16:27:13 GMT
Subject: RFR: 8274293: Build failure with Xcode 13.0 due to vfork is deprecated
Message-ID: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>

remove vfork() on Darwin

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

Commit messages:
 - 8274293: Build failure with Xcode 13.0 due to vfork is deprecated

Changes: https://git.openjdk.java.net/jdk/pull/5686/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274293
  Stats: 10 lines in 2 files changed: 8 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5686.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5686/head:pull/5686

PR: https://git.openjdk.java.net/jdk/pull/5686

From rehn at openjdk.java.net  Fri Sep 24 16:48:38 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 24 Sep 2021 16:48:38 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v3]
In-Reply-To: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
Message-ID: <lkk5J-wwMoMbp8VW-XBf2GzdbCEs2zLy27QB0mwMpZs=.c4b06014-3751-4a4d-95fb-39dc4e2af024@github.com>

> We should not do any processing in SM::should_process().
> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
> 
> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
> 
> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
> 
> Passes t1-t4 and local stressing.

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

  Fixed spelling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5613/files
  - new: https://git.openjdk.java.net/jdk/pull/5613/files/536bb9e8..e5b52cda

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From rehn at openjdk.java.net  Fri Sep 24 16:48:46 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 24 Sep 2021 16:48:46 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v2]
In-Reply-To: <hL5pjyQaxyzbLmQB4vjF1SaehOSiRHiuBtEN2JQzgL8=.6b8887fa-6875-4240-96e5-b333e23a9624@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <wo68UCtT1wWQ3JmoLhZeix4f8_uCXecDxris7kMmnWo=.a225118b-8dde-4328-a1da-a788592161e1@github.com>
 <hL5pjyQaxyzbLmQB4vjF1SaehOSiRHiuBtEN2JQzgL8=.6b8887fa-6875-4240-96e5-b333e23a9624@github.com>
Message-ID: <-0Rw_7QVOEjUK41NQEyAYOZxyltUhxQcT0-GPzI9gQ8=.6e4e6947-165b-4e0a-82d1-bf9b76f7fab3@github.com>

On Wed, 22 Sep 2021 16:44:53 GMT, Daniel D. Daugherty <dcubed 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:
>> 
>>  - Merge branch 'master' into 8273695-swm-should-proc
>>  - Added update poll values and fixed PR comments
>>  - Removed string dedup test from problem list
>>  - Check SWS for processing
>
> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 79:
> 
>> 77:   }
>> 78: 
>> 79:   // It have boiled down to two possibilities.
> 
> Please change to:
> // It has boiled down to two possibilities:

Fixed

> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 82:
> 
>> 80:   // 1: We have nothing to process, this just a disarm poll.
>> 81:   // 2: We have a suspend handshake, which cannot be processed.
>> 82:   // We update the poll value in case of a disarm, to reduce false positive.
> 
> Typo: s/positive/positives/

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From coleenp at openjdk.java.net  Fri Sep 24 16:57:55 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 16:57:55 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <S1z1hPuJNkQOMLFpMQ5TQ4jrAzy2rdSWbzEBtB_-qjg=.2be320db-57ab-4c70-bed1-01544e6b002e@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <pae02IMiuNrPAHK0yTGWCyIQihQqkpsYt4D1E_QR4TY=.871e0aa5-fdbd-4e53-8d69-260edc433d54@github.com>
 <dXBq8JSKlRq_BBmZEBqz2ZZCFs2Vut1xLjtEFvjcf8E=.c213821c-7195-4f86-b8e5-e757a327b264@github.com>
 <WNGEuG7Ai3IFdcnDSfWDAbDT_Gku6v3UwCuaQSqWnFo=.236fca1a-091d-47c0-8f88-9a7765d3f85c@github.com>
 <KYuQBNWwBWK1xZbJkKQaTOT1GDnzRm6AajAgACB6ETQ=.764f80f8-d291-4af1-a00c-5dd756e4ce5a@github.com>
 <S1z1hPuJNkQOMLFpMQ5TQ4jrAzy2rdSWbzEBtB_-qjg=.2be320db-57ab-4c70-bed1-01544e6b002e@github.com>
Message-ID: <ae09Ud9--uRhKCfEgy2X64eIvorRGexdE41IarN8boo=.d60f448c-1e0a-4325-b9f6-8e61574efeac@github.com>

On Fri, 24 Sep 2021 15:05:33 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> yes
>>     void Mutex::check_no_safepoint_state(Thread* thread) {
>>        check_block_state(thread);
>>        assert(!thread->is_active_Java_thread() || _safepoint_check_required != _safepoint_check_always,
>>               "This lock should always have a safepoint check for Java threads: %s",
>>               name());
>>      }
>> 
>> yes, we exclude the check for a non-java thread, which I thought was an odd exclusion last time I looked.  I pass the tests in sun/tools/jmap/BasicJMapTest.java so maybe leave it for now?
>
> I agree, maybe a new issue could be created for tracking this.

??

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From coleenp at openjdk.java.net  Fri Sep 24 16:59:18 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 16:59:18 GMT
Subject: RFR: 8274282: Clarify special wait assert [v2]
In-Reply-To: <WqwNwtyXz47rp5KUISxGDdipwpVnyhSiGgO1e3CSnx8=.f542830a-3598-4249-b418-d79aa9f09f44@github.com>
References: <WqwNwtyXz47rp5KUISxGDdipwpVnyhSiGgO1e3CSnx8=.f542830a-3598-4249-b418-d79aa9f09f44@github.com>
Message-ID: <NYVtWiSaVEKNn6NbgSLKsM1dONaIZW44aEwXgc3LHY4=.9f7d145e-aa06-4cc6-b2b7-19b257aa321f@github.com>

> This change removes the assert and tests for Mutex::wait() only allowed with greater than nosafepoint ranked held locks.
> Tested with tier1-3.

Coleen Phillimore 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:

  Fix wait checking code.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5684/files
  - new: https://git.openjdk.java.net/jdk/pull/5684/files/45b4776c..d5189887

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5684&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5684&range=00-01

  Stats: 70 lines in 4 files changed: 64 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5684.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5684/head:pull/5684

PR: https://git.openjdk.java.net/jdk/pull/5684

From coleenp at openjdk.java.net  Fri Sep 24 16:59:19 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 16:59:19 GMT
Subject: RFR: 8274282: Clarify special wait assert
In-Reply-To: <WqwNwtyXz47rp5KUISxGDdipwpVnyhSiGgO1e3CSnx8=.f542830a-3598-4249-b418-d79aa9f09f44@github.com>
References: <WqwNwtyXz47rp5KUISxGDdipwpVnyhSiGgO1e3CSnx8=.f542830a-3598-4249-b418-d79aa9f09f44@github.com>
Message-ID: <OdrF9m3xIjWOoxk9enfmQ9nJOg4MSoGadrbZYeXxsgc=.79052ff3-401a-4c8a-a080-cbfbbc1763bf@github.com>

On Fri, 24 Sep 2021 15:02:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change removes the assert and tests for Mutex::wait() only allowed with greater than nosafepoint ranked held locks.
> Tested with tier1-3.

I apologize I did a forced update.  @pchilano helped me work out why this assert exists in the code @dholmes-ora also worked it out but I didn't get it yesterday.  The reason for not waiting while holding a non-safepoint checking lock is that the wait could delay safepoints for a blocked thread, when the thread is a JavaThread.  This is because holding the nosafepoint lock has a NoSafepointVerifier, so we won't set the state to blocked while waiting on the lower ranked lock.
I fixed the code to do this assert for JavaThread and assert for NonJavaThread if the lock held is below tty, since that could block a lot of NJT operations.  Also updated one of the tests to call with NJT.
This should help the heap dumping code if it reverts to non-safepoint checking locking.  And also helps solve this mystery of what this code was for.

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

PR: https://git.openjdk.java.net/jdk/pull/5684

From rehn at openjdk.java.net  Fri Sep 24 17:00:00 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Fri, 24 Sep 2021 17:00:00 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock
In-Reply-To: <wPMmcBkqpzc4sCIlfhRoLwFeFIhbnRqqc3yZEb07NT8=.ea76b97a-8d0c-4919-aa3a-e42b3567b873@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <03Fvclcroars49mbVw2oyWttblbyG3VeL68wAlkSdDU=.6f624429-5ae8-4574-bfc6-f14b4b70717f@github.com>
 <wPMmcBkqpzc4sCIlfhRoLwFeFIhbnRqqc3yZEb07NT8=.ea76b97a-8d0c-4919-aa3a-e42b3567b873@github.com>
Message-ID: <OaN5e3dc7RPRuGe7ucJsShFXHUmb_VNDqYZnqlcPyLQ=.67011430-1484-4094-9f4e-770d87e12ff0@github.com>

On Wed, 22 Sep 2021 11:46:32 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

> > @robehn - There are a couple of other bugs that are considered duplicates
> > of this bug. Some of those track failures in Tier7 and Tier8 so it would be a
> > good idea to do testing up through Tier8.
> 
> I started more testing.

After some investigations it passes t6-t8 (unrelated failures).
@dcubed-ojdk thanks
@dholmes-ora noted

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From minqi at openjdk.java.net  Fri Sep 24 17:01:26 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 24 Sep 2021 17:01:26 GMT
Subject: RFR: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info [v2]
In-Reply-To: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
References: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
Message-ID: <lro3dbqx4uqeeLItZct8Hrg70gbSFZF8zANLLITqCfQ=.035ee3c6-202c-41cb-a0e3-6885f5f50436@github.com>

> Hi, please review the change for printing more info in jcmd terminal when dump shared archives. The ultimate shared archive file name is formed in java function (CDS.dumpSharedArchive) so to get the final archive name, the signature of CDS.dumpSharedArchive changed to return the archive name. At the end of dumping, return the archive name back to the caller so we can print out it in jcmd terminal.
> 
> Tests: ter1-4
>            manually checked the output of jcmd execution.
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fixed absolute path issue

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5643/files
  - new: https://git.openjdk.java.net/jdk/pull/5643/files/e0310efc..fd8efd5d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5643&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5643&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5643

From alanb at openjdk.java.net  Fri Sep 24 17:04:49 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 24 Sep 2021 17:04:49 GMT
Subject: RFR: 8274293: Build failure with Xcode 13.0 due to vfork is
 deprecated
In-Reply-To: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
References: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
Message-ID: <CGQVeIZD8TgK4YMfSvTuZ9x1irMRxLHBgevWPPirdiI=.8b6c1da8-8e77-445a-a68b-09470c8c3247@github.com>

On Fri, 24 Sep 2021 16:18:57 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> remove vfork() on Darwin

src/java.base/unix/native/libjava/ProcessImpl_md.c line 447:

> 445: #endif
> 446: 
> 447: /* vfork(2) is deprecated on Solaris and Darwin */

Drive by comment is that we can probably drop "Solaris" from the comment.

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

PR: https://git.openjdk.java.net/jdk/pull/5686

From minqi at openjdk.java.net  Fri Sep 24 18:17:56 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 24 Sep 2021 18:17:56 GMT
Subject: RFR: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info [v2]
In-Reply-To: <4dzTHvj7lAfklryZiiUF209oZfqwYhCAmLE3ZZRapJw=.e7e2dc67-dae0-416d-a614-566bd3513bcb@github.com>
References: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
 <4dzTHvj7lAfklryZiiUF209oZfqwYhCAmLE3ZZRapJw=.e7e2dc67-dae0-416d-a614-566bd3513bcb@github.com>
Message-ID: <xYsyRJ-sjsWFdyoYIUrOWoJKtKMesLFYpXyvIY5YTkA=.0465eb06-94ff-4298-9f47-a7d2b364351e@github.com>

On Fri, 24 Sep 2021 06:47:31 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed absolute path issue
>
> src/java.base/share/classes/jdk/internal/misc/CDS.java line 337:
> 
>> 335:         }
>> 336:         // Everyting goes well, print out the file name.
>> 337:         String archiveFilePath = cwd + File.separator + archiveFileName;
> 
> `archiveFileName` may already be a absolute path (e.g., "/tmp/foo.jar"), so this will print out something like /app/cwd//tmp/foo.jar, which will be incorrect. It should be changed to
> 
> 
> String archiveFilePath = new File(archiveFileName).getAbsolutePath();

Yes, it could be a absolute path already.

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

PR: https://git.openjdk.java.net/jdk/pull/5643

From coleenp at openjdk.java.net  Fri Sep 24 18:20:58 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 24 Sep 2021 18:20:58 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <-XuEnMJmy8mKo98VCPio-GN-BzYzNUaAeMj0cT2ivEo=.65cd9c5b-4953-4eb3-8976-c3d53e1478b5@github.com>

On Fri, 24 Sep 2021 13:13:39 GMT, Lin Zang <lzang at openjdk.org> wrote:

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

The lock stuff looks ok, but please have at least one of the original reviewers review the change.

test/hotspot/jtreg/ProblemList-zgc.txt line 49:

> 47: 
> 48: serviceability/dcmd/gc/HeapDumpAllTest.java                   8274196   linux-all,windows-all
> 49: serviceability/dcmd/gc/HeapDumpTest.java                      8274196   linux-all,windows-all

Before you push, you'll need to do a merge from mainline and should un-ProblemList sun/tools/jmap/BasicJMapTest.java.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5681

From pchilanomate at openjdk.java.net  Fri Sep 24 18:35:59 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Fri, 24 Sep 2021 18:35:59 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v3]
In-Reply-To: <lkk5J-wwMoMbp8VW-XBf2GzdbCEs2zLy27QB0mwMpZs=.c4b06014-3751-4a4d-95fb-39dc4e2af024@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <lkk5J-wwMoMbp8VW-XBf2GzdbCEs2zLy27QB0mwMpZs=.c4b06014-3751-4a4d-95fb-39dc4e2af024@github.com>
Message-ID: <oqtNONvgFRPpXdoNrINpfIuOL4Jgn_wrfvjoqNSX_EM=.f3c0da7b-a780-4394-adff-78676dec573a@github.com>

On Fri, 24 Sep 2021 16:48:38 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> We should not do any processing in SM::should_process().
>> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
>> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
>> 
>> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
>> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
>> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
>> 
>> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
>> 
>> Passes t1-t4 and local stressing.
>
> Robbin Ehn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed spelling

LGTM!

src/hotspot/share/runtime/safepointMechanism.inline.hpp line 90:

> 88:   // 3: The JavaThread wakes-up from blocked and does not allow suspend.
> 89:   // We are now about to avoid processing and thus no cross modify fence will be executed.
> 90:   // Therefore we execute it here.

I would just say we still need to execute this fence in case a safepoint happened while being blocked, and not mention step 1 since as commented above there might be nothing to process.

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

Marked as reviewed by pchilanomate (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5613

From mchung at openjdk.java.net  Fri Sep 24 22:34:00 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 24 Sep 2021 22:34:00 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v12]
In-Reply-To: <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com>
Message-ID: <PR774NH7uymdefiR2E836aOLY4I64GxpG9YkfU93k4k=.96ce8ea1-4ae0-4c83-a01e-66b66086b0d2@github.com>

On Fri, 24 Sep 2021 09:27:02 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   no precompiled headers and mtServiceability nmt classification

Hi Markus,

It's a little surprised to see Finalizer.c to depend JMM interface which is used by `java.management` and `jdk.management` modules only.   It's more appropriate for it to be a JVM_* entry point for Finalizer to report completion of the finalization instead.    I understand that you want to make FinalizerService to be a conditional feature which is a good idea.  Such JVM entry can be made as a nop if not INCLUDE_SERVICES.

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From iklam at openjdk.java.net  Sat Sep 25 00:09:01 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 25 Sep 2021 00:09:01 GMT
Subject: RFR: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info [v2]
In-Reply-To: <lro3dbqx4uqeeLItZct8Hrg70gbSFZF8zANLLITqCfQ=.035ee3c6-202c-41cb-a0e3-6885f5f50436@github.com>
References: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
 <lro3dbqx4uqeeLItZct8Hrg70gbSFZF8zANLLITqCfQ=.035ee3c6-202c-41cb-a0e3-6885f5f50436@github.com>
Message-ID: <AKKS6yhIdf90pLhAZiq7574Og4v4nANufh2lBIi75Mo=.127fc562-ca25-434c-9e3f-e52f56d5f096@github.com>

On Fri, 24 Sep 2021 17:01:26 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, please review the change for printing more info in jcmd terminal when dump shared archives. The ultimate shared archive file name is formed in java function (CDS.dumpSharedArchive) so to get the final archive name, the signature of CDS.dumpSharedArchive changed to return the archive name. At the end of dumping, return the archive name back to the caller so we can print out it in jcmd terminal.
>> 
>> Tests: ter1-4
>>            manually checked the output of jcmd execution.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed absolute path issue

LGTM

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5643

From github.com+7837910+xpbob at openjdk.java.net  Sat Sep 25 01:48:29 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Sat, 25 Sep 2021 01:48:29 GMT
Subject: RFR: 8274293: Build failure with Xcode 13.0 due to vfork is
 deprecated [v2]
In-Reply-To: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
References: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
Message-ID: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>

> remove vfork() on Darwin

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

  Drop drop "Solaris" from the comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5686/files
  - new: https://git.openjdk.java.net/jdk/pull/5686/files/89bb9c31..27d19543

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5686&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5686

From dcubed at openjdk.java.net  Sat Sep 25 04:03:14 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 25 Sep 2021 04:03:14 GMT
Subject: RFR: 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC on
 macOS-all
Message-ID: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>

A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on macOS-all.

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

Commit messages:
 - 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC on macos-all

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

PR: https://git.openjdk.java.net/jdk/pull/5691

From dcubed at openjdk.java.net  Sat Sep 25 05:19:24 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 25 Sep 2021 05:19:24 GMT
Subject: RFR: 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on macos-all [v2]
In-Reply-To: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
References: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
Message-ID: <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on macOS-all.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  8274313: ProblemList sun/tools/jmap/BasicJMapTest.java subtests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5691/files
  - new: https://git.openjdk.java.net/jdk/pull/5691/files/7d5c636a..c53c1cce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5691&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5691&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5691

From stuefe at openjdk.java.net  Sat Sep 25 05:26:54 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 25 Sep 2021 05:26:54 GMT
Subject: RFR: 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on macos-all [v2]
In-Reply-To: <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
References: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
 <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
Message-ID: <4uvT_9UUZFZHkTaz2NdS1efzmPKXwNe4oK2HXZbQXsE=.abf8fa31-b108-4ee9-bb23-54ab99d45a77@github.com>

On Sat, 25 Sep 2021 05:19:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on macOS-all.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274313: ProblemList sun/tools/jmap/BasicJMapTest.java subtests

Looks good and trivial.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5691

From sspitsyn at openjdk.java.net  Sat Sep 25 05:57:49 2021
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Sat, 25 Sep 2021 05:57:49 GMT
Subject: RFR: 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on macos-all [v2]
In-Reply-To: <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
References: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
 <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
Message-ID: <r38vCHNTwOtoXc2XaBkPqbaqYI_g55PPnokcV2-9mZo=.001dabfd-7304-45ee-9795-84f24b8ad216@github.com>

On Sat, 25 Sep 2021 05:19:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on macOS-all.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274313: ProblemList sun/tools/jmap/BasicJMapTest.java subtests

Looks good.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5691

From alanb at openjdk.java.net  Sat Sep 25 08:24:56 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 25 Sep 2021 08:24:56 GMT
Subject: RFR: 8274293: [macos] Build failure with Xcode 13.0 due to vfork
 is deprecated [v2]
In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
References: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
 <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
Message-ID: <VRUX6OLhJeFUgQ0DWlOn4b4sGgkrTRHIWaNOz4b9Bek=.fd464cc3-116f-4d0a-aa15-6ede7382ea6b@github.com>

On Sat, 25 Sep 2021 01:48:29 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> remove vfork() on Darwin
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop drop "Solaris" from the comment

I think this looks okay but would be good for @RogerRiggs to also review.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5686

From stuefe at openjdk.java.net  Sat Sep 25 10:14:04 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 25 Sep 2021 10:14:04 GMT
Subject: RFR: 8274293: Build failure on macOS with Xcode 13.0 as vfork is
 deprecated [v2]
In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
References: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
 <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
Message-ID: <fiGWebhUs3ChEDdAnkj-Vu5A0MwXfj9gj0sNyrBNAZo=.130727be-5f26-47c0-bc9d-546788b4b80f@github.com>

On Sat, 25 Sep 2021 01:48:29 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> remove vfork() on Darwin
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop drop "Solaris" from the comment

The JDK change is fine. AFAICS we have used posix_spawn by default on MacOS since at least 2015, and vfork was not even an option on MacOS.

Wrt the hotspot portion, we now fall back to fork. I wonder what the footprint penalty is compared to vfork. `os::fork_and_exec` gets used mainly by error reporting (`-XX:OnError`=xxx), e.g. in OOM situations. We now may run into situations where error analysis tools are unable to spawn if the parent is too big. Maybe we should change `os::fork_and_exec()` to use posix_spawn instead?

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

PR: https://git.openjdk.java.net/jdk/pull/5686

From dholmes at openjdk.java.net  Sat Sep 25 11:20:51 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 25 Sep 2021 11:20:51 GMT
Subject: RFR: 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on macos-all [v2]
In-Reply-To: <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
References: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
 <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
Message-ID: <eQ3NEqbVQQTRStfao7wZZphJpJL0bovQ5G_tMh2xM9o=.dffa2bea-ed62-4536-80cc-3d7d21f05cdd@github.com>

On Sat, 25 Sep 2021 05:19:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on macOS-all.
>
> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274313: ProblemList sun/tools/jmap/BasicJMapTest.java subtests

Marked as reviewed by dholmes (Reviewer).

test/jdk/ProblemList.txt line 824:

> 822: sun/tools/jmap/BasicJMapTest.java#Parallel                      8274245 generic-all
> 823: sun/tools/jmap/BasicJMapTest.java#Serial                        8274245 generic-all
> 824: sun/tools/jmap/BasicJMapTest.java#Z                             8274245 generic-all

I didn't think it was necessary to enumerate subtests like this?

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

PR: https://git.openjdk.java.net/jdk/pull/5691

From mgronlun at openjdk.java.net  Sat Sep 25 13:34:09 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 25 Sep 2021 13:34:09 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v13]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <Fh_aATAY2QHW-6PVsfqiOaKFM0ftJmdZ1oVm4ka6bu4=.b124f882-dd06-499d-b9d1-16a99a0e2ea4@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  jvm.h and JVM_Entry

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/5759c605..73091f7c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=11-12

  Stats: 52 lines in 6 files changed: 20 ins; 29 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4731/head:pull/4731

PR: https://git.openjdk.java.net/jdk/pull/4731

From dcubed at openjdk.java.net  Sat Sep 25 13:40:56 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 25 Sep 2021 13:40:56 GMT
Subject: RFR: 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on macos-all [v2]
In-Reply-To: <4uvT_9UUZFZHkTaz2NdS1efzmPKXwNe4oK2HXZbQXsE=.abf8fa31-b108-4ee9-bb23-54ab99d45a77@github.com>
References: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
 <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
 <4uvT_9UUZFZHkTaz2NdS1efzmPKXwNe4oK2HXZbQXsE=.abf8fa31-b108-4ee9-bb23-54ab99d45a77@github.com>
Message-ID: <GVDLajAggL9mjor7Vu5iDYNrQALxb6LCIABV9kGLzdA=.943203dd-ef39-4251-bfa7-910f831bc6d9@github.com>

On Sat, 25 Sep 2021 05:24:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274313: ProblemList sun/tools/jmap/BasicJMapTest.java subtests
>
> Looks good and trivial.

@tstuefe, @sspitsyn and @dholmes-ora - Thanks for the reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/5691

From dcubed at openjdk.java.net  Sat Sep 25 13:40:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 25 Sep 2021 13:40:57 GMT
Subject: RFR: 8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC
 on macos-all [v2]
In-Reply-To: <eQ3NEqbVQQTRStfao7wZZphJpJL0bovQ5G_tMh2xM9o=.dffa2bea-ed62-4536-80cc-3d7d21f05cdd@github.com>
References: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
 <iESOt5p_Fb4zi9264efWkVV3h_3n8iT75nRizpJDiAc=.377c7890-7d9e-41fc-852c-2b144a18d6c0@github.com>
 <eQ3NEqbVQQTRStfao7wZZphJpJL0bovQ5G_tMh2xM9o=.dffa2bea-ed62-4536-80cc-3d7d21f05cdd@github.com>
Message-ID: <_DJ1gYQeKiDA-PVVnoUukmKaNvVcO2BGAl8el34MDoM=.fd79ea66-f73d-4a56-8515-0e8bccf8eff9@github.com>

On Sat, 25 Sep 2021 11:17:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8274313: ProblemList sun/tools/jmap/BasicJMapTest.java subtests
>
> test/jdk/ProblemList.txt line 824:
> 
>> 822: sun/tools/jmap/BasicJMapTest.java#Parallel                      8274245 generic-all
>> 823: sun/tools/jmap/BasicJMapTest.java#Serial                        8274245 generic-all
>> 824: sun/tools/jmap/BasicJMapTest.java#Z                             8274245 generic-all
> 
> I didn't think it was necessary to enumerate subtests like this?

I didn't think so either, but the original ProblemListing bug:

JDK-8274294 ProblemList sun/tools/jmap/BasicJMapTest.java

didn't do the job.

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

PR: https://git.openjdk.java.net/jdk/pull/5691

From dcubed at openjdk.java.net  Sat Sep 25 13:40:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 25 Sep 2021 13:40:57 GMT
Subject: Integrated: 8274312: ProblemList 2 serviceability/dcmd/gc tests with
 ZGC on macos-all
In-Reply-To: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
References: <Yzvy08prDr2WYXQUZ3EqGMjcM_l46P5QUweOP4n6zPQ=.b6d1e29b-d7dc-40de-9f00-f7cb98ec2187@github.com>
Message-ID: <8UDLwQt1dYdQQu76Wh7vZfWA5dELWHDYK-NTmHpAN_0=.3431fa8a-f2db-4e31-bacc-e7baa9b7bd55@github.com>

On Sat, 25 Sep 2021 03:54:19 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList 2 serviceability/dcmd/gc tests with ZGC on macOS-all.

This pull request has now been integrated.

Changeset: ab28db14
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ab28db1428e7109934ef1ae17ad574ed8042b9a0
Stats:     6 lines in 2 files changed: 3 ins; 0 del; 3 mod

8274312: ProblemList 2 serviceability/dcmd/gc tests with ZGC on macos-all
8274313: ProblemList sun/tools/jmap/BasicJMapTest.java subtests

Reviewed-by: stuefe, sspitsyn, dholmes

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

PR: https://git.openjdk.java.net/jdk/pull/5691

From mgronlun at openjdk.java.net  Sat Sep 25 13:52:56 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 25 Sep 2021 13:52:56 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v12]
In-Reply-To: <PR774NH7uymdefiR2E836aOLY4I64GxpG9YkfU93k4k=.96ce8ea1-4ae0-4c83-a01e-66b66086b0d2@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <7qUo6JdWeitC5Tw90sAEdokNLL1B0cp7nU8pBRLFoOc=.9d912b5c-41f6-42cd-a393-85f46daad623@github.com>
 <PR774NH7uymdefiR2E836aOLY4I64GxpG9YkfU93k4k=.96ce8ea1-4ae0-4c83-a01e-66b66086b0d2@github.com>
Message-ID: <Z34bbuVo2gL2xRxb8_ZotCkH-F44_7KC-ODMlpyh2rE=.63aac305-8d71-4a8e-b739-5adcdbad5d7b@github.com>

On Fri, 24 Sep 2021 22:31:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> 
> 
> Hi Markus,
> 
> It's a little surprised to see Finalizer.c to depend JMM interface which is used by `java.management` and `jdk.management` modules only. It's more appropriate for it to be a JVM_* entry point for Finalizer to report completion of the finalization instead. I understand that you want to make FinalizerService to be a conditional feature which is a good idea. Such JVM entry can be made as a nop if not INCLUDE_SERVICES.

Thanks Mandy,
 
I choose jmm.h over jvm.h because I wanted the FinalizerService to be conditional, like some other services/management implementations in the VM. There is conditional compilation support for the 'management' component of the JVM, i.e. INCLUDE_MANAGMENT. The jvm.h function JVM_GetManagement(JMM_VERSION) returns null if this subsystem is not included in the JVM, making it easier to support this as a conditional feature. In addition, I had hoped to see if I could also expose some of this finalizer statistics information via JMX. I did not get around to that, but a few accessors can now easily be added to jmm.h to get to this information and build on it further, should that be useful. There is also the benefit of not having to perform a VM call every time, which is probably only a small upshot because the code will most often be included. 

These reasons do not seem strong enough to motivate a move outside of the original classification, so I am ok to put it into jvm.h instead of jmm.h and create a JVM_Entry with a conditionalized body.

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From mgronlun at openjdk.java.net  Sat Sep 25 14:22:28 2021
From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 25 Sep 2021 14:22:28 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v14]
In-Reply-To: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
Message-ID: <fIaB2PXsh3CzYloPDb1XsG1FNBGxzVeh5lKl8stGDeA=.16973d80-0625-4668-a244-bdeed79b2791@github.com>

> Greetings,
> 
> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
> 
> We also like to assist users in replacing and mitigating uses in non-JDK code.
> 
> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  symbols-unix

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4731/files
  - new: https://git.openjdk.java.net/jdk/pull/4731/files/73091f7c..4eaad60d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=4731&range=12-13

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

PR: https://git.openjdk.java.net/jdk/pull/4731

From stuefe at openjdk.java.net  Sat Sep 25 16:05:57 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 25 Sep 2021 16:05:57 GMT
Subject: RFR: 8274293: Build failure on macOS with Xcode 13.0 as vfork is
 deprecated [v2]
In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
References: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
 <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
Message-ID: <HcnhS4OhxSMXJ20CnLnRsBI86xl-Uq0Hia8NJi54lYQ=.73c2155c-ea50-4aec-a66d-2b486f2451db@github.com>

On Sat, 25 Sep 2021 01:48:29 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> remove vfork() on Darwin
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop drop "Solaris" from the comment

.. I opened https://bugs.openjdk.java.net/browse/JDK-8274320 to track the proposed change of os::fork_and_exec() to posix_spawn. So I am fine with this change.

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5686

From rriggs at openjdk.java.net  Sun Sep 26 01:20:04 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Sun, 26 Sep 2021 01:20:04 GMT
Subject: RFR: 8274293: Build failure on macOS with Xcode 13.0 as vfork is
 deprecated [v2]
In-Reply-To: <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
References: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
 <1gNjEaIKRg3DIqtvehDpCbV_rFH3HJSv2Q0_OfAR9Tg=.438ec9fc-9658-4bb5-819f-2a0f771d5466@github.com>
Message-ID: <BG2Xne3lWiRu10t5myuSwG--ujAOR1trCPVX9sKYR-g=.e1d9a391-68ca-48e0-90bf-a379b2a1effd@github.com>

On Sat, 25 Sep 2021 01:48:29 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

>> remove vfork() on Darwin
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop drop "Solaris" from the comment

Looks good, vfork is not/was not being used on Mac OS.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5686

From lzang at openjdk.java.net  Sun Sep 26 08:02:33 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Sun, 26 Sep 2021 08:02:33 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v2]
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <t9DP-2s2muQNNDvEGhxb1wEln1p_8WVyvgKqRRWuU38=.21f4d9e8-480a-4c30-9480-60337c2f2dbf@github.com>

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - un-ProblemList BasicJMapTest.java
 - Merge branch 'master' into pd-fix
 - 8274196: Crashes in VM_HeapDumper::work after JDK-8252842

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

Changes: https://git.openjdk.java.net/jdk/pull/5681/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=01
  Stats: 53 lines in 3 files changed: 22 ins; 28 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5681.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5681/head:pull/5681

PR: https://git.openjdk.java.net/jdk/pull/5681

From dcubed at openjdk.java.net  Sun Sep 26 08:59:50 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 26 Sep 2021 08:59:50 GMT
Subject: RFR: 8274324: ProblemList
 jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64
Message-ID: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>

A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64.

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

Commit messages:
 - 8274324: ProblemList jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64

Changes: https://git.openjdk.java.net/jdk/pull/5700/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5700&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274324
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5700.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5700/head:pull/5700

PR: https://git.openjdk.java.net/jdk/pull/5700

From kbarrett at openjdk.java.net  Sun Sep 26 08:59:50 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 26 Sep 2021 08:59:50 GMT
Subject: RFR: 8274324: ProblemList
 jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64
In-Reply-To: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
References: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
Message-ID: <kv4EIlDJaQ8ghUjyf4GXtH1kRd3qXw4wg-bi1_IeL-Q=.a6212f86-cfdb-4a96-967a-c567a7b5d062@github.com>

On Sun, 26 Sep 2021 02:13:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5700

From egahlin at openjdk.java.net  Sun Sep 26 09:07:09 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Sun, 26 Sep 2021 09:07:09 GMT
Subject: RFR: 8274324: ProblemList
 jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64
In-Reply-To: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
References: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
Message-ID: <Jx1qAPqM4Gu_TeII2EAHhZkJstkO4csF7MIEf_aLpTA=.ebc24e8e-fe29-4f0b-8f13-7a0b7ccba6a9@github.com>

On Sun, 26 Sep 2021 02:13:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64.

There is a real fix here, but it needs a reviewer.
https://github.com/openjdk/jdk/pull/5703

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

PR: https://git.openjdk.java.net/jdk/pull/5700

From dcubed at openjdk.java.net  Sun Sep 26 14:05:06 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 26 Sep 2021 14:05:06 GMT
Subject: RFR: 8274324: ProblemList
 jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64
In-Reply-To: <kv4EIlDJaQ8ghUjyf4GXtH1kRd3qXw4wg-bi1_IeL-Q=.a6212f86-cfdb-4a96-967a-c567a7b5d062@github.com>
References: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
 <kv4EIlDJaQ8ghUjyf4GXtH1kRd3qXw4wg-bi1_IeL-Q=.a6212f86-cfdb-4a96-967a-c567a7b5d062@github.com>
Message-ID: <nrU53eF-X8k1q92DLfSdHeQH09W1cj35HgrXz5hE_5I=.edeebaaa-0d8c-4a58-b246-1f80709e32cb@github.com>

On Sun, 26 Sep 2021 04:38:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64.
>
> Looks good.

@kimbarrett - Thanks for the review. The bots are down so I don't
think I can "/integrate". Also, it looks like @egahlin has a real fix so
this ProblemListing can likely be thrown away. Will investigate
further after breakfast...

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

PR: https://git.openjdk.java.net/jdk/pull/5700

From github.com+7837910+xpbob at openjdk.java.net  Sun Sep 26 14:52:01 2021
From: github.com+7837910+xpbob at openjdk.java.net (xpbob)
Date: Sun, 26 Sep 2021 14:52:01 GMT
Subject: Integrated: 8274293: Build failure on macOS with Xcode 13.0 as vfork
 is deprecated
In-Reply-To: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
References: <KiUIvG8_CAL1YVQdDvD_5x5P8d2cocdEx4x9tKgsOUs=.bae81a1e-6411-4ee2-814c-b8b4aa134752@github.com>
Message-ID: <QDxj_7CMEBWWIgvFWF5Jng-fFUOSdBXcu1gBQQWj3OQ=.0261b87a-32ff-4e31-ad47-5d978974a79a@github.com>

On Fri, 24 Sep 2021 16:18:57 GMT, xpbob <github.com+7837910+xpbob at openjdk.org> wrote:

> remove vfork() on Darwin

This pull request has now been integrated.

Changeset: 252aaa92
Author:    bobpengxie <bobpengxie at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/252aaa9249d8979366b37d59487b5b039d923e35
Stats:     10 lines in 2 files changed: 8 ins; 0 del; 2 mod

8274293: Build failure on macOS with Xcode 13.0 as vfork is deprecated

Reviewed-by: alanb, stuefe, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/5686

From dcubed at openjdk.java.net  Sun Sep 26 15:03:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 26 Sep 2021 15:03:01 GMT
Subject: RFR: 8274324: ProblemList
 jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64
In-Reply-To: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
References: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
Message-ID: <gBogLGs6hUjz3qaislEYoyKBh59KGTSp_Ygf9RTogTw=.1d386b2b-0ac7-434f-9648-51c0e819bff7@github.com>

On Sun, 26 Sep 2021 02:13:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64.

#5703 is reviewed and waiting for the bots to wake up so it can be integrated.
I'll close this PR without integrating it.

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

PR: https://git.openjdk.java.net/jdk/pull/5700

From dcubed at openjdk.java.net  Sun Sep 26 15:03:01 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sun, 26 Sep 2021 15:03:01 GMT
Subject: Withdrawn: 8274324: ProblemList
 jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64
In-Reply-To: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
References: <QdARkULWY8ZQv9gndPL0ubm7OFi-P54fBt6lgOG3k5Q=.10e8c0c6-0d63-4b0e-a0d1-da15d3c01abf@github.com>
Message-ID: <yV1c_yCKA1ZCvksL4Um5oPfgbjtAXw2vmklZAmu0Mg0=.4abaa427-5e95-43a4-8e74-4a75937c12ee@github.com>

On Sun, 26 Sep 2021 02:13:36 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/jfr/api/consumer/TestRecordedFrameType.java on linux-aarch64.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/5700

From dholmes at openjdk.java.net  Mon Sep 27 03:36:55 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 27 Sep 2021 03:36:55 GMT
Subject: RFR: JDK-8274283: string-concatenation build warning as error
 with clang 13 on macOS aarch64
In-Reply-To: <rs95-o9fB9_J_zt2rtKZRu1vEWe8W53r4lwJki4gp9w=.432e0892-75b6-43ca-8a22-b6ba8cd433a1@github.com>
References: <rs95-o9fB9_J_zt2rtKZRu1vEWe8W53r4lwJki4gp9w=.432e0892-75b6-43ca-8a22-b6ba8cd433a1@github.com>
Message-ID: <AOU_Mq3Wt9oyOo-Rzu0AHNLDDJZgjpXZkzjksbsKdxQ=.ca715541-04cf-43d5-b8dd-710c6a521d9a@github.com>

On Fri, 24 Sep 2021 12:43:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small fix fixing builds using clang 13.
> We run into this error when compiling with clang version 13.0.0 (clang-1300.0.29.3) :

@MBaesken this is a duplicate of 

https://github.com/openjdk/jdk/pull/5675

but that PR fixes two issues in this area so I would suggest closing this one and going with what @jespersm has done.

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

PR: https://git.openjdk.java.net/jdk/pull/5680

From mbaesken at openjdk.java.net  Mon Sep 27 06:35:08 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 27 Sep 2021 06:35:08 GMT
Subject: RFR: JDK-8274283: string-concatenation build warning as error
 with clang 13 on macOS aarch64
In-Reply-To: <rs95-o9fB9_J_zt2rtKZRu1vEWe8W53r4lwJki4gp9w=.432e0892-75b6-43ca-8a22-b6ba8cd433a1@github.com>
References: <rs95-o9fB9_J_zt2rtKZRu1vEWe8W53r4lwJki4gp9w=.432e0892-75b6-43ca-8a22-b6ba8cd433a1@github.com>
Message-ID: <RSItdcEMpf9a6vh75_3VZtUk32Xt2ICuZdXYHUhUbjo=.ca4a312f-2c1a-49cf-b868-89686a79665e@github.com>

On Fri, 24 Sep 2021 12:43:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small fix fixing builds using clang 13.
> We run into this error when compiling with clang version 13.0.0 (clang-1300.0.29.3) :

fixed by https://bugs.openjdk.java.net/browse/JDK-8274265, so I close this one.

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

PR: https://git.openjdk.java.net/jdk/pull/5680

From mbaesken at openjdk.java.net  Mon Sep 27 06:35:09 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 27 Sep 2021 06:35:09 GMT
Subject: Withdrawn: JDK-8274283: string-concatenation build warning as error
 with clang 13 on macOS aarch64
In-Reply-To: <rs95-o9fB9_J_zt2rtKZRu1vEWe8W53r4lwJki4gp9w=.432e0892-75b6-43ca-8a22-b6ba8cd433a1@github.com>
References: <rs95-o9fB9_J_zt2rtKZRu1vEWe8W53r4lwJki4gp9w=.432e0892-75b6-43ca-8a22-b6ba8cd433a1@github.com>
Message-ID: <LOfshBIPOSANpj66erpi_aS9uy55Gs5kJRbSfkeF6Wg=.f7525bc7-7505-42ea-878b-d62bb9e6d370@github.com>

On Fri, 24 Sep 2021 12:43:32 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Please review this small fix fixing builds using clang 13.
> We run into this error when compiling with clang version 13.0.0 (clang-1300.0.29.3) :

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/5680

From clanger at openjdk.java.net  Mon Sep 27 08:19:57 2021
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 27 Sep 2021 08:19:57 GMT
Subject: RFR: 8274265: Suspicious string concatenation in test code
In-Reply-To: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
References: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
Message-ID: <toO37TVgIg1UwsbLtpdXZlEqNFdvXVqdWX1-rXRmdVI=.d9122ea3-6928-4c77-9b14-2ac96eb85885@github.com>

On Fri, 24 Sep 2021 08:49:16 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This patch fixes the mishap, and lets JDK compile under XCode 13 / LLVM 13.

Marked as reviewed by clanger (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5675

From mbaesken at openjdk.java.net  Mon Sep 27 08:24:01 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Mon, 27 Sep 2021 08:24:01 GMT
Subject: RFR: 8274265: Suspicious string concatenation in test code
In-Reply-To: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
References: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
Message-ID: <45ILOZGoJhbCjzsaJGZj7ZksObCTXeormFKYAfNTykI=.3d5a3854-4bbd-4479-bab8-470925165e67@github.com>

On Fri, 24 Sep 2021 08:49:16 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This patch fixes the mishap, and lets JDK compile under XCode 13 / LLVM 13.

Looks good to me !
Thanks, Matthias

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

Marked as reviewed by mbaesken (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5675

From pliden at openjdk.java.net  Mon Sep 27 09:43:12 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 27 Sep 2021 09:43:12 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v2]
In-Reply-To: <t9DP-2s2muQNNDvEGhxb1wEln1p_8WVyvgKqRRWuU38=.21f4d9e8-480a-4c30-9480-60337c2f2dbf@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <t9DP-2s2muQNNDvEGhxb1wEln1p_8WVyvgKqRRWuU38=.21f4d9e8-480a-4c30-9480-60337c2f2dbf@github.com>
Message-ID: <GfpHj8dpTQrkxd9SMOTfwBO2UaDT1IgnAFl91_q-HRI=.577c90fe-4a99-4869-86da-265e2f04702b@github.com>

On Sun, 26 Sep 2021 08:02:33 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
>> 
>> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
>> 
>> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.
>
> Lin Zang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - un-ProblemList BasicJMapTest.java
>  - Merge branch 'master' into pd-fix
>  - 8274196: Crashes in VM_HeapDumper::work after JDK-8252842

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.

The fix here should not be to change the order of stuff, so that heap iteration happens first, that will just hide the real bug. The real bug is that the `JNIGlobalsDumper::do_oop()` is missing a load barrier. In other words, keep the order and just make sure to add a load barrier, like this:


void JNIGlobalsDumper::do_oop(oop* obj_p) {
  oop o = NativeAccess<AS_NO_KEEPALIVE>::oop_load(obj_p);
  ...

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

Changes requested by pliden (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Mon Sep 27 11:28:02 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 27 Sep 2021 11:28:02 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v2]
In-Reply-To: <GfpHj8dpTQrkxd9SMOTfwBO2UaDT1IgnAFl91_q-HRI=.577c90fe-4a99-4869-86da-265e2f04702b@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <t9DP-2s2muQNNDvEGhxb1wEln1p_8WVyvgKqRRWuU38=.21f4d9e8-480a-4c30-9480-60337c2f2dbf@github.com>
 <GfpHj8dpTQrkxd9SMOTfwBO2UaDT1IgnAFl91_q-HRI=.577c90fe-4a99-4869-86da-265e2f04702b@github.com>
Message-ID: <O6m8yTQJj7RQuF9y8B9huclanhZ0UedsE-qGpxwZ0P8=.4ec0b797-63f6-4261-9750-0841b852366d@github.com>

On Mon, 27 Sep 2021 09:39:59 GMT, Per Liden <pliden at openjdk.org> wrote:

> > The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The fix here should not be to change the order of stuff, so that heap iteration happens first, that will just hide the real bug. The real bug is that the `JNIGlobalsDumper::do_oop()` is missing a load barrier. In other words, keep the order and just make sure to add a load barrier, like this:
> 
> ```
> void JNIGlobalsDumper::do_oop(oop* obj_p) {
>   oop o = NativeAccess<AS_NO_KEEPALIVE>::oop_load(obj_p);
>   ...
> ```

Hi Per @pliden ,
Thanks a lot?
Correct?I am just puzzling why the sequency of root type dump is a must as there is no such request in spec, and your suggestion definitely help to answer that, I took the wrong fix and neglect that there is a read barrier missed.
I will make the change.

BRs,
Lin

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Mon Sep 27 12:00:56 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 27 Sep 2021 12:00:56 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v3]
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <9lA5QLpliCPex_--98RPabUAEqK0crK8H_Wb_7NJp3Y=.85efd571-79cf-4be7-a1fb-975634ae6000@github.com>

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  Add missing read barrier

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5681/files
  - new: https://git.openjdk.java.net/jdk/pull/5681/files/91f1c349..c1658e19

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=01-02

  Stats: 34 lines in 1 file changed: 16 ins; 16 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5681.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5681/head:pull/5681

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Mon Sep 27 12:02:53 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 27 Sep 2021 12:02:53 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v4]
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <NlrQDH88D5q6SyMDfiCLpZQnEXCBbdsxMZllx7ZOKZg=.d96b4ac9-5faf-41fb-b9e5-2ecea5bde7a1@github.com>

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant empty line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5681/files
  - new: https://git.openjdk.java.net/jdk/pull/5681/files/c1658e19..f6cb2123

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From pliden at openjdk.java.net  Mon Sep 27 13:10:07 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 27 Sep 2021 13:10:07 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v4]
In-Reply-To: <NlrQDH88D5q6SyMDfiCLpZQnEXCBbdsxMZllx7ZOKZg=.d96b4ac9-5faf-41fb-b9e5-2ecea5bde7a1@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <NlrQDH88D5q6SyMDfiCLpZQnEXCBbdsxMZllx7ZOKZg=.d96b4ac9-5faf-41fb-b9e5-2ecea5bde7a1@github.com>
Message-ID: <mJewMw8n4Ttji6JxPTNhY3wMJ1AALGG6YD-mX6II8wY=.a731ab71-c7b8-45f4-a6a4-cad461f80582@github.com>

On Mon, 27 Sep 2021 12:02:53 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
>> 
>> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
>> 
>> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant empty line

src/hotspot/share/services/heapDumper.cpp line 1601:

> 1599: void JNILocalsDumper::do_oop(oop* obj_p) {
> 1600:   // ignore null handles
> 1601:   oop o = NativeAccess<AS_NO_KEEPALIVE>::oop_load(obj_p);

The JNI Local roots do not need a load barrier, only JNI Global roots need that. The JNI Local roots are processed on safepoint entry as part of the "thread head" (via `ZStackWatermark::ZStackWatermark::start_processing_impl()` -> `Thread::oops_do_no_frames()`), so once you are in `VM_HeapDumper::do_thread()` the JNI Local roots have already passed a load barrier.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Mon Sep 27 14:28:47 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 27 Sep 2021 14:28:47 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v4]
In-Reply-To: <mJewMw8n4Ttji6JxPTNhY3wMJ1AALGG6YD-mX6II8wY=.a731ab71-c7b8-45f4-a6a4-cad461f80582@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <NlrQDH88D5q6SyMDfiCLpZQnEXCBbdsxMZllx7ZOKZg=.d96b4ac9-5faf-41fb-b9e5-2ecea5bde7a1@github.com>
 <mJewMw8n4Ttji6JxPTNhY3wMJ1AALGG6YD-mX6II8wY=.a731ab71-c7b8-45f4-a6a4-cad461f80582@github.com>
Message-ID: <qyet0QF8RAOjNtKxO81uu9AkqjcJwfa9e5Evc4MLuAg=.b5f5b548-2884-4f4c-8bb1-f42fc293b24a@github.com>

On Mon, 27 Sep 2021 13:06:57 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove redundant empty line
>
> src/hotspot/share/services/heapDumper.cpp line 1601:
> 
>> 1599: void JNILocalsDumper::do_oop(oop* obj_p) {
>> 1600:   // ignore null handles
>> 1601:   oop o = NativeAccess<AS_NO_KEEPALIVE>::oop_load(obj_p);
> 
> The JNI Local roots do not need a load barrier, only JNI Global roots need that. The JNI Local roots are processed on safepoint entry as part of the "thread head" (via `ZStackWatermark::ZStackWatermark::start_processing_impl()` -> `Thread::oops_do_no_frames()`), so once you are in `VM_HeapDumper::do_thread()` the JNI Local roots have already passed a load barrier.

Get it, Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Mon Sep 27 14:28:43 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Mon, 27 Sep 2021 14:28:43 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v5]
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  remove load barrier for JNI local roots

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5681/files
  - new: https://git.openjdk.java.net/jdk/pull/5681/files/f6cb2123..db77cdaa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5681&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From ccheung at openjdk.java.net  Mon Sep 27 18:22:09 2021
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Mon, 27 Sep 2021 18:22:09 GMT
Subject: RFR: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info [v2]
In-Reply-To: <lro3dbqx4uqeeLItZct8Hrg70gbSFZF8zANLLITqCfQ=.035ee3c6-202c-41cb-a0e3-6885f5f50436@github.com>
References: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
 <lro3dbqx4uqeeLItZct8Hrg70gbSFZF8zANLLITqCfQ=.035ee3c6-202c-41cb-a0e3-6885f5f50436@github.com>
Message-ID: <lQFRUc6YHsc_u4UcEAReziToXatJ7Yix4GyjXVMSEvg=.96983d4d-3ec1-4462-b091-aade95cf30f2@github.com>

On Fri, 24 Sep 2021 17:01:26 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Hi, please review the change for printing more info in jcmd terminal when dump shared archives. The ultimate shared archive file name is formed in java function (CDS.dumpSharedArchive) so to get the final archive name, the signature of CDS.dumpSharedArchive changed to return the archive name. At the end of dumping, return the archive name back to the caller so we can print out it in jcmd terminal.
>> 
>> Tests: ter1-4
>>            manually checked the output of jcmd execution.
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed absolute path issue

LGTM.

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

Marked as reviewed by ccheung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5643

From mchung at openjdk.java.net  Mon Sep 27 19:21:05 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 27 Sep 2021 19:21:05 GMT
Subject: RFR: 8266936: Add a finalization JFR event [v14]
In-Reply-To: <fIaB2PXsh3CzYloPDb1XsG1FNBGxzVeh5lKl8stGDeA=.16973d80-0625-4668-a244-bdeed79b2791@github.com>
References: <PpWS13N5Xk6jE-2GGuVjVbd9KgG11x85fFDHww7fMeA=.cbfa8c67-2ead-4db5-ade3-f2bc45565b11@github.com>
 <fIaB2PXsh3CzYloPDb1XsG1FNBGxzVeh5lKl8stGDeA=.16973d80-0625-4668-a244-bdeed79b2791@github.com>
Message-ID: <lx2ICCaSm67C1pFFO79u_WOQ7OTfPCOB91GTObNp5c0=.2be655a1-9924-44bf-b7c9-7bbee2d111a5@github.com>

On Sat, 25 Sep 2021 14:22:28 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Object.finalize() was deprecated in JDK9. There is an ongoing effort to replace and mitigate Object.finalize() uses in the JDK libraries; please see https://bugs.openjdk.java.net/browse/JDK-8253568 for more information. 
>> 
>> We also like to assist users in replacing and mitigating uses in non-JDK code.
>> 
>> Hence, this changeset adds a periodic JFR event to help identify which classes are overriding Object.finalize().
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   symbols-unix

I reviewed the change in java.base that looks good.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4731

From minqi at openjdk.java.net  Mon Sep 27 21:26:09 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 27 Sep 2021 21:26:09 GMT
Subject: RFR: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info [v2]
In-Reply-To: <AKKS6yhIdf90pLhAZiq7574Og4v4nANufh2lBIi75Mo=.127fc562-ca25-434c-9e3f-e52f56d5f096@github.com>
References: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
 <lro3dbqx4uqeeLItZct8Hrg70gbSFZF8zANLLITqCfQ=.035ee3c6-202c-41cb-a0e3-6885f5f50436@github.com>
 <AKKS6yhIdf90pLhAZiq7574Og4v4nANufh2lBIi75Mo=.127fc562-ca25-434c-9e3f-e52f56d5f096@github.com>
Message-ID: <zqHnNNLNcoPWOYsCyx3K461qXBP2yPJPDTxFY4cq7Xs=.505b425d-51ad-4279-9992-da79f454b68d@github.com>

On Sat, 25 Sep 2021 00:05:40 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed absolute path issue
>
> LGTM

@iklam @calvinccheung 
Thanks for review!

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

PR: https://git.openjdk.java.net/jdk/pull/5643

From minqi at openjdk.java.net  Mon Sep 27 21:31:21 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Mon, 27 Sep 2021 21:31:21 GMT
Subject: Integrated: 8271303: jcmd VM.cds {static,
 dynamic}_dump should print more info
In-Reply-To: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
References: <sXmiPNlhRQSLWU4nIUbINcSUfaJMhIRCfTu09m8IiuI=.75f1475f-eb39-4dd2-bc4d-6b16b269f41f@github.com>
Message-ID: <6rJIO_15MF6-tsVA8ArHdTNg7diEyT1rV9KP4UzXuk8=.a8b7c7ec-cf30-48d2-8b2d-532dc41e8444@github.com>

On Thu, 23 Sep 2021 00:52:40 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, please review the change for printing more info in jcmd terminal when dump shared archives. The ultimate shared archive file name is formed in java function (CDS.dumpSharedArchive) so to get the final archive name, the signature of CDS.dumpSharedArchive changed to return the archive name. At the end of dumping, return the archive name back to the caller so we can print out it in jcmd terminal.
> 
> Tests: ter1-4
>            manually checked the output of jcmd execution.
> 
> Thanks
> Yumin

This pull request has now been integrated.

Changeset: c4b52c73
Author:    Yumin Qi <minqi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4b52c7378183ab0fb987cc571c1debea450e125
Stats:     15 lines in 3 files changed: 9 ins; 0 del; 6 mod

8271303: jcmd VM.cds {static, dynamic}_dump should print more info

Reviewed-by: iklam, ccheung

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

PR: https://git.openjdk.java.net/jdk/pull/5643

From iklam at openjdk.java.net  Tue Sep 28 06:22:56 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 28 Sep 2021 06:22:56 GMT
Subject: RFR: 8274265: Suspicious string concatenation in test code
In-Reply-To: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
References: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
Message-ID: <nba6AE9YR1PhK8tQV78mixQChvKIJqppipRDSzbpvvM=.851af14d-664b-4a9e-90d6-83a5b4f44453@github.com>

On Fri, 24 Sep 2021 08:49:16 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This patch fixes the mishap, and lets JDK compile under XCode 13 / LLVM 13.

I've updated the RFE title to be more specific. Please update the PR title to match the RFE before integration.

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

PR: https://git.openjdk.java.net/jdk/pull/5675

From pliden at openjdk.java.net  Tue Sep 28 07:50:06 2021
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 28 Sep 2021 07:50:06 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v5]
In-Reply-To: <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
Message-ID: <pOEgxUbRqzQlolht9dm2eIpGlCiGU86ZIyVMybWDbjc=.3c581af6-8fe3-41cc-9b12-3353661ed3f3@github.com>

On Mon, 27 Sep 2021 14:28:43 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
>> 
>> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
>> 
>> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove load barrier for JNI local roots

The load barrier part of this now looks good to me.

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

Marked as reviewed by pliden (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5681

From mbaesken at openjdk.java.net  Tue Sep 28 11:20:17 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Tue, 28 Sep 2021 11:20:17 GMT
Subject: RFR: JDK-8274434: move os::get_default_process_handle and
 os::dll_lookup to os_posix for POSIX platforms
Message-ID: <4Dt5972d0-anhV1jfU2BCrcaaANGedVnxNkrFjPz34M=.55c5f633-a698-4c33-898c-bacb1127075e@github.com>

Hello, please review this small change.
The os::get_default_process_handle and os::dll_lookup functions are pretty similar across the POSIX platforms so they can be moved to os_posix.cpp.

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

Commit messages:
 - JDK-8274434

Changes: https://git.openjdk.java.net/jdk/pull/5737/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5737&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274434
  Stats: 49 lines in 4 files changed: 15 ins; 34 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5737.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5737/head:pull/5737

PR: https://git.openjdk.java.net/jdk/pull/5737

From sgehwolf at openjdk.java.net  Tue Sep 28 16:15:28 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Tue, 28 Sep 2021 16:15:28 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman
Message-ID: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>

Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.

Thoughts?

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

Commit messages:
 - 8273216: JCMD does not work across container boundaries with Podman

Changes: https://git.openjdk.java.net/jdk/pull/5740/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5740&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273216
  Stats: 32 lines in 1 file changed: 16 ins; 9 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5740/head:pull/5740

PR: https://git.openjdk.java.net/jdk/pull/5740

From pchilanomate at openjdk.java.net  Tue Sep 28 17:49:00 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Tue, 28 Sep 2021 17:49:00 GMT
Subject: RFR: 8274379: Allow process of unsafe access errors in
 check_special_condition_for_native_trans
Message-ID: <uiJntp85SAthbMdpFuvtCdx4bR8Zwr5X_gA2RTxOe4g=.0f1aa158-8f1b-4318-8e3a-e8ff727e99f2@github.com>

Hi,


Please review the following patch to allow processing of unsafe access errors in check_special_condition_for_native_trans().

Today we special case unsafe access errors from other async exceptions in that we don't process them when transitioning from native back to Java. Code comments in check_special_condition_for_native_trans() mention that unsafe access errors should not be handled because that may block while creating the exception. But that should not be an issue since we can always make sure we call process_if_requested_with_exit_check() after the call to throw_unsafe_access_internal_error() to process any pending operations not already handled in a ThreadBlockInVM wrapper (today that only means suspend requests and object reallocation operations).

By removing this special treatment for unsafe access errors we can also simplify the async exception support API. For instance we can remove _async_exception_condition and simplify some of the supporting methods. I also removed the _thread_in_native case from the switch statement in check_and_handle_async_exceptions() since we never call that method in that state.

Testing by running tiers1-6 in mach5. 

Thanks,
Patricio

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

Commit messages:
 - v1

Changes: https://git.openjdk.java.net/jdk/pull/5741/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5741&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274379
  Stats: 94 lines in 7 files changed: 15 ins; 51 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5741.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5741/head:pull/5741

PR: https://git.openjdk.java.net/jdk/pull/5741

From jespersm at openjdk.java.net  Tue Sep 28 18:25:45 2021
From: jespersm at openjdk.java.net (Jesper Steen =?UTF-8?B?TcO4bGxlcg==?=)
Date: Tue, 28 Sep 2021 18:25:45 GMT
Subject: Integrated: 8274265: Suspicious string concatenation in
 logTestUtils.inline.hpp
In-Reply-To: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
References: <tCg-R_D_U8hFFxRMPu2lQ8K-TsR2n1HKzKpiESAew9Q=.cabaf6ac-ecbc-4370-839d-0143427456f1@github.com>
Message-ID: <EV1cSF_O3XObRvn_BbyGwF-O-rby2v4ch7hgmuzpBKI=.0a086760-1055-4ace-a506-dadf1f70928c@github.com>

On Fri, 24 Sep 2021 08:49:16 GMT, Jesper Steen M?ller <jespersm at openjdk.org> wrote:

> This patch fixes the mishap, and lets JDK compile under XCode 13 / LLVM 13.

This pull request has now been integrated.

Changeset: c57a6c62
Author:    Jesper Steen M?ller <jespersm at openjdk.org>
Committer: Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c57a6c62baecde0bc10bfca89e0616b0c1fbb714
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8274265: Suspicious string concatenation in logTestUtils.inline.hpp

Reviewed-by: clanger, mbaesken

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

PR: https://git.openjdk.java.net/jdk/pull/5675

From mseledtsov at openjdk.java.net  Tue Sep 28 21:34:37 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 28 Sep 2021 21:34:37 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman
In-Reply-To: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
Message-ID: <IzOpIMCJhtn3znILF5nUQbwRdm_mA3PqC2XQBIRoseQ=.fb42d5e3-50c8-4f8e-9313-ad0aca753cf2@github.com>

On Tue, 28 Sep 2021 16:05:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
> 
> Thoughts?

Severin, thank you for addressing this issue. Overall the change looks good.

I ran your change through Oracle's test system, and the Docker case passes. However, a Podman case fails when running 'jcmd -l' attempting to find the target test child process - could not find it. Please note that we run both Docker and Podman tests in non-root mode (a regular "test user"). Perhaps the test should have conditional guards for it, and throw a jtreg.SkippedException for Podman non-root user with a short message?

---------System.err:(13/757)----------
java.lang.RuntimeException: Could not find specified process
	at TestJcmd.testJcmdGetPid(TestJcmd.java:103)
	at TestJcmd.main(TestJcmd.java:72)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
	at java.base/java.lang.Thread.run(Thread.java:833)

JavaTest Message: Test threw exception: java.lang.RuntimeException
JavaTest Message: shutting down test

result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Could not find specified process

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

PR: https://git.openjdk.java.net/jdk/pull/5740

From mseledtsov at openjdk.java.net  Tue Sep 28 21:38:30 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Tue, 28 Sep 2021 21:38:30 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman
In-Reply-To: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
Message-ID: <gkeEFgmQsVP5SxrsV_ZwTVwhQZ8O-Xc_fLLhGf8Zp6g=.0ab73570-4f9c-4bd7-b857-658d667a3d4d@github.com>

On Tue, 28 Sep 2021 16:05:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
> 
> Thoughts?

Also, I checked a Podman version on our test systems: it is earlier/below 3.3.1. Perhaps the conditional guard in the test should check for that as well, and if version is below 3.3.1, we should check if user is root, and throw SkippedException if not?

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

PR: https://git.openjdk.java.net/jdk/pull/5740

From lzang at openjdk.java.net  Tue Sep 28 22:36:37 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Tue, 28 Sep 2021 22:36:37 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v5]
In-Reply-To: <pOEgxUbRqzQlolht9dm2eIpGlCiGU86ZIyVMybWDbjc=.3c581af6-8fe3-41cc-9b12-3353661ed3f3@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
 <pOEgxUbRqzQlolht9dm2eIpGlCiGU86ZIyVMybWDbjc=.3c581af6-8fe3-41cc-9b12-3353661ed3f3@github.com>
Message-ID: <PjHQ5jEMjq5QCzFvgjE45WKYbHKB7hu3zWHvm2JEC3Y=.149fffa0-621c-47f6-964d-9e6fe2ed80f3@github.com>

On Tue, 28 Sep 2021 07:46:27 GMT, Per Liden <pliden at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove load barrier for JNI local roots
>
> The load barrier part of this now looks good to me.

Thanks @pliden for help review and approve.

Dear Chris(@plummercj) and Ralf(@schmelter-sap), may I ask your help to review this fix of JDK-8252842?  Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From dholmes at openjdk.java.net  Wed Sep 29 04:02:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 29 Sep 2021 04:02:35 GMT
Subject: RFR: JDK-8274434: move os::get_default_process_handle and
 os::dll_lookup to os_posix for POSIX platforms
In-Reply-To: <4Dt5972d0-anhV1jfU2BCrcaaANGedVnxNkrFjPz34M=.55c5f633-a698-4c33-898c-bacb1127075e@github.com>
References: <4Dt5972d0-anhV1jfU2BCrcaaANGedVnxNkrFjPz34M=.55c5f633-a698-4c33-898c-bacb1127075e@github.com>
Message-ID: <TkOquoj7MK6zK74_XhDtk7Nl-pzhQbKw9enZYJKsIz0=.ce5c0f80-d371-4e45-afaf-7d70a0cc54f2@github.com>

On Tue, 28 Sep 2021 11:13:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small change.
> The os::get_default_process_handle and os::dll_lookup functions are pretty similar across the POSIX platforms so they can be moved to os_posix.cpp.

Hi Matthias,

The refactoring is fine, but I do wonder (future cleanup ok) if we actually need the macOS special case - see comment below.

Thanks,
David

src/hotspot/os/posix/os_posix.cpp line 646:

> 644:   // MacOS X needs to use RTLD_FIRST instead of RTLD_LAZY
> 645:   // to avoid finding unexpected symbols on second (or later)
> 646:   // loads of a library.

I find this a puzzling comment. RTLD_FIRST is not used instead of RTLD_LAZY it is used with it. RTLD_FIRST simply limits how dlsym will perform a search using the handle that dlopen returns. Second it is trying to protect against something that will happen on other Posix systems anyway, so can't really be a bug. So I have to question whether we really need to special case this code for macOS?

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5737

From dholmes at openjdk.java.net  Wed Sep 29 04:37:35 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 29 Sep 2021 04:37:35 GMT
Subject: RFR: 8274282: Clarify special wait assert [v2]
In-Reply-To: <NYVtWiSaVEKNn6NbgSLKsM1dONaIZW44aEwXgc3LHY4=.9f7d145e-aa06-4cc6-b2b7-19b257aa321f@github.com>
References: <WqwNwtyXz47rp5KUISxGDdipwpVnyhSiGgO1e3CSnx8=.f542830a-3598-4249-b418-d79aa9f09f44@github.com>
 <NYVtWiSaVEKNn6NbgSLKsM1dONaIZW44aEwXgc3LHY4=.9f7d145e-aa06-4cc6-b2b7-19b257aa321f@github.com>
Message-ID: <w9CPOjhoDpenY8jI4YxhfdFU6Y8qu97jkYCt4VRga6w=.d0cb8bf9-32bd-4b09-9e3d-d9374e223ba9@github.com>

On Fri, 24 Sep 2021 16:59:18 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This change removes the assert and tests for Mutex::wait() only allowed with greater than nosafepoint ranked held locks.
>> Tested with tier1-3.
>
> Coleen Phillimore 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:
> 
>   Fix wait checking code.

Hi Coleen,

The rationale is not quite right to me here. See comments below.

Thanks,
David

src/hotspot/share/runtime/mutex.cpp line 388:

> 386:     Mutex* least = get_least_ranked_lock_besides_this(locks_owned);
> 387:     // We enforce not holding locks of rank nosafepoint or lower while waiting for JavaThreads,
> 388:     // because the held lock has a NoSafepointVerifier so waiting on a lock will block out safepoints.

The NSV is not the reason, it is  a mechanism to detect violation of the rules. The reason we must not block in a JavaThread is because it will block without a safepoint check and without becoming safepoint-safe, thus blocking out safepoints while the wait is in progress.

Also note that this applies to any wait() on a nosafepoint lock, not just one done while holding a safepoint lock.

src/hotspot/share/runtime/mutex.cpp line 389:

> 387:     // We enforce not holding locks of rank nosafepoint or lower while waiting for JavaThreads,
> 388:     // because the held lock has a NoSafepointVerifier so waiting on a lock will block out safepoints.
> 389:     // For NonJavaThreads, we enforce not waiting on the tty lock since that could block progress also.

You are checking this for all threads not just NJTs. Is the comment wrong or the code?

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

PR: https://git.openjdk.java.net/jdk/pull/5684

From minqi at openjdk.java.net  Wed Sep 29 04:38:34 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 29 Sep 2021 04:38:34 GMT
Subject: RFR: 8273152: Store base archive path in CDSFileMapHeaderBase [v3]
In-Reply-To: <XPWq6OliO3UMR3y_zlQ8IbY-k6Y7oWZWq6RzVGPtPdI=.d3c11276-4bdf-42e6-84b8-e6f20d02a688@github.com>
References: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
 <XPWq6OliO3UMR3y_zlQ8IbY-k6Y7oWZWq6RzVGPtPdI=.d3c11276-4bdf-42e6-84b8-e6f20d02a688@github.com>
Message-ID: <PtINbD7cjUUG7SVCW3cJVBiOglD-UXVUszdvffbOPkk=.6b68c426-d1c6-4891-8f85-10ea371e0942@github.com>

On Thu, 23 Sep 2021 16:29:22 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Store base archive path offset in CDSFileMapHeaderBase (which should be invariant in evolving versions) so we can read the base archive name reliably from dynamic archive even with variant header sizes over versions.
>> 
>> tests: tier1-4
>> 
>> Thanks
>> Yumin
>
> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved _base_archive_name_size to CDSFileMapHeaderBase and made checking consistency in function check_archive

The patch will be undergo more modification to the header file. A new patch will include the new design and this is closed without further work.

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

PR: https://git.openjdk.java.net/jdk/pull/5584

From minqi at openjdk.java.net  Wed Sep 29 04:38:35 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Wed, 29 Sep 2021 04:38:35 GMT
Subject: Withdrawn: 8273152: Store base archive path in CDSFileMapHeaderBase
In-Reply-To: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
References: <A07qRUaluJ-H14gHuFzNvjcczb4ANn9BoHuAc1AhOYM=.78a20921-b22d-4cb9-a9da-c07a95cf8add@github.com>
Message-ID: <p1FgY8x1N-bbGbwmOt1_XJcgmYr2jjWEt1H-NjZsSqo=.c9fe80de-348f-4ec8-9679-7e8da476688b@github.com>

On Mon, 20 Sep 2021 15:58:54 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Store base archive path offset in CDSFileMapHeaderBase (which should be invariant in evolving versions) so we can read the base archive name reliably from dynamic archive even with variant header sizes over versions.
> 
> tests: tier1-4
> 
> Thanks
> Yumin

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/5584

From dholmes at openjdk.java.net  Wed Sep 29 06:14:37 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 29 Sep 2021 06:14:37 GMT
Subject: RFR: JDK-8274320: os::fork_and_exec() should be using posix_spawn
In-Reply-To: <5hepN-Ub74DMHnpbM_TdPaHmI1zEQddSobpy6AIlT98=.11c35eb4-02c2-4bcc-8153-d07b282f3da3@github.com>
References: <5hepN-Ub74DMHnpbM_TdPaHmI1zEQddSobpy6AIlT98=.11c35eb4-02c2-4bcc-8153-d07b282f3da3@github.com>
Message-ID: <2oeJU-Vvp6c5itsSq0AhrOBDIFONQqQdLdiCyg9ny4M=.6129e715-11e1-48d1-9b5a-4419cfe17924@github.com>

On Sat, 25 Sep 2021 16:16:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Hi, may I have reviews for this small patch please?
> 
> `os::fork_and_exec()`, used in the hotspot to spawn child programs (scripts etc) in error situations, should be using `posix_spawn()`. 
> 
> ATM it uses either `fork()` or `vfork()`. `vfork()` got deprecated on MacOS and we get build errors (JDK-8274293) - even though in this case it would be completely fine to use. This leaves us with `fork()` for MacOS, which has the known problems with large-footprint-parents. This matters here especially since we also use os::fork_and_exec to implement `-XX:OnError` for OOM situations.
> 
> We already use posix_spawn() as default for Runtime.exec() since JDK 15, and it is available on all our Unices. We also should use it here.
> 
> I kept the name of the function (fork_and_exec) since people know it, even though it's more incorrect now than before.
> 
> Tests:
> - manual tests using -XX:OnError with various scripts, including checking that env variables are passed correctly
> - manually ran runtime/ErrorHandling tests
> - GHAs

Hi Thomas,

There is a crucial difference between the requirements of os::fork_and_exec versus the Java Runtime.exec call - in the VM we need to use an async-signal-safe function where possible. fork() is async-signal-safe but posix_spawn is not.

Cheers,
David

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

PR: https://git.openjdk.java.net/jdk/pull/5698

From mbaesken at openjdk.java.net  Wed Sep 29 07:20:31 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 29 Sep 2021 07:20:31 GMT
Subject: RFR: JDK-8274434: move os::get_default_process_handle and
 os::dll_lookup to os_posix for POSIX platforms
In-Reply-To: <TkOquoj7MK6zK74_XhDtk7Nl-pzhQbKw9enZYJKsIz0=.ce5c0f80-d371-4e45-afaf-7d70a0cc54f2@github.com>
References: <4Dt5972d0-anhV1jfU2BCrcaaANGedVnxNkrFjPz34M=.55c5f633-a698-4c33-898c-bacb1127075e@github.com>
 <TkOquoj7MK6zK74_XhDtk7Nl-pzhQbKw9enZYJKsIz0=.ce5c0f80-d371-4e45-afaf-7d70a0cc54f2@github.com>
Message-ID: <f3UVNx-gIDhZadW13nPK4dkxty97yjO2WD0WQZhTEOY=.98ec2937-af90-4200-8dc2-28eee75e384c@github.com>

On Wed, 29 Sep 2021 03:58:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hello, please review this small change.
>> The os::get_default_process_handle and os::dll_lookup functions are pretty similar across the POSIX platforms so they can be moved to os_posix.cpp.
>
> src/hotspot/os/posix/os_posix.cpp line 646:
> 
>> 644:   // MacOS X needs to use RTLD_FIRST instead of RTLD_LAZY
>> 645:   // to avoid finding unexpected symbols on second (or later)
>> 646:   // loads of a library.
> 
> I find this a puzzling comment. RTLD_FIRST is not used instead of RTLD_LAZY it is used with it. RTLD_FIRST simply limits how dlsym will perform a search using the handle that dlopen returns. Second it is trying to protect against something that will happen on other Posix systems anyway, so can't really be a bug. So I have to question whether we really need to special case this code for macOS?

hi David, thanks for your comment and questions. Maybe some Mac expert could comment why the special handling was needed ? Indeed it would be good to remove the special handling and have the same code on all Posix platforms.

Best regards, Matthias

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

PR: https://git.openjdk.java.net/jdk/pull/5737

From rehn at openjdk.java.net  Wed Sep 29 08:02:00 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 29 Sep 2021 08:02:00 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v4]
In-Reply-To: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
Message-ID: <DIf3GZ53F16v695F3jaQa2wGULmN46FiCVYr1Aapi60=.7f7bf573-7ea4-4afe-a5f3-f91c3b6b4896@github.com>

> We should not do any processing in SM::should_process().
> The query is used to determine if we need to process safepoint/handshakes and with this change StackWaterMark.
> When locking a Mutex which may be acquired in such processing, we must release that Mutex before we can start processing, otherwise we can deadlock.
> 
> This change adds a method to determine if StackWaterMarkSet::on_safepoint() will do any processing.
> In that case there are poll is armed, we do not allow suspend handshakes and there is no safepoint and no non-suspend handshakes, we still return true if StackWaterMarkSet needs processing.
> Thus the code querying should release any such Mutex and call process SM::process_if_requested().
> 
> The cross_modify_fence() do not have any such state, so we still need to emit that before returning false if poll is armed.
> 
> Passes t1-t4 and local stressing.

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 seven additional commits since the last revision:

 - Fixed comment
 - Merge branch 'master' into 8273695-swm-should-proc
 - Fixed spelling
 - Merge branch 'master' into 8273695-swm-should-proc
 - Added update poll values and fixed PR comments
 - Removed string dedup test from problem list
 - Check SWS for processing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5613/files
  - new: https://git.openjdk.java.net/jdk/pull/5613/files/e5b52cda..72b98111

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5613&range=02-03

  Stats: 16153 lines in 342 files changed: 12065 ins; 1711 del; 2377 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5613/head:pull/5613

PR: https://git.openjdk.java.net/jdk/pull/5613

From rehn at openjdk.java.net  Wed Sep 29 08:02:02 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Wed, 29 Sep 2021 08:02:02 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v3]
In-Reply-To: <oqtNONvgFRPpXdoNrINpfIuOL4Jgn_wrfvjoqNSX_EM=.f3c0da7b-a780-4394-adff-78676dec573a@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <lkk5J-wwMoMbp8VW-XBf2GzdbCEs2zLy27QB0mwMpZs=.c4b06014-3751-4a4d-95fb-39dc4e2af024@github.com>
 <oqtNONvgFRPpXdoNrINpfIuOL4Jgn_wrfvjoqNSX_EM=.f3c0da7b-a780-4394-adff-78676dec573a@github.com>
Message-ID: <WDO8mGd6ugmzh_i2WluWrwlUyDE6M01gdCgnGi1lTCo=.095a7568-084e-467c-8afd-c683e1fcaaca@github.com>

On Fri, 24 Sep 2021 18:33:03 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> LGTM!

Thank you @pchilano !

> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 90:
> 
>> 88:   // 3: The JavaThread wakes-up from blocked and does not allow suspend.
>> 89:   // We are now about to avoid processing and thus no cross modify fence will be executed.
>> 90:   // Therefore we execute it here.
> 
> I would just say we still need to execute this fence in case a safepoint happened while being blocked, and not mention step 1 since as commented above there might be nothing to process.

Updated, better?

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From sgehwolf at openjdk.java.net  Wed Sep 29 10:09:11 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 29 Sep 2021 10:09:11 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman [v2]
In-Reply-To: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
Message-ID: <k1uSuRb2o_3rCfv1hrDrGyvCabzd9AiCGhtr7moHSaw=.6c0615e4-2a16-4ed5-a67e-d2d597b5b85c@github.com>

> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Check for podman version >= 3.3.1

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5740/files
  - new: https://git.openjdk.java.net/jdk/pull/5740/files/7e1ebd85..c8c9c83f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5740&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5740&range=00-01

  Stats: 80 lines in 1 file changed: 80 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5740.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5740/head:pull/5740

PR: https://git.openjdk.java.net/jdk/pull/5740

From sgehwolf at openjdk.java.net  Wed Sep 29 10:09:12 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 29 Sep 2021 10:09:12 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman
In-Reply-To: <gkeEFgmQsVP5SxrsV_ZwTVwhQZ8O-Xc_fLLhGf8Zp6g=.0ab73570-4f9c-4bd7-b857-658d667a3d4d@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
 <gkeEFgmQsVP5SxrsV_ZwTVwhQZ8O-Xc_fLLhGf8Zp6g=.0ab73570-4f9c-4bd7-b857-658d667a3d4d@github.com>
Message-ID: <ZdoZGpbjnWxnc_XOQdzmptd1aEX_n4ReEEJj5aWvDa0=.b2544715-4fbb-465c-96a3-7ffc69551d10@github.com>

On Tue, 28 Sep 2021 21:35:30 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
>> 
>> Thoughts?
>
> Also, I checked a Podman version on our test systems: it is earlier/below 3.3.1. Perhaps the conditional guard in the test should check for that as well, and if version is below 3.3.1, we should check if user is root, and throw SkippedException if not?

@mseledts Thanks for the review and tests. I've now added a version check for podman. I've run this with 3.3.1 and it works fine in rootless mode. It should start to work for you once you upgrade. Thoughts?

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

PR: https://git.openjdk.java.net/jdk/pull/5740

From sgehwolf at openjdk.java.net  Wed Sep 29 12:58:44 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 29 Sep 2021 12:58:44 GMT
Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with podman
 run as root
Message-ID: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>

Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts?

Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch.

[1] https://github.com/containers/podman/issues/11782

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

Commit messages:
 - 8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

Changes: https://git.openjdk.java.net/jdk/pull/5750/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5750&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8274506
  Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5750.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5750/head:pull/5750

PR: https://git.openjdk.java.net/jdk/pull/5750

From mbaesken at openjdk.java.net  Wed Sep 29 13:02:39 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 29 Sep 2021 13:02:39 GMT
Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with
 podman run as root
In-Reply-To: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
References: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
Message-ID: <MYzz8CVZ2Kl5k_yIg3uW4NdYzG8jedE5OedJ9V_yYmw=.443bf0fd-c816-478b-88d4-a814f7e62d93@github.com>

On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts?
> 
> Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch.
> 
> [1] https://github.com/containers/podman/issues/11782

Hello Severin, the test fix looks good to me.

Best regards, Matthias

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

Marked as reviewed by mbaesken (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5750

From sgehwolf at openjdk.java.net  Wed Sep 29 16:59:38 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 29 Sep 2021 16:59:38 GMT
Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with
 podman run as root
In-Reply-To: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
References: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
Message-ID: <Ff9L8PjgBB77MxnH2UqCY_YSz1eUXKcMlkunIS9gUWg=.028b0327-fcf6-4442-ab16-00c1b9f89c1e@github.com>

On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts?
> 
> Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch.
> 
> [1] https://github.com/containers/podman/issues/11782

Thanks for the review!

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

PR: https://git.openjdk.java.net/jdk/pull/5750

From pchilanomate at openjdk.java.net  Wed Sep 29 17:19:36 2021
From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo)
Date: Wed, 29 Sep 2021 17:19:36 GMT
Subject: RFR: 8273695: Safepoint deadlock on VMOperation_lock [v3]
In-Reply-To: <WDO8mGd6ugmzh_i2WluWrwlUyDE6M01gdCgnGi1lTCo=.095a7568-084e-467c-8afd-c683e1fcaaca@github.com>
References: <QrNe54I2LCOpY7Jmzy9eCSHqIr9dCG78yx7Rp14ABus=.08373535-012f-494c-9976-97a702eb6fab@github.com>
 <lkk5J-wwMoMbp8VW-XBf2GzdbCEs2zLy27QB0mwMpZs=.c4b06014-3751-4a4d-95fb-39dc4e2af024@github.com>
 <oqtNONvgFRPpXdoNrINpfIuOL4Jgn_wrfvjoqNSX_EM=.f3c0da7b-a780-4394-adff-78676dec573a@github.com>
 <WDO8mGd6ugmzh_i2WluWrwlUyDE6M01gdCgnGi1lTCo=.095a7568-084e-467c-8afd-c683e1fcaaca@github.com>
Message-ID: <bK21yV5zZPmEKkkaXjC2V73ExRXd3wh4LUGemRtJF3M=.9726b9b6-8393-4910-a36b-9031cf597da5@github.com>

On Wed, 29 Sep 2021 07:56:35 GMT, Robbin Ehn <rehn at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepointMechanism.inline.hpp line 90:
>> 
>>> 88:   // 3: The JavaThread wakes-up from blocked and does not allow suspend.
>>> 89:   // We are now about to avoid processing and thus no cross modify fence will be executed.
>>> 90:   // Therefore we execute it here.
>> 
>> I would just say we still need to execute this fence in case a safepoint happened while being blocked, and not mention step 1 since as commented above there might be nothing to process.
>
> Updated, better?

Looks good, thanks for the update!

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

PR: https://git.openjdk.java.net/jdk/pull/5613

From cjplummer at openjdk.java.net  Wed Sep 29 18:43:34 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 29 Sep 2021 18:43:34 GMT
Subject: RFR: 8274506: TestPids.java and TestPidsLimit.java fail with
 podman run as root
In-Reply-To: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
References: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
Message-ID: <VmwwAGRJW4enHoDfHCdr0DMihtHzbUzNieCTluwN_tE=.a647f5bc-6b61-4849-83aa-d7f995f807a4@github.com>

On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts?
> 
> Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch.
> 
> [1] https://github.com/containers/podman/issues/11782

Marked as reviewed by cjplummer (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/5750

From mseledtsov at openjdk.java.net  Wed Sep 29 18:54:32 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Wed, 29 Sep 2021 18:54:32 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman [v2]
In-Reply-To: <k1uSuRb2o_3rCfv1hrDrGyvCabzd9AiCGhtr7moHSaw=.6c0615e4-2a16-4ed5-a67e-d2d597b5b85c@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
 <k1uSuRb2o_3rCfv1hrDrGyvCabzd9AiCGhtr7moHSaw=.6c0615e4-2a16-4ed5-a67e-d2d597b5b85c@github.com>
Message-ID: <BNwj2z7X1Nfro0rkm-ITFMiGIP2H0AZD8VM1W-FoLXo=.9e894f96-c703-4d98-8cce-50075537b50e@github.com>

On Wed, 29 Sep 2021 10:09:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for podman version >= 3.3.1

Changes look good to me. This version now passes Oracle container testing, thank you.

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

Marked as reviewed by mseledtsov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/5740

From kvn at openjdk.java.net  Wed Sep 29 19:27:46 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 29 Sep 2021 19:27:46 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
Message-ID: <1TNrE6nHtA1soZLht5HwXl4Hwo23Kf7y6WBZT8x2mMM=.b1e126e1-c1ea-4515-a187-c9ec066ac6c4@github.com>

On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
> 
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error C2220: the following warning is treated as an error
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4778: 'sscanf' : unterminated format string '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note: placeholders and their parameters expect 1 variadic arguments, but 3 were provided
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4778: 'sscanf' : unterminated format string '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note: placeholders and their parameters expect 0 variadic arguments, but 2 were provided
> 
> 
> The failure is caused by non-ASCII chars in the format string of sscanf [1][2], which is non-portable on our Windows platform.
> In fact, these non-ASCII coding also triggers C4819 warning, which had been disabled in JDK-8216154 [3].
> And I also found an article showing that sscanf may fail with non-ASCII in the format string [4].
> 
> So it would be nice to remove these non-ASCII chars  (`\x80 ~ \xef`).
> And I think it's safe to do so.
> 
> This is because:
>  1) There are actually no non-ASCII chars for package/class/method/signature names.
>  2) I don't think there is a use case, in which people will input non-ASCII for `CompileCommand`.
> 
> You may argue that the non-ASCII may be used by the parser itself.
> But I didn't find that usage at all. (Please let me know if I miss something.)
> 
> So I suggest to remove these non-ASCII code to make HotSpot to be more portable.
> And if we do so, we can also remove the only one `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
> 
> Testing:
>  - Build tests on Windows
>  - tier1~3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246

This should be discussed with `build` group and may be `runtime` to get more comments.

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From kvn at openjdk.java.net  Wed Sep 29 19:43:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 29 Sep 2021 19:43:36 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
Message-ID: <zh9t2ydmuJXc76I31RdhorR9bbb-z6rUwWHWVhygKP4=.87485abe-5b8d-48b5-b520-fdd24af5a3ae@github.com>

On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
> 
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error C2220: the following warning is treated as an error
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4778: 'sscanf' : unterminated format string '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note: placeholders and their parameters expect 1 variadic arguments, but 3 were provided
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4778: 'sscanf' : unterminated format string '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note: placeholders and their parameters expect 0 variadic arguments, but 2 were provided
> 
> 
> The failure is caused by non-ASCII chars in the format string of sscanf [1][2], which is non-portable on our Windows platform.
> In fact, these non-ASCII coding also triggers C4819 warning, which had been disabled in JDK-8216154 [3].
> And I also found an article showing that sscanf may fail with non-ASCII in the format string [4].
> 
> So it would be nice to remove these non-ASCII chars  (`\x80 ~ \xef`).
> And I think it's safe to do so.
> 
> This is because:
>  1) There are actually no non-ASCII chars for package/class/method/signature names.
>  2) I don't think there is a use case, in which people will input non-ASCII for `CompileCommand`.
> 
> You may argue that the non-ASCII may be used by the parser itself.
> But I didn't find that usage at all. (Please let me know if I miss something.)
> 
> So I suggest to remove these non-ASCII code to make HotSpot to be more portable.
> And if we do so, we can also remove the only one `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
> 
> Testing:
>  - Build tests on Windows
>  - tier1~3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246

`RANGEBASE` was added by [JDK-6500501](https://bugs.openjdk.java.net/browse/JDK-6500501) and later was modified by [JDK-8027829](https://bugs.openjdk.java.net/browse/JDK-8027829)

Note the original comment from 6500501:

// The characters allowed in a class or method name.  All characters > 0x7f
// are allowed in order to handle obfuscated class files (e.g. Volano)

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From cjplummer at openjdk.java.net  Thu Sep 30 00:02:20 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 30 Sep 2021 00:02:20 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v5]
In-Reply-To: <PjHQ5jEMjq5QCzFvgjE45WKYbHKB7hu3zWHvm2JEC3Y=.149fffa0-621c-47f6-964d-9e6fe2ed80f3@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
 <pOEgxUbRqzQlolht9dm2eIpGlCiGU86ZIyVMybWDbjc=.3c581af6-8fe3-41cc-9b12-3353661ed3f3@github.com>
 <PjHQ5jEMjq5QCzFvgjE45WKYbHKB7hu3zWHvm2JEC3Y=.149fffa0-621c-47f6-964d-9e6fe2ed80f3@github.com>
Message-ID: <Ot4_dw0lXWHapuRKx3VW509I1wc116ZZE_BBFeJ6_iI=.b1d6bf77-cccc-4ab9-bd01-713432edd4ce@github.com>

On Tue, 28 Sep 2021 22:33:32 GMT, Lin Zang <lzang at openjdk.org> wrote:

> Dear Chris(@plummercj) and Ralf(@schmelter-sap), may I ask your help to review this fix of JDK-8252842? Thanks!

Yes, I will have a look at it.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From cjplummer at openjdk.java.net  Thu Sep 30 04:06:27 2021
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Thu, 30 Sep 2021 04:06:27 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v5]
In-Reply-To: <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
Message-ID: <RokSVH9LlLOtk0EMLK1A1gynL2dfRVA-9xU-oLTQYP4=.2c212b6b-c8a1-42df-b7a0-7cbbd9a6713e@github.com>

On Mon, 27 Sep 2021 14:28:43 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
>> 
>> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
>> 
>> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove load barrier for JNI local roots

The dumper threads related fix looks fine. I don't know enough to verify the GC fix, but I think Per has that covered sufficiently. Likewise for the lock rank issue which Coleen has reviewed. Also, I tested your changes with our tier2 and tier3 CI runs, which is where the failures initially turned up, and they are passing now.

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

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5681

From jiefu at openjdk.java.net  Thu Sep 30 08:34:34 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 08:34:34 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <zh9t2ydmuJXc76I31RdhorR9bbb-z6rUwWHWVhygKP4=.87485abe-5b8d-48b5-b520-fdd24af5a3ae@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
 <zh9t2ydmuJXc76I31RdhorR9bbb-z6rUwWHWVhygKP4=.87485abe-5b8d-48b5-b520-fdd24af5a3ae@github.com>
Message-ID: <u9jRW-d_Rih1-sfTanKnBkfRMJLacCve_zvoSWGJLy8=.e15eefe5-5f5a-43a9-b7f9-f8e96d1bc313@github.com>

On Wed, 29 Sep 2021 19:40:20 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `RANGEBASE` was added by [JDK-6500501](https://bugs.openjdk.java.net/browse/JDK-6500501) and later was modified by [JDK-8027829](https://bugs.openjdk.java.net/browse/JDK-8027829)
> 
> Note the original comment from 6500501:
> 
> ```
> // The characters allowed in a class or method name.  All characters > 0x7f
> // are allowed in order to handle obfuscated class files (e.g. Volano)
> ```

Thanks @vnkozlov for your very helpful comments.

I have one question: how can we specify (non-ascii chars) and (non-printable ascii chars) through `-XX:CompileCommand`?


I just learned from https://bugs.openjdk.java.net/browse/JDK-8027829 that we can use unicode like `\uxxxx`.
But it doesn't work in my experiments.

My example was made from: https://bugs.openjdk.java.net/secure/attachment/17128/UnicodeIdentifierTest.java

public class UnicodeIdentifierTest {
    public static void main(String args[]) {
        System.out.println("Can I use \\u0001 in identifier name? " +
                           (Character.isJavaIdentifierPart(1) ? "yes" : "no"));
        for (int i = 0; i < 100000; i++ )
        methodWithUnicode\u0001Char();

        System.out.println("Can I use \\u00aa in identifier name? " +
                           (Character.isJavaIdentifierPart(0xaa) ? "yes" : "no"));
        for (int i = 0; i < 100000; i++ )
        methodWithUnicode\u00aaChar();

        System.out.println("Can I use \\u006b in identifier name? " +
                           (Character.isJavaIdentifierPart(0x6b) ? "yes" : "no"));
        for (int i = 0; i < 100000; i++ )
        methodWithUnicode\u006bChar();

    }
    public static int a = 0;
    public static void methodWithUnicode\u0001Char() {
        a++;
    }

    public static void methodWithUnicode\u00aaChar() {
        a++;
    }

    public static void methodWithUnicode\u006bChar() {
        a++;
    }
}


And I tried to exclude some specific methods like this

${JDK}/bin/java \
   -XX:+PrintCompilation \
   -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest::methodWithUnicode\u0001Char"` \
   -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest.methodWithUnicode\u0001Char"` \
   -XX:CompileCommand=exclude,"UnicodeIdentifierTest.methodWithUnicode\u0001Char" \
   -XX:CompileCommand=exclude,'UnicodeIdentifierTest.methodWithUnicode\u0001Char' \
   -XX:CompileCommand=exclude,UnicodeIdentifierTest.methodWithUnicode\u0001Char \
   -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest::methodWithUnicode\u00aaChar"` \
   -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest.methodWithUnicode\u00aaChar"` \
   -XX:CompileCommand=exclude,"UnicodeIdentifierTest.methodWithUnicode\u00aaChar" \
   -XX:CompileCommand=exclude,'UnicodeIdentifierTest.methodWithUnicode\u00aaChar' \
   -XX:CompileCommand=exclude,UnicodeIdentifierTest.methodWithUnicode\u00aaChar \
   -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest::methodWithUnicode\u006bChar"` \
   -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest.methodWithUnicode\u006bChar"` \
   -XX:CompileCommand=exclude,"UnicodeIdentifierTest.methodWithUnicode\u006bChar" \
   -XX:CompileCommand=exclude,'UnicodeIdentifierTest.methodWithUnicode\u006bChar' \
   -XX:CompileCommand=exclude,UnicodeIdentifierTest.methodWithUnicode\u006bChar \
   ${TEST}


But none of them worked.

So if there is no other way to specify a non-ascii chars, it seems safe to remove the non-ascii code.

If I miss something, please let me know.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From sgehwolf at openjdk.java.net  Thu Sep 30 08:49:34 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 30 Sep 2021 08:49:34 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman
In-Reply-To: <gkeEFgmQsVP5SxrsV_ZwTVwhQZ8O-Xc_fLLhGf8Zp6g=.0ab73570-4f9c-4bd7-b857-658d667a3d4d@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
 <gkeEFgmQsVP5SxrsV_ZwTVwhQZ8O-Xc_fLLhGf8Zp6g=.0ab73570-4f9c-4bd7-b857-658d667a3d4d@github.com>
Message-ID: <sYuLifRovymHAfyRd1cDp7HWHa26Sgbg-oUEBNtE7Ws=.6c006184-1df3-4406-84c8-ef6f8724cca4@github.com>

On Tue, 28 Sep 2021 21:35:30 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
>> 
>> Thoughts?
>
> Also, I checked a Podman version on our test systems: it is earlier/below 3.3.1. Perhaps the conditional guard in the test should check for that as well, and if version is below 3.3.1, we should check if user is root, and throw SkippedException if not?

Thanks for the review, @mseledts. Any (R)eviewers please?

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

PR: https://git.openjdk.java.net/jdk/pull/5740

From sgehwolf at openjdk.java.net  Thu Sep 30 08:56:41 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 30 Sep 2021 08:56:41 GMT
Subject: Integrated: 8274506: TestPids.java and TestPidsLimit.java fail with
 podman run as root
In-Reply-To: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
References: <VN6hDMAzzGgjEP-qhZ0g8aWXBUsJP4_28FkeKJKu7o4=.8c5d8b50-de95-4173-982e-8e743ffcecd6@github.com>
Message-ID: <kPXV8eRDiQ-t9A_fk6XlwXf_Dz-QiLdDGi0gNK3A2lo=.c612dd45-9df0-4c3b-9131-f30b78f61f53@github.com>

On Wed, 29 Sep 2021 12:51:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test fix to work around a podman issue[1]. `podman` expects for the "unlimited" option of `--pids-limit` to be `0` whereas `docker` wants `-1`. See the JBS bug for details. Thoughts?
> 
> Testing: hotspot/jdk container tests with docker and podman. Two pids tests used to fail and pass with the patch.
> 
> [1] https://github.com/containers/podman/issues/11782

This pull request has now been integrated.

Changeset: 94e31e5c
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/94e31e5ca51d1c4c253cf7ac5acd950d10c22267
Stats:     12 lines in 2 files changed: 10 ins; 0 del; 2 mod

8274506: TestPids.java and TestPidsLimit.java fail with podman run as root

Reviewed-by: mbaesken, cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/5750

From ihse at openjdk.java.net  Thu Sep 30 10:04:35 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 30 Sep 2021 10:04:35 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
Message-ID: <O545b5bDuIf4PcTATISSgC3EPbL_2qozRtksTKw5EM8=.c1568a4a-fb8f-4462-bd1a-564d2a5ed381@github.com>

On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
> 
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error C2220: the following warning is treated as an error
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4778: 'sscanf' : unterminated format string '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note: placeholders and their parameters expect 1 variadic arguments, but 3 were provided
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4778: 'sscanf' : unterminated format string '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note: placeholders and their parameters expect 0 variadic arguments, but 2 were provided
> 
> 
> The failure is caused by non-ASCII chars in the format string of sscanf [1][2], which is non-portable on our Windows platform.
> In fact, these non-ASCII coding also triggers C4819 warning, which had been disabled in JDK-8216154 [3].
> And I also found an article showing that sscanf may fail with non-ASCII in the format string [4].
> 
> So it would be nice to remove these non-ASCII chars  (`\x80 ~ \xef`).
> And I think it's safe to do so.
> 
> This is because:
>  1) There are actually no non-ASCII chars for package/class/method/signature names.
>  2) I don't think there is a use case, in which people will input non-ASCII for `CompileCommand`.
> 
> You may argue that the non-ASCII may be used by the parser itself.
> But I didn't find that usage at all. (Please let me know if I miss something.)
> 
> So I suggest to remove these non-ASCII code to make HotSpot to be more portable.
> And if we do so, we can also remove the only one `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
> 
> Testing:
>  - Build tests on Windows
>  - tier1~3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246

Some misc remarks from a build PoV:
 * We count language and region settings as a build environment requirement, not a portability issue. 
 * It is really a shame that Microsoft is making changes to these so darned hard. On all other platforms, LC_ALL=C in the make file just fixes the problem. :-(
 * But we do want the JDK to be easy to build, so this means that we might need to support building on more than en_US on Windows, at least until Microsoft get's their act together.

>From what I see in the discussion here there seems to be no clarity in what range of character the specification allows. This needs to be absolutely clear for any changes here -- we can't filter out legal characters just because they are problematic to build on non en_US platforms.

However, I'm thinking that you need to take a step back and see what you are really trying to solve. To me, it seems that sscanf is not the right tool for the job, and the fact that it has worked until now is more a lucky coincidence. It seems, from a quick glance, that you should consider the input a byte array, and process it like that, instead of a string, if the encoding is unclear, and the spec is talking about character values (like 0x7f) rather than what characters they are supposed to represent in a specific encoding.

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From jiefu at openjdk.java.net  Thu Sep 30 10:36:39 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 10:36:39 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <O545b5bDuIf4PcTATISSgC3EPbL_2qozRtksTKw5EM8=.c1568a4a-fb8f-4462-bd1a-564d2a5ed381@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
 <O545b5bDuIf4PcTATISSgC3EPbL_2qozRtksTKw5EM8=.c1568a4a-fb8f-4462-bd1a-564d2a5ed381@github.com>
Message-ID: <6q7r8NP3eoLCV6e0bgbIjHODdfG9q6wNfpqECZZGZeM=.8675d1bb-f627-41b8-97a9-eb1ea721a50b@github.com>

On Thu, 30 Sep 2021 10:01:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some misc remarks from a build PoV:
> 
> * We count language and region settings as a build environment requirement, not a portability issue.
> * It is really a shame that Microsoft is making changes to these so darned hard. On all other platforms, LC_ALL=C in the make file just fixes the problem. :-(
> * But we do want the JDK to be easy to build, so this means that we might need to support building on more than en_US on Windows, at least until Microsoft get's their act together.
> 
> From what I see in the discussion here there seems to be no clarity in what range of character the specification allows. This needs to be absolutely clear for any changes here -- we can't filter out legal characters just because they are problematic to build on non en_US platforms.
> 
> However, I'm thinking that you need to take a step back and see what you are really trying to solve. To me, it seems that sscanf is not the right tool for the job, and the fact that it has worked until now is more a lucky coincidence. It seems, from a quick glance, that you should consider the input a byte array, and process it like that, instead of a string, if the encoding is unclear, and the spec is talking about character values (like 0x7f) rather than what characters they are supposed to represent in a specific encoding.

Thanks @magicus .

The background is that we want to build CI/CD pipelines for Windows platforms to help the OpenJDK development.

We already have enough Linux and MacOS pipelines but still not have one for Windows.
So we just plan to setup some Windows pipelines to further improve OpenJDK product quality.

But to my surprise, OpenJDK fails to build on our Windows platforms.

You may suggest changing the locale settings.
But many of our Apps don't allow us to changet it since we are non-English speaking country.
It's unfortunate that OpenJDK can't build on our Windows platforms.

It's not our goal to make CompileCommand work with non-ASCII chars.
If it doesn't make anything worse, we can just remove the non-ASCII code to make it to be more portable.

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From rehn at openjdk.java.net  Thu Sep 30 12:16:34 2021
From: rehn at openjdk.java.net (Robbin Ehn)
Date: Thu, 30 Sep 2021 12:16:34 GMT
Subject: RFR: 8274379: Allow process of unsafe access errors in
 check_special_condition_for_native_trans
In-Reply-To: <uiJntp85SAthbMdpFuvtCdx4bR8Zwr5X_gA2RTxOe4g=.0f1aa158-8f1b-4318-8e3a-e8ff727e99f2@github.com>
References: <uiJntp85SAthbMdpFuvtCdx4bR8Zwr5X_gA2RTxOe4g=.0f1aa158-8f1b-4318-8e3a-e8ff727e99f2@github.com>
Message-ID: <RLGIqKD0_Tow7TZi2bJQRS98qJLiCrW80z2-yl4Hr2Q=.cd6da1cf-dc34-4fd5-b313-b0725ca7ce4e@github.com>

On Tue, 28 Sep 2021 17:23:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> Hi,
> 
> 
> Please review the following patch to allow processing of unsafe access errors in check_special_condition_for_native_trans().
> 
> Today we special case unsafe access errors from other async exceptions in that we don't process them when transitioning from native back to Java. Code comments in check_special_condition_for_native_trans() mention that unsafe access errors should not be handled because that may block while creating the exception. But that should not be an issue since we can always make sure we call process_if_requested_with_exit_check() after the call to throw_unsafe_access_internal_error() to process any pending operations not already handled in a ThreadBlockInVM wrapper (today that only means suspend requests and object reallocation operations).
> 
> By removing this special treatment for unsafe access errors we can also simplify the async exception support API. For instance we can remove _async_exception_condition and simplify some of the supporting methods. I also removed the _thread_in_native case from the switch statement in check_and_handle_async_exceptions() since we never call that method in that state.
> 
> Testing by running tiers1-6 in mach5. 
> 
> Thanks,
> Patricio

Marked as reviewed by rehn (Reviewer).

Hi @pchilano,

Yes this seem like an improvement, so process_if_requested_with_exit_check is the only place were we handle async exceptions. (except JNI)
It looks good, but I have I really hard time looking at the diff/code to determine if this behaves differently in any bad ways.
I trust you have done the testing needed to be sure.

Thanks, Robbin

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

PR: https://git.openjdk.java.net/jdk/pull/5741

From hseigel at openjdk.java.net  Thu Sep 30 12:26:33 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 30 Sep 2021 12:26:33 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman [v2]
In-Reply-To: <k1uSuRb2o_3rCfv1hrDrGyvCabzd9AiCGhtr7moHSaw=.6c0615e4-2a16-4ed5-a67e-d2d597b5b85c@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
 <k1uSuRb2o_3rCfv1hrDrGyvCabzd9AiCGhtr7moHSaw=.6c0615e4-2a16-4ed5-a67e-d2d597b5b85c@github.com>
Message-ID: <NdiUc5eTmJEMkppp8ofu9Sh9cCs_Pj3I_UPVy8GwQXg=.451fe156-b582-4acf-ada8-f5ecf48d3677@github.com>

On Wed, 29 Sep 2021 10:09:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for podman version >= 3.3.1

Changes look good.  Thanks for fixing this.
Harold

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

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5740

From minqi at openjdk.java.net  Thu Sep 30 14:43:55 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 30 Sep 2021 14:43:55 GMT
Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code
Message-ID: <PcXSfqeTadnEQMUjrOFHyyJ5RR_I2p8hSHivJHDYFB0=.9d323793-cee0-468b-bab9-e3902828e155@github.com>

Please review,
  Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive.
  With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check.

  Tests: tier1-4
   jtreg on sa.

Thanks
Yumin

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

Commit messages:
 - Fix comparison between size_t and unsigned int
 - 8273152: Refactor CDS FileMapHeader loading code

Changes: https://git.openjdk.java.net/jdk/pull/5768/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273152
  Stats: 423 lines in 11 files changed: 263 ins; 51 del; 109 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5768.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5768/head:pull/5768

PR: https://git.openjdk.java.net/jdk/pull/5768

From lzang at openjdk.java.net  Thu Sep 30 14:45:37 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 30 Sep 2021 14:45:37 GMT
Subject: RFR: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
 [v5]
In-Reply-To: <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
 <Q6Y7IylSygJMjMFScWddwa4GzXLc4KTRMGM91MjL0_0=.fa5237b6-48a7-4ed6-98a5-fc2102bdcec4@github.com>
Message-ID: <yW5ePxZxOulYdz465RBEBdKjHF3pdAkBEF4yo5KnHAA=.e99cf6e9-6a85-4394-b7bf-761e53d50454@github.com>

On Mon, 27 Sep 2021 14:28:43 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
>> 
>> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
>> 
>> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.
>
> Lin Zang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove load barrier for JNI local roots

Thanks all for your help reviewing this patch. I will integrate it.

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From lzang at openjdk.java.net  Thu Sep 30 14:48:34 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 30 Sep 2021 14:48:34 GMT
Subject: Integrated: 8274196: Crashes in VM_HeapDumper::work after JDK-8252842
In-Reply-To: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
References: <_Q2LQYt4iuP2C0-NdFPbogpOJMDygw415TcvCbaX19Y=.6c0d018e-e4d7-4c73-bc49-dcf90bff39e2@github.com>
Message-ID: <hV_o7gH75dtkEsJLClqWiTuVO7A-Oorv7FcCKYX8UBc=.b2433eae-4398-482e-b3bd-f63a10eab82b@github.com>

On Fri, 24 Sep 2021 13:13:39 GMT, Lin Zang <lzang at openjdk.org> wrote:

> The root cause for crash in ZGC is that the JNIHandles are processed before object iteration. And ZGC would update the JNIHandles at object iteration with read barrier. So the crash is cause by accessing the invalid address which can be dummy info after zgc, and hence crash.
> 
> The lock rank issue can be fixed because the related mutexes are acquired in safepoint. so the safepoint_check_required could be safepoint_check_always.
> 
> The Epsilon issue is caused by wrong _num_dumper_thread calculated when the gang==NULL.

This pull request has now been integrated.

Changeset: bfd61634
Author:    Lin Zang <lzang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bfd616347126a802c641326a6be5a14c4cd7af90
Stats:     22 lines in 3 files changed: 5 ins; 13 del; 4 mod

8274196: Crashes in VM_HeapDumper::work after JDK-8252842
8274245: sun/tools/jmap/BasicJMapTest.java Mutex rank failures

Reviewed-by: coleenp, pliden, cjplummer

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

PR: https://git.openjdk.java.net/jdk/pull/5681

From sgehwolf at openjdk.java.net  Thu Sep 30 15:23:33 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 30 Sep 2021 15:23:33 GMT
Subject: RFR: 8273216: JCMD does not work across container boundaries with
 Podman [v2]
In-Reply-To: <k1uSuRb2o_3rCfv1hrDrGyvCabzd9AiCGhtr7moHSaw=.6c0615e4-2a16-4ed5-a67e-d2d597b5b85c@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
 <k1uSuRb2o_3rCfv1hrDrGyvCabzd9AiCGhtr7moHSaw=.6c0615e4-2a16-4ed5-a67e-d2d597b5b85c@github.com>
Message-ID: <V1EUx1DRyuIyPyBjDAK5YjrQqD85anQ02E3CgzCchIw=.8e75264a-a15c-41e6-b58c-d87fb826f2b8@github.com>

On Wed, 29 Sep 2021 10:09:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check for podman version >= 3.3.1

Thank you, Harold!

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

PR: https://git.openjdk.java.net/jdk/pull/5740

From sgehwolf at openjdk.java.net  Thu Sep 30 15:28:37 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Thu, 30 Sep 2021 15:28:37 GMT
Subject: Integrated: 8273216: JCMD does not work across container boundaries
 with Podman
In-Reply-To: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
References: <wXoezvhqQ7ht2cDtXfmtiNQJos3Dn8--0gglpXN0CeY=.c60a1837-3a4d-4254-9491-f0475ad22509@github.com>
Message-ID: <q5nO1Wskt61xnMKtViSzboKZGxKuEy6SRCB9yi8bjuI=.f7edad14-4320-463b-b678-e86bd91c9872@github.com>

On Tue, 28 Sep 2021 16:05:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test fix so as to make it work with podman too. I've tested this with podman 3.3.1 when running as regular user and when running as root. Also tested it with docker on cgroups v1 with root. I don't know how to do rootless docker testing.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 9180d9a2
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9180d9a2f990e71ca6ac9c14e55a21f7372929ac
Stats:     105 lines in 1 file changed: 91 ins; 4 del; 10 mod

8273216: JCMD does not work across container boundaries with Podman

Reviewed-by: mseledtsov, hseigel

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

PR: https://git.openjdk.java.net/jdk/pull/5740

From iklam at openjdk.java.net  Thu Sep 30 16:23:33 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 30 Sep 2021 16:23:33 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <u9jRW-d_Rih1-sfTanKnBkfRMJLacCve_zvoSWGJLy8=.e15eefe5-5f5a-43a9-b7f9-f8e96d1bc313@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
 <zh9t2ydmuJXc76I31RdhorR9bbb-z6rUwWHWVhygKP4=.87485abe-5b8d-48b5-b520-fdd24af5a3ae@github.com>
 <u9jRW-d_Rih1-sfTanKnBkfRMJLacCve_zvoSWGJLy8=.e15eefe5-5f5a-43a9-b7f9-f8e96d1bc313@github.com>
Message-ID: <Ae5XN0mH_tmNvAIPs1nZk0HeF2WqL-lEtSY7861ZBh0=.5fc6aba5-7d9b-4141-888e-6db1aad3a5bc@github.com>

On Thu, 30 Sep 2021 08:31:51 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> > `RANGEBASE` was added by [JDK-6500501](https://bugs.openjdk.java.net/browse/JDK-6500501) and later was modified by [JDK-8027829](https://bugs.openjdk.java.net/browse/JDK-8027829)
> > Note the original comment from 6500501:
> > ```
> > // The characters allowed in a class or method name.  All characters > 0x7f
> > // are allowed in order to handle obfuscated class files (e.g. Volano)
> > ```
> 
> Thanks @vnkozlov for your very helpful comments.
> 
> I have one question: how can we specify (non-ascii chars) and (non-printable ascii chars) through `-XX:CompileCommand`?
> 
> I just learned from https://bugs.openjdk.java.net/browse/JDK-8027829 that we can use unicode like `\uxxxx`. But it doesn't work in my experiments.
> 
> My example was made from: https://bugs.openjdk.java.net/secure/attachment/17128/UnicodeIdentifierTest.java
> 
> ```
> public class UnicodeIdentifierTest {
>     public static void main(String args[]) {
>         System.out.println("Can I use \\u0001 in identifier name? " +
>                            (Character.isJavaIdentifierPart(1) ? "yes" : "no"));
>         for (int i = 0; i < 100000; i++ )
>         methodWithUnicode\u0001Char();
> 
>         System.out.println("Can I use \\u00aa in identifier name? " +
>                            (Character.isJavaIdentifierPart(0xaa) ? "yes" : "no"));
>         for (int i = 0; i < 100000; i++ )
>         methodWithUnicode\u00aaChar();
> 
>         System.out.println("Can I use \\u006b in identifier name? " +
>                            (Character.isJavaIdentifierPart(0x6b) ? "yes" : "no"));
>         for (int i = 0; i < 100000; i++ )
>         methodWithUnicode\u006bChar();
> 
>     }
>     public static int a = 0;
>     public static void methodWithUnicode\u0001Char() {
>         a++;
>     }
> 
>     public static void methodWithUnicode\u00aaChar() {
>         a++;
>     }
> 
>     public static void methodWithUnicode\u006bChar() {
>         a++;
>     }
> }
> ```
> 
> And I tried to exclude some specific methods like this
> 
> ```
> ${JDK}/bin/java \
>    -XX:+PrintCompilation \
>    -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest::methodWithUnicode\u0001Char"` \
>    -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest.methodWithUnicode\u0001Char"` \
>    -XX:CompileCommand=exclude,"UnicodeIdentifierTest.methodWithUnicode\u0001Char" \
>    -XX:CompileCommand=exclude,'UnicodeIdentifierTest.methodWithUnicode\u0001Char' \
>    -XX:CompileCommand=exclude,UnicodeIdentifierTest.methodWithUnicode\u0001Char \
>    -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest::methodWithUnicode\u00aaChar"` \
>    -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest.methodWithUnicode\u00aaChar"` \
>    -XX:CompileCommand=exclude,"UnicodeIdentifierTest.methodWithUnicode\u00aaChar" \
>    -XX:CompileCommand=exclude,'UnicodeIdentifierTest.methodWithUnicode\u00aaChar' \
>    -XX:CompileCommand=exclude,UnicodeIdentifierTest.methodWithUnicode\u00aaChar \
>    -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest::methodWithUnicode\u006bChar"` \
>    -XX:CompileCommand=exclude,`echo -e "UnicodeIdentifierTest.methodWithUnicode\u006bChar"` \
>    -XX:CompileCommand=exclude,"UnicodeIdentifierTest.methodWithUnicode\u006bChar" \
>    -XX:CompileCommand=exclude,'UnicodeIdentifierTest.methodWithUnicode\u006bChar' \
>    -XX:CompileCommand=exclude,UnicodeIdentifierTest.methodWithUnicode\u006bChar \
>    ${TEST}
> ```
> 
> But none of them worked.
> 
> So if there is no other way to specify a non-ascii chars, it seems safe to remove the non-ascii code.
> 
> If I miss something, please let me know. Thanks.

(The Chinese characters in this comment may not be displayed properly inside an e-mail reader. Please see this comment on GitHub https://github.com/openjdk/jdk/pull/5704)

-XX:CompileCommand does not process \uxxxx sequences. However, if your shell's locale is UTF8, you can do something like this, by directly entering them on the command-line, without escaping with \u: 


public class CJK {
    public static void main(String args[]) {
        \u722a\u54c7();
    }

    static void \u722a\u54c7() { // Chinese word for "Java"
        Thread.dumpStack();
    }
}
=======
$ locale
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

$ javac CJK.java
$ java -Xcomp -XX:-BackgroundCompilation -XX:CompileCommand='compileonly,*::??' -XX:+PrintCompilation -cp . CJK > log.txt
java.lang.Exception: Stack trace
	at java.base/java.lang.Thread.dumpStack(Thread.java:1380)
	at CJK.??  (CJK.java:7)
	at CJK.main(CJK.java:3)
$ grep '^   ' log.txt
     53    1    b  3       CJK::\u722a\u54c7 (4 bytes)
     53    2    b  4       CJK::\u722a\u54c7 (4 bytes)
     53    1       3       CJK::\u722a\u54c7 (4 bytes)   made not entrant

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From minqi at openjdk.java.net  Thu Sep 30 16:23:34 2021
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 30 Sep 2021 16:23:34 GMT
Subject: RFR: 8273152: Refactor CDS FileMapHeader loading code [v2]
In-Reply-To: <PcXSfqeTadnEQMUjrOFHyyJ5RR_I2p8hSHivJHDYFB0=.9d323793-cee0-468b-bab9-e3902828e155@github.com>
References: <PcXSfqeTadnEQMUjrOFHyyJ5RR_I2p8hSHivJHDYFB0=.9d323793-cee0-468b-bab9-e3902828e155@github.com>
Message-ID: <L9R-CjIvGEejbFtgEF-2GREL7ivyNg67PoT4X8jEHAw=.e761c3ef-eaa6-4a54-a663-8b3f43a670fe@github.com>

> Please review,
>   Refactor fundamental CDS FileMapHeader code for reliable reading of basic info from shared archive.
>   With the change, it makes it possible to read an archive generated by different version of hotspot. Also it is possible to automatically generate a CDS archive If the archive supplied is not readable or fails to pass the check.
> 
>   Tests: tier1-4
>    jtreg on sa.
> 
> Thanks
> Yumin

Yumin Qi has updated the pull request incrementally with one additional commit since the last revision:

  Fixed miss return after file read failed

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5768/files
  - new: https://git.openjdk.java.net/jdk/pull/5768/files/eb560883..032e819c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=5768&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/5768

From lucy at openjdk.java.net  Thu Sep 30 16:33:51 2021
From: lucy at openjdk.java.net (Lutz Schmidt)
Date: Thu, 30 Sep 2021 16:33:51 GMT
Subject: RFR: JDK-8274434: move os::get_default_process_handle and
 os::dll_lookup to os_posix for POSIX platforms
In-Reply-To: <4Dt5972d0-anhV1jfU2BCrcaaANGedVnxNkrFjPz34M=.55c5f633-a698-4c33-898c-bacb1127075e@github.com>
References: <4Dt5972d0-anhV1jfU2BCrcaaANGedVnxNkrFjPz34M=.55c5f633-a698-4c33-898c-bacb1127075e@github.com>
Message-ID: <fr7BpfOTddLRBf7aNUkUqS61ebw5LMHKdOHch7fRbxw=.7ad3b0f4-ae87-4ab6-8fbe-588587d578ba@github.com>

On Tue, 28 Sep 2021 11:13:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Hello, please review this small change.
> The os::get_default_process_handle and os::dll_lookup functions are pretty similar across the POSIX platforms so they can be moved to os_posix.cpp.

Changes look good to me. 
With respect to the Apple special casing I have requested an opinion from knowledgeable people. I would suggest to wait 24 hours for feedback.

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

Changes requested by lucy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5737

From iklam at openjdk.java.net  Thu Sep 30 17:56:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 30 Sep 2021 17:56:39 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
Message-ID: <4RQ7uX1dWVQYPu8WFnqt0bx4nFoq3ijIUQ6WMSP-INc=.e1274b05-a6e9-4227-9588-08310c3cffac@github.com>

On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
> 
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 files for java.base
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): error C2220: the following warning is treated as an error
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4778: 'sscanf' : unterminated format string '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): note: placeholders and their parameters expect 1 variadic arguments, but 3 were provided
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4778: 'sscanf' : unterminated format string '%1022[[);/\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e%n'
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): warning C4474: 'sscanf' : too many arguments passed for format string
> e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(319): note: placeholders and their parameters expect 0 variadic arguments, but 2 were provided
> 
> 
> The failure is caused by non-ASCII chars in the format string of sscanf [1][2], which is non-portable on our Windows platform.
> In fact, these non-ASCII coding also triggers C4819 warning, which had been disabled in JDK-8216154 [3].
> And I also found an article showing that sscanf may fail with non-ASCII in the format string [4].
> 
> So it would be nice to remove these non-ASCII chars  (`\x80 ~ \xef`).
> And I think it's safe to do so.
> 
> This is because:
>  1) There are actually no non-ASCII chars for package/class/method/signature names.
>  2) I don't think there is a use case, in which people will input non-ASCII for `CompileCommand`.
> 
> You may argue that the non-ASCII may be used by the parser itself.
> But I didn't find that usage at all. (Please let me know if I miss something.)
> 
> So I suggest to remove these non-ASCII code to make HotSpot to be more portable.
> And if we do so, we can also remove the only one `PRAGMA_DISABLE_MSVC_WARNING(4819)` [5].
> 
> Testing:
>  - Build tests on Windows
>  - tier1~3 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L269
> [2] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L246

The current limitations of the MethodMather class are:

[1] `parse_method_pattern(char*& line, ...)` requires `line` to be a UTF8-encoded byte sequence. Essentially, this means that for -XX:CompileCommand to support non-ASCII characters, the JVM (and the shell that runs the JVM) must be using UTF8 character encoding.

Note that a "locale" contains 3 parts: language, country and character encoding. For example,

- en_US.utf8 (English language, United States, UTF8 character encoding)
- zh_CN.utf8 (Chinese language, China,  UTF8 character encoding)
- zh_CN.gbk (Chinese language, China,  GBK character encoding)

The first two support  non-ASCII characters in  -XX:CompileCommand, but the third one doesn't.

[2] MethodMather uses `sscanf`. It assumes that the JVM is running with UTF8 character encoding because

- It uses `char*` strings returned by `sscanf` to compare with the bytes stored in Symbols. This requires `sscanf`  to return strings that are encoded in UTF8, because Symbols stores the string with UTF8-encoded bytes.
- It relies on range checking by `sscanf` to enforce the following restrictions. However, these restrictions are given with the RANGE macro which is UTF8 encoded bytes (and I suspect that these are incorrect when handling multi-byte UTF8-encoded characters):


// '\0' and 0xf0-0xff are disallowed in constant string values
// 0x20 ' ', 0x09 '\t' and, 0x2c ',' are used in the matching
// 0x5b '[' and 0x5d ']' can not be used because of the matcher
// 0x28 '(' and 0x29 ')' are used for the signature
// 0x2e '.' is always replaced before the matching
// 0x2f '/' is only used in the class name as package separator

==================================
Proposed solutions:

I don't think we can solve [1] easily. To handle non-ASCII characters that are non encoded in UTF8, we need to call NewPlatformString() in src/java.base/share/native/libjli/java.c. However, this executes Java code, but -XX:CompileCommand needs to be processed before any Java code execution.  ==> Proposal: IGNORE it for now.

For [2], there are two distinct issues:

(a) The restriction checks are invalid when the JVM is running in an non-UTF8 encoding -- this is a moot point because we can't handle [1] anyway, so the data given to sscanf() is already bad.   => Proposal: IGNORE it for now

(b) VC++ compilation warning when methodMather.cpp is compiled in non-UTF8 environments

This is just a warning, and (I think .....) it doesn't change the object file at all. I.e., the literal strings in methodMatcher.obj are exactly the same as if methodMather.cpp is compiled under a UTF8 environment.

Proposal: use pragma to disable the warning.
Assuming that my analysis for [1] and (a) is correct, there's no reason to fix the sscanf code. Disabling the warnings with pragma is the most painless and easiest way to handle this.

@DamonFool could you try this experiment:

- Implement the pragma and build two JDKs -- one in a Chinese Windows environment, and another in an English Windows environment 
- run `strings methodMatcher.obj` and see if the output is identical
- run the "CJK" test example in my previous comment, and see if you get identical results with both JDKs
  - On Windows, you may need to do this to force the terminal to be using UTF8 code page. See https://stackoverflow.com/questions/388490/how-to-use-unicode-characters-in-windows-command-line

(If this doesn't work, an alternative is to avoid using sscanf and write our own parser).

Thanks

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From jiefu at openjdk.java.net  Thu Sep 30 23:07:31 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 23:07:31 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <4RQ7uX1dWVQYPu8WFnqt0bx4nFoq3ijIUQ6WMSP-INc=.e1274b05-a6e9-4227-9588-08310c3cffac@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
 <4RQ7uX1dWVQYPu8WFnqt0bx4nFoq3ijIUQ6WMSP-INc=.e1274b05-a6e9-4227-9588-08310c3cffac@github.com>
Message-ID: <Ft1puXIxgRPcNQXbjF2rondH6NHunmsvMnesAeB5tGc=.1f75516b-6df0-4bb4-8f98-fc002d3198fd@github.com>

On Thu, 30 Sep 2021 17:53:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> The current limitations of the MethodMather class are:
> 
> [1] `parse_method_pattern(char*& line, ...)` requires `line` to be a UTF8-encoded byte sequence. Essentially, this means that for -XX:CompileCommand to support non-ASCII characters, the JVM (and the shell that runs the JVM) must be using UTF8 character encoding.
> 
> Note that a "locale" contains 3 parts: language, country and character encoding. For example,
> 
> * en_US.utf8 (English language, United States, UTF8 character encoding)
> * zh_CN.utf8 (Chinese language, China,  UTF8 character encoding)
> * zh_CN.gbk (Chinese language, China,  GBK character encoding)
> 
> The first two support non-ASCII characters in -XX:CompileCommand, but the third one doesn't.
> 
> [2] MethodMather uses `sscanf`. It assumes that the JVM is running with UTF8 character encoding because
> 
> * It uses `char*` strings returned by `sscanf` to compare with the bytes stored in Symbols. This requires `sscanf`  to return strings that are encoded in UTF8, because Symbols stores the string with UTF8-encoded bytes.
> * It relies on range checking by `sscanf` to enforce the following restrictions. However, these restrictions are given with the RANGE macro which is UTF8 encoded bytes (and I suspect that these are incorrect when handling multi-byte UTF8-encoded characters):
> 
> ```
> // '\0' and 0xf0-0xff are disallowed in constant string values
> // 0x20 ' ', 0x09 '\t' and, 0x2c ',' are used in the matching
> // 0x5b '[' and 0x5d ']' can not be used because of the matcher
> // 0x28 '(' and 0x29 ')' are used for the signature
> // 0x2e '.' is always replaced before the matching
> // 0x2f '/' is only used in the class name as package separator
> ```
> 
> ================================== Proposed solutions:
> 
> I don't think we can solve [1] easily. To handle non-ASCII characters that are non encoded in UTF8, we need to call NewPlatformString() in src/java.base/share/native/libjli/java.c. However, this executes Java code, but -XX:CompileCommand needs to be processed before any Java code execution. ==> Proposal: IGNORE it for now.
> 
> For [2], there are two distinct issues:
> 
> (a) The restriction checks are invalid when the JVM is running in an non-UTF8 encoding -- this is a moot point because we can't handle [1] anyway, so the data given to sscanf() is already bad. => Proposal: IGNORE it for now
> 
> (b) VC++ compilation warning when methodMather.cpp is compiled in non-UTF8 environments
> 
> This is just a warning, and (I think .....) it doesn't change the object file at all. I.e., the literal strings in methodMatcher.obj are exactly the same as if methodMather.cpp is compiled under a UTF8 environment.
> 
> Proposal: use pragma to disable the warning. Assuming that my analysis for [1] and (a) is correct, there's no reason to fix the sscanf code. Disabling the warnings with pragma is the most painless and easiest way to handle this.
> 
> @DamonFool could you try this experiment:
> 
> * Implement the pragma and build two JDKs -- one in a Chinese Windows environment, and another in an English Windows environment
> * run `strings methodMatcher.obj` and see if the output is identical
> * run the "CJK" test example in my previous comment, and see if you get identical results with both JDKs
>   
>   * On Windows, you may need to do this to force the terminal to be using UTF8 code page. See https://stackoverflow.com/questions/388490/how-to-use-unicode-characters-in-windows-command-line
> 
> (If this doesn't work, an alternative is to avoid using sscanf and write our own parser).
> 
> Thanks

Thanks @iklam for your excellent analysis.

So HotSpot does support non-ASCII chars as names.
Then we shouldn't simply remove such non-ASCII code.

I will do your experiment next week.
This is because it's already our National Day week and I can't find an English Windows machine until next week.
I'll let you know the result as soon as possible.
Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From iklam at openjdk.java.net  Thu Sep 30 23:33:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 30 Sep 2021 23:33:39 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <Ft1puXIxgRPcNQXbjF2rondH6NHunmsvMnesAeB5tGc=.1f75516b-6df0-4bb4-8f98-fc002d3198fd@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
 <4RQ7uX1dWVQYPu8WFnqt0bx4nFoq3ijIUQ6WMSP-INc=.e1274b05-a6e9-4227-9588-08310c3cffac@github.com>
 <Ft1puXIxgRPcNQXbjF2rondH6NHunmsvMnesAeB5tGc=.1f75516b-6df0-4bb4-8f98-fc002d3198fd@github.com>
Message-ID: <FqtSWX8Zh5CKHDCDF8YFTASqO9OvL6_MwGAI9jexJMo=.1127b7fb-e7c2-450c-acb9-d5cabd242c7d@github.com>

On Thu, 30 Sep 2021 23:04:17 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> I will do your experiment next week. This is because it's already our National Day week and I can't find an English Windows machine until next week. I'll let you know the result as soon as possible. Thanks.

No need to hurry :-). In case you can't find an English Windows, I think you can use the `chcp 65001` command mentioned in https://stackoverflow.com/questions/388490/how-to-use-unicode-characters-in-windows-command-line to change your command-line window to use the UTF8 codepage.

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

PR: https://git.openjdk.java.net/jdk/pull/5704

From jiefu at openjdk.java.net  Thu Sep 30 23:44:43 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Thu, 30 Sep 2021 23:44:43 GMT
Subject: RFR: 8274329: Fix non-portable HotSpot code in
 MethodMatcher::parse_method_pattern
In-Reply-To: <FqtSWX8Zh5CKHDCDF8YFTASqO9OvL6_MwGAI9jexJMo=.1127b7fb-e7c2-450c-acb9-d5cabd242c7d@github.com>
References: <BwaPtohTwbzJesayNf3PyTyEVoYVCqyf4heFQuVkevM=.a9642566-74eb-4838-ad6f-960944c2f78d@github.com>
 <4RQ7uX1dWVQYPu8WFnqt0bx4nFoq3ijIUQ6WMSP-INc=.e1274b05-a6e9-4227-9588-08310c3cffac@github.com>
 <Ft1puXIxgRPcNQXbjF2rondH6NHunmsvMnesAeB5tGc=.1f75516b-6df0-4bb4-8f98-fc002d3198fd@github.com>
 <FqtSWX8Zh5CKHDCDF8YFTASqO9OvL6_MwGAI9jexJMo=.1127b7fb-e7c2-450c-acb9-d5cabd242c7d@github.com>
Message-ID: <S-BEY06hO6hwRPgqnnXNIBOAbUApGcvo_bzMlP2lzvU=.a1045068-c44c-482b-ab5f-c6267f5206e5@github.com>

On Thu, 30 Sep 2021 23:30:29 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> > I will do your experiment next week. This is because it's already our National Day week and I can't find an English Windows machine until next week. I'll let you know the result as soon as possible. Thanks.
> 
> No need to hurry :-). In case you can't find an English Windows, I think you can use the `chcp 65001` command mentioned in https://stackoverflow.com/questions/388490/how-to-use-unicode-characters-in-windows-command-line to change your command-line window to use the UTF8 codepage.

Okay.

I also note the warning

e:\jiefu\ws\jdk\src\hotspot\share\compiler\methodMatcher.cpp(269): warning C4778: 'sscanf' : unterminated format string '%255[*\x01\x02\x03\x04\x05\x06\a\b\n\v\f\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f!"#$%&'*+,-0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ\^_`abcdefghijklmnopqrstuvwxyz{|}~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n'


It is already different with the original `RANGEBASE` sequence [1].

~\xe2\x82\xac\xe4\xba\x97\xe5\x84\x8e\xe5\x8e\x97%n

vs.

    "\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f" \
    "\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f" \
    "\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf" \
    "\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf" \
    "\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf" \
    "\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf" \
    "\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef"


Not sure if this fact is sufficient to say the literal strings will be different in methodMatcher.obj.
[1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L49

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

PR: https://git.openjdk.java.net/jdk/pull/5704